Docker Sandboxes

编写好 Kit之后，可以把镜像发布到镜像仓库，或者把源码发布到 Git 来共享。发布镜像让别人不必自己构建这个 Kit；共享源码则让他们在创建沙箱时自行构建。无论哪种方式，sbx 都会读取 Kit 的描述符来配置沙箱。

本页介绍如何发布和签名 v3 Kit。要运行别人分享的 Kit，请参阅 使用 Kit。

发布镜像 ​

用 Docker Buildx 构建你的 Kit，并将其发布为 OCI 镜像。把 YAML 描述符传给 -f，把源目录作为构建上下文：

console
$ docker login
$ docker buildx build ./my-kit -f ./my-kit/my-kit.yaml \
    -t docker.io/<NAMESPACE>/my-kit:1.0.0 --push

把 <NAMESPACE> 换成你可以推送的 Docker Hub 命名空间。Buildx 使用你 docker login 的凭据来推送镜像。

在通过镜像仓库引用运行它之前，先推送镜像。sbx 会拉取已发布的镜像。它无法使用只存在于你宿主 Docker 镜像存储中的镜像。开发期间，你可以改为把本地源目录传给 sbx。对于私有镜像，请为你的沙箱配置 镜像仓库凭据。

v3 Kit 请使用 Buildx。sbx kit pack、push 和 pull 命令是给 v1 和 v2 Kit 用的。

同时支持两种 Linux 架构 ​

要把 Kit 分享给使用不同机器的人，为两种受支持的 Linux 架构分别构建：

console
$ docker buildx build ./my-kit -f ./my-kit/my-kit.yaml \
    --platform linux/amd64,linux/arm64 \
    -t docker.io/<NAMESPACE>/my-kit:1.0.0 --push

发布 Kit 集合 ​

用同一条 Buildx 命令发布集合，把它的 YAML 描述符传给 -f。构建过程会拉取 kits: 中列出的已发布镜像，检查它们的声明是否兼容，并把它们各自的文件和设置合并到一个镜像中。完整示例请参阅 编写 Kit 集合。

构建结果是人们可以直接使用的工作负载或 Mixin 镜像。它会记录每个组件的清单 digest，用来标识构建时所用的确切镜像。更新某个组件的标签不会改变已发布的集合。要分享更新，请重新构建集合并发布另一个版本。如果你希望重新构建时使用相同的组件镜像，就在 kits: 中每个 ref 旁边加上 digest。

通过 Git 共享源码 ​

把 Kit 的源目录提交到 Git 仓库，然后按下面的格式分享一个引用。用 dir 选择 Kit 目录，用 ref 选择提交：

text
git+https://github.com/<ORG>/<REPOSITORY>.git#ref=<COMMIT>&dir=my-kit

当有人用该引用创建沙箱时，sbx 会从选中的提交构建这个 Kit。

签名并验证 Kit ​

为你发布的镜像签名，让别人能够验证是谁签的：

console
$ sbx kit sign docker.io/<NAMESPACE>/my-kit:1.0.0
$ sbx kit verify docker.io/<NAMESPACE>/my-kit:1.0.0 \
    --certificate-identity <SIGNER_IDENTITY> \
    --certificate-oidc-issuer <ISSUER_URL>

这些命令使用 Sigstore 签名，与 Cosign 兼容。示例采用无密钥签名，因此验证需要签名者的证书身份和 OpenID Connect 签发者。若改用密钥签名，给 sign 传 --key cosign.key，给 verify 传 --key cosign.pub。

要在使用 Kit 之前要求有效的签名，请参阅 验证 Kit 签名。

以源目录或 Git 引用形式共享的 v3 Kit 无法签名。如果需要签名，请发布并签名 OCI 镜像。

发布格式 ​

已发布的 Kit 镜像同时包含 Kit 的内容和它的描述符。Docker 镜像工具可以检查和分发它，Docker Sandboxes 则在创建沙箱时读取描述符。

你也可以在沙箱内部查看描述符，位置是 /usr/share/sandbox/kit/<stem>/。 镜像注解和文件布局请参阅 已发布镜像格式。

用 sbx 运行工作负载时，会应用其 Kit 描述符中声明的设置和钩子。用 docker run 运行则只使用镜像配置，因此不会应用这些设置和钩子。