Docker Swarm Introduction
One server runs a handful of containers well. A growing application needs more power and more safety, so teams spread containers across several machines. Docker Swarm turns a group of Docker hosts into a single cluster and manages containers across all of them with the same Docker commands you already know.
The Problem Swarm Solves
A single server creates a single point of failure. When the machine crashes, the application stops. Traffic spikes can also overload one server. A cluster solves both problems by sharing the work and replacing failed pieces.
Single server Swarm cluster +-----------+ +--------+ +--------+ +--------+ | container | | node 1 | | node 2 | | node 3 | | container | | c c | | c c | | c c | | container | +--------+ +--------+ +--------+ +-----------+ One cluster, one control point crash = outage one node fails, others continue
Key Terms
Term Meaning --------- --------------------------------------------------- Node one machine that joins the swarm Manager a node that makes decisions and accepts commands Worker a node that runs containers assigned by managers Service the desired state of an application in the swarm Task one running container belonging to a service Stack a group of services defined in one file
Think of a restaurant. The managers take orders and plan the kitchen. The workers cook. The service is the menu item, and each task is one plate being prepared.
Swarm Architecture
+-----------------------+
| Manager nodes |
| (plan and schedule) |
+-----------+-----------+
|
+--------------+--------------+
| | |
+----v---+ +----v---+ +----v---+
| Worker | | Worker | | Worker |
| task | | task | | task |
+--------+ +--------+ +--------+
Production swarms use three or five managers. An odd number lets the managers vote and keep working when one of them fails.
Creating a Swarm
Swarm mode comes built into Docker. One command starts it.
docker swarm init --advertise-addr 192.168.1.10
The output prints a join command with a secret token.
docker swarm join --token SWMTKN-1-xxxxx 192.168.1.10:2377
Run the join command on every worker machine. Each machine then appears in the cluster.
Checking the Cluster
docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS abc1 * node1 Ready Active Leader def2 node2 Ready Active ghi3 node3 Ready Active
The Leader node is the active manager. The other managers stand by to take over.
Swarm Ports
2377/tcp cluster management 7946/tcp+udp node-to-node communication 4789/udp overlay network traffic
Open these ports between swarm nodes in your firewall. Keep them closed to the public internet.
Built-In Benefits
- Desired state: you declare what should run, and Swarm keeps it true.
- Self-healing: a failed container restarts on a healthy node.
- Load balancing: requests spread across all copies of a service.
- Rolling updates: new versions replace old ones gradually.
- Encrypted traffic: nodes communicate over mutual TLS by default.
Managing Nodes
docker node promote node2 make a worker a manager docker node demote node2 make a manager a worker docker node update --availability drain node3 docker swarm leave remove this node from the swarm
Draining a node moves its containers elsewhere, so you can repair the machine without downtime.
Swarm and Kubernetes
Swarm offers a gentle learning curve and works well for small and medium workloads. Kubernetes offers more features and a larger ecosystem, and it asks for more learning time. Many teams start with Swarm to learn orchestration ideas and move to Kubernetes when their needs grow.
Common Mistakes
- Running a single manager and losing control when it fails.
- Exposing the management port to the internet.
- Forgetting that images must be reachable from every node, usually through a registry.
Real-World Scenario
A local delivery company runs its ordering website on one server. During holiday weeks, orders triple, and the server struggles. The team rents two more servers, installs Docker, and joins them into a swarm with three commands. They raise the website service from two copies to six. Orders flow smoothly through the busy week. When the rush ends, they scale back to two copies and release the extra servers.
The same swarm survives a hardware failure. One server loses its disk on a Tuesday morning, and Swarm moves the lost containers to the remaining servers in under a minute. Customers notice nothing.
Preparing Nodes
- Install the same Docker version on every machine.
- Give each machine a fixed IP address or a stable hostname.
- Open the swarm ports between the machines.
- Synchronize the clocks with a time service, because certificates depend on accurate time.
Protecting the Join Tokens
Anyone who holds a join token can add a machine to your swarm. Treat tokens like passwords. Display them with docker swarm join-token worker and rotate them with docker swarm join-token --rotate worker after staff changes or accidental exposure.