Updating GitLab

原文：https://docs.gitlab.com/ee/update/README.html

Updating GitLab

根据安装方法和您的 GitLab 版本，有多个更新指南.

当前有 3 种官方方法来安装 GitLab：

根据您的安装，在下面选择适合您需要的部分.

Omnibus Packages

Installation from source

过去，我们使用单独的文档来进行升级说明，但是此后我们切换为使用单个文档. 仍然可以在 Git 存储库中找到旧的升级准则：

Installation using Docker

GitLab 提供了针对社区和企业版的官方 Docker 映像. 它们基于 Omnibus 软件包，有关如何更新它们的说明在单独的文档中 .

Upgrading without downtime

从 GitLab 9.1.0 开始，可以升级到较新的主要，次要或补丁版本的 GitLab，而无需使 GitLab 实例脱机. 但是，要使其正常工作，必须满足以下要求：

  • 您一次只能升级 1 个次要版本. 所以从 9.1 到 9.2，而不是 9.3.
  • 您必须使用部署后迁移 （包含在下面的零停机时间更新步骤中）.
  • 您正在使用 PostgreSQL. 从 GitLab 12.1 开始，不支持 MySQL.
  • 多节点 GitLab 实例. 随着服务重启，单节点实例可能会经历短暂的中断.

大多数情况下，如果该修补程序版本不是最新的，则可以从该修补程序版本安全地升级到下一个次要版本. 例如，即使已发布 9.1.2，从 9.1.1 升级到 9.2.0 也应该是安全的. 我们建议您检查当前版本和目标版本之间的所有发行版本，以防它们包含可能需要一次升级 1 个发行版本的任何迁移.

一些版本可能还包含所谓的”后台迁移”. 这些迁移是由 Sidekiq 在后台执行的，通常用于迁移数据. 仅在每月发行版中添加后台迁移.

某些主要/次要版本可能需要完成一组后台迁移. 为了保证这一点，此版本将在继续升级过程之前处理所有剩余的作业. 虽然这不需要停机（如果满足上述条件），但我们建议用户在升级主要/次要版本之间至少保留 1 周，以完成后台迁移. 通过增加可以处理background_migration队列中的作业的 Sidekiq 工作者的数量，可以减少完成这些迁移所需的时间. 要查看此队列的大小， 请在升级之前检查后台迁移 .

根据经验，任何小于 10 GB 的数据库都不会花费太多时间进行升级. 每个次要版本最多可能需要一个小时. 但是，较大的数据库可能需要更多时间，但这在很大程度上取决于数据库的大小和正在执行的迁移.

Examples

为了帮助解释这一点，让我们看一些示例.

示例 1：您正在使用版本 9.4.2（这是 9.4 的最新修补程序版本）运行大型的 GitLab 安装. 如果满足上述要求，则在发布 GitLab 9.5.0 时，可以安全地将此安装升级到 9.5.0，而无需停机. 您也可以跳过 9.5.0 并在其发布后升级到 9.5.1，但是不能直接升级到 9.6.0. 您必须先升级到 9.5.x 版本.

范例 2： You are running a large GitLab installation using version 9.4.2, which is the latest patch release of 9.4. GitLab 9.5 includes some background migrations, and 10.0 will require these to be completed (processing any remaining jobs for you). Skipping 9.5 is not possible without downtime, and due to the background migrations would require potentially hours of downtime depending on how long it takes for the background migrations to complete. To work around this you will have to upgrade to 9.5.x first, then wait at least a week before upgrading to 10.0.

示例 3：您将 MySQL 用作 GitLab 的数据库. 对新的主要/次要版本的任何升级都将需要停机. 如果发行版包含任何后台迁移，则可能会导致数小时的停机时间，具体取决于数据库的大小. 要解决此问题，您将必须使用 PostgreSQL 并满足上述其他在线升级要求.

Steps

无需停机即可进行升级的步骤.

Checking for background migrations before upgrading

某些主要/次要版本可能需要完成一组后台迁移. 可以通过运行以下命令找到剩余的迁移作业数：

对于所有安装

如果使用的是 GitLab 12.9 及更高版本，请运行：

  1. sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'

如果使用的是 GitLab 12.8 及更早版本，请使用Rails 控制台运行以下命令：

  1. puts Sidekiq::Queue.new("background_migration").size
  2. Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size

对于源安装

如果使用的是 GitLab 12.9 及更高版本，请运行：

  1. cd /home/git/gitlab
  2. sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'

如果使用的是 GitLab 12.8 及更早版本，请使用Rails 控制台运行以下命令：

  1. puts Sidekiq::Queue.new("background_migration").size
  2. Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size

