Docker Compose Services: Defining Your App's Components

WHY IT EXISTS: To manage multi-container applications declaratively. Instead of manually starting, networking, and configuring individual containers for a web server, database, and cache, you define them as services in a single file. This makes complex local development setups reproducible and easy to manage.

THE MENTAL MODEL: Think of your docker-compose.yml file as a cast list for a play. Each service is a character. The image or build key is the actor's script (the code they run). ports are the stage doors they can be reached through. volumes are their props that persist between scenes. environment variables are director's notes that change their performance. docker-compose up is the "action!" call that brings them all to life on stage.

HOW IT WORKS: Under the services key in a docker-compose.yml file, you define one or more named services. For each service, you specify configuration. The most important is image (to pull from a registry) or build (to build from a local Dockerfile). Other common keys include ports to map container ports to host ports, volumes for persistent data, environment to set environment variables, and depends_on to control startup order. When you run docker-compose up, Docker reads this file, creates a network, and starts containers for each service according to your definitions.

WHEN TO USE IT: Use services for any project involving more than one container. It is the standard for local development environments for web applications, microservices architectures, and data processing pipelines. It lets you spin up a complete, interconnected environment (e.g., a WordPress site with its MySQL database) with a single command.

WHEN NOT TO USE IT: While excellent for development, Docker Compose is not a full production orchestration tool like Kubernetes. It lacks features for auto-scaling, high-availability, and rolling updates across a cluster of machines. For single-container apps, a simple docker run command may be easier.

ONE CANONICAL EXAMPLE: A simple web app might have two services: web and db. The web service would be built from a local Dockerfile and depend on the db service. The db service would use the official postgres image, use a named volume to persist its data, and not expose any ports to the host. The web service connects to the database using the hostname db, as Compose provides service discovery on its internal network.