在容器内开发
Visual Studio Code Dev Containers 扩展允许您使用容器作为功能齐全的开发环境。它允许您在容器内部(或挂载到容器中)打开任何文件夹,并利用 Visual Studio Code 的全部功能集。项目中的 devcontainer.json 文件会告知 VS Code 如何访问(或创建)具有明确定义的工具和运行时堆栈的开发容器。此容器可用于运行应用程序或分离与代码库一起工作所需的工具、库或运行时。
工作区文件从本地文件系统挂载,或复制或克隆到容器中。扩展在容器内安装和运行,在容器内,它们可以完全访问工具、平台和文件系统。这意味着您只需连接到不同的容器即可无缝切换整个开发环境。
这使 VS Code 能够提供本地质量的开发体验,包括完整的 IntelliSense(补全)、代码导航和调试,无论您的工具(或代码)位于何处。
Dev Containers 扩展支持两种主要操作模式
- 您可以将容器用作您的全职开发环境
- 您可以附加到正在运行的容器以进行检查。
注意:Dev Containers 扩展支持开放的 Dev Containers Specification,该规范使任何工具中的任何人都可以配置一致的开发环境。您可以在我们的 dev container FAQ 和规范网站 containers.dev 中了解更多信息。
入门
注意:您可以在入门级 Dev Containers 教程中学习如何快速启动并运行开发容器。
系统要求
本地/远程主机
您可以通过以下几种方式将 Docker 与 Dev Containers 扩展一起使用,包括
- 本地安装的 Docker。
- 远程环境中安装的 Docker。
- 其他 Docker 兼容的 CLI,本地或远程安装。
- 虽然其他 CLI 可能会工作,但它们未获得官方支持。请注意,附加到 Kubernetes 集群 仅需要正确配置的 kubectl CLI。
您可以在备用 Docker 选项文档中了解更多信息。
以下是一些在本地或远程主机上配置 Docker 的特定方法
- Windows: Windows 10 Pro/Enterprise 上的 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 任务栏项,然后选择设置。选中使用基于 WSL 2 的引擎,并验证您的发行版在资源 > WSL 集成下是否已启用。
-
当不使用 WSL 2 后端时,右键单击 Docker 任务栏项,选择设置,然后使用保留源代码的任何位置更新资源 > 文件共享。有关故障排除,请参阅提示和技巧。
Linux:
-
按照 适用于您的发行版的 Docker CE/EE 官方安装说明进行操作。如果您使用 Docker Compose,也请按照 Docker Compose 指南进行操作。
-
通过使用终端运行以下命令将您的用户添加到
docker
组:sudo usermod -aG docker $USER
-
注销并重新登录,以使更改生效。
-
安装 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...。
-
现在为您的开发容器选择一个起点。您可以从可筛选列表中选择基本开发容器模板,或者使用现有的 Dockerfile 或 Docker Compose 文件(如果在您选择的文件夹中存在)。
注意: 当使用 Alpine Linux 容器时,由于扩展内部本机代码中存在
glibc
依赖项,某些扩展可能无法工作。列表将根据您打开的文件夹的内容自动排序。
您可以使用其他功能自定义您的开发容器,您可以在下面阅读更多相关信息。
显示的开发容器模板来自我们的 第一方和社区索引,它是 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: Reopen in Container 命令。
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: Reopen in Container 命令。
Dev Containers 快速入门的其余部分按原样适用。您可以在其文档中的 Remote - Tunnels 扩展中了解更多信息。如果此模型不能满足您的需求,您还可以查看在远程 Docker 主机上开发文章以了解其他选项。
在容器中打开现有工作区
如果工作区仅引用 .code-workspace
文件所在文件夹(或文件夹本身)的子文件夹的相对路径,您也可以按照类似的过程在单个容器中打开 VS Code 多根工作区。
您可以执行以下操作之一
- 使用 Dev Containers: Open Workspace in Container... 命令。
- 一旦您在容器中打开包含
.code-workspace
文件的文件夹,请使用 文件 > 打开工作区...。
连接后,您可能需要将 .devcontainer
文件夹添加到工作区,以便您可以轻松编辑其内容(如果它尚未可见)。
另请注意,虽然您不能在同一 VS Code 窗口中为同一工作区使用多个容器,但您可以从单独的窗口同时使用多个 Docker Compose 管理的容器。
快速入门:在隔离的容器卷中打开 Git 存储库或 GitHub PR
虽然您可以在容器中打开本地克隆的存储库,但您可能想要使用存储库的隔离副本进行 PR 审查或调查另一个分支,而不会影响您的工作。
存储库容器使用隔离的本地 Docker 卷,而不是绑定到本地文件系统。除了不污染您的文件树之外,本地卷还具有提高 Windows 和 macOS 性能的额外好处。(有关如何在其他场景中使用这些类型的卷的信息,请参阅高级配置提高磁盘性能文章。)
例如,按照以下步骤在存储库容器中打开其中一个“尝试”存储库
-
启动 VS Code 并从命令面板 (F1) 运行 Dev Containers: Clone Repository in Container Volume...。
-
在出现的输入框中输入
microsoft/vscode-remote-try-node
(或其他“尝试”存储库之一)、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
文件的更多信息,请参阅创建开发容器。
开发容器功能
开发容器“功能”是独立的、可共享的安装代码和开发容器配置单元。名称来自这样的想法,即引用其中一个功能可以让您快速轻松地将更多工具、运行时或库“功能”添加到您的开发容器中,供您或您的协作者使用。
当您使用 Dev Containers: Add Dev Container Configuration Files 时,您会看到一个脚本列表,用于自定义现有的开发容器配置,例如安装 Git 或 Azure CLI
当您重建并在容器中重新打开时,您选择的功能将在您的 devcontainer.json
中可用
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {
"version": "latest"
}
}
当您直接编辑 devcontainer.json
中的 "features"
属性时,您将获得 IntelliSense
Dev Containers: Configure Container Features 命令允许您更新现有配置。
VS Code UI 中源自的功能现在来自中央索引,您也可以为此做出贡献。有关当前列表,请参阅 Dev Containers 规范网站,并了解如何发布和分发功能。
“始终安装”功能
类似于您如何在开发容器中设置始终安装的扩展,您可以使用 dev.containers.defaultFeatures 用户设置来设置您始终希望安装的功能
"dev.containers.defaultFeatures": {
"ghcr.io/devcontainers/features/github-cli:1": {}
},
创建您自己的功能
创建和发布您自己的 Dev Container Features 也很容易。已发布的功能可以作为来自任何支持的公共或私有容器注册表的 OCI Artifacts 进行存储和共享。您可以在 containers.dev 上查看当前已发布的功能列表。
功能是文件夹中的一个自包含实体,至少包含一个 devcontainer-feature.json
和 install.sh
入口点脚本
+-- feature
| +-- devcontainer-feature.json
| +-- install.sh
| +-- (other files)
查看 feature/starter 存储库,以获取有关使用 dev container CLI 发布您自己的公共或私有功能的说明。
功能规范和分发
功能是开源 Development Containers Specification 的关键部分。您可以查看有关功能如何工作及其分发的更多信息。
预构建开发容器镜像
我们建议预构建包含您所需工具的镜像,而不是每次在开发容器中打开项目时都创建和构建容器镜像。使用预构建的镜像将加快容器启动速度,简化配置,并允许您固定到特定版本的工具以提高供应链安全性并避免潜在的中断。您可以使用 DevOps 或持续集成 (CI) 服务(如 GitHub Actions)安排构建来自动预构建您的镜像。
更好的是 - 预构建的镜像可以包含 Dev Container 元数据,因此当您引用镜像时,设置将自动拉取过来。
我们建议使用 Dev Container CLI(或其他 规范 支持的实用程序,如 GitHub Action)来预构建您的镜像,因为它与 Dev Containers 扩展的最新功能(包括 dev container 功能)保持同步。构建镜像后,您可以将其推送到容器注册表(如 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
用于预构建镜像,然后在 **一个或多个仓库中拥有一个** 显著简化的 devcontainer.json
。镜像的内容将在创建容器时与这个简化的 devcontainer.json
内容合并(有关合并逻辑的信息,请参阅 规范)。但在最简单的情况下,你只需在 devcontainer.json
中直接引用镜像即可使设置生效。
{
"image": "mcr.microsoft.com/devcontainers/go:1"
}
请注意,你也可以选择手动将元数据添加到镜像标签中。即使你没有使用 Dev Container CLI 构建,这些属性也会被拾取(即使你使用了 CLI,也可以通过 CLI 更新)。例如,考虑以下 Dockerfile 代码片段:
LABEL devcontainer.metadata='[{ \
"capAdd": [ "SYS_PTRACE" ], \
"remoteUser": "devcontainer", \
"postCreateCommand": "yarn install" \
}]'
检查卷
有时你可能会遇到需要检查或更改 Docker 命名卷的情况。你可以使用 VS Code 处理这些内容,而无需创建或修改 devcontainer.json
文件,只需从命令面板 (F1) 中选择 **Dev Containers: 在 Dev Container 中浏览卷...**。
你也可以在远程资源管理器中检查你的卷。确保你在下拉菜单中选择了“Containers”,然后你将注意到一个 **Dev Volumes** 部分。你可以右键单击卷以检查其创建信息,例如卷的创建时间、克隆到其中的仓库以及挂载点。你也可以在开发容器中浏览它。
如果你安装了 Docker 扩展,则可以在 **Docker 资源管理器** 的 **Volumes** 部分中右键单击卷,然后选择 **在开发容器中浏览**。
管理扩展
VS Code 在两个位置之一运行扩展:本地 UI / 客户端侧或容器内。虽然影响 VS Code UI 的扩展(如主题和代码片段)安装在本地,但大多数扩展将驻留在特定的容器内。这允许你仅在容器中安装给定任务所需的扩展,并通过连接到新容器来无缝切换整个工具链。
如果你从扩展视图安装扩展,它将自动安装在正确的位置。你可以根据类别分组来判断扩展的安装位置。将有一个 **本地 - 已安装** 类别,以及一个用于你的容器的类别。
注意: 如果你是扩展作者,并且你的扩展程序无法正常工作或安装在错误的位置,请参阅 支持远程开发 以了解详细信息。
实际上需要在远程运行的本地扩展将在 **本地 - 已安装** 类别中显示为 **已禁用**。选择 **安装** 以在远程主机上安装扩展。
你还可以通过转到扩展视图并使用 **本地 - 已安装** 标题栏右侧的云按钮选择 **在 Dev Container 中安装本地扩展: {Name}**,从而在 Dev Container 内安装所有本地安装的扩展。这将显示一个下拉菜单,你可以在其中选择要在容器中安装的本地安装的扩展。
但是,某些扩展可能需要你在容器中 安装其他软件。如果遇到问题,请查阅扩展文档以获取详细信息。
向 devcontainer.json 添加扩展
虽然你可以手动编辑你的 devcontainer.json 文件以添加扩展 ID 列表,但你也可以在扩展视图中右键单击任何扩展,然后选择 **添加到 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
文件中的特定位置运行。
例如,以下设置将强制 Docker 扩展在本地运行,而 Remote - SSH: 编辑配置文件 扩展在远程运行,而不是使用它们的默认设置。
"remote.extensionKind": {
"ms-azuretools.vscode-docker": [ "ui" ],
"ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}
将值设置为 "ui"
而不是 "workspace"
将强制扩展在本地 UI/客户端侧运行。通常,除非扩展文档中另有说明,否则这应仅用于测试,因为它**可能会破坏扩展**。有关详细信息,请参阅有关 首选扩展位置 的部分。
转发或发布端口
容器是独立的环境,因此如果你想访问容器内的服务器、服务或其他资源,你需要将端口“转发”或“发布”到你的主机。你可以配置你的容器始终公开这些端口,或者只是临时转发它们。
始终转发端口
你可以使用 devcontainer.json
中的 forwardPorts
属性指定在连接或在容器中打开文件夹时始终要转发的端口列表。
"forwardPorts": [3000, 3001]
只需重新加载/重新打开窗口,当 VS Code 连接到容器时,该设置将应用。
临时转发端口
如果你需要访问未添加到 devcontainer.json
或未在 Docker Compose 文件中发布的端口,你可以通过从命令面板 (F1) 运行 **转发端口** 命令来为会话期间临时转发新端口。
选择端口后,通知将告诉你应使用哪个 localhost 端口来访问容器中的端口。例如,如果你转发了在端口 3000 上侦听的 HTTP 服务器,则通知可能会告诉你它已映射到 localhost 上的端口 4123。然后你可以使用 https://127.0.0.1:4123
连接到此远程 HTTP 服务器。
如果你以后需要访问此信息,则可以在远程资源管理器的 **转发端口** 部分中找到相同的信息。
如果你希望 VS Code 记住你转发的任何端口,请在设置编辑器(⌘, (Windows, Linux Ctrl+,)) 中选中 **Remote: Restore Forwarded Ports**,或在 settings.json
中设置 "remote.restoreForwardedPorts": true
。
发布端口
Docker 具有在创建容器时“发布”端口的概念。发布的端口的行为非常类似于你向本地网络提供的端口。如果你的应用程序仅接受来自 localhost 的调用,则它将拒绝来自已发布端口的连接,就像你的本地计算机对网络调用一样。另一方面,转发的端口实际上看起来像应用程序的 localhost。每种端口在不同的情况下都可能有用。
要发布端口,你可以
-
使用 appPort 属性: 如果你在
devcontainer.json
中引用镜像或 Dockerfile,则可以使用appPort
属性将端口发布到主机。"appPort": [ 3000, "8921:5000" ]
-
使用 Docker Compose 端口映射: 可以轻松地将 端口映射 添加到你的
docker-compose.yml
文件中,以发布其他端口。ports: - "3000" - "8921:5000"
在每种情况下,你都需要重建容器才能使设置生效。你可以通过在连接到容器时,从命令面板 (F1) 运行 **Dev Containers: 重建容器** 命令来执行此操作。
打开终端
从 VS Code 在容器中打开终端很简单。在容器中打开文件夹后,你在 VS Code 中打开的任何终端窗口(**终端 > 新终端**)都将自动在容器中而不是本地运行。
你还可以从此终端窗口使用 code
命令行来执行许多操作,例如在容器中打开新文件或文件夹。键入 code --help
以了解命令行中可用的选项。
在容器中调试
在容器中打开文件夹后,你可以像在本地运行应用程序时一样使用 VS Code 的调试器。例如,如果你在 launch.json
中选择启动配置并开始调试 (F5),应用程序将在远程主机上启动并将调试器附加到它。
有关在 .vscode/launch.json
中配置 VS Code 调试功能的详细信息,请参阅 调试 文档。
容器特定设置
当你连接到开发容器时,VS Code 的本地用户设置也会被重用。虽然这保持了你用户体验的一致性,但你可能希望在本地计算机和每个容器之间更改其中一些设置。幸运的是,一旦你连接到容器,你还可以通过从命令面板 (F1) 运行 **Preferences: 打开远程设置** 命令或通过在设置编辑器中选择 **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 时,扩展会自动关闭你已连接到的容器。你可以通过在 devcontainer.json
中添加 "shutdownAction": "none"
来更改此行为。
虽然你可以使用命令行来管理你的容器,但你也可以使用远程资源管理器。要停止容器,请从下拉菜单中选择“Containers”(如果存在),右键单击正在运行的容器,然后选择 **停止容器**。你还可以启动已退出的容器、删除容器和删除最近使用的文件夹。从“详细信息”视图中,你可以转发端口并在浏览器中打开已转发的端口。
如果你想清理镜像或批量删除容器,请参阅 清理未使用的容器和镜像 以了解不同的选项。
使用点文件存储库进行个性化设置
Dotfiles 是文件名以点 (.) 开头的文件,通常包含各种应用程序的配置信息。由于开发容器可以涵盖各种应用程序类型,因此将这些文件存储在某个位置可能很有用,这样你就可以在容器启动并运行后轻松地将它们复制到容器中。
一种常见的方法是将这些 dotfiles 存储在 GitHub 仓库中,然后使用实用程序克隆并应用它们。Dev Containers 扩展内置了对将这些文件与你自己的容器一起使用的支持。如果你不熟悉这个概念,请查看存在的不同 dotfiles 引导仓库。
要使用它,请按如下方式将你的 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 包(用于 Linux)。请遵循 适用于你的发行版的官方 Docker 安装说明。
- 不支持 Windows 上的 Docker Toolbox。
- 如果你使用 SSH 克隆 Git 仓库,并且你的 SSH 密钥有密码,则 VS Code 的拉取和同步功能在远程运行时可能会挂起。可以使用没有密码的 SSH 密钥、使用 HTTPS 克隆或从命令行运行
git push
来解决此问题。 - 本地代理设置不会在容器内重用,这可能会阻止扩展程序工作,除非配置了适当的代理信息(例如,具有适当代理信息的全局
HTTP_PROXY
或HTTPS_PROXY
环境变量)。 - 当 ssh-agent 在 Windows 上以版本 <= 8.8 运行时,而 SSH 客户端(在任何平台上)以版本 >= 8.9 运行时,Windows 上的 OpenSSH 版本之间存在不兼容性。解决方法是将 Windows 上的 OpenSSH 升级到 8.9 或更高版本,可以使用 winget 或来自 Win32-OpenSSH/releases 的安装程序。(请注意,
ssh-add -l
将正常工作,但ssh <ssh-server>
将失败,并显示<ssh-server>: Permission denied (publickey)
。当使用 SSH 连接到仓库时,这也会影响 Git。)
有关与容器相关的活动问题列表,请参阅 此处。
Docker 限制
有关更多信息,请参阅适用于 Windows 或 Mac 的 Docker 故障排除指南,并查阅 Docker 支持资源。
Docker 扩展限制
如果你从 WSL、Remote - Tunnels 或 Remote - SSH 窗口使用 Docker 或 Kubernetes 扩展,则在 Docker 或 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 上搜索。
- 添加 功能请求 或 报告问题。
- 创建一个 Dev Container 模板 或 Feature 供其他人使用。
- 审查并提供有关 Development Containers Specification 的反馈。
- 为 我们的文档 或 VS Code 本身 做出贡献。
- 有关详细信息,请参阅我们的 CONTRIBUTING 指南。
后续步骤
- 连接到正在运行的容器 - 连接到已在运行的 Docker 容器。
- 创建开发容器 - 为你的工作环境创建自定义容器。
- 高级容器 - 查找高级容器场景的解决方案。
- devcontainer.json 参考 - 审查
devcontainer.json
架构。