Docker Compose服务连接：link、port与depends_on相关技术问询

Let's break down your questions one by one, since they cover different aspects of inter-service communication in Docker Compose:

1. Do I need to configure port if using link for service connections? #

Short answer: No—you don't need to expose ports to the host (via the ports directive) for services to communicate with each other using links.

The links feature (now deprecated, more on that later) was designed to let services discover and communicate on the internal Docker network. When you link two services, Docker sets up DNS entries so the linked service can be reached using its service name (or alias) without mapping its ports to the host machine.

For example, if you have a web service linked to a db service, the web container can connect to db:5432 (assuming PostgreSQL) without ever exposing port 5432 to your host via ports. The ports directive is only necessary when you need external traffic (like from your browser or a host-side tool) to reach a service.

2. Can depends_on be used as a replacement for links? #

Not entirely—they serve distinct purposes.

• depends_on only controls the startup order of services: it ensures one service starts before another (e.g., your db launches before your web app). It does not handle service discovery or network connectivity between services.
• Older versions of links did two things: set up DNS resolution for service discovery and enforced a startup order (similar to depends_on). But since Docker Compose 3+, links are deprecated because the default network setup handles service discovery automatically.

So if you're replacing links, you'll need depends_on for startup order (if needed) plus the default network (created automatically) for communication—depends_on alone isn't enough.

3. What's the best way to implement service connections in a Compose file? #

The modern, recommended approach is to leverage Docker Compose's default network (or a custom user-defined network) and avoid links entirely. Here's why and how:

• Docker Compose automatically creates a private network for your project. All services in the same Compose file attach to this network by default, meaning they can resolve each other by their service name (e.g., web can reach db using the hostname db).
• Use depends_on only if you need to enforce a startup order (note: it doesn't wait for the service to be "ready"—just that it's started; you might need a healthcheck if you need to wait for full operational readiness).
• Only use ports when you need to expose a service to the host or external network.

Example Compose File (Best Practice): #

version: '3.8'
services:
  web:
    build: ./web
    depends_on:
      - db
    # Only expose port 80 if you need external access (e.g., from your browser)
    ports:
      - "8080:80"
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret
    # No ports needed here—web can reach it via 'db:5432' internally
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

In this setup:

• The web service connects to PostgreSQL using db:5432 without any links or extra config.
• depends_on ensures db starts before web.
• The db service doesn't expose any ports to the host, keeping it secure.

Key takeaways:

• Forget links—they're legacy and unnecessary with modern Docker networks.
• Use the default (or custom) network for automatic service discovery.
• Use depends_on for startup order (with healthchecks if you need readiness guarantees).
• Only use ports for external access, not inter-service communication.

内容的提问来源于stack exchange，提问作者Shajia