docker引擎
Docker 引擎由如下主要的组件构成：Docker 客户端（Docker Client）、Docker 守护进程（Docker daemon）、containerd 以及 runc。它们共同负责容器的创建和运行。
Docker 首次发布时，Docker 引擎由两个核心组件构成：LXC 和 Docker daemon。
Docker daemon 是单一的二进制文件，包含诸如 Docker 客户端、Docker API、容器运行时、镜像构建等。
LXC 提供了对诸如命名空间（Namespace）和控制组（CGroup）等基础工具的操作能力，它们是基于 Linux 内核的容器虚拟化技术。
下图阐释了在 Docker 旧版本中，Docker daemon、LXC 和操作系统之间的交互关系。
摆脱 LXC
对 LXC 的依赖自始至终都是个问题。
首先，LXC 是基于 Linux 的。这对于一个立志于跨平台的项目来说是个问题。
其次，如此核心的组件依赖于外部工具，这会给项目带来巨大风险，甚至影响其发展。
因此，Docker 公司开发了名为 Libcontainer 的自研工具，用于替代 LXC。
Libcontainer 的目标是成为与平台无关的工具，可基于不同内核为 Docker 上层提供必要的容器交互功能。
在 Docker 0.9 版本中，Libcontainer 取代 LXC 成为默认的执行驱动。
摒弃大而全的 Docker daemon
随着时间的推移，Docker daemon 的整体性带来了越来越多的问题。难于变更、运行越来越慢。这并非生态（或Docker公司）所期望的。
Docker 公司意识到了这些问题，开始努力着手拆解这个大而全的 Docker daemon 进程，并将其模块化。
这项任务的目标是尽可能拆解出其中的功能特性，并用小而专的工具来实现它。这些小工具可以是可替换的，也可以被第三方拿去用于构建其他工具。
这一计划遵循了在 UNIX 中得以实践并验证过的一种软件哲学：小而专的工具可以组装为大型工具。
这项拆解和重构 Docker 引擎的工作仍在进行中。不过，所有容器执行和容器运行时的代码已经完全从 daemon 中移除，并重构为小而专的工具。
目前 Docker 引擎的架构示意图如下图所示，图中有简要的描述。
开放容器计划（OCI）的影响
当 Docker 公司正在进行 Docker daemon 进程的拆解和重构的时候，OCI 也正在着手定义两个容器相关的规范（或者说标准）。
镜像规范和容器运行时规范，两个规范均于 2017 年 7 月发布了 1.0 版。
Docker 公司参与了这些规范的制定工作，并贡献了许多的代码。
从 Docker 1.11 版本（2016 年初）开始，Docker 引擎尽可能实现了 OCI 的规范。例如，Docker daemon 不再包含任何容器运行时的代码——所有的容器运行代码在一个单独的 OCI 兼容层中实现。
默认情况下，Docker 使用 runc 来实现这一点。runc 是 OCI 容器运行时标准的参考实现。
如上图中的 runc 容器运行时层。runc 项目的目标之一就是与 OCI 规范保持一致。
目前 OCI 规范均为 1.0 版本，我们不希望它们频繁地迭代，毕竟稳定胜于一切。
除此之外，Docker 引擎中的 containerd 组件确保了 Docker 镜像能够以正确的 OCI Bundle 的格式传递给 runc。
其实，在 OCI 规范以 1.0 版本正式发布之前，Docker 引擎就已经遵循该规范实现了部分功能。
runc
如前所述，runc 是 OCI 容器运行时规范的参考实现。Docker 公司参与了规范的制定以及 runc 的开发
去粗取精，会发现 runc 实质上是一个轻量级的、针对 Libcontainer 进行了包装的命令行交互工具（Libcontainer 取代了早期 Docker 架构中的 LXC）。
runc 生来只有一个作用——创建容器，这一点它非常拿手，速度很快！不过它是一个 CLI 包装器，实质上就是一个独立的容器运行时工具。
因此直接下载它或基于源码编译二进制文件，即可拥有一个全功能的 runc。但它只是一个基础工具，并不提供类似 Docker 引擎所拥有的丰富功能。
有时也将 runc 所在的那一层称为“OCI 层”，如上图所示。关于 runc 的发布信息见 GitHub 中 opencontainers/runc 库的 release。
containerd
在对 Docker daemon 的功能进行拆解后，所有的容器执行逻辑被重构到一个新的名为 containerd（发音为 container-dee）的工具中。
它的主要任务是容器的生命周期管理——start | stop | pause | rm....
containerd 在 Linux 和 Windows 中以 daemon 的方式运行，从 1.11 版本之后 Docker 就开始在 Linux 上使用它。
Docker 引擎技术栈中，containerd 位于 daemon 和 runc 所在的 OCI 层之间。Kubernetes 也可以通过 cri-containerd 使用 containerd。
如前所述，containerd 最初被设计为轻量级的小型工具，仅用于容器的生命周期管理。然而，随着时间的推移，它被赋予了更多的功能，比如镜像管理。
其原因之一在于，这样便于在其他项目中使用它。比如，在 Kubernetes 中，containerd 就是一个很受欢迎的容器运行时。
然而在 Kubernetes 这样的项目中，如果 containerd 能够完成一些诸如 push 和 pull 镜像这样的操作就更好了。
因此，如今 containerd 还能够完成一些除容器生命周期管理之外的操作。不过，所有的额外功能都是模块化的、可选的，便于自行选择所需功能。
所以，Kubernetes 这样的项目在使用 containerd 时，可以仅包含所需的功能。
containerd 是由 Docker 公司开发的，并捐献给了云原生计算基金会（Cloud Native Computing Foundation, CNCF）。2017 年 12 月发布了 1.0 版本，具体的发布信息见 GitHub 中的 containerd/ containerd 库的 releases。
启动一个新的容器
现在我们对 Docker 引擎已经有了一个总体认识，也了解了一些历史，下面介绍一下创建新容器的过程。
常用的启动容器的方法就是使用 Docker 命令行工具。下面的docker container run命令会基于 alpine:latest 镜像启动一个新容器。
$ docker container run --name ctr1 -it alpine:latest sh
当使用 Docker 命令行工具执行如上命令时，Docker 客户端会将其转换为合适的 API 格式，并发送到正确的 API 端点。
API 是在 daemon 中实现的。这套功能丰富、基于版本的 REST API 已经成为 Docker 的标志，并且被行业接受成为事实上的容器 API。
一旦 daemon 接收到创建新容器的命令，它就会向 containerd 发出调用。daemon 已经不再包含任何创建容器的代码了！
daemon 使用一种 CRUD 风格的 API，通过 gRPC 与 containerd 进行通信。
虽然名叫 containerd，但是它并不负责创建容器，而是指挥 runc 去做。
containerd 将 Docker 镜像转换为 OCI bundle，并让 runc 基于此创建一个新的容器。
然后，runc 与操作系统内核接口进行通信，基于所有必要的工具（Namespace、CGroup等）来创建容器。容器进程作为 runc 的子进程启动，启动完毕后，runc 将会退出。
至此，容器启动完毕。整个过程如下图所示。
该模型的显著优势
将所有的用于启动、管理容器的逻辑和代码从 daemon 中移除，意味着容器运行时与 Docker daemon 是解耦的，有时称之为“无守护进程的容器（daemonless container）”，如此，对 Docker daemon 的维护和升级工作不会影响到运行中的容器。
在旧模型中，所有容器运行时的逻辑都在 daemon 中实现，启动和停止 daemon 会导致宿主机上所有运行中的容器被杀掉。
这在生产环境中是一个大问题——想一想新版 Docker 的发布频次吧！每次 daemon 的升级都会杀掉宿主机上所有的容器，这太糟了！
幸运的是，这已经不再是个问题。
shim
shim 是实现无 daemon 的容器（用于将运行中的容器与 daemon 解耦，以便进行 daemon 升级等操作）不可或缺的工具。
前面提到，containerd 指挥 runc 来创建新容器。事实上，每次创建容器时它都会 fork 一个新的 runc 实例。
不过，一旦容器创建完毕，对应的 runc 进程就会退出。因此，即使运行上百个容器，也无须保持上百个运行中的 runc 实例。
一旦容器进程的父进程 runc 退出，相关联的 containerd-shim 进程就会成为容器的父进程。作为容器的父进程，shim 的部分职责如下。
- 保持所有 STDIN 和 STDOUT 流是开启状态，从而当 daemon 重启的时候，容器不会因为管道（pipe）的关闭而终止。
- 将容器的退出状态反馈给 daemon。
在 Linux 中的实现
在 Linux 系统中，前面谈到的组件由单独的二进制来实现，具体包括 dockerd(Docker daemon)、docker-containerd(containerd)、docker-containerd-shim (shim) 和 docker-runc (runc)。
通过在 Docker 宿主机的 Linux 系统中执行 ps 命令可以看到以上组件的进程。当然，有些进程只有在运行容器的时候才可见。
daemon 的作用
当所有的执行逻辑和运行时代码都从 daemon 中剥离出来之后，问题出现了—— daemon 中还剩什么？
显然，随着越来越多的功能从 daemon 中拆解出来并被模块化，这一问题的答案也会发生变化。
不过，daemon 的主要功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。
docker镜像
拉取镜像
docker image pull 是下载镜像的命令。镜像从远程镜像仓库服务的仓库中下载。
默认情况下，镜像会从 Docker Hub 的仓库中拉取。docker image pull alpine:latest 命令会从 Docker Hub 的 alpine 仓库中拉取标签为 latest 的镜像。
可以使用以下命令检查 Docker 主机的本地仓库中是否包含镜像。
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
Docker 镜像存储在镜像仓库服务（Image Registry）当中。
Docker 客户端的镜像仓库服务是可配置的，默认使用 Docker Hub。
镜像仓库服务包含多个镜像仓库（Image Repository）。同样，一个镜像仓库中可以包含多个镜像。
可能这听起来让人有些迷惑，所以下图展示了包含 3 个镜像仓库的镜像仓库服务，其中每个镜像仓库都包含一个或多个镜像。
镜像命名和标签
只需要给出镜像的名字和标签，就能在官方仓库中定位一个镜像（采用“:”分隔）。从官方仓库拉取镜像时，docker image pull 命令的格式如下。
docker image pull <repository>:<tag>
在之前的 Linux 示例中，通过下面的两条命令完成 Alpine 和 Ubuntu 镜像的拉取。
docker image pull alpine:latest
docker image pull ubuntu:latest
这两条命令从 alpine 和 ubuntu 仓库拉取了标有“latest”标签的镜像。
下面来介绍一下如何从官方仓库拉取不同的镜像。
$ docker image pull mongo:3.3.11
//该命令会从官方Mongo库拉取标签为3.3.11的镜像
$ docker image pull redis:latest
//该命令会从官方Redis库拉取标签为latest的镜像
$ docker image pull alpine
//该命令会从官方Alpine库拉取标签为latest的镜像
$ docker image pull nigelpoulton/tu-demo:v2
//该命令会从以我自己的 Docker Hub 账号为命名空间的 tu-demo 库中下载标签为 v2 的镜像
在 docker image pull 命令中指定 -a 参数来拉取仓库中的全部镜像。接下来可以通过运行 docker image ls 查看已经拉取的镜像。
过滤 docker image ls 的输出内容
Docker 提供 --filter 参数来过滤 docker image ls 命令返回的镜像列表内容。
下面的示例只会返回悬虚（dangling）镜像。
$ docker image ls --filter dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 4fd34165afe0 7 days ago 14.5MB
那些没有标签的镜像被称为悬虚镜像，在列表中展示为<none>:<none>。
通常出现这种情况，是因为构建了一个新镜像，然后为该镜像打了一个已经存在的标签。
当此情况出现，Docker 会构建新的镜像，然后发现已经有镜像包含相同的标签，接着 Docker 会移除旧镜像上面的标签，将该标签标在新的镜像之上。
可以通过 docker image prune 命令移除全部的悬虚镜像。如果添加了 -a 参数，Docker 会额外移除没有被使用的镜像（那些没有被任何容器使用的镜像）。
Docker 目前支持如下的过滤器。
- dangling：可以指定 true 或者 false，仅返回悬虚镜像（true），或者非悬虚镜像（false）。
- before：需要镜像名称或者 ID 作为参数，返回在之前被创建的全部镜像。
- since：与 before 类似，不过返回的是指定镜像之后创建的全部镜像。
- label：根据标注（label）的名称或者值，对镜像进行过滤。docker image ls命令输出中不显示标注内容。
其他的过滤方式可以使用 reference。
下面就是使用 reference 完成过滤并且仅显示标签为 latest 的示例。
$ docker image ls --filter=reference="*:latest"
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest 3fd9065eaf02 8 days ago 4.15MB
test latest 8426e7efb777 3 days ago 122MB
通过 CLI 方式搜索 Docker Hub
docker search 命令允许通过 CLI 的方式搜索 Docker Hub。可以通过“NAME”字段的内容进行匹配，并且基于返回内容中任意列的值进行过滤。
简单模式下，该命令会搜索所有“NAME”字段中包含特定字符串的仓库。例如，下面的命令会查找所有“NAME”包含“nigelpoulton”的仓库。
$ docker search nigelpoulton
NAME DESCRIPTION STARS AUTOMATED
nigelpoulton/pluralsight.. Web app used in... 8 [OK]
nigelpoulton/tu-demo 7
nigelpoulton/k8sbook Kubernetes Book web app 1
nigelpoulton/web-fe1 Web front end example 0
nigelpoulton/hello-cloud Quick hello-world image 0
“NAME”字段是仓库名称，包含了 Docker ID，或者非官方仓库的组织名称。例如，下面的命令会列出所有仓库名称中包含“alpine”的镜像。
$ docker search alpine
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
alpine A minimal Docker.. 2988 [OK]
mhart/alpine-node Minimal Node.js.. 332
anapsix/alpine-java Oracle Java 8... 270 [OK]
<Snip>
需要注意，上面返回的镜像中既有官方的也有非官方的。读者可以使用 --filter "is-official=true"，使命令返回内容只显示官方镜像。
镜像和分层
查看镜像分层的方式可以通过 docker image inspect 命令。
docker image inspect grafana/grafana:7.0.5
docker history 命令显示了镜像的构建历史记录，但其并不是严格意义上的镜像分层。例如，有些 Dockerfile 中的指令并不会创建新的镜像层。比如 ENV、EXPOSE、CMD 以及 ENTRY- POINT。不过，这些命令会在镜像中添加元数据。
所有的 Docker 镜像都起始于一个基础镜像层，当进行修改或增加新的内容时，就会在当前镜像层之上，创建新的镜像层。
举一个简单的例子，假如基于 Ubuntu Linux 16.04 创建一个新的镜像，这就是新镜像的第一层；如果在该镜像中添加 Python 包，就会在基础镜像层之上创建第二个镜像层；如果继续添加一个安全补丁，就会创建第三个镜像层。
该镜像当前已经包含 3 个镜像层，如下图所示（这只是一个用于演示的很简单的例子）。
多个镜像之间可以并且确实会共享镜像层。这样可以有效节省空间并提升性能。Docker 很聪明，可以识别出要拉取的镜像中，哪几层已经在本地存在。
在本例中，Docker 首先尝试拉取标签为 latest 的镜像。然后，当拉取标签为 v1 和 v2 的镜像时，Docker 注意到组成这两个镜像的镜像层，有一部分已经存在了。出现这种情况的原因是前面 3 个镜像相似度很高，所以共享了很多镜像层。
如前所述，Docker 在 Linux 上支持很多存储引擎（Snapshotter）。每个存储引擎都有自己的镜像分层、镜像层共享以及写时复制（CoW）技术的具体实现。
根据摘要区分同一个标签下的镜像是否是同一个。Docker 1.10 中引入了新的内容寻址存储模型。作为模型的一部分，每一个镜像现在都有一个基于其内容的密码散列值。
每次拉取镜像，摘要都会作为 docker image pull 命令返回代码的一部分。只需要在 docker image ls 命令之后添加 --digests 参数即可在本地查看镜像摘要。
接下来通过示例进行相关演示。
$ docker image pull alpine
Using default tag: latest
latest: Pulling from library/alpine
e110a4a17941: Pull complete
Digest: sha256:3dcdb92d7432d56604d...6d99b889d0626de158f73a
Status: Downloaded newer image for alpine:latest
$ docker image ls --digests alpine
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
alpine latest sha256:3dcd...f73a 4e38e38c8ce0 10 weeks ago 4.8 MB
从上面的代码片段中可知，Alpine 镜像的签名值如下。
sha256:3dcdb92d7432d56604d... 6d99b889d0626de158f73a。
现在已知镜像的摘要，那么可以使用摘要值再次拉取这个镜像。这种方式可以确保准确拉取想要的镜像。
没有原生 Docker 命令支持从远端镜像仓库服务（如Docker Hub）中获取镜像签名。这意味着只能先通过标签方式拉取镜像到本地，然后自己维护镜像的摘要列表。镜像摘要在未来绝对不会发生变化。
下面通过示例首先在 Docker 主机上删除 alpine:latest 镜像，然后显示如何通过摘要（而不是标签）来再次拉取该镜像。
$ docker image rm alpine:latest
Untagged: alpine:latest
Untagged: alpine@sha256:c0537...7c0a7726c88e2bb7584dc96
Deleted: sha256:02674b9cb179d...abff0c2bf5ceca5bad72cd9
Deleted: sha256:e154057080f40...3823bab1be5b86926c6f860
$ docker image pull alpine@sha256:c0537...7c0a7726c88e2bb7584dc96
sha256:c0537...7726c88e2bb7584dc96: Pulling from library/alpine
cfc728c1c558: Pull complete
Digest: sha256:c0537ff6a5218...7c0a7726c88e2bb7584dc96
Status: Downloaded newer image for alpine@sha256:c0537...bb7584dc96
随着 Docker 的发展，事情开始变得复杂——尤其是在添加了新平台和架构之后，例如 Windows、ARM 以及 s390x。
这是会突然发现，在拉取镜像并运行之前，需要考虑镜像是否与当前运行环境的架构匹配，这破坏了 Docker 的流畅体验。
多架构镜像（Multi-architecture Image）的出现解决了这个问题！
Docker（镜像和镜像仓库服务）规范目前支持多架构镜像。这意味着某个镜像仓库标签（repository:tag）下的镜像可以同时支持 64 位 Linux、PowerPC Linux、64 位 Windows 和 ARM 等多种架构。
简单地说，就是一个镜像标签之下可以支持多个平台和架构。下面通过实操演示该特性。
为了实现这个特性，镜像仓库服务 API 支持两种重要的结构：Manifest 列表（新）和 Manifest。
Manifest 列表是指某个镜像标签支持的架构列表。其支持的每种架构，都有自己的 Mainfest 定义，其中列举了该镜像的构成。
下图使用 Golang 官方镜像作为示例。图左侧是 Manifest 列表，其中包含了该镜像支持的每种架构。
Manifest 列表的每一项都有一个箭头，指向具体的 Manifest，其中包含了镜像配置和镜像层数据。
在具体操作之前，先来了解一下原理。
假设要在 Raspberry Pi（基于 ARM 架构的 Linux）上运行 Docker。
在拉取镜像的时候，Docker 客户端会调用 Docker Hub 镜像仓库服务相应的 API 完成拉取。
如果该镜像有 Mainfest 列表，并且存在 Linux on ARM 这一项，则 Docker Client 就会找到 ARM 架构对应的 Mainfest 并解析出组成该镜像的镜像层加密 ID。
然后从 Docker Hub 二进制存储中拉取每个镜像层。
下面的示例中通过镜像 ID 来删除镜像，可能跟读者机器上镜像 ID 有所不同。
$ docker image rm 02674b9cb179
Untagged: alpine@sha256:c0537ff6a5218...c0a7726c88e2bb7584dc96
Deleted: sha256:02674b9cb179d57...31ba0abff0c2bf5ceca5bad72cd9
Deleted: sha256:e154057080f4063...2a0d13823bab1be5b86926c6f860
如果被删除的镜像上存在运行状态的容器，那么删除操作不会被允许。再次执行删除镜像命令之前，需要停止并删除该镜像相关的全部容器。
一种删除某 Docker 主机上全部镜像的快捷方式是在 docker image rm 命令中传入当前系统的全部镜像 ID，可以通过 docker image ls 获取全部镜像 ID（使用 -q 参数）。
如果是在 Windows 环境中，那么只有在 PowerShell 终端中执行才会生效。在 CMD 中执行并不会生效。
$ docker image rm $(docker image ls -q) -f
docker容器（container）详解
容器是镜像的运行时实例。正如从虚拟机模板上启动 VM 一样，用户也同样可以从单个镜像上启动一个或多个容器。
虚拟机和容器最大的区别是容器更快并且更轻量级——与虚拟机运行在完整的操作系统之上相比，容器会共享其所在主机的操作系统/内核。
docker container run <image> <app> 指定了启动所需的镜像以及要运行的应用。
docker container run -it ubuntu /bin/bash则会启动某个 Ubuntu Linux 容器，并运行 Bash Shell 作为其应用。
最终，在命令中指定了运行在容器中的程序，Linux 示例中是 Bash Shell，Windows 示例中为 PowerShell。
当敲击回车键之后，Docker 客户端选择合适的 API 来调用 Docker daemon。
Docker daemon 接收到命令并搜索 Docker 本地缓存，观察是否有命令所请求的镜像。
在上面引用的示例中，本地缓存并未包含该镜像，所以 Docker 接下来查询在 Docker Hub 中是否存在对应镜像。找到该镜像后，Docker 将镜像拉取到本地，存储在本地缓存当中。
可以使用 docker container stop 命令手动停止容器运行，并且使用 docker container start 再次启动该容器。
可以使用 docker container ls 命令来观察当前系统正在运行的容器列表。
$ docker container exec -it 3027eb644874 bash 进入到容器内部
Dockerfile
接下来了解一下 Dockerfile 文件当中都包含哪些具体内容。
$ cat Dockerfile
FROM alpine
LABEL maintainer="nigelpoulton@hotmail.com"
RUN apk add --update nodejs nodejs-npm
COPY . /src
WORKDIR /src
RUN npm install
EXPOSE 8080
ENTRYPOINT ["node", "./app.js"]
Dockerfile 主要包括两个用途：
- 对当前应用的描述。
- 指导 Docker 完成应用的容器化（创建一个包含当前应用的镜像）。
下面是这个文件中的一些关键步骤概述：以 alpine 镜像作为当前镜像基础，指定维护者（maintainer）为“nigelpoultion@hotmail.com”，安装 Node.js 和 NPM，将应用的代码复制到镜像当中，设置新的工作目录，安装依赖包，记录应用的网络端口，最后将 app.js 设置为默认运行的应用。
每个 Dockerfile 文件第一行都是 FROM 指令。
FROM 指令指定的镜像，会作为当前镜像的一个基础镜像层，当前应用的剩余内容会作为新增镜像层添加到基础镜像层之上。FROM 指令当中所引用的也是一个 Linux 基础镜像
接下来，Dockerfile 中通过标签（LABLE）方式指定了当前镜像的维护者为“nigelpoulton@hotmail. com”。每个标签其实是一个键值对（Key-Value），在一个镜像当中可以通过增加标签的方式来为镜像添加自定义元数据。备注维护者信息有助于为该镜像的潜在使用者提供沟通途径，这是一种值得提倡的做法。
RUN apk add --update nodejs nodejs-npm 指令使用 alpine 的 apk 包管理器将 nodejs 和 nodejs-npm 安装到当前镜像之中。RUN 指令会在 FROM 指定的 alpine 基础镜像之上，新建一个镜像层来存储这些安装内容。当前镜像的结构如下图所示。
COPY. / src 指令将应用相关文件从构建上下文复制到了当前镜像中，并且新建一个镜像层来存储。COPY 执行结束之后，当前镜像共包含 3 层，如下图所示。
下一步，Dockerfile 通过 WORKDIR 指令，为 Dockerfile 中尚未执行的指令设置工作目录。该目录与镜像相关，并且会作为元数据记录到镜像配置中，但不会创建新的镜像层。然后，RUN npm install 指令会根据 package.json 中的配置信息，使用 npm 来安装当前应用的相关依赖包。npm 命令会在前文设置的工作目录中执行，并且在镜像中新建镜像层来保存相应的依赖文件。
因为当前应用需要通过 TCP 端口 8080 对外提供一个 Web 服务，所以在 Dockerfile 中通过 EXPOSE 8080 指令来完成相应端口的设置。这个配置信息会作为镜像的元数据被保存下来，并不会产生新的镜像层。
最终，通过 ENTRYPOINT 指令来指定当前镜像的入口程序。ENTRYPOINT 指定的配置信息也是通过镜像元数据的形式保存下来，而不是新增镜像层。
docker compose
多数的现代应用通过多个更小的服务互相协同来组成一个完整可用的应用。比如一个简单的示例应用可能由如下 4 个服务组成。
- Web前端。
- 订单管理。
- 品类管理。
- 后台数据库。
将以上服务组织在一起，就是一个可用的应用。
部署和管理繁多的服务是困难的。而这正是 Docker Compose 要解决的问题。
Docker Compose 并不是通过脚本和各种冗长的 docker 命令来将应用组件组织起来，而是通过一个声明式的配置文件描述整个应用，从而使用一条命令完成部署。
version: "3.5"
services:
web-fe:
build: .
command: python app.py
ports:
- target: 5000
published: 5000
networks:
- counter-net
volumes:
- type: volume
source: counter-vol
target: /code
redis:
image: "redis:alpine"
networks:
counter-net:
networks:
counter-net:
volumes:
counter-vol:这是一个能够对访问者进行计数并将其保存到 Redis 的简单的 Web 服务。
version 是必须指定的，而且总是位于文件的第一行。它定义了 Compose 文件格式（主要是 API）的版本。
services 用于定义不同的应用服务。上边的例子定义了两个服务：一个名为 web-fe 的 Web 前端服务以及一个名为 redis 的内存数据库服务。
Docker Compose 会将每个服务部署在各自的容器中。
networks 用于指引 Docker 创建新的网络。默认情况下，Docker Compose 会创建 bridge 网络。
这是一种单主机网络，只能够实现同一主机上容器的连接。当然，也可以使用 driver 属性来指定不同的网络类型。
volumes 用于指引 Docker 来创建新的卷。
Compose 文件中的 services 部分定义了两个二级 key：web-fe 和 redis。
它们各自定义了一个应用程序服务。需要明确的是，Docker Compose 会将每个服务部署为一个容器，并且会使用 key 作为容器名字的一部分。
本例中定义了两个 key：web-fe 和 redis。因此 Docker Compose 会部署两个容器，一个容器的名字中会包含 web-fe，而另一个会包含 redis。
web-fe 的服务定义中，包含如下指令。
1) build
指定 Docker 基于当前目录（.）下 Dockerfile 中定义的指令来构建一个新镜像。该镜像会被用于启动该服务的容器。
2) command
python app.py 指定 Docker 在容器中执行名为 app.py 的 Python 脚本作为主程序。
因此镜像中必须包含 app.py 文件以及 Python，这一点在 Dockerfile 中可以得到满足。
3) ports
指定 Docker 将容器内（-target）的 5000 端口映射到主机（published）的 5000 端口。
这意味着发送到 Docker 主机 5000 端口的流量会被转发到容器的 5000 端口。容器中的应用监听端口 5000。
4) networks
使得 Docker 可以将服务连接到指定的网络上。这个网络应该是已经存在的，或者是在 networks 一级 key 中定义的网络。
对于 Overlay 网络来说，它还需要定义一个 attachable 标志，这样独立的容器才可以连接上它（这时 Docker Compose 会部署独立的容器而不是 Docker 服务）。
5) volumes
指定 Docker 将 counter-vol 卷（source:）挂载到容器内的 /code（target:）。
counter-vol 卷应该是已存在的，或者是在文件下方的 volumes 一级 key 中定义的。
综上，Docker Compose 会调用 Docker 来为 web-fe 服务部署一个独立的容器。该容器基于与 Compose 文件位于同一目录下的 Dockerfile 构建的镜像。
基于该镜像启动的容器会运行 app.py 作为其主程序，将 5000 端口暴露给宿主机，连接到 counter-net 网络上，并挂载一个卷到/code。
从技术上讲，本例并不需要配置 command: python app.py。因为镜像的 Dockerfile 已经将 python app.py 定义为了默认的启动程序。
但是，本例主要是为了展示其如何执行，因此也可用于覆盖 Dockerfile 中配置的 CMD 指令。
redis 服务的定义相对比较简单。
6) image
redis:alpine 使得 Docker 可以基于 redis:alpine 镜像启动一个独立的名为 redis 的容器。
这个镜像会被从 Docker Hub 上拉取下来。
7) networks
配置 redis 容器连接到 counter-net 网络。
由于两个服务都连接到 counter-net 网络，因此它们可以通过名称解析到对方的地址。了解这一点很重要，本例中上层应用被配置为通过名称与 Redis 服务通信。
1) docker-compose up
用于部署一个 Compose 应用。
默认情况下该命令会读取名为 docker-compose.yml 或 docker-compose.yaml 的文件。
当然用户也可以使用 -f 指定其他文件名。通常情况下，会使用 -d 参数令应用在后台启动。
2) docker-compose stop
停止 Compose 应用相关的所有容器，但不会删除它们。
被停止的应用可以很容易地通过 docker-compose restart 命令重新启动。
3) docker-compose rm
用于删除已停止的 Compose 应用。
它会删除容器和网络，但是不会删除卷和镜像。
4) docker-compose restart
重启已停止的 Compose 应用。
如果用户在停止该应用后对其进行了变更，那么变更的内容不会反映在重启后的应用中，这时需要重新部署应用使变更生效。
5) docker-compose ps
用于列出 Compose 应用中的各个容器。
输出内容包括当前状态、容器运行的命令以及网络端口。
6) docker-compose down
停止并删除运行中的 Compose 应用。
它会删除容器和网络，但是不会删除卷和镜像。
docker卷
1) docker volume create
命令用于创建新卷。默认情况下，新卷创建使用 local 驱动，但是可以通过 -d 参数来指定不同的驱动。
2) docker volume ls
会列出本地 Docker 主机上的全部卷。
3) docker volume inspect
用于查看卷的详细信息。可以使用该命令查看卷在 Docker 主机文件系统中的具体位置。
4) docker volume prune
会删除未被容器或者服务副本使用的全部卷。
5) docker volume rm
删除未被使用的指定卷。