You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Docker-Compose链接MySQL与PHP容器时/etc/host无链接记录问题

Hey there! Let's break down why you're missing those familiar link entries in your web_1 container's /etc/hosts file, and how to handle container communication properly given your environment (Docker 17.05.0-ce, docker-compose 1.13.0, Debian 8.10).

The Root Cause

Docker Compose version 1.10+ changed its default network behavior: instead of using the legacy --link mechanism (which modifies /etc/hosts directly), it creates a custom bridge network for your project by default. This custom network relies on Docker's built-in DNS service to handle container-to-container communication—so manual /etc/hosts entries aren't needed anymore.

Solutions for Your Scenario

1. Use Docker DNS for Container Communication (Recommended)

You don't need /etc/hosts entries to talk to other services in your Compose stack. Just use the service name defined in your docker-compose.yml as the hostname. For example:

  • If you have a db service in your config, run ping db inside web_1—Docker's DNS will automatically resolve it to the db container's IP.
  • This approach is far more reliable than /etc/hosts because it updates automatically if containers restart or their IP addresses change.

2. Force /etc/hosts Entries (If You Really Need Them)

If you must have entries in /etc/hosts for specific use cases, here are two actionable ways to do it:

Option A: Manually Add Entries (Temporary)

Log into your web_1 container and add the entry directly (note: this change will disappear when the container restarts):

docker exec -it web_1 bash
echo "<db-container-ip> db" >> /etc/hosts

Replace <db-container-ip> with the actual IP of your db container (get it with docker inspect db_1 | grep "IPAddress").

Option B: Use extra_hosts in docker-compose.yml

Add the extra_hosts field to your web service definition to statically map a hostname to an IP. Example:

services:
  web:
    image: your-web-image
    extra_hosts:
      - "db:172.18.0.3" # Replace with your db container's actual IP
  db:
    image: your-db-image

⚠️ Heads up: Container IPs can change on restart, so this isn't as reliable as using Docker DNS.

Option C: Revert to Legacy --link Behavior

If you want to go back to the old --link mechanism (which updates /etc/hosts automatically), configure your Compose stack to use the default bridge network instead of a custom one. Add this to your docker-compose.yml:

version: '2' # Compose v2 syntax works with your 1.13.0 version
services:
  web:
    image: your-web-image
  db:
    image: your-db-image
networks:
  default:
    external:
      name: bridge

⚠️ Note: The default bridge network has worse isolation than custom networks, so this isn't recommended for production environments.

Final Note

Docker's DNS-based service discovery is the modern, recommended way to handle container communication. It's more flexible, automatic, and secure than relying on /etc/hosts entries from the legacy --link feature. Stick with it unless you have a specific legacy requirement!

内容的提问来源于stack exchange,提问作者sakhunzai

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.19 07:29:48