• 停止对数据库的写入
• 升级 Consul 节点
• 升级 Gitaly 节点（Praefect / Gitaly 集群）
• 升级不属于 Gitaly 集群的 Gitaly 节点
• 升级 PostgreSQL 节点
• 升级 Patroni 节点
• 升级 PgBouncer 节点
• 升级 Redis 节点
• 升级 Rails 组件
• 升级监控节点

{{< details >}}

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

{{< /details >}}

虽然可以通过零停机时间升级多节点极狐GitLab 部署，但有很多限制。特别是，您只能每次升级一个小版本，例如，从 14.6 升级到 14.7，然后到 14.8，依此类推。

如果您希望一次升级多个小版本（例如，从 14.6 到 14.9），则必须将极狐GitLab 实例下线，这意味着停机。在开始此过程之前，请验证与您的升级路径相关的版本特定升级说明：

• 极狐GitLab 17 更改
• 极狐GitLab 16 更改
• 极狐GitLab 15 更改

对于单节点安装，您只需升级极狐GitLab 软件包。

升级多节点极狐GitLab 安装的多个组件的过程与零停机时间升级的过程相同。区别在于运行 Rails（Puma/Sidekiq）的服务器和事件顺序。

总体流程如下：

1. 关闭极狐GitLab 应用程序。
2. 升级您的 Consul 服务器。
3. 升级其他后端组件：
   • Gitaly、Rails PostgreSQL、Redis、PgBouncer：这些可以按任何顺序升级。
   • 如果您使用来自云平台的 PostgreSQL 或 Redis 并且需要升级，请将 Linux 软件包的说明替换为云提供商的说明。
4. 升级极狐GitLab 应用程序（Sidekiq、Puma）并启动应用程序。

停止对数据库的写入

在升级之前，您需要停止对数据库的写入。根据您的参考架构不同，过程也不同。

{{< tabs >}}

{{< tab title=”Linux package” >}}

关闭在所有运行这些进程的服务器上的 Puma 和 Sidekiq：

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

{{< /tab >}}

{{< tab title=”Cloud Native Hybrid” >}}

对于云原生混合环境：

1. 注意数据库客户端的当前副本数量，以便后续重启：

kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}'

1. 停止数据库的客户端：

kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0

{{< /tab >}}

{{< /tabs >}}

升级 Consul 节点

请参考 Consul 文档以获取完整说明。

总结：

1. 检查所有 Consul 节点是否健康。
2. 在所有 Consul 服务器上升级极狐GitLab 软件包。

3. 一次一个节点重启所有极狐GitLab 服务：

   sudo gitlab-ctl restart
   

如果您的 Consul 集群进程不在它们自己的服务器上，并且与 Redis HA 或 Patroni 等其他服务共享，请确保在升级这些服务器时遵循以下原则：

• 不要一次重启多个服务器上的服务。
• 在升级或重启服务之前检查 Consul 集群是否健康。

升级 Gitaly 节点（Praefect / Gitaly 集群）

如果您正在运行 Gitaly 集群，请按照Gitaly 集群的零停机时间过程。

如果您在 AWS 上使用 Amazon 机器映像（AMI），您可以通过 AMI 过程升级 Gitaly 节点，或者升级软件包本身：

• 如果您使用弹性网络接口（ENI），您可以通过 AMI 过程进行升级。使用 ENI，您可以在 AMI 实例更改期间保留私有 DNS 名称，这是 Gitaly 能够正常工作的关键。
• 如果您没有使用 ENI，您必须使用极狐GitLab 软件包升级 Gitaly。这是因为 Gitaly 集群通过服务器主机名跟踪 Git 仓库的副本，而使用 AMI 进行重新部署会为节点分配新的主机名。即使存储相同，Gitaly 集群在主机名更改时无法正常工作。

然而，Praefect 节点可以通过使用 AMI 重新部署过程来升级：

1. AMI 重新部署过程必须包括 gitlab-ctl reconfigure。在 AMI 上设置 praefect['auto_migrate'] = false，使所有节点都获得此设置。这可以防止 reconfigure 自动运行数据库迁移。
2. 第一个使用升级映像重新部署的节点应该是您的部署节点。
3. 部署后，在 gitlab.rb 中设置 praefect['auto_migrate'] = true 并通过 gitlab-ctl reconfigure 应用。这将运行数据库迁移。
4. 重新部署您的其他 Praefect 节点。

升级不属于 Gitaly 集群的 Gitaly 节点

对于不属于 Gitaly 集群的 Gitaly 服务器，升级极狐GitLab 软件包。

如果您有多个 Gitaly 分片或使用 NFS 的多个负载均衡 Gitaly 节点，升级 Gitaly 服务器的顺序无关紧要。

升级 PostgreSQL 节点

对于非集群 PostgreSQL 服务器：

