Docker入门实践之dokerfile编写（1）

   Dockerfile是一个文本格式的配置文件，经过dockerfile能够快速建立自定义镜像以适应测试，预发布，生产环境等各类应用部署镜像，一个好的dockerfile可让咱们的镜像更方便管理以及应用。

一. Dokerfile的基本结构

Dockfile是由一行行命令语句组成，而且迟滞以#开头的注释行；通常而言，Dockerfiel分为四部分：
1.基础镜像信息 ；2.维护者信息；3.镜像操做指令；4.容器启动时指令，以下为一个标准的dockfile镜像模板：

# This dockerfile uses the ubutu image
# VERSION 2 - EDITON 1
# Author docker_user
# Command format: Instruction [arguments / command ] ..

# (第一部分) 基础镜像信息 
FROM ubuntu

# (第二部分) 维护者信息
MAINTAINER docker_user docker_user@email.com

#（第三部分）镜像操做指令 
RUN yum install apr-devel -y

    #（第四部分) 容器启动时指令
CMD /usr/sbin/echo

从上面能够看到一个基本的dockerfile实例包含：1.基础镜像信息， 2.维护者信息，3.镜像操做指令，4容器启动时指令这四个要素

二. Dokerfile镜像操做指令

dockerfiel镜像操做指令通常格式为： Instruction arguments 其指令包括：FORM MAINTAINER RUN 等等指令

1. FROM 引用基础镜像

格式为：FORM <image> 或FORM <image>:<tag>
第一条指令必须为FORM指令，若是在同一个dockerfile文件中建立多个镜像时，可使用多个FROM指令（每一个镜像一次）

在 Docker Store 上有很是多的高质量的官方镜像，有能够直接拿来使用的服务类的镜像，如 nginx、redis、mongo、mysql、httpd、php、tomcat 等；也有一些方便开发、构建、运行各类语言应用的镜像，如 node、openjdk、python、ruby、golang 等。能够在其中寻找一个最符合咱们最终目标的镜像为基础镜像进行定制。若是没有找到对应服务的镜像，官方镜像中还提供了一些更为基础的操做系统镜像，如 ubuntu、debian、centos、fedora、alpine 等，这些操做系统的软件库为咱们提供了更广阔的扩展空间。

除了选择现有镜像为基础镜像外，Docker 还存在一个特殊的镜像，名为 scratch。这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像。

FROM scratch
...

若是你以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将做为镜像第一层开始存在。不以任何系统为基础，直接将可执行文件复制进镜像的作法并不罕见，好比 swarm、coreos/etcd。对于 Linux 下静态编译的程序来讲，并不须要有操做系统提供运行时支持，所需的一切库都已经在可执行文件里了。

所以直接 FROM scratch 会让镜像体积更加小巧。使用 Go 语言 开发的应用不少会使用这种方式来制做镜像，这也是为何有人认为 Go 是特别适合容器微服务架构的语言的缘由之一。

2. MAINTAINER 维护者信息

格式为MAINTAINER <name>, 指定维护者信息

3. RUN 执行命令

RUN 指令是用来执行命令行命令的。因为命令行的强大能力，RUN 指令在定制镜像时是最经常使用的指令之一。其格式有两种：

3.1.shell 格式：

RUN <命令>，就像直接在命令行中输入的命令同样。刚才写的 Dockerfile 中的 RUN 指令就是这种格式。

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

3.2.exec 格式：

RUN ["可执行文件", "参数1", "参数2"]，这更像是函数调用中的格式。既然 RUN 就像 Shell 脚本同样能够执行命令，那么咱们是否就能够像 Shell 脚本同样把每一个命令对应一个 RUN 呢？好比这样：

FROM debian:jessie

RUN apt-get update
RUN apt-get install -y gcc libc6-dev make
RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-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 中每个指令都会创建一层，RUN 也不例外。每个 RUN 的行为，就和刚才咱们手工创建镜像的过程同样：新创建一层，在其上执行这些命令，执行结束后，commit 这一层的修改，构成新的镜像。而上面的这种写法，建立了 7 层镜像。这是彻底没有意义的，并且不少运行时不须要的东西，都被装进了镜像里，好比编译环境、更新的软件包等等。结果就是产生很是臃肿、很是多层的镜像，不只仅增长了构建部署的时间，也很容易出错。 这是不少初学 Docker 的人常犯的一个错误。Union FS 是有最大层数限制的，好比 AUFS，曾经是最大不得超过 42 层，如今是不得超过 127 层。

上面的 Dockerfile 正确的写法应该是这样：

FROM debian:jessie

