desired service state by creating or updating a service, the orchestrator
realizes the desired state by scheduling tasks. For instance, you define a
service that instructs the orchestrator to keep three instances of an HTTP
listener running at all times. The orchestrator responds by creating three
tasks. Each task is a slot that the scheduler fills by spawning a container. The
container is the instantiation of the task. If an HTTP listener task subsequently
fails its health check or crashes, the orchestrator creates a new replica task
that spawns a new container.
A task is a one-directional mechanism. It progresses monotonically through a
series of states: assigned, prepared, running, etc. If the task fails, the
orchestrator removes the task and its container and then creates a new task to
replace it according to the desired state specified by the service.
The underlying logic of Docker's Swarm mode is a general purpose scheduler and
orchestrator. The service and task abstractions themselves are unaware of the
containers they implement. Hypothetically, you could implement other types of
tasks such as virtual machine tasks or non-containerized process tasks. The
scheduler and orchestrator are agnostic about the type of the task. However, the
current version of Docker only supports container tasks.
The diagram below shows how Swarm mode accepts service create requests and
schedules tasks to worker nodes.
### Pending services
A service may be configured in such a way that no node currently in the
swarm can run its tasks. In this case, the service remains in state `pending`.
Here are a few examples of when a service might remain in state `pending`.
> [!TIP]
> If your only intention is to prevent a service from
> being deployed, scale the service to 0 instead of trying to configure it in
> such a way that it remains in `pending`.
- If all nodes are paused or drained, and you create a service, it is