4. 测试环境容器化：使用 services 关键字定义数据库、Redis、RabbitMQ 等依赖服务

集成测试的核心挑战之一，是在 CI 作业执行期间快速搭建与生产环境高度一致的依赖服务。手动安装数据库、消息队列或缓存服务不仅耗时，还容易引入环境差异。GitLab CI 的 services 关键字正是为解决此问题而设计——它允许你在作业容器旁启动辅助容器，通过 Docker 网络将它们链接起来，让被测应用像连接本地服务一样访问它们。

4.1 services 关键字的配置模型

在 .gitlab-ci.yml 中，services 是一个顶级或作业级别的关键字，接受一个服务定义列表。每个服务定义至少包含 name（镜像名称），还可选配 alias、entrypoint、command 等参数。

4.2 典型依赖服务的配置清单

下面给出后台任务集成测试中最常用的四种服务配置：PostgreSQL、Redis、RabbitMQ 以及 MinIO（对象存储模拟）。

# .gitlab-ci.yml 片段：services 定义
services:
  - name: postgres:16-alpine
    alias: postgres-db
    variables:
      POSTGRES_DB: test_db
      POSTGRES_USER: tester
      POSTGRES_PASSWORD: test_pass
  - name: redis:7-alpine
    alias: redis-cache
  - name: rabbitmq:3-management-alpine
    alias: message-bus
    variables:
      RABBITMQ_DEFAULT_USER: guest
      RABBITMQ_DEFAULT_PASS: guest
      RABBITMQ_DEFAULT_VHOST: /
  - name: minio/minio:latest
    alias: object-storage
    entrypoint: ["/bin/sh"]
    command: ["-c", "mkdir -p /data/test-bucket && minio server /data"]

4.3 应用代码如何连接 services

由于主容器与 services 处于同一 Docker 网络，应用可以通过服务别名直接连接，无需关心 IP 地址的动态变化。以下是基于 Spring Boot 配置文件的连接示例：

# src/test/resources/application-ci.yml
spring:
  datasource:
    url: jdbc:postgresql://postgres-db:5432/test_db
    username: tester
    password: test_pass
  data:
    redis:
      host: redis-cache
      port: 6379
  rabbitmq:
    host: message-bus
    port: 5672
    username: guest
    password: guest

4.4 services 的生命周期与网络拓扑

4.5 调试 services 启动问题

当作业失败时，定位 services 问题通常需要检查以下几个方面：

1. 服务启动超时：某些服务（如 PostgreSQL）首次启动需要初始化数据目录。如果应用在服务完全就绪前就尝试连接，会导致连接拒绝。解决方案是在测试脚本中添加健康检查重试逻辑。
2. 端口冲突：虽然 services 运行在独立容器中，但如果主容器也监听了相同端口，可能导致不可预知的行为。确保应用端口不与服务端口冲突。
3. 服务日志：在作业日志中，可以看到 service container X started 的条目。如果服务启动失败，Runner 会输出详细错误，例如镜像拉取失败或退出码非零。

before_script:
  - apk add --no-cache postgresql-client curl
  - until pg_isready -h postgres-db -U tester; do echo "等待 PostgreSQL..."; sleep 2; done
  - curl -f http://redis-cache:6379/ || echo "Redis 已启动"
  - rabbitmqctl -h message-bus status || echo "RabbitMQ 状态检查跳过"

4.6 性能与稳定性优化

在复杂的后台任务集成测试中，services 的启动开销不容忽视。以下是经过实践验证的优化策略：

• 使用轻量级镜像：优先选择 Alpine 或 Slim 变体（如 postgres:16-alpine），减少镜像拉取和容器启动时间。
• 固定镜像标签：避免使用 latest 标签，改用明确版本号（如 redis:7.2-alpine），以确保缓存命中并防止非预期的 breaking changes。
• 复用 service 容器：如果你的流水线中有多个作业需要相同的依赖服务，可以考虑通过 needs 和 resource_group 将它们串联起来，避免重复启动。
• 预构建自定义镜像：对于需要大量初始化数据（如预置测试数据集）的服务，建议构建自定义 Docker 镜像，将初始化步骤放入镜像构建层，而非每次 CI 运行时执行。

# 预构建自定义 PostgreSQL 镜像的 Dockerfile 示例
FROM postgres:16-alpine
COPY init-test-data.sql /docker-entrypoint-initdb.d/
# 镜像构建后，直接使用 services: - name: registry.example.com/my-project/postgres-test:16

4.7 常见错误与避坑指南