为较新的 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 DevOps 项目没有
- 如果同时满足以下两个条件,则使用最新的 Auto Deploy 模板:
- 您的 Auto DevOps 项目有一个
.gitlab-ci.yml
文件并包含Auto-DevOps.gitlab-ci.yml
模板。 - 项目还包括最新的 Auto Deploy 模板。
- 您的 Auto DevOps 项目有一个
如果您知道正在使用什么模板:
-
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
:
-
- 如果您在 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
-
设置以下 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 文件中恢复此备份。如果您有公开流水线,请不要使用它。此产物可以包含 secret,并且任何可以看到您的作业的用户都可以看到。
-
- 运行流水线并触发
<environment-name>:helm-2to3:migrate
作业。 - 像往常一样部署您的环境。此部署使用 Helm v3。
- 如果部署成功,可以安全运行
<environment-name>:helm-2to3:cleanup
。这会从命名空间中删除所有 Helm v2 发布数据。 - 移除
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:
- 验证您的项目是使用 v1
auto-deploy-image
。如果没有,指定版本。 - 如果您正在部署
canary
或rollout
部署,请先将其提升为production
并删除不稳定的。 - 验证您的项目是使用 v2
auto-deploy-image
。如果没有,指定版本。 - 在 CI/CD 设置中,添加一个值为
true
的AUTO_DEVOPS_FORCE_DEPLOY_V2
CI/CD 变量。 - 创建一个新流水线并运行
production
作业,使用 v2auto-deploy-app chart
更新资源架构。 - 移除
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
auto-deploy-image
可能会对您的环境造成不可恢复的损害。不要用重要的项目或环境对其进行测试。
auto-deploy-app
chart 的资源架构
v0 和 v1 chart 资源架构
v2 chart 资源架构
故障排除
主要版本不匹配警告
如果部署的 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 不兼容。 要解决此问题,请按照升级指南。