如何减少40%的Docker构建时间

随着Docker的普及,许多公司的产品会将组件构建为Docker镜像。但随着时间的推移,一些镜像变得越来越大,对应的CI构建也变得越来越慢。

如果能在喝完一杯咖啡的时间(不超过5分钟)内完成构建,将是一个理想状态。否则,则会减慢开发人员的生产力。

本篇文章带大家通过两个小的改变,来提升Docker的构建时间。

Docker最佳实践

在讲解改变之前,首先要确保遵循了编写Dockerfile的最佳实践:

  • 容器应该是短暂的;
  • 镜像层数尽可能少;
  • 使用多阶段构建;
  • 使用最小的基础镜像;
  • 避免安装不必要的包;
  • 一个容器只运行一个进程;
  • 将多行参数排序;
  • 构建缓存;
  • ...

Buildkit

Buildkit是改进后的后端,用于替代传统的Docker构建器。自2018年起,它已经与Docker捆绑在一起,并成为Docker引擎23.0版本的默认构建器。

它提供了一些特殊的功能:

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

使用Buildkit时,会发现docker build命令的输出看起来更清晰、更结构化。

在Docker版本低于23.0时,使用Buildkit的一种典型方法是设置Buildkit参数如下:

ini 复制代码
DOCKER_BUILDKIT=1 docker build --platform linux/amd64 . -t someImage:someVersion
DOCKER_BUILDKIT=1 docker push someImage:someVersion

Buildx

Buildx是Docker的一个插件,能够充分利用Docker中的Buildkit的潜力。它的创建是因为Buildkit支持许多新的配置选项,不能全部以向后兼容的方式集成到docker build命令中。

除了构建镜像之外,Buildx还支持管理多个构建器。这在CI中非常有用,可以定义具有不同配置的作用域环境,因为它们不会修改共享的Docker守护程序。

可以按照以下方式开始使用Buildx:

css 复制代码
docker buildx create --bootstrap --name builder
docker buildx use builder

远程缓存

加快构建速度的第一种方法是将镜像缓存在远程注册表中。这样,即使构建在不同的机器上执行(通常在CI中会这样),也可以从构建缓存中受益。

作为一种解决方法,许多人在构建新的镜像版本之前拉取了最新版本的镜像。好处是可以以拉取完整镜像的代价来缓存未更改的层。拉取完整镜像可能需要一些时间,但也不能保证层可以被重用。

为了说明这一点,可以使用以下命令:

diff 复制代码
docker pull someImage:latest || true
docker build --platform linux/amd64 . \
-t someImage:someVersion \
-f Dockerfile \
--cache-from someImage:latest

使用Buildx,可以将缓存信息存储在远程位置(例如容器注册表、Blob存储等)中。构建器将检查给定的层是否已经存在,如果存在,则会重新使用它,而不是再次创建它。

甚至可以在不将层拉取到本地的情况下完成此操作。为了能够从此机制中受益,我们对先前的命令进行了改进:

ini 复制代码
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"模式,它仅存储关于最终镜像中存在的层的构建信息。

缓存的一个特殊情况是将缓存数据"内联"存储,这意味着它将与镜像一起被缓存。即使在不使用Buildx的情况下使用Buildkit时,该选项也是支持的。它是最容易使用的方法,但在使用多阶段构建时更加棘手,并且它不能清晰地区分输出的工件和缓存。

将缓存数据"内联"存储的命令如下所示:

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

添加文件到Docker镜像的新方法

Docker引入了一种新版本的语法来编写Dockerfile,即:#syntax=docker/dockerfile:1.4。它为COPY和ADD命令提供了额外的链接选项。

以前,当使用COPY或ADD命令时,构建器会创建一个新的快照,将新文件与已存在的文件系统合并。结果是,在执行此操作之前,所有父层都需要存在,否则目标目录可能尚不存在。

最终,镜像(构建命令的结果)将由每个层的tarball组成,其中包含各个快照之间的差异。

sql 复制代码
FROM baseImage:version
COPY binary /opt/

使用链接选项时,新文件将放置在它们自己的快照中,而不依赖于先前的层。链接的文件存储在它们自己的tarball中,并且不依赖于现有的文件系统,如下图所示。

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

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

此外,这也可以提高构建速度,因为现在可以并行执行多个层的数据复制。

小论

本文介绍了两种小的改变,可以让整个Docker构建时间大幅缩减的方法,希望在实践的过程中对大家有所帮助。这两个小改变分别是:

  • 将构建缓存信息存储在远程位置;
  • 在将文件添加、复制到docker镜像时使用链接选项;

当然,在使用Docker时,关于Dockerfile编写的最佳实践,大家也要留意一下。

相关推荐
Anna_Tong3 小时前
云原生大数据计算服务 MaxCompute 是什么?
大数据·阿里云·云原生·maxcompute·odps
豆豆豆豆变3 小时前
Docker轻量级可视化工具Portainer
docker·容器·自动化运维
花晓木3 小时前
k8s etcd 数据损坏处理方式
容器·kubernetes·etcd
运维&陈同学3 小时前
【模块一】kubernetes容器编排进阶实战之基于velero及minio实现etcd数据备份与恢复
数据库·后端·云原生·容器·kubernetes·etcd·minio·velero
花晓木3 小时前
k8s备份 ETCD , 使用velero工具进行备份
容器·kubernetes·etcd
大熊程序猿3 小时前
xxl-job docker 安装
运维·docker·容器
shelby_loo3 小时前
使用 Docker 在 Ubuntu 下部署 Cloudflared Tunnel 服务器
服务器·ubuntu·docker
咏颜4 小时前
Ubuntu离线安装Docker容器
linux·运维·服务器·经验分享·ubuntu·docker
liuxuzxx6 小时前
Istio-2:流量治理之简单负载均衡
云原生·kubernetes·istio
怡雪~6 小时前
Kubernetes使用Ceph存储
ceph·容器·kubernetes