切换语言

将服务部署到 swarm

目录

Swarm 服务使用声明性模型，这意味着您需要定义 desired 状态，并依赖 Docker 来维护此状态。这 state 包括（但不限于）以下信息：

  • 服务容器应运行的镜像名称和标记
  • 参与服务的容器数量
  • 是否向 swarm 外部的客户端公开了任何端口
  • 服务是否应在 Docker 启动时自动启动
  • 服务重新启动时发生的特定行为（例如 是否使用滚动重启）
  • 服务可以运行的节点的特征（例如资源 约束和放置首选项）

有关 Swarm 模式的概述，请参阅 Swarm 模式关键概念。 有关服务工作原理的概述，请参阅服务的工作原理。

创建服务

要创建无需额外配置的单副本服务，您只需要 以提供镜像名称。此命令使用 随机生成的 name，并且没有已发布的端口。这是一个天真的例子，因为 您无法与 Nginx 服务交互。

$ docker service create nginx

该服务被安排在可用节点上。确认服务 已成功创建并启动，请使用docker service ls命令：

$ docker service ls

ID                  NAME                MODE                REPLICAS            IMAGE                                                                                             PORTS
a3iixnklxuem        quizzical_lamarr    replicated          1/1                 docker.io/library/nginx@sha256:41ad9967ea448d7c2b203c699b429abe1ed5af331cd92533900c6d77490e0268

创建的服务并不总是立即运行。服务可以处于待处理状态 state （如果其镜像不可用），则没有节点满足 配置，或出于其他原因。有关更多信息，请参阅 待处理服务 信息。

要为您的服务提供名称，请使用--name旗：

$ docker service create --name my_web nginx

就像使用独立容器一样，您可以指定一个命令，该命令 服务的容器应该运行，方法是将其添加到镜像名称之后。这个例子 启动一个名为helloworld它使用alpine镜像并运行 命令ping docker.com:

$ docker service create --name helloworld alpine ping docker.com

您还可以指定要使用的服务的镜像标签。此示例修改 前一个使用alpine:3.6标记：

$ docker service create --name helloworld alpine:3.6 ping docker.com

有关镜像标签分辨率的更多详细信息，请参阅指定服务应使用的镜像版本。

Swarm 的 gMSA

注意

此示例仅适用于 Windows 容器。

Swarm 现在允许使用 Docker 配置作为 gMSA 凭证规范 - 这是经过 Active Directory 身份验证的应用程序的要求。这减轻了将凭证规范分发到使用它们的节点的负担。

以下示例假定 gMSA 及其凭证规范（称为 credspec.json）已存在，并且要部署到的节点已为 gMSA 正确配置。

要将配置用作凭证规范，请首先创建包含凭证规范的 Docker 配置：

$ docker config create credspec credspec.json

现在，您应该有一个名为 credspec 的 Docker 配置，并且您可以使用此凭证规范创建服务。为此，请在配置名称中使用 --credential-spec 标志，如下所示：

$ docker service create --credential-spec="config://credspec" <your image>

您的服务在启动时使用 gMSA 凭证规范，但与典型的 Docker 配置（通过传递 --config 标志使用）不同，凭证规范不会装载到容器中。

使用私有注册表上的镜像创建服务

如果您的镜像在需要登录的私有注册表中可用，请使用--with-registry-authflag 替换为docker service create登录后。如果 您的镜像存储在registry.example.com，这是一个私有注册表，请使用 如下所示的命令：

$ docker login registry.example.com

$ docker service  create \
  --with-registry-auth \
  --name my_service \
  registry.example.com/acme/my_image:latest

这会将登录令牌从本地客户端传递到 swarm 节点，其中 使用加密的 WAL 日志部署服务。有了这些信息， 节点能够登录到 Registry 并拉取镜像。

提供托管服务账户的凭证规格

在 Enterprise Edition 3.0 中，通过使用 Docker 配置功能集中分发和管理组托管服务帐户 （gMSA） 凭据，从而提高了安全性。Swarm 现在允许将 Docker 配置用作 gMSA 凭证规范，从而减轻了将凭证规范分发到使用它们的节点的负担。

注意

此选项仅适用于使用 Windows 容器的服务。

