如何使用多个 Docker 设置 Gitlab CI E2E 测试

Question

我对使用 Gitlab CI 进行自动化测试有点迷失。我希望我能解释我的问题，以便有人可以帮助我。我会先尝试解释情况，然后尝试提出一个问题（这比听起来更难）

情况

建筑学

1. 使用 Jest 单元测试和 Cypress e2e 测试来响应前端
2. Django API 服务器 1 包括 Postgres 数据库和测试
3. 带有 MongoDB 数据库的 Django API 服务器 2（与其他 API 通信）

GitLab

对于 2 个 API，有一个Docker和一个docker-compose文件。这些工作正常并且设置正确。

我们使用 GitLab 进行 CI/CD，按顺序有以下阶段：

1. 构建：其中 1、2 和 3 的 docker 是单独构建的并推送到私有注册表
2. 测试：单元测试和 e2e 测试（应该）运行的地方
3. Release： docker镜像发布的地方
4. 部署：部署 docker 镜像的位置

目标

我想设置 GitLab CI 以运行 cypress 测试。但为此，需要所有构建泊坞窗。目前，在执行端到端测试时，我无法一起使用所有泊坞窗。

问题

我真的不明白我将如何实现这一目标。

• 我可以使用在构建阶段构建的 Docker 进行 e2e 测试吗？有人可以给我一个如何实现这一点的示例吗？（通过将构建 docker 容器作为服务运行？）
• 我是否需要一个包含所有 docker 和数据库的 Docker-compose 文件？
• 我还需要一个吗dind？

我希望有人能给我一些关于如何实现这一目标的建议。举个例子就更好了，但我不知道是否有人愿意这样做。

感谢您抽出时间阅读！

（如果需要） API 服务器示例 1

build-api:
  image: docker:19
  stage: build
  services:
    - docker:19-dind
  script:
    cd api
    docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    docker pull $IMAGE_TAG_API:latest || true
    docker build -f ./Dockerfile --cache-from $IMAGE_TAG_API:latest --tag $IMAGE_TAG_API:$CI_COMMIT_SHA .
    docker push $IMAGE_TAG_API:$CI_COMMIT_SHA

test-api:
  image: docker:19
  stage: test
  services:
    - postgres:12.2-alpine
    - docker:19-dind
  variables:
    DB_NAME: project_ci_test
    POSTGRES_HOST_AUTH_METHOD: trust
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull $IMAGE_TAG_API:$CI_COMMIT_SHA
    - docker run $IMAGE_TAG_API:$CI_COMMIT_SHA sh -c "python manage.py test"
  after_script:
    - echo "Pytest tests complete"
  coverage: "/TOTAL.+ ([0-9]{1,3}%)/"

release-api-staging:
  image: docker:19
  stage: release
  services:
    - docker:19-dind
  only:
    refs: [ master ]
    changes: [ ".gitlab-ci.yml", "api/**/*" ]
  environment:
    name: staging
  script:
    - docker pull $IMAGE_TAG_API:$CI_COMMIT_SHA
    - docker tag $IMAGE_TAG_API:$CI_COMMIT_SHA $IMAGE_TAG_API:latest
    - docker push $IMAGE_TAG_API:latest

Answer 1

答案有点晚了，但我仍然会尝试为其他具有相同问题的开发人员简要解释该方法。我还在 GitLab 中创建了一个示例项目，包含 3 个微服务，其中服务器 A 运行端到端测试并依赖于服务器 B 和服务器 C。

当 e2e 测试全栈应用程序时，您必须：

• 模拟微服务的所有响应
• 针对已部署的环境进行测试；
• 或在管道中临时启动环境

正如您所指出的，您希望在管道中临时启动环境。应采取以下步骤：

1. 将所有后端部署为 GitLab 私有注册表中的 docker 镜像；
2. docker-compose.yml在管道中的 1 项工作中模仿您的服务；
3. 将这些点连接在一起。

将后端部署为 GitLab 私有注册表中的 docker 镜像

首先，您必须在 GitLab 的私有注册表中发布您的 docker 镜像。您这样做是因为您现在可以在其他作业中重复使用这些图像。对于这种方法，您需要docker:dind. 发布到 gitlab 上的私有注册表的简单示例作业如下所示：

before_script:
  - echo -n $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin $CI_REGISTRY

publish:image:docker:
  stage: publish
  image: docker
  services:
    - name: docker:dind
      alias: docker
  variables:
    CI_DOCKER_NAME: ${CI_REGISTRY_IMAGE}/my-docker-image
  script:
    - docker pull $CI_REGISTRY_IMAGE || true
    - docker build --pull --cache-from $CI_REGISTRY_IMAGE --tag $CI_DOCKER_NAME --file Dockerfile .
    - docker push $CI_DOCKER_NAME
  only:
    - master

为了查看真实的示例，我有一个公开的示例项目。

docker-compose.yml在管道中的 1 项工作中模仿您的服务

一旦您对所有后端进行了 Docker 化并在私有注册表上发布了镜像，您就可以开始docker-compose.yml使用 GitLab 作业来模仿您的后端。一个基本的例子：

test:e2e:
   image: ubuntu:20.04
   stage: test
   services:
      - name: postgres:12-alpine
        alias: postgress
      - name: mongo
        alias: mongo
      # my backend image
      - name: registry.gitlab.com/[MY_GROUP]/my-docker-image
        alias: server
   script:
      - curl http://server:3000 # expecting server exposes on port 3000, this should work
      - curl http://mongo:270117 # should work
      - curl http://postgress:5432 # should work!

运行测试

现在一切都在 GitLab 中的单个作业中运行，您只需以分离模式启动前端并运行 cypress 来测试它。例子：

 script:
   - npm run start & # start in detached mode
   - wait-on http://localhost:8080 # see: https://www.npmjs.com/package/wait-on
   - cypress run # make sure cypress is available as well

结论

您docker-compose.yml不应该在管道中运行。使用GitLab 服务来模仿它。对所有后端进行 Docker 化并将其存储在GitLab 的私有注册表中。启动管道中的所有服务并运行测试。

Answer 2

这篇文章可能会带来一些启发。 https://jessie.codes/article/running-cypress-gitlab-ci/ 本质上，您创建了两个 docker 作曲家，一个用于 Cypress 测试，另一个用于要测试的项目。这解决了图像能够访问节点和 docker 的问题。