3.利用 commit 理解镜像构成

在之前的例子中，我们所使用的都是来自于 Docker Hub 的镜像。

直接使用这些镜像是可以满足一定的需求，而当这些镜像无法直接满足需求时，我们就需要定制这些镜像。

接下来的几节就将讲解如何定制镜像

回顾一下之前我们学到的知识:

• 镜像是多层存储，每一层是在前一层的基础上进行的修改;
• 容器同样也是多层存储，是在以镜像为基础层，在其基础上加一层作为容器运行时的存储层。

 

1)现在让我们以定制一个 Web 服务器为例子，来讲解镜像是如何构建的:

userdeMBP:~ user$  docker run --name webserver -d -p 80:80 nginxUnable to find image 'nginx:latest' locally latest: Pulling from library/nginx a5a6f2f73cd8: Pull complete 1ba02017c4b2: Pull complete 33b176c904de: Pull complete Digest: sha256:5d32f60db294b5deb55d078cd4feb410ad88e6fe77500c87d3970eca97f54dba Status: Downloaded newer image for nginx:latest f4936eb44ef38a8998ec78ab48a967a92f009d6c04dfd5cf2065ec8db0b1fbd7 userdeMBP:~ user$ docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f4936eb44ef3 nginx "nginx -g 'daemon of…" 2 minutes ago Up 2 minutes 0.0.0.0:80->80/tcp webserver

run = pull镜像（如果本地没有) + start容器

这条命令会用 镜像启动一个容器，命名为 webserver，并且映射了 80 端口，这样我们可以用浏览器去访问这个服务器,调用：http://localhost/:

现在，假设我们非常不喜欢这个欢迎页面，我们希望改成欢迎 Docker 的文字，我 们可以使用 docker exec 命令进入容器，修改其内容:

 

userdeMBP:~ user$ docker exec -it webserver bashroot@f4936eb44ef3:/# echo '
 hello docker!
' > /usr/share/nginx/html/index.htmlroot@f4936eb44ef3:/# exit exit

我们以交互式终端方式(-it)进入 容器，并执行了bash命令，也就是获得一个可操作的 Shell。

然后，我们用<h1> hello docker!<h1> 覆盖了 /usr/share/nginx/html/index.html的内容。

现在我们再刷新浏览器的话，会发现内容被改变了:

在上面，我们修改了容器的文件，也就是改动了容器的存储层。我们可以通过 docker diff命令看到具体的改动:

userdeMBP:~ user$ docker diff webserverC /usrC /usr/shareC /usr/share/nginxC /usr/share/nginx/htmlC /usr/share/nginx/html/index.html C /root A /root/.bash_history C /run A /run/nginx.pid C /var C /var/cache C /var/cache/nginx A /var/cache/nginx/client_temp A /var/cache/nginx/fastcgi_temp A /var/cache/nginx/proxy_temp A /var/cache/nginx/scgi_temp A /var/cache/nginx/uwsgi_temp

2）现在我们定制好了变化，我们希望能将其保存下来形成镜像

 

当我们运行一个容器的时候(如果不使用卷volume的话)，我们做的任何文件修 改都会被记录于容器存储层里。

当Docker提供一个docker commit 的命令时，可以将容器的存储层保存下来成为镜像。

换句话说，其实就是在原有镜像的基础上，在叠加上新的容器的存储层，来构成新的镜像。

docker commit 的语法格式为:

docker commit [选项] 
        <容器id或容器名>
          [
         <仓库名>
          [:
          <标签>
           ]]
          
         
        

我们可以用下面的命令将容器保存为镜像：

userdeMBP:~ user$  docker commit --author "manXingHouJi"  --message "修改了默认网页" webserver nginx:v2 sha256:5dda481d7ed18aed71cfd5052ffe64ebac5dde02e8a7c743f7286413f7082610

其中 --author是指定修改的作者，而 --message则是记录本次修改的内容。 这点和 git版本控制相似，不过这里这些信息可以省略留空。

然后我们可以在 docker images中看到这个新定制的镜像:

