标签：docker

当你运行Docker Engines swarm，管理节点是管理swarm和存储swarm状态的关键组件。为了正确地部署和维护swarm，理解管理节点一些关键的功能很重要。

swarm的管理节点

swarm管理节点使用Raft一致性算法来管理swarm的状态。你只需要理解Raft的一些常见概念以便来更好的管理swarm。
对管理节点的数量没有限制。关于要实现多少个管理器节点的决定是性能和容错之间的折衷。增加更多管理节点到swarm使得swarm有更好的容灾能力。不过额外的管理节点会降低写入性能，因为更多的节点必须确认更新swarm状态的提议。意味着产生更多的流量，花更多的时间。
Raft要求大多数管理者（也称为法定人数）同意对swarm的建议更新。 法定人数的管理人员还必须同意节点添加和删除。 成员资格操作受到与状态复制相同的约束。

使用一个advertise静态IP地址

当启动一个swarm时，你必须指定–advertise-addr一个IP地址来通告swarm中的其它管理节点。因为管理节点是一个相对稳定的组件，你应该使用一个固定的IP地址来避免机器重启时IP变更其它管理节点无法连接。
如果整个swarm重启，随便每个管理节点都获取到一个新的IP地址，那么任何的节点都没有办法连接到一个已存在的管理节点。worker节点就可以使用动态IP地址。

添加管理节点来容错

你应该维护奇数个swarm管理节点以支持管理节点故障而不影响swarm运行。奇数的管理节点数量确保了在网络故障分裂为两部分时，有很大可能管理节点的数量仍然为法定数量（即数量超过一半）来选举出新的leader节点。如果遇到网络分裂超过三部分，那就不能保证有法定数量的管理节点了。
例如，在一个有5个管理节点的swarm中，如果你失去了3个节点，余下的2个节点没有超过一半，达不到法定数量，无法选举出新的leader节点。因此在你恢复不可用的管理节点或使用灾难恢复命令恢复swarm前，你不能添加或删除节点。
虽然可以将一个swarm缩放为单个管理器节点，但不可能降级最后一个管理器节点。这可以确保你能访问swarm，并且swarm仍然能处理请求。缩放为单个管理节点是一个不安全的操作且不建议。如果你最后一个节点在降级操作期间突然变得不可用，在你重启节点或使用–force-new-cluster重启前，swarm将变得不可用。

分布管理节点到多个区域

除了维护奇数个管理节点，在部署管理节点时注意数据中心拓扑。为了实现最佳容错性，将管理节点分布在至少3个可用性区域中，以支持整个机房或常见维护情况的故障。如果任意一个区域发生故障，swarm管理节点的数量仍然会超过一半来选举出leader节点。
下面的图表说明在三个可用区域中部署管理节点的数量。

运行仅负责管理的节点

默认下管理节点也作为worker节点。意味着调度器可以分配任务给管理节点。对于小的和非关键的swarm，只要你使用cpu和内存的资源约束来调度服务，则向管理节点分配任务的风险相对较低。
然而因为管理节点使用Raft一致性算法以一致的方式复制数据，它们对资源匮乏较敏感。你应该设置管理节点不接受任务以避免影响swarm心跳或leader选举。
为了避免影响管理节点的相关管理操作，你可以设置管理节点为drain状态不再继续作为worker节点。

当你drain一个节点，调度器会重新分配这个节点上运行的任务到其它可用节点。也会阻止调度器分配新的任务到这个节点。

备份swarm状态

Docker管理节点存储swarm状态和日志在以下目录：

经常的备份raft数据目录以便你能灾难恢复swarm。

监控swarm状态

你可以通过/nodes HTTP endpoint以JSON格式查询docker nodes API来监视管理节点的运行状况。
也可以在命令行执行docker node inspect 来查询节点。
例如，查询管理节点的reachability：

查询worker节点的接受任务的状态：

从这些命令的输出来看，我们可以知道manager1作为管理节点时状态为reachable，作为worker节点时为ready。
unreachable状态意味着从其它管理节点无法访问这个管理节点。这种情况你需要马上恢复这个不可用的管理节点：

重启docker进程来看管理节点是否会恢复为reachable

重启机器

如果以上都没有用，你应该添加一个管理节点或升级一个worker节点为管理节点。你也需要使用docker node demote 和docker node rm 来清除失效的管理节点。

或者你可以在管理节点上执行docker node ls来查看所有节点的运行情况：

