Docker 29 更改了新安装的默认镜像存储位置。
Docker 29 has changed its default image store for new installs

原始链接: https://docs.docker.com/engine/storage/containerd

## Docker Engine 的 containerd 镜像存储 Docker Engine 29.0 及更高版本默认使用 containerd 镜像存储,这是一种新的存储后端,利用快照技术代替了像 overlay2 这样的传统图驱动。虽然它具有优势,但理解其差异至关重要。 **主要优势:** 支持多平台镜像、镜像证明(来源/SBOM)、Wasm 容器以及用于实现更快镜像拉取的先进快照技术。 **重要注意事项:** containerd 存储通常**使用更多磁盘空间**,因为它存储压缩和未压缩的镜像层,导致冗余,尤其是在镜像共享基础层时。建议定期清理 (`docker image prune`) 并监控磁盘使用情况 (`docker system df`)。 **切换与迁移:** 升级需要通过 `/etc/docker/daemon.json` 手动启用 containerd 存储。现有镜像会被隐藏但仍保留在磁盘上,可以通过切换回去来访问。存在一个实验性的自动迁移功能,但建议进行备份。

Docker 29 版本已将其默认镜像存储更改为 containerd,适用于新安装,将数据从 `/var/lib/docker` 移动到 `/var/lib/containerd`。 这一变化导致磁盘空间使用量增加,因为 containerd 以压缩和未压缩格式存储镜像,与之前的系统不同。 一位用户在尝试在 IncusOS 容器实例之间持久化 Docker 数据时注意到了此更新,发现他们现有的卷挂载不再起作用。 他们分享了一个基于 ZFS 的解决方案来同步这两个目录。 虽然一些用户质疑此决定导致磁盘使用量增加,但另一些人指出这使 Docker 与 containerd 标准保持一致。 一位评论员甚至建议考虑 Podman 作为替代方案。 更多关于此更改和配置的信息可以在 Docker 博客和原始帖子中链接的文档中找到。
相关文章

原文

The containerd image store is the default storage backend for Docker Engine 29.0 and later on fresh installations. If you upgraded from an earlier version, your daemon continues using the legacy graph drivers (overlay2) until you enable the containerd image store.

containerd, the industry-standard container runtime, uses snapshotters instead of classic storage drivers for storing image and container data.

The containerd image store is not available when using user namespace remapping (userns-remap). See moby#47377 for details.

The containerd image store uses snapshotters to manage how image layers are stored and accessed on the filesystem. This differs from the classic graph drivers like overlay2.

The containerd image store enables:

  • Building and storing multi-platform images locally. With classic storage drivers, you need external builders for multi-platform images.
  • Working with images that include attestations (provenance, SBOM). These use image indices that the classic store doesn't support.
  • Running Wasm containers. The containerd image store supports WebAssembly workloads.
  • Using advanced snapshotters. containerd supports pluggable snapshotters that provide features like lazy-pulling of images (stargz) or peer-to-peer image distribution (nydus, dragonfly).

For most users, switching to the containerd image store is transparent. The storage backend changes, but your workflows remain the same.

The containerd image store uses more disk space than the legacy storage drivers for the same images. This is because containerd stores images in both compressed and uncompressed formats, while the legacy drivers stored only the uncompressed layers.

When you pull an image, containerd keeps the compressed layers (as received from the registry) and also extracts them to disk. This dual storage means each layer occupies more space. The compressed format enables faster pulls and pushes, but requires additional disk capacity.

This difference is particularly noticeable with multiple images sharing the same base layers. With legacy storage drivers, shared base layers were stored once locally, and reused images that depended on them. With containerd, each image stores its own compressed version of shared layers, even though the uncompressed layers are still de-duplicated through snapshotters. The compressed storage adds overhead proportional to the number of images using those layers.

If disk space is constrained, consider the following:

  • Regularly prune unused images with docker image prune
  • Use docker system df to monitor disk usage
  • Configure the data directory to use a partition with adequate space

If you're upgrading from an earlier Docker Engine version, you need to manually enable the containerd image store.

Switching storage backends temporarily hides images and containers created with the other backend. Your data remains on disk. To access the old images again, switch back to your previous storage configuration.

Add the following configuration to your /etc/docker/daemon.json file:

Save the file and restart the daemon:

After restarting the daemon, verify you're using the containerd image store:

Docker Engine uses the overlayfs containerd snapshotter by default.

When you enable the containerd image store, existing images and containers from the overlay2 driver remain on disk but become hidden. They reappear if you switch back to overlay2. To use your existing images with the containerd image store, push them to a registry first, or use docker save to export them.

Docker Engine includes an experimental feature that can automatically switch to the containerd image store under certain conditions. This feature is experimental. It's provided for those who want to test it, but starting fresh is the recommended approach.

The automatic migration feature is experimental and may not work reliably in all scenarios. Create backups before attempting to use it.

To enable automatic migration, add the containerd-migration feature to your /etc/docker/daemon.json:

You can also set the DOCKER_MIGRATE_SNAPSHOTTER_THRESHOLD environment variable to make the daemon switch automatically if you have no containers and your image count is at or below the threshold. For systemd:

Add:

If you have no running or stopped containers and 5 or fewer images, the daemon switches to the containerd image store on restart. Your overlay2 data remains on disk but becomes hidden.

To learn more about the containerd image store and its capabilities in Docker Desktop, see containerd image store on Docker Desktop.

联系我们 contact @ memedata.com