Azure DevOps CI环境Docker部署ASP.NET Core后端的E2E测试连接问题

1. 确认容器服务是否真正启动并绑定正确地址 #

• 查看容器端口映射状态：在CI流水线中添加docker ps命令，检查目标容器的PORTS列是否显示预期的端口映射（例如0.0.0.0:5000->80/tcp），若未显示，说明docker-compose.yml中的端口配置有误或启动失败。
• 检查容器启动日志：执行docker logs <你的后端容器ID或服务名>，确认是否出现ASP.NET Core的启动成功日志，比如Now listening on: http://[::]:80。如果日志显示绑定到localhost而非0.0.0.0，需要修改ASP.NET Core的启动配置，在Program.cs中指定绑定地址：

  builder.WebHost.UseUrls("http://0.0.0.0:80");
  

2. 排查CI环境的网络可达性 #

• 用容器IP直接测试：先通过docker inspect <容器ID> | grep -oP '"IPAddress": "\K[^"]+'获取容器的内部IP，然后执行curl http://<容器IP>:80/health（替换为你的健康检查路径），如果能访问，说明localhost映射有问题；如果还是拒绝，说明容器内部服务未正常启动。
• 检查CI代理防火墙：如果是自托管代理，确认代理主机的防火墙规则是否允许访问容器暴露的端口；如果是微软托管代理，无需手动配置防火墙，但要确认端口未被代理环境中的其他进程占用。

3. 解决服务启动时机问题 #

• 添加等待逻辑：CI流水线是自动执行，可能服务尚未完全就绪就触发了测试。在测试步骤前加入循环等待脚本：

  MAX_RETRIES=20
  RETRY_COUNT=0
  until curl -s http://localhost:5000/health; do
    RETRY_COUNT=$((RETRY_COUNT+1))
    if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
      echo "Service did not start in time"
      exit 1
    fi
    echo "Waiting for service to start... (Attempt $RETRY_COUNT/$MAX_RETRIES)"
    sleep 3
  done
  

4. 验证静态文件部署与服务配置 #

• 检查前端文件是否正确复制：在CI步骤中，添加docker exec <容器ID> ls /app/wwwroot（替换为你的容器内wwwroot路径），确认前端dist文件是否存在，避免CI中的复制步骤因权限或路径错误导致文件缺失。
• 确认静态文件中间件配置：检查ASP.NET Core的Program.cs，确保app.UseStaticFiles()在管道中正确配置，且位置在路由配置之前。

5. 优化Docker网络配置 #

• 自定义网络下的服务访问：如果使用自定义桥接网络，且E2E测试是在另一个容器中运行，需将测试容器加入同一网络，并通过服务名访问（例如http://backend-service:80/health），而非localhost。
• 针对Windows代理的host网络适配：如果CI代理是Windows系统，network_mode: host在Docker Desktop中存在限制，建议改用端口映射，并确保测试步骤使用代理主机的localhost访问。

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