在容器中开发
Visual Studio Code Dev Containers 扩展允许你使用容器作为功能齐全的开发环境。它允许你在容器内(或挂载到容器内)打开任何文件夹,并利用 Visual Studio Code 的全部功能集。项目中的 devcontainer.json 文件 告诉 VS Code 如何访问(或创建)一个具有明确工具和运行时堆栈的 开发容器。此容器可用于运行应用程序或分离处理代码库所需的工具、库或运行时。
工作区文件从本地文件系统挂载或复制/克隆到容器中。扩展程序安装并在容器内运行,在那里它们可以完全访问工具、平台和文件系统。这意味着你只需连接到不同的容器,即可无缝切换整个开发环境。

这使得 VS Code 能够提供 本地质量的开发体验,包括完整的 IntelliSense(自动补全)、代码导航和调试,无论你的工具(或代码)位于何处。
Dev Containers 扩展支持两种主要操作模式
- 你可以使用容器作为你的全职开发环境
- 你可以 附加到正在运行的容器 进行检查。
注意:Dev Containers 扩展支持开放的 Dev Containers Specification,它使任何工具中的任何人都能够配置一致的开发环境。你可以在我们的 开发容器常见问题 和规范网站 containers.dev 上了解更多信息。
入门
注意:你可以在入门 Dev Containers 教程 中了解如何快速开始使用开发容器。
系统要求
本地/远程主机
你可以通过以下几种方式将 Docker 与 Dev Containers 扩展配合使用,包括
- 本地安装 Docker。
- 安装在远程环境中的 Docker。
- 安装在本地或远程的其他 Docker 兼容 CLI。
- 虽然其他 CLI 可能有效,但它们并未得到官方支持。请注意,附加到 Kubernetes 集群 只需要正确配置的 kubectl CLI。
你可以在 替代 Docker 选项文档 中了解更多信息。
下面是你可以配置本地或远程主机上的 Docker 的一些具体方法
- Windows: Windows 10 专业版/企业版上的 Docker Desktop 2.0+。Windows 10 家庭版 (2004+) 需要 Docker Desktop 2.3+ 和 WSL 2 后端。(不支持 Docker Toolbox。不支持 Windows 容器镜像。)
- macOS:Docker Desktop 2.0+。
- Linux:Docker CE/EE 18.06+ 和 Docker Compose 1.21+。(不支持 Ubuntu snap 包。)
- 远程主机: 需要 1 GB RAM,但建议至少 2 GB RAM 和 2 核 CPU。
容器:
- x86_64 / ARMv7l (AArch32) / ARMv8l (AArch64) Debian 9+、Ubuntu 16.04+、CentOS / RHEL 7+
- x86_64 Alpine Linux 3.9+
其他基于 glibc 的 Linux 容器如果具有 所需的 Linux 先决条件,也可能工作。
安装
要开始使用,请按照以下步骤操作
-
使用以下路径之一或 替代 Docker 选项(例如远程主机上的 Docker 或 Docker 兼容 CLI)安装和配置适用于你的操作系统的 Docker。
Windows / macOS:
-
如果你在 Windows 上使用 WSL 2,要确保 WSL 2 后端 已启用:右键单击 Docker 任务栏图标并选择 Settings。勾选 Use the WSL 2 based engine 并在 Resources > WSL Integration 下验证你的发行版已启用。
-
如果未使用 WSL 2 后端,右键单击 Docker 任务栏图标,选择 Settings 并使用保存源代码的位置更新 Resources > File Sharing。请参阅 提示和技巧 进行故障排除。
Linux:
-
按照 适用于你的发行版的 Docker CE/EE 官方安装说明 进行操作。如果你使用 Docker Compose,请同时按照 Docker Compose 说明 进行操作。
-
使用终端运行
sudo usermod -aG docker $USER将你的用户添加到docker组 -
注销并重新登录以使更改生效。
-
安装 Dev Containers 扩展。如果你计划在 VS Code 中使用其他远程扩展,你可以选择安装 Remote Development 扩展包。
使用 Git?
这里有两个需要考虑的提示
- 如果你在 Windows 本地和容器内使用同一个存储库,请确保设置一致的行尾。有关详细信息,请参阅 提示和技巧。
- 如果你使用 Git 凭证管理器克隆,你的容器应该已经可以访问你的凭证!如果你使用 SSH 密钥,你也可以选择共享它们。有关详细信息,请参阅 与容器共享 Git 凭证。
选择快速入门
本文档包含 3 个快速入门 - 我们建议从最适合你的工作流程和兴趣的快速入门开始
- 想在快速示例存储库中试用开发容器吗?请查看 快速入门 1:试用开发容器。
- 想将开发容器添加到你现有的本地克隆项目中吗?请查看 快速入门 2:在容器中打开现有文件夹。
- 想使用存储库的隔离副本,例如审阅 PR 或调查分支,而不会影响你的本地工作吗?请查看 快速入门 3:在隔离的容器卷中打开 git 存储库或 PR。
快速入门:试用开发容器
最简单的入门方法是试用一个示例开发容器。 容器教程 将引导你设置 Docker 和 Dev Containers 扩展,并允许你选择一个示例。

