Docker知识整理

《深入浅出Docker》这本书的博客版本，地址为：http://c.biancheng.net/view/3118.html

里面讲的内容比较多，对Docker比较有兴趣的同学可以看看。英文好的，可以看看官方文档：https://docs.docker.com/

 

引擎

结构

 

Docker daemon

功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。

containerd

最初被设计为轻量级的小型工具，仅用于容器的生命周期管理。然而，随着时间的推移，它被赋予了更多的功能，比如镜像管理。

runc

runc 实质上是一个轻量级的、针对 Libcontainer 进行了包装的命令行交互工具。.

Libcontainer——提供了对注入命名空间（Namespace）和控制组（CGroup）等基础工具的操作能力，是基于Linux内核的容器虚拟化技术，前身是LXC。

runc 生来只有一个作用——创建容器，这一点它非常拿手，速度很快！不过它是一个 CLI 包装器，实质上就是一个独立的容器运行时工具。

shim

一旦容器进程的父进程 runc 退出，相关联的 containerd-shim 进程就会成为容器的父进程。作为容器的父进程，shim 的部分职责如下：

• 保持所有 STDIN 和 STDOUT 流是开启状态，从而当 daemon 重启的时候，容器不会因为管道（pipe）的关闭而终止。
• 将容器的退出状态反馈给 daemon。

 

创建容器的流程

• Docker 客户端会将其转换为合适的 API 格式，并发送到Docker daemon
• Docker deamon接收到创建命令，向containerd发出调用
• 将 Docker 镜像转换为 OCI bundle，并让 runc 基于此创建一个新的容器
• runc 与操作系统内核接口进行通信，基于所有必要的工具（Namespace、CGroup等）来创建容器。容器进程作为 runc 的子进程启动，启动完毕后，runc 将会退出

 

镜像

镜像和分层

镜像由一些松耦合的只读镜像层组成。

镜像本身就是一个配置对象，其中包含了镜像层的列表以及一些元数据信息。

镜像层才是实际数据存储的地方（比如文件等，镜像层之间是完全独立的，并没有从属于某个镜像集合的概念）。

Docker 通过存储引擎（新版本采用快照机制）的方式来实现镜像层堆栈，并保证多镜像层对外展示为统一的文件系统。

镜像一般比较小，因为会把不必要的功能裁剪掉。像我们登陆容器的终端，会发现有一些linux的命令是执行不了的，没有安装~

 

 

镜像标签

一个镜像可以有多个标签。那些没有标签的镜像被称为悬虚镜像。对新的镜像打已经存在的标签，docker会移除旧镜像的标签，旧镜像就成悬虚镜像。

docker image ls 命令支持--filter 参数来过滤标签，过滤的方式有：

• dangling：可以指定 true 或者 false，仅返回悬虚镜像（true），或者非悬虚镜像（false）
• before：需要镜像名称或者 ID 作为参数，返回在之前被创建的全部镜像。
• since：与 before 类似，不过返回的是指定镜像之后创建的全部镜像。
• label：根据标注（label）的名称或者值，对镜像进行过滤。docker image ls命令输出中不显示标注内容。

latest标签，是一个特殊的，不需要我们手动打的标签。

如果没有在仓库名称后指定具体的镜像标签，则 Docker 会假设用户希望拉取标签为 latest 的镜像。

标有 latest 标签的镜像不保证这是仓库中最新的镜像！

 

镜像仓库服务

镜像仓库服务包含多个镜像仓库。同样，一个镜像仓库中可以包含多个镜像。

 

共享镜像层

多个镜像之间会共享镜像层。节省空间并提升性能。例如：

• 镜像A，包含镜像层1、2、3
• 镜像B，包含镜像层1、2、3、4

那么2和3，是两个镜像共享的。如果你先pull镜像A，再pull镜像B的时候，只会从镜像仓库下载镜像层4。

如果有镜像C，包含的镜像层是2、3、4，pull镜像A和B之后再pull镜像C，是不会走缓存的......

镜像层是链式搜索的, 根据最底层的镜像层逐步找到上面的层，上面的所有层一样才会走缓存。

 

镜像散列值（摘要）

镜像的唯一标识是一个加密 ID，即配置对象本身的散列值。每个镜像层也由一个加密 ID 区分，其值为镜像层本身内容的散列值。

这意味着修改镜像的内容或其中任意的镜像层，都会导致加密散列值的变化。所以，镜像和其镜像层都是不可变的，任何改动都能很轻松地被辨别。

 

