Docker Swarm Mode

All current versions of Docker include the Swarm mode for natively managing a cluster of Docker Engines called a Swarm. Use the Docker CLI to create a swarm, deploy application services to a swarm, and manage swarm behavior. Portainer is the go-to GUI to use for Docker Engines running in Swarm mode.

For me, as I'm downsizing my lab, Docker swarm mode will take over all the K3s and K8s installations I have. I want an easier and easier to maintain environment. As Docker is one of my main tools, it's a great fit.

Swarm mode

Does the Swarm mode compete with K8s – yes and no. It's not as complicated as K8s, but it will handle the orchestration. You will have a quicker learning phase because the infrastructure and setup is easier. The drawback is that very complicated setups will not be the use case for Dockers Swarm mode. But, do we have complicated setups on our Home labs? The Answer is, usually not. I have been running K3s/K8s and Docker Swarms on my servers. Today, I only have Docker Swarm mode clusters left.

Docker Swarm mode is built into the Docker Engine. Run Docker in production the modern way, as a swarm of orchestrated containers. It can use compose.yml -files or Portainer.
Run clusters with or without: load balancing, ingress load balancing or persistent storage.

Why? With Swarm mode, you will have:

• Scalability, you can easily scale up and/or down any app.
• Load Balancing, and by that also
• Redundancy by running Docker VM on different nodes in our without a cluster.

Open protocols and ports between the hosts

The following ports must be available. On some systems, these ports are open by default.

• Port 2377 TCP for communication with and between manager nodes
• Port 7946 TCP/UDP for overlay network node discovery
• Port 4789 UDP (configurable) for overlay network traffic

Set Up a Test Swarm

We need tree VM/CT to start. I will use a Cloud Image of Debian 13, but Ubuntu 24.04 LTS is very well suited for Docker use.

• Create 3 VM, upgrade and install curl, sudo and other tool you need.
• Add your user and add a group docker : usermod -aG docker $USER
• Create a NFS share for the Swarm to use (optional) for HA for the Docker part.

For full redundancy, you need tree Leaders and two or more Workers.

Install Docker – all nodes

Install docker on all the swarm nodes

sudo curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

Then add user to the docker group

Add to the current group

sudo usermod -aG docker $USER

Now, you need to do a logout by CTRL+D and then login again and
then you can test for success: docker ps, if you get the correct output, you are OK.

Setup /etc/hosts

All hosts need to find the Leaders and the Workers. Add this to all nodes:

# My Docker swarm – 50
192.0.2.51 swarm-51 # Leader
192.0.2.52 swarm-52 # Worker
192.0.2.53 swarm-53 # Worker

The first Leader

Go to the first VM (to be our first Leader) and start installation of the app on our swarm.

Initialize the Swarm-mode

docker swarm init --advertise-addr <first node IP>:2377

The following will be shown on your terminal:

Swarm initialized: current node (<random string>xiaw8idd492xhkwpnrpq) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token <Realy long sting with a lot of stuff> <first vm IP>:2377

Check for Success

List of all workers and Leaders: docker node ls

The Workers

To join the Workers to the Leader, copy the Token and execute at each of them:

docker swarm join --token <Realy long string> <first vm IP>:2377

Check for Success

List of all workers and Leaders: docker node ls

Add Leaders

If our Leader goes away, the swarm would be useless. We need to add two more for redundancy: docker node promote <vm2 name> and docker node promote vm3 name.

Check for Success

List of all workers and Leaders docker node ls

Add your Tools and Apps

Compiler

Compiler is already installed and we can use it.

Install Portainer (option)

We need to download from Portainer homepage a YAML-file. We do it on the first VM.

curl -L https://downloads.portainer.io/ce-lts/portainer-agent-stack.yml -o portainer-agent-stack.yml

Then install Portainer on the first Leader and Agents on the other ones by:

docker stack deploy -c portainer-agent-stack.yml portainer

Check for Success

List of all Workers and Leaders running the containers by:

• Portainer: docker service ps portainer_portainer and
• Portainer Agent: docker service ps portainer_agent

With docker node ps you see all containers on one node.

Restart Portainer and you can log in https://<IP or FQDN>:9443 on any of the Docker nodes in the Swarm, due to the internal load balancer for containers.

You will have Portainer Agent on all nodes in the swarm.

