第5章　配置管理——让一切井然有序

本章主要内容

• 使用Dockerfile管理镜像的构建
• 使用传统的配置管理工具来构建镜像
• 管理构建镜像时所需的私密信息
• 缩减镜像的大小，以便更快、更轻量、更安全地交付

配置管理是一门管理运行时环境的艺术，从而使其稳定且可以预测。像Chef和Puppet这样的工具致力于减轻系统管理员维护多台机器的负担。就一定程度而言，Docker带来的软件环境的隔离性和可移植性同样也减轻了这一负担。即便如此，依然需要用配置管理技术来产出Docker镜像，而这也是一个值得关注的重要领域。

随着对Docker的不断了解，这些技巧将为读者提供更多工具来构建镜像以实现想要满足的任何配置需求。

5.1　配置管理和Dockerfile

Dockerfile被认为是构建Docker镜像的标准方式。人们常常会疑惑Dockerfile对于配置管理意味着什么。读者也可能会有许多疑问（尤其是在对一些其他配置管理工具有些经验的时候），例如：

• 如果基础镜像更改会发生什么？
• 如果更改要安装的包然后重新构建会发生什么？
• 它会取代Chef/Puppet/Ansible吗？

事实上，Dockerfile很简单：从给定的镜像开始，Dockerfile为Docker指定一系列的shell命令和元指令，从而产出最终所需的镜像。

Dockerfile提供了一个普通、简单和通用的语言来配置Docker镜像。使用Dockerfile，用户可以使用任何偏好的方式来达到所期望的最终状态。用户可以调用Puppet，可以从其他脚本里复制，甚至可以从一个完整的文件系统复制！

让我们先一起考虑一下如何处理Dockerfile带来的一些小挑战，然后再来讨论我们刚提到的更棘手的那些问题。

技巧40　使用ENTRYPOINT创建可靠的定制工具

Docker允许在任何地方执行命令的潜质意味着在命令行上运行的一些复杂的定制指令或者脚本可以预先配置然后包装到一个打包好的工具。

容易被曲解的ENTRYPOINT指令便是这其中的一个重要部分。读者将会看到它是怎样创建出封装良好、清晰定义以及足够灵活和有价值的Docker镜像来作为工具的。

问题

想要定义容器将会执行的命令，但是将命令的具体参数留给用户。

解决方案

使用Dockerfile的ENTRYPOINT指令。

讨论

作为演示，不妨试想一下企业里有一个这样的简单场景，有一个常规的管理任务是要清理旧的日志文件。通常这很容易出错，人们可能会意外删错东西，因此我们打算使用一个Docker镜像来降低出现问题的风险。

下列脚本（用户应该在保存的时候命名为clean_log）会删除超过特定天数的日志，其中具体天数作为一个命令行选项传入：

#!/bin/bash
echo “Cleaning logs over $1 days old”
find /log_dir -ctime “$1” -name ‘log’ -exec rm {} \;

FROM ubuntu:14.04
ADD clean_log /usr/bin/clean_log （1）
RUN chmod +x /usr/bin/clean_log （2）　　
ENTRYPOINT [“/usr/bin/clean_log”]
CMD [“7”] （3）

docker build -t log-cleaner .
docker run -v /var/log/myapplogs:/log_dir log-cleaner 365

$ docker run -ti log-cleaner /bin/bash
Cleaning logs over /bin/bash days old
find: invalid argument -name' to-ctime’

$ apt-cache show nginx | grep ^Version:
Version: 1.4.6-1ubuntu3

RUN apt-get -y install nginx=1.4.6-1ubuntu3

apt-cache —recurse depends nginx

$ docker run -ti dockerinpractice/get-versions vim
RUN apt-get install -y \
vim=2:7.4.052-1ubuntu3 vim-common=2:7.4.052-1ubuntu3 \
vim-runtime=2:7.4.052-1ubuntu3 libacl1:amd64=2.2.52-1 \
libc6:amd64=2.19-0ubuntu6.5 libc6:amd64=2.19-0ubuntu6.5 \
libgpm2:amd64=1.20.4-6.1 libpython2.7:amd64=2.7.6-8 \ 
libselinux1:amd64=2.2.2-1ubuntu0.1 libselinux1:amd64=2.2.2-1ubuntu0.1 \
libtinfo5:amd64=5.9+20140118-1ubuntu1 libattr1:amd64=1:2.4.47-1ubuntu1 \ 
libgcc1:amd64=1:4.9.1-0ubuntu1 libgcc1:amd64=1:4.9.1-0ubuntu1 \ 
libpython2.7-stdlib:amd64=2.7.6-8 zlib1g:amd64=1:1.2.8.dfsg-1ubuntu1 \ 
libpcre3:amd64=1:8.31-2ubuntu2 gcc-4.9-base:amd64=4.9.1-0ubuntu1 \ 
gcc-4.9-base:amd64=4.9.1-0ubuntu1 libpython2.7-minimal:amd64=2.7.6-8 \ 
mime-support=3.54ubuntu1.1 mime-support=3.54ubuntu1.1 \ 
libbz2-1.0:amd64=1.0.6-5 libdb5.3:amd64=5.3.28-3ubuntu3 \ 
libexpat1:amd64=2.1.0-4ubuntu1 libffi6:amd64=3.1~rc1+r3.0.13-12 \ 
libncursesw5:amd64=5.9+20140118-1ubuntu1 libreadline6:amd64=6.3-4ubuntu2 \ 
libsqlite3-0:amd64=3.8.2-1ubuntu2 libssl1.0.0:amd64=1.0.1f-1ubuntu2.8 \ 
libssl1.0.0:amd64=1.0.1f-1ubuntu2.8 readline-common=6.3-4ubuntu2 \ 
debconf=1.5.51ubuntu2 dpkg=1.17.5ubuntu5.3 dpkg=1.17.5ubuntu5.3 \ 
libnewt0.52:amd64=0.52.15-2ubuntu5 libslang2:amd64=2.2.4-15ubuntu1 \ 
vim=2:7.4.052-1ubuntu3

• 与sed -i不同（该命令具有类似的语法和效果），这一命令天然支持处理多个文件，即便遇到的问题是修改其中一个文件。这意味着可以在一个目录下加上‘‘通配符来执行该命令，便不用再担心在包的后续版本里添加目录时它会突然被破坏。
• 和sed一样，搜索和替换命令中的正斜杠可以使用其他字符替换。
• 它还很容易记忆（我们不妨称之为“perl pie”命令）。

假定有正则表达式的知识　本技巧假定读者对正则表达式有所了解。如果对正则表达式不熟悉的话，有很多网站可以帮到你。

下面是该命令的一个典型示例：

perl -p -i -e ‘s/127.0.0.1/0.0.0.0/g’ 

在这条命令里，-p标志要求perl循环处理看到的所有行，-i标志要求perl即时更新匹配的行内容，而-e标志则要求perl把传入的字符串当作一个perl程序处理。s是perl的一个指令，用来搜索和替换输入里匹配的字符串。这里的127.0.0.1会被替换成0.0.0.0。g修饰符则确保所有匹配都被更新，而不只是任何给定行里的第一个匹配。最后，星号（）会使这一文件夹下的所有文件都被更新。