多层架构的镜像

镜像可以同时支持 64 位 Linux、PowerPC Linux、64 位 Windows 和 ARM 等多种架构，即为多层架构——不管是什么操作系统，只要下载了，就可以跑起来。

 

Manifest 列表

Manifest 列表是指某个镜像标签支持的架构列表。其支持的每种架构，都有自己的 Mainfest 定义，其中列举了该镜像的构成。

Manifest

Manifest里描述了在对应的操作系统里，镜像的真正组成——包含哪些镜像层。

 

常用命令

docker image pull

下载镜像的命令，镜像从远程镜像仓库服务的仓库中下载，默认从Docker Hub的仓库中拉取。
例如：docker image pull alpine:latest

docker image ls

列出了本地Docker主机上存储的镜像。可以通过--digests参数来查看镜像的SHA256签名。

docker image inspect

展示了镜像的细节，包括镜像层数据和元数据。

docker image rm

用于删除镜像。当镜像存在关联的容器，并且容器处于运行或者停止状态时，不允许删除该镜像。

 

容器

镜像是一种构建时（build time）结构——类似于java里的类。容器是一种运行时（run time）结构——类似于java的对象。

容器如果不运行任何进程（进程id为1）则无法存在，杀死 Bash Shell 即杀死了容器唯一运行的进程，导致这个容器也被杀死。

 

实现技术

Namespace

内核命名空间属于容器中非常核心的一部分！ 该技术能够将操作系统（OS）进行拆分，使一个操作系统看起来像多个互相独立的操作系统一样。

 

容器使用到的命名空间有：

进程ID（PID）

Docker 使用 PID 命名空间为每个容器提供互相独立的容器树。每个容器都拥有自己的进程树，意味着每个容器都有自己的 PID 为 1 的进程。PID 命名空间也意味着容器不能看到其他容器的进程树，或者其所在主机的进程树。

网络（NET）

Docker 使用 NET 命名空间为每个容器提供互相隔离的网络栈。网络栈中包括接口、ID 地址、端口地址以及路由表。例如，每个容器都有自己的 eth0 网络接口，并且有自己独立的 IP 和端口地址。

文件系统/挂载（MNT）

每个容器都有互相隔离的根目录 /。这意味着每个容器都有自己的 /etc、/var、/dev 等目录。容器内的进程不能访问 Linux 主机上的目录，或者其他容器的目录，只能访问自己容器的独立挂载命名空间。

进程内通信（IPC）

Docker 使用 IPC 命名空间在容器内提供共享内存。IPC 提供的共享内存在不同容器间也是互相独立的。

用户（USER）

Docker 允许用户使用 USER 命名空间将容器内用户映射到 Linux 主机不同的用户上。常见的例子就是将容器内的 root 用户映射到 Linux 主机的非 root 用户上。用户命名空间对于 Docker 来说还属于新生事物且非必选项。该部分内容在未来可能出现改变。

UTS

Docker 使用 UTS 命名空间为每个容器提供自己的主机名称。

ControlGroup

控制组用于限额。
容器之间是互相隔离的，但却共享 OS 资源，比如 CPU、RAM 以及硬盘 I/O。CGroup 允许用户设置限制，这样单个容器就不能占用主机全部的 CPU、RAM 或者存储 I/O 资源了。

 

相对虚拟机的优势

如果我们现在要开4个服务，用虚拟机，会是这样：

 

每个服务基于Hypervisor创建自己的虚拟机，每个虚拟机上安装自己的系统，这就造成了虚拟机的额外开销（ OS Tax 或者 VM Tax）：

虚拟机模型将底层硬件资源划分到虚拟机当中。每个虚拟机都是包含了虚拟 CPU、虚拟 RAM、虚拟磁盘等资源的一种软件结构。因此，每个虚拟机都需要有自己的操作系统来声明、初始化并管理这些虚拟资源。

而操作系统本身是有其额外开销的。例如，每个操作系统都消耗一点 CPU、一点 RAM、一点存储空间等。每个操作系统都需要独立的许可证，并且都需要打补丁升级，每个操作系统也都面临被攻击的风险。

如果我们使用的是容器，那么结构是这样：

 

容器引擎可以获取系统资源，比如进程树、文件系统以及网络栈，接着将资源分割为安全的互相隔离的资源结构，称之为容器。

每个容器看起来就像一个真实的操作系统，在其内部可以运行应用。