凭证规范文件在运行时应用，无需基于主机的凭证规范文件或注册表项 - 不会将 gMSA 凭证写入工作器节点上的磁盘。在容器启动之前，您可以向运行 swarm kit worker 节点的 Docker Engine 提供凭证规范。使用基于 gMSA 的配置部署服务时，凭证规范将直接传递到该服务中容器的运行时。

这--credential-spec必须采用以下格式之一：

  • file://<filename>：引用的文件必须存在于CredentialSpecs子目录，默认为C:\ProgramData\Docker\在 Windows 上。例如，指定file://spec.json负荷C:\ProgramData\Docker\CredentialSpecs\spec.json.
  • registry://<value-name>：凭证规范是从守护程序主机上的 Windows 注册表中读取的。
  • config://<config-name>：在 CLI 中，配置名称会自动转换为配置 ID。 指定的config被使用。

以下简单示例从 Active Directory （AD） 实例中检索 gMSA 名称和 JSON 内容：

$ name="mygmsa"
$ contents="{...}"
$ echo $contents > contents.json

确保已为 gMSA 正确配置了要部署到的节点。

要将配置用作凭证规范，请在名为credpspec.json. 您可以为config.

$ docker config create --label com.docker.gmsa.name=mygmsa credspec credspec.json

现在，您可以使用此凭证规范创建服务。指定--credential-specflag 替换为配置名称：

$ docker service create --credential-spec="config://credspec" <your image>

您的服务在启动时使用 gMSA 凭证规范，但与典型的 Docker 配置（通过传递 --config 标志使用）不同，凭证规范不会装载到容器中。

更新服务

您可以使用docker service update命令。当您更新服务时，Docker 会停止其 容器，并使用新配置重新启动它们。

由于 Nginx 是一项 Web 服务，因此如果您发布 80 端口，效果会好得多 发送到 Swarm 外部的客户端。您可以在创建服务时指定此项。 使用-p或--publish旗。更新现有服务时，标志 是--publish-add.还有一个--publish-rm标志以删除 之前出版过。

假设my_webservice 仍然存在，请使用 以下命令将其更新为发布端口 80。

$ docker service update --publish-add 80 my_web

要验证它是否有效，请使用docker service ls:

$ docker service ls

ID                  NAME                MODE                REPLICAS            IMAGE                                                                                             PORTS
4nhxl7oxw5vz        my_web              replicated          1/1                 docker.io/library/nginx@sha256:41ad9967ea448d7c2b203c699b429abe1ed5af331cd92533900c6d77490e0268   *:0->80/tcp

有关发布端口工作原理的更多信息，请参阅发布端口。

您可以更新有关现有服务的几乎所有配置详细信息， 包括它运行的镜像名称和标记。请参阅在创建服务后更新服务的镜像。

删除服务

要删除服务，请使用docker service remove命令。您可以删除 service 的 ID 或名称，如docker service ls命令。以下命令将删除my_web服务。

$ docker service remove my_web

服务配置详细信息

以下部分提供有关服务配置的详细信息。本主题 并未涵盖所有标志或场景。在几乎所有情况下，只要您可以 在创建服务时定义配置，您还可以更新现有的 service 的配置。

请参阅命令行参考docker service create和docker service update或运行 其中一个命令与--help旗。

配置运行时环境

您可以在 容器：

  • 环境变量使用--env旗
  • 使用--workdir旗
  • 使用--user旗

以下服务的容器具有环境变量$MYVAR设置为myvalue，从/tmp/目录中，并作为my_user用户。

$ docker service create --name helloworld \
  --env MYVAR=myvalue \
  --workdir /tmp \
  --user my_user \
  alpine ping docker.com

更新现有服务运行的命令

要更新现有服务运行的命令，您可以使用--args旗。 以下示例更新了名为helloworld因此 它会运行命令ping docker.com而不是它正在运行的任何命令 以前：

$ docker service update --args "ping docker.com" helloworld

指定服务应使用的镜像版本

当您创建服务时，未指定有关 要使用的镜像，则服务使用标有latest标记。 您可以强制服务在几个 不同的方法，具体取决于您想要的结果。

