Fix stale image facts

This commit is contained in:
yeasy
2026-05-17 20:28:01 -07:00
parent 78ca8f6d19
commit e21794ebde
2 changed files with 2 additions and 2 deletions
+1 -1
View File
@@ -10,7 +10,7 @@
比如我们想要创建一个 [OpenVZ](https://openvz.org) 的 Ubuntu 16.04 [模板](https://wiki.openvz.org/Download/template/precreated)的镜像: 比如我们想要创建一个 [OpenVZ](https://openvz.org) 的 Ubuntu 16.04 [模板](https://wiki.openvz.org/Download/template/precreated)的镜像:
> **版本提示**示例中的 Ubuntu 16.04 (Xenial) 已于 2021 4 月停止支持如果用于生产环境建议更新至 Ubuntu 22.04 LTS 或更新版本 > **版本提示**`noble` 对应 Ubuntu 24.04 LTS实际用于生产环境应选择仍在安全维护期内的发行版并按团队的基础镜像更新策略定期重建
```bash ```bash
$ docker import \ $ docker import \
+1 -1
View File
@@ -60,7 +60,7 @@ Docker 镜像的每一层都有一个唯一的 ID,这个 ID 是根据该层的
Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载传统的实现方式常见于 `overlay2``aufs``btrfs``zfs` 等存储驱动而在 Docker Engine 29.0 及之后的全新安装中默认镜像后端已经变为 containerd image store它使用 snapshotter 来管理这些层 Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载传统的实现方式常见于 `overlay2``aufs``btrfs``zfs` 等存储驱动而在 Docker Engine 29.0 及之后的全新安装中默认镜像后端已经变为 containerd image store它使用 snapshotter 来管理这些层
> **版本背景**Docker Engine 29.0发布于 2025 11 是一个重要版本分界点全新安装场景下默认 containerd image store 作为镜像存储后端这对镜像管理OCI 合规性和供应链安全都有深远影响如果你的 Docker 版本低于 29.0镜像存储仍使用传统的 classic store 路径 > **版本背景**Docker Engine 29.0.0 发布于 2025 11 10 是一个重要版本分界点Docker Engine 29.0 及之后的全新安装默认使 containerd image store从更早版本升级的 daemon 会继续使用 legacy graph driver直到显式启用 containerd image storeDocker Desktop 4.34 及之后也默认启用 containerd image store实际环境仍应以当前配置为准
虽然底层实现细节不同但它们都遵循上述的 **分层 + CoW** 模型因此无论你看到的是 `overlay2` 还是 containerd snapshotter理解镜像层容器层和写时复制的方式都是一样重要的 虽然底层实现细节不同但它们都遵循上述的 **分层 + CoW** 模型因此无论你看到的是 `overlay2` 还是 containerd snapshotter理解镜像层容器层和写时复制的方式都是一样重要的