Docker Compose: Understanding links and depends_on

In Docker Compose, orchestrating multi-container applications can be accomplished using the docker-compose.yml file. Two directives within this file, links and depends_on, manage the relationships and startup order of services. Understanding these directives is essential for ensuring that your containers communicate effectively and start in the correct sequence. This article delves into the differences and use cases for links and depends_on.

links Directive

The links directive was used to connect services in a Docker Compose file, allowing containers to communicate with one another. When you define a link between two services, Docker would essentially create an alias in the source service's /etc/hosts file. This linkage was used to set up a network channel between containers, specifically allowing them to use DNS names to resolve service addresses.

Key Characteristics:

• Networking: Creates ALIAS entries in the /etc/hosts file.
• Legacy: As of more recent versions of Docker, links has been deprecated in favor of Docker networks.
• Usage: It is necessary when explicitly defined DNS resolution is needed, although rare now with network advancements.

Example:

1version: '3'
2services:
3  web:
4    image: nginx
5    links:
6      - db
7  db:
8    image: postgres

In the above example, the web service can access the db service by simply using the hostname db.

depends_on Directive

The depends_on directive in Docker Compose provides a way to specify service startup order. It tells Docker Compose that a particular service depends on the state of another service.

Key Characteristics:

• Service Order: Specifies service dependencies, ensuring the order of startup.
• No Wait for Readiness: By itself, it does not ensure that the dependent service is fully ready, just started.
• Compatibility: Does not interfere or require specific networking features.

Example:

1version: '3'
2services:
3  web:
4    image: nginx
5    depends_on:
6      - db
7  db:
8    image: postgres

In this configuration, the web service will only start after the db service has initiated its startup sequence.

Modern Best Practices

While historically links were essential for inter-service communication, Docker Compose now encourages the use of user-defined networks. These are more flexible and automatically provide DNS-based service discovery.

For managing service dependencies effectively, it is often necessary to incorporate custom scripts or use health check mechanisms within docker-compose.yml. This is because depends_on only regulates the startup sequence but does not wait for the service to be fully ready. Here’s how you might achieve this:

1version: '3.7'
2services:
3  web:
4    image: nginx
5    depends_on:
6      db:
7        condition: service_healthy
8  db:
9    image: postgres
10    healthcheck:
11      test: ["CMD", "pg_isready", "-U", "postgres"]
12      interval: 30s
13      timeout: 10s
14      retries: 5

In this setup, the web service will only initiate once the db service passes its health check.

Summary Table

Here's a quick comparison of the features associated with links and depends_on:

Additional Considerations

• User-defined Networks: Use networks for better flexibility and improved DNS resolutions.
• Service Readiness: Use health checks or other conditional logic to enable fully reliable startup sequences.
• Deprecated Features: Avoid links in new setups, leaning instead on modern networking and readiness checks.

By wisely incorporating these directives within your Docker Compose file, you can ensure smooth operation and communication between your microservices. Understanding and implementing appropriate orchestration strategies will help achieve more resilient and scalable systems.