DevOps PeachService → task → container
flowchart TB S["service web<br/>nginx:1.27, replicas=3"] --> T1["task web.1"] S --> T2["task web.2"] S --> T3["task web.3"] T1 --> N1["manager1"] T2 --> N2["worker1"] T3 --> N3["worker2"]
- A service describes the desired state: image, replica count, ports, networks…
- Managers split the service into tasks and schedule them on nodes. A task is the swarm's atomic scheduling unit and runs exactly one container.
- If the node running a task dies, the managers create a new task elsewhere to return to the desired state (reconciliation).
- Changing configuration (
docker service update) needs no manual restart: the swarm gradually replaces old tasks with new ones (rolling update).
Replicated and global
| Mode | Meaning |
|---|---|
replicated (default) |
Runs exactly --replicas tasks spread over the nodes |
global |
One task per node, including nodes that join later; --replicas cannot be used |
Commands
| Command | Meaning |
|---|---|
docker service create --name web --replicas 3 -p 80:80 nginx:1.27 |
Create a 3-replica service, publishing port 80 on every node (routing mesh) |
docker service ls |
List services with running/desired replicas |
docker service ps web |
Which node each web task runs on, and its state |
docker service scale web=5 |
Scale (= docker service update --replicas 5 web) |
docker service update --publish-add 8080:80 web |
Change config; the swarm replaces tasks |
docker service create --mode global --name agent busybox:1.36 top |
A global service |
docker stack deploy -c compose.yaml mystack |
Deploy several services from a Compose file |
docker service rm web |
Remove the service and all its tasks |
Like docker run, every docker service create flag goes before the image name.
Controlling rolling updates
docker service update --image nginx:1.27.1 \
--update-parallelism 1 --update-delay 10s \
--update-failure-action rollback --update-order start-first web
| Option | Effect |
|---|---|
--update-parallelism |
How many tasks are replaced at once |
--update-delay |
Wait between batches |
--update-failure-action |
pause, continue, or rollback when new tasks fail |
--update-order start-first |
Start the new task before stopping the old one, for zero downtime |
docker service rollback web returns to the previous service definition at any time.
Health and resources
A service uses the image's HEALTHCHECK (or --health-cmd), and Swarm replaces tasks that become unhealthy. --reserve-memory 256m guarantees capacity for scheduling, while --limit-memory 512m --limit-cpu 1 caps usage. A task stays Pending when no node has enough reserved resources or matches the constraints.
Publishing modes
By default, -p 80:80 uses the routing mesh: every node accepts the port and forwards to any healthy task, even on another node. --publish mode=host,target=80,published=8080 binds only on nodes that actually run a task, which suits global services and avoids the extra hop.
Secrets and configs
printf 'changeme-example' | docker secret create db_password -
docker service create --name db --secret db_password \
-e POSTGRES_PASSWORD_FILE=/run/secrets/db_password postgres:16
Secrets are encrypted in the Raft log and appear only in memory inside tasks that request them. Configs (docker config create) work the same way for non-secret files such as nginx.conf.
Stacks
docker stack deploy -c compose.yaml shop reads the deploy: section of a Compose file (replicas, update settings, placement, resources) and creates or updates every service in one step. docker service logs -f shop_web aggregates logs from all replicas, and docker stack ps shop shows every task with its node and error.