注意:如果你已经安装了 VS Code 和 Docker,那么你可以使用 在开发容器中打开。你可以在 创建开发容器指南 中了解有关此功能以及如何将其添加到你的存储库的更多信息。
快速入门:在容器中打开现有文件夹
本快速入门介绍如何使用文件系统上现有的源代码为现有项目设置开发容器,将其用作你的全职开发环境。请按照以下步骤操作
-
启动 VS Code,从命令面板 (F1) 或快速操作状态栏项运行 Dev Containers: Open Folder in Container... 命令,然后选择你想要设置容器的项目文件夹。
提示: 如果你想在打开文件夹之前编辑容器的内容或设置,你可以运行 Dev Containers: Add Dev Container Configuration Files... 命令。

-
现在为你的开发容器选择一个起点。你可以从可筛选列表中选择一个基础 Dev Container Template,或者如果所选文件夹中存在现有的 Dockerfile 或 Docker Compose 文件,则使用它。
注意: 当使用 Alpine Linux 容器时,某些扩展可能无法工作,因为扩展内部的本地代码存在
glibc依赖项。
该列表将根据你打开的文件夹内容自动排序。
你可能可以使用额外的 Features 来自定义你的开发容器,你可以在 下面阅读更多相关信息。
显示的开发容器模板来自我们的 第一方和社区索引,该索引是 Dev Container Specification 的一部分。我们在 devcontainers/templates 存储库 中托管了一组模板作为规范的一部分。你可以浏览该存储库的
src文件夹以查看每个模板的内容。你也可以选择使用 dev container CLI 发布和分发你自己的开发容器模板。
-
选择容器的起点后,VS Code 会将开发容器配置文件添加到你的项目 (
.devcontainer/devcontainer.json)。 -
VS Code 窗口将重新加载并开始构建开发容器。进度通知提供状态更新。你只需在第一次打开时构建开发容器;第一次成功构建后打开文件夹会快得多。