镜像版本可以用几种不同的方式表示：

  • 如果指定标签，则管理器（或 Docker 客户端，如果使用内容信任）会将该标签解析为摘要。 当在 worker 节点上收到创建容器任务的请求时， Worker 节点只能看到摘要，而看不到标签。

    $ docker service create --name="myservice" ubuntu:16.04

    某些标签表示离散版本，例如ubuntu:16.04.像这样的标签 随着时间的推移，几乎总是分解为稳定的摘要。推荐 请尽可能使用此类标签。

    其他类型的标签，例如latest或nightly可能会解析为新的 digest 的 Digest 频率，具体取决于镜像作者更新标签的频率。是的 不建议使用频繁更新的标签运行服务，以 防止不同的 Service Replica 任务使用不同的镜像版本。

  • 如果您根本不指定版本，按照惯例，镜像的latest标记 解析为摘要。工作人员在创建 服务任务。

    因此，以下两个命令是等效的：

    $ docker service create --name="myservice" ubuntu

$ docker service create --name="myservice" ubuntu:latest

  • 如果直接指定摘要，则镜像的确切版本始终为 在创建服务任务时使用。

    $ docker service create \
    --name="myservice" \
    ubuntu:16.04@sha256:35bc48a1ca97c3971611dc4662d08d131869daa692acb281c7e9e052924e38b1

创建服务时，镜像的标签将解析为特定的摘要 该标签在创建服务时指向。为此 Worker 节点 service 永远使用该特定摘要，除非该服务明确 更新。如果您确实使用经常更改的标签，则此功能尤其重要 如latest，因为它确保所有服务任务都使用相同的版本 的镜像。

注意

如果内容信任为 enabled，则客户端实际上会将镜像的标签解析为之前的摘要 联系 Swarm Manager，以验证镜像是否已签名。 因此，如果您使用内容信任，则 swarm 管理器会收到请求 预先解决。在这种情况下，如果客户端无法将镜像解析为 digest 时，请求将失败。

如果经理无法将标签解析为摘要，则每个 worker node 负责将标签解析为摘要，不同的节点可能会 使用不同版本的镜像。如果发生这种情况，则会显示类似 记录 following，将占位符替换为真实信息。

unable to pin image <IMAGE-NAME> to digest: <REASON>

要查看镜像的当前摘要，请发出命令docker inspect <IMAGE>:<TAG>并查找RepoDigests线。这 以下是 的当前摘要ubuntu:latest当时此内容 写的。为清楚起见，输出被截断。

$ docker inspect ubuntu:latest

"RepoDigests": [
    "ubuntu@sha256:35bc48a1ca97c3971611dc4662d08d131869daa692acb281c7e9e052924e38b1"
],

创建服务后，除非您显式运行docker service update使用--image标志，如下所述。其他更新 扩展服务、添加或删除网络或卷等作， 重命名服务或任何其他类型的更新作不会更新 service 的镜像。

创建服务后更新服务镜像

每个标签代表一个摘要，类似于 Git 哈希。某些标签（例如latest）通常会更新以指向新的摘要。其他 （如ubuntu:16.04表示已发布的软件版本，并且不需要 update 指向新的摘要（如果有）。当您创建服务时，它会 受限制使用镜像的特定摘要创建任务，直到您 使用 Update the serviceservice update使用--image旗。

当您运行service update使用--image标志，则 Swarm Manager 会查询 Docker Hub 或当前摘要标签的私有 Docker 注册表 指向并更新 Service 任务以使用该摘要。

注意

如果您使用内容信任，则 Docker 客户端解析镜像，Swarm Manager 接收镜像和摘要， 而不是标签。

通常，经理可以将标签解析为新的摘要和服务 更新，重新部署每个任务以使用新镜像。如果经理不能 解决标签或其他问题，接下来的两节概述了什么 期待。

如果 Manager 解析了标签

如果 swarm 管理器可以将 image 标签解析为摘要，它会指示 worker nodes 重新部署任务并使用该摘要中的镜像。

  • 如果 worker 在该摘要中缓存了镜像，则它会使用它。

  • 如果没有，它会尝试从 Docker Hub 或私有注册表中提取镜像。

    • 如果成功，则使用新镜像部署任务。

    • 如果 worker 无法拉取镜像，则服务将无法在该镜像上部署 worker 节点。Docker 再次尝试部署任务，可能在不同的 worker 节点。