强制删除一个节点

在大多数情况下在你要使用docker node rm命令来删除一个节点时应该先关闭这个节点。如果某个节点变得不可达，无响应或受损，你可以通过传递–force标志强制删除该节点，而不关闭它。例如如果node9受损：

在你强制删除一个管理节点之前，你必须先降级它为worker节点。如果你降级或删除一个管理节点，必须始终确保管理节点数量为奇数。

灾难恢复

Swarm对故障适应能力强，并且可以从任何数量的临时节点故障（机器重新启动或与崩溃时重新启动）恢复。
在N个管理节点的swarm中，为了使swarm处理请求并保持可用，必须有大于管理节点总数的50％（或（N / 2）+1）的管理节点的法定数量。 这意味着swarm可以容忍多达（N-1）/ 2个永久故障，超过这些永久故障，无法处理涉及swarm管理的请求。 这些类型的故障包括数据损坏或硬件故障。
即使你遵循此处的指南，也可能会丢失一个仲裁节点。 如果无法通过常规方法（如重新启动故障节点）恢复仲裁，则可以通过在管理节点上运行docker swarm init –force-new-cluster来恢复该swarm。

–force-new-cluster参数设置为单管理节点的swarm。 它丢弃失去法定数量的管理节点之前存在的成员信息，但它保留Swarm所需的数据，例如服务，任务和worker节点的列表。

强制重新平衡swarm

一般情况下，你不需要强制平衡swarm的任务。当你添加一个新节点到swarm或者节点不可用一段时间后重新连接，swarm不会自动重新将运行在其它节点的任务分配到这个空闲节点。swarm是这样设计的。如果为了平衡，swarm周期性的迁移任务到不同的节点，使用这些任务的用户会被中断。如果启动一个新任务或者一个运行的节点变为不可用，它们的任务会分配到不太繁忙的节点。目标是保证对用户影响最小来达到重新平衡。
如果你不在意中断运行的服务来强制平衡swarm任务，你可以临时的增大服务的规模。
使用docker service inspect –pretty 来查看服务的规模。使用docker service scale时，调度器会把任务优先分配到最低任务数的节点。 你的swarm中可能有多个负载不足的节点。 你可能需要多次增大服务的规模，以实现所有节点上所需的平衡。
如果平衡满足你的要求，你可以恢复服务到原来的规模数。可以使用docker service ps命令来评估跨节点的服务的当前平衡。

Docker Engine的swarm模式原生支持覆盖网络(overlay networks)，所以你可以启用容器到容器的网络。swarm模式的覆盖网络包括以下功能：

你可以附加多个服务到同一个网络

默认情况下，service discovery为每个swarm服务分配一个虚拟IP地址(vip)和DNS名称，使得在同一个网络中容器之间可以使用服务名称为互相连接。

你可以配置使用DNS轮循而不使用VIP

为了可以使用swarm的覆盖网络，在启用swarm模式之间你需要在swarm节点之间开放以下端口：

TCP/UDP端口7946 – 用于容器网络发现

UDP端口4789 – 用于容器覆盖网络

在swarm中创建一个覆盖网络

当你运行Docker Engine的swarm模式时，你可以在管理节点执行docker network create命令来创建一个覆盖网络。例如，创建一个名为my-network的网络：

默认情况下swarm中的节点通信是加密的。在不同节点的容器之间，可选的–opt encrypted参数能在它们的vxlan流量启用附加的加密层。
–subnet参数指定覆盖网络的子网。当你不指定一个子网时，swarm管理器自动选择一个子网并分配给网络。在一些旧的内核，包括kernel 3.10，自动分配的地址可能会与其它子网重叠。这样的重叠可能引起连接问题。
执行docker network ls来查看网络：

swarm scope表示部署到swarm的服务可以使用这个网络。当你创建一个服务并附加到一个网络后，swarm仅仅扩展该网络到服务运行的节点上。在一个没有运行有附加到网络的服务worker节点上，network ls命令不会显示有任何网络。

附加服务到覆盖网络

要附加一个服务到一个覆盖网络，在创建服务的时候传递–network参数。例如创建一个nginx服务并附加到一个名为my-network的网络：

注意：在附加服务到网络前，必须先创建这个网络。

在同一个覆盖网络的容器之间能互相连接。在管理节点执行docker service ps 来查看哪些节点运行着这个服务：

pic1
你可以在运行着附加有网络的服务的节点上查看这个网络的详情：

