为较新的 Auto Deploy 依赖项升级部署

Auto Deploy 是一项将您的应用程序部署到 Kubernetes 集群的功能。它由几个依赖项组成：

  • Auto Deploy 模板是一组使用 auto-deploy-image 的流水线作业和脚本。
  • auto-deploy-image 是与 Kubernetes 集群通信的执行镜像。
  • auto-deploy-app chart 是用于部署应用程序的 Helm chart。

auto-deploy-image 和 auto-deploy-app chart 使用语义版本控制。 默认情况下，您的 Auto DevOps 项目会继续使用稳定且非破坏性的版本。 但是，这些依赖项可以在极狐GitLab 的主要版本中升级，但需要您升级部署的重大变更。

本指南说明如何使用更新或不同主要版本的 Auto Deploy 依赖项升级您的部署。

验证依赖项版本

检查当前版本的过程因您使用的模板而异。首先验证正在使用哪个模板：

  • 对于私有化部署版实例，正在使用与极狐GitLab 包捆绑的稳定 Auto Deploy 模板。
  • 如果满足以下一个条件，则使用 [JihuLab.com 中稳定的 Auto Deploy 模板]：
    • 您的 Auto DevOps 项目没有 .gitlab-ci.yml 文件。
    • 您的 Auto DevOps 项目有一个 .gitlab-ci.yml 并包含 Auto-DevOps.gitlab-ci.yml 模板。
  • 如果同时满足以下两个条件，则使用最新的 Auto Deploy 模板：

如果您知道正在使用什么模板：

  • auto-deploy-image 版本在模板中（例如 auto-deploy-image:v1.0.3）。
  • auto-deploy-app chart 版本位于 auto-deploy-image 仓库中（例如 version: 1.0.3）。

兼容性

下表解释了极狐GitLab 和 Auto Deploy 依赖项之间的版本兼容性：

极狐GitLab 版本 auto-deploy-image 版本 备注
v10.0 到 v14.0 v0.1.0 到 v2.0.0 v0 和 v1 auto-deploy-image 后向兼容
v13.4 及更高 v2.0.0 及更高 v2 auto-deploy-image 包含重大更改，如升级指南中所述。

您可以在 Auto Deploy 稳定模板中找到当前稳定版本的 auto-deploy-image。

升级指南

使用 Auto DevOps 的项目必须使用极狐GitLab 管理的未修改 chart。 自定义 chart 不受支持。

将部署升级到 v1 auto-deploy-image

v1 chart 向后兼容 v0 chart，因此无需更改配置。

将部署升级到 v2 auto-deploy-image

v2 自动部署镜像包含多个依赖项和架构更改。 如果您的 Auto DevOps 项目有一个使用 v1 auto-deploy-image 部署的活动环境，请继续执行以下升级指南。否则，您可以跳过此过程。

Kubernetes 1.16+

v2 auto-deploy-image 放弃了对 Kubernetes 1.15 及更低版本的支持。如果您需要升级 Kubernetes 集群，请按照云提供商的说明进行操作。

Helm v3

auto-deploy-image 使用 Helm 二进制文件来操作发布。 以前，auto-deploy-image 使用 Helm v2，它在集群中使用 Tiller。 在 v2 auto-deploy-image 中，它使用了不再需要 Tiller 的 Helm v3。

如果您的 Auto DevOps 项目具有使用 v1 auto-deploy-image 部署的活动环境，请使用以下步骤升级到使用 Helm v3 的 v2 auto-deploy-image：

  1. 包含 Helm 2to3 迁移 CI/CD 模板：

    • 如果您在 JihuLab.com，或 14.0.1 及更高版本上，则此模板已包含在 Auto DevOps 中。

    • 在其它版本的上，您可以修改 .gitlab-ci.yml 以包含模板：

      include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Jobs/Helm-2to3.gitlab-ci.yml

  2. 设置以下 CI/CD 变量：

    • MIGRATE_HELM_2TO3 为 true。如果此变量不存在，则迁移作业不会运行。
    • AUTO_DEVOPS_FORCE_DEPLOY_V2 为 1.

    • 可选：BACKUP_HELM2_RELEASES 为 1。如果您设置此变量，迁移作业会在名为 helm-2-release-backups 的作业产物中保存 1 周的备份。如果您在准备好之前意外删除了 Helm v2 版本，您可以使用 kubectl apply -f $backup 从 Kubernetes manifest 文件中恢复此备份。

      caution 如果您有公开流水线，请不要使用它。此产物可以包含 secret，并且任何可以看到您的作业的用户都可以看到。
  3. 运行流水线并触发 <environment-name>:helm-2to3:migrate 作业。
  4. 像往常一样部署您的环境。此部署使用 Helm v3。
  5. 如果部署成功，可以安全运行 <environment-name>:helm-2to3:cleanup。这会从命名空间中删除所有 Helm v2 发布数据。
  6. 移除 MIGRATE_HELM_2TO3 CI/CD 变量或将其设置为 false。您可以使用环境范围，一次完成一个环境。

集群内 PostgreSQL Channel 2