上述命令对Docker容器而言完成的不过是一个很平常的操作。它会在使用一个地址来监听时，将标准的本地主机IP地址（127.0.0.1）替换成一个指示“任意”IPv4地址（0.0.0.0）。许多应用会通过仅监听本地主机地址限制成只有该IP地址才能访问，而通常用户会想要在它们的配置文件里将这一配置修改成“任意”地址，因为从宿主机上访问这些应用时，容器就变成了一台外部主机。

不能访问容器里的应用？　如果一个Docker容器里的应用，即使端口是打开的，用户仍然无法从宿主机上访问的话，不妨尝试一下在应用的配置文件里把监听的地址修改为0.0.0.0，并重启应用。这可能是应用拒绝访问所致，因为用户不是从本地主机访问它。在运行镜像时加上—net=host（后面技巧97会介绍到）可以帮助验证这一猜测。

perl -p -i -e（和sed）还有另外一个很不错的功能，那便是：如果有麻烦的字符转义问题，用户可以使用其他字符替换正斜杠符。下面是一个来自本书作者编写的脚本的真实示例，它在默认的Apache站点文件里添加了一些指令。

这条尴尬的命令

perl -p -i -e ‘s/\/usr\/share\/www/\/var\/www\/html/g’ /etc/apache2/ 

perl -p -i -e ‘s@/usr/share/www@/var/www/html/@g’ /etc/apache2/ 

在极少数情况下，用户要匹配或替换/和@字符的话可以尝试其他字符，如|或者#。

技巧43　镜像的扁平化

Dockerfile的设计以及它们产出Docker镜像的结果便是，最终镜像里包含了Dockerfile里每一步的数据状态。在构建镜像的过程中，可能需要复制私密信息来确保构建工作可以顺利进行。这些所谓的私密信息可能是SSH密钥、证书或者密码文件等。在提交镜像前删除这些私密信息的话可能不会提供任何实质性的保护，因为它们将出现在最终镜像的更高分层里，而恶意用户则可以轻松地从镜像中提取它们。解决这一问题的其中一个办法便是将得到的镜像扁平化。

问题

想要从镜像的分层历史中移除私密信息。

解决方案

基于该镜像创建一个容器，将它导出再导入，然后给它打上最初镜像ID的标签。

讨论

为了演示这种做法的可用场景，让我们在一个新目录里创建一个简单的Dockerfile，该目录下藏着一个大秘密。运行mkdir secrets && cd secrets，然后在该目录里创建一个包含如下内容的Dockerfile：

FROM debian
RUN echo “My Big Secret” >> /tmp/secret_key （1）
RUN cat /tmp/secret_key （2）　
RUN rm /tmp/secret_key （3）

（1）在构建里放置一个带有一些私密信息的文件

（2）对该私密文件做一些事情。当前这个Dockerfile只会列出该文件的内容，但是你的Dockerfile可能会SSH到其他服务器或者在镜像里加密该私密信息

（3）删除该私密文件

现在运行docker build -t mysecret .以构建该Dockerfile并给它打标签。

一旦它完成构建，可以通过docker history命令检查得到的Docker镜像的分层：

$ docker history mysecret （1）
IMAGE　　　　 CREATED　　　　 CREATED BY
➥ SIZE
55f3c131a35d 25 seconds ago　　/bin/sh -c rm /tmp/secret.key
➥ 0 B （2）
5b376ff3d7cd 26 seconds ago　　/bin/sh -c cat /tmp/secret_key
➥ 0 B
5e39caf7560f 27 seconds ago　　/bin/sh -c echo “My Big Secret” >> /tmp/secre
➥ 14 B （3）　　　　　　　　　　　　　 
c90d655b99b2 2 weeks ago　　　 /bin/sh -c #(nop) CMD [/bin/bash]
➥ 0 B
30d39e59ffe2 2 weeks ago　　　 /bin/sh -c #(nop) ADD file:3f1a40df75bc5673ce
➥ 85.01 MB　　　　　　　　　　　 
511136ea3c5a 20 months ago （4）
➥ 0 B （5）

（1）使用刚创建的镜像的名称运行docker history命令

（2）这一分层是删除密钥的地方

（3）这一分层是添加密钥的地方

（4）在这一分层添加了Debian文件系统。注意，该分层是历史记录里最大的一个

（5）最开始（空的）分层

现在试想一下用户从一个公开的注册中心下载了这一镜像。他可以检索镜像分层的历史然后运行如下命令列出私密信息：

$ docker run 5b376ff3d7cd cat /tmp/secret_key
My Big Secret

这里我们运行了一个特定的分层然后将它构造出来，cat我们在更高分层里已经删除的那个密钥的内容。正如所见，文件是可以访问的。

至此，用户有一个里面藏有秘密的“危险”容器，我们已经见证了的确可以“黑”到里面的私密信息。要让这个镜像变得安全，需要将该镜像扁平化处理。这意味着用户可以在该镜像里保留相同的数据但是会删除中间分层的信息。为了达成这一目的，需要将该镜像导出为一个简单运行的容器然后再重新导入并给得到的镜像打上标签：

$ docker run -d mysecret /bin/true　（1）
28cde380f0195b24b33e19e132e81a4f58d2f055a42fa8406e755b2ef283630f
$ docker export 28cde380f | docker import – mysecret （2）　　　　　　
$ docker history mysecret
IMAGE　　　　　　 CREATED　　　　 CREATED BY SIZE
fdbeae08751b 13 seconds ago　　　　　　　85.01 MB （3）

（1）运行一个简单的命令让容器可以快速退出，因为并不需要它处于运行状态

（2）运行docker export，把容器ID当作参数并输出文件系统的内容的一个TAR文件。这一操作被管道到docker import，它会以TAR文件的内容作为输入，基于这些内容创建一个镜像

（3）docker history的输出现在只显示最后那一组文件的分层

传给docker import命令的-参数指明用户想要从命令的标准输入读取TAR文件内容。docker import的最后一个参数指明该如何给导入的镜像打标签。在这个例子里它会覆盖之前的标签。

由于现在镜像里只有一个分层，因此就没有藏着秘密的分层记录。现在再也无法从镜像提取任何秘密了。

技巧44　用alien管理外来软件包

本书里（还有互联网上）绝大部分Dockerfile示例使用的都是基于Debian的镜像，而软件开发的现实决定了许多人不会专门做这些打包的事情。

好在有现成的工具可以帮助用户实现这一点。

问题

想要安装一个外来的发行版的软件包。

解决方案

使用一个基于alien的Docker镜像转换软件包。

讨论

alien是一款命令行工具，是专为转换不同格式的软件包文件设计的，如表5-1所示。我们不止一次遇到过需要让外来软件包管理系统下的软件包正常工作，例如，.deb用在centos中，.rpm文件用在非Red Hat系的系统。

表5-1　alien支持的包格式

