Dockerfile 中文参考文档
如何写Dockerfile,Dockerfile 参考文档 | Deepzz's Blog https://deepzz.com/post/dockerfile-reference.htmldockerfile官方英文文档 Dockerfile reference - Docker https://docs.docker.com/engine/reference/builder/
如何写Dockerfile,Dockerfile 参考文档 | Deepzz's Blog https://deepzz.com/post/dockerfile-reference.html
dockerfile官方英文文档 Dockerfile reference - Docker https://docs.docker.com/engine/reference/builder/
Dockerfile 参考文档
Dockerfile
Dockerfile
是由一系列命令和参数构成的脚本,一个Dockerfile
里面包含了构建整个image
的完整命令。Docker通过docker build
执行Dockerfile
中的一系列命令自动构建image
。
Dockerfile
其语法非常简单,此页面描述了您可以在Dockerfile中使用的命令。 阅读此页面后,你可以参阅Dockerfile最佳实践。
Usage
docker build
命令从Dockerfile
和context
构建image。context
是PATH
或URL
处的文件。PATH
本地文件目录。 URL
是Git repository的位置。
context
以递归方式处理。因此,PATH
包括任何子目录,URL
包括repository及submodules。一个使用当前目录作为context
的简单构建命令:
构建由Docker守护程序运行,而不是由CLI运行。构建过程所做的第一件事是将整个context(递归地)发送给守护进程。大多数情况下,最好是将Dockerfile
和所需文件复制到一个空的目录,再到这个目录进行构建。
build时添加文件,通过Dockerfile
引用指令中指定的文件,例如COPY
指令。要增加构建的性能,请通过将.dockerignore
文件添加到context
目录中来排除文件和目录。有关如何创建.dockerignore文件的信息,请参阅此页上的文档。
一般的,Dockerfile
位于context
的根中。但使用-f
标志可指定Dockerfile的位置。
如果build成功,您可以指定要保存新image的repository和tag:
要在构建后将image标记为多个repositories,请在运行构建命令时添加多个-t
参数:
Docker守护程序一个接一个地运行Dockerfile
中的指令,如果需要,将每个指令的结果提交到一个新image,最后输出新映像的ID。Docker守护进程将自动清理您发送的context。
请注意,每个指令独立运行,并导致创建一个新image - 因此RUN cd / tmp
对下一个指令不会有任何影响。
只要有可能,Docker将重新使用中间images(缓存),以显着加速docker build
过程。这由控制台输出中的使用缓存消息指示。(有关详细信息,请参阅Dockerfile
最佳实践指南构建缓存部分):
构建成功后,就可以准备Pushing a repository to its registry。
Format
Dockerfile
的格式如下:
INSTRUCTION
是不区分大小写的,不过建议大写。
Dockerfile中的指令第一个指令必需是
FROM`,指定构建镜像的Base Image。
Dockerfile中以#
开头的行都将视为注释,除非是[Parser directives]()解析器指令。不支持连续注释符。
Parser directives
解析器指令是可选的,并且影响处理Dockerfile
中后续行的方式。解析器指令不会向构建中添加图层,并且不会显示在构建步骤。解析器指令是以# directive = value
形式写成一种特殊类型的注释。单个指令只能使用一次。
一旦注释,空行或构建器指令已经被处理,Docker不再寻找解析器指令。相反,它将任何格式化为解析器指令作为注释,并且不尝试验证它是否可能是解析器指令。因此,所有解析器指令必须位于Dockerfile
的最顶端。
解析器指令不区分大小写。然而,约定是他们是小写的。公约还要包括一个空白行,遵循任何解析器指令。解析器指令不支持行连续字符。
由于这些规则,以下示例都无效:
因行延续,无效:
因出现两次,无效:
因写在构建指令后,无效:
因写在不是解析器指令之后,无效:
未知指令视为注释,之后的解析器指令也随之,无效:
解析器指令中允许使用非换行符空格,下面几行被视为相同:
支持以下解析器指令: * escape
escape
escape
指令设置用于在Dockerfile
中转义字符的字符。如果未指定,则缺省转义字符为\
。
转义字符既用于转义行中的字符,也用于转义换行符。这允许Dockerfile
指令跨越多行。注意,不管escape
解析器指令是否包括在Dockerfile
中,在RUN
命令中不执行转义,除非在行的末尾。
将转义字符设置为 ` 在Windows
上特别有用,其中\
是目录路径分隔符。 ` 与Windows PowerShell一致。
请考虑以下示例,这将在Windows
上以非显而易见的方式失败。第二行末尾的第二个\
将被解释为换行符,而不是从第一个\
转义的目标。类似地,假设第三行结尾处的\
实际上作为一条指令处理,它将被视为行继续。这个dockerfile
的结果是第二行和第三行被认为是单个指令:
结果是:
上述的一个解决方案是使用/
作为COPY
指令和dir
的目标。然而,这种语法,最好的情况是混乱,因为它在Windows
上是不平常的路径,最坏的情况下,错误倾向,因为并不是Windows
上的所有命令支持/
作为路径分隔符。
通过添加转义解析器指令,下面的Dockerfile在Windows上使用文件路径的自然平台语义成功:
结果是:
Environment replacement
环境变量(使用ENV语句声明)也可以在某些指令中用作要由Dockerfile
解释的变量。还可以处理转义,以将类似变量的语法包含在语句中。
环境变量在Dockerfile
中用$variable_name
或${variable_name}
表示。它们被等同对待,并且括号语法通常用于解决不带空格的变量名的问题,例如${foo}_bar
。
${variable_name}
语法还支持以下指定的一些标准bash
修饰符: * ${variable:-word}
表示如果设置了variable
,则结果将是该值。如果variable
未设置,那么word
将是结果。 * ${variable:+word}
表示如果设置了variable
,那么word
将是结果,否则结果是空字符串。
在所有情况下,word
可以是任何字符串,包括额外的环境变量。
可以通过在变量之前添加\
来转义:\$foo
或\${foo}
,分别转换为$foo
和${foo}
。
示例(解析的表示显示在#
后面):
Dockerfile
中的以下指令列表支持环境变量: * ADD * COPY * ENV * EXPOSE * LABEL * USER * WORKDIR * VOLUME * STOPSIGNAL
以及: * ONBUILD(当与上面支持的指令之一组合时)
环境变量替换将在整个命令中对每个变量使用相同的值。换句话说,在这个例子中:
将导致def
值为hello
,不再bye
。然而,ghi
的值为bye
,因为它不是设置abc
为bye
的相同命令的一部分。
.dockerignore file
在docker CLI将上下文发送到docker守护程序之前,它会在上下文的根目录中查找名为.dockerignore
的文件。如果此文件存在,CLI将修改上下文以排除匹配其中模式的文件和目录。这有助于避免不必要地向守护程序发送大型或敏感文件和目录,并可能使用ADD
或COPY
将其添加到映像。
CLI将.dockerignore
文件解释为换行符分隔的模式列表,类似于Unix shell
的file globs。为了匹配的目的,上下文的根被认为是工作目录和根目录。例如,模式/foo/bar
和foo/bar
都排除了PATH
的foo
子目录中的名为bar
的文件或目录,或者位于URL
处的git repository的根目录中。也不排除任何其他。
如果.dockerignore
文件中的一行以第1列中以#
开头,则此行被视为注释,并在CLI解释之前被忽略。
这里是一个例子.dockerignore
文件:
此文件导致以下构建行为: |规则|行为| |—-|—-| |# comment
|忽略| |*/temp*
|在根的任何直接子目录中排除其名称以temp开头的文件和目录。 例如,普通文件/somedir/temporary.txt被排除,目录/somedir/temp也被排除。| |*/*/temp*
|从根目录下两级的任何子目录中排除以temp开头的文件和目录。 例如,排除了/somedir/subdir/temporary.txt。| |temp?
|排除根目录中名称为temp的单字符扩展名的文件和目录。 例如,/tempa和/tempb被排除。|
匹配是使用Go的filepath.Match规则完成的。 预处理步骤删除前导和尾随空格并消除.
和..
元素使用Go的filepath.Clean。预处理后为空的行将被忽略。
除了Go的filepath.Match规则,Docker还支持一个特殊的通配符字符串**
,它匹配任何数量的目录(包括零)。 例如,**/*.go
将排除所有目录中找到的以.go
结尾的所有文件,包括构建上下文的根。
行开头!
(感叹号)可用于排除例外。 以下是使用此机制的.dockerignore
文件示例:
除了README.md
之外的所有markdown文件都从上下文中排除。
放置!
异常规则影响行为:匹配特定文件的.dockerignore
的最后一行确定它是包括还是排除。思考下面的例子:
除了README-secret.md
之外的README
文件,上下文中排除所有markdown文件。
现在思考这个例子:
包括所有README文件。 中间行没有效果,因为最后的!README*.md
与README-secret.md
匹配。
您甚至可以使用.dockerignore
文件来排除Dockerfile
和.dockerignore
文件。这些文件仍然发送到守护程序,因为它需要它们来完成它的工作。但是ADD
和COPY
命令不会将它们复制到映像。
最后,您可能需要指定要包括在上下文中的文件,而不是要排除的文件。 要实现这一点,指定*
作为第一个模式,后面跟一个或多个!
异常模式。
注意
:由于历史原因.
模式。被忽略。
FROM
FROM
指令为后续指令设置Base Image。因此,有效的Dockerfile
必须具有FROM
作为其第一条指令。image可以是任何有效的image - 可以从Public Repositories pulling an image。
FROM
必须是Dockerfile
中的第一个非注释指令。FROM
可以在单个Dockerfile
中多次出现,以创建多个图像。只需记下在每个新的FROM
命令之前由提交输出的最后一个image ID。tag
或digest
是可选的。如果省略其中任何一个,构建器将默认使用latest
。如果构建器与tag
值不匹配,则构建器将返回错误。
MAINTAINER
MAINTAINER
指令允许您设置生成的images的作者字段。
RUN
RUN有2种形式: * RUN <command>
(*shell*形式,命令在shell中运行,Linux上为/bin/sh -c
,Windows上为cmd /S/C
) * RUN ["executable","param1","param2"]
(exec 形式)
RUN
指令将在当前image之上的新层中执行任何命令,并提交结果。生成的已提交image将用于Dockerfile
中的下一步。
分层RUN
指令和生成提交符合Docker的核心概念,其中提交很轻量,可以从image历史中的任何点创建容器,就像源代码控制一样。
exec
形式使得可以避免shell字符串变化,以及使用不包含指定的shell可执行文件的基本image来运行RUN
命令。
可以使用SHELL
命令更改shell表单的默认shell。
在shell形式中,可以使用\
(反斜杠)将单个RUN
指令继续到下一行。例如,考虑这两行:RUN /bin/bash -c 'source $HOME/.bashrc ; \ echo $HOME'
它们等同于这一行:RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'
用于RUN
指令的高速缓存在下一次构建期间不会自动失效。用于诸如RUN apt-get dist-upgrade
之类的指令的高速缓存将在下一次构建期间被重用。可以通过使用--no-cache
标志来使用于RUN
指令的高速缓存无效,例如docker build --no-cache
。
有关详细信息,请参阅Dockerfile最佳实践指南。
用于RUN
指令的高速缓存可以通过ADD
指令无效。有关详细信息,请参见下文。
Known issues(RUN)
- Issue 783是关于在使用AUFS文件系统时可能发生的文件权限问题。例如,您可能会在尝试
rm
文件时注意到它。对于具有最近aufs版本的系统(即,可以设置dirperm1
安装选项),docker将尝试通过使用dirperm1
选项安装image来自动解决问题。有关dirperm1
选项的更多详细信息,请参见aufs手册页 如果您的系统不支持dirperm1
,则该问题描述了一种解决方法。
CMD
CMD指令三种形式: * CMD ["executable","param1","param2"]
(exec form, 首选形式) * CMD ["param1","param2"]
(as default parameters to ENTRYPOINT) * CMD command param1 param2
(shell form)
在Dockerfile
中只能有一个CMD
指令。如果您列出多个CMD
,则只有最后一个CMD
将生效。
CMD
的主要目的是为执行容器提供默认值。这些默认值可以包括可执行文件,或者它们可以省略可执行文件,在这种情况下,您还必须指定ENTRYPOINT
指令。
当以shell或exec格式使用时,CMD
指令设置运行image时要执行的命令。
如果使用CMD
的shell形式,那么<command>
将在/bin/sh -c
中执行:
如果你想运行你的<command>
没有shell,那么你必须将该命令表示为一个JSON数组,并给出可执行文件的完整路径。此数组形式是CMD
的首选格式。任何其他参数必须单独表示为数组中的字符串:
如果你希望你的容器每次运行相同的可执行文件,那么你应该考虑使用ENTRYPOINT结合CMD。 请参阅ENTRYPOINT。
如果用户指定docker run
参数,那么它们将覆盖CMD
中指定的默认值。
LABEL
LABEL
指令向image添加元数据。LABEL
是键值对。要在LABEL
值中包含空格,请使用引号和反斜杠,就像在命令行解析中一样。几个使用示例:
image可以有多个label。要指定多个label,Docker建议在可能的情况下将标签合并到单个LABEL
指令中。每个LABEL
指令产生一个新层,如果使用许多标签,可能会导致效率低下的图像。该示例产生单个图像层。
上面的也可写为:
标签是添加的,包括LABEL
在FROM
images中。如果Docker遇到已经存在的label/key,则新值将覆盖具有相同键的任何先前标签。
要查看image的labels,请使用docker inspect
命令。
EXPOSE
EXPOSE
指令通知Docker容器在运行时侦听指定的网络端口。EXPOSE
不使主机的容器的端口可访问。为此,必须使用-p
标志发布一系列端口,或者使用-P
标志发布所有暴露的端口。您可以公开一个端口号,并用另一个端口号在外部发布。
要在主机系统上设置端口重定向,请参阅使用-P标志。Docker网络功能支持创建网络,无需在网络中公开端口,有关详细信息,请参阅此功能的概述)。
ENV
ENV
指令将环境变量<key>
设置为值<value>
。该值将在所有”descendant” Dockerfile
命令的环境中,并且可以在许多中被替换为inline。
ENV
指令有两种形式。第一种形式,ENV <key> <value>
,将单个变量设置为一个值。第一个空格后面的整个字符串将被视为<value>
- 包括空格和引号等字符。
第二种形式,ENV <key> = <value> ...
,允许一次设置多个变量。注意,第二种形式在语法中使用等号(=),而第一种形式不使用。与命令行解析类似,引号和反斜杠可用于在值内包含空格。
例如:
将在最终容器中产生相同的净结果,但第一种形式是优选的,因为它产生单个高速缓存层。
使用ENV
设置的环境变量将在从生成的image运行容器时保留。您可以使用docker inspect
查看值,并使用docker run --env <key> = <value>
更改它们。
AND
两种形式: * ADD <src>... <dest>
* ADD ["<src>",... "<dest>"]
(对于包含空格的路径,此形式是必需的)
ADD
指令从<src>
复制新文件,目录或远程文件URL
,并将它们添加到容器的文件系统,路径<dest>
。
可以指定多个<src>
资源,但如果它们是文件或目录,那么它们必须是相对于正在构建的源目录(构建的context)。
每个<src>
可能包含通配符,匹配将使用Go的filepath.Match规则完成。 例如:
<dest>
是绝对路径或相对于WORKDIR
的路径,源将在目标容器中复制到其中。
所有新文件和目录都使用UID和GID为0创建。
在<src>
是远程文件URL
的情况下,目标将具有600的权限。如果正在检索的远程文件具有HTTP Last-Modified
标头,则来自该标头的时间戳将用于设置目的地上的mtime
文件。然而,像在ADD
期间处理的任何其它文件一样,mtime
将不包括在确定文件是否已经改变并且高速缓存应该被更新。
ADD
遵守以下规则:
<src>
路径必须在构建的上下文中;你不能ADD ../something /something
,因为docker构建的第一步是发送上下文目录(和子目录)到docker守护进程。如果<src>
是URL并且<dest>
不以尾部斜杠结尾,则从URL下载文件并将其复制到<dest>
。- 如果
<src>
是URL并且<dest>
以尾部斜杠结尾,则从URL中推断文件名,并将文件下载到<dest>/<filename>
。例如,ADD http://example.com/foobar /
会创建文件/ foobar
。网址必须有一个非平凡的路径,以便在这种情况下可以发现一个适当的文件名(http://example.com
不会工作)。 - 如果
<src>
是目录,则复制目录的整个内容,包括文件系统元数据。
- 如果
<src>
是识别的压缩格式(identity,gzip,bzip2或xz)的本地tar存档,则将其解包为目录。来自远程URL的资源不会解压缩。当目录被复制或解压缩时,它具有与tar -x
相同的行为:结果是以下的联合:- 无论在目的地路径和
- 源树的内容,冲突以逐个文件为基础解析为“2.”。
- 如果
<src>
是任何其他类型的文件,它会与其元数据一起单独复制。在这种情况下,如果<dest>
以尾部斜杠/
结尾,它将被认为是一个目录,并且<src>
的内容将被写在<dest>/base(<src>)
。 - 如果直接或由于使用通配符指定了多个
<src>
资源,则<dest>
必须是目录,并且必须以斜杠/
结尾。 - 如果
<dest>
不以尾部斜杠结尾,它将被视为常规文件,<src>
的内容将写在<dest>
。 - 如果
<dest>
不存在,则会与其路径中的所有缺少的目录一起创建。
COPY
两种形式: * COPY <src>... <dest>
* COPY ["<src>",... "<dest>"]
(this form is required for paths containing whitespace)
基本和ADD类似,不过COPY
的<src>
不能为URL。
ENTRYPOINT
两种形式: * ENTRYPOINT “executable”, “param1”, “param2” * ENTRYPOINT command param1 param2 (shell 形式)
ENTRYPOINT
允许您配置容器,运行执行的可执行文件。
例如,以下将使用其默认内容启动nginx,侦听端口80:
docker run <image>
的命令行参数将附跟在*exec*形式的ENTRYPOINT
中的所有元素之后,并将覆盖使用CMD
指定的所有元素。这允许将参数传递到入口点,即docker run <image> -d
将把-d
参数传递给入口点。您可以使用docker run --entrypoint
标志覆盖ENTRYPOINT
指令。
*shell*形式防止使用任何CMD
或运行命令行参数,但是缺点是您的ENTRYPOINT
将作/bin/sh -c
的子命令启动,它不传递信号。这意味着可执行文件将不是容器的PID 1
,并且不会接收Unix信号,因此您的可执行文件将不会从docker stop <container>
接收到SIGTERM
。
只有Dockerfile
中最后一个ENTRYPOINT
指令会有效果。
Exec form ENTRYPOINT example
您可以使用ENTRYPOINT
的*exec*形式设置相当稳定的默认命令和参数,然后使用任一形式的CMD
设置更可能更改的其他默认值。
运行容器时,您可以看到top是唯一的进程:
要进一步检查结果,可以使用docker exec
:
并且你可以优雅地请求top
使用docker stop test
关闭。
以下Dockerfile
显示使用ENTRYPOINT
在前台运行Apache
(即,作为PID 1
):
如果需要为单个可执行文件编写启动脚本,可以使用exec
和gosu
命令确保最终可执行文件接收到Unix信号:
最后,如果需要在关闭时进行一些额外的清理(或与其他容器通信),或者协调多个可执行文件,您可能需要确保ENTRYPOINT
脚本接收到Unix信号,传递它们,然后做一些更多的工作:
如果你用docker run -it --rm -p 80:80 --name test apache
运行image,则可以使用·docker exec·或·docker top·检查容器的进程,然后请求脚本停止Apache:
Shell form ENTRYPOINT example
您可以为ENTRYPOINT
指定一个纯字符串,它将在/bin/sh -c
中执行。这中形式将使用shell处理来替换shell环境变量,并且将忽略任何CMD
或docker run
命令行参数。要确保docker stop
将正确地发出任何长时间运行的ENTRYPOINT
可执行文件,您需要记住用exec
启动它:
运行此image时,您将看到单个PID 1
进程:
它奖在docker stop
干净的退出:
如果忘记将exec
添加到您的ENTRYPOINT
的开头:
然后,您可以运行它(给它一个名称为下一步):
您可以从top的输出中看到指定的ENTRYPOINT不是PID 1。
如果你然后运行docker停止测试,容器将不会完全退出 - 停止命令将强制发送SIGKILL超时后:
Understand how CMD and ENTRYPOINT interact
CMD
和ENTRYPOINT
指令定义在运行容器时执行什么命令。这里有较少的规则描述他们的合作。 * Dockerfile
应该至少指定一个CMD
或ENTRYPOINT
命令。 * 当使用容器作为可执行文件时,应该定义ENTRYPOINT
。 * CMD
应该用作定义ENTRYPOINT
命令的默认参数或在容器中执行ad-hoc命令的一种方法。 * 当运行带有替代参数的容器时,CMD
将被覆盖。
下表显示了对不同ENTRYPOINT
/CMD
组合执行的命令:
no ENTRYPOINT | ENTRYPOINT exec_enty p1_entry | ENTRYPOINT [“exec_entry”,“p1_entry”] | |
---|---|---|---|
No CMD | error, not allowed | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry |
CMD [“exec_cmd”,“p1_cmd”] | exec_cmd p1_cmd | /bin/sh -c exec_entry p1_entry exec_cmd p1_cmd | exec_entry p1_entry exec_cmd p1_cmd |
CMD [“p1_cmd”, “p2_cmd”] | p1_cmd p2_cmd | /bin/sh -c exec_entry p1_entry p1_cmd p2_cmd | exec_entry p1_entry p1_cmd p2_cmd |
CMD exec_cmd p1_cmd | /bin/sh -c exec_cmd p1_cmd | /bin/sh -c exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd | exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd |
VOLUME
VOLUME
指令创建具有指定名称的挂载点,并将其标记为从本机主机或其他容器保留外部挂载的卷。该值可以是JSON数组VOLUME ["/var/log/"]
或具有多个参数的纯字符串,例如VOLUME /var/log
或VOLUME /var/log /var/db
。有关通过Docker客户端的更多信息/示例和安装说明,请参阅通过卷文档共享目录。
docker run
命令用存在于基本image中指定位置的任何数据初始化新创建的卷。例如,思考以下Dockerfile
片段:
此Dockerfile docker run
的映像,在/myvol
上创建一个新的挂载点,并将greeting
文件复制到新创建的卷中。
USER
USER
指令设置运行image时使用的用户名或UID,以及Dockerfile
中的任何RUN,CMD
和ENTRYPOINT
指令。
WORKDIR
WORKDIR
指令为Dockerfile
中的任何RUN
,CMD
,ENTRYPOINT
,COPY
和ADD
指令设置工作目录。如果WORKDIR
不存在,它将被创建,即使它没有在任何后续的Dockerfile
指令中使用。
它可以在一个Dockerfile
中多次使用。如果提供了相对路径,它将相对于先前WORKDIR指令的路径。 例如:
在这个Dockerfile
中的最终pwd
命令的输出是/a/b/c
。
WORKDIR
指令可以解析先前使用ENV
设置的环境变量。您只能使用在Dockerfile
中显式设置的环境变量。 例如:
pwd
命令在该Dockerfile
中输出的最后结果是/path/$DIRNAME
。
ARG
ARG
指令定义一个变量,用户可以使用docker build
命令使用--build-arg <varname> = <value>
标志,在构建时将其传递给构建器。如果用户指定了一个未在Dockerfile
中定义的构建参数,构建将输出错误。
Dockerfile作者可以通过指定ARG
一个或多个变量,通过多次指定ARG
来定义单个变量。例如,一个有效的Dockerfile
:
Dockerfile作者可以可选地指定ARG
指令的默认值:
如果ARG
值具有缺省值,并且如果在构建时没有传递值,则构建器使用缺省值。
ARG
变量定义从在Dockerfile
中定义的行开始生效,而不是从命令行或其他地方的参数使用。例如,考虑这个Dockerfile:
用户构建此文件如下:
第2行的USER
将评估为some_user
,因为用户变量在后续行3上定义。第4行的USER
在定义用户时估计为what_user
,在命令行中传递what_user
值。在通过ARG
指令定义之前,变量的任何使用都将导致空字符串。
可以使用ARG
或ENV
指令来指定RUN
指令可用的变量。使用ENV
指令定义的环境变量总是覆盖同名的ARG
指令。思考这个Dockerfile
带有ENV
和ARG
指令。
然后,假设此image是使用此命令构建的:
在这种情况下,RUN
指令使用v1.0.0
而不是用户传递的ARG
设置:v2.0.1
此行为类似于shell脚本,其中本地作用域变量覆盖作为参数传递或从环境继承的变量,从其定义点。
使用上述示例,但使用不同的ENV
规范,您可以在ARG
和ENV
指令之间创建更有用的交互:
与ARG
指令不同,ENV
值始终保留在image中。考虑一个没有-build-arg
标志的docker构建:
使用这个Dockerfile示例,CONT_IMG_VER
仍然保留在映像中,但它的值将是v1.0.0
,因为它是ENV
指令在第3行中的默认设置。
此示例中的变量扩展技术允许您从命令行传递参数,并通过利用ENV
指令将它们持久保存在最终image中。仅对一组有限的Dockerfile指令支持变量扩展。
Docker有一组预定义的ARG
变量,您可以在Dockerfile中使用相应的ARG指令。 * HTTP_PROXY * http_proxy * HTTPS_PROXY * https_proxy * FTP_PROXY * ftp_proxy * NO_PROXY * no_proxy
要使用这些,只需在命令行使用标志传递它们:
Impact on build caching
ARG
变量不会持久化到构建的image中,因为ENV
变量是。但是,ARG
变量会以类似的方式影响构建缓存。如果一个Dockerfile
定义一个ARG
变量,它的值不同于以前的版本,那么在它的第一次使用时会出现一个“cache miss”,而不是它的定义。特别地,在ARG
指令之后的所有RUN
指令都隐式地使用ARG变量(作为环境变量),因此可能导致高速缓存未命中。
例如,考虑这两个Dockerfile:
如果在命令行上指定--build-arg CONT_IMG_VER = <value>
,则在这两种情况下,第2行的规范不会导致高速缓存未命中;行3确实导致高速缓存未命中。ARG CONT_IMG_VER
导致RUN
行被标识为与运行CONT_IMG_VER = <value> echo hello
相同,因此如果<value>
更改,我们将得到高速缓存未命中。
考虑在同一命令行下的另一个示例:
在此示例中,高速缓存未命中发生在第3行。由于变量在ENV
中的值引用ARG
变量并且该变量通过命令行更改,因此发生了未命中。在此示例中,ENV
命令使image包括该值。
如果ENV
指令覆盖同名的ARG
指令,就像这个Dockerfile:
第3行不会导致高速缓存未命中,因为CONT_IMG_VER
的值是一个常量(hello)。因此,RUN
(第4行)上使用的环境变量和值在构建之间不会更改。
ONBUILD
ONBUILD
指令在image被用作另一个构建的基础时,向image添加要在以后执行的*trigger*指令。trigger将在下游构建的上下文中执行,就好像它已经在下游Dockerfile中的1FROM1指令之后立即插入。
任何构建指令都可以注册为trigger。
如果您正在构建将用作构建其他image的基础的图像,例如应用程序构建环境或可以使用用户特定配置自定义的后台驻留程序,这将非常有用。
例如,如果您的image是可重用的Python应用程序构建器,则需要将应用程序源代码添加到特定目录中,并且可能需要在此之后调用构建脚本。你不能只是调用ADD
和RUN
现在,因为你还没有访问应用程序源代码,它将是不同的每个应用程序构建。您可以简单地为应用程序开发人员提供一个样板Dockerfile以将其复制粘贴到其应用程序中,但这是低效,容易出错,并且很难更新,因为它与应用程序特定的代码混合。
解决方案是使用ONBUILD
来注册提前指令,以便稍后在下一个构建阶段运行。
以下是它的工作原理:
- 当遇到
ONBUILD
指令时,构建器会向正在构建的image的元数据添加trigger。该指令不会另外影响当前构建。 - 在构建结束时,所有trigger的列表存储在image清单中的OnBuild键下。可以使用
docker inspect
命令检查它们。 - 稍后,可以使用
FROM
指令将image用作新构建的基础。作为处理FROM
指令的一部分,下游构建器会查找ONBUILD
triggers,并按照它们注册的顺序执行它们。如果任何触发器失败,则FROM
指令中止,这又导致构建失败。如果所有触发器都成功,则FROM
指令完成并且构建如常继续。触发器在执行后从最终image中清除。换句话说,它们不会被“grand-children”构建继承。 例如,您可以添加如下:[...] ONBUILD ADD . /app/src ONBUILD RUN /usr/local/bin/python-build --dir /app/src [...]
>警告
:不允许使用ONBUILD ONBUILD
链接ONBUILD
指令。 >警告
:ONBUILD
指令可能不会触发FROM
或MAINTAINER
指令。
STOPSIGNAL
STOPSIGNAL
指令设置将发送到容器以退出的系统调用信号。该信号可以是与内核系统调用表中的位置匹配的有效无符号数,例如9,或者是SIGNAME格式的信号名称,例如SIGKILL。
HEALTHCHECK
两种形式: * HEALTHCHECK [OPTIONS] CMD command (通过在容器中运行命令来检查容器运行状况) * HEALTHCHECK NONE (禁用从基本映像继承的任何运行状况检查)
HEALTHCHECK
指令告诉Docker如何测试容器以检查它是否仍在工作。这可以检测到诸如Web服务器被卡在无限循环中并且无法处理新连接的情况,即使服务器进程仍在运行。
当容器指定了healthcheck时,除了其正常状态外,它还具有健康状态。此状态最初开始。 每当健康检查通过,它变得健康(无论之前的状态)。在一定数量的连续故障后,它变得不健康。
在CMD之前可以出现的选项有: * --interval=DURATION
(default: 30s) * --timeout=DURATION
(default: 30s) * --retries=N
(default: 3)
运行状况检查将首先在容器启动后运行interval秒,然后在每次上次检查完成后再次运行interval秒。
如果检查的单次运行所花费的时间超过timeout秒数,则该检查被认为已失败。
它需要retries连续的健康检查的故障,容器被认为是不健康的。
在Dockerfile中只能有一个HEALTHCHECK
指令。如果您列出多个,则只有最后一个HEALTHCHECK
将生效。
CMD
关键字之后的命令可以是shell命令(例如HEALTHCHECK CMD /bin/check-running
)或exec数组(如同其他Dockerfile命令一样;详情参见ENTRYPOINT
)。
命令的退出状态表示容器的运行状况。 可能的值为: * 0: success - the container is healthy and ready for use * 1: unhealthy - the container is not working correctly * 2: reserved - do not use this exit code
例如,要每五分钟检查一次Web服务器能够在三秒钟内为网站的主页提供服务:
为了帮助调试失败的探测器,命令在stdout或stderr上写入的任何输出文本(UTF-8编码)将存储在运行状况状态,并可以使用docker inspect
查询。这样的输出应该保持短路(只存储当前的4096个字节)。
当容器的运行状况发生更改时,将生成具有新状态的health_status
事件。
HEALTHCHECK
功能在Docker 1.12中添加。
SHELL
SHELL
指令允许用于命令的shell形式的默认shell被覆盖。 Linux上的默认shell是["/bin/sh","-c"]
,在Windows上是["cmd","/S","/C"]
。SHELL
指令必须以JSON格式写在Dockerfile中。
SHELL
指令在Windows上特别有用,其中有两个常用的和完全不同的本机shell:cmd
和powershell
,以及包括sh
的备用Shell。
SHELL
指令可以多次出现。每个SHELL
指令覆盖所有先前的SHELL
指令,并影响所有后续指令。 例如:
以下指令可能受SHELL
指令的影响,当它们的shell形式用于Dockerfile:RUN
,CMD
和ENTRYPOINT
。
以下示例是Windows上的常见模式,可以使用SHELL指令进行简化:
docker调用的命令将是:
这是低效的,有两个原因。首先,有一个不必要的cmd.exe命令处理器(也称为shell)被调用。其次,shell中的每个RUN
指令都需要一个额外的powershell -command
。
为了更有效率,可以采用两种机制之一。 一种是使用JSON形式的RUN命令,如:
虽然JSON形式是明确的,并且不使用不必要的cmd.exe,但它需要通过双引号和转义更详细。 备用机制是使用SHELL
指令和shell形式,为Windows用户提供更自然的语法,特别是与escape
解析指令结合使用时:
结果是:
SHELL
指令还可以用于修改外壳操作的方式。例如,在Windows上使用SHELL cmd /S /C /V:ON|OFF
,可以修改延迟的环境变量扩展语义。
SHELL
指令也可以在Linux上使用,如果需要一个替代shell,如zsh
,csh
,tcsh
和其他。
SHELL
功能在Docker 1.12中添加。
Dockerfile examples
下面你可以看到一些Dockerfile语法的例子。 如果你对更现实的东西感兴趣,可以看看Dockerization的例子。
本文链接:https://deepzz.com/post/dockerfile-reference.html,参与评论 »
--EOF--
更多推荐
所有评论(0)