So far, we have mostly been looking at running a Docker container from a single Docker image, simplifying the Docker model to imagine a world where every application only required a single service, and thus a single Docker image, to run. However, as you know, that is a pretty unrealistic model. Real-world applications are composed of multiple services, and those services are deployed using multiple Docker images. To run all of the necessary containers, and maintain them at the desired number of replicas, handling planned and unplanned downtimes, scaling requirements and all of the other service management needs is a really daunting and complex task. In the recent past, this scenario was handled using a tool called Docker Compose. Docker Compose (as you learned in Chapter 1, Setting up a Docker Development Environment) is an additional tool that you can install in your Docker environment, which we did to complete our workstation's environment. While much of the functionality of Docker Compose is similar to what you find in Docker stacks, we will be focusing on Docker stacks in this chapter. We are doing this because Docker Compose is used to manage containers, and the Docker world has evolved toward the commodity unit being services instead of containers. Docker stacks manages services, and so I see Docker stacks as the evolution of Docker Compose (which was the evolution of a project named Fig). The reason we did not install Docker stacks in Chapter 1, Setting up a Docker Development Environment, is that Stacks is already included as part of a standard Docker installation.
OK, so Docker stacks is the new and improved Docker Compose, and it is included in our installation. I bet you're thinking, Great. But what does that mean? What is the use case of Docker stacks? Great question! Docker stacks is the way to leverage all of the functionality that we have learned about in the earlier chapters, such as the Docker commands, Docker images, Docker services, Docker volumes, Docker swarm, and Docker networks, wrapping it all up in an easy-to-use, easy-to-understand, declarative document file that will instantiate and maintain a complex, multi-image application on our behalf.
Most of your work, which is still the easy part, will be in creating the compose file that will be used in the Docker stack commands. All of the really hard work will be done by Docker when it creates, starts, and manages all of the services required for your multi-service (multi-container) applications. All of this is handled by a single command on your part. Just like image, the container and swarm stacks are another Docker management group. Let's take a look at the stack management commands:
So, what do we have here? For all the power that this management group represents, it has a pretty simple set of commands. The main command is the deploy command. It is the powerhouse! With this command (and a compose file), you will stand up your application, pulling any images that are not local to your environment, running the images, creating volumes as needed, creating networks as needed, deploying the defined number of replicas for each image, spreading them across your swarm for HA and load-balancing purposes, and more. This command is kind of like the one ring in The Lord of the Rings. In addition to deploying your application, you will use this same command to update running applications, when you need to do things such as scale your application.
The next command in the management group is the list stacks command. As the name implies, the ls command allows you to get a list of all the stacks currently deployed to your swarm. When you need more detailed information about a particular stack that is running in your swarm, you will use the ps command to list all of the tasks of a particular stack. When it comes time to end of life a deployed stack, you will use the mighty rm command. And finally, rounding out the management commands, we have the services command, which allows us to get a list of the services that are part of the stack. There is one more important part of the stack puzzle, that being the --orchestrator option. With this option, we can instruct Docker to use either Docker swarm or Kubernetes for the stack orchestration. Of course, to use Kubernetes, it must be installed, and to use swarm—which is the default if the option is not specified—swarm mode must be enabled.
In the rest of this chapter, we are going to take a deep dive into Docker stacks using a sample application. Docker provides several such samples, but the one we are going to examine is the voting application sample. I will provide a link to the Docker repo for the app, as well as a link to a fork of the project in my space in the event that the Docker app changes drastically or the project goes away. Let's take a look at the stack file for the example voting application.