Dockfile是一种被Docker程序解释的脚本,Dockerfile由一条一条的指令组成,每条指令对应Linux下面的一条命令。Docker程序将这些Dockerfile指令翻译真正的Linux命令。Dockerfile有自己书写格式和支持的命令,Docker程序解决这些命令间的依赖关系,类似于Makefile。Docker程序将读取Dockerfile,根据指令生成定制的image。相比image这种黑盒子,Dockerfile这种显而易见的脚本更容易被使用者接受,它明确的表明image是怎么产生的。有了Dockerfile,当我们需要定制自己额外的需求时,只需在Dockerfile上添加或者修改指令,重新生成image即可,省去了敲命令的麻烦。

前文提到了如何拉取tomcat镜像和运行,本文基于Tomcat来定制镜像。最后会对常用的Dockerfile命令汇总归纳。

Dockerfile定制

准备工作

1. 在/usr/local目录下创建docker文件夹,然后在docker文件夹下创建tomcat文件夹,这样做是为了将用户配置归类分开。

2. 使用命令创建Dockerfile文件

touch Dockerfile

编写Dockerfile文件

需要实现的功能:tomcat启动的时候的界面应该都清除,我们需要做的就是替换tomcat的默认界面。

Dockerfile内容如下:

FROM tomcat
RUN echo 'HELLO Docker' > /usr/local/tomcat/webapps/ROOT/index.html

FROM命令:

FROM用于指定基础镜像,这就和之前提到的Docker分层契合。所谓的定制镜像,就一定是在一个基础镜像的基础上进行构建的。基础镜像是必须要指定的,而FROM就是指定基础镜像的,所以FROM是Dockerfile必备的一个指定,而且是第一条指令。

RUN命令:

RUN 指令是用来执行命令行命令的。由于命令行的强大能力,RUN 指令在定制镜像时是最常用的指令之一。其格式有两种:

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

RUN echo 'HELLO Docker' > /usr/local/tomcat/webapps/ROOT/index.html

2. exec 格式:RUN ["可执行文件", "参数1", "参数2"],这更像是函数调用中的格式。(不过多介绍,Shell很好用)

ps:Dockerfile 支持 Shell 类的行尾添加 \ 的命令换行方式,以及行首 # 进行注释的格式。良好的格式,比如换行、缩进、注释等,会让维护、排障更为容易,这是一个比较好的习惯。

构建镜像

上一步已经基于tomcat创建了一个非常简单的Dockerfile文件,接下来基于这个Dockerfile文件创建一个Docker镜像。

使用命令Docker build -t myTomcat .

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

输出结果如下:

root@iZwz99z2ljzabken0hvkjrZ:/usr/local/docker/tomcat# docker build -t mytomcat . 
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM tomcat
latest: Pulling from library/tomcat
Digest: sha256:80db17f3efd9cdcd9af7c799097fe0d223bbee8f25aa36234ab56292e3d8bd7b
Status: Downloaded newer image for tomcat:latest
 ---> 96c4e536d0eb
Step 2/2 : RUN echo 'HELLO Docker' > /usr/local/tomcat/webapps/ROOT/index.html
 ---> Running in c3c023794614
Removing intermediate container c3c023794614
 ---> d163cc98edca
Successfully built d163cc98edca
Successfully tagged mytomcat:latest

注意命令中的一个.,这个.的作用是告诉Docker当前的上下文环境。

接下来使用命令以交互的方式进入到mytomcat这个镜像中:

docker run -it mytomcat bash

查看/usr/local/tomcat/webapps/ROOT下的index.html是否为我们之前写入的‘'HELLO Docker’。

root@iZwz99z2ljzabken0hvkjrZ:/usr/local/docker/tomcat# docker run -it mytomcat bash
root@ffcf70e7045e:/usr/local/tomcat# ls
BUILDING.txt     LICENSE  README.md      RUNNING.txt  conf     lib   native-jni-lib  webapps
CONTRIBUTING.md  NOTICE   RELEASE-NOTES  bin          include  logs  temp            work
root@ffcf70e7045e:/usr/local/tomcat# cd webapps/
root@ffcf70e7045e:/usr/local/tomcat/webapps# ls
ROOT  docs  examples  host-manager  manager
root@ffcf70e7045e:/usr/local/tomcat/webapps# cd ROOT/
root@ffcf70e7045e:/usr/local/tomcat/webapps/ROOT# ls
RELEASE-NOTES.txt  asf-logo-wide.svg  bg-middle.png  bg-upper.png  index.html  tomcat-power.gif  tomcat.gif  tomcat.svg
WEB-INF            bg-button.png      bg-nav.png     favicon.ico   index.jsp   tomcat.css        tomcat.png
root@ffcf70e7045e:/usr/local/tomcat/webapps/ROOT# cat index.html 
HELLO Docker

接下来启动mytomcat

root@iZwz99z2ljzabken0hvkjrZ:/usr/local/docker/tomcat# docker run -p 9001:8080 -d mytomcat

