Docker Swarm: Combining Placement Constraints and Preferences

all nodes where `region` is set to `east` and `type` is not set to `devel`: ```console $ docker service create \ --name my-nginx \ --mode global \ --constraint node.labels.region==east \ --constraint node.labels.type!=devel \ nginx ``` You can also use placement constraints in conjunction with placement preferences and CPU/memory constraints. Be careful not to use settings that are not possible to fulfill. For more information on constraints, refer to the `docker service create` [CLI reference](/reference/cli/docker/service/create.md). #### Placement preferences While [placement constraints](#placement-constraints) limit the nodes a service can run on, _placement preferences_ try to place tasks on appropriate nodes in an algorithmic way (currently, only spread evenly). For instance, if you assign each node a `rack` label, you can set a placement preference to spread the service evenly across nodes with the `rack` label, by value. This way, if you lose a rack, the service is still running on nodes on other racks. Placement preferences are not strictly enforced. If no node has the label you specify in your preference, the service is deployed as though the preference were not set. > [!NOTE] > > Placement preferences are ignored for global services. The following example sets a preference to spread the deployment across nodes based on the value of the `datacenter` label. If some nodes have `datacenter=us-east` and others have `datacenter=us-west`, the service is deployed as evenly as possible across the two sets of nodes. ```console $ docker service create \ --replicas 9 \ --name redis_2 \ --placement-pref 'spread=node.labels.datacenter' \ redis:7.4.0 ``` > [!NOTE] > > Nodes which are missing the label used to spread still receive > task assignments. As a group, these nodes receive tasks in equal > proportion to any of the other groups identified by a specific label > value. In a sense, a missing label is the same as having the label with > a null value attached to it. If the service should only run on > nodes with the label being used for the spread preference, the > preference should be combined with a constraint. You can specify multiple placement preferences, and they are processed in the order they are encountered. The following example sets up a service with multiple placement preferences. Tasks are spread first over the various datacenters, and then over racks (as indicated by the respective labels): ```console $ docker service create \ --replicas 9 \ --name redis_2 \ --placement-pref 'spread=node.labels.datacenter' \ --placement-pref 'spread=node.labels.rack' \ redis:7.4.0 ``` You can also use placement preferences in conjunction with placement constraints or CPU/memory constraints. Be careful not to use settings that are not possible to fulfill. This diagram illustrates how placement preferences work:

This section delves into Docker Swarm's placement preferences, which algorithmically attempt to place tasks on suitable nodes, focusing on spreading them evenly. Placement preferences are not strictly enforced, and are ignored for global services. Examples are provided to illustrate how to spread deployments across nodes based on labels like 'datacenter' and 'rack' using the `--placement-pref` flag. The section also shows how to use multiple placement preferences together. Finally, it provides a diagram that illustrates how placement preferences spread the deployment across different nodes based on labels.