{{< details >}}

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

{{< /details >}}

自动部署 是一种功能，可以将您的应用程序部署到 Kubernetes 集群。它由几个依赖项组成：

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

auto-deploy-image 和 auto-deploy-app charts 使用语义版本控制。默认情况下，您的自动 DevOps 项目会继续使用稳定且无破坏性版本。然而，这些依赖项可能会在极狐GitLab的主要版本发布中升级，并且可能包含破坏性更改，要求您升级您的部署。

本指南解释了如何使用更新或不同的主要版本的自动部署依赖项来升级您的部署。

验证依赖版本

检查当前版本的过程根据您使用的模板而有所不同。首先验证正在使用哪个模板：

如果您知道正在使用哪个模板：

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

兼容性

下表解释了极狐GitLab与自动部署依赖项之间的版本兼容性：

极狐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-image。

升级指南

使用自动 DevOps 的项目必须使用极狐GitLab管理的未修改 chart。定制的 charts是不支持的。

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

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

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

v2 auto-deploy-image 包含多个依赖项和架构更改。如果您的自动 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 中，它使用 Helm v3，不再需要 Tiller。

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

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

    • 如果您在 JihuLab.com 或极狐GitLab 14.0.1 或更高版本上，此模板已包含在自动 DevOps 中。

    • 在极狐GitLab的其他版本上，您可以修改您的 .gitlab-ci.yml 来包含模板：

      include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://jihulab.com/gitlab-cn/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 的备份，为期一周。如果您在准备好之前意外删除 Helm v2 发布，您可以通过使用 kubectl apply -f $backup 从 Kubernetes 清单文件中恢复此备份。

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

      如果您有公共流水线，请勿使用此功能。该产物可能包含密钥，并对任何能看到您的作业的用户可见。

      {{< /alert >}}

  3. 运行一个流水线并触发 <environment-name>:helm-2to3:migrate 作业。
  4. 像往常一样部署您的环境。此部署使用 Helm v3。
  5. 如果部署成功，您可以安全地运行 <environment-name>:helm-2to3:cleanup。这会删除命名空间中的所有 Helm v2 发布数据。
  6. 移除 MIGRATE_HELM_2TO3 CI/CD 变量或将其设置为 false。您可以使用环境范围逐个环境执行此操作。

In-Cluster PostgreSQL Channel 2

v2 auto-deploy-image 不再支持旧版集群内 PostgreSQL。如果您的 Kubernetes 集群仍然依赖它，请使用 v1 auto-deploy-image 升级并迁移您的数据。

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

自动部署支持高级部署策略，例如金丝雀部署和增量发布。

此前，auto-deploy-image 通过改变副本比例创建一个服务来平衡不稳定和稳定轨道之间的流量。在 v2 auto-deploy-image 中，它通过金丝雀入口控制流量。

有关更多详细信息，请参阅 v2 auto-deploy-app chart 资源架构。

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

  1. 验证您的项目是否使用 v1 auto-deploy-image。如果没有，指定版本。
  2. 如果您正在进行 canary 或 rollout 部署，请先将它们提升为 production 以删除不稳定轨道。
  3. 验证您的项目是否使用 v2 auto-deploy-image。如果没有，指定版本。
  4. 在极狐GitLab 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-image 和 auto-deploy-app 版本的先前自动部署稳定模板。

例如，如果模板捆绑在极狐GitLab 16.10 中，请将您的 .gitlab-ci.yml 更改为：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - remote: https://jihulab.com/gitlab-cn/gitlab/-/raw/v16.10.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。

早期采用者

如果您想使用最新的测试版或不稳定版本的 auto-deploy-image，请将最新自动部署模板包含到您的 .gitlab-ci.yml 中：

include:
  - template: Auto-DevOps.gitlab-ci.yml
  - template: Jobs/Deploy.latest.gitlab-ci.yml

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

使用测试版或不稳定 auto-deploy-image 可能会对您的环境造成不可恢复的损害。不要在重要的项目或环境中进行测试。

{{< /alert >}}

auto-deploy-app chart 的资源架构

v0 和 v1 chart 资源架构

%%{init: { "fontFamily": "GitLab Sans" }}%% graph TD; accTitle: v0 和 v1 chart 资源架构 accDescr: 显示 v0 和 v1 charts 组件之间的关系。 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 资源架构

%%{init: { "fontFamily": "GitLab Sans" }}%% graph TD; accTitle: v2 chart 资源架构 accDescr: 显示 v2 chart 组件之间的关系。 subgraph gl-managed-app Z[Nginx Ingress] end Z[Nginx Ingress] --> A(Ingress); Z[Nginx Ingress] --> B(Ingress); Z[Nginx Ingress] --> |如果有金丝雀或增量发布/|J(Canary Ingress); subgraph stg namespace B[Ingress] --> H(...); end subgraph prd namespace subgraph 稳定轨道 A[Ingress] --> D[Service]; D[Service] --> E(Deployment:Pods:app:stable); end subgraph 金丝雀轨道 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 不兼容。要解决此问题，请遵循升级指南。