docker最佳实践-减小镜像体积

docker最佳实践系列介绍了容器使用的一些最佳实践，内容包括如何优化减少镜像的大小，如何提升构建速度（这在CICD中十分重要）， 如何管理镜像等。如果有需要的小伙伴，可以一起讨论学习。

当我们刚开始接触Docker，并尝试使用docker build构建镜像时，通常会构建出体积巨大的镜像。而事实上，我们可以通过一些技巧方法减小镜像的大小。 本片博文，我将介绍一些优化技巧，同时也会探讨如何在减小镜像大小和可调试性取舍。这些技巧可以分为两部分：第一部分是多阶段构建（multi-stage builds）， 正确使用多阶段构建能够极大减小构建物镜像的大小，同时还会解释静态链接（static link）和动态链接（dynamic link）之间的区别以及为什么我们需要了解它们； 第二部分是使用一些常见的基础镜像，这些基础镜像仅包含我们所需要的内容，而无需引入其他文件。

首先，我们通过Golang和C的两个Hello world程序去还原很多开发者第一次使用docker build所构建出镜像， 并且看看这些的镜像的大小。

下面是C的Hello world示例程序：

/* hello.c */
int main () {
  puts("Hello, world!");
  return 0;
}

通过以下的Dockerfile文件构建镜像：

FROM gcc
COPY hello.c .
RUN gcc -o hello hello.c
CMD ["./hello"]

可以发现一个简单的Hello World程序,最终构建出的镜像大小超过了1G。主要是由于我们使用了gcc基础镜像。 如果我们使用Ubuntu镜像，安装C编译器，然后编译程序，最终构建出镜像大小只有300MB，和第一次相比，减小了不少， 但这对于一个实际只有 12KB 的二进制文件来说，仍然大的难以接受。

➜  c-hello-world ls -l hello
-rwxr-xr-x  1 donggang  staff  12556  6 15 11:35 hello

同样，对于Golang程序：

package main

import "fmt"

func main () {
  fmt.Println("Hello, world!")
}

通过golang镜像构建的最终镜像大小超过了 800MB,而实际执行文件的大小只有 2MB。

➜  go-hello-world ls -l go-hello-world
-rwxr-xr-x  1 donggang  staff  2174056  6 15 11:40 go-hello-world

通过以上两个示例，我们急需一些方法来改善我们的构建以减小最终产物的体积。接下来， 我们通过一些方法将最终产物的大小缩小 99.8%（注意：这有时会我们调试程序带来很大问题)。

下面会通过不同的 tag 来标识优化后构建的镜像，如hello:gcc,hello:ubuntu,hello:thisweirdtrick, 这样通过docker image hello,可以方便比较镜像的大小。

多阶段构建

通常，我们首先是通过多阶段构建来减小镜像的大小，往往这也是最有效的方法。不过，我们需要注意，如果处理不当， 可能会造成构建的镜像无法运行。

多阶段构建的核心概念很简单：“我不要包括 C 或者 Go 的编译器和整个构建辅助工具，我仅仅想要可执行文件”。我们添加构建阶段来改造之前的C演示程序， 具体的Dockerfile文件如下：

FROM gcc AS mybuildstage
COPY hello.c .
RUN gcc -o hello hello.c
FROM ubuntu
COPY --from=mybuildstage hello .
CMD ["./hello"]

我们使用gcc作为基础镜像编译hello.c程序，这一阶段为编译阶段mybuildstage。然后，我们开始定义新的阶段执行阶段， 这个阶段使用ubuntu镜像,这个阶段我们将上个阶段的构建产物hello可执行文件复制到指定目录中，最终构建出的镜像只有64MB， 这减少了大约95%的大小：

➜  c-hello-world docker images c-hello
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
c-hello             gcc.ubuntu          d9492a009e98        23 minutes ago      73.9MB
c-hello             gcc                 db0206def0e6        27 minutes ago      1.19GB

通过多阶段构建，我们已经极大地优化了最终产物的大小。关于多阶段构建还有一些需要注意的点:

• 在声明构建阶段时，可以不显示使用As关键字。后续阶段我们可以使用数字（以 0 开始）从前面的阶段复制文件。在复杂的构建中， 显示定义名称便于后续的维护。

  COPY --from=mybuildstage hello . 
  COPY --from=0 hello .
  

• 使用经典镜像： 关于运行阶段的基础镜像的选择，我建议使用一些经典基础镜像，如 Centos，Debian，Fedora，Ubuntu 等， 你可能听过其他简化类型的镜像。

• COPY --from使用绝对路径：golang镜像默认工作目录是/go，所以我们需要从/go目录复制可执行文件。

  FROM golang
  COPY hello.go .
  RUN go build hello.go
  FROM ubuntu
  COPY --from=0 /go/hello .
  CMD ["./hello"]
  

使用Scratch镜像

回到之前Hello World示例程序，C版本大小16KB，Go版本是2MB，那么问题来了，我们可以获取同样大小的镜像吗？可不可以构建出一个镜像， 其中只包括最终的可执行文件呢？答案是肯定的，通过使用scratch作为运行阶段的基础镜像，注意scratch是一个虚拟镜像， 我们不可以直接拉取或运行它，因为它完全为空。我们按照下面示例修改Go的Dockerfile文件：

FROM golang
COPY hello.go .
RUN go build hello.go
FROM scratch
COPY --from=0 /go/hello .
CMD ["./hello"]

➜  go-hello-world docker images go-hello
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
go-hello            scratch             57ae1b48d6bb        47 seconds ago      2.01MB

构建完的最终镜像的大小只有2MB。同样执行成功。是不是什么时候都可以使用scratch作为运行阶段的基础镜像呢？ 当然不行，在使用scratch作为基础镜像时需要注意以下几点。

