标签被定义为键值对的集合。我们将使用env（环境environment的缩写）作为键。目前，我们不需要标记用于持续交付任务的节点，因为它们还没有被作为服务运行，所以将在后面的章节中改变这一点。目前，只需要在类生产环境中标记将用于运行服务的节点。
我们将使用节点swarm-test-2和swarm-test-3作为类生产环境，所以将使用键env和值prod-like来标记它们。
我们从节点swarm-test-2开始：
可以通过检查节点来确认标签确实被加上：
node inspect命令的输出如下：
正如你所看到的，其中一个标签env的值是prod-like，如图5-2所示。
让我们给第二个节点加上相同的标签
图5-2 带有标签节点的CD集群
现在有几个节点标记为prod-like，我们可以创建只在这些服务器上运行的服务。
让我们用alpine镜像来创建一个服务，并将其限制到prod-like节点：
可以列出util服务的进程并确认它正运行在一个prod-like节点上：
service ps命令的输出如下（为简洁起见，删除了ID）：
正如你所看到的，该服务正在标记为env=prod-like的swarm-test-2节点内运行。
这本身并不能证明标签有效。毕竟，三个节点中的两个被标记为prod-like，因此，如果标签不起作用，服务还是有66%的概率会在其中一个节点上运行。所以，让我们调整一下。
把实例的数量增加到6个：
让我们看看util进程：
输出如下（为简洁起见，删除了ID）：
如你所见，所有6个实例都在标有env=prod-like的节点（节点swarm-test-2和swarm-test-3）上运行。
如果在全局模式下运行服务，则可以观察到类似的结果：
下面来看看util-2进程：
输出如下（为简洁起见，删除了ID）：(www.xing528.com)
由于告诉了Docker我们希望该服务是全局的，因此期望的状态是在所有节点上运行。但是，由于指定了约束node.labels.env==prod-like，所以副本仅在匹配的节点上运行。换句话说，服务仅在节点swarm-test-2和swarm-test-3上运行。如果将标签添加到节点swarm-test-1，Swarm也会在该节点上运行该服务。
在继续之前，让我们删除util和util-2服务：
现在知道了如何将服务限制到特定节点，因此，必须先创建一个服务，然后继续执行持续交付步骤。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
