升级过程概述

了解升级 GitHub Enterprise Server 的建议和要求，以便可以规划和测试升级策略。

在本文中

GitHub Enterprise Server 在不断改进，通过功能和补丁版本引入了新的功能性和 bug 修复。你负责升级到实例。 请参阅“关于升级到新版本”。

若要升级实例，必须：

  1. 通过选择升级版本和相应的升级包并计划维护时段来规划升级策略。
  2. 在升级过程之前和期间传达升级信息。
  3. 通过创建备份和创建虚拟机快照来准备备份策略。
  4. 使用相应的包和方法安装升级包。
  5.        **完成升级后任务**。

应用升级包必须遵循的流程取决于部署拓扑中有多少​​个节点。 本文仅提供有关在独立或高可用性配置中升级实例的一般信息。

规划升级策略

规划升级

  • 在执行升级之前，请查看发行说明和记录的已知问题。 请参阅“发行说明”和“实例升级的已知问题”。
  • 查看“升级要求”以确保了解升级的要求和建议。
  • 检查 你的 GitHub Enterprise Server 实例 的数据磁盘是否至少有 15% 的可用空间。 GitHub 建议确保磁盘上有可用的额外存储空间。 在某些极少数情况下，对于具有大量数据的客户，此阈值可能有所不同。 请参阅“增加存储容量”。
  • 确保您有足够的硬件资源以适用于 GitHub Enterprise Server。 升级时，通过预外部测试检查来评估实例是否满足有关系统硬件资源（例如内存、CPU 核心和用户和根磁盘存储）的最低要求。 如果预外部测试检查确定资源不足，或者因其他原因未通过检查，则系统会通知你并中止升级。
  • 确保拥有 你的 GitHub Enterprise Server 实例 的所有自定义防火墙规则的副本，因为自定义规则在升级后不会保留。 升级后必须重新应用任何自定义规则。 请参阅“配置内置防火墙规则”。
  • 对于高可用性配置中的实例，请在升级前检查复制报告 OK 的状态。 请参阅“监视高可用性系统配置”。
  • 请考虑为维护模式配置 IP 例外列表，以便在升级后可以暂时限制对 你的 GitHub Enterprise Server 实例 的访问来验证服务器运行状况。 请参阅“启用和排定维护模式”。

选择升级版本和包

  • 确定升级策略并选择要升级到的版本。
    • 可将 GitHub Enterprise Server 实例升级到新补丁版或新功能版。
    • 请参阅 升级助手，查找从当前发布版本到新补丁或功能版的升级路径。
  • 选择升级包（热补丁或升级包）。
    • 要升级到补丁版，可使用热补丁或升级包。 要升级到功能版，必须使用升级包。
    • 如果使用升级包进行升级，请为 GitHub Enterprise Server 最终用户安排一个维护时段。 如果你要使用热补丁，则不需要使用维护模式。
    • 如果已启用自动更新检查，则站点管理员将收到通知获悉升级包已下载且可用。 请参阅“启用自动更新检查”。
    • 候选发布版本仅用于测试环境。 请不要在生产环境中安装候选发布版本。 不要从候选发布升级到更高版本，包括正式发布版本。

考虑是否需要其他应用程序更新

检查是否需要升级下列应用程序：

  • 如果 GitHub Actions 将临时自托管运行器用于 你的 GitHub Enterprise Server 实例 并禁用了自动更新，则必须更新 GitHub Actions 运行器。 在执行升级之前，请将运行器升级到所升级实例所需的最低应用程序版本。 要查找release所需的最低版本，请参阅GitHub Enterprise Server 发行版。

  • GitHub Enterprise Server Backup Utilities。 GitHub Enterprise Server Backup Utilities 版本需要与 你的 GitHub Enterprise Server 实例 版本相同，或前者最多比后者低两个版本。

    • 在升级实例之前，可能需要将 GitHub Enterprise Server Backup Utilities 升级到较新版本。
    • 在升级实例后，可能还希望将 GitHub Enterprise Server Backup Utilities 升级到更新的版本。

    请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 使用备份实用程序在实例上配置备份 和 README。

规划维护时段

  • 根据您的升级策略，可能需要显著的停机时间。
  • 确定预期故障时间时长的最佳方法是首先在过渡环境中测试升级。 请参阅“设置暂存实例”。
  • 升级的维护时段取决于所执行升级的类型。

    • 使用热补丁进行升级通常不需要维护窗口。 有时需要重启，不过你可以在之后的某个时间重启。

      注意

      热补丁需要配置运行，这可能会导致 你的 GitHub Enterprise Server 实例 上的部分或所有服务短暂出现错误或无响应。 无需在热补丁安装期间启用维护模式，但这样做将保证用户看到维护页，而不是错误或超时。 请参阅“启用和排定维护模式”。

    • 使用升级包的补丁发布通常需要不到五分钟的停机时间。

    • 升级到包含数据迁移的新功能版可能会导致数小时故障时间，具体取决于存储性能和迁移的数据量。 在此期间，所有用户都无法使用该企业版。 你可能会注意到，升级到新功能版所需的时间更短。 这是因为现在选择性数据库转换将并发运行，并发工作进程数默认为 CPU 核心数，最多为 16 个。

传达您的升级方案

  • 在升级之前，可以发布全局公告横幅，向用户强调重要信息，例如即将发生的更改或可能的故障时间。 请参阅“自定义企业的用户消息”。
  • 在升级时，可以启用维护模式并设置自定义消息来告知用户实例暂时不可用。 请参阅“启用和排定维护模式”。

准备备份策略

创建备份快照

开始升级过程之前，请确保拥有实例的主节点的最新成功备份快照。 请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 使用备份实用程序在实例上配置备份 和 README。

创建 VM 快照

如果要升级到新功能版，则需要虚拟机 (VM) 快照。 如果你要升级到补丁版本，可以连接现有数据磁盘。

在升级之前立即创建实例主节点的虚拟机 (VM) 快照，并且仅在启用维护模式或实例已关闭时创建。 请参阅“生成快照”。

安装升级包

在开始安装升级包之前，请查看升级注意事项，并完成如上所述的所有准备步骤。

升级 GitHub Enterprise Server 实例的说明因所执行的升级类型和实例的节点数而异。

完成升级后的任务

  • 检查后台作业的状态，并查看升级日志中是否有错误。
  • 检查基本 GitHub Enterprise Server 功能。 例如，确保可以通过用户界面登录，并验证多个组织、存储库和问题是否可以按预期访问。 此外，最好使用 SSH 和/或 HTTPS 来手动运行多个 Git 提取、克隆和推送，并检查 API 请求和 Webhook 交付是否成功完成。
  • 重新应用任何自定义防火墙规则。 请参阅“配置内置防火墙规则”。
  • 删除升级前创建的任何 VM 快照。 请参阅“生成快照”。
  • 禁用维护模式，并更新任何升级前通信，如公告横幅。 请参阅“自定义企业的用户消息”和“启用和排定维护模式”。
  • 监视实例上所有排队的后台作业，确保它们成功完成。 请参阅“命令行实用程序”。