Help us learn about your current experience with the documentation. Take the survey.

在 GitLab 开发中使用审查应用

审查应用通过 start-review-app-pipeline 作业部署，该作业会触发一个包含一系列作业的子流水线，以执行部署审查应用所需的各项任务。

要启动审查应用，请在合并请求中添加 pipeline:run-review-app 标签，并触发新的 CI/CD 流水线。

绕过失败的审查应用部署以合并损坏的 `master` 修复

如果由于审查应用部署失败导致客户关键的合并请求被流水线阻塞，维护者可以选择使用在损坏的 master 合并期间的过程。

性能指标

在 qa 阶段的每个审查应用子流水线中，browser_performance 作业会自动启动：该作业使用 Sitespeed.io 容器进行基本的浏览器性能测试。

审查应用的示例数据

审查应用部署后，项目数据会从 sample-gitlab-project 模板项目创建。这旨在为项目提供预填充的资源，以方便手动和探索性测试。

示例项目将在 root 用户命名空间中创建，并可以从该用户的个人项目列表中访问。

如何操作

从干净状态重新部署审查应用

要重置审查应用并从干净的状态重新部署，请执行以下操作：

运行 review-stop 作业。
通过运行或重试 review-deploy 作业来重新部署。

这样做将删除先前部署的审查应用中的所有现有数据。

获取 GCP 审查应用集群的访问权限

您需要为 gcp-review-apps-dev GCP 组和角色提交访问请求（内部链接）。

这为您授予以下权限：

检索 Pod 日志。由 Viewer (roles/viewer) 授予。
运行 Rails 控制台。由 Kubernetes Engine Developer (roles/container.pods.exec) 授予。

登录我的审查应用

仅限 GitLab 团队成员。如果您想登录审查应用，请查看共享 1Password 账户的 GitLab 手册信息。

默认用户名是 root。
密码可以在名为 GitLab EE Review App 的 1Password 登录项中找到。

为我的审查应用启用功能标志

打开您的审查应用并按照上述方式登录。
创建个人访问令牌。
使用功能标志 API 启用功能标志。

查找我的审查应用 slug

打开 review-deploy 作业。
查找 ** Deploying review-*。
例如对于 ** Deploying review-1234-abc-defg... **，您的审查应用 slug 在此情况下将是 review-1234-abc-defg。

运行 Rails 控制台

确保您首先拥有集群访问权限和 container.pods.exec 权限。
按您的审查应用 slug 过滤工作负载。例如，review-qa-raise-e-12chm0。
查找并打开 toolbox 部署。例如，review-qa-raise-e-12chm0-toolbox。
在 “Managed pods” 部分中选择 Pod。例如，review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz。
选择 KUBECTL 下拉列表，然后选择 Exec -> toolbox。
将默认命令中的 -c toolbox -- ls 替换为 -it -- gitlab-rails console，或者
- 运行 kubectl exec --namespace review-qa-raise-e-12chm0 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz -it -- gitlab-rails console 并
  - 将 review-qa-raise-e-12chm0-toolbox-d5455cc8-2lsvz 替换为您的 Pod 名称。

深入 Pod 的日志

确保您首先拥有集群访问权限和 container.pods.getLogs 权限。
按您的审查应用 slug 过滤工作负载。例如，review-qa-raise-e-12chm0。
查找并打开 migrations 部署。例如，review-qa-raise-e-12chm0-migrations.1。
在 “Managed pods” 部分中选择 Pod。例如，review-qa-raise-e-12chm0-migrations.1-nqwtx。
选择 Container logs。

或者，您可以使用 Logs Explorer，它提供了更多搜索日志的功能。Pod 名称的示例查询如下：

resource.labels.pod_name:"review-qa-raise-e-12chm0-migrations"

工作原理

CI/CD 架构图

graph TD
  A["build-qa-image, compile-production-assets<br/>(canonical default refs only)"];
  B1[start-review-app-pipeline];
  B[review-build-cng];
  C["review-deploy<br><br>Helm deploys the review app using the Cloud<br/>Native images built by the CNG-mirror pipeline.<br><br>Cloud Native images are deployed to the #96;review-apps#96;<br>Kubernetes (GKE) cluster, in the GCP #96;gitlab-review-apps#96; project."];
  D[CNG-mirror];

  A --> B1
  B1 --> B
  B -.->|triggers a CNG-mirror pipeline| D
  D -.->|depends on the multi-project pipeline| B
  B --> C

subgraph "1#46; gitlab-org/gitlab parent pipeline"
  A
  B1
  end

