Dockerfile 详细教程

Dockerfile 是一个文本文件，它包含了所有可以用来在命令行构建一个容器镜像的命令。

格式

最基础的格式如下所示：

# Comment
INSTRUCTION arguments

虽然 命令(INSTRUCTION) 是大小写不敏感的，但按照惯例，要把它写成大写字母的形式，与 参数(arguments) 进行视觉上的区分。

Docker 会按顺序执行 Dockerfile 中的指令。Dockerfile 的第一个指令必须是 FROM，但 FROM 之前也可能存在 分析器指令、注释或全局环境变量。FROM 指令指定将要进行构建的镜像。

以 # 开头的行，如果不是分析器指令的话，会被看作注释。在一行中的其他地方出现的 # 会被认为是普通字符。续行符(\)在注释行中是无效的。

分析器指令（Parser directives）

分析器指令是可选的，它会影响 Dockerfile 中后续行的处理方式。它不会在构建中增加层数，也不会在构建过程中展示。格式是 # directive=value 。分析器指令必须在 Dockerfile 中的第一行。

分析器指令是大小写不敏感的，但一般会写成小写。下边会空一行。续行符(\)是无效的。

有两种分析器指令可以定义：syntax 和 escape

syntax

几个例子：

# syntax=docker/dockerfile:1
# syntax=docker.io/docker/dockerfile:1
# syntax=example.com/user/repo:tag@sha256:abcdef...

这个特性只在使用 BuildKit 时生效，传统构建方式用不到。

escape

# escape=\

# escape=`

