GitHub Actions中Docker同网络容器无法连接问题排查

问题分析 #

从你提供的信息来看，应用容器clightformsapi和数据库容器lightformsdev确实在同一个lightformsdevops Docker网络下，但应用无法通过容器名解析到数据库，报错getaddrinfo EAI_AGAIN 'lightformsdev'，这大概率是Docker内部DNS解析异常，或是网络配置限制了容器间的DNS查询。

分步解决方案 #

1. 先验证容器内的DNS解析能力 #

进入应用容器，直接测试对数据库容器名的解析：

docker exec -it clightformsapi nslookup lightformsdev

• 如果返回NXDOMAIN或超时，说明DNS解析确实有问题，继续往下排查；
• 如果能正常返回数据库容器的IP（172.20.0.2），那问题可能出在应用的连接配置上，检查.env.prod里的数据库主机名是否拼写正确，有没有多余空格或特殊字符。

2. 调整Docker网络的可附加属性 #

从你的网络检查信息里看到，lightformsdevops网络的Attachable属性是false，部分场景下这会影响容器间的DNS互通。修改这个属性：

# 先停止应用容器
docker stop clightformsapi
# 更新网络属性
docker network update --attachable true lightformsdevops
# 重新启动应用容器
docker run --net lightformsdevops --name clightformsapi -p 3030:3030 --env-file ~/desenv/.env.prod -d ilightformsapi

可以把这个检查和更新步骤加到GitHub Actions的deploy流程里，避免每次手动操作：

- name: Ensure network is attachable
  run: |
    if ! docker network inspect lightformsdevops | grep -q '"Attachable": true'; then
      docker network update --attachable true lightformsdevops
    fi

把这个步骤放在Run new container之前即可。

3. 临时用IP地址绕过DNS问题测试 #

如果上面的操作没效果，可以先把.env.prod里的数据库主机改成数据库容器的静态IP（172.20.0.2），重新启动应用容器，看能不能正常连接。如果能，就坐实了是DNS解析的问题，再进一步排查Docker的DNS服务。

4. 修复Docker内部DNS服务 #

如果DNS解析还是失败，可以尝试重启Docker守护进程（注意：会停止所有运行中的容器，谨慎操作）：

sudo systemctl restart docker

重启后重新启动两个容器，再测试解析。

5. 强制指定容器的DNS服务器 #

在启动应用容器时，手动指定Docker内部的DNS服务器（127.0.0.11），避免容器使用宿主机的DNS：

docker run --net lightformsdevops --name clightformsapi --dns 127.0.0.11 -p 3030:3030 --env-file ~/desenv/.env.prod -d ilightformsapi

额外建议 #

• 生产环境尽量避免依赖容器名的DNS解析，最好给数据库容器配置固定IP，或者用Docker Compose管理容器，它会自动处理网络和DNS问题；
• 在GitHub Actions的deploy步骤里添加容器健康检查，确保应用启动后能正常连接数据库，而不是只打印"ON AIR"。比如：

- name: Check application connectivity
  run: |
    timeout 30s bash -c 'until curl -s http://localhost:3030/health; do sleep 2; done'

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