{{< 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的主要版本发布中升级,并且可能包含破坏性更改,要求您升级您的部署。
本指南解释了如何使用更新或不同的主要版本的自动部署依赖项来升级您的部署。
验证依赖版本
检查当前版本的过程根据您使用的模板而有所不同。首先验证正在使用哪个模板:
- 对于极狐GitLab私有化部署实例,正在使用与极狐GitLab软件包捆绑的稳定自动部署模板。
- 如果以下之一为真,则正在使用极狐GitLab.com稳定自动部署模板:
- 您的自动 DevOps 项目没有
.gitlab-ci.yml
文件。 - 您的自动 DevOps 项目有
.gitlab-ci.yml
文件并且包含Auto-DevOps.gitlab-ci.yml
模板。
- 您的自动 DevOps 项目没有
- 如果以下两者为真,则正在使用最新自动部署模板:
如果您知道正在使用哪个模板:
-
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:
-
- 如果您在 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
-
设置以下 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 >}}
-
- 运行一个流水线并触发
<environment-name>:helm-2to3:migrate
作业。 - 像往常一样部署您的环境。此部署使用 Helm v3。
- 如果部署成功,您可以安全地运行
<environment-name>:helm-2to3:cleanup
。这会删除命名空间中的所有 Helm v2 发布数据。 - 移除
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:
- 验证您的项目是否使用 v1
auto-deploy-image
。如果没有,指定版本。 - 如果您正在进行
canary
或rollout
部署,请先将它们提升为production
以删除不稳定轨道。 - 验证您的项目是否使用 v2
auto-deploy-image
。如果没有,指定版本。 - 在极狐GitLab CI/CD 设置中添加一个值为
true
的AUTO_DEVOPS_FORCE_DEPLOY_V2
CI/CD 变量。 - 创建一个新的流水线并运行
production
作业,以使用 v2auto-deploy-app chart
更新资源架构。 - 移除
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 资源架构
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 不兼容。要解决此问题,请遵循升级指南。