In this chapter I covered Docker Compose, the tool used to organize distributed Docker solutions. With Compose, you explicitly define all the components of your solution, the configuration of the components, and the relationship between them in a simple, clean format.

The Compose file lets you manage all the application containers as a single unit. You learned in this chapter how you can use the docker-compose command line to spin up and tear down the application, creating all the resources and starting or stopping containers. You also learned that you can use Docker Compose to scale components up or down and to release upgrades to your solution.

Docker Compose is a powerful tool for defining complex solutions. The Compose file effectively replaces lengthy deployment documents and fully describes every part of the application. With external resources and Compose overrides, you can even capture the differences between environments and build a set of YAML files that you can use to drive your whole deployment pipeline.

The limitation of Docker Compose is that it's a client-side tool. The docker-compose command needs access to the Compose file to execute any commands. There is a logical grouping of resources into a single application, but that happens only in the Compose file. The Docker engine only sees a set of resources; it does not recognize them as being part of the same application. Docker Compose is also limited to single-node Docker deployments.

In the next chapter, I'll move on to clustered Docker deployments, with multiple nodes running in a Docker Swarm. In a production environment, this gives you high availability and scale. Docker Swarm is a powerful orchestrator for container solutions, and it is very easy to use. It also supports the Compose file format, so you can use your existing Compose files to deploy applications, but Docker stores the logical architecture within the swarm, allowing you to manage your application without needing the Compose file.