服务的工作原理
要在 Docker Engine 处于 Swarm 模式时部署应用程序镜像，您需要创建一个 服务。通常，服务是 context 的 context。服务示例可能包括 HTTP server、数据库或您希望运行的任何其他类型的可执行程序 在分布式环境中。
创建服务时，您可以指定要使用的容器镜像以及 命令以在正在运行的容器内执行。您还可以为 服务包括：
- 召集使服务在 召集 外部可用的端口
- 一个覆盖网络，用于服务连接到 swarm 中的其他服务
- CPU 和内存限制和预留
- 滚动更新策略
- 要在 swarm 中运行的镜像副本数
服务、任务和容器
当您将服务部署到 swarm 时，swarm manager 会接受您的服务 definition 作为服务的所需状态。然后，它会安排服务 作为一个或多个副本任务。任务独立运行 在 Swarm 中的节点上相互分配。
例如，假设您希望在 HTTP 的三个实例之间进行负载均衡 听者。下图显示了具有三个副本的 HTTP 侦听器服务。 侦听器的三个实例中的每一个都是 swarm 中的一个任务。
容器是一个隔离的进程。在 Swarm 模式模型中，每个任务调用 恰好是一个容器。任务类似于一个“槽”，其中调度程序 放置容器。一旦容器处于活动状态，调度程序就会识别出 任务处于 Running 状态。如果容器未通过运行状况检查或 terminates，则任务将终止。
任务和调度
任务是 swarm 中调度的原子单元。当您声明 所需服务状态，则 Orchestrator 通过调度任务实现期望状态。例如，您定义了一个 指示编排器保留 HTTP 的三个实例的服务 listener 始终运行。编排器通过创建三个 任务。每个任务都是一个槽，调度程序通过生成容器来填充该槽。这 container 是任务的实例化。如果 HTTP 侦听器任务随后 未通过运行状况检查或崩溃，则 Orchestrator 会创建新的副本任务 这将生成一个新容器。
任务是一种单向机制。它通过 状态系列：已分配、已准备、正在运行等。如果任务失败，则 Orchestrator 将删除任务及其容器，然后创建一个新任务以 根据服务指定的 DESIRED STATE 替换它。
Docker 的 Swarm 模式的底层逻辑是一个通用的调度器， 编排器。服务和任务抽象本身不知道 他们实现的容器。假设，您可以实现其他类型的 任务，例如虚拟机任务或非容器化进程任务。这 Scheduler 和 Orchestrator 对任务的类型无关。但是， 当前版本的 Docker 仅支持容器任务。
下图显示了 Swarm 模式如何接受服务创建请求，并且 将任务调度到 worker 节点。
待处理服务
服务的配置方式可以是
Swarm 可以运行其任务。在这种情况下，服务保持状态 。
以下是服务何时可能保持状态的几个示例。pendingpending
提示
如果您的唯一目的是阻止服务 部署时，将服务扩展到 0，而不是尝试在 这样它就保持在 中。
pending
如果所有节点都已暂停或耗尽，并且您创建了一个服务，则为 pending 直到节点可用。实际上，第一个节点成为 available 获取所有任务，因此在 生产环境。
您可以为服务预留特定数量的内存。如果 swarm 具有所需的内存量，则服务仍处于待处理状态 状态，直到节点可用，该节点可以运行其任务。如果您指定非常 较大的值（例如 500 GB），则任务将永远保持待处理状态，除非您 真的有一个可以满足它的节点。
您可以对服务施加放置约束，这些约束可能会 无法在给定的时间获得荣誉。
此行为说明了任务的要求和配置 与 Swarm 的当前状态没有紧密联系。作为 一个 swarm 中，您声明 swarm 的所需状态，并且 manager 使用 Swarm 中的节点来创建该状态。您无需对 任务。
复制服务和全球服务
有两种类型的服务部署：复制和全局。
对于复制的服务，您可以指定要执行的相同任务的数量 跑。例如，您决定部署一个具有三个副本的 HTTP 服务，每个副本 提供相同的内容。
全局服务是在每个节点上运行一个任务的服务。没有 预先指定的任务数。每次向 swarm 添加节点时， Orchestrator 将创建一个任务，调度程序将该任务分配给新节点。 全球服务的良好候选者是监控代理、防病毒扫描程序 或您希望在 Swarm 中的每个节点上运行的其他类型的容器。
下图显示了一个灰色的三服务副本和一个 global service 黑色。