这个网络信息包括了该节点上附加到该网络的容器的列表。例如：

在上面的示例中，my-web服务的容器my-web.1.63s86gf6a0ms34mvboniev7bs附加到该节点的my-network网络。

使用swarm模式的service discovery

默认情况下，当你创建一个服务并附加到一个网络时，swarm就给服务分配一个VIP。VIP根据服务名称映射到DNS别名。在该网络的容器之间通过gossip来共享DNS映射信息，所以在该网络的容器能通过服务名称来访问彼此。
你不需要公开特定于服务的端口，以使服务可用于同一覆盖网络上的其他服务。 swarm的内部负载均衡会自动将请求分发到服务VIP。
你可以使用如下命令来查看服务的VIP:

下面的示例展示如何添加一个busybox服务到与nginx服务相同的网络，以及busybox服务使用DNS名称my-web访问nginx服务：
1.在管理节点，部署busybox服务到与my-web同一个网络：

2.查看哪个节点运行着my-busybox服务：

3.登录上一步查询到的node1节点，在busybox容器中打开一个可交互的shell:

你可以将容器名称推断为 + 。 或者，你可以在运行任务的节点上运行docker ps。
4.在busybox容器内部，查询my-web服务的VIP:

5.在busybox容器内部，查询的DNS记录来找出my-web服务的所有容器IP地址：

6.在busybox容器内，执行wget来访问my-web服务的nginx web server:

通过访问服务的VIP，swarm负载均衡自动将HTTP请求路由可用的容器中。 它使用轮循的方式来平均地分发请求。

使用DNS轮循请求

你可以配置服务直接使用DNS轮循而不用VIP，在创建服务的时候设置–endpoint-mode dnsrr。在你要使用你自己的负载均衡器时可能会用此方法。
下面的示例展示一个服务使用dnsrr endpoint模式：

当你查询服务名称的DNS记录时，DNS服务会返回所有该服务容器的IP地址：

创建服务

简单地在swarm中创建一个服务，你仅需要提供一个镜像名称：

这时协调器开始调度任务给一个可用节点。任务基于你给的镜像来运行一个容器。例如，你可以执行如下命令来创建一个nginx web服务器的实例服务：

在这个示例中–name参数命名服务为my_web。
在管理节点上执行docker service ls来列出服务：

要让web服务器在swarm外部可用，你需要发布一个swarm监听web请求的端口。
你可以在指定镜像后添加一个命令来运行在容器内部：

例如启动一个alpine镜像来执行ping docker.com:

配置运行环境

你可以使用如下选项来配置容器的运行环境：

使用–env参数配置环境变量

使用–workdir参数配置容器工作目录

使用–user参数配置程序运行使用的用户或ID

例如：

控制服务规模和布局

swarm模式有两种类型的服务，副本(replicated)和全局(global)。对于副本服务，你可以指定任务副本的数量。对于全局服务，调度器将在每个可用节点都执行一个相同的任务。
你可以使用–mode参数来设置服务类型。如果不指定，默认服务类型为副本。对于副本服务，你可以使用–replicas参数为设置副本数量。例如，启动一个副本数为3的nginx服务：

要启动一个全局服务，在创建服务执行docker service create时传递–mode global参数。当任何时候一个新的节点可用，调度器会调度全局服务的任务到该新节点。例如在每个节点上执行alpine服务：

控制服务规模和布局

swarm模式中有两种可以访问服务的方法：

使用ingress网络来发布端口到swarm外部

在swarm的覆盖网络内部连接服务和任务

发布端口到swarm外部网络

你可以使用–publish:参数来发布服务端口到swarm外部网络。发布服务端口时，无论该节点上是否有任务运行，swarm都会使服务在每个节点的目标端口上可访问。
例如，假设你想部署一个3个副本的nginx服务到一个10个节点的swarm:

调度器会把nginx任务分配到三个可用节点。不过swarm会设置10个节点都监听8080端口，访问此端口时会把请求转发到nginx容器的80端口。你可以使用curl在任意的节点上测试服务：

添加一个覆盖网络

使用覆盖网络可以在swarm内连接一个或多个服务。
首先在管理节点执行docker network create来创建一个覆盖网络：

当你在swarm模式创建一个覆盖网络后，所有的管理节点都可以访问这个网络。
可以在创建服务时传递–network参数过去指定服务加入的覆盖网络：

配置更新策略

