镜像的优化技巧
上面介绍了什么是镜像、镜像的存储方式以及Dockerfile和镜像、镜像和容器之间关系，这节主要介绍我们在制作镜像的时候有哪些技巧可以优化镜像。
Docker镜像构建通过docker build命令触发，docker build会根据Dockerfile文件中的指令构建Docker镜像，最终的Docker镜像是由Dockerfile中的命令所表示的层叠加起来的，所以从Dockerfile的制作到镜像的制作这一系列之间都有可以优化和注意的地方。
镜像优化可以分两个方向：
- 优化镜像体积
- 优化构建速度
优化镜像体积
优化镜像体积主要就是从制作Dockerfile的时候需要考虑的事情。
上面以及介绍过镜像是分层存储的，每个镜像都会有一个父镜像，新的镜像都是在父镜像的基础之上构建出来的，比如下面的Dockerfile。
FROM ubuntu:latest ADD run.sh / VOLUME /data CMD ["./run.sh"]
这段Dockerfile的父镜像是ubuntu:latest，在它的基础之上添加脚本然后组成新的镜像。
所以在优化体积方面，可以从以下几个方面进行考虑。
（1）选择尽可能小的基础镜像
在Docker hub上的同一个基础镜像会存在多个版本，如果可以，我建议你使用alpine版本，这个版本的镜像是经过许多优化，减少了很多不必要的包，节约了体积。这里就以常用的openjdk镜像为例，简单看一下它们的大小差别。
首先在Docker hub上可以看到openjdk:17-jdk和openjdk:17-jdk-alpine的镜像大小，如下：
可以看到同一个版本alpine版本的镜像比正常的版本小50MB左右，所以用这两个做基础镜像构建出来的镜像大小也会有差别。
但是是不是所有基础镜像都选alpine版本呢？
不是的，alpine镜像也会有很多坑，比如。
- 使用alpine版本镜像容易出错，因为这个版本镜像经过了大量的精简优化，很多依赖库都没有，如果程序需要依赖动态链接库就容易报错，比如Go中的cgo调用。
- 域名解析行为跟 glibc 有差异，Alpine 镜像的底层库是 musl libc，域名解析行为跟标准 glibc 有差异，需要特殊作一些修复配置，并且有部分选项在 resolv.conf 中配置不支持。
- 运行 bash 脚本不兼容，因为没有内置 bash，所以运行 bash 的 shell 脚本会不兼容。
所以使用alpine镜像也需要好好斟酌一下，在实际应用中，如果要使用alpine镜像，最好在其上做一些初始化，把需要的依赖、库、命令等先封装进去制作成新的基础镜像，其他应用再以这个基础镜像为父镜像进行操作。
（2）镜像层数尽量少
上面说过镜像是分层存储的，如果上层需要修改下层的文件需要使用写时复制机制，而且下层的文件依然存在并不会消失，如果层数越多，镜像的体积相应的也会越大。
比如下面的Dockerfile。
FROM ubuntu:latest RUN apt update RUN apt install git -y RUN apt install curl -y ADD run.sh / CMD ["./run.sh"]
这个Dockerfile能跑起来吗？完全没问题，但是这样写是不是就会导致镜像的层数非常多？
抛开父镜像ubuntu:latest本身的层不说，上面的Dockerfile足足增加了5层。在Dockerfile中是支持命令的合并的，我们可以把上面的Dockerfile改成如下。
FROM ubuntu:latest RUN apt update && \ apt install git -y && \ apt install curl -y ADD run.sh / CMD ["./run.sh"]
这样一改，就把镜像的层数从5层降低至3层，而且整个逻辑并没有改变。
说明：在 Docker1.10 后有所改变，只有 RUN、COPY、ADD 指令会创建层，其他指令会创建临时的中间镜像，不会直接增加构建的镜像大小 。
（3）删除不必要的软件包
在制作镜像的时候，脑海中始终要想起一句话：镜像尽可能的保持精简。这样也有助于提高镜像的移植性。
比如下面的Dockerfile。
FROM ubuntu:latest COPY a.tar.gz /opt RUN cd /opt && \ tar xf a.tar.gz CMD ["./run.sh"]
在这个镜像中，我们从外部拷贝了一个压缩文件a.tar.gz，在解压过后我们并没有把这个原始包删除掉，它依然会占用着空间，我们可以把这个Dockerfile改成如下。
FROM ubuntu:latest COPY a.tar.gz /opt RUN cd /opt && \ tar xf a.tar.gz && \ rm -f a.tar.gz CMD ["./run.sh"]
这样不仅得到了我们想要的文件，也没有保留不必要的软件包。
（4）使用多阶段构建
这个不是必须。
为什么这么说呢？因为多阶段构建主要是为了解决编译环境留下的多余文件，使最终的镜像尽可能小。那为什么说不是必须呢，因为这种情况很多时候都会在做CI的时候给分开，编译是编译的步骤，构建是构建的步骤，所以我说不是必须。
但是这种思路是非常好的，可以通过一个Dockerfile将编译和构建都写进去，如下。
FROM golang AS build-env ADD . /go/src/app WORKDIR /go/src/app RUN go get -u -v github.com/kardianos/govendor RUN govendor sync RUN GOOS=linux GOARCH=386 go build -v -o /go/src/app/app-server FROM alpine RUN apk add -U tzdata RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime COPY --from=build-env /go/src/app/app-server /usr/local/bin/app-server EXPOSE 8080 CMD [ "app-server" ]
其主要是通过在Dockerfile中定义多个FROM基础镜像来实现多阶段，阶段之间可以通过索引或者别名来引用。
优化镜像体积就总结这4点，如果你有更多更好的方法，欢迎沟通交流。
优化构建速度
当制作好Dockerfile之后，就需要构建镜像了，很多时候看着构建的速度就着急，那有什么办法可以优化一下呢？这里从以下几个方面进行表述。
（1）优化网络速度
网络是万恶之源。比如许多人的基础镜像都是直接从docker hub上拉取，如果一台机器是第一次拉是非常缓慢的，这时候我们可以先把docker hub上的镜像放到本地私有仓库，这样在同一个网络环境中，拉取速度会比直接到docker hub上拉取快1万倍。
还有一个镜像分发技术，比如阿里的dragonfly，充分采用了p2p的思想，提高镜像的拉取分发速度。
（2）优化上下文
不知道你有没有注意到，当我们使用docker build构建镜像的时候，会发送一个上下文给Docker daemon，如下：
# docker build -t test:v1 . Sending build context to Docker daemon 11.26kB Step 1/2 : FROM ubuntu ......
原来在使用docker build构建镜像的时候，会把Dockerfile同级目录下的所有文件都发送给docker daemon，后续的操作都是在这个上下文中发生。
所以，如果你Dockerfile的同级目录存在很多不必要的文件，不仅会增加内存开销，还会拖慢整个构建速度，那有什么办法进行优化吗？
这里提供两种方法：
- 如果Dockerfile必须放在代码仓库的根目录，这时候可以在这个目录下添加一个
.dockerignore文件，在里面添加需要忽略的文件和文件夹，这样在发送上下文的时候就不会发送不必要的文件了。 - 重新创建一个新的目录放置Dockerfile，保持这个目录整洁干净。
（3）充分使用缓存
Docker镜像是分层存储的，在使用docker build构建镜像的时候会默认使用缓存，在构建镜像的时候，Docker都会先从缓存中去搜索要使用的镜像，而不是创建新的镜像，其规则是：从该基本镜像派生的所有子镜像，与已在缓存中的镜像进行比较，以查看是否其中一个是使用完全相同的指令构建的。如果不一样，则缓存失效，重新构建。
简单归纳就以下三个要素：
- 父镜像没有变化
- 构建的指令没有变化
- 添加的文件没有变化
只要满足这三个要素就会使用到缓存，加快构建速度。
上面从体积和效率上分别介绍了Docker镜像的优化和注意事项，如果严格按照这种思路进行镜像设计，你的镜像是能接受考验的，而且面试的时候也是能加分的。
镜像的安全管理
上面聊了那么多镜像相关的话题，最后再来说说镜像安全的问题。
镜像是容器的基石，是应用的载体。最终我们的镜像是为业务直接或者间接的提供服务，做过运维的同学应该都为自己的操作系统做过安全加固，镜像其实也需要。
这里不阐述操作系统加固方面的知识，仅仅只针对容器来说。
（1）保持镜像精简
精简不等于安全。
但是精简的镜像可以在一定程度上规避一些安全问题，都知道，一个操作系统中是会安装非常多的软件，这些软件每天都会暴露不同的漏洞，这些漏洞就会成为不怀好意之人的目标。我们可以把镜像看成是一个缩小版的操作系统，同理，镜像里面的软件越少，越精简，其漏洞暴露的风险就更低。
（2）使用非root用户
容器和虚拟机之间的一个关键区别是容器与主机共享内核。在默认情况下，Docker 容器运行在 root 用户下，这会导致泄露风险。因为如果容器遭到破坏，那么主机的 root 访问权限也会暴露。
所以我们在制作镜像的时候要使用非root用户，比如下面一个java服务：
FROM openjdk:8-jre-alpine RUN addgroup -g 1000 -S joker && \ adduser joker -D -G joker -u 1000 -s /bin/sh USER joker ADD --chown=joker springboot-helloworld.jar /home/joker/app.jar EXPOSE 8080 WORKDIR /home/joker CMD exec java -Djava.security.egd=file:/dev/./urandom -jar app.jar
（3）对镜像进行安全扫描
在容器注册中心运行安全扫描可以为我们带来额外的价值。除了存放镜像，镜像注册中心定期运行安全扫描可以帮助我们找出薄弱点。Docker 为官方镜像和托管在 Docker Cloud 的私有镜像提供了安全扫描。
当然还有其他的仓库也有集成安全扫描工具，比如Harbor新版本已经可以自定义镜像扫描规则，也可以定义拦截规则，可以有效的发现镜像漏洞。
（4）要时常去查看安全结果
大家有没有这种感觉，我加了很多东西，但是感觉不到？
我有时候就有这种感觉，比如我给某个应用加了监控，然后就不管了，以至于我根本不知道或者不在乎这个监控到底怎么样。
假如我们对镜像进行了安全扫描，安装了一些工具，一定要去查看每个安全结果，而不是扫了就完了。
总结
小小的镜像就有这么多道道，不看不知道，一看吓一跳。
本文主要从Docker镜像的概念说起，然后结合一些实际的场景进行对比分析阐述更深层次的实现过程，有助于帮助大家理解Docker镜像。
