此版本的 GitHub Enterprise 将停止服务 2022-02-16. 即使针对重大安全问题,也不会发布补丁。 要获得更好的性能、改进的安全性和新功能,请升级到 GitHub Enterprise 的最新版本。 如需升级方面的帮助,请联系 GitHub Enterprise 支持

Upgrading GitHub Enterprise Server

Upgrade GitHub Enterprise Server to get the latest features and security updates.

Note: Features such as GitHub Actions, GitHub Packages, 手机版 GitHub and GitHub Advanced Security are available on GitHub Enterprise Server 3.0 or higher. We highly recommend upgrading to 3.0 or later releases to take advantage of critical security updates, bug fixes and feature enhancements.

Preparing to upgrade

  1. Determine an upgrade strategy and choose a version to upgrade to. For more information, see "Upgrade requirements" and refer to the Upgrade assistant to find the upgrade path from your current release version.

  2. Create a fresh backup of your primary instance with the GitHub Enterprise Server 备份实用程序. For more information, see the GitHub Enterprise Server 备份实用程序 README.md file.

  3. If you are upgrading using an upgrade package, schedule a maintenance window for GitHub Enterprise Server end users. If you are using a hotpatch, maintenance mode is not required.

    Note: The maintenance window depends on the type of upgrade you perform. Upgrades using a hotpatch usually don't require a maintenance window. Sometimes a reboot is required, which you can perform at a later time. Following the versioning scheme of MAJOR.FEATURE.PATCH, patch releases using an upgrade package typically require less than five minutes of downtime. Feature releases that include data migrations take longer depending on storage performance and the amount of data that's migrated. For more information, see "Enabling and scheduling maintenance mode."

关于 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-30008
Up from 4
48 GB
Up from 32 GB
300 GB
Up from 250 GB
200 GB
3000-500012
Up from 8
64 GB500 GB200 GB
5000-800016
Up from 12
96 GB750 GB200 GB
8000-10000+20
Up from 16
160 GB
Up from 128 GB
1000 GB200 GB

有关 GitHub Actions 硬件要求的详细信息,请参阅“GitHub Enterprise Server 的 GitHub Actions 使用入门”。

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

Taking a snapshot

A snapshot is a checkpoint of a virtual machine (VM) at a point in time. We highly recommend taking a snapshot before upgrading your virtual machine so that if an upgrade fails, you can revert your VM back to the snapshot. If you're upgrading to a new feature release, you must take a VM snapshot. If you're upgrading to a patch release, you can attach the existing data disk.

There are two types of snapshots:

  • VM snapshots save your entire VM state, including user data and configuration data. This snapshot method requires a large amount of disk space and is time consuming.

  • Data disk snapshots only save your user data.

    Notes:

    • Some platforms don't allow you to take a snapshot of just your data disk. For these platforms, you'll need to take a snapshot of the entire VM.
    • If your hypervisor does not support full VM snapshots, you should take a snapshot of the root disk and data disk in quick succession.
PlatformSnapshot methodSnapshot documentation URL
Amazon AWSDiskhttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureVMhttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VVMhttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute EngineDiskhttps://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServerVMhttps://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

Upgrading with a hotpatch

您可以使用热更新将 GitHub Enterprise Server 升级为最新的补丁版本,它不需要维护时间窗,通常不需要重启。 您可以使用热更新来升级到更新的补丁版本,但不能升级到功能版本。 例如,您可以从 2.10.1 升级到 2.10.5,因为它们属于相同的功能系列,但不能从 2. 0.9 升级到 2.11.0,因为它们处于不同的功能系列中。 Using the 管理控制台, you can install a hotpatch immediately or schedule it for later installation. You can use the administrative shell to install a hotpatch with the ghe-upgrade utility. For more information, see "Upgrade requirements."

Notes:

  • If your GitHub Enterprise Server instance is running a release candidate build, you can't upgrade with a hotpatch.

  • Installing a hotpatch using the 管理控制台 is not available in clustered environments. To install a hotpatch in a clustered environment, see "Upgrading a cluster."

Upgrading a single appliance with a hotpatch

Installing a hotpatch using the 管理控制台

  1. Enable automatic updates. For more information, see "Enabling automatic updates."
  2. 从 GitHub Enterprise Server 上的管理帐户,点击任何页面右上角的 用于访问站点管理员设置的火箭图标
  3. 在左侧边栏中,单击 管理控制台左侧边栏中的 管理控制台 选项卡
  4. 在 管理控制台 顶部,单击 Updates(更新)更新菜单项
  5. When a new hotpatch has been downloaded, use the Install package drop-down menu:
    • To install immediately, select Now:
    • To install later, select a later date. Hotpatch installation date dropdown
  6. Click Install. Hotpatch install button

Installing a hotpatch using the administrative shell

注: 如果启用了自动更新检查,则无需下载升级包,可使用自动下载的文件。 更多信息请参阅“启用自动更新检查”。

  1. SSH 连接到 your GitHub Enterprise Server instance。 更多信息请参阅“访问管理 shell (SSH)。”
    $ ssh -p 122 admin@HOSTNAME
  2. 浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边,单击 Download(下载),然后单击 Upgrading(升级)选项卡。 Copy the URL for the upgrade hotpackage (.hpkg file).
  3. 使用 curl 将升级包下载到 your GitHub Enterprise Server instance:
    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Run the ghe-upgrade command using the package file name:
    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
    *** verifying upgrade package signature...
  5. If a reboot is required for updates for kernel, MySQL, Elasticsearch or other programs, the hotpatch upgrade script notifies you.

