# Dockerfile 的优化和最佳实践

请尽量使用 Dockerfile 描述镜像的构建过程。主要原因如下:

  • 过程可追溯:Dockerfile 是在描述镜像的构建过程,可以通过 Dockerfile 看到镜像构建时需要执行的步骤,或者其需要安装的依赖等。
  • 变更可管理:Dockerfile 是个纯文本文件,配合 Git版本管理,可以很清晰的查找到每个版本之间的变更。
  • 基于上述两个原因,使用 Dockerfile 来描述镜像的构建过程,从 可维护性 上来看,也是首选。
  • 易于优化:使用 Dockerfile 描述出来的过程,可以直接通过修改 Dockerfile 来修改构建过程,并对其进行优化,包括 构建效率,最终 镜像体积 等。

# ⼀般准则和建议

# 容器应该是短暂的

通过 Dockerfile 构建的镜像所启动的容器应该尽可能短暂(⽣命周期短)。「短暂」意味着可以停⽌和销毁容器,并且创建⼀个新容器并部署好所需的设置和配置⼯作量应该是极⼩的。我们可以查看下 12 Factor(12要素)应⽤程序⽅法 的进程部分,可以让我们理解这种⽆状态⽅式运⾏容器的动机。

# 构建上下⽂

当触发 docker build 命令时,当前的⼯作⽬录 被称为 构建上下⽂。默认情况下,Dockerfile 就位于该路径下,当然您也可以使⽤ -f 参数来指定不同的位置。⽆论 Dockerfile 在什么地⽅,当前⽬录中的所有⽂件内容 都将作为 构建上下⽂ 发送到 Docker 守护进程中去

下⾯是⼀个构建上下⽂的示例,为构建上下⽂创建⼀个⽬录并 cd 放⼊其中。将“hello”写⼊⼀个⽂本⽂件hello,然后并创建⼀个 Dockerfile 并运⾏ cat 。从构建上下⽂(.)中构建图像:

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

Dockerfilehello 移到单独的目录中,并构建镜像的第二个版本(而不依赖上次构建中的缓存)。使用 -f 指向 Dockerfile 并指定构建上下文的目录:

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

在构建的时候包含不需要的⽂件会导致更⼤的构建上下⽂和更⼤的镜像⼤⼩。这会增加构建时间,拉取和推送镜像的时间以及容器的运⾏时间⼤⼩。要查看您的构建上下文有多大,请在构建 Dockerfile 时注意如下信息:

Sending build context to Docker daemon  187.8MB

# 使⽤ .dockerignore ⽂件

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

# 使⽤多阶段构建

Docker 17.05版本以后,官⽅提供了⼀个新的特性:Multi-stage builds (多阶段构建)。 使⽤多阶段构建,你可以在⼀个 Dockerfile中使⽤多个 FROM 语句。每个 FROM 指令都可以使⽤不同的基础镜像,并表示开始⼀个新的构建阶段。

你可以很⽅便的将⼀个阶段的⽂件复制到另外⼀个阶段,后续阶段可以使用之前阶段的产物,或镜像中原本具备的内容。在最终的镜像中只保留我们所需的内容。

多阶段构建使您可以 大幅度减小最终镜像的大小,而不必努力减少中间层和文件的数量。

由于镜像是在生成过程的最后阶段生成的,因此可以利用 生成缓存 来最小化映像层。

例如,如果您的构建包含多个层,则可以将它们从更改频率较低(以确保生成缓存可重用)到更改频率较高的顺序排序:

  • 安装构建应用程序所需的工具
  • 安装或更新库依赖项
  • 生成您的应用

基于 Go 的应用程序的 Dockerfile 可能类似于:

FROM golang:1.11-alpine AS build

# 安装项目所需的工具
# 运行 `docker build --no-cache .`来更新依赖关系
RUN apk add --no-cache git
RUN go get github.com/golang/dep/cmd/dep