v2 auto-deploy-image 放弃了对老式集群内 PostgreSQL 的支持。 如果您的 Kubernetes 集群仍然依赖它，请使用 v1 auto-deploy-image 升级和迁移您的数据。

金丝雀部署和增量部署的流量路由更改

Auto Deploy 支持高级部署策略，例如金丝雀部署和增量部署。

以前，auto-deploy-image 创建了一项服务，通过更改副本比率来平衡不稳定和稳定之间的流量。在 v2 auto-deploy-image 中，使用 Canary Ingress 控制流量。

获取更多详细信息，查看 v2 auto-deploy-app chart resource architecture。

如果您的 Auto DevOps 项目在使用 v1 auto-deploy-image 部署的 production 环境中具有活动的 canary 或 rollout 版本，请使用以下步骤升级到 v2：

  1. 验证您的项目是使用 v1 auto-deploy-image。如果没有，指定版本。
  2. 如果您正在部署 canary 或 rollout 部署，请先将其提升为 production 并删除不稳定的。
  3. 验证您的项目是使用 v2 auto-deploy-image。如果没有，指定版本。
  4. 在 CI/CD 设置中，添加一个值为 true 的 AUTO_DEVOPS_FORCE_DEPLOY_V2 CI/CD 变量。
  5. 创建一个新流水线并运行 production 作业，使用 v2 auto-deploy-app chart 更新资源架构。
  6. 移除 AUTO_DEVOPS_FORCE_DEPLOY_V2 变量。

使用特定版本的 Auto Deploy 依赖项

要使用特定版本的 Auto Deploy 依赖项，请指定包含所需版本的 auto-deploy-image 和 auto-deploy-app 的先前 Auto Deploy 稳定模板。

例如，如果模板捆绑在 13.3 中，请将 .gitlab-ci.yml 更改为：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://jihulab.com/gitlab-cn/gitlab/-/raw/v13.3.0-ee/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml

忽略警告并继续部署

如果您确定新的 chart 版本可以安全部署，您可以添加 AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number> CI/CD 变量来强制继续部署。

例如，如果您想在以前使用 v0.17.0 chart 的部署上部署 v2.0.0 chart，请添加 AUTO_DEVOPS_FORCE_DEPLOY_V2。

早期采用者

如果您想使用最新的 Beta 版或不稳定版本的 auto-deploy-image，请将最新的 Auto Deploy 模板包含到您的 .gitlab-ci.yml 中：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - template: Jobs/Deploy.latest.gitlab-ci.yml
caution 使用 Beta 或不稳定的 auto-deploy-image 可能会对您的环境造成不可恢复的损害。不要用重要的项目或环境对其进行测试。

auto-deploy-app chart 的资源架构

v0 和 v1 chart 资源架构

graph TD; subgraph gl-managed-app Z[Nginx Ingress] end Z[Nginx Ingress] --> A(Ingress); Z[Nginx Ingress] --> B(Ingress); subgraph stg namespace B[Ingress] --> H(...); end subgraph prd namespace A[Ingress] --> D(Service); D[Service] --> E(Deployment:Pods:app:stable); D[Service] --> F(Deployment:Pods:app:canary); D[Service] --> I(Deployment:Pods:app:rollout); E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)] F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)] I(Deployment:Pods:app:rollout)---id1[(Pods:Postgres)] end

v2 chart 资源架构

graph TD; subgraph gl-managed-app Z[Nginx Ingress] end Z[Nginx Ingress] --> A(Ingress); Z[Nginx Ingress] --> B(Ingress); Z[Nginx Ingress] --> |If canary is present or incremental rollout/|J(Canary Ingress); subgraph stg namespace B[Ingress] --> H(...); end subgraph prd namespace subgraph stable track A[Ingress] --> D[Service]; D[Service] --> E(Deployment:Pods:app:stable); end subgraph canary track J(Canary Ingress) --> K[Service] K[Service] --> F(Deployment:Pods:app:canary); end E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)] F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)] end

故障排除

主要版本不匹配警告

如果部署的 chart 的主要版本与前一个不同，则可能无法正确部署新 chart。这可能是由于架构更改。如果发生这种情况，部署作业将失败并显示类似于以下内容的消息：

*************************************************************************************
                                   [WARNING]
Detected a major version difference between the chart that is currently deploying (auto-deploy-app-v0.7.0), and the previously deployed chart (auto-deploy-app-v1.0.0).
A new major version might not be backward compatible with the current release (production). The deployment could fail or be stuck in an unrecoverable status.
...

要清除此错误消息并恢复部署，您必须执行以下操作之一：

错误：missing key "app.kubernetes.io/managed-by": must be set to "Helm"

如果您的集群有一个使用 v1 auto-deploy-image 的部署，您可能会遇到以下错误：

  • Error: rendered manifests contain a resource that already exists. Unable to continue with install: Secret "production-postgresql" in namespace "<project-name>-production" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "production-postgresql"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "<project-name>-production"

这是因为之前的部署是使用 Helm2 部署的，与 Helm3 不兼容。 要解决此问题，请按照升级指南。