Help us learn about your current experience with the documentation. Take the survey.

多节点升级与停机时间

  • Tier: 免费版、高级版、旗舰版
  • Offering: GitLab 自托管

虽然您可以升级多节点 GitLab 部署 实现零停机， 但存在一些限制。特别是，您每次只能升级一个小版本， 例如从 14.6 升级到 14.7，然后到 14.8，以此类推。

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

对于单节点安装，您只需要 升级 GitLab 包。

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

总体而言，过程如下：

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

停止向数据库写入

升级前，您需要停止向数据库写入。根据您的 参考架构，过程有所不同。

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

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

对于 云原生混合 环境：

  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

升级 Consul 节点

有关完整说明，请参阅 Consul 文档。

总结：

  1. 检查所有 Consul 节点是否健康。

  2. 在所有 Consul 服务器上 升级 GitLab 包。

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

    sudo gitlab-ctl restart

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

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

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

如果您正在运行 Gitaly 集群（Praefect），请遵循 Gitaly 集群（Praefect）的 零停机过程。

如果您在 AWS 上使用 Amazon Machine Images (AMIs)，您可以通过 AMI 过程或升级包本身来升级 Gitaly 节点：

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

但是，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 集群（Praefect）的 Gitaly 节点

对于不属于 Gitaly 集群（Praefect）的 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）

  • Tier: 高级版、旗舰版
  • Offering: GitLab 自托管

遵循 零停机说明 升级您的 Redis HA 集群。

升级 Rails 组件

所有 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

现在所有有状态组件都已升级，您需要遵循 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>

升级 Monitor 节点

升级 GitLab 包。