devContainer

概述

什么是开发容器？

随着生产工作负载容器化变得越来越普遍，越来越多的开发人员将容器用于部署以外的场景，包括持续集成、测试自动化，甚至全功能的编码环境。

每种场景的需求可能各不相同，从简单的单容器环境到复杂的、协调的多容器设置。开发容器规范（简称 Dev Container Spec）并非试图创建另一种协调器格式，而是寻求找到方法，通过元数据丰富现有格式，以实现常见的开发特定设置、工具和配置。

结构化元数据格式

与之前的语言服务器协议一样，规范中的第一个格式devcontainer.json是出于必要而诞生的。它是一种结构化的带注释的 JSON (jsonc) 元数据格式，工具可以使用它来存储在本地或基于云的容器化编码中进行开发所需的任何配置。

自该规范最初发布以来，开发容器元数据现在可以存储在图像标签和可重复使用的元数据块中，并安装称为开发容器功能的脚本。我们设想，这些相同的结构化数据可以嵌入到其他格式中 - 同时保留一个通用对象模型以实现一致的处理。

开发与生产

开发容器定义了一个环境，您可以在其中开发应用程序，然后才能进行部署。虽然部署容器和开发容器可能彼此相似，但您可能不希望在部署映像中包含在开发期间使用的工具。

容器开发内外循环图

构建和测试

除了可重复的设置之外，这些相同的开发容器还提供一致性，以避免开发人员之间出现特定于环境的问题，并提供集中构建和测试自动化服务。开源CLI 参考实现可以直接使用，也可以集成到产品体验中，以使用结构化元数据来实现这些好处。它目前支持与 Docker Compose 和简化、非编排的单容器选项集成 - 以便它们可以用作编码环境或用于持续集成和测试。

GitHub Action 和 Azure DevOps Task 可在devcontainers/ci中使用，用于在持续集成 (CI) 构建中运行存储库的开发容器。这样，您就可以重复使用用于本地开发的相同设置，在 CI 中构建和测试代码。

支持工具

您可以了解更多有关其他工具和服务如何支持开发容器规范的信息。

开发容器元数据参考

该 devcontainer.json文件包含为给定的明确定义的工具和运行时堆栈配置开发容器所需的所有元数据和设置。支持开发容器规范的工具和服务可以使用它来创建包含一个或多个开发容器的开发环境。

除了 之外，标有 🏷️️ 的元数据属性还可以存储在devcontainer.metadata 容器镜像标签devcontainer.json中。此标签可以包含 JSON 片段数组，这些片段将devcontainer.json在创建容器时自动与内容（如果有）合并。

常规 devcontainer.json 属性