不涉及Solaris包和Stampede包　出于本技巧的初衷，没有完全覆盖到Solaris包和Stampede包。Solaris要求安装Solaris特有的软件，而Stampede则是一个已经废弃的项目。

在本书的研究过程中我们发现，在非Debian系的发行版上安装alien可能会有些费劲儿。这是一本Docker书，我们自然决定以Docker镜像的形式提供一个转换工具。作为一个小福利，这一工具用到了技巧40中介绍的ENTRYPOINT命令，让用户可以更加便利地使用它。

举个例子，让我们来看看eatmydata这个软件包，在技巧56里会用到它：

$ mkdir tmp && cd tmp （1）
$ wget \ 
http://mirrors.kernel.org/ubuntu/pool/main/libe/libeatmydata/ 
➥ eatmydata_26-2_i386.deb （2）
$ docker run -v $(pwd):/io dockerinpractice/alienate （3）　　　　　　 
Examining eatmydata_26-2_i386.deb from /io
eatmydata_26-2_i386.deb appears to be a Debian package （4）
eatmydata-26-3.i386.rpm generated
eatmydata-26.slp generated
eatmydata-26.tgz generated
===================================================================
/io now contains:
eatmydata-26-3.i386.rpm
eatmydata-26.slp
eatmydata-26.tgz
eatmydata_26-2_i386.deb
===================================================================
$ ls –1 （5）　　　　　　　　　　 
eatmydata_26-2_i386.deb
eatmydata-26-3.i386.rpm
eatmydata-26.slp
eatmydata-26.tgz

（1）创建一个空的工作目录

（2）获取想要转换的包文件

（3）运行dockerinpractice/alienate镜像，将当前目录挂载到容器的/io路径下。容器会检查该目录，尝试转换找到的任意有效文件

（4）容器通知用户它运行Alien包装脚本时的行为

（5）文件已经被转换为RPM、Slackware tgz和Stampede文件

或者，也可以直接将URL传给docker run命令：

$ mkdir tmp && cd tmp
$ docker run -v $(pwd):/io dockerinpractice/alienate \
http://mirrors.kernel.org/ubuntu/pool/main/libe/
➥ libeatmydata/eatmydata_26-2_i386.deb
wgetting http://mirrors.kernel.org/ubuntu/pool/main/libe/
➥ libeatmydata/eatmydata_26-2_i386.deb
—2015-02-26 10:57:28— http://mirrors.kernel.org/ubuntu/pool/main/libe/ 
➥ libeatmydata/eatmydata_26-2_i386.deb
Resolving mirrors.kernel.org (mirrors.kernel.org)…
➥ 198.145.20.143, 149.20.37.36, 2001:4f8:4:6f:0:1994:3:14, …
Connecting to mirrors.kernel.org (mirrors.kernel.org)
➥ |198.145.20.143|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 7782 (7.6K) [application/octet-stream]
Saving to: ‘eatmydata_26-2_i386.deb’
　　 0K …….　　　　　　　　　　　　　　　　　　　　　　100% 2.58M=0.003s
2015-02-26 10:57:28 (2.58 MB/s) - ‘eatmydata_26-2_i386.deb’ saved [7782/7782]
Examining eatmydata_26-2_i386.deb from /io
eatmydata_26-2_i386.deb appears to be a Debian package
eatmydata-26-3.i386.rpm generated
eatmydata-26.slp generated
eatmydata-26.tgz generated ==================================================== 
/io now contains:
eatmydata-26-3.i386.rpm
eatmydata-26.slp
eatmydata-26.tgz
eatmydata_26-2_i386.deb ======================================================== 
$ ls -1
eatmydata_26-2_i386.deb
eatmydata-26-3.i386.rpm
eatmydata-26.slp
atmydata-26.tgz

如果想在自己的容器里运行alien，可以通过这个命令启动容器：

docker run -ti —entrypoint /bin/bash dockerinpractice/alienate

不确保一定奏效　alien这款工具的定位是“尽力而为”，它并不保证一定能够将提供的包转换成功。

技巧45　把镜像逆向工程得到Dockerfile

用户可能会发现自己遇到这样的场景：有人用一个Dockerfile创建了一个可以访问的镜像，但最初的Dockerfile却遗失了。我们发现自己不止一次遇到过这种情况。能恢复构建步骤相关信息可以避开冗长的自己重新探索的过程。

问题

有一个镜像，想要逆向工程得到最初的Dockerfile。

解决方案

使用docker history命令并通过查看分层的方式尝试确定更改过的地方。

讨论

尽管一个Docker镜像不是每次都能完全逆向工程，但是倘若它本质上是通过一个Dockerfile创建出来的，这会是一个很好的弄懂它是怎样装配到一起的机会（这是一个机会，很有希望借此按需重建镜像）。

在本技巧中我们打算采用如下Dockerfile作为示例。我们尽量用最少的步骤覆盖尽可能多的不同类型的指令。读者会去构建这个Dockerfile，然后运行一个简单的shell命令来了解这一技巧是如何工作的，最终我们会看一个更接近容器化的解决方案。

FROM busybox
MAINTAINER ian.miell@gmail.com
ENV myenvname myenvvalue
LABEL mylabelname mylabelvalue
WORKDIR /opt
RUN mkdir -p copied
COPY Dockerfile copied/Dockerfile
RUN mkdir -p added
ADD Dockerfile added/Dockerfile
RUN touch /tmp/afile
ADD Dockerfile /
EXPOSE 80
VOLUME /data
ONBUILD touch /tmp/built
ENTRYPOINT /bin/bash
CMD -r

LABEL指令可能无法工作　在编写本书期间LABEL还是Docker相对较新的一条指令，因此在用户的安装版本里可能还没有这一指令。

首先，用户需要构建这个示例镜像，将得到的镜像命名为reverseme：

$ docker build -t reverseme .

1．shell解决方案

基于shell的实现方案所需的大部分指令都在这里，与接下来的容器化解决方案相比不那么完备。举个例子，这一方案使用docker inspect命令来提取元数据。

jq是必需的　要运行这一解决方案，用户需要安装jq程序。它允许用户查询和操作JSON数据。

docker history reverseme | \ （1）　　　
awk ‘{print $1}’ | \ （2）
grep -v IMAGE | \ （3）　　　　　　　　　　　　　　
tac|\ （4）
sed “s/(.)/docker inspect \1 | \ （5）
jq -r \’.[0].ContainerConfig.Cmd[2] | tostring\’/“ | \
sh | \ （6）
sed ‘s/^#(nop) //‘ （7）

