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 Key

要经过 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 <user>
    IdentityFile C:/Users/<user>/.ssh/id_rsa
复制代码

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

第一次链接到远程服务器时的初始化工做须要消耗一段时间，之后再次打开就会快不少。请耐心等待服务器初始化完成，若是一切正常，你就会看到 VSCode 转变为远程开发模式。

远程开发模式

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

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

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

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

从图中咱们能够看到，远程开发扩展以及一些界面主题是保留在本地 VSCode 的，而用于开发的扩展则在本地被禁用了。多是出于性能的考虑，这些扩展并无自动安装到远程服务器上，要在远端开启这些扩展的话，须要在图中对特定的扩展选择 Install on SSH <server> 命令。对于已经安装到远端的扩展，则会显示提示信息 Extension is enabled on SSH <server> 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

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