You probably have not noticed this, but so far, all of the Docker workstation deployments, or nodes that we have used in our examples have been run in single-engine mode. What does that mean? Well, it tells us that the Docker installation is managed directly and as a standalone Docker environment. While this is effective, it is not very efficient and it does not scale well. Of course, Docker understands the limitations and has provided a powerful solution to this problem. It is called Docker swarm. Docker swarm is a way to link Docker nodes together, and manage those nodes and the dockerized applications that run on them efficiently and at scale. Simply stated, a Docker swarm is a group of Docker nodes connected and managed as a cluster or swarm. Docker swarm is built into the Docker engine, so no additional installation is required to use it. When a Docker node is part of a swarm, it is running in swarm mode. If there is any doubt, you can easily check whether a system running Docker is part of a swarm or is running in single-engine mode using the docker system info command:

The features that provide swarm mode are part of the Docker SwarmKit, which is a tool for orchestrating distributed systems at scale, that is, Docker swarm clusters. Once a Docker node joins a swarm, it becomes a swarm node, becoming either a Manager node or a Worker node. We will talk about the difference between managers and workers shortly. For now, know that the very first Docker node to join a new swarm becomes the first Manager, also known as the Leader. There is a lot of technical magic that happens when that first node joins a swarm (actually, it creates and initializes the swarm, and then joins it) and becomes the leader. Here is some of the wizardry that happens (in no particular order):

• A Swarm-ETCD-based configuration database or cluster store is created and encrypted
• Mutual TLS (mTLS) authentication and encryption is set up for all inter-node communication
• Container orchestration is enabled, which takes responsibility for managing which containers run on which nodes
• The cluster store is configured to automatically replicate to all manager nodes
• The node gets assigned a cryptographic ID
• A Raft-based distributed consensus-management system is enabled
• The node becomes a Manager and is elected to the status of swarm leader
• The swarm managers are configured for HA
• A public-key infrastructure system is created
• The node becomes the certificate authority, allowing it to issue client certificates to any nodes that join the swarm
• A default 90-day certificate-rotation policy is configured on the certificate authority

• The node gets issued its client certificate, which includes its name, ID, the swarm ID, and the node's role in the swarm
• Creating a new cryptographic join token for adding new swarm managers occurs
• Creating a new cryptographic join token for adding new swarm workers occurs

That list represents a lot of powerful features that you get by joining the first node to a swarm. And, with great power comes great responsibility, meaning that you really need to be prepared to do a lot of work to create your Docker swarm, as you might well imagine. So, let's move on to the next section, where we will discuss how to enable all of these features when you set up a swarm cluster.