GitLab CI/CD DinD环境下docker-compose启动容器间无法通信问题求助

问题澄清与核心原因 #

首先明确：DinD环境的容器命名规则、docker-compose内置的服务名DNS解析逻辑，和本地Docker环境没有任何本质差异。你遇到的连接被拒问题，是CI环境下的执行时序、服务配置、写法缺陷叠加导致的，和规则差异无关。
具体原因拆解如下：

• 执行时序问题：你用docker-compose up -d --build后台启动服务后，没有等待服务完成初始化就立刻执行测试。-d参数仅会等待容器进程启动完成就返回，不会校验端口监听、服务初始化是否完成。InfluxDB、Mosquitto这类服务通常需要1-5秒完成初始化、绑定端口，CI环境下没有额外等待时间，此时发起连接自然会触发Connection refused。本地环境下你手动操作时往往会预留等待时间，或者本地性能更好服务启动更快，所以不会暴露这个问题。
• Mosquitto服务配置缺失：你当前的compose配置没有给eclipse-mosquitto挂载自定义配置文件，2.0+版本的官方镜像默认配置存在两个限制：仅绑定容器内部回环地址的1883端口、禁止匿名客户端连接。这种情况下即使容器进程正常运行，跨容器的连接请求也会被直接拒绝。
• 硬编码容器名的写法缺陷：你用docker exec moderator-monitor_datareplay_1 ...的方式硬编码了compose自动生成的容器名，这个名称的前缀（moderator-monitor）是compose默认的项目名，取自执行命令时的工作目录名称。CI环境下GitLab Runner的默认工作目录basename是项目名，刚好能匹配上属于巧合，但这种写法本身稳定性极差，不属于当前连接被拒的根因，但属于必须修复的配置问题。
• 网络配置遗漏风险：你贴出的compose片段仅包含datareplay、mosquitto的配置，需要确认InfluxDB容器是否明确接入了influxnet网络，否则跨网络无法通过服务名influxdb解析到对应容器IP，也会触发连接错误。另外你给influxnet、brokernet配置的internal: true属性仅会禁止网络内容器访问公网，不会影响同网络下的容器互访，不是问题来源。

针对性解决方案 #

1. 修复测试执行流程，强制等待服务就绪 #

删除compose up之后直接跑测试的逻辑，加一道服务就绪校验，可选以下两种方式：

• 手动加轮询等待逻辑，在compose up之后、执行测试之前插入：

  # 等待InfluxDB端口就绪
  until docker-compose exec -T influxdb nc -z localhost 8086; do sleep 1; done
  # 等待Mosquitto端口就绪
  until docker-compose exec -T mosquitto nc -z localhost 1883; do sleep 1; done
  

• 如果使用的docker-compose版本≥1.27，直接用--wait参数启动compose，会自动等待所有服务的健康检查通过后再返回：

  docker-compose -f "docker-compose.replay.yml" up -d --build --wait
  

2. 修复Mosquitto配置 #

在compose的mosquitto服务定义里挂载自定义配置，开放跨容器访问权限：

mosquitto:
  image: eclipse-mosquitto:latest
  hostname: mosquitto
  networks:
    - web
    - brokernet
  volumes:
    - ./mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf

对应的自定义mosquitto.conf至少需要包含以下配置，确保服务监听所有网卡、允许匿名连接：

listener 1883 0.0.0.0
allow_anonymous true

3. 替换硬编码容器名的执行逻辑 #

放弃手动写自动生成的容器名，直接用docker-compose的exec命令执行测试，自动匹配对应服务的运行容器，避免名称变动导致的执行失败：
将原来的exec命令替换为：

docker-compose exec -T datareplay bash -c 'cd src ; python integration_tests.py'

4. 校验网络配置完整性 #

检查compose文件内的InfluxDB服务定义，确认已将其接入influxnet网络，保证和datareplay容器处于同一网络平面，可通过服务名正常解析。 #

容器健康度的可靠校验方式 #

docker-compose ps仅能判断容器进程是否处于运行状态，无法校验服务本身是否正常对外提供能力，推荐采用以下方式校验：

• 跨容器连通性测试：在datareplay容器内直接测试目标服务的端口连通性，比如执行docker-compose run --rm datareplay nc -z influxdb 8086，返回成功即说明网络通畅、端口正常监听。
• 查看服务运行日志：通过docker-compose logs <服务名>查看对应服务的启动日志，配置错误、初始化失败的问题会直接在日志中暴露。
• 为服务配置healthcheck规则：在compose的服务定义中添加健康检查逻辑，比如InfluxDB的健康检查配置：

  influxdb:
    # 原有配置
    healthcheck:
      test: ["CMD", "influx", "ping"]
      interval: 2s
      timeout: 5s
      retries: 10
  

  配置后compose会自动判断服务是否真正就绪，而非仅识别进程运行状态。

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