这样做，会带来这些优势：

• 更少的资源上运行更多的应用——没有那么多操作系统占用资源
• 启动更快——操作系统已经启动着，没有什么初始化开销
• 支付更少的授权和管理费用——只要付费一个操作系统
• 面对未知攻击的风险也更小——只要管理要一个操作系统的漏洞

 

常用命令

docker container run <container-name or container-id>

启动新容器的命令。该命令的最简形式接收镜像和命令作为参数。镜像用于创建容器，而命令则是希望容器运行的应用。

docker container run -it ubuntu /bin/bash 命令会在前台启动一个 Ubuntu 容器，并运行 Bash Shell。

docker container ls

用于列出所有在运行（UP）状态的容器。如果使用 -a 标记，还可以看到处于停止（Exited）状态的容器。

docker container exec <container-name or container-id>

用于在运行状态的容器中，启动一个新进程。该命令在将 Docker 主机 Shell 连接到一个运行中容器终端时非常有用。

docker container exec -it <container-name or container-id> bash 命令会在容器内部启动一个 Bash Shell 进程，并连接到该 Shell。

docker container stop <container-name or container-id>

此命令会停止运行中的容器，并将状态置为 Exited(0)。该命令通过发送 SIGTERM 信号给容器内 PID 为 1 的进程达到目的。如果进程没有在 10s 之内得到清理并停止运行，那么会接着发送 SIGKILL 信号来强制停止该容器。

docker container start <container-name or container-id>

重启处于停止（Exited）状态的容器。

docker container rm <container-name or container-id>

删除停止运行的容器。可以通过容器名称或者 ID 来指定要删除的容器。

docker container inspect <container-name or container-id>

显示容器的配置细节和运行时信息。

 

注意点

优雅停机

docker container stop <container-name or container-id>

命令会向容器内的 PID 1 进程发送了 SIGTERM 这样的信号。告诉进程有10秒的时间来停止。

docker container rm <container-name or container-id> -f

命令会直接发送SIGKILL，直接干掉进程。

重启策略

• always：除非容器被明确停止，比如通过 docker container stop 命令，否则该策略会一直尝试重启处于停止状态的容器。当 daemon 重启的时候，停止的容器也会被重启。

• unless-stopped：与always类似，但是daemon重启的时候，被stop命令停止的容器不会重启。
• on-failed：退出容器并且返回值不是 0 的时候，重启容器。

 

应用容器化

流程

 

• 编写应用代码
• 创建一个 Dockerfile，其中包括当前应用的描述、依赖以及该如何运行这个应用
• 对该 Dockerfile 执行 docker image build 命令
• 等待 Docker 将应用程序构建到 Docker 镜像中

例子

可以看看这个：http://c.biancheng.net/view/3159.html

 

最佳实践

利用构建缓存

Docker 的构建过程利用了缓存机制。第一次构建的内容（如镜像层）能够被缓存下来，并被后续的构建过程复用。

合并镜像

当镜像中层数太多时，合并是一个不错的优化方式。例如，当创建一个新的基础镜像，以便基于它来构建其他镜像的时候，这个基础镜像就最好被合并为一层。

缺点是，合并的镜像将无法共享镜像层。这会导致存储空间的低效利用，而且 push 和 pull 操作的镜像体积更大。命令：docker image build --squash

使用 no-install-recommends

在构建 Linux 镜像时，若使用的是 APT 包管理器，则应该在执行 apt-get install 命令时增加 no-install-recommends 参数。这能够确保 APT 仅安装核心依赖（Depends 中定义）包，而不是推荐和建议的包。这样能够显著减少不必要包的下载数量。

不要安装 MSI 包（Windows）

在构建 Windows 镜像时，尽量避免使用 MSI 包管理器。因其对空间的利用率不高，会大幅增加镜像的体积。

 

Dockerfile

上面提到的docker image build命令会读取 Dockerfile，并将应用程序容器化。默认读取当前目录下的Dockerfile。

Dockerfile 由一行行命令语句组成，并支持以 # 开头的注释行。例如：

# Test web-app to use with Pluralsight courses and Docker Deep Dive book # Linux x64 FROM alpine   LABEL maintainer="nigelpoulton@hotmail.com"   # Install Node and NPM RUN apk add --update nodejs nodejs-npm   # Copy app to /src COPY . /src   WORKDIR /src   # Install dependencies RUN  npm install   EXPOSE 8080   ENTRYPOINT ["node", "./app.js"]

