LocalStack+TestContainers集成测试本地成功，GitLab流水线报404

以下是针对该问题的具体排查方向，按优先级排序：

1. 确认容器间网络可达性 #

• 本地环境中应用直接访问localhost:4566即可，但GitLab Runner的Docker executor环境下，容器间通信不能用localhost，需使用TestContainers提供的LocalStack容器内部地址/hostname。检查测试代码中AWS客户端的endpointOverride配置，是否正确使用了TestContainers暴露的容器地址（比如通过localstackContainer.getHost() + localstackContainer.getMappedPort(4566)拼接）。
• 在CI流水线中添加调试步骤，比如在应用启动前执行curl http://<localstack-container-ip>:4566/health，验证LocalStack服务是否可访问。若返回404，说明网络存在隔离问题。
• 检查TestContainers配置，确保已显式暴露LocalStack的默认端口4566，比如添加withExposedPorts(4566)。

2. 等待LocalStack服务完全就绪 #

• LocalStack启动后需要时间初始化SQS、DynamoDB等服务，流水线的Runner资源可能受限，启动速度慢于本地。在测试代码中添加就绪等待逻辑：轮询LocalStack的/health接口，直到响应中sqs和dynamodb的状态为available，再执行资源创建操作。
• 示例轮询逻辑（伪代码）：

  while (!localstackHealthCheck()) {
      Thread.sleep(1000);
  }
  

3. 验证AWS客户端配置正确性 #

• 确认AWS客户端（SQSClient、DynamoDbClient）的区域配置为us-east-1（LocalStack默认区域），若配置其他区域会导致服务路由失败。
• 检查凭证配置：LocalStack不需要真实AWS凭证，但客户端默认会尝试签名请求，需显式禁用签名或配置 dummy 凭证（accessKey=test、secretKey=test）。
• 打印客户端发起的请求URL到日志，确认地址是否正确（比如是否误写了端口、域名）。

4. 排查GitLab Runner网络配置 #

• 若使用GitLab共享Runner，检查其网络模式是否为bridge。若Runner采用了自定义网络隔离策略，需将应用容器与LocalStack容器加入同一Docker网络。
• 在CI配置中显式创建并指定网络：

  services:
    - docker:dind
  before_script:
    - docker network create test-network
  

  同时在TestContainers启动LocalStack时指定该网络。

5. 增强日志捕获能力 #

• 启动LocalStack时设置环境变量LOCALSTACK_DEBUG=1，开启详细日志，捕获所有到达LocalStack的请求细节，确认应用的请求是否真的送达服务端。
• 在CI流水线中配置失败后保留容器，通过docker logs <localstack-container-id>提取完整日志，排查请求未被捕获的原因。
• 在应用代码中添加HTTP请求日志，打印请求的URL、Headers和Body，确认请求格式是否符合LocalStack的要求。

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