其他分享
首页 > 其他分享> > 升级 GitLab

升级 GitLab

作者：互联网

升级 GitLab 

所有等级 自我管理

升级 GitLab 是一个相对简单的过程，但根据您使用的安装方法、您的 GitLab 版本的旧版本、是否升级到主要版本等，复杂性可能会增加。

请务必阅读整个页面，因为它包含与每种升级方法相关的信息。

将 GitLab 升级到最新的可用补丁版本，例如13.8.8而不是13.8.0. 这包括您必须在升级路径上停留的版本，因为可能有与升级过程相关的问题的修复程序。

该维修策略文档 有关于升级，包括额外的信息：

根据安装方式升级

根据安装方式和你的 GitLab 版本，官方有多种更新 GitLab 的方式：

Linux 包（综合 GitLab）

该软件包升级指南 包含更新官方GitLab仓库安装了一个包所需的步骤。

当您想要更新到特定版本时，也有说明 。

从源安装

过去，我们使用单独的文档来进行升级说明，但此后我们转而使用单个文档。旧的升级指南仍然可以在 Git 存储库中找到：

使用 Docker 安装

GitLab 为社区版和企业版提供官方 Docker 镜像。它们基于 Omnibus 包，有关如何更新它们的说明位于单独的文档中。

使用 Helm 安装

GitLab 可以使用 Helm 部署到 Kubernetes 集群中。有关如何更新云原生部署的说明位于 单独的文档中。

使用 从图表版本到 GitLab 版本的版本映射来确定升级路径。

计划您的升级

请参阅指南以计划您的 GitLab 升级。

升级前检查后台迁移

在更新到较新版本之前，某些版本可能需要完成不同的迁移。

批量迁移是 GitLab 14.0 及更高版本中可用的迁移类型。后台迁移和批量迁移不一样，所以你应该在更新之前检查两者是否完整。

通过增加 可以处理队列中作业的Sidekiq 工作器的数量来减少完成这些迁移所需的时间 background_migration。

后台迁移

对于 Omnibus 安装：

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

对于从源安装：

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

批量后台迁移

GitLab 14.0 引入了批量后台迁移。

某些安装可能需要运行 GitLab 14.0 至少一天才能完成该升级引入的数据库更改。

检查批量后台迁移的状态

要检查批量后台迁移的状态：

  1. 在顶部栏上，选择菜单 > 管理。

  2. 在左侧边栏上，选择Monitoring > Background Migrations。

    排队批量后台迁移表

Finished在升级 GitLab 之前，所有迁移都必须具有状态。

批量后台迁移的状态也可以直接在数据库中查询。

  1. psql根据您的实例安装方法（例如，sudo gitlab-psql对于 Omnibus 安装）的说明登录提示。

  2. 在psql会话中运行以下查询以查看有关未完成的批处理后台迁移的详细信息：

    select job_class_name, table_name, column_name, job_arguments from batched_background_migrations where status <> 3;

如果迁移未完成并且您尝试更新到更高版本，GitLab 会提示您错误：

Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':

如果出现此错误，请检查批处理后台迁移选项以完成升级。

如果我的后台迁移卡住了怎么办？

以下操作可能会破坏您的 GitLab 性能。

重新执行这些命令是安全的，尤其是当您有 1000 多个可能会溢出运行时内存的待处理作业时。

用于综合安装

# Start the rails console
sudo gitlab-rails c

# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

对于从源安装

# Start the rails console
sudo -u git -H bundle exec rails RAILS_ENV=production

# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

批量迁移（GitLab 14.0 及更新版本）：

请参阅对批处理后台迁移进行故障排除。

处理运行 CI/CD 管道和作业

如果在 GitLab Runner 处理作业时升级 GitLab 实例，则跟踪更新将失败。当 GitLab 重新上线时，跟踪更新应该会自我修复。但是，根据错误，GitLab Runner 会重试或最终终止作业处理。

至于工件，GitLab Runner 尝试上传它们 3 次，之后作业最终失败。

针对以上两种情况，建议升级前进行以下操作：

  1. 计划您的维护。
  2. 暂停你的跑步者。
  3. 等待所有作业完成。
  4. 升级 GitLab。

检查挂起的高级搜索迁移

此部分仅在您启用了Elasticsearch 集成时适用。

主要版本要求 在主要版本升级之前从当前版本中的最新次要版本完成所有高级搜索迁移。您可以通过运行以下命令来查找挂起的迁移：

用于综合安装

sudo gitlab-rake gitlab:elastic:list_pending_migrations

对于从源安装

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:elastic:list_pending_migrations

如果我的高级搜索迁移卡住了怎么办？

了解如何重试暂停的迁移。

