Docker 4.12.0

Docker 在剛剛發布的 Docker Desktop 4.12.0^[1] 中，加入了實驗特性：進一步集成 containerd，使用 containerd 來管理和存儲鏡像。

為什么說是“進一步集成”？這就要翻翻 Docker 和 containerd 的歷史了。

containerd 的誕生

containerd 最早出現在 Docker Engine 中，后來為了將 Docker Engine 做得更加輕量、快速和健壯，在 2016 年 Docker 將 containerd 從 daemon（??dockerd??） 中獨立出來，并完成了與 daemon 的集成。獨立出來的 containerd 全面支持 OCI（Open Container Initiative^[2]）資源的啟動和生命周期的管理，也因此 containerd 可以支持 runc（前身是 Docker 中的 libcontainer，后來捐贈給 LF）以外的其他 OCI 實現。2017 年 Docker 將 containerd 捐獻給 CNCF；2019 年 2 月，containerd 畢業。

docker with containerd

containerd 獨立出來之后，發送到 Docker Engine 的請求：

1. Docker daemon 完成鏡像管理的操作（拉取、更新鏡像）
2. daemon 會為創建容器進行準備工作（創建OCI bundles^[3]）：鏡像的信息和運行時的信息。
3. daemon 調用 containerd 的 API。
4. 收到請求的 containerd 不會直接去操作容器（不直接作為容器的父進程，防止 containerd 掛掉影響容器），而是先創建一個 container-shim 進程。
5. container-shim 調用runc cli^[4]來運行容器，并啟動 Unix domain socket 暴露 API 提供給 containerd進行容器的管理。

隨著 containerd 的不斷演進，除了容器創建和容器聲明周期管理以外，從 1.1 開始 containerd 加入了 CRI（Container Runtime Interface）的支持。

CRI

在《源碼解析 kubectl port-forward 工作原理》^[5] 中層提到 kubelet 會調用 rumtime service 的 gRPC 接口，除了用于 portforward 流的 stream server以外，其實還有實現 CRI 接口 `RuntimeService`^[6] 和 `ImageService `^[7] 的 ??RuntimeServiceServer?? 和 ??ImageServiceServer??。

??RuntimeServiceServer?? 用于接收并處理容器及其生命周期相關的操作，而 ??ImageServiceServer?? 則是用來處理鏡像相關的操作。containerd 提供了鏡像拉取、刪除、檢查、存儲等功能。

既然 containerd 可以進行鏡像的管理，而且 Docker 已經在使用，Docker 也沒有必要自己繼續維護一套相同的功能。

切換到 containerd 的鏡像管理

在 Docker Desktop 的設置中啟動 containerd 管理鏡像后，運行 ??docker info?? 會發現存儲的驅動從原來的 ??overlay2?? 變成了 containerd 的 ??stargz??。

切換前：

切換前切換后：

切換后既然使用了 containerd 的 snapshotters 來管理存儲（掛在容器的根文件系統），就可以支持多種 snapshotters，比如 stargz^[8] 的延遲拉取。

此外，得益于 containerd 原生支持多平臺鏡像的存儲，還是因為 snapshotters 的原因，可以使用 docker 來構建多平臺的鏡像了。

#切換前
docker buildx build -t demo --no-cache --platform linux/amd64,linux/arm64 .
[+] Building 0.0s (0/0)
error: multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")

總結

使用 containerd 作為 Docker 的鏡像管理目前還處于實驗性階段，必可避免會存在問題，使用時請謹慎對待。

隨著 Docker Swarm 在容器編排之戰中的落敗，Kubernetes 的話語權也越來越強。在 Kubernetes 1.24.0 中移除了 docker shim 代碼，看起來更像是 containerd 取代了 Docker 曾經的地位，而 Docker 也越來越名聲不顯。從趨勢來看，Docker 未來將會完全集成 containerd。

參考

• Extending Docker’s Integration with containerd^[9]
• Docker containerd integration^[10]
• Learning Containers From The Bottom Up^[11]

參考資料

[1] Docker Desktop 4.12.0: https://docs.docker.com/desktop/release-notes/#docker-desktop-4120

[2] Open Container Initiative: https://www.opencontainers.org

[3] OCI bundles: https://chromium.googlesource.com/external/github.com/docker/containerd/+/refs/tags/v0.2.0/docs/bundle.md

[4] runc cli: https://github.com/opencontainers/runc

[5] 《源碼解析 kubectl port-forward 工作原理》: https://atbug.com/how-kubectl-port-forward-works/

[6] ??RuntimeService?: https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto#L34

[7] ??ImageService ?: https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto#L128

[8] stargz: https://github.com/containerd/stargz-snapshotter

[9] Extending Docker’s Integration with containerd: https://www.docker.com/blog/extending-docker-integration-with-containerd/

[10] Docker containerd integration: https://www.docker.com/blog/docker-containerd-integration/

[11] Learning Containers From The Bottom Up: https://iximiuz.com/en/posts/container-learning-path/