Answers: <p>A manager is able to run containers just as workers do. To prevent workloads from running on the manager, you need to include a constraint. This is different from the kubernetes model where the managers are tainted and you include a toleration to run on managers.</p>
  <pre><code>version: &quot;3.4&quot;
  services:
  
    redis:
      image: redis:alpine
      ports:
        - &quot;6379&quot;
      networks:
        - frontend
      deploy:
        replicas: 1
        update_config:
          parallelism: 2
          delay: 10s
        restart_policy:
          condition: on-failure
        # add the below constraint
        placement:
          constraints:
            - &quot;node.role==worker&quot;
  
  networks:
    frontend:
  
  volumes:
    db-data:
  </code></pre>
  <p>For more on the placement policies and constraints, see:</p>
  <ul>
  <li><a href="https://docs.docker.com/compose/compose-file/compose-file-v3/#placement" rel="nofollow noreferrer">https://docs.docker.com/compose/compose-file/compose-file-v3/#placement</a></li>
  <li><a href="https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints---constraint" rel="nofollow noreferrer">https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints---constraint</a></li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2021-09-26T09:21:47.137Z
Answers: I see, thanks, However in that case can we have 2 replicas 1 on manager and 1 on worker ?
Answers: Chang Zhao
Answers: CC BY-SA 4.0
Answers: 2021-09-26T12:21:37.280Z
Answers: @ChangZhao you'd need different constraints for that. But consider what you want to happen if a node goes down when you define those constraints. And with only one manager, if the manager itself goes down, no tasks will be rescheduled.
Answers: BMitch
Answers: CC BY-SA 4.0
Answers: 2021-09-26T00:56:21.007Z
Answers: 2021-09-26T00:56:21.007Z
Answers: BMitch
Body: <p>This is my docker-stackk.yaml file.</p>
  <pre><code># cat docker-stack.yml 
  version: &quot;3.4&quot;
  services:
  
    redis:
      image: redis:alpine
      ports:
        - &quot;6379&quot;
      networks:
        - frontend
      deploy:
        replicas: 1
        update_config:
          parallelism: 2
          delay: 10s
        restart_policy:
          condition: on-failure
  
  networks:
    frontend:
  
  volumes:
    db-data:
  </code></pre>
  <p>I did not specified any constraint.</p>
  <pre><code># docker node ls
  ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
  snbsjfcg8eu6w88oyinsaa2q0 *   infinity   Ready     Active         Reachable        20.10.8
  bi2iblsfma9dno4thvcpetc29     rockpi     Ready     Active         Leader           20.10.8
  d5nk1bgdpmo05u1pdlbtxppem     rockpix    Ready     Active                          19.03.8
  </code></pre>
  <p>if you see above rockpix is worker node. and infinity is manager.</p>
  <p>but when I started the stack the container started on manager node instead of worker node.</p>
  <pre><code># docker stack ps redis-stack
  ID             NAME                  IMAGE          NODE       DESIRED STATE   CURRENT STATE           ERROR     PORTS
  zvd9dyx10ro9   redis-stack_redis.1   redis:alpine   infinity   Running         Running 2 minutes ago  
  </code></pre>
  
Tags: <docker><docker-swarm>
Title: Why my docker container is running on swarm manager node instead of worker?
UserDisplayName: Chang Zhao
ThreadText: # Why my docker container is running on swarm manager node instead of worker?
  
  (Asked by: username_0 on 2021-09-25)
  
  This is my docker-stackk.yaml file.
  
  ```
  # cat docker-stack.yml 
  version: "3.4"
  services:
  
    redis:
      image: redis:alpine
      ports:
        - "6379"
      networks:
        - frontend
      deploy:
        replicas: 1
        update_config:
          parallelism: 2
          delay: 10s
        restart_policy:
          condition: on-failure
  
  networks:
    frontend:
  
  volumes:
    db-data:
  
  ```
  
  I did not specified any constraint.
  
  ```
  # docker node ls
  ID                            HOSTNAME   STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
  snbsjfcg8eu6w88oyinsaa2q0 *   infinity   Ready     Active         Reachable        20.10.8
  bi2iblsfma9dno4thvcpetc29     rockpi     Ready     Active         Leader           20.10.8
  d5nk1bgdpmo05u1pdlbtxppem     rockpix    Ready     Active                          19.03.8
  
  ```
  
  if you see above rockpix is worker node. and infinity is manager.
  
  but when I started the stack the container started on manager node instead of worker node.
  
  ```
  # docker stack ps redis-stack
  ID             NAME                  IMAGE          NODE       DESIRED STATE   CURRENT STATE           ERROR     PORTS
  zvd9dyx10ro9   redis-stack_redis.1   redis:alpine   infinity   Running         Running 2 minutes ago  
  
  ```
  
  **Tags:** docker, docker-swarm
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-09-26. Score: 1 | Accepted answer
  
  A manager is able to run containers just as workers do. To prevent workloads from running on the manager, you need to include a constraint. This is different from the kubernetes model where the managers are tainted and you include a toleration to run on managers.
  
  ```
  version: "3.4"
  services:
  
    redis:
      image: redis:alpine
      ports:
        - "6379"
      networks:
        - frontend
      deploy:
        replicas: 1
        update_config:
          parallelism: 2
          delay: 10s
        restart_policy:
          condition: on-failure
        # add the below constraint
        placement:
          constraints:
            - "node.role==worker"
  
  networks:
    frontend:
  
  volumes:
    db-data:
  
  ```
  
  For more on the placement policies and constraints, see:
  
  * <https://docs.docker.com/compose/compose-file/compose-file-v3/#placement>
  * <https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints---constraint>
  
  > **Comments:**
  > **username_0**: I see, thanks, However in that case can we have 2 replicas 1 on manager and 1 on worker ?  
  > **username_1**: @username_0 you'd need different constraints for that. But consider what you want to happen if a node goes down when you define those constraints. And with only one manager, if the manager itself goes down, no tasks will be rescheduled.  
  
  ---
  
  