subgraph "2#46; gitlab-org/gitlab child pipeline"
  B
  C
  end

subgraph "CNG-mirror pipeline"
  D>Cloud Native images are built];
  end

详细说明

在 prepare 阶段的每个流水线中，compile-production-assets 作业会自动启动。
- 完成后，review-build-cng 作业会启动，因为下一步触发的 CNG-mirror 流水线依赖于它。
一旦 compile-production-assets 完成，review-build-cng 作业会在 CNG-mirror 项目中触发一个流水线。
- 仅当您的 MR 包含 CI 或前端更改时，review-build-cng 作业才会自动启动。在其他情况下，该作业是手动执行的。
- CNG-mirror 流水线根据 GitLab 流水线的提交创建每个组件的 Docker 镜像（例如 gitlab-rails-ee、gitlab-shell、gitaly 等）并将它们存储在其注册表中。
- 我们使用 CNG-mirror 项目，以便 CNG（云原生 GitLab）项目的注册表不会被大量临时 Docker 镜像过载。
一旦 review-build-cng 完成，review-deploy 作业使用官方 GitLab Helm chart 将审查应用部署到 GCP 上的 review-apps Kubernetes 集群。
- 实际用于部署审查应用的脚本可以在 scripts/review_apps/review-apps.sh 中找到。
- 这些脚本基本上是我们的官方 Auto DevOps 脚本，其中默认的 CNG 镜像被覆盖为在 CNG-mirror 项目注册表中构建和存储的镜像。
- 由于我们使用官方 GitLab Helm chart，这意味着您的分支会获得一个专用的环境，该环境与生产环境非常接近。
- 每个审查应用都部署到其自己的 Kubernetes 命名空间中。命名空间基于每个分支唯一的审查应用 slug。
一旦 review-deploy 作业成功，您应该能够通过 MR 小部件中的直接链接使用您的审查应用。要登录审查应用，请参阅下面的"登录我的审查应用？"。

附加说明：

如果 review-deploy 作业持续失败（手动重试也无济于事），在 #g_qe_engineering_productivity 频道中留言，或创建一个带有合并请求链接的 ~"Engineering Productivity" ~"dx::review apps" ~"type::bug" 问题。部署失败可能揭示您的合并请求中引入的实际问题（即这不一定是临时故障）！
手动 review-stop 可以手动停止审查应用，并且在合并请求的分支被合并后删除时，GitLab 也会启动它。
Kubernetes 集群通过 GitLab Kubernetes 集成连接到 gitlab 项目。这基本上允许从合并请求小部件直接链接到审查应用。

审查应用的自动停止

审查应用在最后一次部署后 2 天会自动停止，这得益于环境自动停止功能。

如果您需要审查应用保持运行更长时间，可以固定其环境或重试 review-deploy 作业来更新"最新部署于"时间。

在计划流水线中自动运行的 review-cleanup 作业会在 5 天后停止过时的审查应用， 6 天后删除其环境，7 天后清理任何悬空的 Helm 发布和 Kubernetes 资源。

集群配置

集群通过 engineering-productivity-infrastructure 项目中的 Terraform 进行配置。

由于 GitLab Runner 的 Kubernetes 执行器存在此已知问题，节点池映像类型必须是 Container-Optimized OS (cos)，而不是 Container-Optimized OS with Containerd (cos_containerd)。

Helm

使用的 Helm 版本在 review-deploy 和 review-stop 作业使用的 registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-helm3.5-kubectl1.17 镜像中定义。

诊断不健康的审查应用发布

如果审查应用稳定性下降，这可能表明 review-apps 集群不健康。领先指标可能是健康检查失败导致重启或审查应用部署的多数失败。

审查应用概览仪表板有助于识别集群上的负载峰值，以及节点是否有问题或整个集群是否趋向于不健康。

有关排查审查应用发布问题，请参阅工程生产力运行手册中的审查应用页面。

常见问题

每次测试运行都触发 CNG 镜像构建会不会太多？这会产生数千个未使用的 Docker 镜像。

我们必须从某个地方开始，然后逐步改进。此外，我们使用 CNG-mirror 项目来存储这些 Docker 镜像，这样我们就可以在某个时候清空注册表，并使用一个新的干净、空的注册表。

我们如何防止滥用？应用是对外开放的，所以我们需要找到一种方法将其限制给我们自己。

这不会为 fork 启用。

其他资源

有用的命令行工具

K9s - 启用跨 Pod 的 CLI 仪表板，并支持按标签过滤
Stern - 支持基于标签/字段选择器的跨 Pod 日志跟踪

返回测试文档