-
构建完成后,VS Code 将自动连接到容器。
现在,你可以像在本地打开项目一样在 VS Code 中与项目进行交互。从现在开始,当你打开项目文件夹时,VS Code 将自动获取并重新使用你的开发容器配置。
提示: 想使用远程 Docker 主机吗?请参阅有关 在容器中打开远程 SSH 主机上的文件夹 的部分以获取信息。
虽然使用此方法将本地文件系统 绑定挂载 到容器中很方便,但它在 Windows 和 macOS 上确实有一些性能开销。你可以应用 一些技术 来提高磁盘性能,或者你可以 改用隔离的容器卷在容器中打开存储库。
在 Windows 上的容器中打开 WSL 2 文件夹
如果你使用 Windows Subsystem for Linux v2 (WSL 2) 并启用了 Docker Desktop 的 WSL 2 后端,你可以在 WSL 内部存储的源代码上工作!
启用 WSL 2 引擎后,你可以选择
- 使用 WSL 扩展打开的文件夹中运行 Dev Containers: Reopen in Container 命令。
- 从命令面板 (F1) 中选择 Dev Containers: Open Folder in Container...,并使用本地
\\wsl$共享(从 Windows 端)选择 WSL 文件夹。
快速入门的其余部分按原样适用!你可以在 WSL 扩展的文档 中了解更多信息。
在容器中打开远程 SSH 主机上的文件夹
如果你使用 Linux 或 macOS SSH 主机,你可以将 Remote - SSH 和 Dev Containers 扩展一起使用。你甚至不需要在本地安装 Docker 客户端。
操作步骤如下:
- 按照 Remote - SSH 扩展的 安装 和 SSH 主机设置 步骤进行操作。
- 可选: 设置 SSH 基于密钥的身份验证到服务器,这样你就不需要多次输入密码。
- 在你的 SSH 主机上 安装 Docker。你不需要在本地安装 Docker。
- 按照 Remote - SSH 扩展的 快速入门 连接到主机并在那里打开文件夹。
- 从命令面板(F1,⇧⌘P (Windows, Linux Ctrl+Shift+P))使用 开发容器:在容器中重新打开 命令。
Dev Containers 快速入门的其余部分按原样适用。你可以在 Remote - SSH 扩展的文档 中了解更多信息。如果此模型不满足你的需求,你还可以参阅 在远程 Docker 主机上开发 文章了解其他选项。
在容器中打开远程隧道主机上的文件夹
你可以将 Remote - Tunnels 和 Dev Containers 扩展一起使用,以在容器内打开远程主机上的文件夹。你甚至不需要在本地安装 Docker 客户端。这与上面的 SSH 主机场景类似,但使用 Remote - Tunnels 代替。
操作步骤如下:
- 按照 Remote - Tunnels 扩展的 入门 说明进行操作。
- 在你的隧道主机上 安装 Docker。你不需要在本地安装 Docker。
- 按照 Remote - Tunnels 扩展的 步骤 连接到隧道主机并在那里打开文件夹。
- 从命令面板(F1,⇧⌘P (Windows, Linux Ctrl+Shift+P))使用 开发容器:在容器中重新打开 命令。
Dev Containers 快速入门的其余部分按原样适用。你可以在 Remote - Tunnels 扩展的文档 中了解更多信息。如果此模型不满足你的需求,你还可以参阅 在远程 Docker 主机上开发 文章了解其他选项。
在容器中打开现有工作区
你也可以按照类似的过程在单个容器中打开 VS Code 多根工作区,前提是工作区只引用相对于 .code-workspace 文件所在文件夹(或文件夹本身)的子文件夹的相对路径。
你可以选择
- 使用 Dev Containers: Open Workspace in Container... 命令。
- 在容器中打开包含
.code-workspace文件的文件夹后,使用 File > Open Workspace...。
连接后,你可能需要将 .devcontainer 文件夹添加到工作区,以便在它尚未可见时轻松编辑其内容。
另请注意,虽然你不能在同一 VS Code 窗口中为同一工作区使用多个容器,但你可以从单独的窗口使用 多个 Docker Compose 管理的容器。
快速入门:在隔离的容器卷中打开 Git 存储库或 GitHub PR
虽然你可以 在容器中打开本地克隆的存储库,但你可能希望使用存储库的隔离副本进行 PR 审阅或调查另一个分支,而不会影响你的工作。
存储库容器使用隔离的本地 Docker 卷,而不是绑定到本地文件系统。除了不会污染你的文件树之外,本地卷还具有提高 Windows 和 macOS 性能的额外好处。(有关如何在其他场景中使用这些类型卷的信息,请参阅高级配置 提高磁盘性能 文章。)
例如,请按照以下步骤在存储库容器中打开其中一个“try”存储库
-
启动 VS Code 并从命令面板 (F1) 运行 Dev Containers: Clone Repository in Container Volume...。
-
在出现的输入框中输入
microsoft/vscode-remote-try-node(或任何其他“try”存储库)、Git URI、GitHub 分支 URL 或 GitHub PR URL,然后按 Enter。
提示: 如果你选择私有存储库,你可能需要设置凭证管理器或将你的 SSH 密钥添加到你的 SSH 代理。请参阅 与容器共享 Git 凭证。
-
如果你的存储库中没有
.devcontainer/devcontainer.json文件,系统会要求你从可筛选列表中选择一个起点,或者选择一个现有的 Dockerfile 或 Docker Compose 文件(如果存在)。注意: 当使用 Alpine Linux 容器时,某些扩展可能无法工作,因为扩展内部的本地代码存在
glibc依赖项。
该列表将根据你打开的文件夹内容自动排序。显示的开发容器模板来自我们的 第一方和社区索引,该索引是 Dev Container Specification 的一部分。我们在 devcontainers/templates 存储库 中托管了一组模板作为规范的一部分。你可以浏览该存储库的
src文件夹以查看每个模板的内容。 -
VS Code 窗口(实例)将重新加载、克隆源代码并开始构建开发容器。进度通知提供状态更新。

如果你在步骤 2 中粘贴了 GitHub 拉取请求 URL,PR 将自动签出,并且 GitHub Pull Requests 扩展将安装在容器中。该扩展提供了额外的 PR 相关功能,例如 PR 浏览器、与 PR 注释的内联交互以及状态栏可见性。