userdeMBP:~ user$ docker imagesREPOSITORY                        TAG                 IMAGE ID            CREATED             SIZEnginx                             v2                  5dda481d7ed1        58 seconds ago      109MBnginx                             latest              568c4670fa80        2 weeks ago         109MB

 我们还可以用 docker history具体查看镜像内的历史记录，如果比较nginx : latest的历史记录，我们会发现新增了我们刚刚提交的这一层

新的镜像定制好后，我们可以来运行这个镜像:

userdeMBP:~ user$ docker run --name web2 -d -p 81:80 nginx:v2889e5311532c39241510342cd5a15194071b3629c0d9a33dfcc60d10b792a785

这里我们命名为新的服务为web2 ，并且映射到 81端口,可以直接访问 http://localhost:81：

 

⚠️慎用 docker commit

使用 docker commit命令虽然可以比较直观的帮助理解镜像分层存储的概念， 但是实际环境中并不会这样使用。

 

1）首先，如果仔细观察之前的 docker diff webserver的结果，你会发现除了真 正想要修改的 /usr/share/nginx/html/index.html文件外，由于命令的执行，还有很多文件被改动或添加了。这还仅仅是最简单的操作，如果是安装软件包、编译构建，那会有大量的无关内容被添加进来，如果不小心清理，将会导致镜像极为臃肿。

2）此外，使用 意味着所有对镜像的操作都是黑箱操作，生成的镜像也被称为黑箱镜像.换句话说，就是除了制作镜像的人知道执行过什么命令、怎 么生成的镜像，别人根本无从得知。

虽然 docker diff或许可以告诉得到一些线索， 但是远远不到可以确保生成一致镜像的地步。这种黑箱镜像的维护工作是非常痛苦的。

3）而且，回顾之前提及的镜像所使用的分层存储的概念，除当前层外，之前的每一层 都是不会发生改变的.

换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改（如标记某一内容不可见来代表删除操作），而不会改动上一层。

如果使用 docker commit制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，这会让镜像更加臃 肿。

4）因此docker commit命令除了学习之外，还有一些特殊的应用场合，比如被入侵后保存现场等。

但是，不要使用docker commit定制镜像，定制行为应该使用Dockerfile来完成。

下面的章节我们就来讲述一下如何使用 Dockerfile定制镜像。

 

 

 

4.使用 Dockerfile 定制镜像

从上面docker commit的学习中，我们可以了解到，镜像的定制实际上就是 定制每一层所添加的配置、文件。

如果我们可以把每一层修改、安装、构建、操作 的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么之前提及的无法重复 的问题、镜像构建透明性的问题、体积的问题就都会解决。

这个脚本就是 Dockerfile

 

Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。

还以之前定制 镜像为例，这次我们使用 Dockerfile 来定制,内容为：

 

1）FROM 指定基础镜像

上面就指定了该Dockerfile的修改就是在nginx基础镜像上进行的，FROM是必备指令，并且必须是第一条指令

所以以后如果需要自己定制某个镜像时，可以在Docker Hub中找到与自己目标镜像最符合的镜像作为基础镜像来进行定制

 

除了选择现有镜像为基础镜像外，Docker 还存在一个特殊的镜像，名为scratch 。

这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像,使用即 FROM scratch。

 

如果你以 scratch为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。

 

2）RUN 执行命令

 

其格式有两种:

• shell 格式: RUN<命令>，就像直接在命令行中输入的命令一样。刚才写的 Dockrfile 中的 指令就是这种格式。

RUN echo '
Hello, Docker!
' > /usr/share/nginx/html/index.html

• exec 格式: RUN["可执行文件"，"参数1"，"参数2"]，这更像是函数调用中的格式

 

既然 RUN就像 Shell 脚本一样可以执行命令，那么我们是否就可以像 Shell 脚本 一样把每个命令对应一个 RUN 呢?比如这样:

FROM debian:jessieRUN apt-get updateRUN apt-get install -y gcc libc6-dev makeRUN wget -O redis.tar.gz "http://download.redis.io/releases/redi s-3.2.5.tar.gz" RUN mkdir -p /usr/src/redis RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 RUN make -C /usr/src/redis RUN make -C /usr/src/redis install

