Swarm Operations

Docker Swarm Operations: The Restaurant Kitchen Story 🍳

Imagine you’re the head chef of a magical restaurant chain. You have kitchens (nodes) all over the city, and you need to manage all your cooks (containers) smoothly. That’s Docker Swarm Operations!

The Big Picture

Docker Swarm is like being the boss of many kitchens at once. Swarm Operations are your superpowers to:

• Update recipes without closing the restaurant
• Fix mistakes quickly
• Keep secret ingredients safe
• Share cooking instructions everywhere
• Organize all kitchens together
• Decide which kitchen cooks what
• Manage your team of kitchens

1. Rolling Updates 🔄

What Is It?

Imagine you want to change a recipe. But you can’t close all kitchens at once—customers are hungry! A rolling update changes one kitchen at a time while others keep cooking.

Simple Example

You have 5 pizza kitchens. You want to add pineapple to the menu:

docker service update \
  --image pizza:v2 \
  --update-parallelism 2 \
  --update-delay 10s \
  my-pizza-service

What happens:

1. Kitchen 1 and 2 get the new recipe
2. Wait 10 seconds
3. Kitchen 3 and 4 get updated
4. Wait 10 seconds
5. Kitchen 5 gets updated
6. Done! No customer waited!

graph TD
    A["Start Update"] --> B["Update 2 containers"]
    B --> C["Wait 10 seconds"]
    C --> D["Update 2 more"]
    D --> E["Wait 10 seconds"]
    E --> F["Update last one"]
    F --> G["All Done!"]

Key Options

2. Service Rollback ⏪

What Is It?

Oops! The new pineapple pizza is terrible. Everyone’s complaining! Rollback is your “undo” button—go back to the previous good recipe instantly.

Simple Example

docker service rollback my-pizza-service

That’s it! One command and you’re back to the old recipe.

Automatic Rollback

You can tell Docker: “If something breaks, fix it yourself!”

docker service update \
  --image pizza:v2 \
  --update-failure-action rollback \
  my-pizza-service

Now if containers keep crashing, Docker automatically goes back to the working version.

graph TD
    A["New Update"] --> B{Containers Healthy?}
    B -->|Yes| C["Keep New Version"]
    B -->|No| D["Automatic Rollback"]
    D --> E["Back to Old Version"]
    E --> F["Everything Works Again!"]

3. Swarm Secrets 🔐

What Is It?

Secrets are like your super-secret ingredient recipes. You don’t want competitors to know! Secrets store sensitive data like:

• Passwords
• API keys
• Certificates

Docker keeps them encrypted and safe.

Simple Example

Step 1: Create a secret

echo "my-super-password" | \
  docker secret create db_password -

Step 2: Use it in a service

docker service create \
  --name my-app \
  --secret db_password \
  my-image

Step 3: Inside the container

The secret appears as a file at /run/secrets/db_password

cat /run/secrets/db_password
# Output: my-super-password

Why Secrets Are Special

4. Swarm Configs 📋

What Is It?

Configs are like your cooking instructions that aren’t secret. Things like:

• Configuration files
• Settings
• Templates

They’re similar to secrets, but for non-sensitive data.

Simple Example

Step 1: Create a config

docker config create nginx_conf nginx.conf

Step 2: Use it in a service

docker service create \
  --name web \
  --config source=nginx_conf,target=/etc/nginx/nginx.conf \
  nginx

Now every web container gets the same nginx.conf file!

Secrets vs Configs

5. Swarm Stacks 📚

What Is It?

A stack is like a complete meal plan for your restaurant. Instead of creating services one by one, you describe everything in one file and deploy it all together!

Simple Example

Create docker-compose.yml:

version: "3.8"
services:
  web:
    image: nginx
    ports:
      - "80:80"
    deploy:
      replicas: 3

  api:
    image: my-api
    deploy:
      replicas: 2
    secrets:
      - db_password

secrets:
  db_password:
    external: true

Deploy the whole stack:

docker stack deploy -c docker-compose.yml myapp

What you get:

• 3 web containers
• 2 api containers
• All connected and configured!

graph TD
    A["docker-compose.yml"] --> B["docker stack deploy"]
    B --> C["Web Service x3"]
    B --> D["API Service x2"]
    B --> E["Network Created"]
    B --> F["Secrets Attached"]

Stack Commands

6. Service Placement 📍

What Is It?

Sometimes you want specific dishes cooked in specific kitchens. Maybe:

• The sushi chef is only in Kitchen A
• Heavy cooking needs the big oven in Kitchen B

Placement tells Docker where to run your containers.

Simple Example: Labels

Step 1: Label your nodes

docker node update \
  --label-add zone=east \
  node1

Step 2: Place service on labeled nodes

docker service create \
  --name east-api \
  --constraint node.labels.zone==east \
  my-api

Now east-api only runs on nodes with zone=east!

Placement Strategies

Constraint: “Only here”

--constraint node.labels.zone==east
--constraint node.role==worker
--constraint node.hostname==server1

Preference: “Prefer here, but anywhere is OK”

--placement-pref spread=node.labels.zone

This spreads containers evenly across zones!

graph TD
    A["Service: 6 replicas"] --> B["Zone East: 3 containers"]
    A --> C["Zone West: 3 containers"]

7. Swarm Node Management 🖥️

What Is It?

Managing your kitchens! You can:

• Add new kitchens
• Remove old ones
• Promote workers to managers
• Put kitchens on vacation (drain)

Adding Nodes

On the manager, get the join token:

docker swarm join-token worker

On the new node, join:

docker swarm join \
  --token SWMTKN-xxx \
  192.168.1.1:2377

Node Roles

Promote worker to manager:

docker node promote worker1

Demote manager to worker:

docker node demote manager2

Drain Mode

When a kitchen needs cleaning (maintenance), drain it:

docker node update --availability drain node1

• All containers move to other nodes
• No new containers go here
• Node is still in the swarm

Bring it back:

docker node update --availability active node1

graph TD
    A["Node Active"] --> B{Need Maintenance?}
    B -->|Yes| C["Drain Node"]
    C --> D["Containers Move Out"]
    D --> E["Do Maintenance"]
    E --> F["Set Active"]
    F --> G["Ready for Work!"]
    B -->|No| G

Remove a Node

Step 1: Drain it

docker node update --availability drain node1

Step 2: On the node, leave the swarm

docker swarm leave

Step 3: On manager, remove it

docker node rm node1

Putting It All Together 🎯

Here’s how all operations work together:

graph TD
    A["Docker Swarm"] --> B["Stacks"]
    B --> C["Services"]
    C --> D["Rolling Updates"]
    C --> E["Rollback"]
    C --> F["Placement"]
    A --> G["Nodes"]
    G --> H["Node Management"]
    A --> I["Secrets & Configs"]
    I --> C

Quick Reference

You Did It! 🎉

You now understand Docker Swarm Operations like a pro head chef:

✅ Rolling Updates – Change recipes without closing ✅ Rollback – Undo mistakes instantly ✅ Secrets – Keep passwords encrypted ✅ Configs – Share settings everywhere ✅ Stacks – Deploy everything at once ✅ Placement – Control where things run ✅ Node Management – Manage your kitchen team

Your restaurant empire (and Docker Swarm) is ready to scale! 🚀