一.趋势
随着容器化和深度学习等技术在生产中的应用,越来越多的场景需要“远程”开发。例如:
服务器虚拟机容器等远程环境往往难以或无法在本地完全重建,比如:
特定配置:例如曾经遇到的
,以及安装了特定版本补丁的历史项目,几乎无法重现其环境特定操作系统:例如在 Windows 上开发运行在 Linux 的项目对本地环境的破坏性太大:一些全局性的东西,很难做到完全隔离依赖本地不具备的硬件能力:例如深度学习所需的计算和存储能力无论什么原因,总会面临本地与远程环境差异带来的各种不便
二.现状对于远程开发的场景,通常有 4 种解决方案:
远程桌面:开发体验与本地环境差异较大,并且有些 Linux 发行版无法安装远程桌面SSH + Vim:不如现代开发工具方便,影响生产力文件同步工具:速度慢,而且容易出错基于浏览器的工具:难以结合本地工具链使用虽然能解决部分问题,但大多牺牲了本地开发环境的诸多便利
那么,有没有办法从本地环境无缝切入远程环境呢?既能享受本地熟悉的全套工具链带来的便利,同时还能进行远程开发呢?
当然有
三.思路从开发工具的角度来看,需要提供 3 方面的支持:
支持在 Windows 下开发 Linux支持 SSH 连接支持容器环境对于在 Windows 下开发 Linux 的问题,Win 10 在 2016 年已经提供了Windows Subsystem for Linux (WSL),可以在 Windows 下直接(没错,不是虚拟机)运行一个 Linux 子系统:
WSL 提供了基本的文件共享支持,但开发工具(例如 VS Code)面临的情况要更复杂一些:
开发工具需要明确区分不同环境,于是产生了一种很有趣的思路:
简言之,让一部分(环境无关的)插件在本地环境运行,另一些(环境相关的)插件在远程环境运行,比如容器、虚拟机、WSL、服务器等等……
如此这般,一切问题都解决了,在支持远程开发的同时兼顾了本地开发体验:
四.VS Code 远程开发套件VS Code 在 1.35 版本(2019/6/4)正式发布了 Remote Development 支持:
并在最新 1.36 版本中增加了更多特性:
安装Remote Development插件包即可,目前(2019/7/6)插件包里提供了 3 个插件:
Remote – SSH:将远程机器或虚拟机作为开发环境Remote – Containers:将 Docker 容器用作开发环境Remote – WSL:将 Windows 子系统作为开发环境Remote – SSH通过 SSH 通道连接远程机器、虚拟机或容器,继而访问其文件系统、管理终端、运行/调试应用,如下图:
具体来说,基于 SSH 的远程开发支持让我们:
不必受限于本地环境的硬件条件能够管理多套不同的远程开发环境能够远程调试应用在远程运行,而开发调试可以在本地进行,继续享受熟悉的本地完备工具链带来的便利
P.S.关于 SSH 远程开发的更多细节,请见:
演示视频:Visual Studio Code Remote – SSH用法文档:Remote Development using SSHRemote – Containers更进一步地,容器支持允许将指定的 Docker 容器作为开发环境,进而:
能够保证工具链的一致性,并且依靠容器可以快速重建一整套工具链容器间有着天然的环境隔离,可以在不同的开发环境间切换而不影响本地环境能够保证开发/构建/测试环境的一致性,便于协作实现上,结构与 WSL 支持完全一致:
P.S.关于 Docker 容器远程开发的更多细节,请见:
演示视频:Visual Studio Code Remote – Containers用法文档:Developing inside a ContainerRemote – WSL通过 Remote – WSL 插件,可以将 WSL 用作整套开发环境,具体来说,支持以下特性:
在 Windows 上在 Linux 环境中开发,而且可以使用平台相关的工具链编辑位于 WSL 的文件,包括挂载自 Windows 文件系统的那些(如
)在 Windows 上调试运行 Linux 应用程序P.S.关于 WSL 远程开发的更多细节,请见:
演示视频:Visual Studio Code Remote – WSL用法文档:Developing in WSL五.总结就目前而言,能够无缝切入远程环境的 IDE,似乎要比云 IDE 更实际一些:
参考资料Remote Development with VS CodeDeveloping on a remote serverThe new Windows subsystem for Linux architecture: a deep dive – BRK3068