MAINTAINER Jérôme Petazzoni <jerome@docker.com>
ADD file:8cf517d90fe79547c474641cc1e6425850e04abbd8856718f7e4a184ea878538 in / 
CMD [“/bin/sh”]
MAINTAINER ian.miell@gmail.com
ENV myenvname=myenvvalue
WORKDIR /opt
mkdir -p copied
COPY file:d0fb99565b15f8dfec37ea1cf3f9c4440b95b1766d179c11458e31b5d08a2ced in 
➥ copied/Dockerfile
mkdir -p added
ADD file:d0fb99565b15f8dfec37ea1cf3f9c4440b95b1766d179c11458e31b5d08a2ced in
➥ added/Dockerfile
touch /tmp/afile
ADD file:d0fb99565b15f8dfec37ea1cf3f9c4440b95b1766d179c11458e31b5d08a2ced in / 
COPY dir:9cc240dcc0e31ce1b68951d230ee03fc6d3b834e2ae459f4ad7b7d023845e834 in / 
COPY file:97bc58d5eaefdf65278cf82674906836613be10af02e4c02c81f6c8c7eb44868 in / 
EXPOSE 80/tcp
VOLUME [/data]
ONBUILD touch /tmp/built
ENTRYPOINT [/bin/sh -c /bin/bash]
CMD [/bin/sh -c -r]

$ docker run -v /var/run/docker.sock:/var/run/docker.sock \
　dockerinpractice/dockerfile-from-image reverseme
FROM busybox:buildroot-2014.02
MAINTAINER ian.miell@gmail.com
ENV myenvname=myenvvalue
WORKDIR /opt
RUN mkdir -p copied
COPY file:43a582585c738bb8fd3f03f29b18caaf3b0829d3ceb13956b3071c5f0befcbfc \ 
in copied/Dockerfile
RUN mkdir -p added
ADD file:43a582585c738bb8fd3f03f29b18caaf3b0829d3ceb13956b3071c5f0befcbfc \ 
in added/Dockerfile
RUN touch /tmp/afile
ADD \
file:43a582585c738bb8fd3f03f29b18caaf3b0829d3ceb13956b3071c5f0befcbfc in / 
EXPOSE 80/tcp
VOLUME [/data]
ONBUILD touch /tmp/built
ENTRYPOINT [/bin/sh -c /bin/bash]
CMD [/bin/sh -c -r]

.PHONY: default createfile catfile （1）　　
default: createfile （2）　　　　　　　　　　　 
createfile: x.y.z （3）　　　　
catfile: （4）　　　　　
　　 cat x.y.z
x.y.z: （5）　　　　　　　　　　　　　　　　　　　　　 
　　 echo “About to create the file x.y.z”
　　 echo abc > x.y.z

base:
　　docker build -t corp/base .

app1: base
　　cd repos/app1 && docker build -t corp/app1 .

base:
　　tar -cvf - file1 file2 Dockerfile | docker build -t corp/base .

base:
　　tar —transform ‘s/^deps\///‘ -cf - deps/  Dockerfile | \
docker build -t corp/base .

在这里，用户可以将deps目录下的所有内容添加到构建上下文中，然后使用—transform选项压缩tar包（Linux上的最新tar版本支持），这样便可以从文件名中除去任何前导“deps/”。在这个例子里，更好的办法是将deps和Dockerfile放在各自的目录中以允许正常的docker build，但是了解这种高级用法很有价值，因为它可以在一些最不可能的地方派上用场。在使用这一方案之前往往要考虑清楚，毕竟它会增加构建流程的复杂度。

简单的变量替换是一件相对简单的事情，但是（如之前的—transform）在使用它之前还是得考虑清楚——Dockerfile之所以故意不支持变量，就是为了保持构建是易于重现的。这里我们将用到传给make的一些变量，然后使用sed替换，不过用户也可以按照自己的喜好来传参和替换：

VAR1 ?= defaultvalue
base:
　　cp Dockerfile.in Dockerfile
　　sed -i ‘s/{VAR1}/$(VAR1)/‘ Dockerfile
　　docker build -t corp/base .

Dockerfile将在每次基础目标运行时被重新生成，而且用户可以通过添加更多的sed -i条目添加更多的变量替换。要覆盖VAR1的默认值，可以执行make VAR1 = newvalue base。倘若变量里面包含斜杠的话，用户可能需要另外指定一个sed分隔符，如sed -i’s#VAR1}#$（VAR1）#‘Dockerfile。

最后，如果用户一直使用Docker作为构建工具，那便需要知道怎样才能从Docker中获取文件。我们将介绍几种不同的可选方案，具体取决于实际用例场景：

singlefile: base
　　docker run —rm corp/base cat /path/to/myfile > outfile
multifile: base
　　docker run —rm -v $(pwd)/outdir:/out corp/base sh \
-c “cp -r /path/to/dir/  /out/“

git clone https://github.com/docker-in-practice/docker-chef-solo-example.git

$ mkdir chef_example
$ cd chef_example
$ touch attributes.json （1）　　　　　
$ touch config.rb （2） 
$ touch Dockerfile （3） 
$ mkdir -p cookbooks/mysite/recipes （4）　　　　　
$ touch cookbooks/mysite/recipes/default.rb
$ mkdir -p cookbooks/mysite/templates/default （5）
$ touch cookbooks/mysite/templates/default/message.erb

{
　　“run_list”: [
　　　　　　“recipe[apache2::default]”,
　　　　　　“recipe[mysite::default]”
　　] 
}

base_dir　　　　“/chef/“
file_cache_path base_dir + “cache/“
cookbook_path　 base_dir + “cookbooks/“
verify_api_cert true

user “mysiteuser” do （1）　　
　　comment “mysite user”
　　home “/home/mysiteuser”
　　shell “/bin/bash”
　　supports　:manage_home => true
end
directory “/var/www/html/mysite” do （2）　　　 
　　owner “mysiteuser”
　　group “mysiteuser”
　　mode 0755
　　action :create
end
template “/var/www/html/mysite/index.html” do （3）　　　　
　　source “message.erb”
　　variables(
　　　　:message => “Hello World!”
　　)
　　user “mysiteuser”
　　group “mysiteuser”
　　mode 0755
end
web_app “mysite” do （4）　　　　
　　server_name “mysite.com”
　　server_aliases [“www.mysite.com”,”mysite.com”] （5）　　　 
　　docroot “/var/www/html/mysite”
　　cookbook ‘apache2’
end

<%= @message %>

FROM ubuntu:14.04
 RUN apt-get update && apt-get install -y git curl
RUN curl -L \ 
https://opscode-omnibus-packages.s3.amazonaws.com/ 
➥ ubuntu/12.04/x86_64/chefdk_0.3.5-1_amd64.deb \ 
-o chef.deb
RUN dpkg -i chef.deb && rm chef.deb （1）　　　　　　　　　
COPY . /chef （2）　　　　　　　　　
WORKDIR /chef/cookbooks
RUN knife cookbook site download apache2 （3）
RUN knife cookbook site download iptables　　　　　　　 
RUN knife cookbook site download logrotate
RUN /bin/bash -c ‘for f in $(ls gz); do tar -zxf $f; rm $f; done’ （4）　　　　　
RUN chef-solo -c /chef/config.rb -j /chef/attributes.json （5）　　　　
CMD /usr/sbin/service apache2 start && sleep infinity （6）

（1）下载并安装Chef。如果这一下载方式不起作用，可以检查之前在这一技巧的讨论中提到的docker-chef- solo-example的最新代码，因为这里可能需要更新的版本

（2）将所在文件夹下的内容复制到镜像上的/chef 文件夹

