Docker – Managers and workers

How to configure WordPress multisite with NGINX

We have discussed swarm managers a little in the previous sections, but let’s take a closer look at what swarm managers do. The swarm managers do exactly what you would expect. They manage and maintain¬†the state of the swarm cluster. They schedule swarm services, which we will talk about in Swarm services¬†section of this chapter, but for now, think of swarm services as running containers. Manager nodes also serve up the API endpoints of the cluster, allowing for programmatic access via REST. Managers also direct traffic to the running services so that any container can be reached through any manager node without having to know which node is actually running the containers. As part of maintaining the state of the cluster, the managers will deal with the loss of nodes in the system, electing a new leader node in the event that the manager lost was the leader, and they will keep the desired number of service containers running if containers or nodes go down.

The best practices for the number of manager in a swarm are three, five, or seven. You’ll note that all of these options represent an odd number of manager nodes. This is so that if the leader node is lost, the raft consensus algorithm can more easily select a new leader for the swarm. You can run a swarm cluster with one manager node, and that is actually a better option than having two manager nodes. But, for a much more highly available swarm cluster, it is recommended that you have at least three manager nodes. For larger clusters, having five or seven managers is good, but it is not recommended to have more than seven. Once you have more than seven managers in the same cluster, you actually experience degraded performance.

Another important consideration for the manager nodes is the network performance between them. Managers need a low-latency network connection for optimal performance. If you are running your swarm in AWS, for example, you probably don’t want the managers within a swarm spread across regions. You would likely encounter issues with the swarm if you were to do so. If you put the managers within a swarm in different availability zones within a single region, you shouldn’t have any network-performance-related issues.

Worker nodes don’t do anything except run containers. They don’t have a say in electing new leaders when the leader node goes down. They don’t handle API calls. They don’t direct traffic. They do nothing but run containers. In fact, you can’t have a swarm with just a worker node. On the other hand, you can have a swarm with just a manager node, in which case the manager will also act as a worker and run containers in addition to its manager duties.

All manager nodes are actually worker nodes as well by default. This means that they can and will run containers. If you want to keep your managers from running workloads, you need to change the node’s availability setting. Changing it to draining will carefully stop any running containers on the manager node marked as draining, and will start up those containers on other (non-draining) nodes. No new container workloads will be started on a node in drain mode, for example as follows:

# Set node03's availability to drain
docker node update --availability drain ubuntu-node03

There may be times when you want or need to change the role of a docker node in the swarm. You can promote a worker node to manager status, or you can demote a manager node to worker status. Here are some examples of these activities:

# Promote worker nodes 04 and 05 to manager status
docker node promote ubuntu-node04 ubuntu-node05
# Demote manager nodes 01 and 02 to worker status
docker node demote ubuntu-node01 ubuntu-node02

Comments are closed.