The Docker Compose file format is very simple. YAML is a human-readable markup language, and the Compose file specification captures your application configuration, using the same option names that the Docker CLI uses. In the Compose file, you define the services, networks, and volumes that make up your application. Networks and volumes are the same concepts that you use with the Docker engine. Services are an abstraction over containers.

A container is a single instance of a component, which could be anything from a web app to a message handler. A service can be multiple instances of the same component running in different containers, all using the same Docker image and the same runtime options. You could have three containers in the service used for your web application and two containers in the service you use for a message handler:

A service is like a template to run a container from an image, with a known configuration. Using services, you can scale up the components of the application—running multiple containers from the same image and configuring and managing them as a single unit. Services are not used in the standalone Docker engine, but they are used in Docker Compose, and also with a cluster of Docker engines running in Docker Swarm mode (which I cover in the next chapter, Chapter 7, Orchestrating Distributed Solutions with Docker Swarm.

Docker provides discoverability for services in the same way that it does for containers. Consumers access the service by name, and Docker can load-balance requests across multiple containers in a service. The number of instances in the service is transparent to consumers; they always refer to the service name, and the traffic is always directed to a single container by Docker.

In this chapter, I'll use Docker Compose to organize the distributed solution I built in the previous chapter, replacing the brittle docker container run PowerShell scripts with a reliable and production-ready Docker Compose file.