Swarm services, replicas & load balancing

In Docker Swarm, a service is the primary unit of deployment and scaling. While a regular docker run command starts a single container, a Swarm service lets you define and manage a group of containers that should be running across your Swarm cluster.

A service is a higher-level abstraction, and it comes in two main modes:

• Replicated services – Define how many copies (replicas) of a container you want.
• Global services – Run exactly one task per node (useful for logging or monitoring agents).

You can think of a Swarm service as a self-healing, load-balanced, declarative blueprint for how your containers should behave in a cluster environment.

Replicated Services

A replicated service in Swarm maintains a desired number of identical containers (tasks), and Swarm ensures that the correct number is always running. If a container crashes or a node goes down, the Swarm manager reschedules it on a healthy node.

Example:

This command tells Swarm:

• Run 3 replicas of the nginx container
• Distribute them across the available nodes
• Map port 80 on the host to port 80 on each container

Swarm will orchestrate container placement, ensure even distribution, and monitor container health. If any replica dies, Swarm will restart it automatically.

You can change the number of replicas any time:

This scales the webapp service to 5 containers. Swarm handles this gracefully — adding or removing containers without downtime.

Load Balancing in Swarm

Swarm has built-in internal load balancing that makes sure traffic is routed evenly to all service replicas.

There are two types of load balancing:

Ingress Load Balancing

• Works automatically when you publish a port with -p or --publish.
• Docker sets up a routing mesh: any node in the cluster can receive traffic on the published port and route it to the correct service replica.
• Even if a service is not running on that specific node, the node will forward traffic over the overlay network.

Example:

Even if a replica isn't running on node-1, node-1 will still accept traffic on port 8080 and forward it to a running replica via the routing mesh.

DNS-Based Load Balancing

Every Swarm service also gets its own internal DNS entry. If containers resolve the service name, Docker returns a round-robin list of IP addresses for each task (replica). This is used for inter-service communication within the Swarm.

Example:

A container querying http://webapp inside the Swarm will resolve the name to one of the running replicas of the webapp service.

Service Management

You can inspect services and their state with:

View detailed service info:

Check which nodes the tasks are running on:

This shows each replica (task), its state, and on which node it is running. If a node goes down, you’ll see Swarm rescheduling the task to another node.

Behind the Scenes: How Swarm Maintains State

Each Swarm manager stores the desired state of the cluster in a Raft-based distributed store. When you define a service with 5 replicas, the Raft consensus ensures that the state is recorded as "5 replicas." If something deviates (e.g., a node dies), the managers detect the inconsistency and bring the cluster back to the desired state.

This self-healing behaviour is one of Swarm’s biggest strengths.

Global Services

As mentioned earlier, global services run exactly one container per node, which is great for monitoring/logging tools like:

Each node runs one replica, and when a new node joins the Swarm, Swarm automatically runs a new instance of the global service on it.