月份：2016年12月

CMD指令有三种形式：

Dockerfile只能使用一个CMD指令。如果你使用了多个CMD那么Docker仅使用最后一个。
CMD的主要作用是为执行容器提供默认值。这些默认值可以包括一个可执行程序，或省略可执行程序(这种情况下需要指定一个ENTRYPOINT指令)。

注意：如果CMD用来提供ENTRYPOINT的默认参数，那么CMD和ENTRYPOINT指令应该使用JSON数组的格式。

注意：exec形式使用了JSON数组，意味着字符外使用双引号而不是单引号。

不论使用是的shell或exec格式，CMD指令设置了当运行镜像时要执行的命令。
如果使用CMD的shell形式，那么将在/bin/sh -c执行：

如果你想不调用shell运行你的，那么你必须以JSON数组表示你的命令并给出这个命令的完整路径。这个数组形式是CMD的首先格式。额外的参数必须单独地使用一个数组的字符串表示：

如果你想每次容器都是执行相同的执行程序，那么你应该考虑ENTRYPOINT和CMD一起使用。
如果用户在docker run指定参数，那么将会覆盖CMD指定的默认参数。

注意：不要把RUN和CMD搞混了。RUN实际上是在构建镜像时执行命令并提交执行结果到镜像；而CMD在构建期间不会执行任何命令，只是为镜像预先设置运行时容器时运行的命令或参数。

RUN指令有两种形式：

RUN指令将在当前镜像层上面的一个新数据层执行命令并提交其结果。这个新提交的镜像层将用于Dockerfile的下一步。
分层RUN指令和生成提交符合Docker的核心概念，其中提交成本低，可以从镜像历史中的任何点创建容器，就像源代码控制一样。
exec形式避免了shell字符的模糊处理，并且可以在没有特定shell的base镜像上使用RUN指令。
shell形式中默认的shell可以使用SHELL命令更改。
在shell形式中你可以使用反斜杠在下一行继续这个RUN指令。例如下面两行：

两行相当于：

注意：要在exec形式中使用不同的shell，而不是/bin/sh，传递想用的shell即可，如，[“/bin/bash”, “-c”, “echo hello”]

注意：exec形式是接一个JSON数组，意味着在单词之外使用双引号而不是单引号。

注意：不像shell形式，exec形式不会调用一个shell再执行命令。意味着常规shell处理不会发生。例如，RUN [ “echo”, “$HOME” ]不会替换$HOME为家目录。如果你想处理此情况，可以直接使用shell形式或直接执行一个shell。如RUN [ “sh”, “-c”, “echo $HOME” ]。

注意：在JSON格式中，有必要转义反斜杠，特别是windows中使用反斜杠作为路径分隔符的情况。[“c:windowssystem32tasklist.exe”] 会视为shell形式，因为这不是一个有效的JSON格式，正确的语法是RUN [“c:\windows\system32\tasklist.exe”]。

RUN指令的缓存不会在下一次构建镜像时自动失效。一个指令的缓存如RUN apt-get dist-upgrade -y会在下一次构建中重用。可以使用–no-cache参数来使RUN指令的缓存失效，例如docker build –no-cache。

FROM

或

或

FROM指令为随后的指令设置一个Base Image。因此，一个有效的Dockerfile的第一个指令必须是FROM。镜像可以是任意有效的镜像 – 这个很容易从公共仓库拉取一个镜像。

MAINTAINER

MAINTAINER指令允许你设置生成这个镜像的作者。

在docker CLi发送上下文到docker daemon之前，它首先先在上下文的根目录查找名为.dockerignore的文件。如果这个文件存在，CLI则更改上下文来排除与这文件里的模式匹配的文件和目录。这帮助避免了发送不必要的大的或敏感的文件和目录到daemon，以及有可能使用ADD或COPY把不必要的文件添加到镜像。
CLI解析.dockerignore为以行为分隔的模式列表，类似于Unix shells的golbs文件。基于匹配的目的，上下文的根目录可以是工作目录或根目录。例如，/foo/bar和foo/bar模式都是排除PATH或URL git仓库根目录的子目录foo下的bar文件。
如果.dockerignore中的一行以#开始，那么这行视为注释，会以CLI解析前忽略。
例如：

行为解释如下：

