Orchestration
Orchestration
Orchestration is the control plane that decides where and how containers run across a cluster. Candidates must understand the scheduler, desired-state reconciliation, and the object model that expresses intent. In Docker Swarm mode, the core objects are services (the desired state), tasks (a single running container slot), and nodes (workers and managers). A manager uses the Raft consensus protocol; a cluster needs a quorum of managers, so three managers tolerate one failure and five tolerate two. Losing quorum means the cluster can still run existing tasks but cannot accept new scheduling decisions.
Key concepts: replicated services versus global services (one task per node), rolling updates with --update-parallelism and --update-delay, rollback, health checks driving task replacement, and constraints/placement preferences. Understand that a service definition is declarative; the orchestrator continuously reconciles actual state to desired state.
Traps in questions: confusing a task with a container (a task is the scheduling unit that results in a container); assuming a manager must also run workloads (managers can be drained to act as control-plane-only nodes); thinking docker service scale changes the image (it only changes replica count); and forgetting that docker stack deploy reads a Compose file but ignores build directives, because images must already exist in a registry.
Rule of thumb: design for quorum first - always run an odd number of managers (3 or 5), and keep manager nodes out of the data path by draining them. For availability, use at least two replicas and spread them with placement constraints so a single node failure cannot take out every copy of a service.