Docker官方关于Dockerfile最佳实践原文链接地址：https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
Docker 可以通过从 Dockerfile 包含所有命令的文本文件中读取指令自动构建镜像，以便构建给定镜像。
Dockerfiles 使用特定的格式并使用一组特定的指令。您可以在Dockerfile Reference页面上了解基础知识 。如果你是新手写作Dockerfile，你应该从那里开始。
本文档介绍了由 Docker，Inc. 和 Docker 社区推荐的用于构建高效镜像的最佳实践和方法。要查看许多实践和建议，请查看Dockerfile for buildpack-deps。

一般准则和建议

容器应该是短暂的

通过 Dockerfile 构建的镜像所启动的容器应该尽可能短暂（生命周期短）。「短暂」意味着可以停止和销毁容器，并且创建一个新容器并部署好所需的设置和配置工作量应该是极小的。我们可以查看下12 Factor(12要素)应用程序方法的进程部分，可以让我们理解这种无状态方式运行容器的动机。

建立上下文

当你发出一个docker build命令时，当前的工作目录被称为构建上下文。默认情况下，Dockerfile 就位于该路径下，当然您也可以使用-f参数来指定不同的位置。无论 Dockerfile 在什么地方，当前目录中的所有文件内容都将作为构建上下文发送到 Docker 守护进程中去。

下面是一个构建上下文的示例，为构建上下文创建一个目录并 cd 放入其中。将“hello”写入一个文本文件hello，然后并创建一个Dockerfile并运行cat。从构建上下文（.）中构建图像：

  1. mkdir myproject && cd myproject
  2. echo "hello" > hello
  3. echo -e "FROM busybox\nCOPY /hello /\nRUN cat /hello" > Dockerfile
  4. docker build -t helloapp:v1 .

现在移动 Dockerfile 和 hello 到不同的目录，并建立了图像的第二个版本（不依赖于缓存中的最后一个版本）。使用-f指向 Dockerfile 并指定构建上下文的目录：

  1. mkdir -p dockerfiles context
  2. mv Dockerfile dockerfiles && mv hello context
  3. docker build --no-cache -t helloapp:v2 -f dockerfiles/Dockerfile context

在构建的时候包含不需要的文件会导致更大的构建上下文和更大的镜像大小。这会增加构建时间，拉取和推送镜像的时间以及容器的运行时间大小。要查看您的构建环境有多大，请在构建您的系统时查找这样的消息

  1. Dockerfile：
  2. Sending build context to Docker daemon  187.8MB

使用.dockerignore文件

使用 Dockerfile 构建镜像时最好是将 Dockerfile 放置在一个新建的空目录下。然后将构建镜像所需要的文件添加到该目录中。为了提高构建镜像的效率，你可以在目录下新建一个.dockerignore文件来指定要忽略的文件和目录。.dockerignore 文件的排除模式语法和 Git 的 .gitignore 文件相似。

使用多阶段构建

在 Docker 17.05 以上版本中，你可以使用 多阶段构建 来减少所构建镜像的大小。上一节课我们已经重点讲解过了。

避免安装不必要的包

为了降低复杂性、减少依赖、减小文件大小和构建时间，应该避免安装额外的或者不必要的软件包。例如，不要在数据库镜像中包含一个文本编辑器。

一个容器只专注做一件事情

应该保证在一个容器中只运行一个进程。将多个应用解耦到不同容器中，保证了容器的横向扩展和复用。例如一个 web 应用程序可能包含三个独立的容器：web应用、数据库、缓存，每个容器都是独立的镜像，分开运行。但这并不是说一个容器就只跑一个进程，因为有的程序可能会自行产生其他进程，比如 Celery 就可以有很多个工作进程。虽然“每个容器跑一个进程”是一条很好的法则，但这并不是一条硬性的规定。我们主要是希望一个容器只关注意见事情，尽量保持干净和模块化。
如果容器互相依赖，你可以使用Docker 容器网络来把这些容器连接起来，我们前面已经跟大家讲解过 Docker 的容器网络模式了。

最小化镜像层数

在 Docker 17.05 甚至更早 1.10之 前，尽量减少镜像层数是非常重要的，不过现在的版本已经有了一定的改善了：

  • 在 1.10 以后，只有 RUN、COPY 和 ADD 指令会创建层，其他指令会创建临时的中间镜像，但是不会直接增加构建的镜像大小了。
  • 上节课我们也讲解到了 17.05 版本以后增加了多阶段构建的支持，允许我们把需要的数据直接复制到最终的镜像中，这就允许我们在中间阶段包含一些工具或者调试信息了，而且不会增加最终的镜像大小。

当然减少RUN、COPY、ADD的指令仍然是很有必要的，但是我们也需要在 Dockerfile 可读性（也包括长期的可维护性）和减少层数之间做一个平衡。

对多行参数排序

只要有可能，就将多行参数按字母顺序排序（比如要安装多个包时）。这可以帮助你避免重复包含同一个包，更新包列表时也更容易，也更容易阅读和审查。建议在反斜杠符号 \ 之前添加一个空格，可以增加可读性。 下面是来自 buildpack-deps 镜像的例子：

  1. RUN apt-get update && apt-get install -y \
  2.   bzr \
  3.   cvs \
  4.   git \
  5.   mercurial \
  6.   subversion

构建缓存

在镜像的构建过程中，Docker 根据 Dockerfile 指定的顺序执行每个指令。在执行每条指令之前，Docker 都会在缓存中查找是否已经存在可重用的镜像，如果有就使用现存的镜像，不再重复创建。当然如果你不想在构建过程中使用缓存，你可以在 docker build 命令中使用—no-cache=true选项。
如果你想在构建的过程中使用了缓存，那么了解什么时候可以什么时候无法找到匹配的镜像就很重要了，Docker中缓存遵循的基本规则如下：

  • 从一个基础镜像开始（FROM 指令指定），下一条指令将和该基础镜像的所有子镜像进行匹配，检查这些子镜像被创建时使用的指令是否和被检查的指令完全一样。如果不是，则缓存失效。
  • 在大多数情况下，只需要简单地对比 Dockerfile 中的指令和子镜像。然而，有些指令需要更多的检查和解释。
  • 对于 ADD 和 COPY 指令，镜像中对应文件的内容也会被检查，每个文件都会计算出一个校验值。这些文件的修改时间和最后访问时间不会被纳入校验的范围。在缓存的查找过程中，会将这些校验和和已存在镜像中的文件校验值进行对比。如果文件有任何改变，比如内容和元数据，则缓存失效。
  • 除了 ADD 和 COPY 指令，缓存匹配过程不会查看临时容器中的文件来决定缓存是否匹配。例如，当执行完 RUN apt-get -y update 指令后，容器中一些文件被更新，但 Docker 不会检查这些文件。这种情况下，只有指令字符串本身被用来匹配缓存。
  • 一旦缓存失效，所有后续的 Dockerfile 指令都将产生新的镜像，缓存不会被使用。