升级 GitHub Enterprise Server

准备升级

1. 确定升级策略并选择要升级到的版本。 更多信息请参阅“升级要求”。

2. 使用 GitHub Enterprise Server 备份实用程序 创建全新的主实例备份。 更多信息请参阅 GitHub Enterprise Server 备份实用程序 README.md 文件。

3. 如果您要使用升级包进行升级，请为 GitHub Enterprise Server 最终用户排定维护窗口。 如果您要使用热补丁，则不需要使用维护模式。

   注：维护窗口取决于所执行升级的类型。 使用热补丁进行升级通常不需要维护窗口。 有时需要重启，不过您可以在之后的某个时间重启。 按照 MAJOR.FEATURE.PATCH 的版本控制方案，使用升级包的补丁版本通常需要不到 5 分钟的停机时间。 包含数据迁移的功能版本需要的时间更长，具体视存储性能以及迁移的数据量而定。 更多信息请参阅“启用和排定维护模式”。

关于 GitHub Enterprise Server 3.0 及更高版本的最低要求

升级到 GitHub Enterprise Server 3.0 或更高版本之前，请检查您为实例预配的硬件资源。 GitHub Enterprise Server 3.0 引入了 GitHub Actions 和 GitHub Packages 等新功能，比 2.22 和更早版本需要更多的资源。 更多信息请参阅 GitHub Enterprise Server 3.0 发行说明。

GitHub Enterprise Server 3.0 及更高版本的增加要求在下表中以粗体表示。

用户许可	vCPU	内存	附加的存储容量	根存储容量
试用版、演示版或 10 个轻度用户	4 Up from 2	32 GB Up from 16 GB	150 GB Up from 100 GB	200 GB
10-3000	8 Up from 4	48 GB Up from 32 GB	300 GB Up from 250 GB	200 GB
3000-5000	12 Up from 8	64 GB	500 GB	200 GB
5000-8000	16 Up from 12	96 GB	750 GB	200 GB
8000-10000+	20 Up from 16	160 GB Up from 128 GB	1000 GB	200 GB

有关为现有实例调整资源的更多信息，请参阅“增加存储容量”和“增加 CPU 或内存资源”。

生成快照

快照是虚拟机 (VM) 在某一时间点的检查点。 强烈建议在升级虚拟机之前生成快照，这样一来，如果升级失败，您可以将 VM 还原到快照状态。 如果您要升级到新的功能版本，则必须生成 VM 快照。 如果您要升级到补丁版本，可以连接现有数据磁盘。

有两种类型的快照：

• VM 快照会保存整个 VM 状态，包括用户数据和配置数据。 此快照方法需要占用大量磁盘空间，且比较耗时。

• 数据磁盘快照仅会保存您的用户数据。

  注意：

  • 某些平台不允许您只生成数据磁盘的快照。 对于此类平台，您需要生成整个 VM 的快照。
  • 如果您的虚拟机监控程序不支持完整的 VM 快照，您应连续、快速地生成根磁盘和数据磁盘的快照。

平台	快照方法	快照文档 URL
Amazon AWS	磁盘	https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Azure	VM	https://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-V	VM	https://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute Engine	磁盘	https://cloud.google.com/compute/docs/disks/create-snapshots
VMware	VM	https://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServer	VM	https://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

使用热补丁升级

您可以使用热更新将 GitHub Enterprise Server 升级为最新的补丁版本，它不需要维护时间窗，通常不需要重启。 您可以使用热更新来升级到更新的补丁版本，但不能升级到功能版本。 例如，您可以从 2.10.1 升级到 2.10.5，因为它们属于相同的功能系列，但不能从 2. 0.9 升级到 2.11.0，因为它们处于不同的功能系列中。 利用 管理控制台，您可以立即安装热补丁，也可以排定稍后安装热补丁。 您可以使用管理 shell 的 ghe-upgrade 实用程序安装热补丁。 更多信息请参阅“升级要求”。

使用热补丁升级单个设备

使用 管理控制台 安装热补丁

1. 启用自动更新。 更多信息请参阅“启用自动更新”。
2. 从 GitHub Enterprise Server 上的管理帐户，点击任何页面右上角的 。
3. 在左侧边栏中，单击 管理控制台。
4. 在 管理控制台 顶部，单击 Updates（更新）。
5. 在新的热补丁下载完毕后，请使用 Install package 下拉菜单：
   • 要立即安装，请选择 Now：
   • 要稍后安装，请选择以后的日期。
6. 单击 Install（安装）。

使用管理 shell 安装热补丁

1. SSH 连接到 您的 GitHub Enterprise Server 实例。 更多信息请参阅“访问管理 shell (SSH)。”

   $ ssh -p 122 admin@HOSTNAME

2. 浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边，单击 Download（下载），然后单击 Upgrading（升级）选项卡。 复制升级热补丁包（.hpkg 文件）的 URL。
3. 使用 curl 将升级包下载到 您的 GitHub Enterprise Server 实例：

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. 使用包文件名运行 ghe-upgrade 命令：

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
   *** verifying upgrade package signature...

5. 如果更新内核、MySQL、Elasticsearch 或其他程序时需要重启，热补丁升级脚本会通知您。

