VSCode远程开发

VSCode远程开发

VScode远程开发的意义

在进行论文的研读中，往往要对别人已有的开源代码，进行一次跑通的过程，期间可能会修改一些参数，调整一些代码。但是，由于代码的完成时间不同，可能是上古代码；可能会遇到各种奇怪的运行环境，比如各种奇怪的框架；当然另外一个问题是严格的插件版本适配性。

在保证可运行的基础上进行跑通，以及做一些基本的测试操作，代码修正等，会要求不同的运行环境，这时候除了使用docker构建对应版本的镜像，没有更好的选择，anaconda也许可以适配部分不同的运行环境，但是绝不是最完美的解决方式。

• 即使可以耗费时间手动配置多种CUDA版本，但是对于具体的系统版本不一定适配，此时docker方式绝对是最佳的选择方式。
• 有利于保存之前所做的操作，有助于在以后的某段时间内快速查看之前的修改结果.
• docker的性能优秀，除了网络吞吐的性能表现差(折半)，内存，硬盘，CPU以及GPU损耗约为2%.
• 随时随地只需要一个电脑连接到环境即可，不需要每使用一台电脑就配置一次运行环境.

严格的远程开发，指的是代码编辑环境于代码运行环境独立开来，如：运行在window10上的编辑器连接到运行在同一电脑上的WSL2运行环境，WSL2是真内核…

VSCode远程开发的配置

要使用远程开发，总体而言，比较简单，只需要在VSCode的扩展插件中，安装 ‘Remote Development’ 即可，会安装 ‘Remote WSL’, ‘Remote SSH’, ‘Remote Containers’ 三件套。

在扩展插件图标的上面，找到 ‘Remote Explorer’ ,选择对应的远程类型即可， 有’Containers’， ‘SSH Targets’ ,WSL Targets’可选，'Containers’会查看远程和本地运行的镜像而生成的容器。

扩展插件图标下方有一个 ‘docker’ 的鲸鱼图标，这个只会查看本地运行的docker容器.

第一种方式:直接将服务端的docker镜像到本地docker的client

结论：极其不推荐。

可以查看 https://segmentfault.com/a/1190000023095631去了解配置.
核心部分如下：

# 在 window10上，需要开启ssh-agent，忘记开启，VSCode会自动提示。

"""
下载docker.exe文件，也可以完全安装docker desktop.不过安装完成重启电脑后，启动docker desktop会提示未完全安装，直接安装弹出的链接，按照安装即可.
docker desktop, 完全安装后，界面会提示：当前未完全适配容器作为远程开发环境，需要升级，很显然的是docker当前对远程的支持并没有完全处理好，VSCode同样。
保证docker desktop安装完成，或者docker.exe在path路径，或Powershell在当前路径打开.
"""
# 使用frpc 转发宿主机信息 到frps nat服务器，本地frpc接受后转发到 访问主机的12222
docker context create mytest --docker "host=ssh://[email protected]:12222"

# 使用远程主机docker，作为服务，访问主机查询宿主机开启的docker容器.
docker context use mytest

# 删除配置.
docker context rm mytest -f

# 查看是否能连接到宿主机，若可以显示宿主机系统，内存，显卡等，说明连接正常.
docker info

第一种方式VSCode远程开发的问题

PS：使用将linux的docker服务镜像到docker client存在的问题.

• 代码以及运行环境都在宿主机，同时非常慢，即使局域网下使用任然如此，具体原因未知.
• 本人使用Ubuntu连接容器环境，大概2分钟左右断开一次，但是重新刷新一下，断开就会重新连接上.(也许是像ssh到电脑，需要发送no-ctl-string来解决断开问题.)
• 可以直接在Ubuntu VSCode使用docker内对应的环境；但是访问主机不是同一台电脑，并不能直接运行环境，无法配置Interpreter，只能编辑.（shift+ctl+p操作.）

折中的合理方式

• 使用 'Remote SSH’可能是一个折中方案，该连接模式下，可以非常流畅，且不卡顿的连接到宿主机文件夹，但是有时候仍然会无法选择对应的python解释器.不能直接在VSCode编辑器下直接运行代码。这种情况一般退出远程连接，退出VSCode，重新连接，即可解决。

---

第二种方式：直接在docker容器镜像内部开放22端口.

