Visual Studio Code 远程开发探秘

摘要： IDE新时代！

作者：SHUHARI 的博客

原文：Visual Studio Code 远程开发探秘

Fundebug按照原文要求转载，版权归原作者所有。

在以前的文章 有趣的项目 - 在浏览器中运行 Visual Studio Code， 我介绍过 Coder 开发团队将 Visual Studio Code 搬到浏览器里的尝试。这是一个有趣的项目，不过没有想到的是，这之后不久微软官方就推出了 VSCode 的远程开发扩展，这简直是官方逼死同人的节奏。从 Coder 官网 的信息来看，他们似乎已将精力主要放到企业版本，这应该算一个生不逢时的产品吧。今天我们来介绍一下微软自己基于 VSCode 的远程开发平台。

从原理上讲，VSCode 远程开发扩展相当于把开发者自己机器上的 VSCode 原样拷贝到作为目标机器（Remote Host）上，以服务的形式运行，而本地的 VSCode 作为客户端，两者之间通过远程通讯协议彼此协调合作，实际上的开发工作主要是在服务端完成的。这个架构特别之处在于，我们日常所使用的扩展也被分成两个阵营：和界面定制相关的部分，主要包括样式、主题、图标等等在客户端运行；而与开发相关的大部分扩展则在服务端运行。后面在实际操作的部分，我们会看到界面上相应的变化。

目前，VSCode 远程开发支持下列三种主要模式：

Remote SSH：通过 SSH 连接到 Linux 服务器；

Remote Container：连接到 Docker 容器；

Remote WSL：连接到已安装的 WSL 环境。

本文主要介绍第一种，基于 SSH 的方式。容器方式除了初始化配置方面有一些区别以外，具体使用上基本相同。至于 WSL，按照目前的发展方向，可以认为它和从虚拟机运行 Linux 没什么差别，所以我不会特别关注它。想要使用该方式的同学可以参考 官方文档。

为了使用 VSCode Remote SSH，首先请确认你了解它的一些限制与前提条件。

Remote SSH 只支持 Linux 作为服务器，且必须是 64 位版本。这可能是因为 Linux 才有完整的 SSH 服务器支持，而 Windows 或 MacOS 都需要一些额外的工作。鉴于大部分生产服务器都应该是 Linux，相信这个限制对大多数同学不成问题；

对于 Linux 的具体类型，官方明确支持的包括 Debian、RHEL/CentOS 与 Ubuntu 三大发行版。其他很多 Linux 版本也应该可以工作，但并不保证，也有一些比较少见的版本不受支持（主要是因为 glibc 等基础环境的支持问题）。另外，CentOS 最好是 7.x 以上，6.x 版本通常需要一定的调整才能工作（参考: Updating glibc and libstdc++ on RHEL / CentOS 6）；

当然，要使用 Container 或 WSL 方式，在机器上必须有 Docker 或者 WSL 的基础环境；

本地机器上应该有 SSH 命令行客户端。对于 Win10，只要不是补丁太旧的话，应该已经内置了 OpenSSH。Putty 目前是不受支持的。

确认前提条件已满足，接下来应该在自己的 VSCode 中安装远程开发扩展。

远程开发扩展的名称是 Remote Development，它实际上是一个扩展包（Extension Pack），由 Remote-SSH、Remote-Containers、Remote-WSL 以及 Python 四个扩展组合而成，除了 Python 主要用于功能支持外，其他三个扩展功能是很明显的。目前该扩展仍然处于预览状态，不过已经可以安装到 VSCode 正式版了（若不能安装的话，请确认 VSCode 版本高于 1.35）。

要通过 SSH 连接服务器，我们可以使用用户名/密码或者 SSH Key。对于日常使用的环境来说，基于 SSH Key 的方式尽管初始配置要麻烦一些，但是一劳永逸。

生成 SSH Key 并分发到远程机器是服务器运维的常规操作，具体过程就不再赘述了。官方文档也有一个比较详细的 步骤指导，需要的同学可以参考。

这里补充说明一点，对于 Windows 客户端，生成的 Key 通常位于 %USERPROFILE%.ssh 目录下。在后续的配置部分我们会用到这个目录。