docker image build命令也可以使用-f参数指定Dockerfile的路径和名称，这样就可以指定位于任意路径下的任意名称的Dockerfile。

• FROM 指令用于指定要构建的镜像的基础镜像。它通常是 Dockerfile 中的第一条指令。
• RUN 指令用于在镜像中执行命令，这会创建新的镜像层。每个 RUN 指令创建一个新的镜像层。
• COPY 指令用于将文件作为一个新的层添加到镜像中。通常使用 COPY 指令将应用代码赋值到镜像中。
• EXPOSE 指令用于记录应用所使用的网络端口。
• ENTRYPOINT 指令用于指定镜像以容器方式启动后默认运行的程序。
• 其他的 Dockerfile 指令还有 LABEL、ENV、ONBUILD、HEALTHCHECK、CMD 等。

对Dockerfile指令有兴趣的，可以看：https://www.jianshu.com/p/2a90fc6ee383

建议

• Dockerfile所在目录不应该放置与镜像无关的文件——会被构建到镜像中，镜像越小越好
• Dockerfile中使用RUN指令安装/更新软件应加上—no-cache(alpine)——减小镜像层的大小
• Dockerfile中的基础镜像尽量不要使用latest标签——lasest标签指向的镜像不保证是最新的
• Dockerfile中多个RUN命令应尽量用一条RUN指令完成——RUN命令会产生新的镜像层

 

网络

 

Docker的网络是以CNM 为设计标准，Libnetwork是CNM标准的一种实现，驱动负责的是实现数据层。

 

CNM 容器网络模型

在 CNM 中，规定了 Docker 网络架构的基础组成要素：沙盒、终端和网络

 

沙盒（Sandbox）

沙盒是一个独立的网络栈。其中包括以太网接口、端口、路由表以及 DNS 配置。

终端（Endpoint）

终端就是虚拟网络接口。就像普通网络接口一样，终端主要职责是负责创建连接。在 CNM 中，终端负责将沙盒连接到网络。

网络（Network）

网络是 802.1d 网桥（类似大家熟知的交换机）的软件实现。因此，网络就是需要交互的终端的集合，并且终端之间相互独立。

 

Libnetwork

Libnetwork 实现了 CNM 中定义的全部 3 个组件。此外它还实现了本地服务发现（Service Discovery）、基于 Ingress 的容器负载均衡，以及网络控制层和管理层功能。

服务发现

允许容器和 Swarm 服务通过名称互相定位。唯一的要求就是需要处于同一个网络当中。

其底层实现是利用了 Docker 内置的 DNS 服务器，为每个容器提供 DNS 解析功能。

每个容器启动时使用了 --name 参数的 Swarm 服务或者独立的容器，都会将自己的名称和 IP 地址注册到 Docker DNS 服务。这意味着容器和服务副本可以通过 Docker DNS 服务互相发现。

 

驱动

驱动负责实现数据层。比如，网络连通性和隔离性是由驱动来处理的。驱动通过实现特定网络拓扑的方式来拓展该模型的能力——可插拔。

 

单机桥接

重点就是单机，只有同个机器上的服务才能相互访问。具体的介绍可以看：http://c.biancheng.net/view/3189.html

Macvlan

就是让容器看起来是直接接入到宿主节点的物理网络上，让容器能与那些运行在物理网络和 VLAN 上的未容器化部分进行通信。具体的介绍可以看：http://c.biancheng.net/view/3191.html

覆盖网络overlay

 

使用 VXLAN 隧道技术创建了虚拟二层覆盖网络，让所有接入相同overlay网络的容器能够相互通信，即使容器处于不同的宿主节点。具体的介绍可以看：http://c.biancheng.net/view/3198.html

 

常用命令

docker network connect

将容器连接到网络。

docker network create

建新的 Docker 网络。默认情况下，在 Windows 上会采用 NAT 驱动，在 Linux 上会采用Bridge 驱动。可以使用 -d 参数指定驱动（网络类型）。

docker network disconnect

断开容器的网络。

docker network inspect

提供 Docker 网络的详细配置信息。

docker network ls

用于列出运行在本地 Docker 主机上的全部网络。

docker network prune

删除 Docker 主机上全部未使用的网络。

docker network rm

删除 Docker 主机上指定网络。

 

注意点

1、容器进程侦听的端口可以重复, 但对外暴露(映射)的端口不能重复。

    如果两个容器对外暴露的端口相同，当流量到达的时候，docker不知道应该把流量转发到哪个容器

