Docker v23.0.0 正式发布

Docker 上一个发布的正式版本是 v20.10 发布于 2020 年的 12 月份，至今已过两年有余。不过其 patch 版本倒是也一直在更新，目前最新的是 v20.10.23 。

作为一个引领了容器化浪潮的基础技术，Docker 经历了每年发多个版本，到每年两个版本，每年一个版本，以及现在这个历经两年才发布了一个正式版本的过程。这其实也从侧面反映出来了 Docker 的发展。

作为一个真正被用户采用的开源项目，在初期会不断的满足用户需求，并且也不断的有贡献者参与进来，迭代速度相对较快。但是当大多数需求已经被满足，成为一个基础设施的时候，大多数用户会更加关注于上层的项目，比如 Kubernetes，而逐步放弃对该项目的投入。

加上 Docker 也把自己的底层容器运行时 containerd 和 runc 拆分出来，还有很多其中的模块和通用基础库也都拆分成为了一些独立的项目，这也就使得主仓库更加的专注，活跃度慢慢降低。

同时，过去的两年多时间，Docker 开源项目，及其创办者 Docker Inc. 过的也并不好。

比如 2020 年，它在技术圈内的两度成为（舆论的）焦点。，具体信息可以看我之前的文章：

K8S 弃用 Docker 了？Docker 不能用了？别逗了！ | MoeLove

不过从 2022 年初，Docker Inc. 拿到 C 轮 1.05 亿美金的融资后，展开了多个收购项目和扩充团队，也逐步的让 Docker Inc. 和 Docker 项目回到了正轨。

好了，回到 Docker v23.0.0 版本中，我们一起来看看这个已经跳票两年的版本为我们带来了哪些值得关注的更新吧！

构建系统默认切换到了 BuildKit

Docker 其实在 2017 年就开始着手增加自己的新一代构建引擎 BuildKit 了，并且在 Docker v18.09 中已经可以通过增加 DOCKER_BUILDKIT=1 环境变量的方式来默认启用它了。后来 Docker Desktop 中也已经将 BuildKit 设置成了默认的构建引擎。

BuildKit 有很多优秀的特性，比如：

它可以在多阶段构建中检测并跳过执行未使用的构建阶段。但是 Docker 旧版本中的 builder 只能按顺序执行 Dockerfile 中的阶段；
并发构建独立的构建阶段，这可以显著提升构建的效率；
在两次构建之间，只递增传输构建环境中已更改的文件;
检测并跳过传输构建环境中未使用的文件;
使用具有许多新功能的 Dockerfile 前端实现，用户可以自行选择要使用的 Dockerfile frontend；
避免与其他API（中间镜像和容器）产生副作用;
对你的构建缓存进行优先排序，以便自动清除;

关于 Docker 中构建过程的原理和源码分析，可以看看我之前的文章：万字长文：彻底搞懂容器镜像构建 | MoeLove

同时，BuildKit 除了作为 Docker 的构建引擎外，也可以被独立使用，或者被其他工具集成，比如 Tekton，Dagger 等。

Docker 之前提供了一个名为 buildx 的插件，可以认为是 BuildKit 的前端，主要是为了能提供 BuildKit 的一些能力。在 Docker v23.0.0 中，docker build 实际已经成为了 docker buildx build 的别名。

(MoeLove) ➜ docker build --help

Usage:  docker buildx build [OPTIONS] PATH | URL | -

Start a build

Aliases:
  docker buildx build, docker buildx b

docker buildx 同样具备了非常丰富的特性，其中一个有趣的特性在于它支持设置不同的构建驱动，包括使用 docker-container ， Kubernetes 和 remote。

这样做的好处在于，如果你本地的计算资源不足，那么你可以选择使用 Kubernetes 集群进行构建（副本数可以自行设置）也可以使用 remote 的 Docker engine 进行构建（但是 remote 就只是 1 个副本了）。