如果 Manager 无法解析标签

如果 swarm 管理器无法将镜像解析为摘要，则不会丢失所有内容：

  • 管理器指示 Worker 节点使用镜像重新部署任务 在那个标签上。

  • 如果 worker 具有解析为该标签的本地缓存镜像，则使用 那个镜像。

  • 如果 worker 没有解析为标签的本地缓存镜像，则 worker 尝试连接到 Docker Hub 或私有注册表以拉取 镜像。

    • 如果成功，则 worker 将使用该镜像。

    • 如果失败，则任务部署失败，Manager 将再次尝试部署 任务，可能位于不同的 worker 节点上。

发布端口

创建 Swarm 服务时，您可以将该服务的端口发布到主机 以两种方式在 swarm 之外：

  • 您可以依赖布线网格。 当您发布服务端口时，swarm 会使该服务可通过 target 端口，无论是否有 服务是否在该节点上运行。这不那么复杂，而且是正确的 多种服务类型的选择。

  • 您可以直接在运行该服务的 swarm 节点上发布服务任务的端口。这将绕过路由网格并提供 最大的灵活性，包括您开发自己的路由的能力 框架。但是，您有责任跟踪每个任务的位置 运行请求并将其路由到任务，以及跨节点进行负载均衡。

请继续阅读以了解有关每种方法的更多信息和用例。

使用路由网格发布服务的端口

要将服务的端口从外部发布到 swarm，请使用--publish <PUBLISHED-PORT>:<SERVICE-PORT>旗。swarm 使服务 可在每个 Swarm 节点上的已发布端口访问。如果外部主机 连接到任何 Swarm 节点上的该端口，路由网格会将其路由到 Task。 外部主机不需要知道 IP 地址或内部使用的 port 来与服务交互。当用户或进程 连接到服务时，任何运行 Service Task 的工作节点都可能响应。为 有关 Swarm 服务网络的更多详细信息，请参阅管理 Swarm 服务网络。

示例：在 10 节点 swarm 上运行三任务 Nginx 服务

假设您有一个 10 节点的 swarm，并且您部署了一个运行 10 节点 Swarm 上的 3 个任务：

$ docker service create --name my_web \
                        --replicas 3 \
                        --publish published=8080,target=80 \
                        nginx

三个任务在最多三个节点上运行。您无需知道哪些节点 正在运行任务;连接到 10 个节点中任何一个节点上的端口 8080 将您连接到三个nginx任务。您可以使用curl. 以下示例假定localhost是 Swarm 节点之一。如果 事实并非如此，或者localhost未解析为 IP 地址 host，请替换主机的 IP 地址或可解析的主机名。

HTML 输出被截断：

$ curl localhost:8080

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...truncated...
</html>

后续连接可以路由到同一个 swarm 节点或不同的 swarm 节点。

直接在 swarm 节点上发布服务的端口

如果您满足以下条件，则使用路由网格可能不是您的应用的正确选择 需要根据应用程序状态做出路由决策，或者您需要总计 控制将请求路由到服务任务的流程。发布 服务的端口直接位于运行该服务的节点上，请使用mode=host选项添加到--publish旗。

注意

如果您使用mode=host并将published=<PORT>这会创建一个隐式的 限制，您只能在给定 Swarm 上为该服务运行一个任务 节点。您可以通过指定published无端口 定义，这会导致 Docker 为每个任务分配一个随机端口。

此外，如果您使用mode=host并且您不使用--mode=global标记docker service create，很难知道 哪些节点正在运行服务以将工作路由到它们。

示例：运行nginx每个 Swarm 节点上的 Web 服务器服务

nginx 是一个开源的反向代理，load balancer、HTTP 缓存和 Web 服务器。如果您使用 路由网格，连接到任何 Swarm 节点上的 nginx 端口都会显示 Web 页面，用于（实际上）运行该服务的随机 Swarm 节点。

以下示例在 swarm 中的每个节点上运行 nginx 作为服务，并且 在每个 Swarm 节点上本地公开 nginx 端口。