# 使用 Gopkg.toml 和 Gopkg.lock 列出项目依赖项
# 仅在更新 Gopkg 文件时才重新构建这些层
COPY Gopkg.lock Gopkg.toml /go/src/project/
WORKDIR /go/src/project/
# 安装库依赖
RUN dep ensure -vendor-only

# 复制整个项目并进行构建
# 当项目目录中的文件更改时,将重新构建此层
COPY . /go/src/project/
RUN go build -o /bin/project

# 最终生成单层镜像
FROM scratch
COPY --from=build /bin/project /bin/project
ENTRYPOINT ["/bin/project"]
CMD ["--help"]

# 避免安装不必要的包

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

# ⼀个容器只专注做⼀件事情

应该保证在⼀个容器中只运⾏⼀个进程。将多个应⽤ 解耦 到不同容器中,保证了容器的 横向扩展复⽤。例如⼀个 web 应⽤程序可能包含三个独⽴的容器:web应⽤、数据库、缓存,每个容器都是独⽴的镜像,分开运⾏。但这并不是说⼀个容器就只跑⼀个进程,因为有的程序可能会⾃⾏产⽣其他进程,⽐如 Celery 就可以有很多个⼯作进程。

虽然 “每个容器跑⼀个进程” 是⼀条很好的法则,但这并不是⼀条硬性的规定。我们主要是希望⼀个容器只关注意⻅事情,尽量保持 ⼲净模块化

如果容器互相依赖,你可以使⽤ Docker 容器⽹络 来把这些容器连接起来。

# 镜像层数尽可能少

在 Docker 17.05 甚⾄更早 1.10之 前,尽量减少镜像层数是⾮常重要的,不过现在的 Docker 版本已经对此进行了优化:

  • 在 1.10 以后,只有 RUN、COPY 和 ADD 指令会创建层,其他指令会创建临时的中间镜像,但是不会直接增加构建的镜像⼤⼩了。
  • 17.05 版本以后增加了 多阶段构建 的⽀持,允许我们把需要的数据直接复制到最终的镜像中,这就允许我们在中间构建阶段包含⼀些⼯具或者调试信息了,⽽且不会增加最终的镜像⼤⼩。

当然减少 RUNCOPYADD 的指令仍然是很有必要的,但是我们也需要在 Dockerfile 可读性(也包括⻓期的可维护性)和减少层数之间做⼀个平衡

# 对多行参数进行排序

将多行参数按字母顺序排序(比如要安装多个包时)。这可以帮助你避免重复包含同一个包,更新包列表时也更容易。也便于 PRs 阅读和审查。建议在反斜杠符号 (\)之前添加一个空格,以增加可读性。

RUN apt-get update && apt-get install -y \
  bzr \
  cvs \
  git \
  mercurial \
  subversion

# 构建缓存

在镜像的构建过程中,Docker 根据 Dockerfile 指定的顺序执⾏每个指令。在执⾏每条指令之前,Docker 都会在缓存中查找是否已经存在可重⽤的镜像,如果有就使⽤现存的镜像,不再重复创建。

当然如果你不想在构建过程中使⽤缓存,你可以在 docker build 命令中使⽤ --no-cache=true 选项。

但是,如果你想在构建的过程中使用缓存,你得明白什么时候会,什么时候不会找到匹配的镜像,遵循的基本规则如下:

  • 从⼀个基础镜像开始(FROM 指令指定),当前执行的指令将和该基础镜像的所有⼦镜像进⾏匹配,检查⼦镜像创建时使⽤的指令是否和当前执行的指令完全⼀样。如果不是,则缓存失效。
  • 在大多数情况下,仅将 Dockerfile 中的指令与子镜像进行比较就足够了。然⽽,有些指令需要更多的检查和解释。
  • 对于 ADDCOPY 指令,镜像中对应 ⽂件的内容 也会进行校验,每个⽂件都会计算出⼀个校验值。这些⽂件的 修改时间最后访问时间 不会被纳⼊校验的范围。在缓存的查找过程中,会将这些校验和和已存在镜像中的⽂件校验值进⾏对⽐。如果 ⽂件有任何改变,⽐如 内容元数据,则缓存失效。
  • 除了 ADDCOPY 指令,缓存匹配过程不会查看临时容器中的⽂件来决定缓存是否匹配。例如,当执⾏完 RUN apt-get -y update 指令后,容器中⼀些⽂件被更新,但 Docker 不会检查这些⽂件。这种情况下,只有指令字符串本身被⽤来匹配缓存。

