containerd/stargz-snapshotter
GitHub: containerd/stargz-snapshotter
Stargz Snapshotter 是 containerd 的快照插件，通过 eStargz 镜像格式实现延迟拉取，让容器无需等待镜像完整下载即可按需启动，大幅缩短容器启动时间。
Stars: 1569 | Forks: 155
[[⬇️ **下载**]](https://github.com/containerd/stargz-snapshotter/releases)
[[📔**浏览镜像**]](./docs/pre-converted-images.md)
[[☸**快速开始**]](#quick-start-with-kubernetes)
[[🤓**快速开始**]](https://github.com/containerd/nerdctl/blob/master/docs/stargz.md)
[[🔆**安装**]](./docs/INSTALL.md)
# Stargz Snapshotter
[](https://github.com/containerd/stargz-snapshotter/actions?query=workflow%3ATests+branch%3Amain)
[](https://github.com/containerd/stargz-snapshotter/actions?query=workflow%3ABenchmark+branch%3Amain)
[](https://github.com/containerd/stargz-snapshotter/actions?query=workflow%3ANightly+branch%3Amain)
另请阅读介绍博客：[在 Containerd 上通过延迟镜像分发实现闪电般启动容器](https://medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361)
拉取镜像是容器生命周期中比较耗时的步骤之一。
研究表明，拉取操作所花费的时间占容器启动时间的 76%[[FAST '16]](https://www.usenix.org/node/194431)。
*Stargz Snapshotter* 是 snapshotter 的一种实现，旨在通过*延迟拉取*来解决此问题。
这里的*延迟拉取*是指容器无需等待镜像拉取完成即可运行，并且会*按需*获取镜像所需的 chunks。
[*eStargz*](/docs/stargz-estargz.md) 是本项目提出的一种支持延迟拉取的镜像格式。
它兼容 [OCI](https://github.com/opencontainers/image-spec/)/[Docker](https://github.com/moby/moby/blob/master/image/spec/v1.2.md) 镜像，因此可以推送到标准的容器镜像仓库（例如 ghcr.io），并且即使在包括 Docker 在内的不支持 eStargz 的 runtime 上也*仍然可以运行*。
eStargz 格式基于 [CRFS 的 stargz 镜像格式](https://github.com/google/crfs)，但具有 runtime 优化和内容校验等附加功能。
下面的直方图是在 GitHub Actions 上使用 GitHub Container Registry 测量的几个容器启动时间的性能测试结果。
`legacy` 展示了当我们使用 containerd 的默认 snapshotter（`overlayfs`）以及从 `docker.io/library` 复制且未经过优化的镜像时的启动性能。
对于此配置，containerd 会拉取整个镜像内容，`pull` 操作也会相应地消耗时间。
当我们使用带有 eStargz 转换镜像但未进行任何优化的 stargz snapshotter（`estargz-noopt`）时，我们看到 `pull` 操作的性能有所提升，因为 containerd 可以在容器启动时无需等待 `pull` 完成，并按需获取镜像必要的 chunks。
但同时，我们看到 `run` 操作出现了性能下降，因为每次访问文件都需要额外花费时间从 registry 获取它们。
当我们使用[优化后的 eStargz](/docs/ctr-remote.md)（`estargz`）时，我们可以缓解在 `estargz-noopt` 镜像中观察到的性能下降。
这是因为 [stargz snapshotter 在运行容器期间会预取并缓存*可能被访问的文件*](/docs/stargz-estargz.md)。
在首次创建容器时，stargz snapshotter 会等待预取完成，因此 `create` 有时会比其他类型的镜像花费更长的时间。
但这仍然比等待下载所有层的所有文件要快。
上面的直方图是[在 `ecdb227` 提交上的性能测试结果](https://github.com/containerd/stargz-snapshotter/actions/runs/398606060)。
我们会不断测量此 snapshotter 的性能，因此您可以通过本文档顶部显示的徽章获取最新结果。
请注意，由于互联网上的网络状况以及 GitHub Actions 中实例的位置等因素，我们有时会看到结果存在差异。
我们的性能测试方法基于 [HelloBench](https://github.com/Tintri/hello-bench)。
:nerd_face: 您也可以使用延迟拉取在 IPFS 上运行容器。这是一项实验性功能。有关更多详细信息，请参阅 [`./docs/ipfs.md`](./docs/ipfs.md)。
Stargz Snapshotter 是 containerd 的一个**非核心**子项目。
## 快速开始
- 有关 stargz snapshotter 插件及其配置的更多详细信息，请参阅 [Containerd Stargz Snapshotter 插件概述](/docs/overview.md)。
- 有关使用 containerd、CRI-O、Podman、systemd 等设置 eStargz 延迟拉取的更多详细信息，请参阅[安装 Stargz Snapshotter 和 Stargz Store](./docs/INSTALL.md)。
- 有关 eStargz 与社区工具集成状态的更多详细信息，请参阅 [eStargz 与其他工具的集成](./docs/integration.md)
要在 kubernetes 节点上使用 stargz snapshotter，您需要对 containerd 进行以下配置，并在节点上运行 stargz snapshotter daemon。
我们假设您使用 containerd（> v1.4.2）作为 CRI runtime。
```
version = 2
# 将 stargz snapshotter 插入到 containerd 中
# Containerd 通过指定的 socket 地址识别 stargz snapshotter。
# 下面指定的地址是 stargz snapshotter 监听的默认地址。
[proxy_plugins]
[proxy_plugins.stargz]
type = "snapshot"
address = "/run/containerd-stargz-grpc/containerd-stargz-grpc.sock"
[proxy_plugins.stargz.exports]
root = "/var/lib/containerd-stargz-grpc/"
# 通过 CRI 使用 stargz snapshotter
[plugins."io.containerd.grpc.v1.cri".containerd]
snapshotter = "stargz"
disable_snapshot_annotations = false
```
您可以尝试我们[预构建的](/Dockerfile) [KinD](https://github.com/kubernetes-sigs/kind) 节点镜像，其中包含上述配置。
```
$ kind create cluster --name stargz-demo --image ghcr.io/containerd/stargz-snapshotter:0.12.1-kind
```
:information_source: 对于 `ghcr.io/containerd/stargz-snapshotter:0.12.1-kind`，建议使用 kind 二进制文件 v0.16.x 或更高版本。
:information_source: 您可以从 [`ghcr.io/containerd/stargz-snapshotter:${VERSION}-kind`](https://github.com/orgs/containerd/packages/container/package/stargz-snapshotter) 命名空间获取最新的节点镜像。
然后您可以在集群上创建 eStargz pod。
在此示例中，我们创建一个转换过的 stargz Node.js pod（`ghcr.io/stargz-containers/node:17.8.0-esgz`）作为演示。
```
apiVersion: v1
kind: Pod
metadata:
name: nodejs
spec:
containers:
- name: nodejs-stargz
image: ghcr.io/stargz-containers/node:17.8.0-esgz
command: ["node"]
args:
- -e
- var http = require('http');
http.createServer(function(req, res) {
res.writeHead(200);
res.end('Hello World!\n');
}).listen(80);
ports:
- containerPort: 80
```
以下命令从 GitHub Container Registry 延迟拉取 `ghcr.io/stargz-containers/node:17.8.0-esgz` 并创建 pod，因此所花费的时间比原始镜像 `library/node:13.13` 更短。
```
$ kubectl --context kind-stargz-demo apply -f stargz-pod.yaml && kubectl --context kind-stargz-demo get po nodejs -w
$ kubectl --context kind-stargz-demo port-forward nodejs 8080:80 &
$ curl 127.0.0.1:8080
Hello World!
```
Stargz snapshotter 还支持[更多配置](/docs/overview.md)，包括私有 registry 身份验证、镜像仓库等。
## 获取 eStargz 镜像
- 有关镜像转换器 `ctr-remote` 的更多示例和详细信息，请参阅[使用 `ctr-remote image optimize` 优化镜像](/docs/ctr-remote.md)。
- 有关 eStargz 格式的更多详细信息，请参阅 [eStargz：用于延迟拉取容器镜像的 Tar.gz 层的标准兼容扩展](/docs/stargz-estargz.md)
要实现延迟拉取镜像，您首先需要准备 eStargz 镜像。
有几种方法可以实现这一目标。
本节介绍其中的一些方法。
### 尝试预构建的 eStargz 镜像
您可以尝试我们在 [尝试预转换的镜像](/docs/pre-converted-images.md) 中列出的、位于 ghcr.io 上的预转换 eStargz 镜像。
### 使用 BuildKit 构建 eStargz 镜像
BuildKit 自 v0.10 版本起支持构建 eStargz 镜像。
您可以使用 [Docker Buildx](https://docs.docker.com/buildx/working-with-buildx/) 进行尝试。
以下命令构建一个 eStargz 镜像并将其推送到 `ghcr.io/ktock/hello:esgz`。
Flags `oci-mediatypes=true,compression=estargz` 用于启用 eStargz 的构建。
```
$ docker buildx build -t ghcr.io/ktock/hello:esgz \
-o type=registry,oci-mediatypes=true,compression=estargz,force-compression=true \
/tmp/buildctx/
```
支持 eStargz 的 BuildKit（v0.10）将[包含在 Docker v22.XX 中](https://github.com/moby/moby/blob/v22.06.0-beta.0/vendor.mod#L51)，但是您可以使用 Buildx 的 [driver](https://github.com/docker/buildx/blob/master/docs/reference/buildx_create.md#-set-the-builder-driver-to-use---driver) 功能在之前的版本中构建 eStargz 镜像。
您可以使用 [`docker buildx create`](https://docs.docker.com/engine/reference/commandline/buildx_create/) 启用特定版本的 BuildKit（此示例指定了 `v0.10.3`）。
```
$ docker buildx create --use --name v0.10.3 --driver docker-container --driver-opt image=moby/buildkit:v0.10.3
$ docker buildx inspect --bootstrap v0.10.3
```
### 使用 Kaniko 构建 eStargz 镜像
[Kaniko](https://github.com/GoogleContainerTools/kaniko) 是一种可以在容器和 Kubernetes 中运行的镜像构建器。
从 v1.5.0 版本开始，它实验性地支持构建 eStargz。
需要设置 `GGCR_EXPERIMENT_ESTARGZ=1`。
```
$ docker run --rm -e GGCR_EXPERIMENT_ESTARGZ=1 \
-v /tmp/buildctx:/workspace -v ~/.docker/config.json:/kaniko/.docker/config.json:ro \
gcr.io/kaniko-project/executor:v1.8.1 --destination ghcr.io/ktock/hello:esgz
```
### 使用 nerdctl 构建 eStargz 镜像
[nerdctl](https://github.com/containerd/nerdctl) 是兼容 Docker 的 containerd CLI，支持构建 eStargz 镜像。
```
$ nerdctl build -t ghcr.io/ktock/hello:1 /tmp/buildctx
$ nerdctl image convert --estargz --oci ghcr.io/ktock/hello:1 ghcr.io/ktock/hello:esgz
$ nerdctl push ghcr.io/ktock/hello:esgz
```
有关更多信息（例如延迟拉取）的更多详细信息，请参阅 nerdctl 文档：https://github.com/containerd/nerdctl/blob/master/docs/stargz.md
### 使用 `ctr-remote` 创建 eStargz 镜像
[`ctr-remote`](/docs/ctr-remote.md) 允许将镜像转换为经过优化的 eStargz。
如上面的性能测试结果所示，按需的延迟拉取提高了 pull 的性能，但由于读取文件会引发远程下载内容，因此会导致 runtime 的性能下降。
为了解决这个问题，`ctr-remote` 具有针对镜像的*基于工作负载*的优化。
为了尝试本节中描述的示例，您还可以使用基于 docker-compose 的演示环境。
您可以使用以下命令设置此环境（将此仓库放在 `${GOPATH}/src/github.com/containerd/stargz-snapshotter` 中）。
*请注意，这会在您的主机上运行特权容器。*
```
$ cd ${GOPATH}/src/github.com/containerd/stargz-snapshotter/script/demo
$ docker-compose build containerd_demo
$ docker-compose up -d
$ docker exec -it containerd_demo /bin/bash
(inside container) # ./script/demo/run.sh
```
以下示例将传统的 `library/ubuntu:20.04` 镜像转换为 eStargz。
该命令还针对在 `/bin/bash` 上执行 `ls` 的工作负载优化了镜像。
实际执行的操作是在临时容器中运行指定的工作负载，并记录所有文件访问，同时在 runtime 期间将它们标记为*可能被访问*。
转换后的镜像仍然是 **docker 兼容**的，因此您可以在不支持 eStargz 的 runtime（例如 Docker）上运行它。
```
# ctr-remote image pull docker.io/library/ubuntu:20.04
# ctr-remote image optimize --oci --entrypoint='[ "/bin/bash", "-c" ]' --args='[ "ls" ]' docker.io/library/ubuntu:20.04 registry2:5000/ubuntu:20.04
# ctr-remote image push --plain-http registry2:5000/ubuntu:20.04
```
最后，以下命令清除本地缓存，然后延迟拉取 eStargz 镜像。
Stargz snapshotter 会预取在优化后的工作负载中最可能被访问的文件，这有望提高该工作负载的缓存命中率，并缓解 runtime 开销，如本文档顶部的性能测试结果所示。
```
# ctr-remote image rm --sync registry2:5000/ubuntu:20.04
# ctr-remote images rpull --plain-http registry2:5000/ubuntu:20.04
fetching sha256:610399d1... application/vnd.oci.image.index.v1+json
fetching sha256:0b4a26b4... application/vnd.oci.image.manifest.v1+json
fetching sha256:8d8d9dbe... application/vnd.oci.image.config.v1+json
# ctr-remote run --rm -t --snapshotter=stargz registry2:5000/ubuntu:20.04 test /bin/bash
root@8eabb871a9bd:/# ls
bin boot dev etc home lib lib32 lib64 libx32 media mnt opt proc root run sbin srv sys tmp usr var
```
## 将 Stargz Snapshotter 作为 go module 导入
目前，Stargz Snapshotter 仓库包含以下两个 Go module，并且它们都需要被导入。
- `github.com/containerd/stargz-snapshotter`
- `github.com/containerd/stargz-snapshotter/estargz`
请确保您同时导入了它们，并且它们都指向*相同的提交版本*。
## 项目详情
Stargz Snapshotter 是 containerd 的**非核心**子项目，采用 [Apache 2.0 许可证](./LICENSE)授权。
作为 containerd 的非核心子项目，您可以在我们的 [`containerd/project`](https://github.com/containerd/project) 仓库中找到以下信息：
* [项目治理](https://github.com/containerd/project/blob/main/GOVERNANCE.md),
* [维护者](./MAINTAINERS),
* 和[贡献指南](https://github.com/containerd/project/blob/main/CONTRIBUTING.md)
`legacy` 展示了当我们使用 containerd 的默认 snapshotter（`overlayfs`）以及从 `docker.io/library` 复制且未经过优化的镜像时的启动性能。
对于此配置，containerd 会拉取整个镜像内容，`pull` 操作也会相应地消耗时间。
当我们使用带有 eStargz 转换镜像但未进行任何优化的 stargz snapshotter（`estargz-noopt`）时，我们看到 `pull` 操作的性能有所提升，因为 containerd 可以在容器启动时无需等待 `pull` 完成，并按需获取镜像必要的 chunks。
但同时，我们看到 `run` 操作出现了性能下降，因为每次访问文件都需要额外花费时间从 registry 获取它们。
当我们使用[优化后的 eStargz](/docs/ctr-remote.md)（`estargz`）时，我们可以缓解在 `estargz-noopt` 镜像中观察到的性能下降。
这是因为 [stargz snapshotter 在运行容器期间会预取并缓存*可能被访问的文件*](/docs/stargz-estargz.md)。
在首次创建容器时，stargz snapshotter 会等待预取完成，因此 `create` 有时会比其他类型的镜像花费更长的时间。
但这仍然比等待下载所有层的所有文件要快。
上面的直方图是[在 `ecdb227` 提交上的性能测试结果](https://github.com/containerd/stargz-snapshotter/actions/runs/398606060)。
我们会不断测量此 snapshotter 的性能，因此您可以通过本文档顶部显示的徽章获取最新结果。
请注意，由于互联网上的网络状况以及 GitHub Actions 中实例的位置等因素，我们有时会看到结果存在差异。
我们的性能测试方法基于 [HelloBench](https://github.com/Tintri/hello-bench)。
:nerd_face: 您也可以使用延迟拉取在 IPFS 上运行容器。这是一项实验性功能。有关更多详细信息，请参阅 [`./docs/ipfs.md`](./docs/ipfs.md)。
Stargz Snapshotter 是 containerd 的一个**非核心**子项目。
## 快速开始
- 有关 stargz snapshotter 插件及其配置的更多详细信息，请参阅 [Containerd Stargz Snapshotter 插件概述](/docs/overview.md)。
- 有关使用 containerd、CRI-O、Podman、systemd 等设置 eStargz 延迟拉取的更多详细信息，请参阅[安装 Stargz Snapshotter 和 Stargz Store](./docs/INSTALL.md)。
- 有关 eStargz 与社区工具集成状态的更多详细信息，请参阅 [eStargz 与其他工具的集成](./docs/integration.md)
要在 kubernetes 节点上使用 stargz snapshotter，您需要对 containerd 进行以下配置，并在节点上运行 stargz snapshotter daemon。
我们假设您使用 containerd（> v1.4.2）作为 CRI runtime。
```
version = 2
# 将 stargz snapshotter 插入到 containerd 中
# Containerd 通过指定的 socket 地址识别 stargz snapshotter。
# 下面指定的地址是 stargz snapshotter 监听的默认地址。
[proxy_plugins]
[proxy_plugins.stargz]
type = "snapshot"
address = "/run/containerd-stargz-grpc/containerd-stargz-grpc.sock"
[proxy_plugins.stargz.exports]
root = "/var/lib/containerd-stargz-grpc/"
# 通过 CRI 使用 stargz snapshotter
[plugins."io.containerd.grpc.v1.cri".containerd]
snapshotter = "stargz"
disable_snapshot_annotations = false
```
您可以尝试我们[预构建的](/Dockerfile) [KinD](https://github.com/kubernetes-sigs/kind) 节点镜像，其中包含上述配置。
```
$ kind create cluster --name stargz-demo --image ghcr.io/containerd/stargz-snapshotter:0.12.1-kind
```
:information_source: 对于 `ghcr.io/containerd/stargz-snapshotter:0.12.1-kind`，建议使用 kind 二进制文件 v0.16.x 或更高版本。
:information_source: 您可以从 [`ghcr.io/containerd/stargz-snapshotter:${VERSION}-kind`](https://github.com/orgs/containerd/packages/container/package/stargz-snapshotter) 命名空间获取最新的节点镜像。
然后您可以在集群上创建 eStargz pod。
在此示例中，我们创建一个转换过的 stargz Node.js pod（`ghcr.io/stargz-containers/node:17.8.0-esgz`）作为演示。
```
apiVersion: v1
kind: Pod
metadata:
name: nodejs
spec:
containers:
- name: nodejs-stargz
image: ghcr.io/stargz-containers/node:17.8.0-esgz
command: ["node"]
args:
- -e
- var http = require('http');
http.createServer(function(req, res) {
res.writeHead(200);
res.end('Hello World!\n');
}).listen(80);
ports:
- containerPort: 80
```
以下命令从 GitHub Container Registry 延迟拉取 `ghcr.io/stargz-containers/node:17.8.0-esgz` 并创建 pod，因此所花费的时间比原始镜像 `library/node:13.13` 更短。
```
$ kubectl --context kind-stargz-demo apply -f stargz-pod.yaml && kubectl --context kind-stargz-demo get po nodejs -w
$ kubectl --context kind-stargz-demo port-forward nodejs 8080:80 &
$ curl 127.0.0.1:8080
Hello World!
```
Stargz snapshotter 还支持[更多配置](/docs/overview.md)，包括私有 registry 身份验证、镜像仓库等。
## 获取 eStargz 镜像
- 有关镜像转换器 `ctr-remote` 的更多示例和详细信息，请参阅[使用 `ctr-remote image optimize` 优化镜像](/docs/ctr-remote.md)。
- 有关 eStargz 格式的更多详细信息，请参阅 [eStargz：用于延迟拉取容器镜像的 Tar.gz 层的标准兼容扩展](/docs/stargz-estargz.md)
要实现延迟拉取镜像，您首先需要准备 eStargz 镜像。
有几种方法可以实现这一目标。
本节介绍其中的一些方法。
### 尝试预构建的 eStargz 镜像
您可以尝试我们在 [尝试预转换的镜像](/docs/pre-converted-images.md) 中列出的、位于 ghcr.io 上的预转换 eStargz 镜像。
### 使用 BuildKit 构建 eStargz 镜像
BuildKit 自 v0.10 版本起支持构建 eStargz 镜像。
您可以使用 [Docker Buildx](https://docs.docker.com/buildx/working-with-buildx/) 进行尝试。
以下命令构建一个 eStargz 镜像并将其推送到 `ghcr.io/ktock/hello:esgz`。
Flags `oci-mediatypes=true,compression=estargz` 用于启用 eStargz 的构建。
```
$ docker buildx build -t ghcr.io/ktock/hello:esgz \
-o type=registry,oci-mediatypes=true,compression=estargz,force-compression=true \
/tmp/buildctx/
```
支持 eStargz 的 BuildKit（v0.10）将[包含在 Docker v22.XX 中](https://github.com/moby/moby/blob/v22.06.0-beta.0/vendor.mod#L51)，但是您可以使用 Buildx 的 [driver](https://github.com/docker/buildx/blob/master/docs/reference/buildx_create.md#-set-the-builder-driver-to-use---driver) 功能在之前的版本中构建 eStargz 镜像。
您可以使用 [`docker buildx create`](https://docs.docker.com/engine/reference/commandline/buildx_create/) 启用特定版本的 BuildKit（此示例指定了 `v0.10.3`）。
```
$ docker buildx create --use --name v0.10.3 --driver docker-container --driver-opt image=moby/buildkit:v0.10.3
$ docker buildx inspect --bootstrap v0.10.3
```
### 使用 Kaniko 构建 eStargz 镜像
[Kaniko](https://github.com/GoogleContainerTools/kaniko) 是一种可以在容器和 Kubernetes 中运行的镜像构建器。
从 v1.5.0 版本开始，它实验性地支持构建 eStargz。
需要设置 `GGCR_EXPERIMENT_ESTARGZ=1`。
```
$ docker run --rm -e GGCR_EXPERIMENT_ESTARGZ=1 \
-v /tmp/buildctx:/workspace -v ~/.docker/config.json:/kaniko/.docker/config.json:ro \
gcr.io/kaniko-project/executor:v1.8.1 --destination ghcr.io/ktock/hello:esgz
```
### 使用 nerdctl 构建 eStargz 镜像
[nerdctl](https://github.com/containerd/nerdctl) 是兼容 Docker 的 containerd CLI，支持构建 eStargz 镜像。
```
$ nerdctl build -t ghcr.io/ktock/hello:1 /tmp/buildctx
$ nerdctl image convert --estargz --oci ghcr.io/ktock/hello:1 ghcr.io/ktock/hello:esgz
$ nerdctl push ghcr.io/ktock/hello:esgz
```
有关更多信息（例如延迟拉取）的更多详细信息，请参阅 nerdctl 文档：https://github.com/containerd/nerdctl/blob/master/docs/stargz.md
### 使用 `ctr-remote` 创建 eStargz 镜像
[`ctr-remote`](/docs/ctr-remote.md) 允许将镜像转换为经过优化的 eStargz。
如上面的性能测试结果所示，按需的延迟拉取提高了 pull 的性能，但由于读取文件会引发远程下载内容，因此会导致 runtime 的性能下降。
为了解决这个问题，`ctr-remote` 具有针对镜像的*基于工作负载*的优化。
为了尝试本节中描述的示例，您还可以使用基于 docker-compose 的演示环境。
您可以使用以下命令设置此环境（将此仓库放在 `${GOPATH}/src/github.com/containerd/stargz-snapshotter` 中）。
*请注意，这会在您的主机上运行特权容器。*
```
$ cd ${GOPATH}/src/github.com/containerd/stargz-snapshotter/script/demo
$ docker-compose build containerd_demo
$ docker-compose up -d
$ docker exec -it containerd_demo /bin/bash
(inside container) # ./script/demo/run.sh
```
以下示例将传统的 `library/ubuntu:20.04` 镜像转换为 eStargz。
该命令还针对在 `/bin/bash` 上执行 `ls` 的工作负载优化了镜像。
实际执行的操作是在临时容器中运行指定的工作负载，并记录所有文件访问，同时在 runtime 期间将它们标记为*可能被访问*。
转换后的镜像仍然是 **docker 兼容**的，因此您可以在不支持 eStargz 的 runtime（例如 Docker）上运行它。
```
# ctr-remote image pull docker.io/library/ubuntu:20.04
# ctr-remote image optimize --oci --entrypoint='[ "/bin/bash", "-c" ]' --args='[ "ls" ]' docker.io/library/ubuntu:20.04 registry2:5000/ubuntu:20.04
# ctr-remote image push --plain-http registry2:5000/ubuntu:20.04
```
最后，以下命令清除本地缓存，然后延迟拉取 eStargz 镜像。
Stargz snapshotter 会预取在优化后的工作负载中最可能被访问的文件，这有望提高该工作负载的缓存命中率，并缓解 runtime 开销，如本文档顶部的性能测试结果所示。
```
# ctr-remote image rm --sync registry2:5000/ubuntu:20.04
# ctr-remote images rpull --plain-http registry2:5000/ubuntu:20.04
fetching sha256:610399d1... application/vnd.oci.image.index.v1+json
fetching sha256:0b4a26b4... application/vnd.oci.image.manifest.v1+json
fetching sha256:8d8d9dbe... application/vnd.oci.image.config.v1+json
# ctr-remote run --rm -t --snapshotter=stargz registry2:5000/ubuntu:20.04 test /bin/bash
root@8eabb871a9bd:/# ls
bin boot dev etc home lib lib32 lib64 libx32 media mnt opt proc root run sbin srv sys tmp usr var
```
## 将 Stargz Snapshotter 作为 go module 导入
目前，Stargz Snapshotter 仓库包含以下两个 Go module，并且它们都需要被导入。
- `github.com/containerd/stargz-snapshotter`
- `github.com/containerd/stargz-snapshotter/estargz`
请确保您同时导入了它们，并且它们都指向*相同的提交版本*。
## 项目详情
Stargz Snapshotter 是 containerd 的**非核心**子项目，采用 [Apache 2.0 许可证](./LICENSE)授权。
作为 containerd 的非核心子项目，您可以在我们的 [`containerd/project`](https://github.com/containerd/project) 仓库中找到以下信息：
* [项目治理](https://github.com/containerd/project/blob/main/GOVERNANCE.md),
* [维护者](./MAINTAINERS),
* 和[贡献指南](https://github.com/containerd/project/blob/main/CONTRIBUTING.md)标签：EVTX分析, 子域名突变, 日志审计, 请求拦截