2、同一个容器集群能对外暴露的端口数跟一台物理机(或虚拟机)一样。

    在Docker Swarm集群中，服务不管使用Ingress还是host模式发布，都得把自己容器内部的端口映射到宿主节点的端口。特别是Ingress模式，服务的容器映射到8888端口，整个集群的所有节点的8888端口都会被该容器占用，流量达到任意一台节点的8888端口，都会被转发到该服务的容器。

 

卷

卷用于持久化数据，容器把卷挂载到自己的某个目录，通过写数据到该目录，就能实现数据的持久存储。常用的命令如下：

docker volume create

命令用于创建新卷。默认情况下，新卷创建使用 local 驱动，但是可以通过 -d 参数来指定不同的驱动。

docker volume ls

会列出本地 Docker 主机上的全部卷。

docker volume inspect

用于查看卷的详细信息。可以使用该命令查看卷在 Docker 主机文件系统中的具体位置。

docker volume prune

会删除未被容器或者服务副本使用的全部卷。

docker volume rm

删除未被使用的指定卷。

 

Docker Compose

通过一个声明式的配置文件描述整个应用，从而使用一条命令完成部署。

应用部署成功后，还可以通过一系列简单的命令实现对其完整声明周期的管理。甚至，配置文件还可以置于版本控制系统中进行存储和管理。

这个工具一开始是其他公司写的，后面被docker收购，作为一个常用的单机docker节点的管理工具；多个节点组成集群的，需要Docker Swarm。有兴趣了解Compose的，可以看：http://c.biancheng.net/view/3172.html

 

Docker Swarm

Docker的运行模式有两种：

• 单引擎模式，不包含在任何Swarm中的Docker节点。
• Swarm模式，加入了Swarm集群的Docker节点。

Swarm的架构图如下：

 

节点类型

管理节点（Manager）

管理节点负责集群控制面（Control Plane），进行诸如监控集群状态、分发任务至工作节点等操作。

管理节点的高可用（HA）

 

通常处于活动状态的管理节点被称为“主节点”（leader），而主节点也是唯一一个会对 Swarm 发送控制命令的节点。也就是说，只有主节点才会变更配置，或发送任务到工作节点。如果一个备用（非活动）管理节点接收到了 Swarm 命令，则它会将其转发给主节点。

这样的模式，也就组成了swarm集群管理节点HA 的支持。当主节点发生故障，剩余管理节点会进行选举，产生新的主节点，新的主节点会继续保证 Swarm 的运转。

最佳实践原则

• 部署奇数个管理节点：防止脑裂。

• 不要部署太多管理节点（建议 3 个或 5 个）：更多的参与节点就意味着需要花费更多的时间来达成共识。

 

工作节点（Worker）

工作节点接收来自管理节点的任务并执行。

 

service 服务

使用服务仍能够配置大多数熟悉的容器属性，比如容器名、端口映射、接入网络和镜像。此外还增加了额外的特性，比如可以声明应用服务的期望状态，将其告知 Docker 后，Docker 会负责进行服务的部署和管理。

服务发布模式

 

• Ingress模式（默认），从 Swarm 集群内任一节点（即使没有运行服务的副本）都能访问该服务。即映射端口的时候，所有节点都会开放published指定的端口。

• Host模式，只能通过运行服务副本的节点来访问。

服务的相关操作，可以看：http://c.biancheng.net/view/3180.html

 

Ingress模式

在底层，Ingress 模式采用名为 Service Mesh 或者 Swarm Mode Service Mesh 的四层路由网络来实现。下图展示了 Ingress 模式下一个外部请求是如何流转，最终访问到服务的。

 

想要了解多一些的，可以看：http://c.biancheng.net/view/3195.html

 

健康检查

服务可以指定健康检查的策略，健康检查不通过的时候，重启服务，在docker service create/update可以指定如下参数：

• --health-cmd=命令，用于检查接口的命令。
• --health-interval=时间间隔 (默认: 30s)，它是每次执行healthcheck的时间间隔。
• --health-timeout=时间间隔 (默认: 30s)，如果在超时时间之内没有响应，则代表异常。
• --health-retries=N (默认: 3)，连续达到多少次异常之后退出。
• --health-start-period=时间间隔 (默认：0)，容器启动之后多久进行健康检查（服务启动预热），即运行health-cmd。

 

滚动升级