你可以在创建服务或更新服务时指定swarm应用服务更新的策略。
–update-delay标志配置更新到服务任务或任务集之间的时间延迟。 你可以将时间T描述为秒数Ts，分钟Tm或小时Th的组合。 所以10m30s表示10分30秒的延迟。
默认情况下，调度器一次更新1个任务。 你可以传递–update-parallelism标志来配置调度器同时更新的最大服务任务数。
当对单个任务的更新返回RUNNING状态时，调度器通过继续执行另一个任务，直到所有任务都更新为止，继续更新。 如果在更新期间的任何时间任务返回FAILED，则调度器暂停更新。 你可以使用–update-failure-action标志控制docker服务创建或docker服务更新的行为。
在下面的示例服务中，调度器一次最多应用更新2个副本。 当更新的任务返回RUNNING或FAILED时，调度程序在停止下一个要更新的任务之前等待10秒钟：

配置挂载

你可以创建两种类型的swarm服务挂载，volume挂载或bind挂载。在创建服务时传递–mount参数指定挂载类型。默认挂载类型是volume。

Volumes存储在容器任务被删除时仍然会保留。
挂载volumes首先方法是利用已存在的volumes:

1. $ docker service create
2.   –mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH>
3.   –name myservice
4.   <IMAGE>

下面的方法是在部署服务时创建一个volume:

1. $ docker service create
2.   –mount type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=<DRIVER>,volume-opt=<KEY0>=<VALUE0>,volume-opt=<KEY1>=<VALUE1>
3.   –name myservice
4.   <IMAGE>

Bind挂载是把容器中的目录挂载到运行容器所在的主机上的目录。在swarm初始化任务容器时，主机文件系统路径必须存在。
下面的示例显示bind挂载的语法：

1. # Mount a read-write bind
2. $ docker service create
3.   –mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>
4.   –name myservice
5.   <IMAGE>
6.  
7. # Mount a read-only bind
8. $ docker service create
9.   –mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>,readonly
10.   –name myservice
11.   <IMAGE>

在swarm的生命周期中，你可能需要查看或更新节点，如：

列出swarm中的节点

查看单个节点详信息

更新节点

脱离swarm

列出节点

在管理节点在执行docker node ls来列出swarm中的节点：

AVAILABILITY显示出调度器是否能分配任务给这个节点：

Active意味着调度器可以分配任务给节点

Pause意味着调度器不能分配任务给节点，不过已存在的任务仍然继续运行

Drain意味着调度器不能分配任务给节点。调度器关闭已存在的任务并调度它们到其它可用节点

MANAGER STATUS列显示节点是否参与到Raft一致性：

没有值表示worker节点不参与到swarm管理

Leader表示该节点是主要管理节点，负责全部的swarm管理工作和编排决策。

Reachable表示该节点是一个管理节点并参与到Raft一致性。如果leader节点变为不可用，该节点有资格被选为新的leader。

Unavailable表示该节点是一个管理节点，不过目前不能与其它管理节点通信。如果一个管理节点变为不可用，你应该加入一个新的管理节点或者提升一个worker节点为管理节点。

查看单个节点详细信息

你可以在管理节点上执行docker node inspect 来查看单个节点的详细信息。默认输出来json格式，你可以传递–pretty参数来输出较易读的格式，如：

更新节点

更新节点状态

更新节点的状态可以：

drain一个管理节点，可以使该节点只完成swarm管理任务，而不接收来自调度器的任务并停止已存在的任务

drain一个节点，你可以下线该节点来进行维护工作

pause一个节点，使它不再接收新任务

restore一个不可用或暂停的节点为可用状态

例如，设置一个管理节点为Drain：

添加或删除标签元数据

节点标签提供了一种灵活的节点组织方法。 你还可以在服务约束中使用节点标签。 在创建服务时应用约束，以限制调度器为服务分配任务的节点。
在管理节点上运行docker node update –label-add以将标签元数据添加到节点。 –label-add标志支持或 = 对。
每添加一个节点标签需要传递一次label-add参数：

升级或降级节点

你可以升级一个worker节点为管理节点。这个在管理节点变为不可用或者你想下线管理节点来维护会比较有帮助。当然，你也可以降级一个管理节点为worker节点。
不管你降级和升级节点是出于什么原因，你应该始终确保swarm中管理节点数量为奇数。
在管理节点执行docker node promote来升级一组worker节点：

在管理节点执行docker node demote来降级一组节点：