没有shell

scratch镜像没有shell，这意味着不能在Dockerfile中CMD使用字符串语法(RUN也是)：

FROM golang
COPY hello.go .
RUN go build hello.go
FROM scratch
COPY --from=0 /go/hello .
CMD ./hello

如果我们执行以上构建出的镜像，会提示以下错误：

➜  go-hello-world docker run go-hello:scratch.stringsyntax
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.

这是因为RUN,CMD中使用字符串语法，这些参数会传递给/bin/sh,CMD ./hello最终会执行/bin/sh -c "./hello"。 而scratch中没有shell。解决方法就是使用JSON语法，使用JSON语法时，Docker会直接执行而不是通过shell执行。

没有调试工具

因为scratch是空的，所以构建出的镜像不包含任何工具，如ls,ps,ping等，我们也就无法进入到该容器（docker exec）中。

严格意义上，我们仍然可以通过一些方法进行容器故障排错，我们可以使用docker cp从容器中获取文件，使用docker run –net container与网络堆栈进行交互， 以及使用像nsenter这样的工具。如果使用新版本kubernetes，也可以利用ephemeral container这一特性,

一种解决方法是使用busybox或者alpine作为基础镜像，这些镜像只有几MB大小，但提供一些方便调试的工具。

没有libc

这个问题往往很难解决，简单的Go Hello World能够使用scratch基础镜像执行，但是C Hello World和一些其他复杂的Go程序（使用net包，或者使用sqlite）, 往往不能成功执行，会产生如以下的报错：

standard_init_linux.go:211: exec user process caused "no such file or directory"

似乎是缺少了一些文件导致的，但是又没具体指出缺失了什么文件。其实这是因为缺失了必要动态库文件dynamic library， 程序编译成功运行时，需要使用一些库，如C Hello World中的puts。在90年代，通常使用静态链接的方式static linking， 这意味着程序使用的库将包含在最终的二进制文件中，在使用软盘分发程序和没有标准库的情况下，这种方式十分方便， 但是在linux分时系统流行后，这种无法共享公共库的方式很快不再流行。

如今大部分情况下，使用动态链接。使用动态链接编译的程序，最终二进制文件不包含具体的库，而只包含对依赖库的引用，例如一个程序需要libtrigonometry.so中的cos和sin和tan函数。 执行程序时，系统会查找该libtrigonometry.so并将其与程序一起加载，以便程序可以调用这些函数。使用动态链接往往有以下优点：

1. 节省存储资源，多个程序共享一个库；
2. 节省内存，多个程序运行内存调用同一片内存；
3. 维护方便，更新库时，无需重新编译程序；

有些人可能会说节省内存不是动态链接所带来的优点，而是共享库shared library。关于具体的细节大家可以参考具体文档。

回到上面的示例程序，默认情况C使用动态链接，使用某些包的Go程序也是如此，上述程序使用标准C库，该库位于libc.so.6文件中， 所以需要在镜像中包含该文件，C Hello World才能正常执行。而scratch镜像中，这个文件显然不存在，buysbox和alpine也不包含这个库， busybox没有包含标准C库，alpine使用的是另外版本。通常我们通过以下方式解决找不到库链接的问题。

使用静态链接

我们可以使用静态链接，这取决于我们具体使用的构建工具，如果使用gcc，可以通过-static实现静态链接：

gcc -o hello hello.c -static

最终构建的二进制文件大小760KB而不16KB,主要是嵌入的库文件导致镜像变大，但是运行镜像时，将不再会报错。

手动添加库文件

首先通过一些工具，可以得到程序正在使用哪些库（ldd，mac下使用otool）:

$ ldd hello
	linux-vdso.so.1 (0x00007ffdf8acb000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007ff897ef6000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007ff8980f7000)

我们可以看程序使用的具体哪些库以及路径，上面的例子中，唯一有意义的是libc.so.6库,linux-vdso.so.1与虚拟动态共享对象有关， 该机制主要用于加速某些系统调用，而ld-linux-x86-64.so.2则是动态链接器本身。

我们可以手动将上面所有的库文件添加到镜像中，也能成功执行。这种方式对于后续维护是灾难性的，同时对于大型的程序（GUI）, 通过这种方式，我们往往会力不从心。所以不推荐使用这种方式。

使用busybox:glibc之类的镜像

上述例子，我们可以通过busybox:glibc作为基础镜像，它只有5MB,这个镜像提供了GNU C Libray（glibc）， 这样可以使用动态链接，运行这些程序。

但是如果我们的程序还使用了其他库，仍然需要手动安装。

通过优化，我们最终将一个超过1GB的文件优化到只有几十KB:

• 使用gcc镜像： 1.14GB
• 多阶段构建，使用gcc和ubuntu镜像：64.2MB
• 静态链接，使用alpine： 6.5MB
• 动态链接，使用alpine： 5.6MB
• 静态链接，使用scratch：940KB
• 静态musl二进制文件，使用scratch： 94KB

优化镜像的同时，能够帮助我们更好的理解容器相关核心特性。依我个人的使用的总结经验，主要会从以下几个角度思考是否可以进行优化：

1. 是否可以使用多阶段优化；
2. 是否可以使用如scratch较小的镜像作为基础镜像；
3. 是否可以移除一些没有必要的层；
4. 是否可以合并某些层；

通常，追求最小的镜像并不等同于最佳实践，我们需要综合考虑后续可调试性以及使用成本。一般情况我会偏向使用scratch，alpine这类的镜像。 这类镜像很小的同时也提供了必要的工具和可拓展性。

1. 在学习Docker以及编写Dockerfile时，我们通过工具dive帮助我们分析镜像的结构，方便后续优化