<p>At present the answer is "no", swarm mode does not support affinity or anti-affinity between a service and other containers/services running on a node. However, depending on your goal there are other options.</p>

<p>One option is to reserve resources like CPU and memory for your container. This will ensure two resource intensive applications do not schedule themselves on the same node if there are insufficient resources.</p>

<p>The other option, as you've mentioned, is to use labels and constraints. You can give the same label to multiple nodes, which is often done to specify a type of node, or assign nodes to a specific team/project/environment.</p>

<p>Both of these options will reduce your fault tolerance, particularly if you assign a label to one or a small handful of nodes. If those nodes with the label go down, docker will be unable to reschedule your service on another node.</p>

CC BY-SA 4.0
2021-11-10T12:59:24.957Z
Basically the same thing is said in official docs: https://docs.docker.com/engine/swarm/services/#control-service-placement
ilvez
CC BY-SA 4.0
2018-10-08T21:41:48.270Z
2018-10-08T21:41:48.270Z
BMitch
<p>From the docs, I could only find information about placement restrictions based on <strong>node</strong> attributes, likes labels and its role. However, I couldn't find how to configure placement based on the <strong>services already running</strong> on a given node.</p>

<p>How can I do that?</p>

CC BY-SA 4.0
2018-10-08T21:22:36.317Z
Why can't your two services be run on the same node? There may be other ways to achieve your goal.
BMitch
CC BY-SA 4.0
2018-10-08T21:25:08.097Z
I want different IPs for similar microservices with different parameters, so replicas won’t do. The question is interesting regardless
ivarec
CC BY-SA 4.0
2018-10-08T21:29:09.200Z
Each container gets it's own private internal IP by default, even when on the same host. And if you publish with ingress, a port will be opened on every host of the network. The answer to the question asked is "no" so I'm trying to see if there's a way to solve the underlying problem.
BMitch
CC BY-SA 4.0
2018-10-08T21:30:39.670Z
Thanks for the input! If it’s a no, it’s a useful answer regardless
ivarec
<docker><dockerfile><docker-swarm>
How do I prevent service A from being placed in the same node as service B in Docker Swarm?
ivarec
# How do I prevent service A from being placed in the same node as service B in Docker Swarm?

(Asked by: username_0 on 2018-10-08)

From the docs, I could only find information about placement restrictions based on **node** attributes, likes labels and its role. However, I couldn't find how to configure placement based on the **services already running** on a given node.

How can I do that?

**Tags:** docker, dockerfile, docker-swarm

> **Comments:**
> **username_1**: Why can't your two services be run on the same node? There may be other ways to achieve your goal.  
> **username_0**: I want different IPs for similar microservices with different parameters, so replicas won’t do. The question is interesting regardless  
> **username_1**: Each container gets it's own private internal IP by default, even when on the same host. And if you publish with ingress, a port will be opened on every host of the network. The answer to the question asked is "no" so I'm trying to see if there's a way to solve the underlying problem.  
> **username_0**: Thanks for the input! If it’s a no, it’s a useful answer regardless  

---

## 1 answers

### Answer by username_1 on 2018-10-08. Score: 2 | Accepted answer

At present the answer is "no", swarm mode does not support affinity or anti-affinity between a service and other containers/services running on a node. However, depending on your goal there are other options.

One option is to reserve resources like CPU and memory for your container. This will ensure two resource intensive applications do not schedule themselves on the same node if there are insufficient resources.

The other option, as you've mentioned, is to use labels and constraints. You can give the same label to multiple nodes, which is often done to specify a type of node, or assign nodes to a specific team/project/environment.

Both of these options will reduce your fault tolerance, particularly if you assign a label to one or a small handful of nodes. If those nodes with the label go down, docker will be unable to reschedule your service on another node.

> **Comments:**
> **username_2**: Basically the same thing is said in official docs: https://docs.docker.com/engine/swarm/services/#control-service-placement  

---