docker node promote和docker node demote分别是docker node update –role manager和docker node update –role worker命令等效。

脱离节点

要从swarm删除一个节点，首先要执行docker swarm leave命令。
例如从swarm脱离一个worker节点：

当一个节点脱离swarm时，Docker Engine不再以swarm模式运行。orchestrator不再调度任务给该节点。
当节点脱离swarm之后，你可以在管理节点执行docker node rm命令来从节点列表中删除该节点。
例如：

当你首次创建一个swarm时，你就放置了一个Docker Engine到swarm中。为了充分利用swarm模式的优势，你可以添加节点到swarm:

添加worker节点来增加集群容量。当你部署一个服务到swarm，Engine调度任务到可用的节点中(不管是worker节点或者是manager节点)。当你添加一个worker节点到swarm中，你增加了swarm的规模来处理更多的任务而不会影响到管理器raft的一致性

多个manager节点可以增强集群容错能力。manager节点执行swarm的编排和集群管理功能。在manager节点中，单个leader节点执行编排任务。当leader节点出现故障，余下的manager节点选出一个新的leader节点并恢复编排和维护swarm状态。默认情下，manager节点也执行任务。

在添加节点到swarm之前你必须安装Docker Engine 1.12或之后的版本。

添加worker节点

要获取添加worker到swarm的命令，在manager节点上执行：

在要添加到swarm的worker节点上执行如下命令来加入到swarm:

docker swarm join做了如下工作：

切换当前节点的Docker Engine为swarm模式

从manager节点请求一个TLS证书

以机器主机名命名节点

基于swarm token和manager节点监听的地址来添加当前节点到swarm

设置当前节点为Active状态，意味着它可以接收从调度器分配的任务

将ingress覆盖网络扩展到当前节点

添加manager节点

当你执行docker swarm join并传递manager token，跟worker节点一样Docker Engine切换到swarm模式。新添加的manager节点也参与到raft一致性当中。新的节点应该是可访问的，但之前的leader节点仍然不变。
Docker推荐3个或5个manager节点的集群来实现高可用。因为swarm模式的manager节点使用Raft共享数据，必须是奇数的manager节点数。只要超过一半的manager节点可用，swarm就可以继续工作。
要获取添加manager到swarm的加入命令，执行：

在要添加到swarm的manager节点上执行：

当你首次安装并开始使用Docker Engine，默认情况下swarm模式是关闭的。当你激活swarm模式，你开始可以使用docker service命令来管理服务。
有两种方法来激活swarm模式：

创建一个新的swarm，本文将介绍

加入一个已存在的swarm

当你在你本地机器运行docker engine的swarm模式，你可以基于你之前创建的镜像或其它可用镜像来创建和测试服务。在生产环境中，swarm模式提供了集群管理的容错功能来保持你服务一直可用。
本文假设你已经在你机器安装了Docker Engine 1.12或更高版本。

创建一个swarm

当你运行创建swarm的命令，Docker Engine就开始以swarm模式运行了。
执行docker swarm init命令在当前节点创建一个单节点的swarm。Docker Engine设置swarm的步骤为：

切换当前节点进入swarm模式

创建一个名为default的swarm

将当前节点指定为该swarm的leader管理器节点。

以机器主机名命名节点

配置管理节点监听端口2377

设置当前节点为Active状态，意味着当前节点可以接收来自调度器的任务

创建一个内部的分布式数据存储来维护swarm的一致状态

默认下为swarm生成一个自签名根CA证书

默认下生成一个token用来worker和manager节点加入swarm

创建一个名为ingress的覆盖网络用来发布服务端口，以连接swarm外部网络

docker swarm init命令的输出提供了worker节点加入swarm的命令：

配置advertise地址

管理节点使用一个advertise地址来允许swarm中的其它节点进入Swarmkit API和覆盖网络。其它节点必须能够通过advertise地址连接管理节点。
如果你没有指定一个advertise地址，Docker会检查系统是否只有一个IP地址，如果是，Docker就使用这个IP地址监听2377端口。如果系统有多个IP地址，你就必须指定一个正确的–advertise-addr来启用内部管理间通信和覆盖网络。

注意有时候其它节点连接管理节点的地址不绑定在管理节点本身系统上，即使用ifconfig看不到能用于连接管理节点的地址时，也需要手动指定正确的advertise地址。例如在云服务器中有多个不同的区域，主机有用于内部通过的内部地址和用于外部通过的外部地址。在这种情况下，需要指定其它节点能连接管理节点的地址。

