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對一、微脈、青團社等衆多品牌企業。歡迎你們免費試用！