-
构建完成后,VS Code 将自动连接到容器。现在,你可以在这个独立环境中处理存储库源代码,就像你在本地克隆代码一样。
请注意,如果容器因 Docker 构建错误等原因而无法启动,你可以在出现的对话框中选择 Reopen in Recovery Container 进入“恢复容器”,该容器允许你编辑 Dockerfile 或其他内容。这会在一个最小容器中打开带有克隆存储库的 docker 卷,并向你显示创建日志。修复完成后,使用 Reopen in Container 重试。
提示: 想使用远程 Docker 主机吗?请参阅有关 在容器中打开远程 SSH 主机上的文件夹 的部分以获取信息。
信任工作区
Visual Studio Code 非常重视安全性,并希望帮助你安全地浏览和编辑代码,无论来源或原始作者是谁。工作区信任功能 允许你决定项目文件夹是应允许还是限制自动代码执行。
Dev Containers 扩展采用了工作区信任。根据你打开和与源代码交互的方式,系统会在不同时间提示你决定是否信任你正在编辑或执行的代码。
在容器中重新打开文件夹
为现有项目设置开发容器 需要信任本地(或 WSL)文件夹。系统会在窗口重新加载之前要求你信任本地(或 WSL)文件夹。
此流程有几个例外情况
- 单击最近条目时。
- 使用 Open Folder in Container 命令将在窗口重新加载后要求信任(如果尚未给予信任)。
附加到现有容器
当 附加到现有容器 时,系统会要求你确认附加意味着你信任该容器。这只会确认一次。

在卷中克隆存储库
当 在容器卷中克隆存储库 时,系统会要求你确认克隆存储库意味着你信任该存储库。这只会确认一次。

检查卷
远程运行 Docker 守护程序
这意味着信任 运行 Docker 守护程序的机器。没有额外的提示需要确认(只有上面列出的本地/WSL 情况)。
创建 devcontainer.json 文件
VS Code 的容器配置存储在 devcontainer.json 文件中。此文件类似于用于调试配置的 launch.json 文件,但用于启动(或附加到)你的开发容器。你还可以指定容器运行时要安装的任何扩展或用于准备环境的创建后命令。开发容器配置位于 .devcontainer/devcontainer.json 下,或者存储在项目根目录中的 .devcontainer.json 文件中(注意点前缀)。
从命令面板 (F1) 选择 Dev Containers: Add Dev Container Configuration Files... 命令将所需的文件添加到你的项目作为起点,你可以根据需要进一步自定义。该命令允许你从基于文件夹内容的列表中选择预定义的容器配置,重用现有的 Dockerfile,或重用现有的 Docker Compose 文件。

你也可以手动创建 devcontainer.json,并使用任何镜像、Dockerfile 或一组 Docker Compose 文件作为起点。这是一个使用预构建的 开发容器镜像 之一的简单示例
{
"image": "mcr.microsoft.com/devcontainers/typescript-node",
"forwardPorts": [3000],
"customizations": {
// Configure properties specific to VS Code.
"vscode": {
// Add the IDs of extensions you want installed when the container is created.
"extensions": ["streetsidesoftware.code-spell-checker"]
}
}
}
注意: 额外的配置将根据基础镜像中的内容自动添加到容器中。例如,我们在上面添加了
streetsidesoftware.code-spell-checker扩展,容器还将包含"dbaeumer.vscode-eslint",因为 它是mcr.microsoft.com/devcontainers/typescript-node的一部分。使用devcontainer.json预构建时会自动发生这种情况,你可以在 预构建部分 中阅读更多相关信息。
要了解有关创建 devcontainer.json 文件的更多信息,请参阅 创建开发容器。
开发容器特性
开发容器“Features”是自包含、可共享的安装代码单元和开发容器配置。这个名称来源于这样一个想法:引用其中一个 Features 可以让你快速轻松地为你的开发容器添加更多工具、运行时或库“Features”,供你或你的协作者使用。
当你使用 Dev Containers: Add Dev Container Configuration Files 时,系统会向你显示一个脚本列表,用于自定义现有开发容器配置,例如安装 Git 或 Azure CLI

当你重建并在容器中重新打开时,你选择的 Features 将在你的 devcontainer.json 中可用
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {
"version": "latest"
}
}
当你直接编辑 devcontainer.json 中的 "features" 属性时,你将获得 IntelliSense