查看join命令或更新swarm join token

节点需要一个秘密token来加入swarm。worker节点用来加入swarm的token与manager节点的token不一样。节点只在加入swarm的时候使用token。当在一个节点加入swarm后更新token不会影响节点的swarm成员资格。更改token只是为了确保其它新的节点不能使用旧的token来尝试加入swarm。
要获取用于worker节点加入swarm的token，执行：

要获取用于manager节点加入swarm的token，执行：

传递–quiet参数只打印token:

我们建议在以下情况来更新token:

如果token不小心进入到了版本管理系统，群组聊天或打印到了日志文件中

如果你怀疑节点已被入侵

如果你想确保没有新的节点可以加入swarm

除此之外，我们建议你定时的更新token。建议至少6个月更新一个token。
运行swarm join-token –rotate以使旧token无效并生成新token。 指定更新的是worker节点token还是manager节点：

要在Docker Engine swarm模式中部署一个应用程序镜像，你需要创建一个服务。通常时候，一个服务对于一些规模比较大的应用程序的一个微服务镜像。例如服务比较包含一个HTTP服务器，一个数据库或者你想运行在分布式环境的可执行程序。
当你创建一个服务，你可以指定使用哪个容器镜像和在容器中运行的命令。你也可以定义服务的选项，包括：

可在swarm外部访问服务的端口

在swarm中服务之间可以互相通信的覆盖网络

CPU和内存限制和预留

滚动更新策略

运行在swarm的镜像副本的数量

服务，任务和容器

当你部署服务到swarm，swarm管理器接收你对服务期望状态的定义。然后它为你服务在swarm中的节点调度一个或多个副本任务。这些任务在swarm的节点上彼此独立地运行。
例如假设你想负载均衡三个HTTP服务器实例。下面的图表展示了三个HTTP服务器副本。三个HTTP实例中的每一个是swarm中的一个任务。

一个容器是孤立的进程。在swarm模式模型中，每个任务调用一个容器。任务包含着容器。一旦容器运行正常，调度器就会把相此容器相关联的任务识别为在线状态。否则容器停止或有异常，则任务显示为终止。

任务和调度

任务是swarm内调度的原子单位。当你通过创建或更新服务声明一个期望状态的服务，调度器通过调度任务来实现期望的状态。例如，你指定一个服务始终保持运行三个HTTP实例。调度器就创建三个任务。每个任务运行一个容器。容器是任务的实例化。如果一个HTTP容器之后出现故障停止，此任务被标志为失败，调度器就会创建一个新的任务来生成一个新容器。
任务是一个单向机制。它单向地执行一系统状态，assigned, prepared, running等。如果一个任务失败了，调度器就会删除这个任务和它的容器，然后创建一个新的任务来替换它。
下面的图表显示swarm模式是如何接收服务创建请求和调度任务到worker节点的。

副本和全局服务

有两种类型的服务部署，副本和全局。
对于副本服务，你可以指定运行相同任务的数量。例如，你决定部署三个HTTP实例的副本，每个提供相同的内容。
一个全局服务是在每个节点上运行一个相同的任务。不需要预先指定任务的数量。每次你增加一个节点到swarm中，协调器就会创建一个任务，然后调度器把任务分配给新节点。比如你希望在每个节点上运行监控代理，病毒扫描器等。
下面的图表显示以黄色标注的三个副本的服务和灰色标注的一个全局服务。

从Docker Engine 1.12版本起开始引进swarm模式来创建一个或多个Docker Engines的集群，称为swarm。一个swarm包含一个或多个节点：运行在Docker Engine1.12或更高版本的swarm模式下的物理的或虚拟的机器。
有两种类型的节点：managers和workers。

Manager节点

manager节点处理集群管理任务：

维护集群状态

调度服务

提高swarm模式的HTTP API服务

swarm管理器使用Raft来实现维护整个swarm集群一致的内部状态。如果是测试的目的可以只运行一个swarm管理节点。如果单管理器的swarm出问题下线了，服务仍然会运行，不过你需要创建一个新的集群来恢复它。
要利用swarm模式的容错功能，Docker建议根据你对高可用的要求来创建奇数的管理节点。当你有多个管理节点时，可以不用停机从故障的管理节点中恢复。

三个管理节点的swarm最大允许一个管理节点宕机