配置好 SSH Key 就可以连接到服务器了。最直接的方法是通过命令面板，选择命令 Remote-SSH: Connect to Host，然后按照提示输入格式为 user@host 的服务器地址。

但是每次打开环境都要手工输入地址显然是很不人道的，于是远程开发扩展为我们提供了保存服务器配置的方式。调用该方式一般也是通过命令面板：Remote-SSH: Open Configuration File。

该命令又会进一步提示我们选择哪个配置文件来编辑。

你可以认为上图中两个文件分别代表机器级别和用户级别的配置，通常应该选择用户级别配置。打开以后会看到，它已经为我们提供了一个默认模板。我们按格式添加服务器记录，并且额外提供一个证书文件的位置参数。对于服务器地址和用户名，请按你的实际情况输入：

# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
# Host alias
#    HostName hostname
#    User user

Host test-server
    HostName <192.168.207.130>
    User 
    IdentityFile C:/Users//.ssh/id_rsa

在安装完远程开发扩展之后，我们会注意到在活动栏下边多了一个远程图标，点击该图标会出现远程视图，其中包含了我们已经定义过的服务器。在服务器上右键点击，选择 Connect to Host in Current/New Window，就会在当前窗口或新窗口打开到服务器的连接，让你开始工作。

第一次连接到远程服务器时的初始化工作需要消耗一段时间，以后再次打开就会快很多。请耐心等待服务器初始化完成，如果一切正常，你就会看到 VSCode 转变为远程开发模式。

当工作环境处于远程模式的时候，你会注意到和本地开发的一些不同之处。

首先，状态栏左边会用绿色的文字明确指示当前处于远程模式（使用其他主题的话颜色可能会有所不同）：

其次，当你使用“打开文件”或“打开目录”命令的时候，也会发现现在显示的已经不是操作系统的本地文件对话框，而是另外一个不同的界面，用于选择远程服务器上的路径：

此外，你还应该注意以下扩展视图的变化。

从图中我们可以看到，远程开发扩展以及一些界面主题是保留在本地 VSCode 的，而用于开发的扩展则在本地被禁用了。可能是出于性能的考虑，这些扩展并没有自动安装到远程服务器上，要在远端开启这些扩展的话，需要在图中对特定的扩展选择 Install on SSH 命令。对于已经安装到远端的扩展，则会显示提示信息 Extension is enabled on SSH and disabled locally。

接下来的操作和普通的本地开发就没什么差别了。你可以打开目录、编辑文件、执行程序，等等。但需要注意的是，现在几乎所有操作幕后都是在服务器上完成的，如果你还下意识地以为是本地操作的话，有时候就难免有点混乱，所以还是应该坚持一段时间来适应。

还有一点补充建议：如果服务端是 Linux 而客户端是 Windows，并且你将要打开的是一个 Git 仓库的话，请考虑在 Git 中配置 autocrlf = false，，以避免不同平台对换行的处理差异导致莫名其妙的变更问题。

最近我录制了一个课程 Visual Studio Code 全景学习，其中对设置的结构有专门的介绍。VSCode 的设置是一个非常灵活、但又相当复杂的层次结构，在远程开发的背景下，又多了一个远程设置的来源，所以结构是更加复杂了。

在默认情况下，本地的 VSCode 用户配置会自动应用到远程服务器环境，不需要我们做额外的工作。但客户端和服务器通常是不同的操作系统，它们之间难免有一些差异，所以有时候还是要对远程环境多带带作一些配置。为此，VSCode 提供了一个命令 Open Remote Settings 专门用来编辑远程配置。和其他命令一样，你可以从命令面板（Command Palette）调用它。

另外，远程开发也注册了一些自己特有的配置信息。其中最主要的可能是 remote.extensionKind。我们在本文前面的原理部分讲述过，为了支持远程开发模式，VSCode 会把扩展分为本地和远程两种运行类型。一般来说，VSCode 会自动判断扩展应该放在哪个位置，但也有一些情况可能不太好判断，所以 VSCode 允许我们自行配置它。

