今天来介绍一个 Docker build 很有用的特性：Multi-stage builds，即多阶段打包。

前言

这个特性很早之前，在 2017 年初的时候就可以使用了。如果你没有用到，很有可能你不需要编译语言，就比如 C/C++/Golang/Java 之类的语言。

现在网上有非常多的教程告诉我们，打包 Docker 镜像的时候，我们需要把镜像缩减到最小，因此我们可以看到最佳实践是类似于这样的：

1
2
3
4
5
6
RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    && rm -rf /var/lib/apt/lists/*

又或者这样的：

1
2
RUN npm install --production \
    && rm -rf $HOME/.npm

还有这样的：

1
RUN pip install -r requirements --no-cache-dir

这些技巧的目的都在于把改动的内容缩减到最小，因为没必要把缓存之类的内容也放到镜像中去，这样就可以把镜像尽可能缩小。

而今天介绍的 Multi-Stage builds 就是达到这个目的的另一个重要手段。

很早之前

对于编译型的语言，我们可能需要编译完成后，将依赖与编译好的二进制文件（artifacts，即制品）拷贝到一个新的小镜像中来进行打包了，比如我们会把镜像的打包过程放到 CI 中去，大概的内容包括：

  1. 测试
    1. 安装测试依赖
    2. 静态检查
    3. 单元测试
  2. 编译
    1. 安装编译依赖
    2. 编译
  3. 打包镜像
    1. 安装依赖
    2. 将编译制品拷贝到空镜像
    3. 将镜像推送到镜像库中

我们可以看到，编译与打包的步骤需要分开，因为我们需要：

  1. 解耦，简化整体的过程；
  2. 两者如果是基于不同 CI 运行镜像的话，我们还需要用到不同的镜像；
  3. 需要用到 CI 提供的并行执行能力；

于是我们的问题出现了：如何将编译制品传送至打包步骤？用缓存是比较简单的，但是需要保证缓存只能被当前的编译步骤使用，不然会导致编译的版本错误。

Gitlab 提供的 dependencies 也能做到这一点，自动将你制定步骤的 artifacts 下载下来，只不过这样的步骤会显得多余：有时候你只是想用来打包镜像而已，而如果 artifacts 上传至 Gitlab 服务器，还有那缓慢速度的限制，拖慢整体打包步骤。

所以，我们的救星来了，Multi-stage builds。

现在

现在这个步骤就很简单了，它允许你把所有的步骤放到一个 Dockerfile 中去完成，拿官网1, 2上的例子来说：

1
2
3
4
5
6
7
8
9
10
11
FROM golang:1.7.3 AS builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

它将我之前说的 CI 编译与打包步骤合并了，可以注意到的是它有两个 FROM 关键字，这就是这个多阶段的关键所在了，它允许多个 FROM 来达到多阶段的目的，并且，最后一个 FROM 才是你真正的打包步骤，利用这个特性，你可以将最后打包完成的镜像做到最小。

这样还有一个好处，你可以更方便地迁移到其它 CI 平台了，毕竟两个步骤合并成一个了。

另外，这样的改变，在不注意的情况下，会让你的编译过程变慢，因为没有缓存。

解决方案也是有的，就是官网上说的是 Stop at a specific build stage，我们在编译的时候，需要多加一行镜像编译命令，就拿上面的例子来说：

1
2
docker build -t . example-registry.com/app:latest
docker push example-registry.com/app:latest

我们可以利用 --target 以及 --cache-from 来实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 将最新已有的 builder 镜像拉下来
docker pull example-registry.com/app:builder || true

# --cache-from 就是关键了，它就可以复用缓存了
# 另外还有个 --target 即告诉 docker 
# 只要编译到 builder 这个就停止，这样可以把缓存保留下来
docker build \
    --cache-from=example-registry.com/app:builder \
    --target builder \
    -t example-registry.com/app:builder \
    .

# 将最新已有的镜像拉下来
docker pull example-registry.com/app:latest || true
docker build \
    --cache-from=example-registry.com/app:builder \
    --cache-from=example-registry.com/app:latest \
    -t example-registry.com/app:latest \
    .

# 将最新的镜像以及 builder 镜像推送至远程
docker push example-registry.com/app:latest
docker push example-registry.com/app:builder

Ref

  1. Builder pattern vs. Multi-stage builds in Docker
  2. Use multi-stage builds
  3. Caching Docker layers on serverless build hosts with multi-stage builds, —target, and —cache-from

首发于 Github issues: https://github.com/xizhibei/blog/issues/124 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/zh-cn/2019/11/04/use-docker-multi-stage-builds/