18.2 Docker Swarm

Docker Swarm is Docker's own built-in container orchestration mode, providing multi-host clustering, service replication, overlay networking, and rolling updates directly through the same Docker CLI already used for single-host work, positioned as a meaningfully simpler alternative to Kubernetes for teams whose orchestration needs do not warrant Kubernetes's considerably greater complexity.

Initializing a swarm

A swarm cluster begins with a single manager node, with additional manager and worker nodes joining afterward using a token generated during initialization:

docker swarm init --advertise-addr 192.168.1.10

docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377

Running the join command on additional hosts brings them into the cluster as workers (or, with an additional flag, as managers), after which the cluster can be managed entirely through commands issued from any manager node, without needing to individually configure or address each worker node separately.

Services as the core deployment unit

Rather than running individual containers directly, Swarm mode introduces services, a declarative definition of how many replicas of a given image should run across the cluster, with Swarm itself responsible for scheduling those replicas onto available nodes and maintaining the desired replica count automatically:

docker service create --name my-api --replicas 3 -p 80:80 my-api:1.4.2

docker service scale my-api=5

If a node running one of these replicas fails, Swarm automatically reschedules that replica onto a different, healthy node to maintain the declared replica count, which is the core self-healing behavior that distinguishes Swarm-managed services from individually run, standalone containers.

Stacks as the multi-service deployment unit

A stack, defined using the same Compose file format already familiar from single-host Compose usage, deploys an entire multi-service application across the swarm cluster in one command, extending the same declarative, file-based approach to a genuinely multi-host context:

docker stack deploy -c docker-compose.yml my-stack

docker stack services my-stack

This reuse of the Compose file format is one of Swarm's most practically valuable properties: a team already comfortable with Compose for local development and single-host deployment can extend much of that same knowledge and file format directly into a genuine, multi-host production cluster.

Overlay networking across hosts

Swarm provides an overlay network driver allowing containers on different physical hosts within the cluster to communicate as though they were on the same local network, with the same service-name-based DNS resolution familiar from single-host Compose usage extended transparently across the entire cluster:

docker network create --driver overlay my-overlay-network

services:
  api:
    networks:
      - my-overlay-network

This means a service running on one physical node can reach a dependency running on an entirely different node using exactly the same service-name resolution that would work within a single-host Compose stack, with the actual cross-host networking handled transparently underneath.

Rolling updates with built-in configuration

Swarm services support declarative rolling update configuration directly, controlling how many replicas update at once and how long to pause between batches, without needing a separate deployment tool or script to implement this behavior:

docker service update --image my-api:1.5.0 --update-parallelism 1 --update-delay 10s my-api

This built-in rolling update mechanism, combined with the ability to roll back to a previous service definition directly, provides a meaningful share of what a more complex orchestrator like Kubernetes offers, through commands considerably simpler to learn and operate.

When Swarm is the appropriate choice

Swarm fits well for teams that need genuine multi-host orchestration, automatic rescheduling on node failure, rolling updates, but whose actual scale and complexity needs do not warrant the considerably larger operational investment Kubernetes requires, custom resource definitions, a more elaborate networking and storage ecosystem, a steeper overall learning curve:

docker stack deploy -c docker-compose.yml my-stack

A small-to-medium team running a handful of services across a handful of hosts, already comfortable with Compose, often finds Swarm provides everything genuinely needed without the proportionally much larger investment Kubernetes would require for the same actual orchestration needs.

Current ecosystem position and maintenance considerations

Swarm's ecosystem momentum and broader community tooling support have not kept pace with Kubernetes's dominant position in container orchestration, which is worth factoring into a long-term platform decision, since the availability of third-party tooling, community knowledge, and hiring pool familiarity skews considerably more toward Kubernetes at this point; this does not mean Swarm is unmaintained or unsuitable, but it does mean evaluating realistically what ecosystem support actually exists for whichever platform a team commits to long-term.

docker swarm ca --rotate

Docker itself continues to maintain and ship Swarm mode as a core feature, which means it remains a genuinely viable, supported choice, just one operating within a smaller surrounding ecosystem than Kubernetes's considerably larger one.

Common mistakes

• Adopting Kubernetes by default for orchestration needs that Swarm would address with considerably less operational complexity and learning investment.
• Underestimating the genuine multi-host capability Swarm provides, mistakenly assuming any real orchestration need automatically requires Kubernetes specifically.
• Not accounting for Swarm's smaller surrounding ecosystem, third-party tooling, community knowledge, hiring pool familiarity, when making a long-term platform commitment.
• Treating Swarm's Compose file reuse as merely a convenience rather than recognizing it as a genuine, practical advantage for teams already invested in Compose-based workflows.
• Assuming Swarm is deprecated or unmaintained, when Docker continues to ship and support it as a core feature, just within a comparatively smaller ecosystem than Kubernetes.

Docker Swarm remains a genuinely viable, considerably simpler orchestration choice for teams whose actual multi-host needs, replica management, automatic rescheduling, rolling updates, do not warrant Kubernetes's substantially larger operational and learning investment, and its direct reuse of the familiar Compose file format makes it a particularly natural extension for any team already comfortable with Compose-based single-host workflows.