打开浏览器就可以看到之前修改的index.html的界面。

Docker Context上下文

前面说到了Docker build命令最后面有一个.,.表示当前目录,所以会自然而然的认为这个.表示的就是Dockerfile所在的路径,其实不尽然,这个.也代表当前的上下文环境。

首先我们要理解 docker build 的工作原理。Docker 在运行时分为 Docker 引擎(也就是服务端守护进程)和客户端工具。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 常用指令

COPY复制文件

命令格式:

COPY <源路径>... <目标路径>
COPY ["<源路径1>",... "<目标路径>"]

和 RUN 指令一样,也有两种格式,一种类似于命令行,一种类似于函数调用。

COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。比如:

COPY package.json /usr/src/app/

<源路径> 可以是多个,甚至可以是通配符,其通配符规则要满足 Go 的 filepath.Match 规则,如:

COPY hom* /mydir/
COPY hom?.txt /mydir/

<目标路径> 可以是容器内的绝对路径,也可以是相对于工作目录的相对路径(工作目录可以用 WORKDIR 指令来指定)。目标路径不需要事先创建,如果目录不存在会在复制文件前先行创建缺失目录。

ENV 设置环境变量

格式有两种:

ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...

这个指令很简单,就是设置环境变量而已,无论是后面的其它指令,如 RUN,还是运行时的应用,都可以直接使用这里定义的环境变量。

ENV VERSION=1.0 DEBUG=on \

    NAME="Happy Feet"

这个例子中演示了如何换行,以及对含有空格的值用双引号括起来的办法,这和 Shell 下的行为是一致的。

定义了环境变量,那么在后续的指令中,就可以使用这个环境变量。比如在官方 node 镜像 Dockerfile 中,就有类似这样的代码:

ENV NODE_VERSION 7.2.0

RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.xz" \

  && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \

  && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \

  && grep " node-v$NODE_VERSION-linux-x64.tar.xz\$" SHASUMS256.txt | sha256sum -c - \

  && tar -xJf "node-v$NODE_VERSION-linux-x64.tar.xz" -C /usr/local --strip-components=1 \

  && rm "node-v$NODE_VERSION-linux-x64.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \

  && ln -s /usr/local/bin/node /usr/local/bin/nodejs

在这里先定义了环境变量 NODE_VERSION,其后的 RUN 这层里,多次使用 $NODE_VERSION 来进行操作定制。可以看到,将来升级镜像构建版本的时候,只需要更新 7.2.0 即可,Dockerfile 构建维护变得更轻松了。

VOLUME 定义匿名卷

格式为:

VOLUME ["<路径1>", "<路径2>"...]
VOLUME <路径>

之前我们说过,容器运行时应该尽量保持容器存储层不发生写操作,对于数据库类需要保存动态数据的应用,其数据库文件应该保存于卷(volume)中。为了防止运行时用户忘记将动态文件所保存目录挂载为卷,在 Dockerfile 中,我们可以事先指定某些目录挂载为匿名卷,这样在运行时如果用户不指定挂载,其应用也可以正常运行,不会向容器存储层写入大量数据。

VOLUME /data

这里的 /data 目录就会在运行时自动挂载为匿名卷,任何向 /data 中写入的信息都不会记录进容器存储层,从而保证了容器存储层的无状态化。当然,运行时可以覆盖这个挂载设置。比如:

docker run -d -v mydata:/data xxxx

在这行命令中,就使用了 mydata 这个命名卷挂载到了 /data 这个位置,替代了 Dockerfile 中定义的匿名卷的挂载配置。

WORKDIR 指定工作目录

格式为 :

WORKDIR <工作目录路径>

使用 WORKDIR 指令可以来指定工作目录(或者称为当前目录),以后各层的当前目录就被改为指定的目录,如该目录不存在,WORKDIR 会帮你建立目录。

之前提到一些初学者常犯的错误是把 Dockerfile 等同于 Shell 脚本来书写,这种错误的理解还可能会导致出现下面这样的错误:

RUN cd /app
RUN echo "hello" > world.txt

如果将这个 Dockerfile 进行构建镜像运行后,会发现找不到 /app/world.txt 文件,或者其内容不是 hello。原因其实很简单,在 Shell 中,连续两行是同一个进程执行环境,因此前一个命令修改的内存状态,会直接影响后一个命令;而在 Dockerfile 中,这两行 RUN 命令的执行环境根本不同,是两个完全不同的容器。这就是对 Dockerfile 构建分层存储的概念不了解所导致的错误。

之前说过每一个 RUN 都是启动一个容器、执行命令、然后提交存储层文件变更。第一层 RUN cd /app 的执行仅仅是当前进程的工作目录变更,一个内存上的变化而已,其结果不会造成任何文件变更。而到第二层的时候,启动的是一个全新的容器,跟第一层的容器更完全没关系,自然不可能继承前一层构建过程中的内存变化。

因此如果需要改变以后各层的工作目录的位置,那么应该使用 WORKDIR 指令。