[ Placement preferences ]

Hi the docker community,

I have 3 identical servers in 3 differents sites.
They are all 3 with manager role but one is on pause availability.
Each server have a different label with these commands :

docker node update --label-add type=prodgra SRV-GRA-01
docker node update --label-add type=prodrbx SRV-RBX-01
docker node update --label-add type=monistr SRV-STR-01

On my docker-compose I try to use placements / preferences for specify a site to deploy the service and if the host will take down, swarm will reup container on the second site.

But it seems to be that preferences is totally ignored by docker stack deploy .

here is a part of my docker-compose

version: "3.6"
services:

  # Web server
  php:
    image: bitnami/php-fpm:7.4.30
    volumes:
      - ./apps/public_html:/srv_ademe:rw,cached
      - ./apps/php/php.ini-development:/opt/bitnami/php/etc/php.ini:ro
      - ./apps/php/common.conf:/opt/bitnami/php/etc/common.conf:ro
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports :
      - 9001:9000 
    networks:
      - caddy
    depends_on:
      - db
    deploy:
      placement:
        #constraints: [node.hostname == SRV-GRA-01]
        #preferences : i want that this php container is deploying on prodgra in first (if prodgra goes down then deploy on prodrbx
        preferences:
          - spread: node.labels.prodgra
          - spread: node.labels.prodrbx

Thanks for your help
Micka

I am afraid this is not how spread works.

You could use - spread: node.labels.type to spread replicas of a service across nodes that have a node label “type” with different values, though nodes without the label are considered having the label with a value of “null” as well. The order is random. You can not influence the order of the placement of the deployments.

If this affinity is a requirement for you, then swarm is not the right orchestrator for you. Kubernetes allows specifying an affinity.

Note: I am surprised your swarm cluster is even working properly, as swarm (more precisely the raft consensus it uses) requires low latency network connections amongst the nodes.