将更新越频繁的内容,就写到 Dockerfile 越下面的位置,这是为了能更好的利用缓存 (当某处缓存失效后,其后的全部缓存都会失效);

# Dockerfile 指令

下面是 Dockerfile 中各种指令的最佳编写方式。

# FROM

尽可能使⽤ 官⽅仓库 作为你构建镜像的基础。推荐使⽤ Alpine 镜像,因为它被严格控制并保持最⼩尺⼨(⽬前⼩于 5 MB),但它仍然是⼀个完整的发⾏版。

# LABEL

你可以给镜像添加标签来帮助 组织镜像记录许可信息辅助⾃动化构建 等。每个标签⼀⾏,由LABEL 开头加上⼀个或多个标签对。

下⾯的示例展示了各种不同的可能格式。 # 开头的⾏是注释内容。

注意:如果你的字符串包含空格,那么它必须被引⽤或者空格必须被转义。如果您的字符串包含内部引号字符("),则也可以将其转义。
# Set one or more individual labels
LABEL com.example.version="0.0.1-beta"
LABEL vendor="ACME Incorporated"
LABEL com.example.release-date="2015-02-12"
LABEL com.example.version.is-production=""

⼀个镜像可以包含多个标签,在 1.10 之前,建议将所有标签合并为⼀条 LABEL 指令,以防⽌创建额外的层,但是现在这个不再是必须的了,以上内容也可以写成下⾯这样:

# Set multiple labels at once, using line-continuation characters to break long lines
LABEL vendor=ACME\ Incorporated \
com.example.is-production="" \
com.example.version="0.0.1-beta" \
com.example.release-date="2015-02-12"

获取标签可以接受的键值对信息,参考 Understanding object labels

# RUN

为了保持 Dockerfile ⽂件的可读性,以及可维护性,建议将⻓的或复杂的 RUN 指令⽤反斜杠 \ 分割成多⾏。

RUN 指令最常⻅的⽤法是⽤ apt-get 安装软件包。因为 RUN apt-get 指令会安装软件包,所以有⼏个问题需要注意:

  • 不要使⽤ RUN apt-get upgradedist-upgrade,如果基础镜像中的某个包过时了,你应该联系它的维护者。如果你确定某个特定的包需要更新,⽐如 foo,需要升级,使⽤ apt-get install -y foo 就⾏,该指令会⾃动升级 foo 包。
  • 始终将 RUN apt-get updateapt-get install 组合成⼀条 RUN 声明,例如:
    RUN apt-get update && apt-get install -y \
          package-bar \
          package-baz \
          package-foo
    

apt-get update 放在⼀条单独的 RUN 声明中会导致缓存问题以及后续的 apt-get install 失败。⽐如,假设你有⼀个 Dockerfile ⽂件:

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y curl

构建镜像后,所有的层都在 Docker 的缓存中。假设你后来⼜修改了其中的 apt-get install 添加了⼀个包:

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y curl nginx

Docker 发现修改后的 RUN apt-get update 指令和之前的完全⼀样。所以,apt-get update 不会执⾏,⽽是使⽤之前的缓存镜像。因为 apt-get update 没有运⾏,后⾯的 apt-get install 可能安装的是 过时的curl 和 nginx 版本

使⽤ RUN apt-get update && apt-get install -y 可以确保你的 Dockerfiles 每次安装的都是包的最新的版本,⽽且这个过程不需要进⼀步的编码或额外⼲预。

这项技术叫作 cache busting(缓存清除) 。您还可以通过指定软件包版本来实现 缓存清除,这就是所谓的 版本固定,例如:

RUN apt-get update && apt-get install -y \
package-bar \
package-baz \
package-foo=1.3.*

版本固定 会迫使构建过程检索特定的版本,⽽不管缓存中有什么。这项技术也可以减少因所需包中未预料到的变化⽽导致的失败。

下⾯是⼀个 RUN 指令的示例模板,展示了所有关于 apt-get 的建议。

RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    dpkg-sig \
    libcap-dev \
    libsqlite3-dev \
    mercurial \
    reprepro \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \
 && rm -rf /var/lib/apt/lists/*

其中 s3cmd 指令指定了版本号为 1.1.* 。如果之前的镜像使⽤的是旧版本,指定新的版本会导致 apt-get udpate 缓存失效并确保安装的是新版本。

另外,清理掉 apt 缓存 var/lib/apt/lists 可以减⼩镜像⼤⼩。因为 RUN 指令的开头为 apt-get udpate,包缓存总是会在 apt-get install 之前刷新。

注意:官⽅的 Debian 和 Ubuntu 镜像会⾃动运⾏ apt-get clean,所以不需要显式的调⽤ apt-get clean。

# CMD

CMD 指令用于执行目标镜像中 包含的软件,可以包含参数。CMD 大多数情况下都应该以 CMD ["executable", "param1", "param2"...] 的形式使用。

因此,如果创建镜像的目的是为了部署某个服务(比如 Apache),你可能会执行类似于 CMD ["apache2", "-DFOREGROUND"] 形式的命令。建议任何服务镜像都使用这种形式的命令。

多数情况下,CMD 都需要一个交互式的 shell (bash, Python, perl 等),例如 CMD ["perl", "-de0"],或者 CMD ["PHP", "-a"]

使用这种形式意味着,当你执行类似 docker run -it python 时,你会进入一个准备好的 shell 中。

CMD 在极少的情况下才会以 CMD ["param", "param"] 的形式与 ENTRYPOINT 协同使⽤,除非你和你的镜像使用者都对 ENTRYPOINT 的工作方式十分熟悉。

# EXPOSE

EXPOSE 指令⽤于指定 容器将要监听的端⼝。因此,你应该为你的应⽤程序使⽤ 常⻅的端⼝

例如,提供 Apache web 服务的镜像应该使⽤ EXPOSE 80,⽽提供 MongoDB 服务的镜像使⽤ EXPOSE 27017

对于外部访问,用户可以在执行 docker run 时使用一个标志 p 来指示如何将指定的端口映射到所选择的端口。

# ENV

为了方便新程序运行,你可以使用 ENV 来为容器中安装的程序更新 PATH 环境变量 。例如使用 ENV PATH /usr/local/nginx/bin:$PATH 来确保 CMD ["nginx"] 能正确运行。

ENV 指令也可用于为你想要容器化的服务提供必要的环境变量,比如 Postgres 需要的 PGDATA

最后,ENV 也能用于设置常见的 版本号,比如下面的示例:

ENV PG_MAJOR 9.3
ENV PG_VERSION 9.3.4
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH

类似于程序中的常量,这种⽅法可以让你只需改变 ENV 指令来⾃动的改变容器中的软件版本。

# ADD 和 COPY

虽然 ADDCOPY 功能类似,但⼀般 优先使⽤ COPY。因为它⽐ ADD 更透明。

COPY 只⽀持简单将本地⽂件拷⻉到容器中,⽽ ADD 有⼀些并不明显的功能(⽐如本地 tar 解压缩和远程 URL ⽀持)。

因此,ADD 的最佳⽤例是将本地 tar ⽂件⾃动解压缩到镜像中,例如 ADD rootfs.tar.xz

如果你的 Dockerfile 有多个步骤需要使用上下文中不同的文件。单独 COPY 每个文件,而不是一次性的 COPY 所有文件,这将保证每个步骤的构建缓存只在特定的文件变化时失效。例如:

COPY requirements.txt /tmp/
RUN pip install --requirement /tmp/requirements.txt
COPY . /tmp/

如果将 COPY . /tmp/ 放置在 RUN 指令之前,只要 . 目录中任何一个文件变化,都会导致后续指令的缓存失效。

为了让镜像尽量小,最好不要使用 ADD 指令从远程 URL 获取包,而是使用 curlwget。这样你可以在文件解压缩完之后删掉不再需要的文件来避免在镜像中额外添加一层。比如尽量避免下面的用法:

ADD http://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all

而是应该使用下面这种方法:

RUN mkdir -p /usr/src/things \
    && curl -SL http://example.com/big.tar.xz \
    | tar -xJC /usr/src/things \
    && make -C /usr/src/things all

上面使用的 管道操作,所以没有中间文件需要删除。

对于其他不需要 ADD 的自动解压缩功能的文件或目录,你应该使用 COPY

# ENTRYPOINT

ENTRYPOINT 的最佳⽤处是 设置镜像的主命令,允许将镜像当成命令本身来运⾏(⽤ CMD 提供默认选项)。

例如,下⾯的示例镜像提供了命令⾏⼯具 s3cmd:

ENTRYPOINT ["s3cmd"]
CMD ["--help"]

现在直接运行该镜像创建的容器会显示命令帮助:

$ docker run s3cmd

或者提供正确的参数来执行某个命令:

$ docker run s3cmd ls s3://mybucket

这样镜像名可以当成命令⾏的参考。

ENTRYPOINT 指令也可以与辅助脚本结合使用,当该启动工具需要不止一个步骤。

例如,Postgres 官方镜像使用下面的脚本作为 ENTRYPOINT

#!/bin/bash
set -e

if [ "$1" = 'postgres' ]; then
    chown -R postgres "$PGDATA"

    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi

    exec gosu postgres "$@"
fi

exec "$@"
注意:该脚本使⽤了 Bash 的内置命令 exec,所以最后运⾏的进程就是容器的 PID 为 1 的进程。
这样,进程就可以接收到任何发送给容器的 Unix 信号了。

该辅助脚本被拷贝到容器,并在容器启动时通过 ENTRYPOINT 执行:

COPY ./docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]

该脚本可以让用户用几种不同的方式和 Postgres 交互。

你可以很简单地启动 Postgres

docker run postgres

也可以在执行 Postgres 时传递参数:

docker run postgres postgres --help

最后,你还可以启动另外一个完全不同的工具,比如 Bash

docker run --rm -it postgres bash

# VOLUME

VOLUME 指令用于暴露任何数据库存储文件,配置文件,或容器创建的文件和目录。强烈建议使用 VOLUME 来管理镜像中的可变部分和用户可以改变的部分。

通过 VOLUME 数据卷,可以实现 Docker数据共享与持久化

# USER

如果某个服务不需要特权执行,建议使用 USER 指令切换到 非 root 用户

先在 Dockerfile 中使用类似 RUN groupadd -r postgres && useradd -r -g postgres postgres 的指令 创建用户和用户组

注意:在镜像中,用户和用户组每次被分配的 UID/GID 都是不确定的,下次重新构建镜像时被分配到的 UID/GID 可能会不一样。如果要依赖确定的 UID/GID,你应该显示的指定一个 UID/GID。

你应该 避免使用 sudo,因为它 不可预期的 TTY信号转发行为 可能导致造成的问题比它能解决的问题还多。

如果你真的需要和 sudo 类似的功能(例如,以 root 权限初始化某个守护进程,以非 root 权限执行它),请考虑使用 gosu

最后,为了减少层数和复杂度,避免频繁地使用 USER 来回切换用户

# WORKDIR

为了清晰性和可靠性,你应该总是在 WORKDIR 中使用 绝对路径

另外,你应该使用 WORKDIR 来替代类似于 RUN cd ... && do-something 的指令,后者难以阅读、排错和维护。

# ONBUILD

格式:ONBUILD <其它指令>。

ONBUILD 是⼀个特殊的指令,它后⾯跟的是其它指令,⽐如 RUNCOPY 等,⽽这些指令,在当前镜像构建时并不会被执⾏。只有当以当前镜像为基础镜像,去构建下⼀级镜像的时候才会被执⾏

Dockerfile 中的其它指令都是为了 定制当前镜像 ⽽准备的,唯有 ONBUILD 是为了 帮助别⼈定制自己⽽准备的

假设我们要制作 Node.js 应⽤的镜像。我们都知道 Node.js 使⽤ npm 进⾏ 包管理,所有依赖、配置、启动信息等会放到 package.json ⽂件⾥。

在拿到程序代码后,需要先运行 npm install 获得所有需要的依赖。然后就可以通过 npm start 来启动应⽤。

因此,⼀般来说 Dockerfile 文件如下:

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

Dockerfile 放到 Node.js 项目的根目录下,构建好镜像后,就可以直接拿来启动容器运⾏。但是如果我们还有第⼆个 Node.js 项⽬也差不多呢?好吧,那就再把这个 Dockerfile 复制到第⼆个项⽬⾥。那如果有第三个项⽬呢?再复制么?⽂件的副本越多,版本控制就越困难,让我们继续看这样的场景维护的问题:

如果第⼀个 Node.js 项⽬在开发过程中,发现这个 Dockerfile ⾥存在问题,⽐如敲错字了、或者需要安装额外的包,然后开发⼈员修复了这个 Dockerfile,再次构建,问题解决。第⼀个项⽬没问题了,但是第⼆个项⽬呢?虽然最初 Dockerfile 是复制、粘贴⾃第⼀个项⽬的,但是并不会因为第⼀个项⽬修复了他们的 Dockerfile,⽽第⼆个项⽬的 Dockerfile` 就会被⾃动修复。

那么我们可不可以做⼀个 基础镜像,然后各个项⽬使⽤这个基础镜像呢?这样基础镜像更新,各个项目不用手动同步 Dockerfile 的变化,重新构建后就继承了基础镜像的更新?好吧,可以,让我们看看这样的结果。那么上⾯的这个 Dockerfile 就会变为:

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

这里我们把项⽬相关的构建指令拿出来,放到⼦项⽬⾥去。假设这个基础镜像的名字为 my-node 的话,各个项⽬内的⾃⼰的 Dockerfile 就变为:

FROM my-node
COPY ./package.json /app
RUN [ "npm", "install" ]
COPY . /app/

基础镜像变化后,各个项⽬都⽤这个 Dockerfile 重新构建镜像,会继承基础镜像的更新。

那么,问题解决了么?没有。准确说,只解决了⼀半。如果这个 Dockerfile ⾥⾯有些东⻄需要调整呢?⽐如 npm install 都需要加⼀些参数,那怎么办?这⼀⾏ RUN 是不可能放⼊基础镜像的,因为涉及到了当前项⽬的 ./package.json,难道⼜要⼀个个修改么?所以说,这样制作基础镜像,只解决了原来的 Dockerfile 的前4条指令的变化问题,⽽后⾯三条指令的变化则完全没办法处理。

ONBUILD 可以解决这个问题。让我们⽤ ONBUILD 重新写⼀下基础镜像的 Dockerfile:

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

这次我们回到原始的 Dockerfile,但是这次将项⽬相关的指令加上 ONBUILD,这样在构建基础镜像的时候,这三行并不会被执⾏。然后各个项⽬的 Dockerfile 就变成了简单地:

FROM my-node

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

# 官方仓库示例

这些官方仓库的 Dockerfile 都是参考典范:https://github.com/docker-library/docs

# 参考

更新时间: 7/31/2020, 6:44:44 PM