无需停机即可升级

阅读如何在不停机的情况下进行升级。

升级到新的主要版本

升级主要版本需要更多关注。向后不兼容的更改和迁移保留给主要版本。请仔细按照说明进行操作，因为我们无法保证主要版本之间的升级是无缝的。

需要按照以下升级步骤确保主版本升级成功：

  1. 升级到先前主要版本的最新次要版本。
  2. 升级到下一个主要版本 ( X.0.Z)。
  3. 升级到它的第一个次要版本 ( X.1.Z)。
  4. 继续升级到该主要版本的较新版本。

确定支持的升级路径。

在升级到新的主要版本之前，确保所有后台迁移都已完全完成也很重要。要查看background_migration队列的当前大小， 请在升级前检查后台迁移。

如果您已启用Elasticsearch 集成，请确保在当前版本中的最后一个次要版本中完成所有高级搜索迁移。 在继续进行主要版本升级之前，请务必 检查待处理的高级搜索迁移。

如果您的 GitLab 实例有任何关联的运行器，升级 GitLab Runner 以匹配升级到的 GitLab 次要版本非常重要。这是为了确保与 GitLab 版本的兼容性。

升级路径

一次升级跨多个 GitLab 版本只能通过接受停机时间来实现。以下示例假设升级时停机是可以接受的。如果您不想停机，请阅读如何零停机升级。

找到您的版本在下面的升级路径中的位置，并相应地升级 GitLab，同时参考 版本特定的升级说明：

8.11.Z-> 8.12.0-> 8.17.7-> 9.5.10-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17-> 12.10.14-> 13.0.14-> 13.1.11-> 13.8.8->最新13.12.Z->最新14.0.Z->最新14.1.Z->最新14.Y.Z

下表虽然并非详尽无遗，但显示了支持的升级路径的一些示例。上述版本之间的附加步骤是可能的。我们只列出了最低限度的必要步骤。

目标版本 你的版本 支持的升级路径 笔记
14.2.6 13.10.2 13.10.2-> 13.12.12-> 14.0.11-> 14.1.8->14.2.6 需要三个中间版本：13.12、14.0、 和14.1，然后14.2.6。
14.1.8 13.9.2 13.9.2-> 13.12.12-> 14.0.11->14.1.8 需要两个中间版本：13.12和14.0，然后14.1.8。
13.12.10 12.9.2 12.9.2-> 12.10.14-> 13.0.14-> 13.1.11-> 13.8.8->13.12.10 需要四个中间版本：12.10、13.0、13.1和13.8.8，然后13.12.10。
13.2.10 11.5.0 11.5.0-> 11.11.8-> 12.0.12-> 12.1.17-> 12.10.14-> 13.0.14-> 13.1.11->13.2.10 需要六个中间版本：11.11、12.0、12.1、12.10、13.0和13.1，然后13.2.10。
12.10.14 11.3.4 11.3.4-> 11.11.8-> 12.0.12-> 12.1.17->12.10.14 需要三个中间版本：11.11,12.0和12.1, 然后12.10.14。
12.9.5 10.4.5 10.4.5-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17->12.9.5 需要四个中间版本：10.8、11.11、12.0和12.1，然后12.9.5。
12.2.5 9.2.6 9.2.6-> 9.5.10-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17->12.2.5 需要五个中间版本：9.5, 10.8, 11.11, 12.0, and 12.1, then 12.2.5。
11.3.4 8.13.4 8.13.4-> 8.17.7-> 9.5.10-> 10.8.7->11.3.4 8.17.7是第 8 版的最后一个版本，9.5.10是第 9 版的最后一个版本，10.8.7是第 10 版的最后一个版本。

版本间升级

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

您可以在下面找到一些帮助您更改 GitLab 版本的指南。

社区到企业版

以下指南仅适用于企业版订阅者。

如果您希望将 GitLab 安装从社区版升级到企业版，请根据安装方法按照以下指南进行操作：

企业到社区版

如果您需要将企业版安装降级回社区版，您可以按照本指南使该过程尽可能顺利。

特定版本升级说明

每个月，GitLab 的主要、次要或补丁版本都会与发布帖子一起 发布。您应该阅读您传递的所有版本的发布帖子。在主要和次要发布帖子的末尾，有三个部分需要专门查找：

这些包括：

除了本节中的说明外，您还应该根据您安装 GitLab 的方式检查特定于安装的升级说明：

以下与 Ruby 和 Git 版本相关的特定信息不适用于Omnibus 安装 和Helm Chart 部署。它们带有适当的 Ruby 和 Git 版本，并且没有使用 Ruby 和 Git 的系统二进制文件。使用这两种方法时无需安装 Ruby 或 Git。

