編輯

開發容器使用技巧

本文包含了一些關於在不同環境中設定和執行開發容器擴充套件的技巧和竅門。

安裝 Docker 的其他方法

您可以透過以下幾種方式將 Docker 與開發容器擴充套件配合使用，包括：

本地安裝 Docker。
在遠端環境中安裝 Docker。
在本地或遠端安裝其他相容 Docker 的 CLI。
- 雖然其他 CLI 可能有效，但它們並未獲得官方支援。請注意，連線到 Kubernetes 叢集僅需要正確配置的 kubectl CLI。

您可以在備用 Docker 選項文件中瞭解更多資訊。

自定義 AI 聊天回覆

自定義指令允許您描述通用的指導方針或規則，以獲取符合您特定編碼實踐和技術棧的回覆。

您可以使用自定義指令與開發容器配合使用，為 Copilot 提供更多關於您所連線的開發容器型別的資訊（例如安裝了哪些語言或工具鏈）。您可以透過以下幾種方式實現這一點：

直接在您的 devcontainer.json 中新增 "github.copilot.chat.codeGeneration.instructions"
- 我們釋出了開發容器資源（如映象和功能），以使建立和連線開發容器的過程更加簡單，現在我們將自定義指令包含在這些檔案中。
- 此處是 Python 功能中自定義指令的示例。
像在本地一樣使用 copilot-instructions.md 檔案

Windows 版 Docker Desktop 技巧

Windows 版 Docker Desktop 在大多數設定中都能很好地工作，但有一些“陷阱”可能會導致問題。以下是一些避免它們的技巧：

考慮在 Windows 10 (2004+) 上使用新的 Docker WSL 2 後端。 如果您正在使用Docker Desktop 的 WSL 2 後端，您可以使用它開啟 WSL 內部以及本地的資料夾。容器也在 Windows 和 WSL 內部共享，並且這個新引擎不易出現檔案共享問題。詳情請參閱快速入門。
切換出“Windows 上的 Linux 容器 (LCOW)”模式。 儘管預設停用，但最新版本的 Docker 支援Windows 上的 Linux 容器 (LCOW)，它允許您同時使用 Windows 和 Linux 容器。然而，這是一個新功能，因此您可能會遇到問題，並且開發容器擴充套件目前僅支援 Linux 容器。您可以隨時透過右鍵單擊 Docker 工作列圖示並從上下文選單中選擇 Switch to Linux Containers... 來切換出 LCOW 模式。
確保您的防火牆允許 Docker 設定共享驅動器。 Docker 只需要在兩個機器本地 IP 之間進行連線，但某些防火牆軟體可能仍然會阻止任何驅動器共享或所需的埠。有關解決此問題的後續步驟，請參閱這篇 Docker 知識庫文章。

以下是一些適用於舊版 Windows 版 Docker 但現在應該已解決的技巧。如果您由於可能的迴歸而遇到奇怪的行為，這些技巧過去曾解決過問題。

共享驅動器時使用 AD 域帳戶或本地管理員帳戶。不要使用 AAD（基於電子郵件）帳戶。 AAD（基於電子郵件）帳戶存在眾所周知的問題，如 Docker 問題 #132 和問題 #1352 中所述。如果您必須使用 AAD 帳戶，請在您的機器上建立一個單獨的本地管理員帳戶，專門用於共享驅動器。按照此部落格文章中的步驟進行設定。
堅持使用字母數字密碼以避免驅動器共享問題。 當被要求在 Windows 上共享您的驅動器時，系統會提示您輸入具有機器管理員許可權的帳戶的使用者名稱和密碼。如果系統警告您使用者名稱或密碼不正確，這可能是由於密碼中包含特殊字元。例如，!、[ 和 ] 已知會導致問題。將密碼更改為字母數字字元即可解決。有關詳細資訊，請參閱此關於Docker 卷掛載問題的議題。
使用您的 Docker ID 登入 Docker（而不是您的電子郵件）。 Docker CLI 僅支援使用您的 Docker ID，因此使用您的電子郵件可能會導致問題。詳情請參閱 Docker 問題 #935。

