升级过程概述

了解升级 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 实例 高两个版本。

    • 你也可以考虑在升级实例后，将 GitHub Enterprise Server Backup Utilities 升级到较新的版本。 请参阅“关于 GitHub Enterprise Server 的备份服务”。
    • 同样的情况不适用于GitHub Enterprise Server Backup Service，因为它随设备一同提供。

规划维护时段

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

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

      注意

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

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

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

传达您的升级方案

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

准备备份策略

创建备份快照

开始升级过程之前，请确保拥有实例的主节点的最新成功备份快照。 请参阅项目文档中的 关于 GitHub Enterprise Server 的备份服务 以及 READMEGitHub Enterprise Server Backup Utilities

创建 VM 快照

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

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

安装升级包

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

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

完成升级后的任务

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