定义在 Dockerfile 语句中使用的转义运算符和续行符，默认是反斜杠。在 Windows 系统中，将 escape 配置成 ` 会更方便。

环境变量

在 Dockerfile 中可以定义环境变量供后续指令使用（ENV）。

使用环境变量的格式可以是 $variable_name 或 ${variable_name}，${variable_name} 也支持使用一些标准 bash 中的控制符：

${variable_name:-word} 表示如果变量已定义，取值就是变量的值，未定义的话，取值是word
${variable_name:+word} 表示如果变量已定义，取值是word，未定义的话，取值为空字符串

word 可以是任意字符串，包括额外的环境变量。

在下列指令中，可以使用环境变量：

ADD
COPY
ENV
EXPOSE
FROM
LABEL
STOPSIGNAL
USER
VOLUME
WORKDIR
ONBUILD（与上边的其他指令一起使用时）

FROM

FROM [--platform=<platform>] <image> [AS <name>]
FROM [--platform=<platform>] <image>[:<tag>] [AS <name>]
FROM [--platform=<platform>] <image>[@<digest>] [AS <name>]

FROM 指令初始化一个新的构建阶段，把下边的指令实施到基础镜像上边。镜像可以是任意可用的镜像。

• ARG 是唯一一个可以放在 FROM 前边的指令。
• 在一个 Dockerfile 中可以出现多个 FROM 指令，用来创建多个镜像，或者以一个构建阶段为另一个构建阶段的依赖。只需在每个新 FROM 指令之前记下commit输出的最后一个镜像ID。每个 FROM 会把之前的所有指令的状态清空。
• 可以给一个新的构建阶段起个名字，用法是在 FROM 指令中添加 AS name。这个名字可以在后续的 FROM 和 COPY --from=<name> 指令中使用，以指定在当前阶段构建的镜像。
• tag 和 digest 字段是可选的，如果都没有指定，默认值是 latest。如果构建器找不到 tag 的值，返回一个 error。

如果 FROM 指定的镜像是多平台的，--platform 可以用来指定镜像的平台。

FROM 指令可以使用任意在第一个 FROM 指令之前在 ARG 指令中定义的变量。但是在 FROM 之前定义的变量不能用在 FROM 之后的其他指令中，如果想继续使用，需要在想使用此变量的指令之前写上 ARG argument（不写变量的值）。

RUN

RUN 有两种格式：

RUN <command> 
(shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)

RUN ["executable", "param1", "param2"] 
(exec form) 必须使用双引号

RUN 指令会在当前镜像上边的一个新的层上执行命令。生成的新镜像会用于执行 Dockerfile 中的接下来的其他指令。

分层 RUN 指令和生成提交符合 Docker 的核心概念，其中提交很廉价，容器可以从镜像历史的任何点创建，就像源代码控制一样。

exec form 可以避免 shell 字符串被篡改，并使用不包含指定 shell 可执行文件的基本镜像运行命令。

shell form 的默认 shell 可以使用 SHELL 命令来修改。

在 shell form 中，你可以使用一个反斜杠来换行。

RUN --mount

RUN --mount 可以用来创建作为构建的一部分运行的进程可以访问的挂载。这可以用于绑定来自构建其他部分的文件，而无需复制、访问构建密钥或 ssh 代理套接字，也无需创建缓存位置来加快构建速度。

格式：

--mount=[type=<TYPE>][,option=<value>[,option=<value>]...]

type:

bind(默认)	绑定挂载上下文目录（只读）
cache	把一个临时目录挂载到缓存目录，供编译器和包管理器使用
tmpfs	挂载 tmpfs
secret	允许构建容器访问私钥等安全文件，而不将其放到镜像中。
ssh	允许构建容器通过 SSH 代理访问 SSH 密钥，通过密码支持。

RUN --mount=type=bind

选项	描述
target	挂载路径
source	from 选项的源路径，默认是 root
from	源的 root 的生成阶段或镜像名称。默认为构建上下文。
rw,readwrite	允许写入挂载的文件。已写入的数据会被丢弃。

RUN --mount=type=cache

选项	描述
id	可选的标记分离或不同的缓存的 id，默认值是 target 的值。
target	挂载路径。
ro,readonly	只读。
sharing	可选值有 shared，private，locked。默认值是 shared。一个 shared 缓存挂载可以被多个作者使用。如果有多个作者，private 可以创建一个新的挂载。locked 暂停第二个作者的使用直到第一个作者释放挂载。
from	构建阶段使用的作为缓存挂载的基础。默认是空目录。
source	from 中的要挂载的子路径。默认是from 的 root。
mode	8进制显示的新缓存目录的文件模式，默认0755。
uid	新缓存目录的用户 id，默认 0。
gid	新缓存目录的用户组 id，默认 0。

缓存目录的内容在构建器调用之间保持不变，而不会使指令缓存无效。缓存挂载只能用于获得更好的性能。您的构建应该可以处理缓存目录的任何内容，因为另一个构建可能会覆盖这些文件，或者如果需要更多存储空间，GC可能会将其清除。

RUN --mount=type=tmpfs

选项	描述
target	挂载路径。
size	指定一个文件系统的大小上限

RUN --mount=type=secret

选项	描述
id	密钥的 id，默认值是 target 的路径的基础名。
target	挂载路径，默认值是 /run/secrets/ + id
required	默认值 false。如果设置为 true，当密钥不存在时报错。
mode	8进制显示的密钥文件的文件模式，默认0400。
uid	密钥文件的用户 id，默认 0。
gid	密钥文件的用户组 id，默认 0。

RUN --mount=type=ssh

选项	描述
id	SSH 代理套接字或私钥的 id，默认值是 default。
target	SSH 代理套接字路径，默认值是 /run/buildkit/ssh_agent.${N}
required	默认值 false。如果设置为 true，当私钥不存在时报错。
mode	8进制显示的套接字的文件模式，默认0600。
uid	套接字的用户 id，默认 0。
gid	套接字的用户组 id，默认 0。

RUN --network

RUN --network 允许控制命令所在的环境的网络。

格式：

--network=<TYPE>

type:

default	默认网络
none	无网络
host	宿主机网络

CMD

有三种格式：

CMD ["executable","param1","param2"] 
(exec form, this is the preferred form)

CMD ["param1","param2"] 
(as default parameters to ENTRYPOINT)

CMD command param1 param2 
(shell form)

Dockerfile 中只能有一个 CMD 指令，如果存在多个 CMD 指令，只有最后一个会生效。

CMD 的主要目的是提供执行容器的默认命令。这些默认命令必须有一个可执行参数，如果没有，那就必须指定一个 ENTRYPOINT 指令。如果 CMD 提供了 ENTRYPOINT 的默认参数，那么 ENTRYPOINT 和 CMD 都要是 JSON 数组格式。

如果使用 shell form，就相当于在 command 之前添加 /bin/sh -c。

如果用户在 docker run 命令中指定参数，这个参数就会取代 CMD 中的参数。

LABEL

LABEL <key>=<value> <key>=<value> <key>=<value> ...

LABEL 指令将元数据加入到镜像中。一个 LABEL 是一个键值对。

一些例子：

LABEL "com.example.vendor"="ACME Incorporated"
LABEL com.example.label-with-value="foo"
LABEL version="1.0"
LABEL description="This text illustrates \
that label-values can span multiple lines."

一个镜像可以有多个标签。在一行里可以指定多个标签。

LABEL multi.label1="value1" multi.label2="value2" other="value3"

LABEL multi.label1="value1" \
      multi.label2="value2" \
      other="value3"

包括在基础镜像或父镜像中的标签会被你的镜像继承。如果一个标签已经存在且值不同，取最新的值。查看标签的方法是：

docker image inspect --format='' myimage

EXPOSE

EXPOSE <port> [<port>/<protocol>...]

EXPOSE 指令提醒 docker 容器是在监听指定的网络端口。你可以指定使用 TCP 或 UDP 协议，默认是 TCP。

EXPOSE 指令不是真的发布这个端口。它其实是作为在构建镜像的人和使用容器的人之间的一个文档。docker run -p 才是真正发布端口。

EXPOSE 80/tcp
EXPOSE 80/udp

ENV

ENV <key>=<value> ...

ENV 指令设置环境变量 <key> 的值为 <value>。这个值在接下来的构建阶段一直有效，也可以在许多情况下内联替换。该值将被解释为其他环境变量，因此，如果引号字符没有转义，它们将被删除。与命令行解析类似，可以使用引号和反斜杠在值中包含空格。

ENV MY_NAME="John Doe"
ENV MY_DOG=Rex\ The\ Dog
ENV MY_CAT=fluffy

ENV 指令可以包含多个键值对，下边这个例子和上边的效果一样：

ENV MY_NAME="John Doe" MY_DOG=Rex\ The\ Dog \
    MY_CAT=fluffy

你可以通过 docker inspect 查看环境变量的值，docker run --env <key>=<value> 改变值。

如果一个变量只在构建过程中使用，那就可以用一个简单命令或 ARG 指令代替：

RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y ...

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y ...

ADD

ADD [--chown=<user>:<group>] [--checksum=<checksum>] <src>... <dest>
ADD [--chown=<user>:<group>] ["<src>",... "<dest>"]

ADD 指令复制新文件、目录或远端的文件 URL(<src>)，把它们放到镜像的文件系统中的路径(<dest>)。

所有以 "hom" 开头的文件：

ADD hom* /mydir/

问号代表一个字符：

ADD hom?.txt /mydir/

<dest> 是一个绝对路径，或者是相对于 WORKDIR 的相对路径。

下边的例子复制 "test.txt" 到 <WORKDIR>/relativeDir/

ADD test.txt relativeDir/

但下边的例子用的是绝对路径：

ADD test.txt /absoluteDir/

全新的文件和目录使用 0 作为 UID 和 GID 来创建，除非 --chown 制定了具体的值。只指定用户名而不指定用户组或只指定 UID 而不指定 GID ，则 GID 等于 UID。

ADD --chown=55:mygroup files* /somedir/
ADD --chown=bin files* /somedir/
ADD --chown=1 files* /somedir/
ADD --chown=10:11 files* /somedir/

ADD 遵循以下规则：

• <src> 路径一定要在构建上下文之内，你不能 ADD ../something /something，因为 docker build 的第一步就是把上下文目录发送到 docker daemon。
• 如果 <src> 是一个 URL，<dest> 不以斜杠结束，则这个文件会下载到 <dest>。
• 如果 <src> 是一个 URL，<dest> 以斜杠结束，这个文件就会下载到 <dest>/<filename>。
• 如果 <src> 是一个目录，整个目录的内容将会被复制，包括元数据。
• 如果 <src> 是一个本地压缩过的 tar 包，它将会被自动解压缩成一个目录。如果是远程 URL 中的资源则不会解压缩。
• 如果 <src> 是其他类型的文件，它会被独立地和元数据一起复制。
• 如果 <src> 是多个文件，则 <dest> 必须是目录且以斜杠结尾。
• 如果 <dest> 不是以斜杠结束，他就被认为是一个文件，<src> 就被写入 <dest>。
• 如果 <dest> 不存在，则会创建它及其路径中所有缺少的目录。

COPY

COPY [--chown=<user>:<group>] <src>... <dest>
COPY [--chown=<user>:<group>] ["<src>",... "<dest>"]

COPY 指令把新文件或目录从 <src> 复制到镜像的文件系统中的路径(<dest>)。

一些与 ADD 相同的规则：

COPY hom* /mydir/
COPY hom?.txt /mydir/
COPY test.txt relativeDir/
COPY test.txt /absoluteDir/

COPY --chown=55:mygroup files* /somedir/
COPY --chown=bin files* /somedir/
COPY --chown=1 files* /somedir/
COPY --chown=10:11 files* /somedir/

COPY 遵循以下规则：

• <src> 路径一定要在构建上下文之内，你不能 COPY ../something /something，因为 docker build 的第一步就是把上下文目录发送到 docker daemon。
• 如果 <src> 是一个目录，整个目录的内容将会被复制，包括元数据。
• 如果 <src> 是其他类型的文件，它会被独立地和元数据一起复制。
• 如果 <src> 是多个文件，则 <dest> 必须是目录且以斜杠结尾。
• 如果 <dest> 不是以斜杠结束，他就被认为是一个文件，<src> 就被写入 <dest>。
• 如果 <dest> 不存在，则会创建它及其路径中所有缺少的目录。

COPY --link

在 COPY 或 ADD 命令中启用此标志，可以使用增强的语义复制文件，其中文件保持独立于自己的层，并且在更改前一层上的命令时不会失效。

使用--link时，源文件将复制到空的目标目录中。该目录将转换为一个链接到上一状态顶部的层。

FROM alpine
COPY --link /foo /bar

等于以下两步的效果：

FROM alpine

FROM scratch
COPY /foo /bar

使用--link在后续构建中重用已构建的层，使用--cache from，即使前面的层已更改。对于多阶段构建来说，这一点尤其重要，因为如果同一阶段中以前的任何命令发生更改，则COPY--from语句以前都会失效，从而需要重新构建中间阶段。使用--link，将重用先前生成的层，并将其合并到新层之上。这也意味着当基本镜像接收到更新时，您可以轻松地重新设置镜像的基址，而无需再次执行整个构建。

使用--link时，不允许COPY/ADD命令读取以前状态的任何文件。这意味着，如果在以前的状态下，目标目录是包含符号链接的路径，则COPY/ADD不能跟随它。在最后一个镜像中，使用--link创建的目标路径将始终是只包含目录的路径。

如果不依赖于目标路径中跟随的符号链接的行为，则始终建议使用--link。--link的性能相当于或优于默认行为，它为缓存重用创造了更好的条件。

ENTRYPOINT

ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2

ENTRYPOINT 指令允许你配置一个作为可执行文件的容器。

docker run <image> 的命令行参数将附加在 exec 格式 ENTRYPOINT 中的所有元素之后，并将覆盖使用CMD指定的所有元素。这允许将参数传递到 ENTRYPOINT，即docker run <image> -d 将  -d 参数传递给ENTRYPOINT。你可以使用docker run --entrypoint 标志覆盖 ENTRYPOINT 指令。

shell 格式阻止使用任何 CMD 或 run 命令行参数，但有一个缺点，即 ENTRYPOINT 将作为 /bin/sh -c 的子命令启动，它不会传递信号。这意味着可执行文件将不是容器的 PID 1，并且不会接收 Unix 信号，因此你的可执行文件不会从 docker stop <container> 接收 SIGTERM。

只有 Dockerfile 中的最后一条 ENTRYPOINT 指令才会生效。

理解 ENTRYPOINT 和 CMD 的互动方式

CMD 和 ENTRYPOINT 指令都定义了运行容器时执行的命令。

1. Dockerfile 应该指定至少一个 CMD 或 ENTRYPOINT

2. ENTRYPOINT 应在将容器用作可执行文件时定义。

3. CMD 应该用作定义 ENTRYPOINT 命令的默认参数或在容器中执行特殊命令的默认参数。

4. 在运行容器时指定不同的参数会覆盖 CMD。

	没有 ENTRYPOINT	ENTRYPOINT exec_entry p1_entry	ENTRYPOINT ["exec_entry","p1_entry"]
没有 CMD	报错	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry
CMD exec_entry p1_entry	exec_entry p1_entry	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry exec_cmd p1_cmd
CMD ["exec_entry","p1_entry"]	/bin/sh -c  exec_entry p1_entry	/bin/sh -c exec_entry p1_entry	exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd

VOLUME

VOLUME ["/data"]

VOLUME 指令创建一个具有指定名称的挂载点，并将其标记为保存来自本机主机或其他容器的外部挂载卷。该值可以是JSON数组、VOLUME["/var/log/"]，也可以是具有多个参数的普通字符串，例如VOLUME /var/log 或 VOLUME /var/log /var/db。

docker run 命令使用基本镜像中指定位置存在的任何数据初始化新创建的卷。

USER

USER <user>[:<group>]
USER <UID>[:<GID>]

USER 指令将用户名（或UID）和可选的用户组（或GID）设置为当前阶段剩余部分的默认用户和组。指定的用户用于 RUN 指令，并在运行时运行相关的 ENTRYPOINT 和 CMD 命令。

WORKDIR

WORKDIR /path/to/workdir

WORKDIR 指令为 Dockerfile 中其后的任何 RUN、CMD、ENTRYPOINT、COPY 和 ADD 指令设置工作目录。如果 WORKDIR 不存在，即使它没有在任何后续 Dockerfile 指令中使用，也会创建它。WORKDIR 指令可以在 Dockerfile 中多次使用。如果提供了相对路径，则它将相对于上一条WORKDIR 指令的路径。

WORKDIR 指令可以解析在 ENV 指令中定义的环境变量。

ARG

ARG <name>[=<default value>]

ARG 指令定义了一个变量，用户可以在构建时使用 docker build 命令使用                                      --build-arg <varname>=<value> 标志将该变量传递给构建器。如果用户指定了 Dockerfile 中未定义的生成参数，则生成会输出警告。

一个 Dockerfile 中可以包括多个 ARG 指令。

默认值

如果 ARG 指令具有默认值，并且在生成时没有传递值，则生成器将使用默认值。

范围

ARG 变量定义从 Dockerfile 中定义它的行开始生效，而不是从命令行或其他地方使用参数开始生效。如果多个构建阶段都要使用同一个变量，那么每个阶段中都要有 ARG 指令。

使用变量

你可以使用 ARG 或 ENV 指令指定 RUN 指令可用的变量。使用 ENV 指令定义的环境变量总是覆盖同名的 ARG 指令。

预定义的 ARG

• HTTP_PROXY
• http_proxy
• HTTPS_PROXY
• https_proxy
• FTP_PROXY
• ftp_proxy
• NO_PROXY
• no_proxy
• ALL_PROXY
• all_proxy

要使用这些变量，可以用 --build-arg:

$ docker build --build-arg HTTPS_PROXY=https://my-proxy.example.com .

默认情况下，这些预定义变量将从 docker history 的输出中排除。排除它们可以降低HTTP_PROXY 变量中意外泄漏敏感身份验证信息的风险。

对构建缓存的影响

ARG 变量不会像 ENV 变量那样持久化到构建镜像中。然而，ARG 变量确实以类似的方式影响构建缓存。如果 Dockerfile 定义了一个 ARG 变量，该变量的值与以前的构建不同，那么“缓存未命中”会在首次使用时发生，而不是在定义时发生。特别是，ARG 指令之后的所有 RUN 指令都隐式使用 ARG 变量（作为环境变量），因此可能会导致缓存未命中。除非 Dockerfile 中有匹配的 ARG 语句，否则所有预定义的 ARG 变量都可以免除缓存。

ONBUILD

ONBUILD <INSTRUCTION>

ONBUILD 指令将一条触发器指令添加到镜像中，以便在以后将镜像用作另一个构建的基础时执行。触发器将在下游构建的上下文中执行，就好像它被直接插入下游 Dockerfile 中 FROM 指令之后一样。

任何构建指令都可以注册为触发器。

如果你正在构建一个镜像，该镜像将用作构建其他镜像的基础，例如应用程序构建环境或可以使用用户特定配置自定义的守护程序，那么这将非常有用。

例如，如果你的镜像是一个可重用的 Python 应用程序构建器，那么它将需要将应用程序源代码添加到特定目录中，并且可能需要在该目录之后调用构建脚本。你现在不能只调用 ADD 和 RUN，因为你还没有访问应用程序源代码的权限，并且对于每个应用程序构建来说，这将是不同的。你可以简单地为应用程序开发人员提供一个样板 Dockerfile，将复制粘贴到他们的应用程序中，但这是低效的、容易出错的，并且很难更新，因为它与应用程序特定的代码混合在一起。

解决方案是使用 ONBUILD 注册高级指令，以便稍后在下一个构建阶段运行。

下面是它的工作方式：

1. 当遇到 ONBUILD 指令时，生成器会向正在生成的镜像的元数据添加触发器。该指令不会影响当前版本。
2. 在构建结束时，所有触发器的列表存储在镜像清单中的 OnBuild 键下。可以使用          docker inspect命令检查它们。
3. 稍后，可以使用 FROM 指令将镜像用作新构建的基础。作为处理 FROM 指令的一部分，下游构建器查找 ONBUILD 触发器，并以注册它们的相同顺序执行它们。如果任何一个触发器失败，FROM 指令将中止，从而导致构建失败。如果所有触发器都成功，则 FROM 指令完成，构建照常继续。
4. 触发器在执行后从最终镜像中清除。换言之，它们不是由“孙子”构建继承的。

不能使用 ONBUILD ONBUILD，FROM 和 MAINTAINER 也不能被 ONBUILD 触发。

STOPSIGNAL

STOPSIGNAL signal

STOPSIGNAL 指令设置将发送到容器以退出的系统调用信号。此信号可以是SIG<NAME>格式的信号名称，例如SIGKILL，也可以是与内核系统调用表中的位置匹配的无符号数字，例如9。如果未定义，则默认值为SIGTERM。

可以在 docker run 和 docker create 上使用 --stop-signal 标志覆盖每个容器的图像默认stopsignal。

HEALTHCHECK

HEALTHCHECK [OPTIONS] CMD command 
(check container health by running a command inside the container)

HEALTHCHECK NONE 
(disable any healthcheck inherited from the base image)

HEALTHCHECK 指令告诉 Docker 如何测试容器以检查它是否仍在工作。这可以检测到一些情况，例如 web 服务器陷入无限循环，无法处理新连接，即使服务器进程仍在运行。

当容器指定了健康检查时，它除了正常状态外，还具有健康状态。此状态最初处于 starting。只要健康检查通过，它就会变得 healthy（无论以前处于什么状态）。在连续出现一定数量的故障后，它会变得 unhealthy。

可以在 CMD 之前出现的选项有：

• --interval=DURATION (default:30s)
• --timeout=DURATION (default:30s)
• --start-period=DURATION (default:0s)
• --retries=N (default:3)

健康检查将首先在容器启动后 interval 秒运行，然后在每个前一检查完成后 interval 秒再次运行。

如果单个检查运行时间超过 timeout 秒，则认为检查失败。

需要 retries 次连续失败的健康检查才能将容器视为 unhealthy。

start period 为需要引导时间的容器提供初始化时间。在此期间的探测失败不会计入最大重试次数。但是，如果健康检查在启动期间成功，则认为容器已启动，所有连续失败都将计入最大重试次数。

Dockerfile 中只能有一条 HEALTHCHECK 指令。如果列出多个，则只有最后一个 HEALTHCHECK 才会生效。

CMD 关键字后面的命令可以是 shell 命令（例如HEALTHCHECK CMD /bin/check-running）或exec 数组。

命令的退出状态指示容器的运行状况。可能的值为：

• 0：成功 - 容器健康且可以使用
• 1：不健康 - 容器没有正确工作
• 2：保留

例如，要每隔五分钟左右检查一次web服务器是否能够在三秒钟内为站点的主页提供服务，请执行以下操作：

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

为了帮助调试失败的探测，命令在 stdout 或 stderr 上写入的任何输出文本（UTF-8编码）都将存储在健康状态中，并且可以通过 docker inspect 查询。这样的输出应该保持简短（目前只存储前4096个字节）。

当容器的健康状态更改时，将生成一个具有新状态的 health_status 事件。

SHELL

SHELL ["executable", "parameters"]

SHELL 指令允许重写用于 SHELL 形式命令的默认 SHELL。Linux 上的默认 shell 是      [“/bin/sh”，“-c”]，Windows 上的默认 shell 是 [“cmd”，“/S”，“/c”]。SHELL 指令必须以 JSON 格式写入 Dockerfile。

SHELL指令可以出现多次。每个SHELL指令都会覆盖所有先前的 SHELL 指令，并影响所有后续指令。这些指令的 shell 形式会被 SHELL 指令影响：RUN，CMD，ENTRYPOINT。