What do I do if my background migrations are stuck?

警告：以下操作可能会破坏您的 GitLab 性能.注意：重新执行这些命令是安全的，尤其是当您有 1000 个以上的挂起作业可能会溢出运行时内存时.

对于所有安装

  1. # Start the rails console
  2. sudo gitlab-rails c
  4. # Execute the following in the rails console
  5. scheduled_queue = Sidekiq::ScheduledSet.new
  6. pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
  7. pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

对于源安装

  1. # Start the rails console
  2. sudo -u git -H bundle exec rails RAILS_ENV=production
  4. # Execute the following in the rails console
  5. scheduled_queue = Sidekiq::ScheduledSet.new
  6. pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
  7. pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

Upgrading to a new major version

主要版本保留用于向后不兼容的更改. 我们建议您首先升级到主要版本中的最新可用次要版本. 请按照升级建议确定支持的升级路径.

升级到新的主要版本之前，您应确保已完成以前版本的所有后台迁移作业. 要查看background_migration队列的当前大小， 请在升级之前检查后台迁移 .

Upgrading between editions

GitLab 有两个版本： 社区版是 MIT 许可，以及企业版 ，其基于社区版的顶部，包括额外的功能，主要是针对机构拥有超过 100 个用户.

您可以在下面找到一些指南，以帮助您轻松更改版本.

Community to Enterprise Edition

注意：以下指南仅适用于企业版的订户.

如果您希望将 GitLab 安装从 Community 升级到 Enterprise Edition，请根据安装方法遵循以下指南：

  • 从 CE 到 EE 的源更新指南 -步骤与版本升级非常相似：停止服务器，获取代码，更新新功能的配置文件，安装库并进行迁移，更新初始化脚本，启动应用程序并检查其功能状态.
  • Omnibus CE to EE-按照本指南将您的 Omnibus GitLab 社区版更新为企业版.

Enterprise to Community Edition

如果您需要将 Enterprise Edition 安装降级回 Community Edition，则可以按照本指南进行操作，以使过程尽可能的顺利.

Version specific upgrading instructions

13.2.0

由于 Rails 的重大更改可能会导致授权问题，因此具有多个 Web 节点的 GitLab 安装将需要先升级到 13.1，然后再升级到 13.2（及更高版本）.

13.1.0

在 13.1.0 中，您必须升级到以下任一版本：

  • 至少是 Git v2.24（以前，最低要求是 Git v2.22）.
  • 推荐的 Git v2.26.

否则，由于使用新的--end-of-options Git 标志，某些 RPC 中的 Gitaly 服务将导致内部错误.

此外，在 GitLab 13.1.0 中， Rails的版本从 6.0.3 升级到 6.0.3.1 . Rails 升级包括对 CSRF 令牌生成的更改，此更改不向后兼容-具有新 Rails 版本的 GitLab 服务器将生成 CSRF 令牌，而具有较旧 Rails 版本的 GitLab 服务器无法识别-这可能导致非 GET 请求失败用于多节点 GitLab 安装 .

因此，如果您正在使用多个 Rails 服务器，并专门从 13.0 升级，则必须先将所有服务器升级到 13.1.0，然后再升级到更高版本：

  1. 确保所有 GitLab Web 节点都在 GitLab 13.1.0 上.

  2. （可选）启用global_csrf_token功能标记以启用 CSRF 令牌生成的新方法：

    1. Feature.enable(:global_csrf_token)

  3. 只有这样，才能继续升级到更高版本的 GitLab.

12.2.0

在 12.2.0 中，我们启用了 Rails 的身份验证 cookie 加密. 旧会话将自动升级.

但是，不支持会话 cookie 降级. 因此，升级到 12.2.0 后，任何降级都将导致所有会话无效，并且用户将注销.

12.0.0

在 12.0.0 中，我们进行了各种与数据库相关的更改. 这些更改要求用户首先升级到最新的 11.11 修补程序版本. 升级到 11.11.x 之后，用户可以升级到 12.0.x. 否则可能导致未应用数据库迁移，这可能导致应用程序错误.

还需要先升级到 12.0.x，然后再升级到 12.x 的更高版本.

示例 1：您当前正在使用 GitLab 11.11.8，它是 11.11.x 的最新补丁程序版本. 您可以照常升级到 12.0.x.

示例 2：您当前使用的是 GitLab 10.x 版本. 要升级，请先升级到最新的 10.x 版本（10.8.7），然后再升级到最新的 11.x 版本（11.11.8）. 升级到 11.11.8 后，您可以安全地升级到 12.0.x.

有关更多信息，请参见我们的升级路径文档 .

Miscellaneous