使用热补丁升级包含副本实例的设备

配置为高可用性和 Geo-replication 的设备除了会使用主实例之外，还会使用副本实例。 要升级此类设备，您需要逐个升级主实例和所有副本实例。

升级主实例

1. 请按照“使用管理 shell 安装热补丁”中的说明升级主实例。

升级副本实例

1. 按照“使用管理 shell 安装热补丁”中的说明升级副本实例。 如果使用多个副本进行异地复制，则必须重复此过程，每次升级一个副本。

2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. 运行以下命令来验证升级：

   $ ghe-version

使用升级包升级

虽然您可以使用热补丁升级到功能系列中的最新补丁版本，但必须使用升级包升级到更新的功能版本。 例如，要从 2.11.10 升级到 2.12.4，您必须使用升级包，因为两者在不同的功能系列中。 更多信息请参阅“升级要求”。

使用升级包升级单个设备

1. SSH 连接到 您的 GitHub Enterprise Server 实例。 更多信息请参阅“访问管理 shell (SSH)。”

   $ ssh -p 122 admin@HOSTNAME

2. 浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边，单击 Download（下载），然后单击 Upgrading（升级）选项卡。 选择适当的平台并复制升级包（.pkg 文件）的 URL。

3. 使用 curl 将升级包下载到 您的 GitHub Enterprise Server 实例：

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. 启用维护模式并等待 GitHub Enterprise Server 实例上的所有活动进程完成。 更多信息请参阅“启用和排定维护模式”。

   注：升级采用高可用性配置的主设备时，如果您按照“升级主实例”中的说明操作，设备应当已处于维护模式。

5. 使用包文件名运行 ghe-upgrade 命令：

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
   *** verifying upgrade package signature...

6. 确认您要继续升级，并在包签名得到验证后重新启动。 新的根文件系统会写入辅助分区，实例会在维护模式下自动重启：

   *** 正在应用更新...
   This package will upgrade your installation to version version-number
   Current root partition: /dev/xvda1 [version-number]
   Target root partition:  /dev/xvda2
   Proceed with installation? [y/N]

7. 对于单个设备升级，请禁用维护模式，以便用户能够使用 您的 GitHub Enterprise Server 实例。

   注：升级采用高可用性配置的主设备时，您应当一直处于维护模式，直至已升级所有副本，复制是最新版本。 更多信息请参阅“升级副本实例”。

使用升级包升级包含副本实例的设备

配置为高可用性和 Geo-replication 的设备除了会使用主实例之外，还会使用副本实例。 要升级此类设备，您需要逐个升级主实例和所有副本实例。

升级主实例

1. 在主实例上，启用维护模式并等待所有活动进程完成。 更多信息请参阅“启用维护模式”。
2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. 在副本实例或者所有副本实例（如果您将多个副本实例作为 Geo-replication 的一部分运行）上，运行 ghe-repl-stop 以停止复制。
4. 按照“使用升级包升级单个设备”中的说明升级主实例。

升级副本实例

1. 按照“使用升级包升级单个设备”中的说明升级副本实例。 如果使用多个副本进行异地复制，则必须重复此过程，每次升级一个副本。

2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。

   $ ssh -p 122 admin@replica-host

3. 运行以下命令来验证升级：

   $ ghe-version

4. 在副本实例上，要开始复制，请运行 ghe-repl-start。

5. 在副本实例中，为确保复制服务正常运行，请运行 ghe-repli-status。 当成功的复制正在进行中且副本已升级时，此命令将对所有服务返回 OK。 如果命令返回 Replication is not running，说明复制可能仍在启动。 等待 1 分钟左右，然后再次运行 ghe-repl-status。

   注：在重新同步过程中，ghe-repl-status 可能返回预期消息，提示复制落后。 例如：CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists

   如果 ghe-repl-status 未返回 OK，请执行以下步骤手动启动复制。

   1. 在副本实例上，再次运行 ghe-repl-setup <primary-instance-ip>。
   2. 在副本实例上，要开始复制，请运行 ghe-repl-start。
   3. 在副本实例中，为确保复制服务正常运行，请运行 ghe-repli-status。 当成功的复制正在进行中且副本已升级时，此命令将对所有服务返回 OK。

6. 最后一个副本升级完毕且重新同步完成后，请禁用维护模式，以便用户能够使用 您的 GitHub Enterprise Server 实例。

从失败的升级中恢复

如果升级失败或中断，您应将实例还原为其之前的状态。 完成此操作的过程取决于升级类型。

回滚补丁版本

要回滚补丁版本，请使用带 --allow-patch-rollback 开关的 ghe-upgrade 命令。 回滚升级时，您必须使用一个带 .pkg 扩展的升级包文件。 不支持带 .hpkg 扩展的热补丁包文件。

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

运行命令后需要重启。 回滚不会影响数据分区，因为迁移不是在补丁版本上运行的。

更多信息请参阅“命令行实用程序”。

回滚功能版本

要从功能版本回滚，请从 VM 快照恢复，以确保根分区和数据分区处于一致的状态。 更多信息请参阅“生成快照”。