之前说过，Dockerfile 中每一个指令都会建立一层， 也不例外。每一个的行为，就和刚才我们手工建立镜像的过程一样:新建立一层，在其上执行这些命令，执行结束后， 这一层的修改，构成新的镜像。

⚠️而上面的这种写法，创建了 7 层镜像。这是完全没有意义的，而且很多运行时不需要的东西，都被装进了镜像里，比如编译环境、更新的软件包等等。结果就是产生 非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。 这是很多初学 Docker 的人常犯的一个错误。

 

正确的写法应该是这样：

FROM debian:jessieRUN buildDeps='gcc libc6-dev make' \    && apt-get update \ && apt-get install -y $buildDeps \ && wget -O redis.tar.gz "http://download.redis.io/releases/r edis-3.2.5.tar.gz" \ && mkdir -p /usr/src/redis \ && tar -xzf redis.tar.gz -C /usr/src/redis --strip-component s=1 \ && make -C /usr/src/redis \ && make -C /usr/src/redis install \ && rm -rf /var/lib/apt/lists/* \ && rm redis.tar.gz \ && rm -r /usr/src/redis \ && apt-get purge -y --auto-remove $buildDeps

首先，之前所有的命令只有一个目的，就是编译、安装 redis 可执行文件。因此没 有必要建立很多层，这只是一层的事情

所以其实仅需要一个RUN，并使用&&将各个命令串联起来

 

⚠️在撰写 Dockerfile 的时候，要经常提醒自己，这并不是在写 Shell 脚本，而是在定义每一层该如何构建。

 

此外，还可以看到这一组命令的最后添加了清理工作的命令，删除了为了编译构建 所需要的软件，清理了所有下载、展开的文件，并且还清理了 缓存文件。这 是很重要的一步，我们之前说过，镜像是多层存储，每一层的东西并不会在下一层 被删除，会一直跟随着镜像。因此镜像构建时，一定要确保每一层只添加真正需要 添加的东西，任何无关的东西都应该清理掉。

很多人初学 Docker 制作出了很臃肿的镜像的原因之一，就是忘记了每一层构建的最后一定要清理掉无关文件。

 

 

3）构建镜像

接下来就使用上面生成Dockerfile文件去构建nginx镜像

在生成Dockerfile文件的目录下执行：

userdeMBP:mynginx user$ docker build -t nginx:v3 .Sending build context to Docker daemon  2.048kBStep 1/2 : FROM nginx ---> 568c4670fa80 Step 2/2 : RUN echo '
Hello, Docker!
' > /usr/share/nginx/html/index.html ---> Running in 0e5088418e3b Removing intermediate container 0e5088418e3b ---> beda48ecf85b Successfully built beda48ecf85b Successfully tagged nginx:v3

从命令的输出结果中，我们可以清晰的看到镜像的构建过程。

在 step 2中，如同我们之前所说的那样， RUN指令启动了一个容器 0e5088418e3b，执行了所要求的命令，并最后提交了这一层 beda48ecf85b，随后删除了所用到的这个容器 0e5088418e3b。

docker build 命令格式：

docker build [选项] 
                    <上下文路径 url ->

-t, --tag list      Name and optionally a tag in the 'name:tag' format 指定生成的镜像名字，标签是可选项，如上面-t nginx:v3

上面例子中的<上下文路径/URL/->使用的是 . 来表示，表示当前目录

 

4）镜像构建上下文(Context)——注意看看

如果简单理解上面所说的 . 是表示Dockerfile文件当前所在目录的话，是不准确的，其指定的是上下文路径。

那么为什么会有人误以为 是指定 所在目录呢?这是因为在默认情况下，如果不额外指定Dockerfile的话，会将上下文目录下的名为Dockerfile的文件作为 Dockerfile。

这只是默认行为，实际上Dockerfile的文件名并不要求必须为Dockerfile ，而且并不要求必须位于上下文目录中，比如可以用 -f ../Dockerfile.php 参数指定某个文件作为Dockerfile 。

 

 

首先我们要理解 docker build的工作原理。Docker 在运行时分为 Docker 引擎 (也就是服务端守护进程daemon)和客户端工具。

Docker 的引擎提供了一组 REST API， 被称为 Docker Remote API，而如 docker命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。

因此，虽然表面上我们好像是在 本机执行各种 docker功能，但实际上，一切都是使用的远程调用形式在服务端 (Docker 引擎)完成。也因为这种 C/S 设计，让我们操作远程服务器的 Docker 引 擎变得轻而易举。

 

当我们进行镜像构建的时候，并非所有定制都会通过 RUN指令完成，经常会需要将一些本地文件复制进镜像，比如通过 COPY指令、 ADD指令等。

而 docker build命令构建镜像，其实并非在本地构建，而是在服务端，也就是 Docker 引擎中构建的。

那么在这种客户端/服务端的架构中，如何才能让服务端获得本地文件呢?

 

这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，docker build 命令得知这个路径后，会将路径下的所有内容打包，然后上 传给 Docker 引擎。

这样 Docker 引擎收到这个上下文包后，展开就会获得构建镜 像所需的一切文件。

从刚刚运行的docker build的结果中我们可以看见：

 

userdeMBP:mynginx user$ docker build -t nginx:v3 .Sending build context to Docker daemon  2.048kB  //这就是发送给Docker引擎的上下文包

 

 

如果在 Dockerfile中这么写:

COPY ./package.json /app/

这并不是要复制执行docker build命令所在的目录下的package.json，也不是要复制Dockerfile所在目录下的package.json，而是复制传到Docker引擎的上下文包的上下文下的package.json

这也就是为什么有时执行COPY ../package.json /app 或者 COPY /opt/XXXX /app 会无法工作的原因，因为这些路径已经超出了上下文的范围，Docker引擎是无法获得这些文件的。

如果真的需要这些文件，你需要将其复制到Docker引擎的上下文中。

 

如果指定本地作为上下文的目录下有些东西确实不希望构建时传给 Docker 引擎，那么可以用 .gitignore 一样的语法写一 个 .dockerignore，该文件是用于剔除不需要作为上下文传递给 Docker 引擎 的。

 

 

5)其它 docker build的用法

1>直接从 Git repo 进行构建

docker build [选项] 
                    <上下文路径 url ->

可见，docker build还支持URL构建，所以可以直接从Git repo中构建

userdeMBP:~ user$ docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14 unable to prepare context: unable to 'git clone' to temporary context directory: stat /var/folders/2_/g5wrlg3x75zbzyqvsd5f093r0000gn/T/docker-build-git776693632/8.14: no such file or directory userdeMBP:~ user$ docker build https://github.com/twang2218/gitlab-ce-zh.git#:11.0 Sending build context to Docker daemon 5.632kB Step 1/23 : FROM gitlab/gitlab-ce:11.0.5-ce.0 as builder 11.0.5-ce.0: Pulling from gitlab/gitlab-ce 3620e2d282dc: Downloading [=====> ] 4.758MB/43.19MB ef22f5e4b3b2: Download complete

书中给的例子的8.14版本太旧了，所以找不到相应的文件了，换成了新版本即可

 

2>用给定的 tar 压缩包构建

docker build http://server/context.tar.gz

Docker 引擎会下 载这个包，并自动解压缩，以其作为上下文，开始构建

 

3>从标准输入中读取 Dockerfile 进行构建

docker build - < Dockerfile

或：

cat Dockerfile | docker build -

上面的这两个语句都会自动在终端运行该命令的当前目录下去寻找是否有名叫Dockerfile的文件，然后输入命令

如果标准输入传入的是文本文件，则将其视为 Dockerfile，并开始构建。

这种 形式由于直接从标准输入中读取 Dockerfile 的内容，它没有上下文，因此不可以像其他方法那样可以将本地文件 COPY进镜像之类的事情。

 

4>从标准输入中读取上下文压缩包进行构建

docker build - < context.tar.gz

上面的这个语句都会自动在终端运行该命令的当前目录下去寻找是否有名叫context.tar.gz的压缩包，然后输入命令

如果发现标准输入的文件格式是gzip 、bzip2 以及 xz的话，将会使其为上下文压缩包，直接将其展开，将里面视为上下文，并开始构建。