解决Docker Compose中MongoDB副本集的主机与服务间连接问题

你遇到的是MongoDB副本集地址解析的双向兼容性问题：

• 当副本集注册mongo（Docker Compose服务名）时，同Compose内的应用可正常连接，但主机执行./check_status时会抛出MongoNetworkError: getaddrinfo ENOTFOUND mongo——因为主机无法解析Docker内部的服务名
• 若将副本集地址改为localhost，主机端脚本可正常运行，但容器内应用会将localhost解析为自身容器，导致服务间连接失败

同时你受限于：不得修改主机/etc/hosts、不能使用network: host模式、需兼容Linux和macOS系统。

标准解决方案：利用host.docker.internal统一解析 #

host.docker.internal是Docker官方提供的内置域名，macOS上默认支持，Linux Docker 20.10+版本通过简单配置即可支持，全程无需修改主机系统设置。

步骤1：更新Docker Compose配置

修改docker-compose.yml中MongoDB服务的环境变量和额外主机配置：

services:
  app:
    build: .
    environment:
      MONGO_URI: "mongodb://root:root@mongo:27020/foo?replicaSet=rs0"
    depends_on:
      mongo:
        condition: service_healthy

  mongo:
    build:
      context: .
      args:
        MONGO_VERSION: 7.0.5
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: root
      MONGO_REPLICA_HOST: host.docker.internal  # 替换原有的mongo或localhost
      MONGO_REPLICA_PORT: 27020
      MONGO_COMMAND: "mongosh"
    ports:
      - "27020:27020"
    restart: unless-stopped
    extra_hosts:
      - "host.docker.internal:host-gateway"  # Linux下必填，macOS可省略但不影响兼容性
    healthcheck:
      test: [ "CMD", "mongosh", "admin", "--port", "$$MONGO_REPLICA_PORT", "--eval", "db.adminCommand('ping').ok" ]

步骤2：确保MongoDB允许外部连接

在MongoDB的启动配置中，设置net.bindIp: 0.0.0.0（或启动时添加--bind_ip_all参数），允许MongoDB监听所有IP地址，确保主机和容器都能建立连接。

步骤3：验证双向连接

• 容器内应用：保持应用的MONGO_URI使用mongo:27020，通过Docker Compose内置DNS直接解析到MongoDB容器，保持网络隔离性
• 主机端：./check_status脚本无需修改（若原脚本使用127.0.0.1:27020），或直接使用mongodb://root:root@host.docker.internal:27020/foo?replicaSet=rs0连接，均可正常访问副本集

原理说明 #

1. 副本集地址兼容性：host.docker.internal:27020可同时被主机和容器解析：
   • 主机端：host.docker.internal等价于localhost，直接通过端口映射访问MongoDB
   • 容器端：host.docker.internal指向主机IP，再通过端口映射转发到MongoDB容器；同时容器也可通过mongo服务名直接访问，两种方式均有效
2. Linux适配：extra_hosts配置让Linux容器内的host.docker.internal解析到主机网关IP，确保端口映射正常工作
3. 零主机修改：全程不涉及/etc/hosts或其他主机系统配置修改，符合部署独立的要求

替代方案：自定义DNS服务（可选） #

如果需要更灵活的域名规则，可以在Compose中添加CoreDNS服务，自定义域名在主机和容器内的解析结果。但此方案复杂度较高，上述host.docker.internal方案是更轻量的标准实现。

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