摘要：正确的做法是直接执行可执行文件，并且要求以前台形式运行。官方镜像官方镜像在这里先定义了环境变量，其后的这层里，多次使用来进行操作定制。只有当以当前镜像为基础镜像，去构建下一级镜像的时候才会被执行。

介绍

Dockerfile 是一个文本文件，里面包含了一条条的指令，每一条指令构建一层，因此每一条指令的内容都是描述该层如何构建。

使用dockerfile的好处

避免了docker commit方式带来的臃肿，实际应用中不应采用docker commit.

基本流程

mkdir mynginx
cd mynginx
touch Dockerfile

vim Dockerfile,写入
FROM nginx
RUN echo "
Hello, Docker!
" > /usr/share/nginx/html/index.html

构建镜像
docker build -t nginx:v3 .  # 注意最后面有一个点

or docker build - < Dockerfile #从标准输入中读取 Dockerfile 进行构建
or cat Dockerfile | docker build -

or docker build http://server/context.tar.gz  #用给定的 tar 压缩包构建

or docker build https://github.com/twang2218/gitlab-ce-zh.git#:8.14 # 直接用 Git repo 进行构建
or docker build - < context.tar.gz # 从标准输入中读取上下文压缩包进行构建

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

    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

    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

  COPY ./package.json /app/
  这并不是要复制执行 docker build 命令所在的目录下的 package.json ，也不是复制
  Dockerfile 所在目录下的 package.json ，而是复制 上下文（context） 目录下的
  package.json 

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

shell格式: CMD echo $HOME
实际执行: CMD [ "sh", "-c", "echo $HOME" ]
Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，
用 upstart/systemd 去启动后台服务，容器内没有后台服务的概念。

CMD service nginx start
这个命令会被理解为 CMD [ "sh", "-c", "service nginx start"] ，因此主进程实际上是 sh 。
那么当 service nginx start 命令结束后， sh 也就结束了， sh 作为主进程退出了，自然就会令容器退出。

正确的做法是直接执行 nginx 可执行文件，并且要求以前台形式运行。比如：
CMD ["nginx", "-g", "daemon off;"]

场景一：让镜像变成像命令一样使用

错误的示范

FROM ubuntu:16.04
RUN apt-get update 
&& apt-get install -y curl 
&& rm -rf /var/lib/apt/lists/*
CMD [ "curl", "-s", "http://ip.cn" ]

docker build -t myip .
docker run myip
docker run myip -i # 如果加上-i参数,就会报错

正确的示范

FROM ubuntu:16.04
RUN apt-get update 
&& apt-get install -y curl 
&& rm -rf /var/lib/apt/lists/*
ENTRYPOINT [ "curl", "-s", "http://ip.cn" ]

场景二：应用运行前的准备工作

启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。
官方redis镜像

FROM alpine:3.4
...
RUN addgroup -S redis && adduser -S -G redis redis
...
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 6379
CMD [ "redis-server" ]

docker-entrypoint.sh
#!/bin/sh
...
# allow the container to be started with `--user`
if [ "$1" = "redis-server" -a "$(id -u)" = "0" ]; then
chown -R redis .
exec su-exec redis "$0" "$@"
fi
exec "$@"

官方node镜像
ENV NODE_VERSION 7.2.0
RUN curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.ta
r.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 构建维护变得更轻松了。
下列指令可以支持环境变量展开：
ADD 、 COPY 、 ENV 、 EXPOSE 、 LABEL 、 USER 、 WORKDIR 、 VOLUME 、 STOPSIGNAL 、 ONBUILD 。

Dockerfile 中的 ARG 指令是定义参数名称，以及定义其默认值。该默认值可以在构建命令
docker build 中用 --build-arg <参数名>=<值> 来覆盖。

VOLUME /data
这里的 /data 目录就会在运行时自动挂载为匿名卷，任何向 /data 中写入的信息都不会记录进容器存储层，
从而保证了容器存储层的无状态化。当然，运行时可以覆盖这个挂载设置。
docker run -d -v mydata:/data xxxx
在这行命令中，就使用了 mydata 这个命名卷挂载到了 /data 这个位置，替代了Dockerfile 中定义的匿名卷的挂载配置。

要将 EXPOSE 和在运行时使用 -p <宿主端口>:<容器端口> 区分开来。 -p ，是映射宿主端口和
容器端口，换句话说，就是将容器的对应端口服务公开给外界访问，而 EXPOSE 仅仅是声明
容器打算使用什么端口而已，并不会自动在宿主进行端口映射

错误的示例

初学者常犯的错误是把 Dockerfile 等同于 Shell 脚本来书写
RUN cd /app
RUN echo "hello" > world.txt

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

USER 指令和 WORKDIR 相似，都是改变环境状态并影响以后的层,用户需提前建好.
RUN groupadd -r redis && useradd -r -g redis redis
USER redis
RUN [ "redis-server" ]

FROM nginx
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
HEALTHCHECK --interval=5s --timeout=3s 
CMD curl -fs http://localhost/ || exit 1
这里我们设置了每 5 秒检查一次（这里为了试验所以间隔非常短，实际应该相对较长），如
果健康检查命令超过 3 秒没响应就视为失败，并且使用 curl -fs http://localhost/ || exit
1 作为健康检查命令。

查看 docker inspect --format "{{json .State.Health}}" web | python -m json.tool

ONBUILD 是一个特殊的指令，它后面跟的是其它指令，比如 RUN , COPY 等，而这些指令，
在当前镜像构建时并不会被执行。只有当以当前镜像为基础镜像，去构建下一级镜像的时候才会被执行。
Dockerfile 中的其它指令都是为了定制当前镜像而准备的，唯有 ONBUILD 是为了帮助别人定制自己而准备的。

假设一个node.js的dockerfile如下

FROM node:slim
RUN mkdir /app
WORKDIR /app
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
CMD [ "npm", "start" ]

现在有其他的镜像依赖这个镜像,假设基础镜像叫my-node

FROM node:slim
RUN mkdir /app
WORKDIR /app
CMD [ "npm", "start" ]

那么其他依赖的子项目的镜像为

FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/
基础镜像变化后，各个项目都用这个 Dockerfile 重新构建镜像，会继承基础镜像的更新
但是问题只解决了一半,如果这个子Dockerfile 里面有些东西需要调整呢？
比如 npm install 都需要加一些参数，那怎么办？这一行 RUN 是不可能放入基础镜像的，
因为涉及到了当前项目的 ./package.json ，难道又要一个个修改么？
所以说，这样制作基础镜像，只解决了原来的 Dockerfile 的前4条指令的变化问题，
而后面三条指令的变化则完全没办法处理。

用ONBUILD重写基础镜像

FROM node:slim
RUN mkdir /app
WORKDIR /app
ONBUILD COPY ./package.json /app
ONBUILD RUN [ "npm", "install" ]
ONBUILD COPY . /app/
CMD [ "npm", "start" ]

在用ONBUILD构建基础镜像的时候，这三行并不会被执行

那么子镜像只需

FROM my-node

当在各个项目目录中，用这个只有一行的 Dockerfile 构建镜像时，之前基础镜像的那三行 ONBUILD 就会开始执行，
成功的将当前项目的代码复制进镜像、并且针对本项目执行 npm install ，生成应用镜像

Docker 从入门到实践