14.5.0

14.4.0

14.3.0

14.2.0

14.1.0

14.0.0

升级到更高版本的 14.Y

13.12.0

请参阅GitLab 13.9 到 14.4 中的维护模式问题。

13.11.0

13.10.0

请参阅GitLab 13.9 到 14.4 中的维护模式问题。

13.9.0

13.8.8

GitLab 13.8 包括后台迁移以解决重复服务记录的问题。如果存在重复的服务，则此后台迁移必须在唯一索引应用于服务表之前完成，这是在 GitLab 13.9中引入的。从 GitLab 13.8 及更早版本升级到更高版本必须包括对 GitLab 13.8.8 的中间升级，并且必须等到后台迁移完成才能继续。

如果仍然存在重复的服务，升级到 13.9.x 或更高版本会导致升级失败并显示以下错误：

PG::UniqueViolation: ERROR:  could not create unique index "index_services_on_project_id_and_type_unique"
DETAIL:  Key (project_id, type)=(NNN, ServiceName) is duplicated.

13.6.0

需要 Ruby 2.7.2。GitLab 不是从 Ruby 2.6.6 或更旧版本开始的。

所需的 Git 版本是 Git v2.29 或更高版本。

13.4.0

GitLab 13.4.0 包括后台迁移，将遗留存储中的所有剩余存储库移动到散列存储。此迁移存在已知问题，已在 GitLab 13.5.4 及更高版本中修复。如果可能，请跳过 13.4.0 并升级到 13.5.4 或更高版本。请注意，迁移可能需要很长时间才能运行，具体取决于必须移动的存储库数量。在进一步升级之前，请务必检查所有后台迁移是否已完成。

13.3.0

推荐的 Git 版本是 Git v2.28。Git v2.24 所需的最低版本保持不变。

13.2.0

由于 Rails 中的重大更改可能导致授权问题，因此具有多个 Web 节点的 GitLab 安装必须先 升级到 13.1，然后才能升级到 13.2（及更高版本）。

GitLab 13.2.0修复了电子邮件验证绕过。升级后，如果您的某些用户在登录时意外遇到 404 或 422 错误，或者在使用命令行时出现“被阻止”消息，则他们的帐户可能未得到确认。在这种情况下，请让他们查看电子邮件以获取重新确认链接。有关更多信息，请参阅我们对电子邮件确认问题的讨论。

GitLab 13.2.0 依赖于btree_gistPostgreSQL的扩展。对于使用外部管理的 PostgreSQL 设置的安装，如果 GitLab 的数据库用户不是超级用户，请确保 在升级 GitLab 之前手动安装扩展。这对于使用 GitLab 管理的 PostgreSQL 数据库的安装来说不是必需的。

13.1.0

在 13.1.0 中，您必须升级到：

由于使用了新的--end-of-optionsGit 标志，否则会导致某些 RPC 中 Gitaly 服务出现内部错误。

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

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

  1. 确保所有 GitLab Web 节点都运行 GitLab 13.1.Z。

  2. 启用global_csrf_token功能标志以启用CSRF令牌生成的新方法：

    Feature.enable(:global_csrf_token)
  3. 只有这样，才能继续升级到更高版本的 GitLab。

12.2.0

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

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

12.1.0

如果您打算从 升级12.0.Z到12.10.Z，则需要在升级12.1.Z前执行中间升级到，12.10.Z以避免出现#215141 之类的问题。

12.0.0

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

还需要您升级到 12.0.Z，然后再移动到 12.Y 的更高版本。

示例 1：您当前使用的是 GitLab 11.11.8，这是 11.11.Z 的最新补丁版本。您可以像往常一样升级到 12.0.Z。

示例 2：您当前使用的是 GitLab 10.Y 版本。要升级，请先升级到最后一个 10.Y 版本 (10.8.7)，然后再升级到最后一个 11.Y 版本 (11.11.8)。升级到 11.11.8 后，您可以安全地升级到 12.0.Z。

有关 更多信息，请参阅我们关于升级路径的文档。

GitLab 13.9 到 14.4 中的维护模式问题

当维护模式启动时，使用者无法与SSO，SAML，或LDAP登录。

在启用维护模式之前登录的用户将继续登录。如果启用维护模式的管理员丢失了他们的会话，那么他们将无法通过 UI 禁用维护模式。在这种情况下，您可以通过 API 或 Rails 控制台禁用维护模式。

此错误已在 GitLab 14.5.0 中修复，预计将向后移植到 GitLab 14.3 和 14.4。

各种各样的

标签：14.0,GitLab,升级,job,版本,迁移
来源： https://www.cnblogs.com/cndevops/p/15755324.html