开发容器

](https://containers.dev/)

• 概述

• 参考

• 规格

• 支持工具

• 指南

• 可用功能

• 可用模板

• 收藏

• 规格

• 参考实现

• devcontainer.json 架构

• 开发容器元数据参考

• 特征

• 特征分布

• 模板

• 模板分发

• 贡献

Topics

Specification Reference Implementation devcontainer.json schema Dev Container metadata reference Features Features distribution Templates Templates distribution Contributing

规格

开发容器元数据参考

该devcontainer.json文件包含为给定的明确定义的工具和运行时堆栈配置开发容器所需的所有元数据和设置。支持开发容器规范的工具和服务可以使用它来创建包含一个或多个开发容器的****开发环境。

除了 之外，标有 🏷️️ 的元数据属性还可以存储在devcontainer.metadata 容器镜像标签devcontainer.json中。此标签可以包含 JSON 片段数组，这些片段将devcontainer.json在创建容器时自动与内容（如果有）合并。

常规 devcontainer.json 属性

财产	类型	描述
name	细绳	在 UI 中显示的开发容器的名称。
forwardPorts🏷️	大批	应始终从主容器内部转发到本地计算机（包括 Web 上）的端口号或"host:port"值数组（例如）。此属性最适用于转发无法自动转发的端口，因为相关进程在支持服务/工具连接之前启动，或者在 Docker Compose 场景中转发不在主容器中的服务（例如）。默认为。[3000, "db:5432"]``devcontainer.json``"db:5432"``[]
portsAttributes🏷️	目的	将端口号、"host:port"值、范围或正则表达式映射到一组默认选项的对象。请参阅端口属性以了解可用选项。例如：
"portsAttributes": {"3000": {"label": "Application port"}}
otherPortsAttributes🏷️	目的	未使用 配置的端口、端口范围和主机的默认选项portsAttributes。请参阅端口属性以了解可用选项。例如：
"otherPortsAttributes": {"onAutoForward": "silent"}
containerEnv🏷️	目的	一组名称-值对，用于设置或覆盖容器的环境变量。环境变量和预定义变量可以在值中引用。例如：
"containerEnv": { "MY_VARIABLE": "${localEnv:MY_VARIABLE}" }
如果您想在设置此变量时引用现有容器变量（如更新PATH），请改用remoteEnv。
containerEnv将在 Docker 容器本身上设置变量，因此容器中生成的所有进程都可以访问它。但它在容器的生命周期内也将是静态的 - 您必须重建容器才能更新该值。
我们建议尽可能多地使用containerEnv（而不是remoteEnv），因为它允许所有进程查看变量并且不是特定于客户端的。
remoteEnv🏷️	目的	一组名称-值对，用于设置或覆盖devcontainer.json支持服务/工具（或终端等子进程）的环境变量，但不覆盖整个容器。值中可以引用环境和预定义变量
。如果值不是静态的，您可能需要使用remoteEnv(over containerEnv)，因为您可以更新其值而无需重建整个容器。
remoteUser🏷️	细绳	devcontainer.json覆盖支持服务工具 / 在容器中运行的用户（以及终端、任务或调试等子进程）。不会更改容器整体运行的用户（可以使用 进行设置） containerUser。默认为容器整体运行的用户（通常为root）。
您可以在下面的 remoteUser 部分了解更多信息。
containerUser🏷️	细绳	覆盖容器内所有操作的运行用户。默认为用于创建镜像的相关 Dockerfile 中的root最后一条USER指令。如果您希望任何连接的工具或相关进程使用与容器不同的用户，请参阅remoteUser。
updateRemoteUserUID🏷️	布尔值	在 Linux 上，如果指定了containerUser或remoteUser，则用户的 UID/GID 将更新为与本地用户的 UID/GID 匹配，以避免绑定挂载的权限问题。默认为true。
userEnvProbe🏷️	枚举	devcontainer.json指示用于“探测”要包含在支持服务/工具进程中的用户环境变量的 shell 类型：、、或none（默认）。使用的特定 shell 基于用户的默认 shell（通常为 bash）。例如，bash 交互式 shell 通常包括和中设置的变量，而登录 shell 通常包括和中的变量。将此属性设置为将从所有四个文件中获取变量。interactiveShell``loginShell``loginInteractiveShell``/etc/bash.bashrc``~/.bashrc``/etc/profile``~/.profile``loginInteractiveShell
overrideCommand🏷️	布尔值	告诉devcontainer.json支持服务/工具是否应/bin/sh -c "while sleep 1000; do :; done"在启动容器时运行它们，而不是容器的默认命令（因为如果默认命令失败，容器可能会关闭）。false如果必须运行默认命令才能使容器正常运行，则设置为。true当使用镜像 Dockerfile 和false引用 Docker Compose 文件时，默认为。
shutdownAction🏷️	枚举	指示devcontainer.json支持工具是否应在相关工具窗口关闭时停止容器。
值为 none、stopContainer（图像或 Dockerfile 的默认值）和stopCompose（Docker Compose 的默认值）。
init🏷️	布尔值	默认为false。跨编排器方式指示是否应使用tini init 进程来帮助处理僵尸进程。
privileged🏷️	布尔值	默认为false。跨编排器方式使容器以特权模式运行（--privileged）。对于 Docker-in-Docker 之类的东西是必需的，但存在安全隐患，尤其是在直接在 Linux 上运行时。
capAdd🏷️	大批	默认为[]。跨编排器添加通常对容器禁用的功能的方式。最常用于添加ptrace调试 C++、Go 和 Rust 等语言所需的功能。例如：
"capAdd": ["SYS_PTRACE"]
securityOpt🏷️	大批	默认为[]。跨编排器设置容器安全选项的方式。例如：
"securityOpt": [ "seccomp=unconfined" ]
mounts🏷️	字符串或对象	默认为未设置。跨编排器方式向容器添加其他挂载。每个值都是一个字符串，接受与Docker CLI--mount标志相同的值。值中可以引用环境和预定义变量。例如：
"mounts": [{ "source": "dind-var-lib-docker", "target": "/var/lib/docker", "type": "volume" }]
features	目的	一个包含要添加到主容器中的Dev Container Feature ID和相关选项的对象。可用的具体选项因功能而异，因此请参阅其文档以了解更多详细信息。例如：
"features": { "ghcr.io/devcontainers/features/github-cli": {} }
overrideFeatureInstallOrder	大批	默认情况下，功能将尝试根据每个功能内的属性自动设置安装顺序installsAfter。此属性允许您在需要时覆盖功能安装顺序。例如：
"overrideFeatureInstallОrder": [ "ghcr.io/devcontainers/features/common-utils", "ghcr.io/devcontainers/features/github-cli" ]
customizations🏷️	目的	产品特定属性，在支持工具中定义

场景特定属性

的重点devcontainer.json是描述如何丰富容器以用于开发目的，而不是充当多容器编排器格式。相反，可以在需要管理多个容器及其生命周期时引用容器编排器格式。如今，devcontainer.json包括特定于场景的属性，用于在没有容器编排器的情况下工作（通过直接引用映像或 Dockerfile）以及将 Docker Compose 用作简单的多容器编排器。

图像或 Dockerfile 特定属性

财产	类型	描述
image	细绳	使用映像时必填。支持服务/工具应使用容器注册表（ DockerHub、GitHub 容器注册表、Azure 容器注册表）中的映像名称devcontainer.json来创建开发容器。
build.dockerfile	细绳	使用 Dockerfile 时必需。定义容器内容的Dockerfiledevcontainer.json的位置。路径相对于文件。
build.context	细绳	Docker 构建应相对于 运行的路径devcontainer.json。例如， 的值".."将允许您引用同级目录中的内容。默认为"."。
build.args	目的	一组名称-值对，包含构建 Dockerfile 时应传递的Docker 镜像构建参数。值中可以引用环境和预定义变量。默认为未设置。例如："build": { "args": { "MYARG": "MYVALUE", "MYARGFROMENVVAR": "${localEnv:VARIABLE_NAME}" } }
build.options	大批	构建 Dockerfile 时应传递给 build 命令的Docker 镜像构建选项数组。默认为[]。例如："build": { "options": [ "--add-host=host.docker.internal:host-gateway" ] }
build.target	细绳	指定构建 Dockerfile 时应传递的Docker 映像构建目标的字符串。默认为未设置。例如："build": { "target": "development" }
build.cacheFrom	字符串，
数组	一个字符串或字符串数​​组，用于指定构建映像时要用作缓存的一个或多个映像。缓存映像标识符docker build通过 传递给命令--cache-from。
appPort	整数、
字符串、
数组	在大多数情况下，我们建议使用新的forwardPorts 属性。此属性接受容器运行时应在本地发布的端口或端口数组。与不同forwardPorts，您的应用程序可能需要侦听所有接口（0.0.0.0），而不仅仅是localhost为了在外部可用。默认为[]。在此处
了解有关发布与转发端口的更多信息。请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串与数组属性的更多信息。
workspaceMount	细绳	也需要workspaceFolder设置。创建容器时覆盖工作区的默认本地挂载点。支持与Docker CLI--mount标志相同的值。值中可以引用环境和预定义变量。例如：
"workspaceMount": "source=${localWorkspaceFolder}/sub-folder,target=/workspace,type=bind,consistency=cached", "workspaceFolder": "/workspace"
workspaceFolder	细绳	需要设置。设置支持服务/工具在连接到容器时应打开的workspaceMount默认路径。默认为自动源代码挂载位置。devcontainer.json
runArgs	大批	运行容器时应使用的Docker CLI 参数数组。默认为[]。例如，这允许基于 ptrace 的调试器（如 C++）在容器中工作：
"runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ]。

Docker Compose 特定属性

财产	类型	描述
dockerComposeFile	字符串，
数组	使用Docker Compose时必需。相对于文件的 Docker Compose 文件的路径或路径的有序列表。扩展 Docker Compose 配置时devcontainer.json使用数组很有用。数组的顺序很重要，因为后面的文件的内容可以覆盖前面的文件中设置的值。默认文件从项目的根目录中获取，但您可以在 Docker Compose 文件中使用它来指定备用位置。请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串与数组属性的更多信息。
.env``env_file
service	细绳	使用Docker Compose时必填devcontainer.json。支持服务/工具运行时应连接的服务名称。
runServices	大批	Docker Compose 配置中的一组服务，应由支持服务/工具启动。除非是devcontainer.json，否则断开连接时这些服务也会停止。默认为所有服务。"shutdownAction"``"none"
workspaceFolder	细绳	设置支持服务/工具连接到容器时应打开的默认路径devcontainer.json（通常是可在容器中找到源代码的卷挂载路径）。默认为"/"。

工具特定属性

虽然大多数属性适用于任何devcontainer.json支持工具或服务，但有些属性特定于某些工具。您可以在支持工具和服务文档中探索这一点。

生命周期脚本

创建或使用开发容器时，您可能需要在容器生命周期的不同时间点运行不同的命令。下表列出了一组命令属性，您可以使用它们按运行顺序更新容器的内容（例如，onCreateCommand将在 之后运行initializeCommand）。每个命令属性都是应从 执行的字符串或命令参数列表workspaceFolder。

财产	类型	描述
initializeCommand	字符串、
数组、
对象	在初始化期间（包括容器创建期间和后续启动时）在主机上运行的命令字符串或命令参数列表。该命令可能在给定会话期间运行多次。⚠️

该命令在源代码位于主机上的任何地方运行。对于云服务，这是在云中。

请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。 |
| onCreateCommand🏷️ | 字符串、
数组、
对象 | 此命令是创建开发容器时完成容器设置的三个命令中的第一个（与 和updateContentCommand一起）。它和后续命令在容器首次启动后立即在容器内执行。云服务可以在缓存或预构建容器时使用此命令。这意味着它通常无法访问用户范围的资产或机密。请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。postCreateCommand

|
| updateContentCommand🏷️ | 字符串、
数组、
对象 | 此命令是创建开发容器时完成容器设置的三个命令中的第二个。onCreateCommand在创建过程中，每当源树中有新内容可用时，它都会在容器内执行。

它将至少执行一次，但云服务也会定期执行命令以刷新缓存或预建的容器。与使用 的云服务一样onCreateCommand，它只能利用存储库和组织范围的机密或权限。

请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。 |
| postCreateCommand🏷️ | 字符串、
数组、
对象 | 此命令是创建开发容器时完成容器设置的三个命令中的最后一个。它在updateContentCommand开发容器首次分配给用户之后发生。

云服务可以使用此命令来利用用户特定的机密和权限。

请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。 |
| postStartCommand🏷️ | 字符串、
数组、
对象 | 每次成功启动容器时运行的命令。

请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。 |
| postAttachCommand🏷️ | 字符串、
数组、
对象 | 每次工具成功附加到容器时运行的命令。

请注意，数组语法将在没有 shell 的情况下执行命令。您可以了解有关格式化字符串、数组和对象属性的更多信息。 |
| waitFor🏷️ | 枚举 | 一个枚举，指定任何工具在连接之前应等待的命令。默认为updateContentCommand。这允许您使用onCreateCommand或updateContentCommand执行支持工具连接之前必须发生的步骤devcontainer.json，同时仍使用执行postCreateCommand之后可以在后台发生的步骤。 |

对于每个命令属性，如果值是单个字符串，它将在 中运行/bin/sh。&&在字符串中使用可执行多个命令。例如，"yarn install"或"apt-get update && apt-get install -y curl"。数组语法["yarn", "install"]将直接调用命令（在本例中为yarn），而无需使用 shell。每个命令都会在源代码挂载后触发，因此您也可以从源代码树运行 shell 脚本。例如：bash scripts/install-dev-tools.sh。

如果其中一个生命周期脚本失败，则不会执行任何后续脚本。例如，如果postCreateCommand失败，postStartCommand则将跳过任何后续脚本。

最低主机要求

虽然devcontainer.json不关注硬件或虚拟机配置，但了解容器的最低 RAM、CPU 和存储要求很有用。这些hostRequirements属性允许您执行这些操作。云服务可以使用这些属性自动默认为最佳可用计算选项，而在其他情况下，如果不满足要求，您将收到警告。

财产	类型	描述
hostRequirements.cpus🏷️	整数	表示所需的最小 CPU/虚拟 CPU/核心数。例如："hostRequirements": {"cpus": 2}
hostRequirements.memory🏷️	细绳	表示最低内存要求的字符串，带有tb、gb、mb或kb后缀。例如，"hostRequirements": {"memory": "4gb"}
hostRequirements.storage🏷️	细绳	表示最低存储要求的字符串，带有tb、gb、mb或kb后缀。例如，"hostRequirements": {"storage": "32gb"}

端口属性

portsAttributes和属性otherPortsAttributes允许您为一个或多个手动或自动转发端口映射默认端口选项。以下是可在分配给该属性的配置对象中设置的选项列表。

财产	类型	描述
label🏷️	细绳	端口视图中端口的显示名称。默认为未设置。
protocol🏷️	枚举	控制转发端口的协议处理。如果未设置，则端口被视为原始 TCP 流，如果转发到localhost，则支持任意数量的协议。但是，如果端口转发到 Web URL（例如从 Web 上的云服务），则仅支持容器中的 HTTP 端口。将此属性设置为会https通过忽略在端口上通信时存在的任何 SSL/TLS 证书并使用转发 URL 的正确证书（例如https://*.githubpreview.dev）来改变处理。如果设置为http，则处理与未设置协议时相同。默认为未设置。
onAutoForward🏷️	枚举	控制连接到容器后端口自动转发时应发生的情况。notify是默认值，当端口自动转发时将出现通知。 如果设置为openBrowser，端口将在系统的默认浏览器中打开。 的值openBrowserOnce将仅打开浏览器一次。openPreview将在支持服务/工具的嵌入式预览浏览器中打开 URL devcontainer.json。 的值silent将转发端口，但不采取进一步操作。 的值ignore表示此端口根本不应自动转发。
requireLocalPort🏷️	布尔值	指示何时需要端口转发以将容器中的端口本地映射到同一端口。如果设置为false，devcontainer.json支持服务/工具将尝试使用指定的端口转发到localhost，并在不可用时静默映射到其他端口。如果设置为true，如果无法使用同一端口，您将收到通知。默认为false。
elevateIfNeeded🏷️	布尔值	将低端口（如 22、80 或 443）转发到支持服务/工具localhost的同一端口devcontainer.json可能需要在某些操作系统上提升权限。将此属性设置为true将在此情况下自动尝试提升devcontainer.json支持工具的权限。默认为false。

格式化字符串与数组属性

某些属性的格式将根据 shell 的参与而有所不同。

postCreateCommand、、、postStartCommand均有3 种类型postAttachCommand：initializeCommand

• 数组：传递给操作系统执行，无需经过 shell
• 字符串：经过 shell（需要解析为命令和参数）
• 对象：所有生命周期脚本都已扩展，object以支持允许并行执行的类型

runArgs只有数组类型。runArgs通过典型的命令行使用时，如果 shell 遇到带空格的参数，则需要单引号。但是，这些单引号不会传递给可执行文件。因此，在您的 中devcontainer.json，您将遵循数组格式并省略单引号：

"runArgs": ["--device-cgroup-rule=my rule here"]

而不是：

"runArgs": ["--device-cgroup-rule='my rule here'"]

我们也可以比较的字符串、数组和对象版本postAttachCommand。您可以使用以下字符串格式，它将在 shell 解析过程中删除单引号：

"postAttachCommand": "echo foo='bar'"

相比之下，数组格式将保留单引号并将其写入标准输出（您可以在开发容器日志中看到输出）：

"postAttachCommand": ["echo", "foo='bar'"]

最后，您可以使用对象格式：

{
  "postAttachCommand": {
    "server": "npm start",
    "db": ["mysql", "-u", "root", "-p", "my database"]
  }
}

devcontainer.json 中的变量

devcontainer.json变量可以按照以下格式在某些字符串值中引用： ${variableName}。以下是您可以使用的变量列表。

多变的	特性	描述
${localEnv:VARIABLE_NAME}	任何	主机上环境变量的值（在下面的示例中称为VARIABLE_NAME）。未设置的变量留空。⚠️

客户端（如 VS Code）可能需要重新启动才能获取新设置的变量。⚠️

对于云服务，主机在云端而不是您的本地机器。

示例

**1.**设置一个包含 Linux / macOS 上的本地主文件夹或 Windows 上的用户文件夹的变量：
"remoteEnv": { "LOCAL_USER_PATH": "${localEnv:HOME}${localEnv:USERPROFILE}" }。

当未设置环境变量时，可以使用 给出默认值${localEnv:VARIABLE_NAME:default_value}。2

**.**在现代版本的 macOS 中，默认配置允许使用命令设置局部变量echo 'export VARIABLE_NAME=my-value' >> ~/.zshenv。 |
| ${containerEnv:VARIABLE_NAME} | remoteEnv | 容器启动并运行后，容器内现有环境变量的值（在本例中称为VARIABLE_NAME）。例如：
"remoteEnv": { "PATH": "${containerEnv:PATH}:/some/other/path" }

当未设置环境变量时，可以使用 给出默认值${containerEnv:VARIABLE_NAME:default_value}。 |
| ${localWorkspaceFolder} | 任何 | devcontainer.json在支持服务/工具（包含）中打开的本地文件夹的路径.devcontainer/devcontainer.json。 |
| ${containerWorkspaceFolder} | 任何 | 可以在容器中找到工作区文件的路径。 |
| ${localWorkspaceFolderBasename} | 任何 | 在支持服务/工具中打开的本地文件夹的名称devcontainer.json（包含.devcontainer/devcontainer.json）。 |
| ${containerWorkspaceFolderBasename} | 任何 | 可在容器中找到工作区文件的文件夹的名称。 |
| ${devcontainerId} | 任何 | 允许功能引用其安装到的开发容器所特有的标识符，且该标识符在重建过程中保持稳定。devcontainer.json中支持它的属性
包括：name、、、、、、、、、、、、、、、、、、和。runArgs``initializeCommand``onCreateCommand``updateContentCommand``postCreateCommand``postStartCommand``postAttachCommand``workspaceFolder``workspaceMount``mounts``containerEnv``remoteEnv``containerUser``remoteUser``customizations |

架构

您可以在此处看到开发容器模式。

发布与转发端口

Docker 在创建容器时有“发布”端口的概念。已发布端口的行为与您提供给本地网络的端口非常相似。如果您的应用程序仅接受来自的调用localhost，它将拒绝来自已发布端口的连接，就像您的本地计算机拒绝网络调用一样。另一方面，转发端口实际上看起来像localhost应用程序。

远程用户

开发容器配置remoteUser将从其使用的基础映像继承该属性。

使用规范中的图像和模板remoteUser部分作为示例：在这些图像中设置为自定义值 - 您可以在C++ 图像中查看示例。然后， C++ 模板将从其基本 C++ 图像继承自定义remoteUser值。

规格

开发容器规范

开发容器规范的目的是提供一种方法来丰富容器，使其中的内容和元数据能够在容器内进行开发。这些容器环境应该易于使用、创建和重新创建。

开发容器是用户可以在其中开发应用程序的容器。想要实现此规范的工具应提供一组功能/命令，为用户提供更多灵活性，并允许开发容器扩展到大型开发组。

环境被定义为一个或多个开发容器以及任何所需的边车容器的逻辑实例。环境基于一组可以作为单个单元进行管理的元数据。用户可以从相同的配置元数据创建多个环境****以用于不同的目的。

元数据

开发容器规范允许为用户或开发团队定义可重复的开发环境，其中包括应用程序所需的执行环境。开发容器定义了在准备部署之前开发应用程序的环境。虽然部署和开发容器可能彼此相似，但您可能不想在开发期间使用的部署映像中包含工具，并且可能需要使用不同的机密或其他设置。

此外，在开发容器内工作可能需要额外的元数据来驱动工具或服务体验，而这在生产容器中通常并不需要。为这些元数据提供结构化且一致的形式是本规范的核心部分。

开发容器由定义（例如包含在文件中devcontainer.json）组成，该定义在用户的控制下确定性地创建容器。

devcontainer.json

虽然此元数据的结构至关重要，但在适当的情况下，指出这些数据在磁盘上的表示方式也很重要。虽然可能会随着时间的推移添加其他表示形式，但元数据可以存储在名为devcontainer.jsontoday 的带有注释的 JSON 文件中。使用它的产品应该会在以下一个或多个位置（按优先顺序）找到 devcontainer.json 文件：

• .devcontainer/devcontainer.json
• .devcontainer.json
• .devcontainer/<folder>/devcontainer.json（其中<folder>是子文件夹，深度为一级）

这些文件可能存在于多个位置，因此请考虑提供一种机制，让用户在适当的时候选择一个。

图像元数据

某些开发容器元数据属性可以作为元数据片段数组存储在图像标签中。这样，它们就可以存储在预构建的图像中，这样图像及其相关配置就是独立的。然后，应在创建容器时将这些内容与任何本地 devcontainer.json 文件内容合并。使用数组，以便后续图像构建可以简单地将更改附加到数组，而不是尝试在此时合并 - 这提高了与任意图像构建系统的兼容性。

元数据应具有以下代表性结构，每个开发容器功能使用一个条目devcontainer.json（完整列表见下表）：

[
	{
		"id"?: string,
		"init"?: boolean,
		"privileged"?: boolean,
		"capAdd"?: string[],
		"securityOpt"?: string[],
		"entrypoint"?: string,
		"mounts"?: [],
		...
		"customizations"?: {
			...
		}
	},
	...
]

为了简化为其他工具添加元数据，我们还支持拥有具有相同属性的单个顶级对象。

元数据作为标签添加到图像中，devcontainer.metadata其中的 JSON 字符串值代表上述数组或单个对象。

合并逻辑

为了在运行时将元数据与用户元数据一起应用devcontainer.json，我们使用以下按属性合并的逻辑。该表还指出了当前支持哪些来自devcontainer.json和来自功能元数据的属性 - 随着我们添加更多属性，这将随时间而变化。

财产	类型/格式	合并逻辑	devcontainer.json	devcontainer-feature.json
id	例如，ghcr.io/devcontainers/features/node:1	未匯合。		✓
init	boolean	true如果至少有一个是true，false否则。	✓	✓
privileged	boolean	true如果至少有一个是true，false否则。	✓	✓
capAdd	string[]	所有capAdd无重复数组的并集。	✓	✓
securityOpt	string[]	所有securityOpt无重复数组的并集。	✓	✓
entrypoint	string	收集所有入口点的列表。		✓
mounts	(string | { type, src, dst })[]	收集所有挂载点的列表。冲突：最后一个源获胜。	✓	✓
onCreateCommand	string | string[] | {[key: string]: string | string[]}	收集所有 onCreateCommands 的列表。	✓	✓
updateContentCommand	string | string[] | {[key: string]: string | string[]}	收集所有 updateContentCommands 的列表。	✓	✓
postCreateCommand	string | string[] | {[key: string]: string | string[]}	收集所有 postCreateCommands 的列表。	✓	✓
postStartCommand	string | string[] | {[key: string]: string | string[]}	收集所有 postStartCommands 的列表。	✓	✓
postAttachCommand	string | string[] | {[key: string]: string | string[]}	收集所有 postAttachCommands 的列表。	✓	✓
waitFor	枚举	最后一个值获胜。	✓
customizations	工具特定定制的对象。	合并留给工具去做。	✓	✓
containerUser	string	最后一个值获胜。	✓
remoteUser	string	最后一个值获胜。	✓
userEnvProbe	string（枚举）	最后一个值获胜。	✓
remoteEnv	字符串对象。	对于每个变量，最后一个值获胜。	✓
containerEnv	字符串对象。	对于每个变量，最后一个值获胜。	✓
overrideCommand	boolean	最后一个值获胜。	✓
portsAttributes	端口到属性的映射。	每个端口（而不是每个端口属性），最后一个值获胜。	✓
otherPortsAttributes	端口属性。	最后一个值获胜（不是每个端口属性）。	✓
forwardPorts	(number | string)[]	所有端口的联合（无重复）。最后一个端口获胜（当映射发生变化时）。	✓
shutdownAction	string（枚举）	最后一个值获胜。	✓
updateRemoteUserUID	boolean	最后一个值获胜。	✓
hostRequirements	cpus，，，，memory​storage​gpu	最大值获胜。	✓

字符串值中的变量将在应用值时被替换。当顺序很重要时，将devcontainer.json被视为最后。

笔记

• 将标签作为LABELDockerfile 中的指令传递：
  • Dockerfiles 的大小限制为 1.3MB 左右。每行长度限制为 65k 个字符。
  • 每个功能使用一行应该可以充分利用这些限制。
• 将标签作为命令行参数传递：
  • 标签没有记录大小限制，但当请求标头 > 500kb 时，守护进程会返回错误。
  • 500kb 的限制是共享的，所以我们不能在同一个版本中使用第二个标签来避免它。
  • 如果/当这成为一个问题时，我们可以将元数据作为文件嵌入到图像中（例如，用标签指示它）。

业务流程选项

本规范的核心原则是寻求在适当的情况下用开发容器元数据丰富现有的容器编排器格式，而不是替换它们。因此，元数据模式包括一组可选属性，用于与不同的编排器进行互操作。如今，该规范包括特定于场景的属性，用于在没有容器编排器的情况下工作（通过直接引用映像或 Dockerfile）以及将 Docker Compose 用作简单的多容器编排器。同时，本规范为进一步开发和实施其他编排器机制和文件格式留出了空间。

以下部分描述了现在支持的版本之间的差异。

基于图像

基于图像的配置仅引用可通过命令访问和下载的图像docker pull。这些操作所需的登录名和令牌是特定于执行环境的。唯一需要的参数是image。详细信息在此处。

基于Dockerfile

这些配置定义为使用 Dockerfile 来定义开发容器的起点。与基于图像的配置一样，假设执行命令时 Docker 已经可以访问任何基础图像docker build。在这种情况下，唯一需要的参数是 中对 Dockerfile 的相对引用build.dockerfile。详情请见此处。

有多个属性允许用户控制docker build工作方式：

• build.context
• build.args
• build.target
• build.cacheFrom

基于Docker Compose

Docker Compose 配置使用docker-compose（可能是 Docker Compose V1 或别名 Docker Compose V2）来创建和管理应用程序所需的一组容器。与其他配置一样，此操作所需的任何映像都假定是可访问的。所需参数包括：

• dockerComposeFile：对要使用的 Docker Compose 文件的引用。
• service：声明将用于所有其他操作的主容器。工具也假定使用此参数来连接到****开发容器，尽管它们可以根据用户需要提供连接到其他容器的设施。
• runServices``docker-compose：可选属性，指示配置中应随环境启动或停止的服务集。

值得注意的是，image和dockerfile属性不是必需的，因为 Docker Compose 本身就支持该格式。

其他选择

除了上面解释的配置选项之外，在创建开发容器时还有其他设置适用于方便开发人员的使用。

devcontainer.json可以在参考资料中找到可用元数据属性及其用途的完整列表。但是，我们将在下面更详细地描述关键属性。

特征

开发容器“功能”是安装代码和开发容器配置的独立、可共享单元。这个名字的由来是，引用其中一个功能可以让您快速轻松地将更多工具、运行时或库“功能”添加到开发容器中，供您或您的协作者使用。

它们作为辅助构建步骤应用于容器镜像，并可能影响许多开发容器配置设置。有关更多详细信息，请参阅功能文档。

环境变量

可以在开发容器生命周期的不同时间点设置环境变量。考虑到这一点，开发容器支持两类环境变量：

• 容器：这些变量在容器创建时即为容器的一部分，在其生命周期的所有阶段都可用。此概念是容器固有的，可在容器映像本身中设置，用于containerEnv映像和Dockerfile场景或使用****Docker Composeenv文件中的编排器特定属性。
• 远程：这些变量应由开发容器支持工具在配置其运行时环境时设置。用户可以使用该remoteEnv属性设置这些变量，并且实现工具或服务可以针对特定场景（例如机密）添加自己的变量。这些变量可以在容器的生命周期内发生变化，并在容器ENTRYPOINT启动后添加。

这种分离的原因是它允许使用在镜像构建时不可用的信息，并简化了更新环境以满足项目/存储库特定需求而无需修改镜像。考虑到这一点，重要的是要注意实施工具还应支持元数据参考文档中描述的动态变量语法。

另一个值得注意且重要的环境变量相关属性是**userEnvProbe**。实施工具应使用此属性使用指定类型的 shell“探测”预期的环境变量。但是，它并未指定需要对所有子进程使用这种类型的 shell（考虑到性能影响）。相反，“探测”的环境变量应与实施者在创建容器后注入的任何进程的远程环境变量合并。允许实施者模拟开发人员围绕添加到其配置文件和 rc 文件中的值的预期行为。

坐骑

挂载允许容器访问底层机器、在容器之间共享数据以及在开发容器之间保存信息。

应包含默认安装，以便可从容器内部访问源代码。源代码存储在容器外部，以便可以提取开发人员的即时编辑，或者在容器不再启动的情况下创建新容器。

workingFolder 和 workingMount

可以使用workspaceMount镜像和 Dockerfile 场景的属性或使用 Docker Compose 文件中的内置mounts属性来设置源代码的默认挂载点。此文件夹应指向存储库的根目录（.git文件夹所在的位置），以便源代码控制操作在容器内正常工作。

然后可以workspaceFolder将其设置为容器内应使用的默认文件夹。通常，这是容器中的挂载点，或者是其下的子文件夹。允许使用子文件夹对于 monorepos 尤其重要，因为您需要文件夹.git与源代码控制进行交互，但开发人员通常与整个存储库中的特定子项目进行交互。

请参阅workspaceMount并workspaceFolder参考。

用户

用户控制在容器中执行的应用程序的权限，从而允许开发人员控制它们。该规范考虑了两种类型的用户定义：

• 容器用户：用于在容器内运行的所有操作的用户。此概念是容器固有的。可以在容器映像中设置它，使用映像和dockerfilecontainerUser场景的属性 ，或使用特定于业务流程的属性（如Docker Compose 文件中的属性）。user
• 远程用户：用于在容器内运行生命周期remoteEnv脚本。这也是连接到容器的用户工具和编辑器应该用来运行其进程。此概念并非容器所固有。在所有情况下都使用该属性进行设置，默认为容器用户。

这种分离允许ENTRYPOINT图像以与开发人员不同的权限执行，并允许开发人员切换用户而无需重新创建其容器。

生命周期

开发环境在开发的外循环和内循环使用过程中会经历不同的生命周期事件。

• 配置验证
• 环境创建
• 环境停止
• 环境简历

配置验证

验证配置所需的具体步骤可能因开发容器元数据的保存位置而异。但是，在考虑文件时devcontainer.json，应进行以下验证：

1. 验证是否提供了工作区源文件夹。如果没有提供源文件夹，则由实现工具决定如何处理。
2. 在工作区源文件夹中的上述devcontainer.json位置之一中搜索文件。
3. 如果未devcontainer.json找到，则由实施工具或服务决定如何处理。本规范不规定此行为。
4. 验证元数据（例如devcontainer.json）是否包含所选配置类型所需的所有参数。

环境创建

创建过程经过从用户配置到可供使用的作业环境所需的步骤。

初始化

在此步骤中，执行以下操作：

• 验证对配置指定的容器编排器的访问。
• 执行initializeCommand。

图像创建

环境创建的第一部分是生成开发容器将要使用的最终映像。此步骤依赖于协调器，可以仅包括拉取 Docker 映像、运行 Docker 构建或docker-compose构建。此外，此步骤本身很有用，因为它允许创建可上传并供其他用户使用的中间映像，从而缩短创建时间。鼓励实现此规范的工具允许访问仅执行此步骤的命令。

此步骤执行以下任务：

1. 配置验证
2. 拉取/构建/执行定义的容器编排格式来创建图像。
3. 验证这些操作的结果。

容器创建

创建映像后，将基于该映像和设置创建容器。

此步骤执行以下任务：

1. [可选] 执行任何所需的用户 UID/GID 同步（更多内容见下文）
2. 根据上面指定的属性创建容器。
3. 验证容器是否已成功创建。

请注意，此时应应用容器挂载、环境变量和用户配置。但是，不应应用远程用户和环境变量配置。

UID/GID 同步是 Linux 的一项可选任务（仅限），如果属性updateRemoteUserUID设置为 true 并且指定了containerUser或，则执行该remoteUser任务。在这种情况下，应在创建容器之前进行映像更新，以将指定用户的 UID 和 GID 设置为与当前本地用户的 UID/GID 匹配，以避免绑定挂载出现权限问题。如果实现不使用 Linux 上的绑定挂载，或者使用自动执行此转换的容器引擎，则可以跳过此任务。

容器创建后

在容器创建步骤结束时，主容器内部执行一组命令：

• onCreateCommand和。这组命令在容器首次创建时按顺序执行，具体取决于收到的创建参数。您可以在生命周期脚本文档中了解更多信息updateContentCommand。默认情况下，在报告开发环境创建成功后在后台执行。postCreateCommandpostCreateCommand
• 如果waitFor定义了该属性，则执行将阻塞，直到序列中指定属性之前的所有命令都已执行。此属性默认为updateContentCommand。

远程环境变量和用户配置应该应用于容器中创建的所有进程（包括userEnvProbe）。

实施具体步骤

执行完这些步骤后，任何特定于实现的命令都可以安全执行。具体来说，实现所需的任何支持本规范中其他属性的进程都应在此时启动。这些进程可能与任何非阻塞的后台容器创建命令（由属性决定waitFor）并行发生。

任何面向用户的进程都应该应用远程环境变量和用户配置（包括userEnvProbe）。

例如，在CLI 参考实现中，这是执行的任何内容都会运行的点devcontainer exec。

customizations通常，这也是实现者从开发容器元数据部分应用配置或设置的步骤（例如，VS Code 根据customizations.vscode.extensions属性安装扩展）。这些示例可以在支持工具部分参考中找到。但是，此时应用这些并不是本规范严格要求或强制的。

一旦完成这些最后步骤，实施工具或服务就可以根据其需要连接到环境。

环境停止

此步骤的目的是确保所有容器都根据适当的编排器特定步骤正确停止，以确保不会丢失任何数据。实施工具或服务将决定何时发生此事件。

环境简历

虽然在停止开发容器后保留它并不是严格的要求，但这是最常见的情况。

要从停止状态恢复环境：

1. 重新启动所有相关容器。
2. 遵循适当的具体实施步骤。
3. 另外，在容器中执行postStartCommand和。postAttachCommand

与创建过程一样，远程环境变量和用户配置应应用于容器中创建的所有进程（包括userEnvProbe）。

并行生命周期脚本执行

Dev 容器支持每个生命周期脚本使用单个命令。虽然可以使用 、 等实现多个命令的串行执行;，&&但并行执行值得一流的支持。

所有生命周期脚本都已扩展以支持object类型。的键object将是命令的唯一名称，值将是string或array命令。每个命令必须成功退出，该阶段才被视为成功。

每个条目object将在该生命周期步骤中并行运行。

例子

{
  "postCreateCommand": {
    "server": "npm start",
    "db": ["mysql", "-u", "root", "-p", "my database"]
  }
}

定义

项目工作区文件夹

项目工作区文件夹是实施工具开始搜索devcontainer.json文件的地方。如果磁盘上的目标项目使用 git，则项目工作区文件夹通常是 git 存储库的根目录。

支持工具和服务

本页概述了当前支持开发容器规范的工具和服务，包括格式devcontainer.json。devcontainer.json项目中的文件会告诉支持开发容器规范的工具和服务如何访问（或创建）具有明确定义的工具和运行时堆栈的开发容器。

虽然大多数开发容器属性适用于任何devcontainer.json支持工具或服务，但有些属性特定于某些工具，如下所述。

編輯

Visual Studio 代码

Visual Studio Code 特定属性位于vscode内部customizations。

"customizations": {
		// Configure properties specific to VS Code.
		"vscode": {
			// Set *default* container specific settings.json values on container create.
			"settings": {},
			"extensions": [],
		}
}

财产	类型	描述
extensions	大批	扩展 ID 数组，用于指定在创建容器时应安装在容器内的扩展。默认为[]。
settings	目的	将默认settings.json值添加到容器/机器特定的设置文件中。默认为{}。

请注意，Dev Containers扩展和GitHub Codespaces支持这些 VS Code 属性。

Visual Studio

Visual Studio 在 Visual Studio 2022 17.4 中为使用 CMake 预设的 C++ 项目添加了开发容器支持。它是 Linux 和嵌入式 C++ 开发工作负载的一部分，因此请确保在 VS 安装中选择了它。Visual Studio 会在您工作时管理它使用的开发容器的生命周期，但它会以与其他 Linux 或 WSL 目标类似的方式将它们视为远程目标。

您可以在公告博客文章中了解更多信息。

IntelliJ IDEA

IntelliJ IDEA 具有早期支持开发容器，可以通过 SSH 连接远程运行或使用 Docker 本地运行。

您可以在公告博客文章中了解更多信息。

工具

开发容器 CLI

Dev Container 命令行界面 (CLI) 是 Dev Container Spec 的参考实现。它正在devcontainers/cli存储库中开发。它既可供直接使用，也可供希望支持该规范的工具或服务使用。

CLI 可以获取devcontainer.json并从中创建和配置开发容器。它允许使用 CI 或 DevOps 产品（如 GitHub Actions）预先构建开发容器配置。它可以检测和包含开发容器功能并在容器运行时应用它们，并运行生命周期脚本（如）postCreateCommand，提供比普通docker build和更强大的功能docker run。

VS Code 扩展 CLI

VS Code Dev Containers 扩展包含Dev Container CLI 的变体，该变体增加了使用命令行在 VS Code 中打开开发容器的功能。扩展更新时它也会自动更新。

按cmd/ctrl+ shift+p或F1并选择Dev Containers：Install devcontainer CLI命令来安装它。

雪蝽

Cachix 的**devenv**现在支持自动生成文件。这为您提供了一种更方便、更一致的方式，可以将Nix与任何 Dev Container Spec 支持工具或服务一起.devcontainer.json使用！

有关详细信息，请参阅devenv 文档。

Jetify 开发箱

Jetify （原名 jetpack.io）是一种基于Nix的应用程序部署服务。DevBox提供了一种使用 Nix 生成开发环境的方法。Jetify的 VS Code 扩展允许您在任何支持 Dev Container Spec 的工具或服务中快速利用 DevBox。

按cmd/ctrl+ shift+p或F1并选择生成开发容器文件命令即可开始！

VS Code Dev Containers 扩展

Visual Studio Code Dev Containers 扩展可让您将Docker 容器用作功能齐全的开发环境。它允许您打开容器内（或装载到容器中）的任何文件夹并利用 Visual Studio Code 的完整功能集。Dev Containers文档中有更多信息。

提示：如果在构建并连接到开发容器后对其进行了更改，请务必从命令面板（++或）运行Dev Containers：重建容器以获取所做的任何更改。cmd/ctrlshiftpF1

产品特定属性

Dev Containers 扩展实现了VS Code 属性特定的属性。

产品特定限制

某些属性在 Dev Containers 扩展中可能还存在某些限制。

属性或变量	类型	描述
workspaceMount	细绳	在容器卷中使用克隆存储库时尚不支持。
workspaceFolder	细绳	在容器卷中使用克隆存储库时尚不支持。
${localWorkspaceFolder}	任何	在容器卷中使用克隆存储库时尚不支持。
${localWorkspaceFolderBasename}	任何	在容器卷中使用克隆存储库时尚不支持。

服务

GitHub Codespaces

Codespace是托管在云中的开发环境。Codespace 在 GitHub.com 托管的各种基于 VM 的计算选项上运行，您可以配置从 2 核计算机到 32 核计算机。您可以从浏览器或本地使用 Visual Studio Code 连接到 Codespace。

提示：如果在构建并连接到代码空间后对开发容器进行了更改，请务必从命令面板（++或）运行Codespaces：重建容器以获取所做的任何更改。cmd/ctrlshiftpF1

产品特定属性

GitHub Codespaces 可与越来越多的工具及其devcontainer.json属性（如适用）配合使用。例如，连接 Codespaces Web 编辑器或 VS Code 即可使用VS Code 属性。

repositories如果您的 Codespaces 项目需要其他存储库的额外权限，您可以通过和属性进行配置。您可以在Codespaces 文档permissions中了解更多信息。与其他工具一样，Codespaces 特定属性放置在属性内的命名空间内。codespaces``customizations

"customizations": {
	// Configure properties specific to Codespaces.
	"codespaces": {
		"repositories": {
			"my_org/my_repo": {
				"permissions": {
					"issues": "write"
				}
			}
		}
	}
}

您可以自定义创建代码空间时最初打开的文件：

"customizations": {
	// Configure properties specific to Codespaces.
	"codespaces": {
		"openFiles": [
			"README"
			"src/index.js"
		]
	}
}

这些路径相对于存储库的根目录。它们将按顺序打开，并激活第一个文件。

请注意，目前 Codespaces 从 读取这些属性devcontainer.json，而不是从图像元数据中读取。

产品特定限制

某些属性可能以不同的方式应用于代码空间。

属性或变量	类型	描述
mounts	大批	Codespaces 忽略“绑定”挂载，但 Docker 套接字除外。卷挂载仍被允许。
forwardPorts	大批	Codespaces 尚不支持"host:port"此属性的变化。
portsAttributes	目的	Codespaces 尚不支持"host:port"此属性的变化。
shutdownAction	枚举	不适用于 Codespaces。
${localEnv:VARIABLE_NAME}	任何	对于 Codespaces，主机位于云端而不是您的本地机器。
customizations.codespaces	目的	Codespaces 从 devcontainer.json 而不是图像元数据中读取此属性。
hostRequirements	目的	Codespaces 从 devcontainer.json 而不是图像元数据中读取此属性。

代码沙盒

CodeSandbox提供在 microVM 架构上运行的云开发环境。VM 规格从每个环境 2 个 vCPU + 2 GB RAM（免费套餐）开始，最高可达 16 个 vCPU + 32 GB RAM。

当您将 GitHub 存储库导入 CodeSandbox 时，它将自动为每个分支提供专用环境。借助内存快照，CodeSandbox 可以在两秒内恢复并分支环境。

CodeSandbox 支持多种编辑器，因此您可以使用 CodeSandbox 网络编辑器、VS Code 或 CodeSandbox iOS 应用进行编码。

**提示：**将存储库导入 CodeSandbox 后，您可以使用内置 UI 使用开发容器配置环境。

产品特定属性

CodeSandbox 内置对任何编程语言的支持，并支持基于 Debian 和 Ubuntu 的图像。

CodeSandbox 特有的所有属性都放置在.codesandbox根级别的文件夹中。通常，它将包含一个tasks.json文件，该文件定义了启动时或单击时要运行的命令。

有关这些的更多详细信息可以在 CodeSandbox文档中找到。

产品特定限制

CodeSandbox 使用无根 Podman 而不是 Docker 来运行开发容器。CodeSandbox 还使用devcontainers/cli来管理开发容器。因此，无根 Podman 和 Dev Container CLI 的任何限制都应适用于 CodeSandbox。

以下属性对 CodeSandbox 的应用有所不同。

属性或变量	类型	描述
forwardPorts	大批	CodeSandbox 不需要此属性。开发容器中打开的所有端口都将自动映射到公共 URL。
portsAttributes	目的	CodeSandbox 尚不支持此属性。端口附加到配置的任务.codesandbox/tasks.json并归属于该任务。
otherPortsAttributes	目的	CodeSandbox 尚不支持此属性。
remoteUser	细绳	CodeSandbox 目前忽略此属性并将其覆盖为root。CodeSandbox 使用无根 Podman 来运行容器。从安全角度来看，以非 root 远程用户身份运行与在无根 Podman 中以 root 远程用户身份运行相同。CodeSandbox 计划在未来支持此功能。
shutdownAction	细绳	不适用于 CodeSandbox。
capAdd	大批	CodeSandbox 不支持添加 docker 功能。由于容器以非 root 用户身份运行，因此需要 root 访问权限的功能将不起作用。
features	目的	CodeSandbox 会自动将 docker-cli 添加到容器并连接到主机套接字。docker-in-docker和等功能docker-outside-of-docker的工作方式略有不同。由于 docker-cli 和主机套接字可在容器中访问，因此大多数用例应能按预期工作。
${localEnv:VARIABLE_NAME}	任何	对于 CodeSandbox，主机在云端而不是在本地机器上。
hostRequirements	目的	CodeSandbox 尚不支持此属性。

开发平台

DevPod是一款客户端专用工具，可根据devcontainer.json任何后端创建可重现的开发人员环境。每个开发人员环境都在容器中运行，并通过指定devcontainer.json。通过 DevPod 提供程序，可以在任何后端（例如本地计算机、Kubernetes 集群、任何可访问的远程计算机或云中的 VM）上创建这些环境。

架构

您可以探索VS Code的 dev 容器模式实现。