3.2 构建镜像

Docker提供了两种构建镜像的方法：

（1）docker commit命令

（2）Dockerfile构建文件

3.2.1 docker commit  （不建议用户通过这种方式构建镜像）

• docker commit命令是创建新镜像最直观的方法，其过程包含三个步骤：
  • 运行容器。
  • 修改容器。
  • 将容器保存为新的镜像。
• 举个例子：在centOS镜像中安装vi并保存为新镜像

i参数的作用是以交互模式进入容器，并打开终端。aaa96b997052是容器的内部D。

确认没有安装vi，安装vi

在新窗口中查看当前运行的容器，执行docker commit命令将容器保存为镜像，sad_neumann是容器随机分配的名字，新镜像命名为centos_with_vi

查看新镜像属性

即便是用 Dockerfile（推荐方法）构建镜像，底层也是 docker commit一层一层构建新镜像的。学习 docker commit能够帮助我们更加深入地理解构建过程和镜像的分层结构。

3.2.2 Dockerfile（推荐）

Dockerfile是一个文本文件，记录了镜像构建的所有步骤。

用Dockerfile创建安装了vi的Ubuntu

• 首先 Docker将 build context中的所有文件送给 Docker daemon. build context为镜像构建提供所需要的文件或目录。
• Dockerfile中的ADD、COPY等命令可以将 build context中的文件添加到镜像。此例中，build context为当前目录fot,该目录下的所有文件和子目录都会被发送给 Docker daemon。

使用了 docker build 命令进行镜像构建。其格式为：

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

为镜像添加一个新的标签：docker tag

docker build工作原理：Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 Docker Remote API (opens new window)，而如 docker 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。因此，虽然表面上我们好像是在本机执行各种 docker 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。

镜像实现原理：

Docker 镜像是怎么实现增量的修改和维护的？

每个镜像都由很多层次构成，Docker 使用 Union FS (opens new window)将这些不同的层结合到一个镜像中去。

通常 Union FS 有两个用途, 一方面可以实现不借助 LVM、RAID 将多个 disk 挂到同一个目录下,另一个更常用的就是将一个只读的分支和一个可写的分支联合在一起，Live CD 正是基于此方法可以允许在镜像不变的基础上允许用户在其上进行一些写操作。

Docker 在 OverlayFS 上构建的容器也是利用了类似的原理。

3.镜像缓存特性

Docker会缓存已有镜像的镜像层，构建新镜像时，如果某镜像层已经存在，就直接使用，无须重新创建。

Dockerfile中每一个指令都会创建一个镜像层，上层是依赖于下层的。无论什么时候，只要某一层发生变化，其上面所有层的缓存都会失效。

4.调试Dockerfile

总结一下通过 Dockerfile构建镜像的过程：

(1)从base镜像运行一个容器。

(2)执行一条指令，对容器做修改。

(3)执行类似 docker commit的操作，生成一个新的镜像层。

(4) Docker再基于刚刚提交的镜像运行一个新容器。

(5)重复24步，直到 Dockerfile中的所有指令执行完毕。

如果Dockerfile由于某种原因执行失败了，能够得到前一个指令成功执行构建出的镜像

1. Dockerfile常用指令

• FROM

指定base镜像。

• MAINTAINER

设置镜像的作者，可以是任意字符串。

•  COPY

将文件从 build context复制到镜像。从上下文目录中复制文件或者目录到容器里指定路径。

COPY支持两种形式： COPY src dest与COPY ["srce"dest]

• 注意：src只能指定 build context中的文件或目录。
• <源路径>：源文件或者源目录，如果源路径为文件夹，复制的时候不是直接复制该文件夹，而是将文件夹中的内容复制到目标路径。这里可以是通配符表达式，其通配符规则要满足 Go 的 filepath.Match 规则。例如：
  • COPY hom* /mydir/
  • COPY hom?.txt /mydir/
• <目标路径>：容器内的指定路径，该路径不用事先建好，路径不存在的话，会自动创建。
• 使用 COPY 指令，源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。在使用该指令的时候还可以加上 --chown=<user>:<group> 选项来改变文件的所属用户及所属组。

• ADD

与COPY类似，从 build context复制文件到镜像。不同的是，如果sre是归档文件（tar、zip、tgz、Xz等），文件会被自动解压到dest，<源路径> 可以是一个 URL，这种情况下，Docker 引擎会试图去下载这个链接的文件放到 <目标路径> 去。下载后的文件权限自动设置为 600，如果这并不是想要的权限，那么还需要增加额外的一层 RUN 进行权限调整

• ADD 指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。
• 可以遵循的使用原则：所有的文件复制均使用 COPY 指令，仅在需要自动解压缩的场合使用 ADD。

