Docker Deep Dive
Restart the app with the docker-compose restart command.
It’s also worth knowing that Compose builds networks and volumes before deploying services. This makes sense, as networks and volumes are lower-level infrastructure objects that are consumed by services (containers).
docker-compose restart will restart a Compose app that has been stopped with docker-compose stop. If you have made changes to your Compose app since stopping it, these changes will not appear in the restarted app. You will need to re-deploy the app to get the changes.
docker-compose ps will list each container in the Compose app. It shows current state, the command each one is running, and network ports.
docker-compose down will stop and delete a running Compose app. It deletes containers and networks, but not volumes and images.
Docker Compose is a Python application that you install on top of the Docker Engine. It lets you define multi-container apps in a single declarative configuration file and deploy it with a single command.
Compose files can be YAML or JSON, and they define all of the containers, networks, volumes, and secrets that an application requires.
You also saw how volumes have a separate lifecycle to the rest of the app, and can be used to mount changes directly into containers.
Docker Swarm is two main things: An enterprise-grade secure cluster of Docker hosts An engine for orchestrating microservices apps
On the clustering front, Swarm groups one or more Docker nodes and lets you manage them as a cluster. Out-of-the-box, you get an encrypted distributed cluster store, encrypted networks, mutual TLS, secure cluster join tokens, and a PKI that makes managing and rotating certificates a breeze. You can even non-disruptively add and remove nodes. It’s a beautiful thing.
On the orchestration front, Swarm exposes a rich API that allows you to deploy and manage complex microservices apps with ease. You can define your apps in declarative manifest files and deploy them to the Swarm with native Docker commands. You can even perform rolling updates, rollbacks, and scaling operations. Again, all with simple commands.
Docker Swarm competes directly with Kubernetes — they both orchestrate containerized applications. While it’s true that Kubernetes has more momentum and a more active community and ecosystem, Docker Swarm is an excellent technology and a lot easier to configure and deploy. It’s an excellent technology for small-to-medium businesses and application deployments.
a swarm consists of one or more Docker nodes. These can be physical servers, VMs, Raspberry Pi’s, or cloud instances. The only requirement is that all nodes have Docker installed and can communicate over reliable networks.
Nodes are configured as managers or workers. Managers look after the control plane of the cluster, meaning things like the state of the cluster and dispatching tasks to workers. Workers accept tasks from managers and execute them.
The configuration and state of the swarm is held in a distributed etcd database located on all managers. It’s kept in memory and is extremely up-to-date.
Something that’s game changing on the clustering front is the approach to security. TLS is so tightly integrated that it’s impossible to build a swarm without it.
Swarm uses TLS to encrypt communications, authenticate nodes, and authorize roles. Automatic key rotation is also thrown in as the icing on the cake.
On the application orchestration front, the atomic unit of scheduling on a swarm is the service.
Docker nodes that are not part of a swarm are said to be in single-engine mode. Once they’re added to a swarm they’re automatically switched into swarm mode.
Running docker swarm init on a Docker host in single-engine mode will switch that node into swarm mode, create a new swarm, and make the node the first manager of the swarm.
docker swarm init: This tells Docker to initialize a new swarm and make this node the first manager. It also enables swarm mode on the node.
–advertise-addr: As the name suggests, this is the swarm API endpoint that will be advertised to other nodes in the swarm. It will usually be one of the node’s IP addresses, but can be an external load-balancer address.
–listen-addr: This is the IP address that the node will accept swarm traffic on. If not explicitly set, it defaults to the same value as –advertise-addr.
The default port that swarm mode operates on is 2377. This is customizable, but it’s convention to use 2377/tcp for secured (HTTPS) client-to-swarm connections.
Swarm managers have native support for high availability (HA). This means one or more can fail, and the survivors will keep the swarm running.
Technically speaking, swarm implements a form of active-passive multi-manager HA. This means that although you have multiple managers, only one of them is active at any given moment. This active manager is called the “leader”, and the leader is the only one that will ever issue live commands against the swarm.
If you look closely at Figure 10.3, you’ll notice that managers are either leaders or followers. This is Raft terminology, because swarm uses an implementation of the Raft consensus algorithm to maintain a consistent cluster state across multiple highly available managers.
On the topic of HA, the following two best practices apply: Deploy an odd number of managers. Don’t deploy too many managers (3 or 5 is recommended)
Having an odd number of managers reduces the chances of split-brain conditions. For example, if you had 4 managers and the network partitioned, you could be left with two managers on each side of the partition. This is known as a split brain — each side knows there used to be 4 but can now only see 2.
A swarm cluster continues to operate during split-brain conditions, but you are no longer able to alter the configuration or add and manage application workloads.
As with all consensus algorithms, more participants means more time required to achieve consensus. It’s like deciding where to eat — it’s always quicker and easier for 3 people to make a quick decision than it is for 33! With this in mind, it’s a best practice to have either 3 or 5 managers for HA. 7 might work, but it’s generally accepted that 3 or 5 is optimal. You definitely don’t want more than 7, as the time taken to achieve consensus will be longer.
While it’s obviously a good practice to spread your managers across availability zones within your network, you need to make sure the networks connecting them are reliable, as network partitions can be a difficult to troubleshoot and resolve.
Swarm clusters have a ton of built-in security that’s configured out-of-the-box with sensible defaults — CA settings, join tokens, mutual TLS, encrypted cluster store, encrypted networks, cryptographic node ID’s and more.
Despite all of this built-in native security, restarting an older manager or restoring an old backup has the potential to compromise the cluster. Old managers re-joining a swarm automatically decrypt and gain access to the Raft log time-series database — this can pose security concerns. Restoring old backups can also wipe the current swarm configuration.
To prevent situations like these, Docker allows you to lock a swarm with the Autolock feature. This forces restarted managers to present the cluster unlock key before being admitted back into the cluster.
Locking your swarm and protecting the unlock key is recommended for production environments.
services are a new construct introduced with Docker 1.12, and they only apply to swarm mode.
Services let us specify most of the familiar container options, such as name, port mappings, attaching to networks, and images. But they add important cloud-native features, including desired state and automatic reconciliation.