A worker is the execution side of an orchestrator: a component running on a physical or virtual machine that accepts assigned tasks and runs them as Docker containers. It keeps local task state, exposes machine and task information, and supplies the manager with the operational facts needed to place work. section 1.5.5 section 4.1
Figure 4.3 Our worker will be made up of these five components, but this chapter will focus only on the runtime, task queue, and task DB.
A worker combines a runtime, task queue, task database, metrics, and an API. The runtime, queue, and database form the core execution path; the API and metrics support manager interaction. section 4.1
The worker has a deliberately narrow scope. It knows the tasks assigned to itself, not the other workers in the cluster. The manager has the broader cluster view, selects a worker through scheduling, sends work to it, and periodically reconciles its own task records with the worker’s reported state. section 1.9.3 section 7.3.3
A minimal worker implementation centers on explicit local state and a small task-processing loop:
- Store tasks in a UUID-keyed map and track their count; use a FIFO queue for work received from the manager. section 2.2
- Remove a task from the queue, inspect its state, and start or stop it as appropriate. section 2.2 section 4.8
- Delegate container operations to a Docker wrapper rather than embedding SDK calls in StartTask and StopTask. section 4.2 section 4.8
- Collect worker statistics so the manager can judge CPU, memory, and disk availability when scheduling incoming tasks. section 6.0
Start, then stop a container task
Create a worker with an empty queue and task map. Add a Scheduled task using the strm/helloworld-http image, then run the processing loop to start its container. Save the returned container ID, change the task state to Completed, enqueue it again, and run the loop to stop and remove that container. section 4.7
Multiple workers let an application run on separate machines, spreading requests and preserving service when one worker machine fails. A worker-component crash is different: running containers continue, but the manager cannot place new work, stop tasks, or obtain task state until communication returns. Recovery therefore requires care; treating every unreachable worker and task as dead can create duplicate or unexpected application state. section 4.1 section 9.3.4
The same manager-worker pattern extends beyond container orchestration. A manager can coordinate a pool of workers for application tasks, while workflow systems use a related arrangement to automate sequences of well-defined operational steps. section 13.2