(MoeLove) ➜ kubectl create ns buildkit
namespace/buildkit created
(MoeLove) ➜ docker buildx create \
  --bootstrap \
  --name=kube \
  --driver=kubernetes \
  --driver-opt=namespace=buildkit,replicas=4
[+] Building 12.7s (1/1) FINISHED
 => [internal] booting buildkit                                                                                                                                                                                            12.2s
 => => waiting for 4 pods to be ready                                                                                                                                                                                      11.6s
kube
(MoeLove) ➜ docker buildx ls     
NAME/NODE                DRIVER/ENDPOINT             STATUS   BUILDKIT PLATFORMS
kube                     kubernetes                                    
  kube0-6977cdcb75-5flvl                             running  v0.11.2  linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
  kube0-6977cdcb75-7s8x9                             running  v0.11.2  linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
  kube0-6977cdcb75-bzk75                             running  v0.11.2  linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
  kube0-6977cdcb75-n78cw                             running  v0.11.2  linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
default *                docker                                        
  default                default                     running  23.0.0   linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
(MoeLove) ➜ docker buildx  use kube

这样之后执行 docker build 的时候，构建就会在 Kubernetes 集群中的 Pod 内进行了。

另一个好处在于，如果你的本地网络环境不太好，也可以利用远端的 Kubernetes 或者 remote 的 Docker 实例进行构建，突破这个限制。

允许配置更多 OCI 运行时

Docker 默认使用的运行时是 containerd，其底层 OCI 运行时是 runc，但是目前也有很多其他的运行时可以使用，比如

containers/crun: A fast and lightweight fully featured OCI runtime and C library for running containers
containers/youki: A container runtime written in Rust

但如果从规范层来看 containerd 架构的话，shim 才是 OCI 运行时，所以上述的这些实现都可以认为是 io.containerd.runc.v2 的一个实现细节。

目前有一些其他的运行时，它们实现了自己的 shim，比如 Kata 的 io.containerd.kata.v2 ，它是无法在 Docker 中直接使用的。所以 Docker 对此进行了支持。从 Docker v23.0.0 开始，用户可以简单的通过 docker run --runtime <> 将任意兼容 containerd runtime v2 API 的运行时配置给 Docker 使用。

几个月前，Docker Desktop 中支持了通过 wasmedge 运行 WASM，就是这样的方式。

允许多种配置 Proxy 的方式

之前 Docker 仅仅允许通过环境变量的方式进行 Proxy 的配置，所以通常在进行 Docker 部署的时候，会增加一个配置

# /etc/systemd/system/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://IP:Port"
Environment="HTTPS_PROXY=http://IP:PORT"
Environment="NO_PROXY=localhost,127.0.0.1,*.moelove.info"

在新版本中允许通过 /etc/docker/daemon.json 和通过命令行参数的方式进行配置了：

(MoeLove) ➜ dockerd --help |grep http
      --http-proxy string                       HTTP proxy URL to use for outgoing traffic
      --https-proxy string                      HTTPS proxy URL to use for outgoing traffic

但是注意此配置仍然不是动态加载的，如果要修改，仍然需要重启 docker daemon，这和 Go 中使用的 sync.Once() 有关。

废弃

移除了对 ~/.dockercfg 配置的支持，实际上这个配置从 1.7 就宣布废弃了；
移除了 -g 和 --graph 参数，使用 --data-root 替代；
移除了 LCOW (Linux Containers on Windows);
移除了 io.containerd.runtime.v1.linux OCI runtime 的支持；
移除了对于没有 d_type 文件系统上 overlay 和 overlay2 的支持，对于新部署 Docker 环境的小伙伴需要特别关注，毕竟 Overlay2 是默认的存储驱动；

对 SwarmKit 的一些支持

Swarm 尽管在容器编排领域败给了 Kubernetes，但即使到目前也还是有一些人因为它的简单在使用它。而且 Mirantis 在 2019 年收购了 Docker Enterprise 后，也将 Swarm 放在了自家的 Mirantis Kubernetes Engine 平台中了。所以也还在继续更新和提供支持。