$ docker service create \
  --mode global \
  --publish mode=host,target=80,published=8080 \
  --name=nginx \
  nginx:latest

您可以在每个 swarm 节点的端口 8080 上访问 nginx 服务器。如果您添加了 node 添加到 swarm 中，则会在其上启动 nginx 任务。您不能再开始另一个 service 或 container 绑定到端口 8080 的任何 Swarm 节点上。

注意

这是一个纯粹的说明性示例。创建应用层 多层服务的路由框架很复杂，超出了 本主题。

将服务连接到覆盖网络

您可以使用叠加网络连接群中的一个或多个服务。

首先，使用docker network create命令与--driver overlay旗。

$ docker network create --driver overlay my-network

在 swarm 模式下创建覆盖网络后，所有管理器节点都可以访问 到网络。

您可以创建新服务并将--network标志以附加服务 到 overlay 网络：

$ docker service create \
  --replicas 3 \
  --network my-network \
  --name my-web \
  nginx

虫群扩展my-network分配给运行服务的每个节点。

您还可以使用--network-add旗。

$ docker service update --network-add my-network my-web

要断开正在运行的服务与网络的连接，请使用--network-rm旗。

$ docker service update --network-rm my-network my-web

有关覆盖网络和服务发现的更多信息，请参阅将服务附加到覆盖网络和 Docker 群模式覆盖网络安全模型。

向服务授予对密钥的访问权限

要创建有权访问 Docker 托管密钥的服务，请使用--secret旗。有关更多信息，请参阅管理 Docker 服务的敏感字符串 （密钥）

自定义服务的隔离模式

重要

此设置仅适用于 Windows 主机，对于 Linux 主机，此设置将被忽略。

Docker 允许您指定 swarm 服务的隔离 模式。隔离模式可以是以下模式之一：

  • default：使用为 Docker 主机配置的默认隔离模式，如 由-exec-optflag 或exec-opts数组daemon.json.如果 守护程序未指定隔离技术，process是默认值 对于 Windows Server，以及hyperv是 Windows 10 的。

  • process：在主机上将服务任务作为单独的进程运行。

    注意

    process隔离模式仅在 Windows Server 上受支持。 Windows 10 仅支持hyperv隔离模式。

  • hyperv：以隔离方式运行服务任务hyperv任务。这会增加 开销，但提供了更多的隔离。

您可以在创建或更新新服务时使用 这--isolation旗。

控制服务放置

Swarm 服务提供了几种不同的方法来控制规模和 将服务放置在不同的节点上。

  • 您可以指定服务是否需要运行特定数量的副本 或者应该在每个 worker 节点上全局运行。请参阅复制服务或全球服务。

  • 您可以配置服务的 CPU 或内存要求，以及 service 仅在可以满足这些要求的节点上运行。

  • 放置约束允许您配置服务 仅在具有特定（任意）数据集的节点上运行，并导致 如果不存在合适的节点，则部署失败。例如，您可以 指定您的服务应仅在带有任意标签的节点上运行pci_compliant设置为true.

  • 放置首选项允许您应用任意 label 并为每个节点分配一系列值，并将服务的任务分散 使用算法在这些节点之间。目前，唯一支持的算法 是spread，这会尝试将它们均匀放置。例如，如果你 用标签标记每个节点rack的值为 1-10，然后指定 键入rack，则服务任务将作为 在标签rack，服用其他 放置约束、放置首选项和其他特定于节点的 考虑限制。

    与约束不同，放置首选项是 best-effort，而服务 如果没有节点可以满足首选项，则不会 Fail Deploy。如果指定 placement 首选项，则与该首选项匹配的节点为 当 Swarm Manager 决定哪些节点应该运行 服务任务。其他因素，例如服务的高可用性、 此外，还要考虑计划运行服务任务的节点。为 例如，如果您有 N 个带有机架标签的节点（然后是其他一些节点），并且 您的服务配置为运行 N+1 个副本，则 +1 被调度在 节点上尚未包含该服务的节点（如果有的话），无论 该节点是否具有rack标签或非标签。

复制服务或全球服务

Swarm 模式有两种类型的服务：复制服务和全局服务。对于复制的 services 中，您可以指定 Swarm Manager 要 schedule 到可用节点上。对于全局服务，调度程序会放置一个 task 的 task 任务。

