Docker Compose for Inter-Service Communication

1. The Default Network: Automatic Service Discovery

When you run docker compose up, Docker Compose does something magical behind the scenes: it creates a single, private network and connects all the services defined in your docker-compose.yml file to it.

This network has a special property: it provides an internal DNS service. This means each service can find any other service simply by using its service name as a hostname.

For example, if you have a web service and a db service, your web container's application code can connect to the database using a connection string like postgres://db:5432. You don't need to worry about finding the container's internal IP address, which can change every time it restarts. Compose handles it all for you.

From Manual to Automatic

To fully appreciate the convenience of Docker Compose, it helps to see how you would achieve this manually using just the Docker CLI. It involves creating a network first and then explicitly attaching containers to it.

The following video does an excellent job of demonstrating this "before and after" scenario.

As you can see, what took several manual commands is handled automatically by Compose. This default network is perfect for many applications where all services need to communicate freely.

2. Custom Networks: Gaining Control and Security

While the default network is convenient, it's not always ideal. In a real-world application, you often want to enforce stricter rules about which services can communicate. For instance, you might want your frontend to talk to your backend API, but you almost certainly do not want the frontend to have direct access to your database. This is a security best practice known as the principle of least privilege.

This is where custom networks come in. Docker Compose allows you to define your own networks and selectively connect services to them.

This enables you to create network topologies that match your application's architecture, such as a multi-tier design with a frontend and a backend network.

Defining and Using Custom Networks

To implement a custom network topology, you use two keys in your docker-compose.yml file:

1. Top-level networks key: This is where you declare your custom networks. You can simply list their names.
2. Service-level networks key: Under each service, you specify which of the declared networks it should connect to.

Here’s the classic example from the Docker documentation, which implements the topology we discussed:

And for another clear, concise example, see the "Custom Networks" section in this guide from CubePath.

version: '3.8'

services:
  frontend:
    # ... other service config
    networks:
      - frontend-net

  api:
    # ... other service config
    networks:
      - frontend-net
      - backend-net

  database:
    # ... other service config
    networks:
      - backend-net

networks:
  frontend-net:
  backend-net:

3. Practical Example: Securing a Database

Let's see this in action with a more complete, practical example. The video below demonstrates creating a public network for an Nginx proxy and a private network for a PostgreSQL database, improving the application's security posture. It also shows you how to verify that the isolation is working correctly.

Verifying Your Network Setup

As shown in the video, you can and should always verify your network configuration. Here are the key commands:

• docker network ls: Lists all Docker networks on the host. You'll see the networks created by Compose, typically prefixed with your project's directory name (e.g., myproject_frontend-net).
• docker network inspect <network-name>: Shows detailed information about a network, including which containers are connected to it and their IP addresses within that network.
• docker compose exec <service-name> <command>: Executes a command inside a running service container. This is invaluable for testing. Common commands include:
  • docker compose exec api sh (to get an interactive shell)
  • docker compose exec frontend ping api (to test if frontend can resolve and reach api)

Conclusion

You've now mastered a fundamental concept in orchestrating multi-container applications. Understanding Docker Compose networking allows you to move beyond simple applications and build complex, secure, and well-architected systems.

Key Takeaways:

• Default Network: Docker Compose automatically creates a shared network for all services, allowing them to communicate using their service names as hostnames.
• Custom Networks: You can define your own networks to create isolated communication channels between specific services. This is a crucial security practice.
• Configuration: You use the top-level networks key to define networks and the service-level networks key to connect services to them.
• Verification: Always use tools like docker network inspect and docker compose exec to verify that your network topology is configured as you expect.

Next Up

We've figured out how to build our services and make them communicate. But what happens when a database container is removed and recreated? All the data is lost! In our next lesson, we will solve this problem by learning how to manage persistent data for stateful services using named volumes in a Compose file.