From 64279e87a621a498087834cb7a9c5c69d810e35d Mon Sep 17 00:00:00 2001 From: Trapier Marshall Date: Thu, 6 Sep 2018 12:36:40 -0400 Subject: [PATCH] fix swarm service constraint examples 1. Be more specific about what happens when constraints aren't satified. 2. There is no `--global`. Also addressed in network/overlay.md. 3. Label constraints do not match node labels without `node.label` prefix. AFAIK neither 2 nor 3 have ever been correct testedon: 17.06.2-ee-16 --- engine/swarm/services.md | 24 ++++++++++++------------ network/overlay.md | 6 +++--- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/engine/swarm/services.md b/engine/swarm/services.md index 09190fe21e..a045df39b0 100644 --- a/engine/swarm/services.md +++ b/engine/swarm/services.md @@ -621,20 +621,20 @@ labels to ensure that your service is deployed to the appropriate swarm nodes. Use placement constraints to control the nodes a service can be assigned to. In the following example, the service only runs on nodes with the -[label](engine/swarm/manage-nodes.md#add-or-remove-label-metadata) -`region` set to `east`. If no appropriately-labelled nodes are available, -deployment fails. The `--constraint` flag uses an equality operator -(`==` or `!=`). For replicated services, it is possible that all services -run on the same node, or each node only runs one replica, or that some nodes -don't run any replicas. For global services, the service runs on every node -that meets the placement constraint and any -[resource requirements](#reserve-cpu-or-memory-for-a-service). +[label](engine/swarm/manage-nodes.md#add-or-remove-label-metadata) `region` set +to `east`. If no appropriately-labelled nodes are available, tasks will wait in +`Pending` until they become available. The `--constraint` flag uses an equality +operator (`==` or `!=`). For replicated services, it is possible that all +services run on the same node, or each node only runs one replica, or that some +nodes don't run any replicas. For global services, the service runs on every +node that meets the placement constraint and any [resource +requirements](#reserve-cpu-or-memory-for-a-service). ```bash $ docker service create \ --name my-nginx \ --replicas 5 \ - --constraint region==east \ + --constraint node.labels.region==east \ nginx ``` @@ -648,9 +648,9 @@ all nodes where `region` is set to `east` and `type` is not set to `devel`: ```bash $ docker service create \ --name my-nginx \ - --global \ - --constraint region==east \ - --constraint type!=devel \ + --mode global \ + --constraint node.labels.region==east \ + --constraint node.labels.type!=devel \ nginx ``` diff --git a/network/overlay.md b/network/overlay.md index 75af520eef..8b476c2d3d 100644 --- a/network/overlay.md +++ b/network/overlay.md @@ -241,9 +241,9 @@ When you connect to a published port on any swarm node (whether it is running a given service or not), you are redirected to a worker which is running that service, transparently. Effectively, Docker acts as a load balancer for your swarm services. Services using the routing mesh are running in _virtual IP (VIP) -mode_. Even a service running on each node (by means of the `--global` flag) -uses the routing mesh. When using the routing mesh, there is no guarantee about -which Docker node services client requests. +mode_. Even a service running on each node (by means of the `--mode global` +flag) uses the routing mesh. When using the routing mesh, there is no guarantee +about which Docker node services client requests. To bypass the routing mesh, you can start a service using _DNS Round Robin (DNSRR) mode_, by setting the `--endpoint-mode` flag to `dnsrr`. You must run