Deploy Boards

Deploy Boards

Introduced in 9.0.

GitLab 的部署板提供了Kubernetes上运行的每个 CI 的当前运行状况和状态的综合视图，显示了部署中 Pod 的状态. 开发人员和其他团队成员可以在已经使用的工作流程中逐个窗格地查看发布的进度和状态，而无需访问 Kubernetes.

使用部署板，您可以通过以下优势对部署进行更多了解：

  • 从头开始进行部署，而不仅仅是完成之后
  • 监视跨多个服务器的构建的推出
  • 更详细的状态详细信息（成功，正在运行，失败，待处理，未知）
  • See Canary Deployments

这是生产环境的部署板的示例.

正方形表示与给定环境关联的 Kubernetes 集群中的 Pod. 将鼠标悬停在每个方块上方，可以看到部署的状态. 百分比是已更新到最新版本的 Pod 的百分比.

由于部署板与 Kubernetes 紧密结合，因此需要一些知识. 特别是，您应该熟悉：

由于部署板是针对特定环境的 Kubernetes 吊舱的直观表示，因此存在许多用例. 仅举几例：

  • 您触发了部署，并且有很多容器需要升级，因此您将花费一段时间（您也限制了部署，一次只能删除 X 个容器）. 但是您需要告诉某人何时部署，因此您可以转到环境列表，查看生产环境，以了解每个 Pod 滚动时的实时进度.
  • 您会得到一份报告，说明生产中有些异常，因此您可以查看生产环境以查看正在运行什么，以及部署是否正在进行，是否停止或失败.
  • 您的 MR 看起来不错，但是您希望在登台上运行它，因为登台是在某种程度上更接近生产环境进行设置的. 您转到环境列表，找到您感兴趣的Review App ，然后单击手动操作将其部署到登台.

要显示特定的部署板，您应该：

  1. 用部署阶段定义了一个环境 .

  2. 使 Kubernetes 集群启动并运行.

    在 OpenShift 上运行：如果使用的是 OpenShift，请确保使用的是资源而不是DeploymentConfiguration . 否则，部署板将无法正确渲染. 有关更多信息，请阅读和GitLab 问题＃4584 .

  3. 使用或Kubernetes执行器 .
  4. 在您的项目中为集群配置Kubernetes 集成 . 特别注意 Kubernetes 命名空间，因为部署脚本（由KUBE_NAMESPACE env 变量公开）将需要它.

  5. 确保将 app.gitlab.com/env：$ app.gitlab.com/env: $CI_ENVIRONMENT_SLUG和app.gitlab.com/app: $CI_PROJECT_PATH_SLUG CI_PROJECT_PATH_SLUG 的 Kubernetes 注释应用于部署，副本集和 Pod，其中和$CI_PROJECT_PATH_SLUG是 CI 变量的值. 这样一来，我们便可以在可能有多个的群集/命名空间中查找适当的环境. 这些资源应包含在 Kubernetes 服务设置中定义的名称空间中. 您可以使用 .gitlab-ci.yml模板，该模板具有要使用的预定义阶段和命令，并自动应用注释. 每个项目还需要在 Kubernetes 中具有唯一的名称空间. 下图演示了如何在 Kubernetes 中显示此内容.

    注意：在GitLab 12.1中删除了基于 Kubernetes app标签的匹配. 要迁移，请应用所需的注释（请参见上文），然后重新部署您的应用程序. 如果您使用的是 Auto DevOps，这将自动完成，无需采取任何措施.

完成以上所有设置并且管道至少运行了一次之后，导航至Operations> Environments下的 environment 页面.

默认情况下，部署板是可见的. 您可以显式单击相应环境名称旁边的三角形以隐藏它们.

以下示例是使用两个注释app.gitlab.com/env和启用 Kubernetes 清单部署文件的app.gitlab.com/env ，以启用Deploy Boards ：

注释将应用于部署，副本集和 Pod. 通过更改副本数量，例如kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE} ，您可以从开发板上跟踪实例的 pod.

注意： YAML 文件是静态的. 如果使用kubectl apply ，则必须在kubectl apply之前手动提供项目和环境段，或者创建脚本来替换 YAML 中的变量.

一种流行的 CI 策略，其中将一小部分车队更新为应用程序的新版本.