如何为GitLab-CI服务配置重启策略，规避启动竞态问题？

针对Service B需等待Service A就绪才能正常启动的场景，无需修改业务镜像的解决方案如下：

方案1：给Service B添加启动前等待逻辑 #

如果myservice-b镜像包含基础shell工具（如bash、curl或nc），可通过覆盖command参数，让Service B先等待Service A就绪，再启动自身主进程。

示例配置：

variables:
  FF_NETWORK_PER_BUILD: 'true' # 为构建创建专属网络

my-test-job:
  services:
    - name: myservice-a:1.0.0
      alias: serva
    - name: myservice-b:1.0.0
      alias: servb
      # 替换为实际的就绪检查方式和Service B启动命令
      command: ["/bin/bash", "-c", "until nc -z serva 8080; do sleep 2; done; exec /usr/local/bin/start-myservice-b"]

• 用nc -z serva 8080检查Service A的8080端口是否就绪，若有HTTP健康检查接口，可替换为curl -s http://serva:8080/health。
• /usr/local/bin/start-myservice-b需替换为镜像中启动Service B的实际命令。

方案2：主任务脚本前置等待Service A就绪 #

GitLab CI默认会尝试重启崩溃的服务容器，因此可在主任务执行测试前，先等待Service A就绪，待Service B自动重启成功后再运行测试。

示例配置：

variables:
  FF_NETWORK_PER_BUILD: 'true'

my-test-job:
  services:
    - name: myservice-a:1.0.0
      alias: serva
    - name: myservice-b:1.0.0
      alias: servb
  script:
    # 等待Service A就绪，添加超时避免无限等待（示例超时5分钟）
    - timeout 300 bash -c 'until curl -s http://serva:8080/health; do sleep 2; done'
    # 执行集成测试
    - ./run-integration-tests.sh

注意事项 #

• 选择适配Service A的就绪检查方式：数据库类服务可使用专属工具（如pg_isready用于PostgreSQL），替代curl或nc。
• 根据服务启动速度调整等待间隔和超时时间，避免不必要的等待或任务挂起。

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