构建安全可靠、最小化的 Docker 镜像
构建镜像
手动构建 Docker 镜像的流程图，如下：
现在依次按照流程采用命令行的方式手动构建一个简单的 Docker 镜像。
创建容器并增加文件
取 BusyBox 作为本次试验的基础镜像，因为它足够小，大小才 1.21MB。
$: docker run -it busybox:latest sh
/ # touch /newfile
/ # exit通过以上的操作，我们完成了流程图的前三步。创建了一个新容器，并在该容器上创建了一个新问题。只是，我们退出容器后，容器也不见了。当然容器不见了，并不表示容器不存在了，Docker 已经自动保存了该容器。如果在创建时，未显示设置容器名称，可以通过以下方式查找该消失的容器。
# 列出最近创建的容器
$: docker container ls -l
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c028c091f964 busybox:latest "sh" 13 minutes ago Exited (0) 27 seconds ago upbeat_cohen
# 查询容器的详情
$: docker container inspect c028c091f964
...提交变更生成镜像
手动构建镜像，很简单。先找到发生变更的容器对象，对其变更进行提交。提交完成后，镜像也就生成了。不过此时的镜像只有一个自动生成的序列号唯一标识它。为了方便镜像的检索，需要对镜像进行命名以及标签化处理。
命令行操作如下：
# 提交变更, 构建镜像完成
$: docker commit -a JayL -m "add newfile" c028c091f964
sha256:01603f50694eb62e965e85cae2e2327240e4a68861bd0e98a4fb4ee27b403e6d
# 对镜像进行命名, 原镜像ID取前几位就可以了
$: docker image tag 01603f50694eb62e9 busybox:manual
# 验证新镜像
$: docker run busybox:manual ls -al newfile
-rw-r--r-- 1 root root 0 Jun 15 05:25 newfile通过以上两步过程就完成了 Docker 镜像手动创建。非常简单是不是。但是也非常麻烦，必须先创建新容器在提交变更，生成镜像。整个过程完全可以通过脚本化处理，这也是下节要说的，自动化构建 Docker 镜像。
自动化构建
Dockerfile 构建
自动化构建 Docker 镜像，Docker 公司提供的不是 SHELL 脚本的方式，而是通过定义一套独立的语法来描述整个构建过程，通过该语法编辑的文件，称为 Dockerfile。自动化构建镜像就是通过编写 Dockerfile 文件构建的。
同样完成上面的工作，用 Dockerfile 写出来就是：
FROM busybox:latest
RUN touch /newfile至于更加详细的 Dockerfile 语法，请查看官方指南。
完成 Dockerfile 编写后，通过命令触发构建。整个过程，脚本化出来就是：
$: mkdir autobuild && cd autobuild
$: cat < Dockerfile
FROM busybox:latest
RUN touch /newfile
EOF
$: docker build -t busybox:autobuild . 镜像的存储
Docker 镜像是由一组只读的镜像层 Image Layer 组成的。而 Docker 容器则是在 Docker 镜像的基础之上，增加了一层：容器层 Container Layer。容器层 Container Layer是可读写的。如果对该容器层 Container Layer 进行 commit 提交操作，该层就变成了新的镜像层 Image Layer。新的 Docker Image 也就构建出来了。
$: mkdir layer && cd layer && touch newfile
$: cat < Dockerfile
FROM scratch
ADD newfile .
EOF
$: docker build -t layer . 以下官网提供的图示可以很清楚的看出镜像与容器之间的联系与区别：
具体某个镜像的组成 Layer 可以通过如下命令进行查询：
# 镜像的构建层历史
$: docker history busybox:autobuild
IMAGE CREATED CREATED BY SIZE COMMENT
845cc5130d2c 17 minutes ago /bin/sh -c touch /newfile 0B
ef46e0caa533 4 days ago /bin/sh -c #(nop) CMD ["sh"] 0B
4 days ago /bin/sh -c #(nop) ADD file:1067e5a... in / 1.21MB 不难看出，镜像 busybox:autobuild 一共执行了从底往上的三次层构建。具体构建的指令可以通过第三列的命令得出。的意思是：该层是在其它系统上构建的，在本地是不可用的。只需要忽略就好。
Union FileSystem
要了解 Docker 镜像的存储首先必须了解联合文件系统 UnionFS（Union File System），所谓 UnionFS 就是把不同物理位置的目录合并 mount 到同一个目录中。UnionFS 的具体实现有很多种：
早期的UFS
AUFS
OverlayFS
overlay
overlay2
具体 Docker 宿主机上使用那种 UnionFS 文件系统驱动，可以通过如下命令查询：
$: docker info | grep Storage
Storage Driver: overlay2overlay2 是一种更现代的联合文件系统 UnionFS，它比 overlay 的早期版本在稳定与性能上都有很大提升。所以一般最新的 Docker 采用的存储驱动使用的都是 overlay2。
为了方便演示 UnionFS 文件系统，如果是 MacOS 系统，建议安装 Docker Machine 开启一台新的虚拟机操作，排除因为 Docker for MacOS 运行在虚拟机上的各种环境干扰。具体 Docker Machine 的安装请自行查阅相关文档。
首先创建一台新的Docker Machine：
# 创建
$: docker-machine create ufs
...
Docker is up and running!
# 登录
$: docker-machine ssh ufs
... ok
# 查询 overlay
$: cat /proc/filesystems | grep overlay
nodev overlay通过确认，这台 Docker Machine 是支持 UnionFS 文件系统的，使用的是overlay 存储驱动。既然 UnionFS 就是把不同物理位置的目录合并 mount 到同一个目录中.现在我们通过命令行的方式实现一下 Docker 官网提供 UnionFS 的原理图。
从图中可以看出，我们需要提供两个目录，分别代表 Container Layer 和 Image Layer。目录名称，取图示右部的名称：
目录 upper， 代表 Container Layer
目录 lower， 代表 Image Layer
除了这两个目录以外，通过 UnionFS 挂载目录还需要两个目录：
目录 merged，代表挂载目录，即合并后的目录
目录 work，必须为空目录，是 overlay 存储驱动挂载所需的工作目录
通过命令行实现图示中的文件夹结构：
# 创建一个测试目录
$: mkdir demo && cd demo
# 创建子目录与文件
$: mkdir upper lower merged work
$: touch lower/file1 lower/file2 lower/file3
$: touch upper/file2 upper/file4
# 通过文件内容区分以下file2
$: echo lower > lower/file2
$: echo upper > upper/file2
# 未挂载
$: ls merged迄今为止，一切都是常规文件系统操作。现在通过 mount 命令进行 UnionFS 文件系统的目录挂载。
# 目录合并挂载到merged
$: sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged
# 挂载完成后
$: ls merged
file1 file2 file3 file4
# file2 使用的是顶层 upper 的file2 文件
$: cat merged/file2
upper下面再分别通过文件的增删改加深对 UnionFS 文件系统的理解：
新增文件：
# 新增文件
$: touch merges/file5
$: ls merged/
file1 file2 file3 file4 file5
# 新增文件写在顶层的 upper 文件夹
$: ls upper/
file2 file4 file5
$: ls lower/
file1 file2 file3修改文件：
# 修改文件 CoW 技术
$: echo mod > merged/file1
$: ls upper/
file1 file2 file4 file5
$: cat upper/file1
mod
$: cat lower/file1删除文件：
# 删除文件
$: rm merged/file1
$: ls -al upper | grep file1
c--------- 1 root root 0, 0 Jun 17 10:41 file1
$: ls -al lower | grep file1
-rw-r--r-- 1 docker staff 0 Jun 17 10:15 file1实际操作完成以上过程，相信你对于 UnionFS 文件系统有了更加直观的感受。你可能会问， Docker Image 的底层镜像是由一组 Layer 组成的，多个底层目录在 UnionFS 中如何挂载？其实很简单，只需要通过分隔即可。
# 多层目录: lower1 / lower2 / lower3
$: sudo mount -t overlay overlay -olowerdir=lower1:lower2:lower3,upperdir=upper,workdir=work merged挂载完成后，lower1 / lower2 / lower3之间的层叠顺序又是怎样，读者可以自行测试一下。
最后，我们查询一下系统的挂载列表。
mount | grep overlay
overlay on /home/docker/demo/merged type overlay (rw,relatime,lowerdir=lower,upperdir=upper,workdir=work)从现有输出可知目前我们 docker-machine 中仅挂载了一个 overlay 目录。
镜像的存储
现在我们在这台新的 docker-machine 上构建一个上面章节中所描述的 Docker镜像：busybox:autobuild。
$: mkdir autobuild && cd autobuild
$: cat < Dockerfile
FROM busybox:latest
RUN touch /newfile
EOF
$: docker build -t busybox:autobuild .
# 完成构建后，现在系统中有两个docker image
$: docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox autobuild 2e32da74b3ad 4 seconds ago 1.22MB
busybox latest e4db68de4ff2 2 days ago 1.22MB 构建完成后，我们直接看一下 docker-machine 上的文件系统的挂载情况：
# docker 无容器运行
$: mount
...
/dev/sda1 on /mnt/sda1/var/lib/docker type ext4 (rw,relatime,data=ordered)
# docker 运行容器时
# 重新开启新会话，运行一个容器实例 `docker run -it busybox:autobuild sh`
$: mount
...
/dev/sda1 on /mnt/sda1/var/lib/docker type ext4 (rw,relatime,data=ordered)
overlay on /mnt/sda1/var/lib/docker/overlay2/a54541dd24971b9491a54b43cdf51f4ef9c87c1cd29748bb3fe64dedafd91b56/merged type overlay (rw,relatime,lowerdir=/mnt/sda1/var/lib/docker/overlay2/l/KLGL6INSJ2UBLMAUP5B4IORUTG:/mnt/sda1/var/lib/docker/overlay2/l/BGIT3WQZVII4Z2THF35I6T5V5O:/mnt/sda1/var/lib/docker/overlay2/l/6GZ2NT4UQT6EQK3IT4IGMBXU4T,upperdir=/mnt/sda1/var/lib/docker/overlay2/a54541dd24971b9491a54b43cdf51f4ef9c87c1cd29748bb3fe64dedafd91b56/diff,workdir=/mnt/sda1/var/lib/docker/overlay2/a54541dd24971b9491a54b43cdf51f4ef9c87c1cd29748bb3fe64dedafd91b56/work)
shm on /mnt/sda1/var/lib/docker/containers/e50f19c5bde3fe53cde3729de92f75b74323f7ebb506b0635eb76dd5b81e080a/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
nsfs on /var/run/docker/netns/3c464f8003e8 type nsfs (rw)对比输出，能够很明显的看到，暂仅关注 overlay 挂载情况。得出：
挂载后的目录是：/mnt/sda1/var/lib/docker/overlay2/a54541dd24971b9491a54b43cdf51f4ef9c87c1cd29748bb3fe64dedafd91b56/merged
容器 Layer 是：/mnt/sda1/var/lib/docker/overlay2/a54541dd24971b9491a54b43cdf51f4ef9c87c1cd29748bb3fe64dedafd91b56/diff
镜像 Layer 是：/mnt/sda1/var/lib/docker/overlay2/l/KLGL6INSJ2UBLMAUP5B4IORUTG /mnt/sda1/var/lib/docker/overlay2/l/BGIT3WQZVII4Z2THF35I6T5V5O /mnt/sda1/var/lib/docker/overlay2/l/6GZ2NT4UQT6EQK3IT4IGMBXU4T
其中镜像 Layer 使用的是软连接。同样的信息，我们可以通d ocker inspect 查询出来。
$: docker inspect -f '{{.GraphDriver.Data.MergedDir}}'
$: docker inspect -f '{{.GraphDriver.Data.UpperDir}}'
$: docker inspect -f '{{.GraphDriver.Data.LowerDir}}' 输出的路径就是具体 Docker 镜像的存储位置。
最小化 Docker 镜像
最小化 Docker 镜像的原因可总结出以下几条：
省钱，减少网络传输流量，节省镜像存储空间
省时，加速镜像部署时间
安全，有限功能降低被攻击的可能性
环保，垃圾都分类了，浪费资源可耻
如何构建最小化 Docker 镜像
按之前所讨论的镜像的组成原理与存储， 最小化 Docker 镜像的主要途径总结下来也就两条：
缩减镜像的Layer大小
减少镜像的Layer层数
减少镜像的 Layer 层数
组合命令
在定义 Dockerfile 的时候，每一条指令都会对应一个新的镜像层。通过 docker history 命令就可以查询出具体 Docker 镜像构建的层以及每层使用的指令。为了减少镜像的层数，在实际构建镜像时，通过使用&&连接命令的执行过程，将多个命令定义到一个构建指令中执行。如：
FROM debian:stable
WORKDIR /var/www
RUN apt-get update && \
apt-get -y --no-install-recommends install curl \
ca-certificates && \
apt-get purge -y curl \
ca-certificates && \
apt-get autoremove -y && \
apt-get clean压缩镜像层
除了通过将多命令通过&&连接到一个构建指令外，在 Docker 镜像的构建过程中，还可以通过 --squash 的方式，开启镜像层的压缩功能，将多个变化的镜像层，压缩成一个新的镜像层。
具体命令就如下：
$: docker build --squash -t . 缩减镜像的 Layer 大小
选择基础镜像
缩减 Layer 的大小需要从头开始，即选择什么样的基础镜像作为初始镜像。一般情况下，大家都会从以下三个基础镜像开始。
镜像 Scratch（空镜像），大小 0B
镜像 BusyBox（空镜像 + BusyBox），大小 1.4MB
镜像 alpine（空镜像 + BusyBox + apk），大小 3.98MB
镜像 BusyBox 通过 BusyBox 程序提供一些基础的 Linux 系统操作命令，镜像 alpine 则是在次基础上提供了 apk 包管理命令，方便安装各类工具及依赖包。广泛使用的镜像基本都是镜像 alpine。镜像 BusyBox 更适合一些快速的实验场景。而镜像 Scratch 空镜像，因为不提供任何辅助工具，对于不依赖任何第三方库的程序是合适的。因为镜像 Scratch 空镜像本身不提供任何 container OS，所以程序是运行在 Docker Host 即宿主机上的，只是利用了 Docker 技术提供的隔离技术而已。
细心的读者可能会发现，在 MacOS 上编译的程序，采用镜像 Scratch 空镜像时，容器运行会报错。那是因为，Docker for Mac 是运行在 Linux 虚拟机上的缘故。所以不可以直接构建 MacOS 格式的可执行程序在 Docker for Mac 上采用空镜像的方式运行。
多阶段构建镜像
多阶段构建 Multi-Stage Build 是 Docker 17.05 版本开始引入的新特性。通过将原先仅一个阶段构建的镜像查分成多个阶段。之所以多阶段构建镜像能够缩减镜像的大小，是因为发布程序在编译期相关的依赖包以及临时文件并不是最终发布镜像所需要的。通过划分不同的阶段，构建不同的镜像，最终镜像则取决于我们真正需要发布的实体是什么。
FROM golang:1.11-alpine3.7 AS builder
WORKDIR /app
COPY main.go .
RUN go build -o server .
FROM alpine:3.7
WORKDIR /app
COPY --from=builder /app .
CMD ["./server"]如上的 Dockerfile 就是多阶段构建，在 builder 阶段使用的基础镜像是 golang:1.11-alpine3.7，显然是因为编译期的需要，对于发布真正的server程序是完全没必要的。通过多阶段构建镜像的方式就可以仅仅打包需要的实体构成镜像。
除了多阶段构建以外，如果你还想忽略镜像中一些冗余文件，还可以通过 .dockerignore 的方式在文件中定义出来。功能和 .gitignore 类似。
加固 Docker 镜像
镜像内容可寻址标识符（CAIID）
镜像内容可寻址标识符（Content addressable image identifiers），可以对来源基础镜像内容进行校验，确保没有被第三方篡改。具体的操作方式，就是在构建自己镜像的同时，对基础镜像内容进行内容的 sha256 摘要值进行设置，防止在不知情的情况下被篡改。
首先，得出具体镜像的正确 sha256 摘要值。
# 通过命令查询出具体镜像的sha256摘要
$: docker inspect busybox:autobuild -f "{{.RepoDigests}}"
sha256:9b63a0eaaed5e677bb1e1b29c1a97268e6c9e6fee98b48badf0f168ae72a51dc再在 Dockerfile 定义时，设置基础镜像的 sha256 摘要值。
FROM busybox@sha256:9b63a0eaaed5e677bb1e1b29c1a97268e6c9e6fee98b48badf0f168ae72a51dc
...注意：镜像内容可寻址标识符的获取必须经过一次 push 或者 pull 操作，即在镜像注册服务上发布后，才可以通过以上 inspect 命令查询出结果。如果仅仅是本地的镜像，无法通过 inpect 命令获取。当然仅仅是本地使用的镜像，镜像内容可寻址标识符也是没必要的。
用户权限
容器一旦创建出来，其默认使用的用户是可以在镜像中进行设置的。通过设置必要的镜像默认用户，可以限制其在容器中的执行权限。在某种程度上也就进行提升了镜像的安全级别。不过，这需要根据具体的业务发布情况进行设置，常规情况下，基础镜像都还是 root 用户作为默认用户。
安全原则：构建镜像本身是为了特定的应用定制的，默认情况下应该尽可能的降低用户权限。
SUID 与 SGID 问题
除了镜像本身设置必要的默认用户以外，在镜像中，还会存在一类程序，即使是通过普通用户执行，但在运行时会以更高级别的权限执行。就是系统针对可执行文件与目录提供的 SUID 与 SGID 特殊权限。
通过对可执行文件设置 SUID 或 SGID 属性，原本执行命令的用户会切换成为命令的所有者或是所属组的权限进行执行。也就是提升了执行命令的权限。
在实际的镜像构建中，应该尽可能的避免此类权限提升造成的可能的漏洞。建议镜像构建时，扫描镜像内是否存在此类执行文件，如果存在尽可能的删除。删除命令可参考：
# 镜像构建过程中增加对特殊权限可执行文件的扫描并删除
RUN for i in $(find / -type f \( -perm +6000 -o -perm +2000 \)); \
do chmod ug-s $i; done审查 Docker 镜像
虽然我们可以通过 Docker 命令结合文件系统浏览的方式进行容器镜像的审查，但其过程需要人工参与，很难做到自动化，更别提将镜像审查集成到 CI 过程中了。但一个好的工具可以帮我们做到这点。
推荐一个非常棒的开源项目 dive（https://github.com/wagoodman/dive），具体安装请参考其项目页。它不但可以方便我们查询具体镜像层的详细信息，还可以作为CI持续集成过程中的镜像审查之用。使用它可以大大提升我们审查镜像的速度，并且可以将这个过程做成自动化。
该项目的具体动态操作图示如下：
如果作为镜像审查之后，可以进行如下命令操作：
$: CI=true dive
Fetching image... (this can take a while with large images)
Parsing image...
Analyzing image...
efficiency: 95.0863 %
wastedBytes: 671109 bytes (671 kB)
userWastedPercent: 8.2274 %
Run CI Validations...
Using default CI config
PASS: highestUserWastedPercent
SKIP: highestWastedBytes: rule disabled
PASS: lowestEfficiency 从输出信息可以得到很多有用的信息，集成的 CI 过程也就非常容易了。dive 本身就提供了 .dive-ci 作为项目的 CI 配置：
rules:
# If the efficiency is measured below X%, mark as failed.
# Expressed as a percentage between 0-1.
lowestEfficiency: 0.95
# If the amount of wasted space is at least X or larger than X, mark as failed.
# Expressed in B, KB, MB, and GB.
highestWastedBytes: 20MB
# If the amount of wasted space makes up for X% or more of the image, mark as failed.
# Note: the base image layer is NOT included in the total image size.
# Expressed as a percentage between 0-1; fails if the threshold is met or crossed.
highestUserWastedPercent: 0.20集成到CI中，增加以下命令即可：
$: CI=true dive 镜像审查和代码审查类似，是一件开始抵制，开始后就欲罢不能的事。这件事宜早不宜迟。对于企业与个人而言均百利而无一害。
总结
容器的构建，讲解了容器的手动构建与自动构建过程。
镜像的存储，讲解了镜像的分层结构以及UnionFS联合文件系统，以及镜像层在UnionFS上的实现。
最小化容器构建，讲解了为什么需要最小化镜像，同时如何进行最小化操作。
容器镜像的加固，容器镜像加固的具体方式。
容器镜像的审查，高质量的项目中容器镜像也需要向代码一样进行审查。
文中例子，均可以在 Linux 系统或 MacOS 系统中进行实际演练。通过具体的操作可以对加深具体概念的理解。
本文转载自：GitDiG.com，链接：https://www.gitdig.com/build-a-small-image/
基于Kubernetes的DevOps实战培训
