和大多数公司一样，我们为产品中使用的所有组件构建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`这将启用内联缓存，可以显著加快构建过程。但是，这在Docker版本低于23.0的情况下不可用。
DOCKER_BUILDKIT=1 docker build --platform linux/amd64 . -t someImage:someVersion
DOCKER_BUILDKIT=1 docker push someImage:someVersionBuildx
Buildx是Docker的一个插件，它让你能够充分利用Buildkit在Docker中的能力。它之所以被创建，是因为Buildkit支持许多新的配置选项，这些选项无法以向后兼容的方式全部集成到docker build命令中。
除了构建镜像之外，Buildx还支持管理多个构建器。这在持续集成中非常有用，可以定义范围明确且具有不同配置的环境，因为它们不会修改共享的Docker守护进程。
可以按照以下步骤开始使用Buildx：
docker buildx create --bootstrap --name builder
docker buildx use builder一、从远程缓存中受益
加快构建速度的第一个方法是将镜像缓存在远程注册表中。这样，即使在不同的机器上执行构建时（例如CI中的常见情况），仍然可以从构建缓存中受益。大多数人在构建新版本的镜像之前会拉取最新版本的镜像。这样做的好处是可以缓存未更改的层，但代价是最初需要拉取完整的镜像。拉取完整镜像可能需要一些时间，而且也不能保证可以重用这些层。使用以下命令进行说明：
docker pull someImage:latest || true
docker build --platform linux/amd64 . \
-t someImage:someVersion \
-f Dockerfile \
--cache-from someImage:latest使用 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模式“max”表示我们将为每个层存储构建信息，即使这些层在最终的镜像中未被使用（例如在使用多阶段构建时）。默认情况下，使用模式“min”，它仅存储关于最终镜像中存在的层的构建信息。
缓存存在一个特殊情况是将缓存数据“内联”存储，这意味着它将与镜像一起缓存。在使用Buildkit没有使用Buildx时也支持此选项。但在使用多阶段构建时会更具挑战性，并且它无法清晰地区分构建产物的输出和缓存。缓存数据“内联”存储的命令如下所示：
docker buildx build - platform linux/amd64 . \
-t someImage:someVersion --push \
--cache-to type=inline,mode=max \
--cache-from someImage:somePreviousVersion二、添加文件到镜像的新方法
Docker推出了新版本的Dockerfile语法，即#syntax=docker/dockerfile:1.4。它支持COPY和ADD命令的额外链接选项。
以前，当使用COPY或ADD命令时，构建器会创建一个新的快照，将新文件与已存在的文件系统合并。结果是，在执行此操作之前，父层都需要存在，不然的话目标目录可能还不存在。最终的镜像（构建命令的结果）将由每个层的tarball组成，其中包含相应快照之间的差异。
FROM baseImage:version
COPY binary /opt/使用链接选项时，新文件将放入自己的快照中，而不会依赖于先前的层。链接的文件存储在自己的tarball中，并且不同的tarball相互链接在一起，而不会依赖于现有的文件系统，如下图所示。
# syntax=docker/dockerfile:1.4
FROM baseImage:version
COPY [--chown=<user>:<group>] [--chmod=<perms>] --link binary /opt/主要的优势是文件不再依赖于先前的层。只要文件没有改变，即使父层发生了更改，该层也可以重复使用。
并且还可以提高构建速度，因为现在可以并行执行多个层复制数据的操作。
结论
通过上述两种方式，我们将镜像构建速度提升了 1 倍。