Dev Containers: Configure Container Features 命令允许你更新现有配置。
VS Code UI 中获取的 Features 现在来自一个中心索引,你也可以向其中贡献。请参阅 Dev Containers 规范网站 获取当前列表,并 了解如何发布和分发 Features。
“始终安装”的 Features
与如何 设置始终安装在开发容器中的扩展 类似,你可以使用 dev.containers.defaultFeatures 用户 设置 来设置你希望始终安装的 Features
"dev.containers.defaultFeatures": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
创建你自己的 Feature
创建和发布你自己的 Dev Container Features 也很容易。已发布的 Features 可以作为 OCI Artifacts 存储和共享,来自任何支持的公共或私有容器注册表。你可以在 containers.dev 上查看当前已发布的 Features 列表。
Feature 是一个自包含的实体,位于一个文件夹中,至少包含 devcontainer-feature.json 和 install.sh 入口脚本
+-- feature
| +-- devcontainer-feature.json
| +-- install.sh
| +-- (other files)
请查看 feature/starter 存储库,了解有关使用 dev container CLI 发布你自己的公共或私有 Features 的说明。
Features 规范和分发
Features 是开源 Development Containers Specification 的关键部分。你可以查看 有关 Features 如何工作的更多信息 及其 分发。
预构建开发容器镜像
我们建议预构建包含所需工具的镜像,而不是每次在开发容器中打开项目时都创建和构建容器镜像。使用预构建镜像将加快容器启动速度、简化配置,并允许你固定到特定版本的工具以提高供应链安全性并避免潜在的中断。你可以使用 DevOps 或持续集成 (CI) 服务(如 GitHub Actions)安排构建来自动预构建镜像。
更好的是 - 预构建镜像可以包含 Dev Container 元数据,因此当你引用镜像时,设置将自动拉取。v
我们建议使用 Dev Container CLI(或 规范 支持的其他实用程序,例如 GitHub Action)来预构建你的镜像,因为它与 Dev Containers 扩展的最新功能(包括 开发容器 Features)保持同步。构建镜像后,你可以将其推送到容器注册表(例如 Azure Container Registry、GitHub Container Registry 或 Docker Hub)并直接引用它。
你可以使用 devcontainers/ci 存储库中的 GitHub Action 来帮助你在工作流中重用开发容器。
有关更多信息,请参阅 dev container CLI 文章中的预构建镜像。
继承元数据
你可以通过 镜像标签 将 Dev Container 配置和 Feature 元数据包含在预构建镜像中。这使得镜像自包含,因为当引用镜像时,这些设置会自动获取——无论是直接引用,在引用的 Dockerfile 中的 FROM 中,还是在 Docker Compose 文件中。这有助于防止你的 Dev Container 配置和镜像内容不同步,并允许你通过简单的镜像引用将同一配置的更新推送到多个存储库。
当你使用 Dev Container CLI(或 规范 支持的其他实用程序,例如 GitHub Action 或 Azure DevOps 任务)预构建时,此元数据标签会自动添加,并包含 devcontainer.json 中的设置以及引用的任何 Dev Container Features。
这允许你拥有一个单独的更复杂的 devcontainer.json 来预构建你的镜像,然后在S一个或多个存储库中拥有一个显著简化的 devcontainer.json。在你创建容器时,镜像的内容将与这个简化的 devcontainer.json 内容合并(请参阅 规范 以了解合并逻辑)。但最简单的方法是直接在 devcontainer.json 中引用镜像,使设置生效
{
"image": "mcr.microsoft.com/devcontainers/go:1"
}
请注意,你也可以选择手动将元数据添加到镜像标签中。即使你没有使用 Dev Container CLI 构建,这些属性也会被获取(即使你使用了 CLI,它也可以更新)。例如,考虑以下 Dockerfile 代码片段
LABEL devcontainer.metadata='[{ \
"capAdd": [ "SYS_PTRACE" ], \
"remoteUser": "devcontainer", \
"postCreateCommand": "yarn install" \
}]'
检查卷
有时你可能会遇到需要检查或更改 Docker 命名卷的情况。你可以使用 VS Code 处理这些内容,而无需创建或修改 devcontainer.json 文件,方法是从命令面板 (F1) 中选择 Dev Containers: Explore a Volume in a Dev Container...。
你还可以在远程资源管理器中检查你的卷。确保在下拉列表中选择了 Containers,然后你会注意到一个 Dev Volumes 部分。你可以右键单击一个卷以检查其创建信息,例如卷何时创建、克隆了哪个存储库以及挂载点。你还可以在开发容器中探索它。