1. 升级极狐GitLab 软件包。

2. 升级过程不会在升级二进制文件时重启 PostgreSQL。重启以加载新版本：

   sudo gitlab-ctl restart
   

升级 Patroni 节点

Patroni 用于实现 PostgreSQL 的高可用性。

如果需要 PostgreSQL 主要版本升级，请遵循主要版本过程。

其他版本的升级过程首先在所有副本上进行。升级后，会发生从领导者到其中一个升级副本的集群故障转移。这确保只需一次故障转移，完成后新的领导者将被升级。

请遵循以下流程：

1. 确定领导者和副本节点，并验证集群是否健康。在数据库节点上运行：

   sudo gitlab-ctl patroni members
   

2. 在一个副本节点上升级极狐GitLab 软件包。

3. 重启以加载新版本：

   sudo gitlab-ctl restart
   

4. 验证集群是否健康。
5. 对其他副本重复这些步骤：升级、重启、健康检查。
6. 根据副本的相同软件包升级升级领导节点。

7. 重启领导节点上的所有服务以加载新版本，并触发集群故障转移：

   sudo gitlab-ctl restart
   

8. 检查集群是否健康。

升级 PgBouncer 节点

如果您在 Rails（应用程序）节点上运行 PgBouncer，那么 PgBouncer 将作为应用程序服务器升级的一部分进行升级。

在 PgBouncer 节点上升级极狐GitLab 软件包。

升级 Redis 节点

通过升级极狐GitLab 软件包升级独立的 Redis 服务器。

升级 Redis HA（使用 Sentinel）

{{< details >}}

• Tier: 专业版，旗舰版
• Offering: 私有化部署

{{< /details >}}

按照零停机时间说明升级您的 Redis HA 集群。

升级 Rails 组件

{{< tabs >}}

{{< tab title=”Linux package” >}}

所有 Puma 和 Sidekiq 进程都已关闭。在每个节点上：

1. 确保 /etc/gitlab/skip-auto-reconfigure 不存在。

2. 检查 Puma 和 Sidekiq 是否已关闭：

   ps -ef | egrep 'puma: | puma | sidekiq '
   

选择一个运行 Puma 的节点。这是您的部署节点，负责运行所有数据库迁移。在部署节点上：

1. 确保服务器已配置为允许常规迁移。检查 /etc/gitlab/gitlab.rb 中不包含 gitlab_rails['auto_migrate'] = false。要么明确设置 gitlab_rails['auto_migrate'] = true 要么省略它以获得默认行为（true）。

2. 如果您使用 PgBouncer：

   您必须绕过 PgBouncer 并直接连接到 PostgreSQL，然后才能运行迁移。

   Rails 在尝试运行迁移时使用建议锁，以防止在同一数据库上运行并发迁移。这些锁未跨事务共享，导致在使用 PgBouncer 以事务池模式运行数据库迁移时出现 ActiveRecord::ConcurrentMigrationError 和其他问题。

   1. 如果您正在运行 Patroni，请找到领导节点。在数据库节点上运行：

      sudo gitlab-ctl patroni members
      

   2. 更新部署节点上的 gitlab.rb。将 gitlab_rails['db_host'] 和 gitlab_rails['db_port'] 更改为：

      • 您的数据库服务器的主机和端口（非集群 PostgreSQL）。
      • 如果您正在运行 Patroni，则为集群领导者的主机和端口。

   3. 应用更改：

      sudo gitlab-ctl reconfigure
      

3. 升级极狐GitLab 软件包。

4. 如果您修改了部署节点上的 gitlab.rb 以绕过 PgBouncer：
   1. 更新部署节点上的 gitlab.rb。将 gitlab_rails['db_host'] 和 gitlab_rails['db_port'] 更改回您的 PgBouncer 设置。

   2. 应用更改：

      sudo gitlab-ctl reconfigure
      

5. 为确保所有服务都运行升级后的版本，并（如果适用）使用 PgBouncer 访问数据库，请重启部署节点上的所有服务：

   sudo gitlab-ctl restart
   

接下来，升级所有其他 Puma 和 Sidekiq 节点。在这些节点的 gitlab.rb 中，设置 gitlab_rails['auto_migrate'] 可以是任何值。

它们可以并行升级：

1. 升级极狐GitLab 软件包。

2. 确保所有服务都已重启：

   sudo gitlab-ctl restart
   

{{< /tab >}}

{{< tab title=”Cloud Native Hybrid” >}}

现在所有状态组件都已升级，您需要遵循极狐GitLab 图表升级步骤以升级无状态组件（Webservice、Sidekiq、其他支持服务）。

在执行极狐GitLab 图表升级后，恢复数据库客户端：

kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

{{< /tab >}}

{{< /tabs >}}

升级监控节点

升级极狐GitLab 软件包。