Merge pull request #7328 from trapier/swarm-service-node-label-constraints

fix swarm service constraint examples. Ready per @trapier
This commit is contained in:
Anne Henmi 2018-09-26 08:53:48 -06:00 committed by GitHub
commit 1eb8514229
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 15 additions and 15 deletions

View File

@ -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 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 the following example, the service only runs on nodes with the
[label](engine/swarm/manage-nodes.md#add-or-remove-label-metadata) [label](engine/swarm/manage-nodes.md#add-or-remove-label-metadata) `region` set
`region` set to `east`. If no appropriately-labelled nodes are available, to `east`. If no appropriately-labelled nodes are available, tasks will wait in
deployment fails. The `--constraint` flag uses an equality operator `Pending` until they become available. The `--constraint` flag uses an equality
(`==` or `!=`). For replicated services, it is possible that all services operator (`==` or `!=`). For replicated services, it is possible that all
run on the same node, or each node only runs one replica, or that some nodes services run on the same node, or each node only runs one replica, or that some
don't run any replicas. For global services, the service runs on every node nodes don't run any replicas. For global services, the service runs on every
that meets the placement constraint and any node that meets the placement constraint and any [resource
[resource requirements](#reserve-cpu-or-memory-for-a-service). requirements](#reserve-cpu-or-memory-for-a-service).
```bash ```bash
$ docker service create \ $ docker service create \
--name my-nginx \ --name my-nginx \
--replicas 5 \ --replicas 5 \
--constraint region==east \ --constraint node.labels.region==east \
nginx nginx
``` ```
@ -648,9 +648,9 @@ all nodes where `region` is set to `east` and `type` is not set to `devel`:
```bash ```bash
$ docker service create \ $ docker service create \
--name my-nginx \ --name my-nginx \
--global \ --mode global \
--constraint region==east \ --constraint node.labels.region==east \
--constraint type!=devel \ --constraint node.labels.type!=devel \
nginx nginx
``` ```

View File

@ -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 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 service, transparently. Effectively, Docker acts as a load balancer for your
swarm services. Services using the routing mesh are running in _virtual IP (VIP) 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) mode_. Even a service running on each node (by means of the `--mode global`
uses the routing mesh. When using the routing mesh, there is no guarantee about flag) uses the routing mesh. When using the routing mesh, there is no guarantee
which Docker node services client requests. about which Docker node services client requests.
To bypass the routing mesh, you can start a service using _DNS Round Robin 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 (DNSRR) mode_, by setting the `--endpoint-mode` flag to `dnsrr`. You must run