如果你安装了 Container Tools 扩展,你可以在 Container Explorer 的 Volumes 部分中右键单击一个卷,然后选择 Explore in a Development Container。

管理扩展
VS Code 在两个地方运行扩展:本地 UI/客户端,或在容器中。虽然影响 VS Code UI 的扩展(如主题和代码片段)安装在本地,但大多数扩展将驻留在特定容器中。这允许你只安装给定任务所需的扩展到容器中,并通过连接到新容器无缝切换整个工具链。
如果你从 Extensions 视图安装扩展,它将自动安装在正确的位置。你可以根据类别分组判断扩展安装在哪里。将有一个 Local - Installed 类别以及一个用于你的容器的类别。


注意: 如果你是扩展作者,并且你的扩展无法正常工作或安装在错误的位置,请参阅 支持远程开发 以了解详细信息。
实际上需要在远程运行的本地扩展将在 Local - Installed 类别中显示为 Disabled。选择 Install 将扩展安装到远程主机上。

你还可以通过转到 Extensions 视图并使用 Local - Installed 标题栏右侧的云按钮选择 Install Local Extensions in Dev Container: {Name} 来在 Dev Container 中安装所有本地安装的扩展。这将显示一个下拉列表,你可以在其中选择要安装到容器中的本地安装扩展。

但是,某些扩展可能需要你 在容器中安装额外的软件。如果遇到问题,请查阅扩展文档以获取详细信息。
将扩展添加到 devcontainer.json
虽然你可以手动编辑 devcontainer.json 文件以添加扩展 ID 列表,但你也可以右键单击 Extensions 视图中的任何扩展并选择 Add to devcontainer.json。