您可以使用--mode旗。如果未指定 模式，则服务默认为replicated.对于复制的服务，您可以指定 要使用--replicas旗。为 示例，要启动具有 3 个副本任务的复制 nginx 服务：

$ docker service create \
  --name my_web \
  --replicas 3 \
  nginx

要在每个可用节点上启动全局服务，请将--mode global自docker service create.每次有新节点可用时，调度程序 将 Global Service 的任务放置在新节点上。例如，要启动 在 Swarm 中的每个节点上运行 Alpine 的服务：

$ docker service create \
  --name myservice \
  --mode global \
  alpine top

Service Constraints 允许您设置节点在计划程序之前要满足的条件 将服务部署到节点。您可以将约束应用于 基于节点属性和元数据或引擎元数据的服务。了解更多 有关约束的信息，请参阅docker service create CLI 参考。

为服务预留内存或 CPU

要为服务预留给定的内存量或 CPU 数量，请使用--reserve-memory或--reserve-cpu标志。如果没有可用的节点可以满足 要求（例如，如果您请求 4 个 CPU 并且 Swarm 中没有节点 具有 4 个 CPU），则服务将保持待处理状态，直到相应的节点 可用于运行其任务。

内存不足异常 （OOME）

如果您的服务尝试使用的内存多于 swarm 节点的可用内存，则 您可能会遇到内存不足异常 （OOME） 和容器，或者 Docker 守护程序可能会被内核 OOM 终止程序杀死。为了防止这种情况 发生时，请确保您的应用程序在具有足够内存的主机上运行，并且 请参阅了解内存不足的风险。

Swarm 服务允许您使用资源约束、放置首选项和 标签，以确保您的服务部署到适当的 Swarm 节点。

放置约束

使用放置约束来控制服务可以分配到的节点。在 以下示例中，该服务仅在标签为 region设置 自east.如果没有适当标记的节点可用，任务将等待Pending直到它们可用。这--constraintflag 使用相等 运算符 （ 或==!=).对于复制的服务，可能会所有 服务在同一节点上运行，或者每个节点只运行一个副本，或者某些 节点不运行任何副本。对于全球服务，该服务在每个 满足放置约束和任何资源要求的节点。

$ docker service create \
  --name my-nginx \
  --replicas 5 \
  --constraint node.labels.region==east \
  nginx

您还可以使用constraintservice-level 键在compose.yml文件。

如果您指定多个放置约束，则服务只会部署到 节点。以下示例将服务限制为在其上运行 所有节点，其中region设置为east和type未设置为devel:

$ docker service create \
  --name my-nginx \
  --mode global \
  --constraint node.labels.region==east \
  --constraint node.labels.type!=devel \
  nginx

也可以将放置约束与放置首选项结合使用 和 CPU/内存限制。请注意，不要使用不是 可能实现。

有关约束的更多信息，请参阅docker service create CLI 参考。

放置首选项

而 placement constraints 限制节点服务 可以运行，则 Placement Preferences 会尝试将任务放置在适当的节点上 以算法方式 （目前，仅均匀分布）。例如，如果你 为每个节点分配一个rack标签中，您可以将位置首选项设置为 Spread 该服务在节点之间均匀分配racklabel、按值。这样，如果 您丢失了一个机架，该服务仍在其他机架上的节点上运行。

位置首选项不是严格执行的。如果没有节点具有标签 您在首选项中指定，则部署服务时，就像 首选项。

注意

全局服务的 Placement preferences 将被忽略。

以下示例设置一个首选项以跨节点分布部署 基于datacenter标签。如果某些节点具有datacenter=us-east而其他人则有datacenter=us-west，则服务为 在两组节点之间尽可能均匀地部署。

$ docker service create \
  --replicas 9 \
  --name redis_2 \
  --placement-pref 'spread=node.labels.datacenter' \
  redis:7.4.0

注意

缺少用于传播的标签的节点仍会收到 任务分配。作为一个组，这些节点以相等的方式接收任务 与特定标签标识的任何其他组的比例 价值。从某种意义上说，缺少标签与标签 附加到它的 null 值。如果服务应仅在 标签用于跨页首选项的节点，则 首选项应与 constraint 结合使用。

