In this lesson, you will learn how to evolve your local Compose files into robust service definitions that Docker Swarm can distribute across multiple nodes.
When you run a docker-compose.yml file on a single machine, Docker handles the containers locally. However, when you move to a Swarm cluster, your definition needs to shift from a "container-centric" mindset to a "service-centric" mindset. A service is an abstraction that tells Swarm how many replicas you want, where they should run, and how to maintain their state across your cluster.
Transforming Your Definitions
To make your services "Swarm-ready," you keep your existing configuration but add orchestration instructions. When you deploy these to a Swarm manager, the engine takes your definition and ensures the desired state is reached, regardless of which physical node has available capacity.
Consider this simplified service definition:
version: '3.8'
services:
web:
image: nginx:latest
deploy:
replicas: 3
placement:
constraints:
- node.role == worker
update_config:
parallelism: 2
delay: 10s
ports:
- "80:80"
Why Orchestration Matters
The deploy block is the key differentiator here. Unlike standard Compose files that simply launch containers, the deploy key provides the Swarm manager with the instructions required for distributed management:
replicas: Tells Swarm exactly how many instances of this service must be running at all times. If a node fails, Swarm automatically spins up a new instance on another node.placement: Allows you to control distribution. You can ensure your database runs on a specific high-performance node while web services spread across multiple workers.update_config: Defines the "rolling update" strategy, allowing you to deploy new versions without taking the entire application offline.
By explicitly defining these requirements, you stop thinking about "starting a container" and start managing an "orchestrated system" that remains resilient even if individual nodes go offline. Swarm constantly compares your definition to the cluster's reality, rebalancing tasks whenever a mismatch is detected.
Key Takeaway: Moving to Swarm requires shifting from running isolated containers to declaring a desired state, where the deploy configuration allows Docker to manage the lifecycle and distribution of your services across the entire cluster.