使用Go的filepath.Match规则完成匹配。除了Go的filepath.Match规则，docker也支持一个特殊的通配符**，用来匹配任意数量的目录。如**/*.go将排除在所有目录中以.go后缀的文件，包括根目录。
以!开始的行表示与排除相反的动作，即包括。如下：

除了README.md，其它的.md文件排除。
放置!例外规则影响的行为：.dockerignore的最后行匹配的文件决定是否是包含或排除。如下：

除了README markdown文件（不含README-secret.md），其它的markdown文件包括全都排除。
再看一个例子：

包括所有的README文件。中间的行没有影响是因为!README*.md匹配了README-secret.md。
你甚至可以使用.dockerignore文件来排除Dockerfile和.dockerignore文件。这些排除的文件仍然会发送到daemon，因为需要它们来工作。不过ADD和COPY命令不再复制它们到镜像。
最后，你可能想指定包括一些文件，而不是排除。那么可以在第一行输入*，随后的行使用!来包括。

注意：由于历史原因，模式.会被忽略。

由EVN指令声明的环境变量也可以用在Dockerfile的一些指令中作为变量使用。转义符也将类似变量的语法转义为语句。
在Dockerfile引用环境变量可以使用$variable_name或${variable_name}。它们是等同的，其中大括号的变量是用在没有空格的变量名中的，如${foo}_bar。
${variable_name}变量也支持一些标准的bash修饰符，如：

word可以是任意的字符，包括额外的环境变量。
转义符可以添加在变量前面：$foo or ${foo}，例如，会分别转换为$foor和${foo}。
示例：

环境变量支持在下面的指令中使用：

也包括：

注意：1.4之前的版本，ONBUILD指令不支持环境变量，即使是与上面列出的指令一起使用。

环境变量的替换在整个命令使用的值是一样的。例如：

def的值是hello，不是bye，不过，ghi的值为bye，因为设置abc为bye的命令与设置ghi命令不同。

解释器指令是可选的，并影响Dockerfile随后行的处理方式。解释器指令不会添加新层到镜像，也不会显示在构建步骤中。解释器指令的编写格式是一种特定的注释格式# directive=value。一个指令只能用一次。
一旦注释，空行或构建器指令已经被处理，Docker不再寻找解析器指令。相反，它将格式化为解析器指令的任何内容视为注释，并且不尝试验证它是否可能是解析器指令。因此，所有解析器指令必须位于Dockerfile的最顶端。
解析器指令不区分大小写。不过，约定使用小写。也约定解释器指令后包括一个新空行。解析器指令不支持行连续字符。
由于这些规则，下面的示例都是无效的：
由于使用了行连续字符无效：

由于出现两次相同的解释器指令：

由于出现在构建指令后，所以视为注释：

由于出现在不是解释器指令的注释后面，视为一个注释：

由于不被识别，未知的指令视为一个注释。此外由于出现在不是解释器指令的注释后面，一个已知的指令也视为注释。

解析器指令中允许使用非换行符空格。因此，下面的指令视为同样的：

目前支持的解释器指令有：

escape

格式为：

或

escape指令用于设置在Dockerfile中转义使用的字符。如果不指定，默认的转义字符是。
转义字符用来转义一行中的字符，也可以转义一个新行。这就允许Dockerfile的指令跨越多行。注意，不管escape解析器指令是否包括在Dockerfile中，除了在行尾转义新行 RUN命令中不进行字符转义。
设置转义字符`对于windows上使用Dockerfile非常有用，因为默认的是目录路径的分隔符。而`与Windows PowerShell使用的转义字符一致。
看下下面的在windows Dockerfile的示例，不是很显然地看出错误。第二行行尾的第二个解释为转义新行，而不是第一个的转义目标。结果是这个Dockerfile的第2行和第3行合并为一行处理：

构建时输出:

上面的一个解决方法是使用/作为COPY和dir的路径分隔符。不过这个语法最好的结果是只会由于不是windows原生的分隔符感到混乱，最糟糕的情况是会导致错误，因为windows不是所有的命令都支持这个分隔符。
所以最好的解决方法是使用excape解释器指令来指令`作为分隔符：

结果：

下面是Dockerfile的格式：

instruction指令是不区分大小写的，不过一般约定使用大写字符以与参数区分开来。
docker按顺序执行Dockerfile中的指令。第一个指令必须是FROM，用于指定从哪个Base Image构建镜像。
Docker把以#开头的行视为注释，除非该行是一个有效的解释器指令。#标志在行中的其它地方视为一个参数，如：

注释中不支持行连续字符。

docker build命令从Dockerfile文件和上下文构建一个镜像。构建的上下文是一个指定的PATH或URL位置。PATH是你本地文件系统的一个目录。URL是git仓库地址。
上下文是递归处理的。所以PATH包括所有的子目录，URL包括仓库和它的子模块。下面是使用当前目录作为上下文的简单build命令：

build命令来docker daemon运行，不是由CLI。build进程的第一件事是递归发送整个上下文给daemon。大多数情况下，最好使用一个空的目录作为上下文并放置Dockerfile到此目录。只添加构建Dockerfile时所需的文件。

警告：不要使用root目录/作为PATH，因为它会导致build传递你硬盘的所有内容到docker daemon。

Dockerfile包括了一系列用于构建镜像的指令，例如COPY指令。为了提高构建性能，可以通过添加.dockerignore文件到上下文目录来排除文件和目录。
通常称为Dockerfile的Dockerfile文件放置在上下文的根目录。你可以将docker build与-f参数一起使用来指向你文件系统的任何位置的Dockerfile。

可以使用-t参数指定保存新镜像的仓库和标签：

要标记镜像到多个仓库，可以在build命令中使用多个-t参数：

docker daemon一个接一个运行Dockerfile中的指令，在最后生成新镜像之前，如果需要，将提交每一个指令的结果到新镜像。docker daemon会自动清理你发送过来的上下文。
注意每个指令都是独立运行的，所以RUN cd /tmp不会对下一个指令有任何影响。
如果有可能，docker会重用镜像缓存来加速docker build进程。在控制台输出中使用到缓存时将显示Using cache消息。如：