详解容器镜像优化.docxVIP

对于刚接触容器的人来说，很容易被自己制作的Docker镜像大小所吓到，我只需要一个几MB的可执行文件而已，为何镜像的大小会达到1GB以上?下面将从两方面来进行镜像大小优化，一种是通过多阶段构建处理，一种是使用不同的基础镜像进行特定优化与精简。

1减少镜像大小

这部分着重介绍多阶段构建（multi-stagebuilds），因为这是镜像精简之路至关重要的一环。在这部分内容中，我会解释静态链接和动态链接的区别，它们对镜像带来的影响，以及如何避免那些不好的影响。

我们还是从helloworld的程序开始，用C语言实现如下：

然后为其编写Dockerfile，如下：

执行Dockerbuild-thello:gcc.进行构建后，发现镜像大小超过了1GB。因为该镜像包含了整个gcc镜像的内容。但其实编译好的代码可执行文件只有8.4KB，这显然不科学。

换个安装了C编译器的Ubuntu镜像看看，会得到一个大概300MB大小的镜像，缩小了3倍，但还是比8.4KB大太多了。

类似地，Go语言版本的helloworld会得到相同的结果：

使用基础镜像golang构建的镜像大小是800MB，而编译后的可执行文件只有2MB大小，看来这个起决定性因素的还是基础镜像，那我们如何减小呢？请采用多阶段构建的方法。

我们还是以C语言的来看看，要想大幅度减少镜像的大小，多阶段构建是必不可少的。多阶段构建的想法很简单：“我不想在最终的镜像中包含一堆C或Go编译器和整个编译工具链，我只要一个编译好的可执行文件！”。

多阶段构建可以由多个FROM指令识别，每一个FROM语句表示一个新的构建阶段，阶段名称可以用AS参数指定，例如：

这里使用基础镜像gcc来编译程序hello.c，然后启动一个新的构建阶段，它以ubuntu作为基础镜像，将可执行文件hello从上一阶段拷贝到最终的镜像中。最终的镜像大小是73.9MB，比之前的1.19GB减少了95%。

在声明构建阶段时，可以不必使用关键词AS，最终阶段拷贝文件时可以直接使用序号表示之前的构建阶段（从零开始）。也就是说，下面两行是等效的：

如果Dockerfile内容不是很复杂，构建阶段也不是很多，可以直接使用序号表示构建阶段。一旦Dockerfile变复杂了，构建阶段增多了，最好还是通过关键词AS为每个阶段命名，这样也便于后期维护。

细心的你，可能会发现上面以ubuntu为基础镜像还是大了些，能不能选择一个更小的镜像呢？当然可以，我们可以采用busybox或alpine镜像来替代该ubuntu镜像。

2精简策略

这部分将会针对不同的基础镜像进行精简，比如scratch,alpine,slim等，还可以从语言层面进行精简，会以golang语言为例进行分析。

2.1golang精简

Go语言程序编译时会将所有必须的依赖编译到二进制文件中，但也不能完全肯定它使用的是静态链接，因为Go的某些包是依赖系统标准库的，例如使用到DNS解析的包。只要代码中导入了这些包，编译的二进制文件就需要调用到某些系统库，为了这个需求，Go实现了一种机制叫cgo，以允许Go调用C代码，这样编译好的二进制文件就可以调用系统库。也就是说，如果Go程序使用了net包，就会生成一个动态的二进制文件，如果想让镜像能够正常工作，必须将需要的库文件复制到镜像中，或者直接使用busybox:glibc镜像。当然，你也可以禁止cgo，这样Go就不会使用系统库，使用内置的实现来替代系统库（例如使用内置的DNS解析器），这种情况下生成的二进制文件就是静态的。可以通过设置环境变量CGO_ENABLED=0来禁用cgo，例如：

由于编译生成的是静态二进制文件，因此可以直接跑在scratch镜像中（下面会介绍）。

当然，也可以不用完全禁用cgo，可以通过-tags参数指定需要使用的内建库，例如-tagsnetgo就表示使用内建的net包，不依赖系统库：

这样指定之后，如果导入的其他包都没有用到系统库，那么编译得到的就是静态二进制文件。也就是说，只要还有一个包用到了系统库，都会开启cgo，最后得到的就是动态二进制文件。要想一劳永逸，还是设置环境变量CGO_ENABLED=0吧。

2.2使用scratch镜像

scratch镜像很小，因为它基本上是空的，除了Docker给它额外添加的metadata（元数据：描述数据的数据）。它是一个虚拟镜像，不能被pull，也不能运行，因为它表示空！scratch镜像不可以直接从Docker官方拉取下来，但可以用以下命令构建这个scratch镜像：

从镜像大小可知，scratch镜像大小为0，scratch构建镜像时，可精简到只在scratch上面加一层代码生成的二进制可执行文件。可以用于构建busybox等超