摘要： 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、微脈、青團社等眾多品牌企業。歡迎大家免費試用！