（3）切换到cookbooks文件夹然后使用Chef的knife工具下载apache2 cookbook及相关依赖的压缩包

（4）解压下载完的压缩包然后删除它们

（5）运行chef命令配置镜像。把事先创建好的属性和配置文件传给它

（6）定义镜像默认的启动命令。sleep infinity命令可以确保容器不会在service命令完成任务后立刻退出

现在可以构建并运行镜像：

docker build -t chef-example .
docker run -ti -p 8080:80 chef-example

如果读者现在浏览http://localhost:8080，应该能看到“Hello World!”的字样。

Docker Hub访问超时　如果Chef构建需要很长时间，而且用的是Docker Hub工作流的话，构建可能会出现超时。如果发生这种情况，用户可以在一台受自己管控的机器上完成构建，为支持的服务买单，或者是把构建步骤拆分成更小的单元，这样一来Dockerfile里每个单独步骤返回的时间便会更短。

这个例子虽然很简单，但是使用这一方案的好处是显而易见的。通过一些相对明了的配置文件，将镜像转换成所需状态的具体细节交由配置管理工具处理。这并不意味着可以忘记配置的细节，更改变量值的话还是要求理解其语义的，这样可以确保不会把事情搞砸。但是，这种方法的确可以节省很多的时间和精力，特别是那些不需要了解太多细节的项目。

技巧48　从源到镜像的构建

我们已经介绍了构建Docker镜像的几种方式，但是唯一一个从头设计来利用Docker的功能的便是Dockerfile。然而，这里还有一些可供选择的替代方案，它们可以让那些对Docker不感兴趣的开发者从中解脱出来，或是可以给构建过程提供更强大的能力。

问题

想要给自己的用户提供一种手段，使他们无须了解Docker便可以创建出一个Docker镜像。

解决方案

使用Red Hat的Source to Image（S2I或者STI）框架来构建Docker镜像。

讨论

Source to Image是通过将源代码存放到一个单独定义的负责构建镜像的Docker镜像来创建所需Docker镜像的一种手段。

读者可能想知道为什么会想出这么一种构建方法。主要原因便是它允许应用开发人员对自己的代码进行修改而无须关心Dockerfile甚至Docker镜像的细节。如果镜像交付到了一个aPaaS（应用程序平台即服务）平台，个别工程师不需要懂Docker也可以为项目贡献代码。这在企业环境里相当有用，在那里有大群人专注于特定领域，而且不用直接关注他们项目的构建过程。

S2I也称为STI　从源到镜像的构建方法在源代码和文档里有两个众所周知的名字：最开始是STI，新的名字是S2I。它们是一回事。

图5-1在核心轮廓里展示了S2I的工作流。

一旦流程建立起来，工程师们只需要专注他们希望对源代码做出的变更，致力于将它推广到不同的环境。其他一切事情则交由启动该流程的sti工具驱动。

1．额外收益

这一方案的优点体现在以下几个方面。

• 灵活性——这个过程可以很容易地嵌到任何现有的软件交付流程中，而且它几乎可以使用任意Docker镜像作为它的基础镜像层。
• 速度——这种构建方法可以比Dockefile构建更快，因为任意数量的复杂操作都可以添加到构建过程中而无须在每个步骤创建出一个新的分层。S2I还使用户能够在构建之间复用组件以节省时间。
• 业务解耦——由于源代码和Docker镜像均是清晰且明确分离的，开发人员可以专注于代码而基础架构团队则专注于Docker镜像及其交付。因为基础的底层镜像和代码是分离的，一些升级和补丁也更容易交付。

图5-1　从源到镜像的工作流

• 安全性——这个流程可以将构建中执行的操作限制为特定用户，而Dockerfile则允许以root身份运行任意命令。
• 生态系统——此框架的结构允许用户建立一个镜像和代码分离模式的共享生态系统，这更易于大型环境的运维。

本技巧将展示如何完成镜像构建这样的一个模式，尽管它很简单而且在某些方面有所限制。我们的应用模式将包含：

• 包含一个shell脚本的源代码；
• 一个用来创建镜像的构建器，该镜像会获取shell脚本，使它可运行，然后运行它。

2．创建自己的S2I镜像

创建自己的S2I镜像需要以下几个步骤：

（1）启动一个S2I开发环境；

（2）创建自己的Git项目；

（3）创建构建器镜像；

（4）构建应用程序镜像。

一旦镜像被创建出来，对其做修改和重新构建就很简单了。

3．启动一个S2I开发环境

为了帮助确保建立一种一致的体验，用户可以使用一个受维护的环境来开发自己的S2I构建镜像和项目：

$ docker run-ti \
-v /var/run/docker.sock:/var/run/docker.sock \ （1）
dockerinpractice/shutit-s2i （2）

（1）确保宿主机的Docker守护进程在容器里可用（见技巧25）

（2）使用一个受维护的S2I构建环境

有问题？启用了SELinux？　如果读者使用的是一个开启了SELinux的环境，那么在容器里执行Docker可能会遇到问题。详情见技巧88。

4．创建自己的Git项目

用户可以使用一个在其他地方构建然后放到GitHub上的Git项目，但是为了保证这个例子的简单性和独立性，我们会在S2I开发环境本地创建一个项目。正如前面所讲，源代码里包含一个向终端输出“Hello World”的shell脚本：

mkdir /root/myproject
cd /root/myproject
git init
git config —global user.email “you@example.com”
git config —global user.name “Your Name”
cat > app.sh <<< “echo ‘Hello World’”
git add .
git commit -am ‘Initial commit’

5．创建构建器镜像

为了创建构建器镜像，我们打算用sti创建一个脚手架然后在它上面做修改：

sti create sti-simple-shell /opt/sti-simple-shell
cd /opt/sti-simple-shell

这条S2I命令会创建出若干文件。为了让我们的工作流能够运行起来，我们要重点编辑如下文件：

• Makefile；
• Dockerfile；
• .sti/bin/assemble；
• .sti/bin/run。

先拿Dockerfile来说，将其内容修改成下面这些：

FROM openshift/base-centos7 （1）　　　　 
RUN chown -R default:default /opt/openshift （2）　
COPY ./.sti/bin /usr/local/sti （3）　　　　 
RUN chmod +x /usr/local/sti/  （4）　
USER default （5）

#!/bin/bash –e （1）　　　 
if [ “$1” = “-h” ]; then （2）　　　　　
　　exec /usr/local/sti/usage
fi　　　　　　　　　　　　　　　　　　 
if [ “$(ls /tmp/artifacts/ 2>/dev/null)” ]; then （3）
　echo “—-> Restoring build artifacts”
　mv /tmp/artifacts/  ./
fi　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
echo “—-> Installing application source” （4）　
cp -Rf /tmp/src/. ./　　　　　　　　　　　　　　 
echo “—-> Building application from source” （5）
chmod +x /opt/openshift/src/app.sh

（1）作为一个bash脚本运行并且一旦失败就退出

（2）如果传入了usage标志就输出使用帮助

（3）可以的话，从先前的构建中恢复任何已经保存的组件