Next post in the series

Next time I will discuss stuff like Persistent Storage and ingress Virtual IP.

Feature highlights TLDR;

Cluster management integrated with Docker Engine

With the Docker Engine CLI, you can spin up a swarm of Docker Engines to run your application services. You don't need any extra orchestration tools – Docker's got you covered for creating and managing the whole thing.

Decentralized design

Instead of figuring out node roles when you deploy, Docker Engine sorts out the specialization on the fly. You can spin up both manager and worker nodes using the same Docker Engine, which means you can build your entire swarm from a single disk image, pretty convenient and very efficient.

Declarative service model

Docker Engine uses a declarative approach, so you just describe what you want your application stack to look like, and it makes it happen. For instance, you could describe an app with a web front end, message queueing services, and a database backend – and the Docker Engine takes care of the rest.

Scaling

For each service, you just say how many tasks you want running. Then, when you need to scale up or down, the swarm manager automatically adjusts by adding or removing tasks to keep everything in the state you want.

Desired state reconciliation

The swarm manager(s) keeps an eye on the cluster and makes sure reality matches what you've asked for. Say you want 10 replicas of a container running, if a worker node crashes and takes two of them down, the manager automatically spins up two new replicas to replace them. Or a node is taken down for service, the manager moves the load to the remaining nodes. Then it assigns those new replicas to workers that are healthy and ready to go.

Multi-host networking

You can set up an overlay network for your services. The swarm manager then takes care of handing out addresses to containers on the network whenever it initializes or updates your app.

Service discovery

The swarm manager gives each service its own unique DNS name and balances the load across running containers. There's a built-in DNS server in the swarm that lets you query any container running in it.

Load balancing

You can expose service ports to an external load balancer, and internally the swarm gives you control over how to spread your service containers across nodes.

Secure by default

Every node in the swarm uses TLS mutual authentication and encryption to keep communications between nodes secure. You can go with self-signed root certificates or bring your own from a custom root CA of your choice. You may have a Reverse Proxy to manage your certificates.

Rolling updates

When you're rolling out updates, you can apply them gradually across your nodes. The swarm manager lets you control how much of a delay there is between deploying to different groups of nodes. And if something breaks, you can just roll back to an earlier version of the service.

Explore Swarm mode CLI commands

• Swarm init
  Initialize a swarm. The Docker Engine targeted by this command becomes a manager in the newly created single-node swarm.
• Swarm join
  Join a node to a swarm. The node joins as a manager node or worker node based upon the token you pass with the --token flag. If you pass a manager token, the node joins as a manager. If you pass a worker token, the node joins as a worker.

Cluster Management Commands

They must be executed on a swarm manager node. To learn about managers and workers, refer to the Swarm mode section in the documentation.

Docker commands, use as e.g: docker service create. Most commands do have options and other things to remember, please read the documentation.

• service create
  Creates a service as described by the specified parameters.
• service inspect
  Inspects the specified service.
  By default, this renders all results in a JSON array. If a format is specified, the given template will be executed for each result.
• service logs
  The docker service logs command batch-retrieves logs present at the time of execution. The docker service logs command can be used with either the name or ID of a service, or with the ID of a task. If a service is passed, it will display logs for all the containers in that service. If a task is passed, it will only display logs from that particular task.
• service ls
  This command lists services that are running in the swarm.
• service ps
  Lists the tasks that are running as part of the specified services.
• service rm
  Removes the specified services from the swarm.
• service rollback Roll back a specified service to its previous version from the swarm.
• service scale The scale command enables you to scale one or more replicated services either up or down to the desired number of replicas. This command cannot be applied on services which are global mode. The command will return immediately, but the actual scaling of the service may take some time. To stop all replicas of a service while keeping the service active in the swarm, you can set the scale to 0.
• service update
  Updates a service as described by the specified parameters. The parameters are the same as docker service create. Refer to the description there for further information.
  Normally, updating a service will only cause the service's tasks to be replaced with new ones if a change to the service requires recreating the tasks for it to take effect. For example, only changing the --update-parallelism setting will not recreate the tasks, because the individual tasks are not affected by this setting. However, the --force flag will cause the tasks to be recreated anyway. This can be used to perform a rolling restart without any changes to the service parameters.

References

Docker ^[1] Ubuntu ^[2] ]