Managing Containers with Docker Compose

Microservices often rely on several components. Think of a Spring Boot application needing a database, a message queue, or another API service.

Each component typically runs in its own Docker container. Managing these individually can become complex, especially during development.

How do we start them all together, ensure they can communicate, and manage their lifecycle efficiently? This is where Docker Compose steps in!

Docker Compose is a tool for defining and running multi-container Docker applications. Instead of managing each container separately, you define all services in a single, easy-to-read file.

This definition file is typically named docker-compose.yml. It uses YAML syntax, which is both human-readable and machine-parseable.

Compose simplifies your development workflow by letting you spin up your entire application stack with a single command.

The docker-compose.yml file starts with a version, followed by the services section where you define each container as a distinct service.

Each service represents a container, and you can specify its image, exposed ports, environment variables, and more.

Here's a minimal structure for a simple web app:

Let's define a simple web service. We'll use the official Nginx image, map a port, and give it an optional container_name.

The image key specifies the Docker image to use (e.g., nginx:latest). The ports key maps host ports to container ports (e.g., host's port 80 to container's port 80).

Most applications need a database. Let's add a PostgreSQL database service to our docker-compose.yml file.

We'll specify the postgres:13 image and set crucial environment variables for credentials (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD).

Docker Compose automatically creates a default network for all services defined in your docker-compose.yml file.

Services can communicate with each other using their service names as hostnames. For example, your web app can connect to the database using database as the hostname and the specified port (e.g., 5432 for PostgreSQL).

This automatic networking simplifies inter-service communication setup significantly.

Containers are ephemeral; data inside them is lost if the container is removed. For databases, this is a critical problem!

Docker volumes provide a way to persist data generated by Docker containers. We can use a named volume to store our database's data outside the container, ensuring it survives container restarts or removals.

Often, you'll have your own application code (like a Spring Boot JAR) that needs to be built into a Docker image. Docker Compose can handle this too.

Instead of specifying an image, you can use the build key and point to the directory containing your Dockerfile.

Compose will then build your custom image before starting the service. Here's how it looks:

Once your docker-compose.yml is ready, a few commands will be essential for managing your application stack:

• docker compose up: Builds (if needed) and starts all services. Use -d for detached mode.
• docker compose down: Stops and removes containers, networks, and optionally volumes.
• docker compose ps: Lists all running services defined in the Compose file.
• docker compose logs: Shows log output from services.

Remember to run these commands in the directory where your docker-compose.yml file is located.

Consider a docker-compose.yml file that defines two services: web and db.

Which of the following statements about how these services communicate and store data are generally TRUE?

Congratulations! You've learned how Docker Compose simplifies the management of multi-container applications.

You can now define your entire application stack in a single docker-compose.yml file, including web services, databases, and custom-built images.

This tool is incredibly useful for local development and testing of microservices, allowing you to spin up your whole environment with just one command. Keep practicing!