服务的工作原理
当 Docker Engine 处于 Swarm 模式时，要部署一个应用程序镜像，你需要创建一个服务 (service)。通常情况下，服务是某个大型应用程序上下文中的微服务镜像。服务的示例可能包括 HTTP 服务器、数据库，或者你希望在分布式环境中运行的任何其他类型的可执行程序。
创建服务时，你需要指定要使用的容器镜像以及在运行的容器内执行的命令。你还需要定义服务的选项，包括：
- Swarm 将服务暴露给 Swarm 外部的端口
- 用于服务连接到 Swarm 中其他服务的覆盖网络 (overlay network)
- CPU 和内存的限制及预留
- 滚动更新策略
- 在 Swarm 中运行的镜像副本数量
服务、任务和容器
当你将服务部署到 Swarm 时，Swarm 管理器接受你的服务定义作为服务的期望状态 (desired state)。然后，它将服务作为一个或多个副本任务 (replica tasks) 调度到 Swarm 中的节点上。这些任务在 Swarm 的节点上彼此独立运行。
例如，假设你希望在 HTTP 监听器的三个实例之间进行负载均衡。下图显示了一个包含三个副本的 HTTP 监听器服务。监听器的三个实例中的每一个都是 Swarm 中的一个任务。
容器是一个隔离的进程。在 Swarm 模式模型中，每个任务恰好调用一个容器。任务类似于调度器放置容器的“插槽”。一旦容器处于活动状态，调度器就会识别出任务处于运行状态。如果容器未通过健康检查或终止，任务也会终止。
任务和调度
任务是 Swarm 内部调度的原子单位 (atomic unit)。当你通过创建或更新服务来声明期望的服务状态时，编排器 (orchestrator) 会通过调度任务来实现期望状态。例如，你定义一个服务，指示编排器始终保持 HTTP 监听器的三个实例运行。编排器通过创建三个任务来响应。每个任务都是一个插槽，调度器通过生成容器来填充该插槽。容器是任务的实例化。如果 HTTP 监听器任务随后未通过健康检查或崩溃，编排器会创建一个新的副本任务来生成新的容器。
任务是一种单向机制。它通过一系列状态单调地演进：ASSIGNED、PREPARING、RUNNING 等。如果任务失败，编排器会移除该任务及其容器，然后根据服务指定的期望状态创建一个新任务来替换它。
Docker Swarm 模式的底层逻辑是一个通用调度器和编排器。服务和任务抽象本身并不知道它们所实现的容器。理论上，你可以实现其他类型的任务，例如虚拟机任务或非容器化进程任务。调度器和编排器对任务的类型是不可知的。然而，Docker 仅支持容器任务。
下图显示了 Swarm 模式如何接受服务创建请求并将任务调度到工作节点。
挂起的服务
服务的配置方式可能导致当前 Swarm 中没有节点可以运行其任务。在这种情况下，服务将保持在 pending（挂起）状态。以下是服务可能保持在 pending 状态的几个示例。
Tip如果你唯一的意图是阻止服务部署，请将服务扩展 (scale) 到 0，而不是尝试将其配置为保持在
pending状态。
- 如果所有节点都处于
paused（暂停）或drained（排空）状态，而你创建了一个服务，该服务将一直处于挂起状态，直到有节点变为可用。实际上，第一个变为可用的节点将获得所有任务，因此在生产环境中这样做并不是一个好主意。 - 你可以为服务预留特定数量的内存。如果 Swarm 中没有节点拥有所需的内存量，服务将保持在挂起状态，直到有节点可以运行其任务。如果你指定一个非常大的值，例如 500 GB，任务将永远挂起，除非你真的有一个可以满足该需求的节点。
- 你可以对服务施加放置约束 (placement constraints)，而这些约束在特定时间可能无法得到满足。
这种行为说明了任务的需求和配置与 Swarm 的当前状态并没有紧密联系。作为 Swarm 的管理员，你声明 Swarm 的期望状态，管理器会与 Swarm 中的节点协作来创建该状态。你不需要对 Swarm 上的任务进行微观管理。
副本服务和全局服务
服务部署有两种类型：副本 (replicated) 和全局 (global)。
对于副本服务，你指定要运行的相同任务的数量。例如，你决定部署一个具有三个副本的 HTTP 服务，每个副本提供相同的内容。
全局服务是在每个节点上运行一个任务的服务。没有预先指定的任务数量。每当你向 Swarm 添加一个节点时，编排器就会创建一个任务，调度器将该任务分配给新节点。监控代理、防病毒扫描程序或你希望在 Swarm 中每个节点上运行的其他类型的容器是全局服务的良好候选者。
下图显示了灰色的三个副本服务和黑色的全局服务。
了解更多
- 阅读关于 Swarm 模式 节点 (nodes) 的工作原理。
- 了解 Swarm 模式中 PKI 的工作原理。