Chapter 74: DevOps Projects Part 4: Docker Scan, Network, Logging and Swarm

74.4 Project 30: Docker Swarm cluster with rolling updates

By Ravindra Bagale Last updated: 28 October 2026

Friends, Swarm turns Docker engines into a small cluster without Kubernetes. Today we init a one-node swarm, create a service with replicas, scale, roll an update, rollback a bad tag, and deploy a stack file.

What you will build in this project

swarm init on one node.
service with 2+ replicas.
scale and rolling update.
rollback + stack deploy.

1. Start from a real company story

At a Coimbatore logistics firm, releases were SSH loops across five VMs. One missed host served old code for a day.

Customers saw mixed prices. Rough cost: about ₹5 lakh in support and refunds.

Vikram moved the web tier to a Swarm service with rolling updates and rollback.

Today we practice that Swarm lab on one manager.

Picture 1: swarm init → service → scale → rolling update

Ravindra Bagale's Tip

Many students run swarm leave --force on a shared lab and wipe everyone else. Only force-leave on your own practice machine. Keep that habit.

2. Start and prepare

Step 1: docker swarm init

Why: Swarm mode turns engines into a cluster. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: swarm init. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 1: init

Type this:

docker swarm leave --force >/dev/null 2>&1; docker swarm init

You will see:

Swarm initialized: current node is now a manager

What it means: Init.

Example 2: tok tip

Type this:

echo 'Worker join token: docker swarm join-token worker'

You will see:

Worker join token: docker swarm join-token worker

What it means: Token.

Example 3: info

Type this:

docker info --format '{{.Swarm.LocalNodeState}}'

You will see:

active

What it means: Active.

Step 2: Status and node ls

Why: Need to see the manager. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: node ls. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 4: nodes

Type this:

docker node ls

You will see:

ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS

What it means: List.

Example 5: ready

Type this:

docker node ls --format '{{.Hostname}} {{.Status}} {{.Availability}}'

You will see:

... Ready Active

What it means: Ready.

Example 6: managers

Type this:

docker info --format '{{.Swarm.Managers}}'

You will see:

What it means: One manager lab.

Step 3: Create overlay network

Why: Overlay spans nodes. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: network create -d overlay. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 7: overlay

Type this:

docker network create -d overlay shop-overlay && docker network ls --filter name=shop-overlay --format '{{.Name}} {{.Driver}}'

You will see:

shop-overlay overlay

What it means: Overlay.

Example 8: attachable

Type this:

echo 'Add --attachable if one-off containers must join'

You will see:

Add --attachable if one-off containers must join

What it means: Flag.

Example 9: ls

Type this:

docker network ls -f driver=overlay

You will see:

shop-overlay

What it means: Listed.

3. Build the main pieces

Step 4: docker service create

Why: Services replace raw run. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: service create. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 10: svc

Type this:

docker service rm web >/dev/null 2>&1; docker service create --name web --replicas 2 --network shop-overlay -p 8092:80 nginx:1.27-alpine

You will see:

overall progress: 2 out of 2 tasks

What it means: Created.

Example 11: ps

Type this:

docker service ps web --format '{{.Name}} {{.CurrentState}}'

You will see:

web.1 Running
web.2 Running

What it means: Tasks.

Example 12: ls

Type this:

docker service ls --format '{{.Name}} {{.Replicas}} {{.Ports}}'

You will see:

web 2/2 *:8092->80/tcp

What it means: Service.

Step 5: Scale replicas

Why: Scale is one command. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: service scale. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 13: scale

Type this:

docker service scale web=3

You will see:

web scaled to 3

What it means: Scaled.

Example 14: ps3

Type this:

docker service ps web --format '{{.Name}} {{.CurrentState}}' | wc -l

You will see:

What it means: Three tasks.

Example 15: curl

Type this:

curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8092/

You will see:

What it means: VIP works.

Step 6: Rolling update

Why: Updates must roll. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: service update. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 16: update

Type this:

docker service update --image nginx:1.27-alpine --update-parallelism 1 --update-delay 5s web

You will see:

verify: Waiting X seconds...

What it means: Rolling.

Example 17: ps

Type this:

docker service ps web --format '{{.DesiredState}} {{.CurrentState}}' | head -5

You will see:

Running ...

What it means: States.

Example 18: why delay

Type this:

echo 'update-delay gives time to watch health between batches'

You will see:

update-delay gives time to watch health between batches

What it means: Why.

4. Automate and verify

Step 7: Rollback

Why: Rollback saves bad releases. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: service rollback. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 19: bad

Type this:

docker service update --image nginx:1.27-not-a-real-tag web || echo 'update_failed_expected'

You will see:

update_failed_expected

What it means: Bad tag.

Example 20: rollback

Type this:

docker service rollback web

You will see:

rollback: verify...

What it means: Rollback.

Example 21: ok

Type this:

docker service ps web --filter desired-state=running --format '{{.Image}}' | head -1

You will see:

nginx:1.27-alpine

What it means: Restored.

Step 8: Service logs

Why: Logs per service. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: service logs. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 22: logs

Type this:

docker service logs web --tail 3

You will see:

... GET / ...

What it means: Logs.

Example 23: follow

Type this:

echo 'docker service logs -f web'

You will see:

docker service logs -f web

What it means: Follow.

Example 24: task

Type this:

docker service ps web -q | head -1 | xargs -I{} docker inspect -f '{{.Status.State}}' {}

You will see:

running

What it means: Task.

Step 9: Drain a node tip

Why: Drain before maintenance. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: node update --availability drain. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 25: drain tip

Type this:

echo 'docker node update --availability drain <node>'

You will see:

docker node update --availability drain <node>

What it means: Drain.

Example 26: why

Type this:

echo 'Drain moves tasks away before you reboot a worker'

You will see:

Drain moves tasks away before you reboot a worker

What it means: Why.

Example 27: active

Type this:

echo 'docker node update --availability active <node>'

You will see:

docker node update --availability active <node>

What it means: Back.

5. Harden and accept

Step 10: Stack deploy compose

Why: Stacks use compose files. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: stack deploy. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 28: stack file

Type this:

printf '%s\n' 'version: "3.8"' 'services:' '  web:' '    image: nginx:1.27-alpine' '    ports: ["8093:80"]' '    deploy:' '      replicas: 2' '      update_config:' '        parallelism: 1' '        delay: 5s' 'networks: [shopnet]' 'networks:' '  shopnet:' '    driver: overlay' > /tmp/swarm-stack.yaml && wc -l /tmp/swarm-stack.yaml

You will see:

14 /tmp/swarm-stack.yaml

What it means: Stack file.

Example 29: deploy

Type this:

docker stack deploy -c /tmp/swarm-stack.yaml shop && docker stack services shop

You will see:

web ... 2/2

What it means: Deployed.

Example 30: rm stack later

Type this:

echo 'docker stack rm shop'

You will see:

docker stack rm shop

What it means: Cleanup cmd.

Step 11: Leave swarm tip

Why: Labs must clean up. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: swarm leave. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 31: leave tip

Type this:

echo 'Lab cleanup: docker stack rm shop; docker service rm web; docker swarm leave --force'

You will see:

Lab cleanup: docker stack rm shop; docker service rm web; docker swarm leave --force

What it means: Leave.

Example 32: care

Type this:

echo 'leave --force on a manager destroys the swarm; use only on lab machines'

You will see:

leave --force on a manager destroys the swarm; use only on lab machines

What it means: Care.

Example 33: k8s note

Type this:

echo 'Swarm is fine for small fleets; many teams choose Kubernetes next'

You will see:

Swarm is fine for small fleets; many teams choose Kubernetes next

What it means: Context.

Step 12: Acceptance checklist

Why: Vikram signs off when scale and rollback work. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if logging and the swarm are healthy today.

What: All green. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams centralize logs and roll out services.

Example 34: replicas

Type this:

docker service ls --format '{{.Name}} {{.Replicas}}' | head

You will see:

web 3/3 or stack web 2/2

What it means: Replicas.

Example 35: curl

Type this:

curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8092/; echo; curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8093/

You will see:

200
200

What it means: Both.

Example 36: Sign-off

Type this:

echo 'Vikram: PASS'

You will see:

Vikram: PASS

What it means: Done.

Check yourself

Q1. Who moved logistics to Swarm?

Vikram

Q2. Init command?

docker swarm init

Q3. Scale command?

docker service scale

Q4. Rollback command?

docker service rollback

Q5. Stack command?

docker stack deploy

Q6. Lab publish port?

8092

Friends, you scaled and rolled back a Swarm service. Did you understand? Let us try it once more. Add a second stack service for an API and put both on one overlay network.

Lab: try at home

swarm init.
Create overlay and service.
Scale to 3.
Bad update then rollback.
stack deploy a compose file.

Recap

Managers schedule; workers run tasks.
Overlay networks span nodes.
update-delay slows batches.
rollback undoes a bad image.
Stacks package multi-service apps.

Lab

Finish all four projects on one practice machine.
Keep a notebook of CRITICAL counts before and after base bumps.
Never leave swarm leave --force on a shared lab.
After each project, write one paragraph: what broke and how you fixed it.
Confirm logging rotation options with docker inspect.

Practice task

Pick the Trivy gate and the Swarm rollback. Prove both on a fresh image tag.

Ravindra Bagale's Tip

Do Trivy before you push. Prefer user-defined networks. Set max-size on every long-running service.

In short

Fail CI on CRITICAL.
User-defined bridges give DNS names.
json-file needs max-size.
Swarm update-delay slows batches.
rollback undoes a bad image.
Stacks package multi-service apps.