{
    "remote.extensionKind": {
        "ext1": "ui",
        "ext2": "workspace"
    }
}

对于每个扩展，我们可以把它设置为 ui 或者 workspace，分别代表在本地/服务器上启用。这样，VSCode 在启动远程模式时会对扩展做出合适的处理。如果还觉得有点糊涂的话，建议回头看看文章开头的架构图。

在远程模式下工作时，几乎所有开发相关的操作都是在远程服务器上完成的。这也包括了终端（Terminal）。你可以尝试在终端输入一些命令，从提示和结果都能发现，这并不是客户端的 Windows Cmd，而是一个真实的 Linux Terminal。另外，我们还会发现 VSCode 会在远程服务器的用户目录下建立一个 .vscode-server 目录，该目录实际上就是一个完整的 VSCode 程序（那个很长的中缀猜想是用来区分不同的session，但是没有具体验证过）。所有在服务端开启的开发扩展也会自动拷贝到相应的子目录下。

如果你希望了解远程模式的一些工作内幕，那么输出面板有一个 Remote-SSH 视图能为你提供一些信息。这个输出显示的内容还是比较有限，但是也能看到启动服务和调用命令的一些细节。此外，输出视图的 Log (Remote Server) 和 Log (Remote Extension Host) 也会显示服务器相关的一些日志记录。

我个人非常希望从源代码级别了解远程开发工作的一些细节，但很可惜，目前微软官方的代码库中只有一些文档和问题模板，并未开放远程开发扩展的源码。其实仔细研究远程开发的一些细节可以认识到，远程开发在很多方面是需要和 VSCode 的核心架构深度绑定的，因此有很大可能，该扩展会在功能逐渐稳定以后合并到 VSCode 的主体代码，不再作为多带带的扩展出现。当然这是我个人的一家之言，不妨姑妄听之。

VSCode 远程开发目前还在预览状态，并且它对 VSCode 内部的一些架构变动也比较大，可能仍然存在不少 bug，对于第三方扩展也可能会有一些兼容性问题。如果你在使用中发现有问题的话，可以到 远程开发 Issue 查找或报告，或者参考官方文档中的 Troubleshooting 以解决一些常见问题。

如果你自己是扩展开发者的话，需要注意的是在远程模式下过去的某些做法可能是会出问题的，特别是一些直接访问本地功能的原生 nodejs 库。微软也列出了容易导致问题的一些常见场景，以及建议的解决方法，请参考阅读：Supporting Remote Development。

按照微软官方的设想，以及一些开发者的使用经验，VSCode 远程开发主要用于跨平台开发、统一开发环境、沙盒模拟等场景。对于一般性个人开发，我的感觉是通过 SSH 管理比本地开发还是反应略慢，失去了流畅的感觉，并且我个人对于上述场景没有特别强烈的要求，因此远程开发对我来说，至少在目前意义并不算大。但需要承认的是，这种方式带来了很大的想象空间，也很有可能在未来会看到其他更加有用的玩法，所以还是一个值得关注的方向。

然而从架构的角度讲，我对这个扩展是有一些担心的。主要的问题在于复杂性。我看到的主要问题包括：

目前 VSCode 的设置层次已经相当复杂了，并且从官方 Issue 可以感受到，由于这种架构分支太多、难于管理，某些问题处理起来应该是比较棘手，甚至微软的开发者也无法给出明确的回答。而远程开发模式还会让这个结构更加复杂，可谓雪上加霜；

对于扩展的本地/远程分类，也给扩展管理带来了额外的复杂性，并且不够直观；

它也给扩展开发者带来了额外的负担，一些过去习以为常的用法在远程模式下可能彻底无法工作了，且需要这些开发者去了解一些琐碎的技术细节。提高扩展开发者的门槛对于 VSCode 繁荣的生态可能是不利的。

从长远来说，远程开发功能是不是独立成一个多带带的产品更好呢？呃——其实我也不知道。

Fundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有阳光保险、核桃编程、荔枝FM、掌门1对1、微脉、青团社等众多品牌企业。欢迎大家免费试用！