{{< details >}}

  • Tier: 基础版, 专业版, 旗舰版
  • Offering: JihuLab.com, 私有化部署

{{< /details >}}

{{< history >}}

  • 在极狐GitLab 15.0 中，在私有化部署上禁用。

{{< /history >}}

{{< alert type=”warning” >}}

此功能在极狐GitLab 14.5 中被弃用。

{{< /alert >}}

{{< alert type=”flag” >}}

在极狐GitLab 私有化部署实例上，此功能默认不可用。要使其可用，管理员可以启用名为 certificate_based_clusters 的功能标志。

{{< /alert >}}

极狐GitLab 部署板提供了当前每个 CI 环境运行在 Kubernetes 上的健康状况和状态的统一视图，显示部署中 pod 的状态。开发人员和其他团队成员可以在他们已经使用的工作流中查看滚动更新的进度和状态，无需访问 Kubernetes。

{{< alert type=”note” >}}

如果你有一个 Kubernetes 集群，你可以使用 Auto DevOps 自动部署应用程序到生产环境。

{{< /alert >}}

概述

通过部署板，你可以获得更多关于部署的见解，例如：

  • 从开始跟踪部署，而不仅仅是完成时
  • 观察构建在多个服务器上的滚动更新
  • 更详细的状态信息（成功、运行中、失败、待处理、未知）
  • 查看金丝雀部署

下面是生产环境的一个部署板示例。

deploy boards landing page

这些方块代表与你的 Kubernetes 集群相关的给定环境中的 pod。悬停在每个方块上可以看到滚动更新的状态。百分比表示更新到最新版本的 pod 的比例。

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

使用案例

由于部署板是特定环境中 Kubernetes pod 的可视化表示，因此有很多使用案例。举几个例子：

  • 你想把在 staging 中运行的内容提升到生产环境。你进入环境列表，验证在 staging 中运行的内容是你认为正在运行的，然后选择手动作业部署到生产。
  • 你触发了一个部署，并且有很多容器需要升级，所以你知道这需要一些时间（你也限制了部署一次只能关闭 X 个容器）。但你需要告诉某人什么时候部署完成，所以你进入环境列表，查看生产环境以实时查看每个 pod 的滚动进度。
  • 你收到报告说生产中有些东西不对，所以你查看生产环境以查看正在运行的内容，以及部署是否正在进行中、卡住或失败。
  • 你有一个看起来不错的 MR，但你想在 staging 上运行，因为 staging 的设置方式更接近生产。你进入环境列表，找到你感兴趣的审查应用，然后选择手动操作将其部署到 staging。

启用部署板

要显示特定环境的部署板，你应该：

  1. 已经定义了一个环境并有一个部署阶段。

  2. 有一个 Kubernetes 集群正在运行。

    {{< alert type=”note” >}}

    如果你正在使用 OpenShift，请确保你使用的是 Deployment 资源而不是 DeploymentConfiguration。否则，部署板不能正确渲染。有关详细信息，请阅读 OpenShift 文档 和 极狐GitLab 议题 #4584。

    {{< /alert >}}

  3. 配置极狐GitLab Runner 使用 docker 或 kubernetes 执行器。
  4. 在项目中配置Kubernetes 集成 为集群。Kubernetes 命名空间特别值得注意，因为你需要它用于你的部署脚本（由 KUBE_NAMESPACE 部署变量暴露）。

  5. 确保 app.gitlab.com/env: $CI_ENVIRONMENT_SLUG 和 app.gitlab.com/app: $CI_PROJECT_PATH_SLUG 的 Kubernetes 注释被应用于部署、副本集和 pod，其中 $CI_ENVIRONMENT_SLUG 和 $CI_PROJECT_PATH_SLUG 是 CI/CD 变量的值。这样我们可以在可能有多个环境的集群/命名空间中查找正确的环境。这些资源应该包含在 Kubernetes 服务设置中定义的命名空间中。你可以使用一个自动部署 .gitlab-ci.yml 模板，其中包含预定义的阶段和命令，并自动应用注释。每个项目在 Kubernetes 中必须有一个唯一的命名空间。下面的图片演示了在 Kubernetes 中如何显示。

    如果你使用 GCP 来管理集群，你可以通过导航到 Workloads > deployment name > Details 在 GCP 中查看部署详细信息：

    deploy boards Kubernetes Label

一旦所有上述设置完成并且流水线至少运行了一次，进入 Operate > Environments 下的环境页面。

部署板默认可见。你可以显式选择与其各自环境名称相邻的三角形来隐藏它们。

示例清单文件

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "APPLICATION_NAME"
  annotations:
    app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
    app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "APPLICATION_NAME"
  template:
    metadata:
      labels:
        app: "APPLICATION_NAME"
      annotations:
        app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
        app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}

注释被应用于部署、副本集和 pod。通过改变副本的数量，比如 kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}，你可以从板上跟踪实例的 pod。

{{< alert type=”note” >}}

YAML 文件是静态的。如果你使用 kubectl apply 应用它，你必须手动提供项目和环境标识符，或者创建一个脚本在应用之前替换 YAML 中的变量。

{{< /alert >}}

金丝雀部署

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

阅读更多关于金丝雀部署的信息。

进一步阅读