如果您仍然遇到問題，請參閱Windows 版 Docker Desktop 故障排除指南。

僅當您的程式碼位於與 Docker 共享的資料夾或驅動器中時，VS Code 開發容器擴展才能自動將您的原始碼掛載到容器中。如果您從非共享位置開啟開發容器，容器將成功啟動，但工作區將為空。

請注意，使用Docker Desktop 的 WSL 2 引擎時，此步驟不是必需的。

要更改 Docker 的驅動器和資料夾共享設定：

Windows

右鍵單擊 Docker 工作列圖示，然後選擇 Settings。
轉到 Resources > File Sharing，然後選中您的原始碼所在的驅動器。
如果您看到關於本地防火牆阻止共享操作的訊息，請參閱這篇 Docker KB 文章瞭解後續步驟。

macOS

單擊 Docker 選單欄圖示，然後選擇 Preferences。
轉到 Resources > File Sharing。確認包含您的原始碼的資料夾位於列出的共享資料夾之一中。

解決容器中 Git 行尾符問題（導致許多檔案被修改）

由於 Windows 和 Linux 使用不同的預設行尾符，Git 可能會報告大量除了行尾符之外沒有其他差異的修改檔案。為了防止這種情況發生，您可以使用 .gitattributes 檔案或在 Windows 端全域性停用行尾符轉換。

通常，在您的倉庫中新增或修改 .gitattributes 檔案是解決此問題最可靠的方法。將此檔案提交到原始碼管理將有助於其他人，並允許您根據需要更改倉庫行為。例如，將以下內容新增到倉庫根目錄的 .gitattributes 檔案中，將強制所有內容為 LF，除了需要 CRLF 的 Windows 批處理檔案：

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

請注意，這適用於 Git v2.10+，因此如果您遇到問題，請確保您已安裝最新的 Git 客戶端。您可以將倉庫中需要 CRLF 的其他檔案型別新增到此同一檔案中。

如果您仍然希望始終上傳 Unix 風格的行尾符 (LF)，可以使用 input 選項。

git config --global core.autocrlf input

如果您希望完全停用行尾符轉換，請執行以下命令：

git config --global core.autocrlf false

最後，您可能需要再次克隆倉庫才能使這些設定生效。

使用 Docker Compose 時避免在容器中設定 Git

有關解決此問題的資訊，請參閱主容器文章中的與容器共享 Git 憑據。

解決從容器執行 Git push 或 sync 時掛起的問題

如果您使用 SSH 克隆 Git 倉庫，並且您的 SSH 金鑰有密碼，則當遠端執行時，VS Code 的 pull 和 sync 功能可能會掛起。

使用沒有密碼的 SSH 金鑰，使用 HTTPS 克隆，或者從命令列執行 git push 以解決此問題。

解決缺少 Linux 依賴項的錯誤

某些擴充套件依賴於某些 Docker 映象中找不到的庫。請參閱容器文章，瞭解解決此問題的幾種方法。

加快 Docker Desktop 中容器的速度

預設情況下，Docker Desktop 只為容器提供機器容量的一小部分。在大多數情況下，這已經足夠了，但如果您正在做一些需要更多容量的事情，您可以增加記憶體、CPU 或磁碟使用量。

首先，嘗試停止所有不再使用的正在執行的容器。

如果這不能解決您的問題，您可能需要檢視 CPU 使用率是否確實是問題所在，或者是否有其他情況發生。一個簡單的檢查方法是安裝資源監視器擴充套件。在容器中安裝後，它會在狀態列中提供有關容器容量的資訊。

Resource use Status bar

如果您希望始終安裝此擴充套件，請將其新增到您的 settings.json 中：

"dev.containers.defaultExtensions": [
    "mutantdino.resourcemonitor"
]

如果您確定需要為容器提供更多機器容量，請按照以下步驟操作：

右鍵單擊 Docker 工作列圖示，然後選擇 Settings / Preferences。
轉到 Advanced 以增加 CPU、記憶體或交換空間。
在 macOS 上，轉到 Disk 以增加 Docker 允許在您的機器上消耗的磁碟空間量。在 Windows 上，這位於 Advanced 下，與其他設定在一起。

