Stacks rather than compose, constraints, replicas, rolling updates & self healing

A Docker Stack is a higher-level abstraction in Docker used to deploy and manage a group of services on a Docker Swarm cluster. It is the Swarm-native way of orchestrating multi-container applications — similar to Docker Compose — but optimized for production and multi-node clusters.

Stacks allow you to define entire applications (services, networks, volumes, secrets, configs) in a single YAML file and deploy them across a distributed set of nodes.

Docker Compose vs Docker Stack

Not all Compose features work with Docker Stack (Swarm mode):

• build: is limited or unsupported (use docker build beforehand).
• depends_on: is ignored.
• container_name: is ignored (since services get auto-named).
• Volumes must be defined properly; anonymous volumes behave differently.
• healthcheck: behaviour may be limited in Swarm context.

Docker Stack YAML File

Docker Stack uses the same docker-compose.yml format, but not every Compose option is supported (e.g., depends_on, build in Swarm mode is limited).

version: '3.8'​services:  web:    image: myapp:latest    deploy:      replicas: 3      restart_policy:        condition: on-failure      placement:        constraints: [node.role == worker]    ports:      - "80:80"​  redis:    image: redis:alpine​networks:  default:    driver: overlay

Deploying a stack:

docker stack deploy -c docker-compose.yml mystack

This command will:

• Create services from your YAML file.
• Deploy them across the Swarm nodes.
• Manage networks, volumes, secrets as Swarm-scoped resources.

Managing stacks

Show all stacks running in the Swarm:

docker stack ls

List all tasks (containers) running under that stack:

docker stack services mystack

List services running in the stack:

docker stack services mystack

Remove the entire stack (services, networks, etc):

docker stack rm mystack

Updating a stack

The best way to update a stack, is to update the compose file with any changes, and then redeploy the stack. That way the compose file will always be correct for the stack that is deployed. This is the prefered approach over making individual updates via the CLI as it means looking at the compose file is the current state and one source of truth. So make changes to that and redeploy.

You can make changes to your Compose file and then run:

docker stack deploy -c docker-compose.yml mystack

Docker will:

• Compare the changes,
• Apply rolling updates (where possible),
• Avoid downtime (if correctly configured).

Stack Compose File Syntax for Deployments

When using Docker Stack, service-level deployment settings go under the deploy: key in your docker-compose.yml file. This is Swarm-specific and not supported by standard docker compose up.

Basic structure:

services:  web:    image: myapp:latest    deploy:      replicas: 3      placement:        constraints:          - node.role == worker      resources:        limits:          cpus: '0.50'          memory: 512M        reservations:          cpus: '0.25'          memory: 256M      restart_policy:        condition: on-failure        delay: 5s        max_attempts: 3        window: 30s

Replicas - defines the number of instances of the service to run. Swarm will spread them across the cluster as needed:

deploy:  replicas: 5

placement.constraints - control where services run based on node labels, roles, or system attributes:

deploy:  placement:    constraints:      - node.role == worker       # Only on worker nodes      - node.labels.type == api   # Custom label

Note: you can add labels to nodes by calling: docker node update --label-add type=api <node-id>.

Define resource limits and reservations:

deploy:  resources:    limits:      cpus: '0.50'       # Max CPU usage (in cores)      memory: 512M       # Max memory    reservations:      cpus: '0.25'       # Minimum guaranteed CPU      memory: 256M       # Minimum guaranteed memory

Limits enforce caps; reservations help Swarm schedule based on available resources.

Define how Swarm restarts a failed container:

deploy:  restart_policy:    condition: on-failure    delay: 10s    max_attempts: 5    window: 60s

Customise rolling update behaviour:

deploy:  update_config:    parallelism: 2         # Update 2 services at a time    delay: 10s             # Wait 10s between each batch    failure_action: pause  # Pause on error (or continue/rollback)    monitor: 30s           # Monitor health for 30s

Configures rollback behavior if an update fails:

deploy:  rollback_config:    parallelism: 1    delay: 5s

Global - Instead of specifying replicas, you can run one instance per node:

deploy:  mode: global

All these combined as an example:

version: '3.8'​services:  app:    image: myorg/myapp:latest    deploy:      replicas: 4      placement:        constraints:          - node.labels.env == prod      resources:        limits:          cpus: '0.7'          memory: 1G        reservations:          cpus: '0.3'          memory: 512M      restart_policy:        condition: on-failure        delay: 5s        max_attempts: 2      update_config:        parallelism: 2        delay: 10s      rollback_config:        parallelism: 1        delay: 5s