Upgrading an appliance that has replica instances using a hotpatch

Note: If you are installing a hotpatch, you do not need to enter maintenance mode or stop replication.

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

  1. Upgrade the primary instance by following the instructions in "Installing a hotpatch using the administrative shell."

Upgrading a replica instance

Note: If you're running multiple replica instances as part of geo-replication, repeat this procedure for each replica instance, one at a time.

  1. Upgrade the replica instance by following the instructions in "Installing a hotpatch using the administrative shell." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

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

    $ ssh -p 122 admin@replica-host
  3. 运行以下命令来验证升级:

    $ ghe-version

Upgrading with an upgrade package

While you can use a hotpatch to upgrade to the latest patch release within a feature series, you must use an upgrade package to upgrade to a newer feature release. For example to upgrade from 2.11.10 to 2.12.4 you must use an upgrade package since these are in different feature series. For more information, see "Upgrade requirements."

Upgrading a single appliance with an upgrade package

注: 如果启用了自动更新检查,则无需下载升级包,可使用自动下载的文件。 更多信息请参阅“启用自动更新检查”。

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

    $ ssh -p 122 admin@HOSTNAME
  2. 浏览到 GitHub Enterprise Server 发行版页面。 在要升级到的版本旁边,单击 Download(下载),然后单击 Upgrading(升级)选项卡。 Select the appropriate platform and copy the URL for the upgrade package (.pkg file).

  3. 使用 curl 将升级包下载到 your GitHub Enterprise Server instance:

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Enable maintenance mode and wait for all active processes to complete on the GitHub Enterprise Server instance. For more information, see "Enabling and scheduling maintenance mode."

    Note: When upgrading the primary appliance in a High Availability configuration, the appliance should already be in maintenance mode if you are following the instructions in "Upgrading the primary instance."

  5. Run the ghe-upgrade command using the package file name:

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
  6. Confirm that you'd like to continue with the upgrade and restart after the package signature verifies. The new root filesystem writes to the secondary partition and the instance automatically restarts in maintenance mode:

    *** applying update...
    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. For single appliance upgrades, disable maintenance mode so users can use your GitHub Enterprise Server instance.

    Note: When upgrading appliances in a High Availability configuration you should remain in maintenance mode until you have upgraded all of the replicas and replication is current. For more information, see "Upgrading a replica instance."

Upgrading an appliance that has replica instances using an upgrade package

Appliances configured for high-availability and geo-replication use replica instances in addition to primary instances. To upgrade these appliances, you'll need to upgrade both the primary instance and all replica instances, one at a time.

Upgrading the primary instance

Warning: When replication is stopped, if the primary fails, any work that is done before the replica is upgraded and the replication begins again will be lost.

  1. On the primary instance, enable maintenance mode and wait for all active processes to complete. For more information, see "Enabling maintenance mode."
  2. 以“admin”用户身份在端口 122 上通过 SSH 连接到副本实例。
    $ ssh -p 122 admin@replica-host
  3. On the replica instance, or on all replica instances if you're running multiple replica instances as part of geo-replication, run ghe-repl-stop to stop replication.
  4. Upgrade the primary instance by following the instructions in "Upgrading a single appliance with an upgrade package."

Upgrading a replica instance

Note: If you're running multiple replica instances as part of geo-replication, repeat this procedure for each replica instance, one at a time.

  1. Upgrade the replica instance by following the instructions in "Upgrading a single appliance with an upgrade package." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

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

    $ ssh -p 122 admin@replica-host
  3. 运行以下命令来验证升级:

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

  5. 在副本实例中,为确保复制服务正常运行,请运行 ghe-repli-status。 当成功的复制正在进行中且副本已升级时,此命令将对所有服务返回 OK。 If the command returns Replication is not running, the replication may still be starting. Wait about one minute before running ghe-repl-status again.

    Note: While the resync is in progress ghe-repl-status may return expected messages indicating that replication is behind. For example: CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists

    If ghe-repl-status did not return OK, contact GitHub Enterprise 支持. For more information, see "Receiving help from GitHub 支持."

  6. When you have completed upgrading the last replica, and the resync is complete, disable maintenance mode so users can use your GitHub Enterprise Server instance.

Restoring from a failed upgrade

If an upgrade fails or is interrupted, you should revert your instance back to its previous state. The process for completing this depends on the type of upgrade.

Rolling back a patch release

To roll back a patch release, use the ghe-upgrade command with the --allow-patch-rollback switch. 回滚升级时,您必须使用一个带 .pkg 扩展的升级包文件。 不支持带 .hpkg 扩展的热补丁包文件。

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

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

For more information, see "Command-line utilities."

Rolling back a feature release

To roll back from a feature release, restore from a VM snapshot to ensure that root and data partitions are in a consistent state. For more information, see "Taking a snapshot."

Further reading

此文档对您有帮助吗?

隐私政策

帮助我们创建出色的文档!

所有 GitHub 文档都是开源的。看到错误或不清楚的内容了吗?提交拉取请求。

做出贡献

或者, 了解如何参与。