Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-11-10T12:59:24.957Z
Answers: Basically the same thing is said in official docs: https://docs.docker.com/engine/swarm/services/#control-service-placement
Answers: ilvez
Answers: CC BY-SA 4.0
Answers: 2018-10-08T21:41:48.270Z
Answers: 2018-10-08T21:41:48.270Z
Answers: BMitch
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2018-10-08T21:22:36.317Z
Comments: Why can't your two services be run on the same node? There may be other ways to achieve your goal.
Comments: BMitch
Comments: CC BY-SA 4.0
Comments: 2018-10-08T21:25:08.097Z
Comments: I want different IPs for similar microservices with different parameters, so replicas won’t do. The question is interesting regardless
Comments: ivarec
Comments: CC BY-SA 4.0
Comments: 2018-10-08T21:29:09.200Z
Comments: 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.
Comments: BMitch
Comments: CC BY-SA 4.0
Comments: 2018-10-08T21:30:39.670Z
Comments: Thanks for the input! If it’s a no, it’s a useful answer regardless
Comments: ivarec
Tags: <docker><dockerfile><docker-swarm>
Title: How do I prevent service A from being placed in the same node as service B in Docker Swarm?
UserDisplayName: ivarec
ThreadText: # 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  
  
  ---
  
  