Docker Swarm Basics

The plain-language idea

Swarm is Docker's own built-in orchestrator — the same docker binary you already use, extended with commands that turn a group of machines into a cluster and run containers across it. It implements the same four capabilities the earlier orchestration-basics lesson named in the abstract (scheduling, self-healing, scaling, service discovery), using Docker's existing vocabulary instead of a separate platform's.

docker swarm init turns the current machine into a manager node — the node that makes scheduling decisions and holds the cluster's state. Other machines join as either additional managers (for high availability) or worker nodes (which only run containers, no cluster-management role). Once a swarm exists, docker service create replaces docker run as the way you launch something: a service declares an image and a desired replica count, and Swarm's scheduler decides which nodes actually run which replicas, restarting any that fail — the same self-healing behavior the orchestration lesson described generally, running here specifically. docker stack deploy goes one level further, taking a Compose-file-compatible YAML format and deploying an entire multi-service application as one unit — genuinely reusing the same file format from earlier in this track, extended with Swarm-specific fields like deploy: replicas:.

See it in a real thing: from Compose to a stack

# docker-stack.yml — same shape as docker-compose.yml, plus a deploy: block
services:
  api:
    image: myapp:latest
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
  db:
    image: postgres:16

docker swarm init
docker stack deploy -c docker-stack.yml myapp
docker service ls

This is deliberately close to the Compose file from earlier in this track — the same services: shape, the same idea of declaring what should run. The deploy: block is what's new: it's Swarm-specific, and it's exactly the fleet-scale information Compose never needed, because Compose only ever ran on one host. docker service ls then shows something Compose has no equivalent of — replica counts actually achieved versus desired, across however many nodes the swarm has.

What people usually miss

Watch out

• A single manager node is a single point of failure for cluster management — if it goes down, the cluster keeps running whatever was already scheduled, but no new scheduling decisions can be made until a manager is available again. Real HA setups run multiple manager nodes specifically to avoid this.
• Manager HA relies on Raft consensus, conceptually the same idea used elsewhere in distributed systems — an odd number of managers (3 or 5, not 2 or 4) vote on cluster state changes, and the cluster only makes progress while a majority of managers are reachable. This is why manager counts are always odd: an even number adds nodes without improving the fault tolerance the odd number already provided.
• Worker nodes can't make scheduling decisions even if a manager is unreachable. A worker only runs whatever it was already assigned — it doesn't promote itself or start making its own decisions, which is exactly why losing manager quorum stalls new scheduling even though existing containers keep running.
• docker stack deploy isn't a plain docker-compose.yml runner — some Compose fields (like build:) are ignored in Swarm mode, since Swarm schedules pre-built images across a fleet rather than building on the fly the way local Compose does. The file format overlaps, but the two aren't fully interchangeable.

Why this matters in interviews

"Why would you choose Swarm over Kubernetes, or vice versa?" is a genuine judgment question, and a strong answer doesn't default to "Kubernetes is just better" — it names the real tradeoff (Swarm's simplicity and built-in familiarity for a Docker-fluent team versus Kubernetes' much larger ecosystem and operational surface) and reasons about fit for a specific team's scale, rather than treating orchestrator choice as a popularity contest. It's also a natural, concrete example the moment an interviewer asks for one after the general orchestration-basics discussion.