1 为什么要做镜像优化?
1）随着我们对docker镜像的持续使用，在此过程中如果不加以注意并且优化，镜像的体积会越来越大，很多时候我们在使用docker部署应用时，会发现镜像的体积可能都会在1G以上。
2）镜像体积的增大，不单单会增加磁盘资源与网络资源的开销，也会影响应用的部署效率，使得应用的部署时间会越来越长。
因此，我们需要尽量减小镜像的体积，以加快部署效率、降低资源的开销，而对于镜像的优化，可以通过对dockerfile的优化来实现。
镜像的优化过程：
- 循序渐进
- 选择最精简的基础镜像
- 减少镜像的层数
- 清理镜像构建的中间产物
- 注意优化网络请求 尽量去用构建缓存
- 使用多阶段构建镜像
2 构建镜像的几个原则
2.1 镜像最小化原则
1）选择最精简的基础镜像。
选择体积最小的基础镜像可有效降低镜像体积。如：alpine、busybox等
2）清理镜像构建的中间产物
构建镜像的过程中，当dockerfile的指令执行完成后，删除镜像不需要用的的文件。比如，使用yum安装组件，最后可使用yum clean all镜像清理不需要的文件，或者使用系统rm命令删除不需要的源文件等。
3）减少镜像的层数
镜像是一个分层存储的文件，dockerfile中的每一条指令都会生成一个层，并且镜像对层数也是有一定数量的限制，当前镜像的层数最高是127层，如果不多加注意，将会导致镜像越来越臃肿。因此，可以通过合并dockerfile中可合并的指令，减少最终生成镜像的层数。
例如：在dockerfile中使用RUN执行shell命令的时候，可以用 " && " 将多条命令连接起来。
2.2 构建速度最快化原则
1）充分利用镜像构建缓存
我们可以利用构建的缓存来加快镜像构建速度，Docker构建默认会开启缓存，缓存生效有三个关键点：
- 镜像父层没有发生变化
- 构建指令不变
- 添加文件校验和一致
只要一个构建指令满足这三个条件，这一层镜像构建就不会再执行，它会直接利用之前构建的结果。
但是，如果某一层的镜像缓存失效之后，它之后的镜像层缓存都会失效。因此，我们应该把变化最少的部分放在Dockerfile的前面，这样可以充分利用镜像缓存；dockerfile中有可能导致缓存失效的命令WORKDIR、CMD、ENV、ADD等，像这些命令最好放到dockerfile文件的底部，以便在构建镜像过程中最大限度使用缓存。
2）删除构建目录中（默认：Dockerfile所在目录）不需要用的的文件
编写 .dockerignore 文件过滤构建过程中不必要的文件，或者创建单独的目录，并且目录中仅存在镜像构建过程中需要使用的文件。
要知道：
Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 Docker Remote API，而如 docker 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。因此，虽然表面上我们好像是在本机执行各种 docker 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。
也就是说，docker build 命令构建镜像，其实并非在本地构建，而是在服务端，也就是 Docker 引擎中构建的。构建镜像时，Docker需要先准备context ，将所有需要的文件收集到进程中。默认的context包含Dockerfile文件所在目录下的所有文件。如果，目录中存在大量不相关的文件，那么就会导致构建缓慢。（换句话说，docker build 默认在构建的时候，会把当前目录下的所有数据发送到docker引擎，因此会导致构建时间变长；但默认不会把当前文件夹的内容都打进镜像，也就是不会导致镜像体积变大）
.dockerignore示例如下：
比如在一个构建项目中，我们并不需要.env目录等内容。可以在.dockerignore文件中加入以下内容：
.env/
其实，.dockerignore 的作用和语法类似于 .gitignore，可以忽略一些不需要的文件，这样可以有效加快镜像构建时间。
2.3 注意优化网络请求
我们使用一些镜像源，或者在dockerfile中使用互联网上的url时，去用一些网络比较好的开源站点，这样可以节约时间、减少失败率。
3 dockerfile指令优化
点击这里，查看本节内容。
4 多阶段构建镜像
多阶段构建是一个新特性，需要 Docker 17.05 或更高版本的守护进程和客户端。对于优化 Dockerfiles 并使其易于阅读和维护来说，多阶段构建非常有用。
4.1 使用多阶段构建
对于多阶段构建，可以在 Dockerfile 中使用多个 FROM 语句。每个 FROM 指令都可以使用不同的基础镜像，并且它们都开始了构建的新阶段。你可以选择性地将工件从一个阶段复制到另一个阶段，并舍弃在最终镜像中您不想要的所有内容。
如下Dockerfile：
FROM golang:1.7.3
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=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]
最后面的 --from=0 参数，是指从前边的阶段中拷贝文件到当前阶段中（没有拷贝的东西默认都会被舍弃），Dockerfile中包含多个FROM语句时，0 代表第一个阶段。除了使用数字，我们还可以给阶段命名。
和以往一样运行 docker build即可：
$ docker build -t alexellis2/href-counter:latest .
思考下：它是如何工作的？
第二个 FROM 指令用 alpine:latest 镜像作为基础镜像，开始一个新的构建阶段。COPY --from=0 行，只将前一阶段的构建工件复制到这个新阶段。第一阶段中的Go SDK 和任何中间工件都会被抛弃，不会保存到最终的镜像中。
4.2 为构建阶段命名
默认情况下，如果我们没有对阶段进行命名，那么可以通过它们的整数来引用它们（比如通过 --from=0 来引用第一个阶段），FROM 指令的第一个整数从 0 开始。另外，你可以通过添加一个 AS < NAME > 到 FROM 指令来给该阶段进行命名。下面示例通过命名阶段并在 COPY 指令中使用名称改进了前面一个示例。这意味着，即使 Dockerfile 中的各阶段被重新排序，COPY 也不会破坏。
改进后的Dockerfile：
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"]
4.3 在特定的构建阶段停止
在构建映像时，不必构建包括每个阶段的整个 Dockerfile。你可以指定目标构建阶段。以下命令假设你正在使用之前的 Dockerfile，但是在名为 builder 的阶段停止：
docker build --target builder -t alexellis2/href-counter:latest .
这可能非常强有力的几个场景是：
- 调试一个特定的构建阶段；
- 使用一个测试（testing）阶段，在这个阶段你的应用会被测试数据填充，但是在构建产品时，使用真实数据。
4.4 使用外部镜像作为“阶段”
当使用多阶段构建时，您不受限于从 Dockerfile 中先前创建的阶段进行复制。您可以使用 COPY --from 指令从单独的镜像中进行复制，可以使用本地镜像名称、本地或 Docker 注册表上可用的标签或标签 ID。Docker 客户端会在必要时拉取镜像并从中复制工件。语法是：
COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
4.5 把以前的阶段作为新的阶段
在使用 FROM 指令时，您可以引用前一阶段的内容。例如：
FROM alpine:latest as builder
RUN apk --no-cache add build-baseFROM builder as build1
COPY source1.cpp source.cpp
RUN g++ -o /binary source.cpp
)