滚动升级能让服务的部署变得更为平滑，在docker service create/update可以指定如下参数：

--update-delay

定义滚动更新的时间间隔，单位 s、m、h，1小时20分30秒即 1h20m30s，默认0

--update-parallelism

定义并行更新的副本数量，默认是1

--update-monitor

定义服务的一个实例更新多久才认为超时失败，单位与--update-delay相同，默认0

--update-max-failure-ratio

定义服务多少比例的容器升级失败才认为服务更新失败，从而触发update-failure-action指定的动作，通过这个参数的指定，能够保证更好的控制服务的灰度发布。

--update-failure-action

默认情况下，当对单个任务的更新返回 RUNNING 状态时，调度程序开始更新另一个任务，直到所有任务都更新。如果在更新期间任务返回 FAILED 状态，则调度程序会暂停更新。该参数定义容器启动失败之后所执行的动作：continue—继续、pause—暂停，rollback—回滚

--update-order

更新的顺序：start-first—先起新服务，stop-first—先停旧服务，默认值是stop-first

 

例子：

docker service create --name masl -e TZ="Asia/Shanghai" --network mrp_net --replicas 8 -p 8081:8080 \
--update-delay 10s \　　　　　　　　　　　　#每次更新间隔10s
--update-parallelism 2 \　　　　　　　　　　#每次允许两个服务一起更新
--update-failure-action continue \　　　　#更新失败后的动作是继续

 

滚动升级能做到无缝切换，对外服务部完全不中断么？

dubbo能，http不能，其他任务看shutdown hook。

滚动升级，要停止旧容器的时候，会给容器发送SIGTERM信号，让容器做清理动作，准备停机。

dubbo服务在接收到信号的时候，可以把自己从注册中心移除，让消费者告知到它下线，不会有新的请求到达该服务；接着休眠一定的时间，等待现有的请求处理完成即可。

http之所以不行，是因为docker swam是等到容器完全退出才会从dns从把该容器对应的id移除，在停机过程中会有新服务被分配到该服务——k8s就没这问题，给容器发SIGTERM信号的时候就移除了。

其他任务，例如工作线程池，就要靠java的shutdown hook做好清理动作，等待现有的工作处理完成。

 

常用命令

docker swarm init

用于创建一个新的 Swarm。执行该命令的节点会成为第一个管理节点，并且会切换到 Swarm 模式。

docker swarm join-token

用于查询加入管理节点和工作节点到现有 Swarm 时所使用的命令和 Token。要获取新增管理节点的命令，请执行 docker swarm join-token manager 命令；要获取新增工作节点的命令，请执行 docker swarm join-token worker 命令。

docker node ls

用于列出 Swarm 中的所有节点及相关信息，包括哪些是管理节点、哪个是主管理节点。

docker service create

用于创建一个新服务。

docker service ls

用于列出 Swarm 中运行的服务，以及诸如服务状态、服务副本等基本信息。

docker service ps <service>

该命令会给出更多关于某个服务副本的信息。

docker service inspect

用于获取关于服务的详尽信息。附加 --pretty 参数可限制仅显示重要信息。

docker service scale

用于对服务副本个数进行增减。

docker service update

用于对运行中的服务的属性进行变更。

docker service logs

用于查看服务的日志。

docker service rm

用于从 Swarm 中删除某服务。该命令会在不做确认的情况下删除服务的所有副本，所以使用时应保持警惕。

 

Docker Stack

简介

Docker Compose可以用来管理单引擎模式下的Docker节点。Docker Stack相当于Compose的集群版，是基于 Docker Swarm 之上来完成应用的部署。

能够在单个声明文件中定义复杂的多服务应用。还提供了简单的方式来部署应用并管理其完整的生命周期：初始化部署 -> 健康检查 -> 扩容 -> 更新 -> 回滚，以及其他功能！

 

相关的配置内容，有兴趣的可以看：http://c.biancheng.net/view/3211.html

 

常用命令

docker stack deploy

用于根据 Stack 文件（通常是 docker-stack.yml）部署和更新 Stack 服务的命令。

docker stack ls

会列出 Swarm 集群中的全部 Stack，包括每个 Stack 拥有多少服务。

docker stack ps

列出某个已经部署的 Stack 相关详情。该命令支持 Stack 名称作为其主要参数，列举了服务副本在节点的分布情况，以及期望状态和当前状态。

docker stack rm

命令用于从 Swarm 集群中移除 Stack。移除操作执行前并不会进行二次确认。