（4）将应用程序源安装到默认目录中

（5）从源代码构建应用程序。在这个例子里，构建即是简单的给app.sh赋予可执行权限这一步

S2I构建的运行脚本负责运行应用程序。它是镜像默认会去执行的脚本：

#!/bin/bash -e
exec /opt/openshift/src/app.sh

至此，构建器已经准备就绪，用户可以执行make来构建自己的S2I构建器镜像了。它会创建出一个叫sti-simple-shell的Docker镜像，里面会提供应用程序镜像构建所需的环境，包括之前建出来的软件项目。make的输出结果看上去应该会类似下面这样：

$ make
imiell@osboxes:/space/git/sti-simple-shell$ make
docker build —no-cache -t sti-simple-shell .
Sending build context to Docker daemon 153.1 kB
Sending build context to Docker daemon
Step 0 : FROM openshift/base-centos7
 —-> f20de2f94385
Step 1 : RUN chown -R default:default /opt/openshift
 —-> Running in f25904e8f204
 —-> 3fb9a927c2f1
Removing intermediate container f25904e8f204
Step 2 : COPY ./.sti/bin /usr/local/sti
 —-> c8a73262914e
Removing intermediate container 93ab040d323e
Step 3 : RUN chmod +x /usr/local/sti/ 
 —-> Running in d71fab9bbae8
 —-> 39e81901d87c
Removing intermediate container d71fab9bbae8
Step 4 : USER default
 —-> Running in 5d305966309f
 —-> ca3f5e3edc32
Removing intermediate container 5d305966309f
Successfully built ca3f5e3edc32

$ sti build —force-pull=false —loglevel=1 \ （1）
file:///root/myproject sti-simple-shell final-image-1 （2）　
I0608 13:02:00.727125 00119 sti.go:112] Building final-image-1　　　　　　　　　　 
I0608 13:02:00.843933 00119 sti.go:182] Using assemble from image:///usr/local/sti （3）
I0608 13:02:00.843961 00119 sti.go:182] Using run from image:///usr/local/sti 
I0608 13:02:00.843976 00119 sti.go:182] Using save-artifacts from image:///
➥ usr/local/sti
I0608 13:02:00.843989 00119 sti.go:120] Clean build will be performed
I0608 13:02:00.844003 00119 sti.go:130] Building final-image-1
I0608 13:02:00.844026 00119 sti.go:330] No .sti/environment provided
➥ (no evironment file found in application sources)　
I0608 13:02:01.178553 00119 sti.go:388]—-> Installing application source
I0608 13:02:01.179582 00119 sti.go:388]—-> Building application from source　 （4）
I0608 13:02:01.294598 00119 sti.go:216] No .sti/environment provided
➥ (no evironment file found in application sources)
I0608 13:02:01.353449 00119 sti.go:246] Successfully built final-image-1 ) （5）

$ docker run final-image-1
Hello World

$ cd /root/myproject
$ cat > app.sh <<< “echo ‘Hello S2I!’”
$ git commit -am ‘new message’
$ sti build —force-pull=false file:///root/myproject sti-simple-shell \
　final-image-2

$ docker run final-image-2
Hello S21!

FROM ubuntu:14.04
RUN apt-get update && apt-get upgrade –y （1）　
RUN apt-get install -y git （2）　　　　　　　　
RUN apt-get install -y wget　　　　　　　　
RUN git clone https://github.com/facebook/osquery.git （3）　　　　 
WORKDIR /osquery （4）　　　　　　　　　 
RUN git checkout 1.0.3
RUN ./tools/provision.sh
RUN make
RUN make package　　　　　　　　　　 
RUN dpkg -i \
./build/linux/osquery-0.0.1-trusty.amd64.deb （5）　 
CMD [“/usr/bin/osqueryi”] （6）

RUN SUDO_FORCE_REMOVE=yes apt-get purge -y git wget sudo
RUN rm -rf /var/lib/apt/lists/ 
RUN apt-get autoremove -y
RUN apt-get clean
RUN cd
RUN rm -rf /osquery

我们的镜像大小现在比最近的一个版本还大一点儿，大约是2.19 GB！由于Docker是分层的，每一条RUN命令都会在最终镜像里创建一个新的写时复制（copy-on-write）分层，即使我们把文件删掉还是会导致镜像大小的增长。这触发了我们下面的改进。

什么是写时复制　写时复制是一项在处理文件时最小化资源占用的技术。只希望读取文件的进程看到的是来自最上层展示的文件——不同容器里的进程可以看到相同的底层文件，因为它们的镜像共享同一个分层。在大多数系统上这样做可以显著降低所需磁盘空间的使用量。当一个容器想要修改一个文件时，该文件会在它被修改前（否则其他容器也能感知到这一变化）复制到该容器所在的分层，这便是写时复制。

3．将一系列命令设置为一行

尽管可以手动将镜像扁平化（见技巧43），但是也可以在Dockerfile里通过将所有命令放到一条RUN指令中以实现相同的效果，如代码清单5-8所示。

代码清单5-8　带有单条RUN指令的OSQuery Dockerfile

FROM stackbrew/ubuntu:14.04
RUN apt-get update && apt-get upgrade -y && \ （1）
　　apt-get install -y git wget sudo && \
　　git clone https://github.com/facebook/osquery.git && \
　　cd /osquery && \
　　git checkout 1.0.3 && \
　　./tools/provision.sh && \
　　make && \
　　make package && \
　　dpkg -i ./build/linux/osquery-0.0.1-trusty.amd64.deb && \
　　SUDO_FORCE_REMOVE=yes apt-get purge -y git wget sudo && \
　　rm -rf /var/lib/apt/lists/  && \
　　apt-get autoremove -y && \
　　apt-get clean && \
　　cd / && \
　　rm -rf /osquery
CMD [“/usr/bin/osqueryi”]

FROM stackbrew/ubuntu:14.04
COPY install.sh /install.sh
RUN /bin/bash /install.sh && rm /install.sh
CMD [“/usr/bin/osqueryi”]

#!/bin/bash
set -o errexit （1）　　　　　　 
apt-get update
apt-get upgrade -y
apt-get install -y git wget sudo
git clone https://github.com/facebook/osquery.git
cd /osquery
git checkout 1.0.3
./tools/provision.sh
make
make package
dpkg -i ./build/linux/osquery-0.0.1-trusty.amd64.deb
SUDO_FORCE_REMOVE=yes apt-get purge -y git wget sudo
rm -rf /var/lib/apt/lists/ 
apt-get autoremove -y
apt-get clean
cd /
rm -rf /osquery

（1）将bash脚本配置为只要其中任何命令返回一个非零退出码就抛出错误

已构建的镜像报告显示的大小没有改变，仍然是1.05 GB。

解决一个又来一个　由于做出了这些更改，用户也因此失去了许多Dockerfile显而易见的有用功能。举个例子，因为工作变成了一个单条指令，所以不会有构建缓存，也就丧失了构建缓存所带来的省时的好处。同以往一样，这是一个在镜像大小、构建灵活性和构建时间三者之间的权衡。