RUN  buildDeps='gcc libc6-dev make' \
    && apt-get update \
    && apt-get install -y $buildDeps \
    && wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
    && mkdir -p /usr/src/redis \
    && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=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 对一一对应不一样的命令，而是仅仅使用一个 RUN 指令，并使用 && 将各个所需命令串联起来。将以前的 7 层，简化为了 1 层。在撰写 Dockerfile 的时候，要常常提醒本身，这并非在写 Shell 脚本，而是在定义每一层该如何构建。而且，这里为了格式化还进行了换行。Dockerfile 支持 Shell 类的行尾添加 \ 的命令换行方式，以及行首 # 进行注释的格式。良好的格式，好比换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。

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

编写Docker制做出了很臃肿的镜像的缘由之一，就是忘记了每一层构建的最后必定要清理掉无关文件。

4. COPY 复制文件

复制本地主机<src> (为dockerfile所在的目录的相对路径，文件或目录) <dest>为容器中的路径,当目标路径不存在时,会自动建立,通常格式为：

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

和 RUN 指令同样，也有两种格式，一种相似于命令行，一种相似于函数调用。
COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的 <目标路径> 位置。好比：

COPY package.json /usr/src/app/

<源路径> 能够是多个，甚至能够是通配符，其通配符规则要知足 Go 的 filepath.Match 规则，如：

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

<目标路径> 能够是容器内的绝对路径，也能够是相对于工做目录的相对路径（工做目录能够用 WORKDIR 指令来指定）。目标路径不须要事先建立，若是目录不存在会在复制文件前先行建立缺失目录。

此外，还须要注意一点，使用 COPY 指令，源文件的各类元数据都会保留。好比读、写、执行权限、文件变动时间等。这个特性对于镜像定制颇有用。特别是构建相关文件都在使用 Git 进行管理的时候。

5. ADD更高级的复制文件

好比 <源路径> 是一个 URL，这种状况下，Docker 引擎会试图去下载这个连接的文件放到 <目标路径> 去。下载后的文件权限自动设置为 600，若是这并非想要的权限，那么还须要增长额外的一层 RUN 进行权限调整，另外，若是下载的是个压缩包，须要解压缩，也同样还须要额外的一层 RUN 指令进行解压缩。因此不如直接使用 RUN 指令，而后使用 wget 或者 curl 工具下载，处理权限、解压缩、而后清理无用文件更合理。所以，这个功能其实并不实用，并且不推荐使用。

若是 <源路径> 为一个 tar 压缩文件的话，压缩格式为 gzip, bzip2 以及 xz 的情下，ADD 指令将会自动解压缩这个压缩文件到 <目标路径> 去。在某些状况下，这个自动解压缩的功能很是有用，好比官方镜像 ubuntu 中：

FROM scratch
ADD ubuntu-xenial-core-cloudimg-amd64-root.tar.gz /
...

但在某些状况下，若是复制个压缩文件，而不解压缩，这时就不可使用 ADD 命令了。尽量的使用 COPY，由于 COPY 的语义很明确，就是复制文件而已，而 ADD 则包含了更复杂的功能，其行为也不必定很清晰。最适合使用 ADD 的场合，就是所说起的须要自动解压缩的场合。所以在 COPY 和 ADD 指令中选择的时候，能够遵循这样的原则，全部的文件复制均使用 COPY 指令，仅在须要自动解压缩的场合使用 ADD。

6 .ENV设置环境变量

格式有两种：

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

env就是设置环境变量，不管是后面的其它指令，如 RUN，仍是运行时的应用，均可以直接使用env定义的环境变量。以下所示定义了环境变量，那么在后续的指令中，就可使用这个环境变量：

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

这和 Shell 下的行为是一致的。

7 . VOLUME 定义匿名卷

格式为：

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

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

VOLUME /data

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

docker run -d -v mydata:/data xxxx

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

8. 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 指令。例如：

WORKDIR /a
WORKDIR b
WORKDIR c
则最终路径为：/a/b/c

注意可使用多个WORKDIR指令，后续指令若是为相对路径，则会基于以前命令指定路径，述上所示。

9. USER 指定当前用户

格式：USER <用户名>

USER 指令和 WORKDIR 类似，都是改变环境状态并影响之后的层。WORKDIR 是改变工做目录，USER 则是改变以后层的执行 RUN, CMD 以及 ENTRYPOINT 这类命令的身份。固然，和 WORKDIR 同样，USER 只是帮助你切换到指定用户而已，这个用户必须是事先创建好的，不然没法切换。

RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]

若是以 root 执行的脚本，在执行期间但愿改变身份，好比但愿以某个已经创建好的用户来运行某个服务进程，不要使用 su 或者 sudo，这些都须要比较麻烦的配置，并且在 TTY 缺失的环境下常常出错。建议使用 gosu。以下所示：

# 创建 redis 用户，并使用 gosu 换另外一个用户执行命令
RUN groupadd -r redis && useradd -r -g redis redis
# 下载 gosu
RUN wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/1.7/gosu-amd64" \
    && chmod +x /usr/local/bin/gosu \
    && gosu nobody true
# 设置 CMD，并以另外的用户执行
CMD [ "exec", "gosu", "redis", "redis-server" ]