您可以指定多个放置首选项，这些首选项将在 的顺序。以下示例使用 多个 Placement 首选项。任务首先分布在各种 datacenters，然后在机架上（如相应的标签所示）：

$ docker service create \
  --replicas 9 \
  --name redis_2 \
  --placement-pref 'spread=node.labels.datacenter' \
  --placement-pref 'spread=node.labels.rack' \
  redis:7.4.0

也可以将放置首选项与放置约束结合使用 或 CPU/内存限制。请注意，不要使用不是 可能实现。

此图说明了放置首选项的工作原理：

How placement preferences work

使用docker service update,--placement-pref-add在所有现有 Placement Preferences 之后附加新的 Placement 首选项。--placement-pref-rm删除与 论点。

配置服务的更新行为

在创建服务时，您可以指定滚动更新行为，以指定 swarm 应在您运行docker service update. 您还可以将这些标志指定为更新的一部分，作为docker service update.

这--update-delayflag 配置服务更新之间的时间延迟 任务或任务集。您可以描述时间T作为 秒数Ts纪要Tm或小时Th.所以10m30s表示 10 分 30 秒延迟。

默认情况下，计划程序一次更新 1 个任务。您可以将--update-parallelism标志配置最大服务任务数 调度程序同时更新。

当对单个任务的更新返回RUNNING、调度程序 通过继续执行另一个任务来继续更新，直到更新所有任务。 如果在更新期间的任何时候，任务返回FAILED时，调度程序将暂停 更新。您可以使用--update-failure-action的标志docker service create或docker service update.

在下面的示例服务中，计划程序将更新应用于最多 2 个 副本。当更新的任务返回RUNNING或FAILED, 计划程序会等待 10 秒，然后停止下一个要更新的任务：

$ docker service create \
  --replicas 10 \
  --name my_web \
  --update-delay 10s \
  --update-parallelism 2 \
  --update-failure-action continue \
  alpine

这--update-max-failure-ratioflag 控制任务可以失败的比例 在更新期间，在更新整体被视为失败之前。为 example，其中--update-max-failure-ratio 0.1 --update-failure-action pause, 在 10% 的更新任务失败后，更新将暂停。

如果任务未失败，则认为单个任务更新失败 启动，或者如果它在使用 这--update-monitor旗。的默认值--update-monitor30 岁 秒，这意味着任务在任务 started 计入服务更新失败阈值，失败 之后不计算在内。

回滚到服务的上一个版本

如果服务的更新版本未按预期运行，则 可以使用docker service update的--rollback旗。这将还原服务 添加到最近的docker service update命令。

其他选项可以与--rollback;例如--update-delay 0s，以执行回滚，而无需在任务之间延迟：

$ docker service update \
  --rollback \
  --update-delay 0s
  my_web

您可以将服务配置为在服务更新失败时自动回滚 进行部署。请参阅更新失败时自动回滚。

手动回滚在服务器端处理，这允许手动启动 rollbacks 以遵循新的 rollback 参数。请注意，--rollback不能 与其他标志结合使用，以docker service update.

更新失败时自动回滚

您可以这样配置服务：如果对服务进行更新 导致重新部署失败，则服务可以自动回滚到 以前的配置。这有助于保护服务可用性。您可以设置 在服务创建或更新时出现以下一个或多个标志。如果你没有 set a value 时，使用默认值。

旗违约描述
--rollback-delay0s回滚任务后在回滚下一个任务之前要等待的时间。值0表示在部署第一个回滚任务后立即回滚第二个任务。
--rollback-failure-actionpause当任务回滚失败时，是否pause或continue尝试回滚其他任务。
--rollback-max-failure-ratio0回滚期间允许的失败率，指定为介于 0 和 1 之间的浮点数。例如，给定 5 个任务，失败率.2将容忍一个无法回滚的任务。值0表示不允许任何失败，而值1表示可以容忍任意数量的失败。
--rollback-monitor5s每个任务回滚后的持续时间，用于监控失败。如果任务在此时间段之前停止，则回滚被视为失败。
--rollback-parallelism1要并行回滚的最大任务数。默认情况下，一次回滚一个任务。值0导致所有任务并行回滚。