• ENV
  • 设置环境变量，环境变量可以被后面的指令使用，如 RUN，还是运行时的应用，都可以直接使用这里定义的环境变量
  • 格式：
    • ENV <key> <value>
    • ENV <key1>=<value1> <key2>=<value2>...
  • 下列指令可以支持环境变量展开： ADD、COPY、ENV、EXPOSE、FROM、LABEL、USER、WORKDIR、VOLUME、STOPSIGNAL、ONBUILD、RUN。
  • 可以从这个指令列表里感觉到，环境变量可以使用的地方很多，很强大。通过环境变量，我们可以让一份 Dockerfile 制作更多的镜像，只需使用不同的环境变量即可。

• EXPOSE
  • 是声明容器运行时提供服务的端口，这只是一个声明，在容器运行时并不会因为这个声明应用就会开启这个端口的服务。在 Dockerfile 中写入这样的声明有两个好处，一个是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；另一个用处则是在运行时使用随机端口映射时，也就是 docker run -P 时，会自动随机映射 EXPOSE 的端口。
  • 格式为 EXPOSE <端口1> [<端口2>...]
  • 要将 EXPOSE 和在运行时使用 -p <宿主端口>:<容器端口> 区分开来。-p，是映射宿主端口和容器端口，换句话说，就是将容器的对应端口服务公开给外界访问，而 EXPOSE 仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行端口映射。
• VOLUME
  • 将文件或目录声明为volume。容器运行时应该尽量保持容器存储层不发生写操作，对于数据库类需要保存动态数据的应用，其数据库文件应该保存于卷(volume)中。为了防止运行时用户忘记将动态文件所保存目录挂载为卷，在 Dockerfile 中，我们可以事先指定某些目录挂载为匿名卷，这样在运行时如果用户不指定挂载，其应用也可以正常运行，不会向容器存储层写入大量数据。
  • 格式为：
    • VOLUME ["<路径1>", "<路径2>"...]
    • VOLUME <路径>

• WORKDIR
  • 为指令设置镜像中的当前工作目录，以后各层的当前目录就被改为指定的目录，如该目录不存在，WORKDIR 会帮你建立目录。
  • 如果你的 WORKDIR 指令使用的相对路径，那么所切换的路径与之前的 WORKDIR 有关
  • 格式为：WORKDIR <工作目录路径>
• USER
  • 指定当前用户。改变之后层的执行RUN,CMD以及ENTRYPOINT这类命令的身份。
  • USER 只是帮助你切换到指定用户而已，这个用户必须是事先建立好的，否则无法切换。
  • 如果以 root 执行的脚本，在执行期间希望改变身份，比如希望以某个已经建立好的用户来运行某个服务进程，不要使用 su 或者 sudo，这些都需要比较麻烦的配置，而且在 TTY 缺失的环境下经常出错。建议使用 gosu

• RUN
  • 在容器中运行指定的命令；每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更
  • 执行命令并创建新的镜像层，RUN经常用于安装软件包和应用
  • 它有两种格式：
    • shell格式：RUN <命令>，就像直接在命令行中输入的命令一样。
      • RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
    • exec格式：RUN ["可执行文件", "参数1", "参数2"]，这更像是函数调用中的格式。

 

• CMD
  • 容器就是进程。既然是进程，那么在启动容器的时候，需要指定所运行的程序及参数。CMD 指令就是用于指定默认的容器主进程的启动命令的。在运行时可以指定新的命令来替代镜像设置中的这个默认命令。可以有多个CMD命令，但是有最后一个生效。
    • CMD可以被docker run之后的参数替换
  • 在指令格式上，一般推荐使用 exec 格式，这类格式在解析时会被解析为 JSON 数组，因此一定要使用双引号 "，而不要使用单引号。
  • 对于容器而言，其启动程序就是容器应用进程，容器就是为了主进程而存在的，主进程退出，容器就失去了存在的意义，从而退出，其它辅助进程不是它需要关心的东西。
• ENTRYPOINT
  • ENTRYPOINT 的目的和 CMD 一样，都是在指定容器启动程序及参数。ENTRYPOINT 在运行时也可以替代，不过比 CMD 要略显繁琐，需要通过 docker run 的参数 --entrypoint 来指定。。可以有多个ENTRYPOINT命令，但是有最后一个生效
  • 当指定了 ENTRYPOINT 后，CMD 的含义就发生了改变，不再是直接的运行其命令，而是将 CMD 的内容作为参数传给 ENTRYPOINT 指令，换句话说实际执行时，将变为：<ENTRYPOINT> "<CMD>"
    • CMD或docker run之后的参数会被当作参数传递给ENTRYPOINT

• shell
  • SHELL 指令可以指定 RUN ENTRYPOINT CMD 指令的 shell，Linux 中默认为 ["/bin/sh", "-c"]
  • 格式：SHELL ["executable", "parameters"]

 

Dockerfile 支持 Shell 类的行尾添加 \ 的命令换行方式，以及行首 # 进行注释的格式。

因此镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉。