Consists of:
- multiple Docker hosts running in swarm mode
- act as managers and workers
A given host can be a:
- manager
- worker
- or perform both roles
Managers: manage membership and delegation
Workers: run Swarm services
A node is an instance of the Docker engine participating in the swarm
- Think of this as a Docker node.
- You may run one+ nodes on a single physical computer or cloud server, BUT
- ... production swarm deployments typically include Docker nodes distributed across MULTIPLE physical & cloud machines
- Submit a service definition to a manager node
- Tasks: Manager node dispatches uints of work called tasks to worker nodes
- Perform orchestration and cluster management functions required to maintain desired state of the swarm
- Elect a single leader to conduct orchestration tasks
-
receive and execute tasks dispatched from manager nodes
- an agent runs on each worker node and reports on tasks assigned to it
- worker node notifies manager node of current state of its assigned tasks
- by default, manager nodes also run servcies as worker nodes; but you can configure them to run manager tasks exclusively
A service: defintion of tasks to execute on the manager or worker nodes
- CENTRAL STRUCTURE of swarm system
- primary root of user interaction wih the swarm
- replicated services model: swarm manager distributes specific number of replica tasks among nodes based up the scale you set in the desired state.
- global services: the swarm runs one task for the service on every available node in the cluster.
-
A task carries a Docker container and the commands to run inside the container.
- atomic scheduling unit of swarm
- who: manager nodes assign tasks to worker nodes, according to number of replicas set in the service scale
- caution! once task is assigned to a node, it can't move to another node; it must run on assigned node or fail.
- ingress load balancing
- internal load balancing
For now, I'll write these steps as if I'm creating/running a single-node swarm.