结论：推荐，我甚至认为上述没有存在的必要，除非docker有巨大的改进，能解决卡顿问题。

第二种方式是完全将docker运行的镜像内部开放22端口，使用ssh直接连接到内部的容器环境。这时候是完全将镜像环境当做一台真正的电脑进行操作即可。比如：Remote-SSH 雷同的所有远程方式，可以按照以上方式进行操作：

构建镜像

镜像构建的教程很多，一般是两种方式

• 直接运行镜像，在容器内，想在linux操作系统上安装软件一种，最后提交即可.

  # 像在真实的电脑上安装软件一样.
  

• 第二种是使用dockerfile构建。

  # 构建镜像,如切换到dockerfile对应的目录下执行如下.
  docker build -t ubuntu1804:v1 .
  '''
  -t tag的意思，生成的镜像文件名称，v1代表版本号，可以不写，默认latest， .表示当前路径
  其中更加复杂些的有context以及使用docker cp的限定范围问题。
  '''
  

运行镜像

• 配置默认的cuda环境，配置方式按照NVIDIA的说明有两种，其他教程往往配置两种，其实只需要配置其中一种即可。

sudo vim /etc/docke/daemon.json
{
    "runtimes": {
        "nvidia": {
            "path": "nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}
sudo systemctl daemon-reload
sudo systemctl start docker 

• 运行镜像

docker run -it --runtime=nvidia --rm -v /media/gaoming/CommonBak/DFace:/var/data_test naoming/kuaikuaikim_dface /bin/bash

# 上述可以改为下面一条，其实保持容器打开，而不是运行之后就关闭，只需要 -it参数即可。
docker run -it --gpus all --rm -v /media/gaoming/CommonBak/DFace:/var/data_test naoming/kuaikuaikim_dface

# 更加合理的应该是停止容器不自动删除容器,并且映射出22到host端口.
docker run -d -it --gpus all --name newmy -p 25600:22 -v /media/gaoming/CommonBak:/var/data_test mmdetection

# 与上一行的区别：就是该行只能ssh [email protected] -p 25600,所以只能本机连接，上面一行局域网的主机都可以接入到docker内部环境.
# 但使用frpc转发端口的仍然可用，不会影响.
docker run -d -it --gpus all --name newmy -p 127.0.0.1:25600:22 -v /media/gaoming/CommonBak:/var/data_test mmdetection

• 镜像内部开启ssh，一般镜像没有启动ssh服务，所以需要自己开启对应的服务.

# 必须配置密码.
passwd
1234567890

# 安装ssh.
uname -a
apt-get update && apt-get install openssh-server openssh-client vim -y

# 先关闭服务.
service ssh stop

# 需要编辑，添加以下五行.
vim /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin yes
MaxStartups 1000

# 调试模式运行：注意 有一个ssh连接，第二个自动拒绝连接，调试模式对判断是host还是docker容器的问题非常有用.
/usr/sbin/sshd -d

# 启动服务，chconfig开启自启，systemctl自启设置无效，因为没有该命令.貌似有没有装的必要，因为启动非常简单.
service ssh start

# 不需要密码，则需要添加访问端主机的公匙.
mkdir /root/.ssh
touch /root/.ssh/authorized_keys
cat i* > /root/.ssh/authorized_keys

#  访问主机公钥生成.
ssh-keygen

# 直接回车多次即可，默认在~/.ssh/目录下.

Pycharm的意义.

• pycharm的远程是一种，本地保留一份代码，宿主机保留代码，同时会有个temp文件，也可以通过pytcharm提交一份类似于git tag的状态到宿主机.
• 使用docker内部的环境，由于同步代码到本地的机制，因此速度快，连接稳定.

结论

• Remote-Explorer提供的三种方式，我认为最合理最有效的是：Remote-SSH，将容器22端口开放，也可以使用 Remote-SSH。搭配frp的端口转发，非常完美，运行在nat主机上的frps也非常廉价，因为nat主机一年100多块钱，1000GB双向流量，也有200出头的500M带宽2T的双向流量套餐，简而言之nat流量和带宽的价格非常便宜。

• 可以使用Remote-Explorer中的container，但是最好是同一台电脑上，比如windows10开一个WSL2，即使局域网下使用docker server <==> docker client体验也非常糟糕。