极狐 GitLab Logo

升级极狐GitLab chart

在升级您的极狐GitLab 实例之前，您需要检查要升级的特定版本对应的 变更记录。

升级必须要遵循支持的升级路径。因为极狐GitLab chart 的版本并不跟随极狐GitLab 的版本，两者之间的详情可以查看版本映射。

NOTE: 零停机升级不适用于 GitLab charts。

我们还建议您先进行 备份。请注意必须使用 helm upgrade --set key=value 语法或 -f values.yaml 提供所有 value 值，不要使用 --reuse-values，因为某些当前值可能会被废弃。

您可以使用 helm get values <release name> 来检索您以前的 --set 参数。如果您将其定向到文件中（helm get values <release name> > gitlab.yaml），您可以通过 -f 安全地传递文件，例如 helm upgrade gitlab gitlab-jh/gitlab -f gitlab.yaml，这样可以安全替代使用 --reuse-values 。

操作步骤#

NOTE: 如果您要升级到 7.0 版本的 chart，遵循 7.0 手动升级步骤。 如果您要升级到 6.0 版本的 chart，遵循 6.0 手动升级步骤。如果您要升级到更老的 chart版本，遵循升级到更老版本。

在升级之前，请考虑一下您的设定值以及您是否可能“过度配置”了您的设置。我们希望您维护一小部分修改后的值，并利用大多数 chart 默认值。如果您通过以下方式配置了大量设置：

  • 复制计算设置
  • 复制所有设置并明确定义实际上与默认值相同的值

这几乎肯定会在升级过程中导致问题，因为配置结构可能会在不同版本之间发生变化，会导致应用设置出现问题。我们将在以下步骤中介绍如何检查这一点。

以下是将极狐GitLab 升级到新版本的操作步骤：

  1. 检查要升级的特定版本对应的 变更记录。

  2. 查看部署指导的详细操作步骤。

  3. 使用以下命令提取之前的 --set 参数。

    shell
    helm get values gitlab > gitlab.yaml

  4. 确定升级时需要继承的所有值。极狐GitLab 具有合理的默认值，在升级时，您可以尝试从上述命令中传递所有值，但它可能会导致由于配置在 chart 版本之间发生更改而可能无法顺利映射的场景。我们建议保留您要显式设置的最小的值集，并在升级过程中传递这些值。

  5. 使用上一步中提取的值执行升级：

    shell
    helm upgrade gitlab gitlab-jh/gitlab \
  --version <new version> \
  -f gitlab.yaml \
  --set gitlab.migrations.enabled=true \
  --set ...

在主数据库升级期间，我们要求您将 gitlab.migrations.enabled 设置为 false。确保您明确将其设置回 true 以便未来的更新。

升级捆绑的 PostgreSQL#

NOTE: 如果您未使用捆绑的 PostgreSQL chart（postgresql.install 的值为 false），您不需要执行该步骤。

将捆绑的 PostgreSQL 升级到 version 13#

极狐GitLab 14.1 及更高版本支持 PostgreSQL 13。PostgreSQL 13 带来显着的性能提升。

要升级绑定的 PostgreSQL 到 version 13，需要遵循以下步骤：

  1. 准备好现有的数据库。
  2. 删除现有的 PostgreSQL 数据。
  3. 更新 postgresql.image.tag 的值为 13.6.0，并重新安装 chart 去创建一个新的 PostgreSQL 13 数据库。
  4. 恢复数据库。

将捆绑的 PostgreSQL 升级到 version 12#

作为 5.0.0 发布版本 chart 的一部分，我们将捆绑的 PostgreSQL 版本从 11.9.0 升级到 12.7.0。这并非完全的替代，您需要执行手动步骤去升级数据库，了解操作步骤，请查看 5.0 升级步骤。

升级到 7.0 版本#

WARNING: 如果您要从 6.x 版本的 chart 升级到最新的 7.0 版本，您需要先更新到最新的 6.11.x 补丁版本才能继续升级。7.0 发行说明描述了支持的升级路径。

7.0.x 版本可能需要手动步骤才能执行升级。

  • 如果使用捆绑的 bitnami/Redis 子 chart 来提供集群内 Redis 服务 - 您需要在升级到 GitLab chart 7.0 版之前，手动删除 Redis 的 StatefulSet。按照下面升级捆绑的 Redis 子 chart 中的设置进行操作。

更新捆绑的 Redis 子 chart#

极狐GitLab chart 的 7.0 版，将捆绑的 bitnami/Redis 子 chart 从之前安装的 11.3.4 更新为版本 16.13.2。由于子 chart 中的 redis-master StatefulSet 应用了 matchLabels 的变更，进行升级前，不手动删除 StatefulSet 会导致如下错误：

shell
Error: UPGRADE FAILED: cannot patch "gitlab-redis-master" with kind StatefulSet: StatefulSet.apps "gitlab-redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden

删除 RELEASE-redis-master 的 StatefulSet：

  1. 将 webservice、sidekiq、kas 和 gitlab-exporter 部署的副本缩小到 0：

    shell
    kubectl scale deployment --replicas 0 --selector 'app in (webservice, sidekiq, kas, gitlab-exporter)' --namespace <namespace>

  2. 删除 RELEASE-redis-master StatefulSet：

    shell
    kubectl delete statefulset RELEASE-redis-master --namespace <namespace>
    • <namespace> 应该替换为安装 GitLab chart 的命名空间。

然后按照正常升级步骤。由于 Helm 合并更改的方式，您可能需要手动扩展在第一步中缩小的 deployments。

global.redis.password 的使用#

为了减轻配置类型与使用 global.redis.password 的冲突，我们已弃用 global.redis.password 转而支持 global.redis.auth。

除了显示弃用通知之外 - 如果您执行 helm upgrade 时看到以下警告消息：

plaintext
coalesce.go:199: warning: destination for password is a table. Ignoring non-table value

这表明您正在值文件中设置 global.redis.password。

Ingress userNewIngressForCerts#

如果您正在讲当前的 7.x chart 升级到最新，而且将 global.ingress.useNewIngressForCerts 改为 true，您还必须升级任何既有的 cert-manger Certificate 对象来删除 acme.cert-manager.io/http01-override-ingress-nam 注释。

您必须要做此变更，因为将此属性设为 false（默认的），此注释被默认添加到 Certificates，而且 cert-manger 使用它来确认应该为哪个证书使用哪个 Ingress 方法。仅将此属性修改为 false 并不能自动删除此注释。需要手动执行操作，否则 cert-manager 会持续使用旧的行为来处理已存在的 Ingress 资源。

6.0 升级步骤#

WARNING: 如果您从 5.x 版本的 chart 升级到最新的 6.0 版本，您需要先更新到最新的 5.10.x 补丁版本才能使升级工作。 6.0 发行说明描述了支持的升级路径。

要升级到 6.0 版本，您必须首先使用最新的 5.10.x 补丁版本。6.0 中不需要任何额外的手动更改，因此您可以按照常规版本升级步骤进行升级。

老旧版本升级指南#

如果您正在从比 5.x 还老旧的版本进行升级，查看极狐GitLab 归档文档来访问老旧版本的文档。