利用这样几个简单的技巧，用户可以显著地缩减生成的镜像的大小。尽管如此，故事还没有结束，利用下面更加激进的技巧，用户还可以对镜像进行更加严格的瘦身。

技巧50　让镜像变得更小的技巧

我们不妨假设用户拿到一个第三方提供的镜像，而他希望让镜像变得更小。最简单的办法便是启动一个可以工作的镜像，然后删除一些不必要的文件。

经典的配置管理工具往往不会删除东西，除非显式地声明这样做——取而代之的是它们会从一个不工作的状态开始然后往里面添加新的配置和文件。这导致出于一个特定目的制作出的系统千奇百怪，而且可能会与在一台全新的服务器上运行配置管理工具的结果看上去不太一样，尤其是在配置已经演变了一段时间。通过Docker友好的分层及轻量的镜像技术，可以完成这一流程的反向操作并尝试删除一些东西。

问题

想要让镜像变得更小。

解决方案

删除不必要的软件包和文档文件。

讨论

本技巧将会遵循下列步骤来缩减一个镜像的大小：

（1）运行该镜像；

（2）进入容器内部；

（3）删除不必要的文件；

（4）提交容器作为一个新镜像（见技巧14）；

（5）扁平化该镜像（见技巧43）。

最后两步在本书前面已经讲过，所以这里仅介绍前面3个步骤。

为了讲解如何利用这一技巧，我们打算使用在技巧40里创建的镜像，并尝试使这个镜像变得更小。

先将该镜像作为一个容器运行起来；

docker run -ti —name smaller —entrypoint /bin/bash \
dockerinpractice/log-cleaner

因为这是一个基于Debian的镜像，所以用户可以先看看有哪些可能不需要的软件包然后删掉它们。执行dpkg -l | awk ‘{print $2}’用户便能拿到系统上已经安装的软件包的清单。

之后，用户可以通过执行apt-get purge -y packge_name来清理这些软件包。如果跳出一条吓人的消息警告用户“你要做的操作可能有害”，不妨点击“返回”以继续。

一旦删掉所有能够安全删除的软件包，紧接着就可以运行如下这些命令来清理apt的缓存：

apt-get autoremove
apt-get clean

这是一个相对安全地减少镜像里空间占用的办法。

通过删除文档可以进一步节省大量空间。举个例子，执行rm -rf /usr/share/doc/ /usr/share/man/ /usr/share/info/ 往往可以删除大概永远不会用到的一些大文件。用户还可以通过手动运行rm来删除一些不需要的二进制和类库以进一步缩减镜像的大小。

find /var | grep ‘.log$’ | xargs rm -v

$ docker run -ti busybox /bin/bash
exec: “/bin/bash”: stat /bin/bash: no such file or directory2015/02/23
➥ 09:55:38 Error response from daemon: Cannot start container
➥ 73f45e34145647cd1996ae29d8028e7b06d514d0d32dec9a68ce9428446faa19: exec: 
➥ “/bin/bash”: stat /bin/bash: no such file or directory

$ docker run -ti busybox /bin/ash 
/#

$ docker run -ti progrium/busybox /bin/ash
/ # opkg-install bash > /dev/null
/ # bash
bash-4.3#

FROM ubuntu:14.04
RUN apt-get update -q \
&& DEBIAN_FRONTEND=noninteractive apt-get install -qy mysql-client \
&& apt-get clean && rm -rf /var/lib/apt
ENTRYPOINT [“mysql”]

FROM gliderlabs/alpine:3.1
RUN apk-install mysql-client
ENTRYPOINT [“mysql”]

FROM gcc （1）　　　　　　　
RUN echo ‘int main() { puts(“Hello world!”); }’ > hi.c （2） 
RUN gcc -static hi.c -w -o hi （3）

$ docker build -t hello_build . （1）　　　 
$ docker run —name hello hello_build /bin/true （2）
$ docker cp hello:/hi new_folder （3）
$ docker rm hello （4）　　　　　　　　　
hello
$ docker rmi hello_build　　　　　 
Deleted: 6afcbf3a650d9d3a67c8d67c05a383e7602baecc9986854ef3e5b9c0069ae9f2

$ cd new_folder

FROM scratch （1）　　
ADD hi /hi （2）　　
CMD [“/hi”] （3）

$ docker build -t hello_world .
Sending build context to Docker daemon 931.3 kB
Sending build context to Docker daemon
Step 0 : FROM scratch
 —->
Step 1 : ADD hi /hi
 —-> 2fe834f724f8
Removing intermediate container 01f73ea277fb
Step 2 : ENTRYPOINT /hi
 —-> Running in 045e32673c7f
 —-> 5f8802ae5443
Removing intermediate container 045e32673c7f
Successfully built 5f8802ae5443
$ docker run hello_world
Hello world!
$ docker images | grep hello_world
hello_world　　　latest　　5f8802ae5443　 24 seconds ago　928.3 kB

FROM golang:1.4.2 （1）
RUN CGO_ENABLED=0 go get \ （2）　　　　　　 
-a -ldflags ‘-s’ -installsuffix cgo \ （3）
github.com/docker-in-practice/go-web-server （4）　　　 
CMD [“cat”,”/go/bin/go-web-server”] （5）

$ docker build -t go-web-server . （1）
$ mkdir -p go-web-server && cd go-web-server （2） 
$ docker run go-web-server > go-web-server （3）　　
$ chmod +x go-web-server （4）

FROM scratch
ADD go-web-server /go-web-server （1）　 
ENTRYPOINT [“/go-web-server”] （2）

$ docker build -t go-web-server .
$ docker images | grep go-web-server
go-web-server　　latest　　de1187ee87f3　3 seconds ago　 4.156 MB
$ docker run -p 8080:8080 go-web-server -port 8080

[host]$ docker run -ti —entrypoint /bin/bash \ （1） 
—name reduce dockerinpractice/log-cleaner-purged （2）
$ apt-get update && apt-get install -y inotify-tools （3） 
$ inotifywait -r -d -o /tmp/inotifywaitout.txt \ （4）
/bin /etc /lib /sbin /var （5）
inotifywait[115]: Setting up watches. Beware: since -r was given, this 
➥ may take a while!
inotifywait[115]: Watches established.　　　　　　　　
$ inotifywait -r -d -o /tmp/inotifywaitout.txt /usr/bin /usr/games \　（6）
/usr/include /usr/lib /usr/local /usr/sbin /usr/share /usr/src 
inotifywait[118]: Setting up watches. Beware: since -r was given, this 
➥ may take a while!
inotifywait[118]: Watches established.　　 
$ sleep 5 （7）
$ cp /usr/bin/clean_log /tmp/clean_log （8）
$ rm /tmp/clean_log　　　　　　　　　　　　　　　
$ bash　　　　　　　　　　　　　　　　　　　　　　　
$ echo “Cleaning logs over 0 days old”
$ find /log_dir -ctime “0” -name ‘log’ -exec rm {} \; （9）　　　　 
$ awk ‘{print $1$3}’ /tmp/inotifywaitout.txt | sort -u > \　　　
/tmp/inotify.txt （10）
$ comm -2 -3 \ （11）　　 
<(find /bin /etc /lib /sbin /var /usr -type f | sort) \
<(cat /tmp/inotify.txt) > /tmp/candidates.txt
$ cat /tmp/candidates.txt | xargs rm （12）　　　　　 
$ exit （13）
$ exit