最後，如果您的容器正在執行磁碟密集型操作，或者您只是希望獲得更快的響應時間，請參閱提高容器磁碟效能以獲取技巧。VS Code 的預設設定旨在方便和普遍支援，但可以進行最佳化。

清理未使用的容器和映象

如果您看到 Docker 報告磁碟空間不足的錯誤，通常可以透過清理未使用的容器和映象來解決。有幾種方法可以做到這一點：

選項 1：使用遠端資源管理器

您可以透過選擇遠端資源管理器，右鍵單擊要刪除的容器，然後選擇刪除容器來刪除容器。

Remote Explorer screenshot

但是，這不會清理您可能已下載的任何映象，這會使您的系統變得混亂。

選項 2：使用容器工具擴充套件

在 VS Code 中開啟一個本地視窗（檔案 > 新視窗）。
如果尚未安裝，請從擴充套件檢視中安裝容器工具擴充套件。
然後，您可以轉到容器資源管理器並展開容器或映象節點，右鍵單擊並選擇刪除容器/映象。

選項 3：使用 Docker CLI 選擇要刪除的容器

開啟一個本地終端/命令提示符（或在 VS Code 中使用本地視窗）。
鍵入 docker ps -a 以檢視所有容器的列表。
從列表中鍵入 docker rm <Container ID> 以刪除容器。
鍵入 docker image prune 以刪除所有未使用的映象。

如果 docker ps 未提供足夠的資訊來識別要刪除的容器，以下命令將列出 VS Code 管理的所有開發容器以及用於生成它們的資料夾。

docker ps -a --filter="label=vsch.quality" --format "table {{.ID}}\t{{.Status}}\t{{.Image}}\tvscode-{{.Label \"vsch.quality\"}}\t{{.Label \"vsch.local.folder\"}}"

選項 4：使用 Docker Compose

開啟一個本地終端/命令提示符（或在 VS Code 中使用本地視窗）。
轉到包含 docker-compose.yml 檔案的目錄。
鍵入 docker-compose down 以停止並刪除容器。如果您有多個 Docker Compose 檔案，可以使用 -f 引數指定其他 Docker Compose 檔案。

選項 4：刪除所有未執行的容器和映象

開啟一個本地終端/命令提示符（或在 VS Code 中使用本地視窗）。
鍵入 docker system prune --all。

解決使用 Debian 8 的映象的 Dockerfile 構建失敗問題

在構建使用基於 Debian 8/Jessie 的映象的容器時（例如舊版本的 node:8 映象），您可能會遇到以下錯誤：

...
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
...

這是一個眾所周知的問題，由 Debian 8 被“歸檔”引起。更新版本的映象通常會解決此問題，通常透過升級到 Debian 9/Stretch。

有兩種方法可以解決此錯誤：

選項 1：刪除依賴於該映象的任何容器，刪除該映象，然後嘗試再次構建。這應該會下載一個不受此問題影響的更新映象。有關詳細資訊，請參閱清理未使用的容器和映象。

選項 2：如果您不想刪除容器或映象，請在任何 apt 或 apt-get 命令之前將此行新增到 Dockerfile 中。它添加了 Jessie 所需的源列表：