以下示例将redisservice 自动回滚 如果docker service update部署失败。两个任务可以回滚 平行。任务在回滚后会监控 20 秒，以确保它们这样做 不退出，并且最大故障率为 20%。默认值为 用于--rollback-delay和--rollback-failure-action.

$ docker service create --name=my_redis \
                        --replicas=5 \
                        --rollback-parallelism=2 \
                        --rollback-monitor=20s \
                        --rollback-max-failure-ratio=.2 \
                        redis:latest

授予服务对卷或绑定挂载的访问权限

为了获得最佳性能和可移植性，您应该避免写入重要数据 直接写入容器的可写层。您应该改用数据卷 或 bind mounts。此原则也适用于服务。

您可以为 swarm 中的服务创建两种类型的挂载：volumemounts 或bind坐骑。无论您使用哪种类型的挂载，都可以使用--mount标志，或者--mount-add或--mount-rm标志。默认值为数据卷，如果您 不要指定类型。

数据量

数据卷是独立于容器而存在的存储。这 Swarm 服务下数据卷的生命周期与 器皿。卷的寿命比任务和服务长，因此必须将其删除 单独管理。可以在部署服务之前创建卷，或者如果 当任务被安排在特定主机上时，它们不存在，它们是 根据服务上的卷规范自动创建。

要将现有数据卷与服务结合使用，请使用--mount旗：

$ docker service create \
  --mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH> \
  --name myservice \
  <IMAGE>

如果名称<VOLUME-NAME>不存在 scheduled 到特定主机，然后创建一个。默认卷 driver 为local.将其他卷驱动程序与此按需创建一起使用 pattern，请使用--mount旗：

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

有关如何创建数据卷和使用卷的更多信息 驱动程序，请参阅使用卷。

绑定挂载

绑定挂载是来自调度程序部署的主机的文件系统路径 任务的容器。Docker 将路径挂载到容器中。这 在 Swarm 初始化 任务。

以下示例显示了 bind 挂载语法：

  • 要挂载读写绑定：

    $ docker service create \
  --mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH> \
  --name myservice \
  <IMAGE>

  • 要挂载只读绑定：

    $ docker service create \
  --mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>,readonly \
  --name myservice \
  <IMAGE>

重要

绑定挂载可能很有用，但它们也可能导致问题。在 大多数情况下，建议您构建应用程序，以便 不需要从主机挂载路径。主要风险包括 以后：

  • 如果您将 mount 主机路径绑定到服务的容器中，则路径 必须存在于每个 Swarm 节点上。Docker swarm 模式调度器可以调度 满足资源可用性要求的任何计算机上的容器 并满足您指定的所有约束和放置首选项。

  • Docker swarm 模式调度程序可能会重新调度正在运行的服务 容器（如果它们变得运行状况不佳或无法访问）。

  • Host bind 挂载是不可移植的。当您使用 bind 挂载时，没有 保证您的应用程序在开发中的运行方式与开发方式相同 在生产中。

使用模板创建服务

您可以将模板用于service create，使用语法 由 Go 的 text/template 包提供。

支持以下标志：

  • --hostname
  • --mount
  • --env

Go 模板的有效占位符为：

占 位 符描述
.Service.ID服务 ID
.Service.Name服务名称
.Service.Labels服务标签
.Node.ID节点 ID
.Node.Hostname节点主机名
.Task.Name任务名称
.Task.Slot任务槽

模板示例

此示例根据 service 的名称和运行容器的节点的 ID：

$ docker service create --name hosttempl \
                        --hostname="{{.Node.ID}}-{{.Service.Name}}"\
                         busybox top

要查看使用模板的结果，请使用docker service ps和docker inspect命令。

$ docker service ps va8ew30grofhjoychbr6iot8c

ID            NAME         IMAGE                                                                                   NODE          DESIRED STATE  CURRENT STATE               ERROR  PORTS
wo41w8hg8qan  hosttempl.1  busybox:latest@sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912  2e7a8a9c4da2  Running        Running about a minute ago

$ docker inspect --format="{{.Config.Hostname}}" hosttempl.1.wo41w8hg8qanxwjwsg4kxpprj

了解更多信息