Networking Between Containers

When you manage multiple containers individually with docker run, enabling communication between them requires manual steps. You might need to find container IP addresses, which can change, or use legacy linking mechanisms. This process is tedious and not ideal for defining reproducible application stacks.

Docker Compose addresses this by automatically setting up networking for your application. When you launch an application using docker-compose up, Compose performs several networking steps behind the scenes:

1. Creates a Network: By default, Compose creates a dedicated bridge network for your application (often named <project_name>_default). Each project defined by a docker-compose.yml file gets its own isolated network.
2. Connects Services: Every service (container) defined in your docker-compose.yml file is attached to this default network.
3. Enables Service Discovery: Containers within the same Compose network can find and communicate with each other simply by using the service name as a hostname.

This built-in service discovery is a significant advantage. You don't need to worry about container IP addresses. If you have a service named db and another named api, the api container can reach the db container by connecting to the hostname db on the appropriate port.

Let's consider a simple example involving a Python application (app) that needs to connect to a Redis cache (cache).

# docker-compose.yml
version: '3.8'

services:
  app:
    build: . # Assumes a Dockerfile in the current directory
    ports:
      - "5000:5000" # Expose port 5000 externally
    environment:
      # The app can connect to Redis using 'cache' as the hostname
      REDIS_HOST: cache
    depends_on:
      - cache

  cache:
    image: redis:alpine
    # No 'ports' needed here for internal communication

In this example:

• Compose creates a network.
• It builds the app service using a local Dockerfile and starts a container.
• It pulls the redis:alpine image and starts the cache service container.
• Both app and cache containers are attached to the same Compose-managed network.
• The app container can connect to the Redis service using the hostname cache (as specified by REDIS_HOST: cache). The standard Redis port is 6379, so the connection string within the application code would likely target cache:6379.
• The depends_on key ensures the cache service is started before the app service, although it doesn't guarantee Redis is fully ready within the container, just that the container has started.

Diagram illustrating how the app service container uses the service name cache to connect to the cache service container over the automatically created Docker Compose network. External access to the app service occurs via the host's mapped port.

It's important to distinguish between internal network communication and exposing ports externally.

• Internal Communication: Services within the same Compose network can communicate directly using service names and the ports the target service listens on internally (e.g., Redis listens on 6379 inside its container). You do not need to use the ports directive in docker-compose.yml for this internal traffic.
• External Access: The ports directive (e.g., "5000:5000" for the app service) maps a port on the host machine to a port inside a container. This is only necessary if you need to access a service from outside the Docker host (e.g., from your web browser or another application not managed by this Compose file). In our example, the Redis cache service doesn't need external access, so it has no ports section.

While the default network is sufficient for most applications, Docker Compose also allows you to define and use custom networks if you need more granular control over network topology or want to connect services across different Compose files. However, for typical ML development stacks involving components like an API, a database, or a worker queue defined within a single docker-compose.yml, the default network provides a straightforward and effective solution for inter-service communication. This automatic networking and service discovery significantly streamline the process of defining and running multi-container applications.