# Add archived sources to source list if base image uses Debian 8 / Jessie
RUN cat /etc/*-release | grep -q jessie && printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list

Docker CLI 僅支援使用您的 Docker ID，因此使用您的電子郵件登入可能會導致問題。詳情請參閱 Docker 問題 #935。

作為一種解決方法，請使用您的 Docker ID 而不是您的電子郵件登入 Docker。

macOS 上 Hyperkit 的高 CPU 利用率

Docker for Mac 存在一個已知問題，可能導致 CPU 飆升。特別是，在監視檔案和構建時會出現高 CPU 使用率。如果您在活動監視器中看到 com.docker.hyperkit 的 CPU 使用率很高，而您的開發容器中幾乎沒有活動，您很可能遇到了這個問題。請關注Docker 問題以獲取更新和修復。

使用 SSH 隧道連線到遠端 Docker 主機

在遠端 Docker Machine 或 SSH 主機上的容器中開發文章介紹了在遠端 Docker 主機上工作時如何設定 VS Code。這通常就像將容器工具擴充套件 containers.environment 屬性在 settings.json 中或 DOCKER_HOST 環境變數設定為 ssh:// 或 tcp:// URI 一樣簡單。

但是，您可能會遇到由於 SSH 配置複雜性或其他限制導致此方法在您的環境中不起作用的情況。在這種情況下，SSH 隧道可以用作備用方案。

使用 SSH 隧道作為備用選項

您可以設定 SSH 隧道並將 Docker 套接字從遠端主機轉發到本地機器。

請按照以下步驟操作：

安裝支援 OpenSSH 的 SSH 客戶端。
如下更新您的使用者或工作區 settings.json 中的容器工具擴充套件 containers.environment 屬性：
```
"containers.environment": {
    "DOCKER_HOST": "tcp://:23750"
}
```
從本地終端/PowerShell 執行以下命令（將 user@hostname 替換為遠端使用者和您的伺服器主機名/IP）：
```
ssh -NL localhost:23750:/var/run/docker.sock user@hostname
```

VS Code 現在將能夠連線到遠端主機上任何正在執行的容器。您還可以使用專門的本地 devcontainer.json 檔案來建立/連線到遠端開發容器。

完成後，在終端/PowerShell 中按 Ctrl+C 以關閉隧道。

注意：如果 ssh 命令失敗，您可能需要在 SSH 主機上 AllowStreamLocalForwarding。

在 SSH 主機（而不是本地）上使用編輯器（如 Vim、nano 或 Pico）開啟 /etc/ssh/sshd_config。

新增設定 AllowStreamLocalForwarding yes。

重啟 SSH 伺服器（在 Ubuntu 上，執行 sudo systemctl restart sshd）。

重試。

持久化使用者配置檔案

您可以使用 mounts 屬性來持久化使用者配置檔案（以保留 shell 歷史記錄等內容），使其在開發容器重建後仍然存在。

    "mounts": [
        "source=profile,target=/root,type=volume",
        "target=/root/.vscode-server,type=volume"
    ],

上面的程式碼首先建立一個名為 profile 的命名卷，掛載到 /root，它將在重建後倖存。接下來，它建立一個匿名卷，掛載到 /root/.vscode-server，該卷在重建時被銷燬，這允許 VS Code 重新安裝擴充套件和點檔案。

高階容器配置技巧

有關以下主題的資訊，請參閱高階容器配置文章：

擴充套件提示

雖然許多擴充套件可以在未經修改的情況下工作，但有一些問題可能會阻止某些功能按預期工作。在某些情況下，您可以使用其他命令來解決問題，而在其他情況下，擴充套件可能需要修改。遠端擴充套件提示部分提供了常見問題和解決技巧的快速參考。您還可以參考主擴充套件文章支援遠端開發，獲取關於修改擴充套件以支援遠端擴充套件主機的深入指南。

問題和反饋

報告問題

如果您在使用開發容器擴充套件時遇到問題，收集正確的日誌非常重要，這樣我們才能幫助您診斷您的問題。您可以使用 Dev Containers: Show Container Log 獲取開發容器擴充套件日誌。

如果您在使用其他擴充套件遠端時遇到問題（例如，其他擴充套件在遠端環境中無法正常載入或安裝），從遠端擴充套件主機輸出通道（輸出：聚焦於輸出檢視）獲取日誌，並從下拉列表中選擇日誌（遠端擴充套件主機）會很有幫助。

注意：如果您只看到日誌（擴充套件主機），這是本地擴充套件主機，遠端擴充套件主機未啟動。這是因為日誌通道僅在建立日誌檔案後才建立，因此如果遠端擴充套件主機未啟動，則未建立遠端擴充套件主機日誌檔案，也不會顯示在輸出檢視中。這仍然是包含在您的問題中的有用資訊。

遠端問題和反饋資源

我們還有各種其他遠端資源：

在 Stack Overflow 上搜索。
新增功能請求或報告問題。

09/11/2025