选择退出扩展
如果基础镜像或 Feature 配置了你不希望安装在开发容器中的扩展,你可以通过列出带有减号的扩展来选择退出。例如
{
"image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
"customizations": {
"vscode": {
"extensions": ["-dbaeumer.vscode-eslint"]
}
}
}
“始终安装”的扩展
如果你希望在任何容器中始终安装某些扩展,你可以更新 dev.containers.defaultExtensions 用户 设置。例如,如果你想安装 GitLens 和 Resource Monitor 扩展,你将按如下方式指定它们的扩展 ID
"dev.containers.defaultExtensions": [
"eamodio.gitlens",
"mutantdino.resourcemonitor"
]
高级:强制扩展在本地或远程运行
扩展通常设计和测试为仅在本地或远程运行,而不是两者都运行。但是,如果扩展支持,你可以在 settings.json 文件中强制它在特定位置运行。
例如,以下设置将强制 Container Tools 扩展在本地运行,以及 Remote - SSH: Editing Configuration Files 扩展在远程运行,而不是使用它们的默认设置:
"remote.extensionKind": {
"ms-azuretools.vscode-containers": [ "ui" ],
"ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}
值 "ui" 而不是 "workspace" 将强制扩展在本地 UI/客户端运行。通常,这只应用于测试,除非扩展文档中另有说明,因为它可能会破坏扩展。有关详细信息,请参阅 首选扩展位置 部分。
转发或发布端口
容器是独立的环境,因此如果你想访问容器内的服务器、服务或其他资源,你需要将端口“转发”或“发布”到你的主机。你可以配置容器始终公开这些端口,或者只临时转发它们。
始终转发端口
你可以使用 devcontainer.json 中的 forwardPorts 属性来指定在附加或打开容器中的文件夹时你始终想要转发的端口列表。
"forwardPorts": [3000, 3001]
只需重新加载/重新打开窗口,当 VS Code 连接到容器时,该设置就会应用。
临时转发端口
如果你需要访问你没有添加到 devcontainer.json 或在 Docker Compose 文件中发布的端口,你可以通过从命令面板 (F1) 运行 Forward a Port 命令来为会话持续时间临时转发新端口。

选择端口后,通知将告诉你用于访问容器中端口的 localhost 端口。例如,如果你转发了侦听端口 3000 的 HTTP 服务器,通知可能会告诉你它已映射到 localhost 上的端口 4123。然后,你可以使用 https://:4123 连接到此远程 HTTP 服务器。
如果你以后需要访问它,Remote Explorer 的 Forwarded Ports 部分中提供了相同的信息。
如果你希望 VS Code 记住你已转发的任何端口,请在 Settings 编辑器中选中 Remote: Restore Forwarded Ports (⌘, (Windows, Linux Ctrl+,)),或在 settings.json 中设置 "remote.restoreForwardedPorts": true。

发布端口
Docker 在创建容器时具有“发布”端口的概念。已发布端口的行为与你提供给本地网络的端口非常相似。如果你的应用程序只接受来自 localhost 的调用,它将拒绝来自已发布端口的连接,就像你的本地机器会拒绝网络调用一样。另一方面,转发端口对应用程序来说看起来就像 localhost。每种情况都可以在不同的情况下有用。
要发布端口,你可以
-
使用 appPort 属性: 如果你在
devcontainer.json中引用镜像或 Dockerfile,你可以使用appPort属性将端口发布到主机。"appPort": [ 3000, "8921:5000" ] -
使用 Docker Compose 端口映射: ports 映射 可以轻松添加到你的
docker-compose.yml文件中以发布额外的端口。ports: - "3000" - "8921:5000"
在每种情况下,你都需要重建容器才能使设置生效。当连接到容器时,你可以通过在命令面板 (F1) 中运行 Dev Containers: Rebuild Container 命令来完成此操作。
打开终端
从 VS Code 在容器中打开终端很简单。在容器中打开文件夹后,你在 VS Code 中打开的任何终端窗口 (Terminal > New Terminal) 都将自动在容器中运行,而不是在本地运行。
你还可以使用此同一终端窗口中的 code 命令行执行多项操作,例如在容器中打开新文件或文件夹。键入 code --help 以了解命令行中可用的选项。

在容器中调试
在容器中打开文件夹后,你可以像在本地运行应用程序时一样使用 VS Code 的调试器。例如,如果你在 launch.json 中选择启动配置并开始调试 (F5),应用程序将在远程主机上启动并附加调试器。
有关在 .vscode/launch.json 中配置 VS Code 调试功能的详细信息,请参阅调试文档。
容器特定设置
当你连接到开发容器时,VS Code 的本地用户设置也会被重用。虽然这使你的用户体验保持一致,但你可能希望在本地机器和每个容器之间更改某些设置。幸运的是,连接到容器后,你还可以通过从命令面板 (F1) 运行 Preferences: Open Remote Settings 命令或在 Settings 编辑器中选择 Remote 选项卡来设置容器特定设置。每当你连接到容器时,这些设置都会覆盖你设置的任何本地设置。

默认容器特定设置
你可以使用 settings 属性在 devcontainer.json 中包含容器特定设置的默认值。创建容器后,这些值将自动放置在容器内的容器特定设置文件中。
例如,将此添加到 .devcontainer/devcontainer.json 将设置 Java 主路径
// Configure tool-specific properties.
"customizations": {
// Configure properties specific to VS Code.
"vscode": {
"settings": {
"java.home": "/docker-java-home"
}
}
}
由于这只是建立默认值,因此你仍然可以在创建容器后根据需要更改设置。
管理容器
默认情况下,当你打开文件夹时,Dev Containers 扩展会自动启动 devcontainer.json 中提到的容器。当你关闭 VS Code 时,扩展会自动关闭你已连接到的容器。你可以通过将 "shutdownAction": "none" 添加到 devcontainer.json 来更改此行为。
虽然你可以使用命令行管理容器,但你也可以使用 Remote Explorer。要停止容器,请从下拉列表中选择 Containers(如果存在),右键单击正在运行的容器,然后选择 Stop Container。你还可以启动已退出的容器、删除容器和删除最近的文件夹。从 Details 视图中,你可以转发端口并在浏览器中打开已转发的端口。

如果你想清理镜像或批量删除容器,请参阅 清理未使用的容器和镜像 以了解不同的选项。
使用 dotfile 存储库进行个性化设置
Dotfiles 是文件名以点 (.) 开头的文件,通常包含各种应用程序的配置信息。由于开发容器可以涵盖广泛的应用程序类型,因此将这些文件存储在某个位置会很有用,这样你就可以在容器启动并运行后轻松地将它们复制到容器中。
一种常见的方法是将这些 dotfiles 存储在 GitHub 存储库中,然后使用实用程序克隆并应用它们。Dev Containers 扩展内置了对将这些文件与你自己的容器一起使用的支持。如果你不熟悉这个概念,请查看存在的不同 dotfiles bootstrap 存储库。
要使用它,请按如下方式将你的 dotfiles GitHub 存储库添加到 VS Code 的用户设置 (⌘, (Windows, Linux Ctrl+,))

或者在 settings.json 中
{
"dotfiles.repository": "your-github-id/your-dotfiles-repo",
"dotfiles.targetPath": "~/dotfiles",
"dotfiles.installCommand": "install.sh"
}
从现在开始,无论何时创建容器,都将使用 dotfiles 存储库。
已知限制
Dev Containers 限制
- 不支持 Windows 容器镜像。
- 多根工作区中的所有根/文件夹都将在同一容器中打开,无论较低级别是否存在配置文件。
- 不支持非官方的 Ubuntu Docker snap 包。请按照 适用于你的发行版的 Docker 官方安装说明 进行操作。
- 不支持 Windows 上的 Docker Toolbox。
- 如果你使用 SSH 克隆 Git 仓库,并且你的 SSH 密钥有密码短语,VS Code 的拉取和同步功能在远程运行时可能会挂起。请使用不带密码短语的 SSH 密钥,使用 HTTPS 克隆,或者从命令行运行
git push来解决此问题。 - 本地代理设置不会在容器内部重用,这可能会阻止扩展工作,除非配置了适当的代理信息(例如带有适当代理信息的全局
HTTP_PROXY或HTTPS_PROXY环境变量)。 - 当 ssh-agent 运行版本 <= 8.8 且 SSH 客户端(在任何平台上)运行版本 >= 8.9 时,Windows 上的 OpenSSH 版本之间存在不兼容性。解决方法是使用 winget 或来自 Win32-OpenSSH/releases 的安装程序将 Windows 上的 OpenSSH 升级到 8.9 或更高版本。(请注意,
ssh-add -l将正常工作,但ssh <ssh-server>将失败并显示<ssh-server>: Permission denied (publickey)。这也影响 Git 在使用 SSH 连接到存储库时。)
请参阅 此处 了解与容器相关的活动问题列表。
Docker 限制
有关更多信息,请参阅适用于 Windows 或 Mac 的 Docker 故障排除指南。
容器工具扩展限制
如果你在 WSL、Remote - Tunnels 或 Remote - SSH 窗口中使用 Container Tools 或 Kubernetes 扩展,使用 Container Explorer 或 Kubernetes 视图中的 Attach Visual Studio Code 上下文菜单操作将要求第二次从可用容器中选择。
扩展限制
此时,大多数扩展都可以在 Dev Containers 内部工作而无需修改。但是,在某些情况下,某些功能可能需要更改。如果你遇到扩展问题,请参阅 此处 了解常见问题和解决方案的摘要,你可以在报告问题时向扩展作者提及这些问题。
此外,虽然 Alpine 支持可用,但容器中安装的某些扩展可能无法工作,因为扩展内部的本机代码存在 glibc 依赖项。有关详细信息,请参阅 使用 Linux 进行远程开发 文章。
高级容器配置
请参阅 高级容器配置 文章,了解有关以下主题的信息
- 添加环境变量
- 添加另一个本地文件挂载
- 更改或删除默认源代码挂载
- 提高容器磁盘性能
- 向开发容器添加非 root 用户
- 设置 Docker Compose 的项目名称
- 在容器内部使用 Docker 或 Kubernetes
- 同时连接到多个容器
- 在远程 Docker Machine 或 SSH 主机上的容器中开发
- 减少 Dockerfile 构建警告
- 与容器共享 git 凭证
devcontainer.json 参考
有一个完整的 devcontainer.json 参考,你可以在其中查看文件模式,以帮助你自定义开发容器并控制如何附加到正在运行的容器。
问题或反馈
- 请参阅 提示和技巧 或 常见问题。
- 在 Stack Overflow 上搜索。
- 添加功能请求或报告问题。
- 创建开发容器模板或特性供他人使用。
- 查看并提供有关 Development Containers Specification 的反馈。
- 为我们的文档或VS Code 本身做出贡献。
- 请参阅我们的贡献指南了解详细信息。
故障排除
无法写入文件 (NoPermissions (FileSystemError))
当你在以下配置中运行开发容器时,你可能会遇到此问题
- Docker Desktop 运行 Windows Subsystem for Linux (WSL) 后端
- 启用了 Enhanced Container Isolation (ECI)
请查看 issue #8278 以获取潜在的解决方法。
后续步骤
- 附加到正在运行的容器 - 附加到已在运行的 Docker 容器。
- 创建开发容器 - 为你的工作环境创建自定义容器。
- 高级容器 - 查找高级容器场景的解决方案。
- devcontainer.json 参考 - 查看
devcontainer.json模式。