五个管理节点的swarm最大允许两个管理节点宕机

N个管理节点的swarm最大允许(N-1)/2个管理节点宕机

Docker推荐最多创建7个管理节点

Worker节点

Worker节点是Docker Engine的实例，其唯一目的是运行容器。Worker节点不参与Raft分布状态，作调度的决定或提供swam模式的HTTP API服务。
你可以创建单个管理节点的swarm，不过你不能只有一个Worker节点而没有管理节点。默认情况下，所有的管理节点也是Worker节点。在单管理节点的集群中，你可以运行命令如docker service create，然后调度器会把所有的任务放到本地执行。
如果你想阻止调度器把任务分配到多个节点的集群的管理节点上，你可以设置管理节点的状态为Drain。调度器就不会继续把任务分发这些节点上执行。

改变角色

你可以通过执行docker node promote来把一个worker节点提升为管理节点。例如，你当你的管理节点下线时你可能会想把worker节点提升为管理节点。

Docker Engine的swarm模式使得服务发布端口让服务在swarm外部可用变得容易。所以的节点都参与到routing mesh中，意味着任何的节点（即使该节点没有服务在运行）都可以作为入口，都能路由请求。
为了能在swarm中使用ingress网络，你需要在节点之间开放如下端口：

TCP/UDP端口7946 – 用来发现容器网络

UDP端口4789 – 容器ingress网络

当然你也必须在swarm节点之间和做任意外部资源（如外部负载均衡）之间开放published端口。

发布服务端口

在创建服务时使用–publish参数来发布一个端口：

是容器内监听的端口。是对外发布的端口，外部通过此端口能访问到容器内的应用程序。
例如，以下的命令是发布nginx容器内的80端口到swarm所有节点的8080端口：

当你访问任意节点的8080端口，swarm的负载均衡会把你的请求路由到一个任意节点的可用的容器上。routing mesh在swarm节点的所有IP上监听published端口。

你可以使用以下命令来为已存在的服务发布一个端口：

使用docker service inspect来查看服务的published端口。如：

发布一个TCP端口或UDP端口

默认情况下，以上发布的端口都是TCP端口。你可以指定发布一个UDP端口。当你TCP和UDP两个端口都发布时，Docker 1.12.2及更早版本要求你为TCP端口添加/tcp后缀。

只发布TCP端口

下面的两个命令是一样的。

发布TCP和UDP端口

只发布UDP端口

配置一个外部负载均衡

你可以配置一个外部负载均衡来路由请求到swarm服务。例如，你可以配置HAProxy来路由请求到一个published端口为8080的nginx服务。

在这个示例中，在负载均衡和所有swarm节点之间需要开放8080端口。
你可以配置负载均衡负载请求到swarm的任何节点。例如HAProxy的配置文件/etc/haproxy/haproxy.cfg:

当你访问HAProxy负载均衡的80端口时，它会把你的请求转发到swarm节点。然后swarm节点的routing mesh把请求路由到一个可用的服务上。

在之前的章节，所以的节点状态都为ACTIVE了。swarm管理器能分配任务到任何ACTIVE的节点，所以目前为止所有的节点都可以接收任务。
不过有时候如维护期间，你需要设置一个节点为DRAIN状态，也就是下线节点。DRAIN状态的节点不再接受来自swarm管理器发来的新任务。也意味着管理器停止DRAIN状态节点的任务然后再在ACTIVE节点上新起一个副本任务来替代之前的任务。
1.登录manager1机器。
2.查看目前所有的节点都为Active状态。

3.如果你没有运行之前滚动更新的步骤，那么先执行如下命令创建redis服务：

4.执行docker service ps redis查看swarm管理器把任务分配到了哪些节点：

在这个示例中，swarm管理器为每个节点分配一个任务。
5.执行docker node update –availability drain 来下线一个节点：

6.查看这个节点的状态：

下线的节点显示Drain状态。
7.执行docker service ps redis来查看swarm管理器是如何重新分配redis任务到其它可用节点的：

swarm管理器停止已下线节点的redis任务并在其它Active节点创建一个新任务来维持设定redis副本数。
8.执行docker node update –availability active 来上线已下线的节点：

9.查看上一步更新节点的状态：

当设置节点重新为Active状态时，在以下几种情况会重新接收新任务：

在增大服务规模期间

在滚动更新期间

当设置另一个节点为Drain状态时

当一个任务在另一个Active节点失败时