和大多数公司一样，我们为产品中使用的所有组件构建Docker镜像。随着时间的推移，其中一些镜像变得越来越大，同时持续集成（CI）构建也变得越来越长。我的目标是让CI构建时间不超过5分钟。

生产力下降的原因如下：

• 开发人员需要等待构建完成，从而浪费时间。
• 开发人员开始着手新任务，并需要稍后返回。这需要进行更多的上下文切换，通常也会导致效率低下。

在本文中，我们应用了两个小的改进，使得构建时间大幅度提高。在介绍两个改进之前，首先确保你已经遵循了编写Dockerfile的实践，例如：

• 尽量减少层数
• 使用多阶段构建
• 使用小基础镜像
• ……

Buildkit和Buildx

让我们解释一下Buildkit和Buildx，因为这两个术语经常被互换使用，但它们并不是完全相同的。在撰写本文之前，我也没有完全理解两者之间的区别。

Buildkit

Buildkit是改进后的后端，用于取代传统的Docker构建器。从2018年开始，它与Docker一起打包，并在docker引擎23.0中成为默认构建器。

Buildkit提供了许多实用的功能：

• 缓存能力改进
• 不同层并行构建
• 延迟拉取基础镜像（≥ Buildkit 0.9）

使用Buildkit时，你应该会注意到docker build命令的输出看起来更干净、更有结构。

在Docker版本低于23.0的情况下，使用Buildkit的典型方法是按照以下方式设置Buildkit参数：

`--build-arg BUILDKIT_INLINE_CACHE=1`
				

					
					

						1.
					

				

这将启用内联缓存，可以显著加快构建过程。但是，这在Docker版本低于23.0的情况下不可用。

DOCKER_BUILDKIT=1 docker build --platform linux/amd64 . -t someImage:someVersion
DOCKER_BUILDKIT=1 docker push someImage:someVersion
				

					
					

						1.
					

					

						2.
					

				

Buildx

Buildx是Docker的一个插件，它让你能够充分利用Buildkit在Docker中的能力。它之所以被创建，是因为Buildkit支持许多新的配置选项，这些选项无法以向后兼容的方式全部集成到docker build命令中。

除了构建镜像之外，Buildx还支持管理多个构建器。这在持续集成中非常有用，可以定义范围明确且具有不同配置的环境，因为它们不会修改共享的Docker守护进程。

可以按照以下步骤开始使用Buildx：

docker buildx create --bootstrap --name builder
docker buildx use builder
				

					
					

						1.
					

					

						2.
					

				

一、从远程缓存中受益

加快构建速度的个方法是将镜像缓存在远程注册表中。这样，即使在不同的机器上执行构建时（例如CI中的常见情况），仍然可以从构建缓存中受益。大多数人在构建新版本的镜像之前会拉取版本的镜像。这样做的好处是可以缓存未更改的层，但代价是初需要拉取完整的镜像。拉取完整镜像可能需要一些时间，而且也不能保证可以重用这些层。使用以下命令进行说明：

docker pull someImage:latest || true docker build --platform linux/amd64 .  -t someImage:someVersion  -f Dockerfile  --cache-from someImage:latest
				

					
					

						1.
					

					

						2.
					

					

						3.
					

					

						4.
					

					

						5.
					

				

使用 Buildx，可以将缓存信息存储在远程位置（例如容器注册表、blob 存储等）。构建器会检查给定的层是否已经存在，如果存在，它将重用该层而不是重新创建它。甚至无需将层拉取到本地即可实现此功能。如下所示：

docker buildx build --platform linux/amd64 .  -t someImage:someVersion - push  --cache-to type=registry,ref=someCachedImage:someVersion,mode=max --cache-from type=registry,ref=someCachedImage:someVersion
				

					
					

						1.
					

					

						2.
					

					

						3.
					

					

						4.
					

				

模式“max”表示我们将为每个层存储构建信息，即使这些层在终的镜像中未被使用（例如在使用多阶段构建时）。默认情况下，使用模式“min”，它仅存储关于终镜像中存在的层的构建信息。

缓存存在一个特殊情况是将缓存数据“内联”存储，这意味着它将与镜像一起缓存。在使用Buildkit没有使用Buildx时也支持此选项。但在使用多阶段构建时会更具挑战性，并且它无法清晰地区分构建产物的输出和缓存。缓存数据“内联”存储的命令如下所示：

docker buildx build - platform linux/amd64 .  -t someImage:someVersion --push  --cache-to type=inline,mode=max  --cache-from someImage:somePreviousVersion
				

					
					

						1.
					

					

						2.
					

					

						3.
					

					

						4.
					

				

二、添加文件到镜像的新方法

Docker推出了新版本的Dockerfile语法，即#syntax=docker/dockerfile:1.4。它支持COPY和ADD命令的额外链接选项。

以前，当使用COPY或ADD命令时，构建器会创建一个新的快照，将新文件与已存在的文件系统合并。结果是，在执行此操作之前，父层都需要存在，不然的话目标目录可能还不存在。终的镜像（构建命令的结果）将由每个层的tarball组成，其中包含相应快照之间的差异。

FROM baseImage:version COPY binary /opt/
				

					
					

						1.
					

					

						2.
					

				

使用链接选项时，新文件将放入自己的快照中，而不会依赖于先前的层。链接的文件存储在自己的tarball中，并且不同的tarball相互链接在一起，而不会依赖于现有的文件系统，如下图所示。

# syntax=docker/dockerfile:1.4 FROM baseImage:version COPY [--chown=<user>:<group>] [--chmod=<perms>] --link binary /opt/
				

					
					

						1.
					

					

						2.
					

					

						3.
					

				

主要的优势是文件不再依赖于先前的层。只要文件没有改变，即使父层发生了更改，该层也可以重复使用。

并且还可以提高构建速度，因为现在可以并行执行多个层复制数据的操作。

结论

通过上述两种方式，我们将镜像构建速度提升了 1 倍。