（1）安装inotify-tools包

（2）覆盖此镜像默认的入口程序

（3）给容器起一个名字，后面可以用它来引用该容器

（4）以递归（-r）和守护进程（-d）模式运行inotifywait，获取一个已访问文件的清单并写到outfile（以-o标志指定的）里

（5）指定感兴趣的需要关注的文件夹。注意不要监听/tmp，因为/tmp/inotifywaitout. txt文件如果自己监听自己的话可能会造成一个死循环

（6）对/usr文件夹上的子文件夹再次执行inotifywait。由于/usr文件夹里有太多文件需要inotifywait来处理，因此用户需要单独一个个地去指定

（7）Sleep 会给予inotifywait 一个合理的等待启动的时间

（8）记得访问一个要用到的脚本文件。还有，要确保有执行rm命令的权限

（9）像脚本里做的那样，启动一个bash shell，然后运行脚本里本来要执行的一些命令

（10）利用awk工具从inotifywait的日志输出里生成一个文件名清单，然后将它去重并排序

（11）使用comm工具输出一个文件系统上未访问的文件清单

（12）删除所有未访问的文件

（13）退出之前打开的bash shell，随后再退出容器本身

现在已经完成：

• 给一些文件设置监听以查看哪些文件是被访问的；
• 执行所有的命令来模拟脚本的运行；
• 执行一些命令确保用户有权限访问后面肯定要用到的脚本和rm实用工具；
• 获取一个运行期间未被访问的所有文件的清单；
• 删除所有未被访问的文件。

现在，可以将此容器扁平化（见技巧43），创建出一个新镜像，然后测试它是否仍然能够正常工作：

$ ID=$(docker export reduce | docker import -) （1）
$ docker tag $ID smaller （2）
$ docker images | grep smaller
smaller　latest　2af3bde3836a　18 minutes ago　6.378 MB （3）　　
$ mkdir -p /tmp/tmp （4）　　　　　　　　　　　　　　
$ touch /tmp/tmp/a.log （5）　　　　　　　　　　　 
$ docker run -v /tmp/tmp:/log_dir smaller \
/usr/bin/clean_log 0
Cleaning logs over 0 days old
$ ls /tmp/tmp/a.log
ls: cannot access /tmp/tmp/a.log: No such file or directory

（1）将镜像扁平化然后把镜像ID放到环境变量ID里

（2）给新的扁平镜像打上smaller的标签

（3）现在该镜像甚至比之前大小的10%还小

（4）在测试目录上运行新创建的镜像，并检查创建的文件是否已经被删除

（5）为了测试创建一个新的文件夹和文件，模拟一个日志目录

我们将此镜像的大小从96 MB缩减到了大约6.5 MB，而它似乎仍然可以正常工作。相当节俭！

有风险！　本技巧就像CPU超频一样，并不是一个无关紧要的优化。这个特定案例能够很正常地运转，是因为它是一个运行范围相当有限的应用程序，但是用户的一些核心关键业务应用程序可能是更复杂的，而且在如何访问文件方面可能是更加动态的。用户可以轻易删除一个在运行时未访问的文件，但是该文件可能会在某些其他场景下需要用到。

如果有点儿担心删掉的这些文件后面可能会用到而导致镜像损坏的话，可以用/tmp/candidates.txt文件收录未触及的最大文件的清单，如下所示：

cat /tmp/candidates.txt | xargs wc -c | sort -n | tail

然后可以删掉那些确定应用程序将来不会用到的大一点儿的文件。这也是一场大的胜利！

技巧54　大也可以美

尽管本节是关于如何保持镜像小的，但值得铭记的是小也不一定就是更好的。正如我们接下来将讨论的那样，一个相对较大的单体镜像可以比一个小镜像更加高效。

问题

想要降低由于Docker镜像导致的磁盘空间占用和网络带宽。

解决方案

为组织内部创建一个统一的、较大的、单体的基础镜像。

讨论

这是一个两难的取舍，但是使用一个大的单体镜像可以帮用户节省磁盘空间和网络带宽。

回想一下，Docker在容器正在运行时使用的是写时复制机制。这意味着用户可以运行数百个Ubuntu容器，而在每个容器启动后只需要占用少量额外的磁盘空间。

如图5-2所示，如果用户在Docker服务器上运行了大量不同的较小的镜像的话，那么使用的磁盘空间甚至可能会比运行一个大一些的一切所需都包揽到其中的单体镜像还要多。

图5-2　许多小的基础镜像与较少的大的基础镜像的对比

读者可能会想起共享库的原理。一个共享库可以一次性被多个应用程序加载，这减少了要运行这些程序所需的磁盘空间和内存的使用量。同理，一个组织内共享的基础镜像可以节省空间，因为它只需要被下载一次，而且应该囊括了所需的一切。之前多个镜像里需要用到的程序和库现在只需要引用一次。

此外，这样做的另外一个好处是可以有一个跨团队共享的单体的、集中管理的镜像。该镜像的维护可以是集中式的，一些改进也是共享的，并且构建中遇到的问题只需要解决一次。

要采用本技巧，需要注意下列事项。

• 基础镜像首先应该是可靠的。如果它的行为不一致，应当避免使用。
• 对基础镜像的变更应该在某处可以可视化地跟踪到，以便用户可以自行调试。
• 在更新香草（vanilla）镜像时一些回归测试是至关重要的，这样可以减少麻烦。
• 在添加内容到基础镜像时要谨慎——一旦添加到了基础镜像，它便很难删除，而且镜像会膨胀得很快。

我们在自己600强的开发公司里使用了本技巧，产生的效果非常好。每月构建的核心应用会被打包到一个大的镜像并发布到内部的Docker注册中心。默认情况下，团队将会在所谓的“香草”企业镜像上构建应用，有必要的话再在上面创建定制镜像分层。

5.4　小结

本章展示了如何管理Docker镜像的配置，这是任何Docker工作流都必须关注的一个重点。我们一起了解了用户可以如何在Docker官方推荐的路线中结合现有流程，并且介绍了一些构建镜像时的最佳实践。

我们就下面几个问题讨论了“如何做”：

• 如果觉得受限的话，可以扩展Dockerfile的灵活性；
• 可以通过扁平化镜像的方式删除底层镜像分层里的私密文件；
• Dockerfile和像Chef这样更加传统的配置管理工具并不是互斥的；
• 用户应该努力让自己的镜像尽可能小。

至此，读者已经通过一些手段得到了自己的Docker镜像，是时候考虑该如何和其他人分享这些镜像，为促进持续交付和持续集成打下基础。

[1]　 Ddocker从1.9版本开始已经引入ARG指令支持传入变量，见https://docs.docker.com/engine/reference/ builder/#arg。——译者注