Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

此版本的 GitHub Enterprise 已停止服务 2023-03-15. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

Upgrading GitHub Enterprise Server

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

准备升级

  1. 确定升级策略并选择要升级到的版本。 有关详细信息,请参阅“升级要求”和 升级助手 以查找当前发行版本的升级路径。

  2. 使用 GitHub Enterprise Server Backup Utilities 创建全新的主实例备份。 有关详细信息,请参阅 GitHub Enterprise Server Backup Utilities 项目文档中的 README.md 文件

    注意:GitHub Enterprise Server Backup Utilities 版本需要与 你的 GitHub Enterprise Server 实例 版本相同,或前者最多比后者低两个版本。 有关详细信息,请参阅“升级 GitHub Enterprise Server 备份实用程序”。

  3. 如果 你的 GitHub Enterprise Server 实例 对 GitHub Actions 使用临时自承载运行器,并且已禁用自动更新,请将运行器升级到升级实例将运行的运行器应用程序版本。

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

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

生成快照

快照是虚拟机 (VM) 在某一时间点的检查点。 强烈建议在升级虚拟机之前生成快照,这样一来,如果升级失败,您可以将 VM 还原到快照状态。 我们仅建议在设备关闭电源或处于维护模式且所有后台作业都已完成时拍摄 VM 快照。

如果您要升级到新的功能版本,则必须生成 VM 快照。 如果您要升级到补丁版本,可以连接现有数据磁盘。

有两种类型的快照:

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

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

    注意:

    • 某些平台不允许您只生成数据磁盘的快照。 对于此类平台,您需要生成整个 VM 的快照。
    • 如果您的虚拟机监控程序不支持完整的 VM 快照,您应连续、快速地生成根磁盘和数据磁盘的快照。
平台Snapshot 方法快照文档 URL
Amazon AWS磁盘https://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 Engine磁盘https://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-64B866EF-7636-401C-A8FF-2B4584D9CA72.html

使用热补丁升级

可使用热补丁将 GitHub Enterprise Server 升级到最新的补丁版本。

您可以使用热更新来升级到更新的补丁版本,但不能升级到功能版本。 例如,你可从 2.10.1 升级到 2.10.5,因为它们位于同一功能系列中,但不能从 2.10.9 升级到 2.11.0,因为它们位于不同的功能系列中。

热补丁通常不要求重启。 如果热补丁确实要求重启,GitHub Enterprise Server 发行说明将说明此要求。

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

使用 管理控制台,您可以立即安装热补丁,也可以安排以后安装。 你可以使用管理 shell 通过 ghe-upgrade 实用程序安装热补丁。 有关详细信息,请参阅“升级要求”。

注意:

  • 如果 你的 GitHub Enterprise Server 实例 正在运行候选发布版本,就无法使用热补丁升级。

  • 无法在集群环境中使用 管理控制台 安装热补丁。 要在集群环境中安装热补丁,请参阅“升级群集”。

使用热补丁升级单个设备

如果要使用热补丁升级单个设备,并且目标是修补程序版本,则可以使用 管理控制台。 若要升级到功能版本,必须使用管理 shell。

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

您可以通过启用自动更新来使用 管理控制台 通过热补丁进行升级。 然后,您将看到可升级到的最新可用 GitHub Enterprise Server 版本。

如果显示的升级目标是功能版本而不是修补程序版本,则无法使用 管理控制台 来安装修补程序。 您必须改为使用管理 shell 安装热补丁。 有关详细信息,请参阅“使用管理 shell 安装热补丁”。

  1. 启用自动更新。 有关详细信息,请参阅“启用自动更新”。

  2. 在 GitHub Enterprise Server 上的管理帐户中,在任一页面的右上角,单击

  3. 如果你尚未在“站点管理员”页上,请在左上角单击“站点管理员”。 1. 在“ 站点管理”边栏中,单击“管理控制台”。 1. 在顶部导航栏中,单击“更新”。

    管理控制台 标头的屏幕截图。 标有“更新”的选项卡以橙色轮廓突出显示。

  4. 在新的热补丁下载完毕后,请选择“安装包”下拉菜单。

    • 若要立即安装,请单击“立即”。
    • 要稍后安装,请选择以后的日期。
  5. 单击“安装” 。

使用管理 shell 安装热补丁

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

  1. 通过 SSH 连接到 你的 GitHub Enterprise Server 实例。 如果实例包含多个节点,例如,如果配置了高可用性或异地复制,则通过 SSH 连接到主节点。 如果使用群集,则可以通过 SSH 连接到任何节点。 有关 SSH 访问的详细信息,请参阅“访问管理 shell (SSH)”。

    $ ssh -p 122 admin@HOSTNAME
  2. 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边,单击“下载”,然后单击“升级”选项卡 。 复制升级热补丁包(.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
    1. 运行以下命令来验证升级:
    $ ghe-version

使用升级包升级

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

使用升级包升级单个设备

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

  1. 通过 SSH 连接到 你的 GitHub Enterprise Server 实例。 如果实例包含多个节点,例如,如果配置了高可用性或异地复制,则通过 SSH 连接到主节点。 如果使用群集,则可以通过 SSH 连接到任何节点。 有关 SSH 访问的详细信息,请参阅“访问管理 shell (SSH)”。

    $ ssh -p 122 admin@HOSTNAME
  2. 浏览到 GitHub Enterprise Server 版本页。 在要升级到的版本旁边,单击“下载”,然后单击“升级”选项卡 。 选择适当的平台并复制升级包(.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. 确认您要继续升级,并在包签名得到验证后重新启动。 新的根文件系统会写入辅助分区,实例会在维护模式下自动重启:

    *** 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. 对于单个设备升级,请禁用维护模式,以便用户能够使用 你的 GitHub Enterprise Server 实例。

    注意:升级采用高可用性配置的主设备时,你应当一直处于维护模式,直至已升级所有副本,且复制是最新版本。 有关详细信息,请参阅“升级副本实例”。

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

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

使用升级包升级主实例

警告:复制停止时,如果主实例发生故障,副本升级和复制再次开始之前执行的任何操作都将丢失。

  1. 在主实例上,启用维护模式并等待所有活动进程完成。 有关详细信息,请参阅“启用维护模式”。
  2. admin 用户身份在端口 122 上通过 SSH 连接到副本节点:
    $ ssh -p 122 admin@REPLICA_HOST
  3. 在该副本实例或者所有副本实例上,如果要将多个副本实例作为异地复制的一部分运行,请运行 ghe-repl-stop 以停止复制。
  4. 请按照“使用升级包升级单个设备”中的说明升级主实例。

使用升级包升级副本实例

注意:如果你要将多个副本实例作为异地复制的一部分运行,请逐一为每个副本实例重复此过程。

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

  2. admin 用户身份在端口 122 上通过 SSH 连接到副本节点:

    $ ssh -p 122 admin@REPLICA_HOST
    1. 运行以下命令来验证升级:
    $ ghe-version
  3. 在副本节点上,要启动复制,请运行 ghe-repl-start

  4. 在副本节点上,为确保复制服务正常运行,请运行 ghe-repl-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
    
    • 如果已将每个节点升级到 GitHub Enterprise Server 3.6.0 或更高版本,但开始复制 45 分钟后仍然出现 git replication is behind the primary,请联系 GitHub Enterprise 支持。 有关详细信息,请参阅“从 GitHub 支持 获得帮助”。

    • 否则, ghe-repl-status 未返回 OK,请联系 GitHub Enterprise 支持。 有关详细信息,请参阅“从 GitHub 支持 获得帮助”。

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

从失败的升级中恢复

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

回滚补丁版本

要回滚修补程序版本,请将 ghe-upgrade 命令与 --allow-patch-rollback 开关结合使用。 在回滚之前,必须通过在所有副本实例上运行 ghe-repl-stop 来暂时停止复制。 回滚升级时,必须使用一个带 .pkg 扩展的升级包文件。 不支持带 .hpkg 扩展的热补丁包文件。

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

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

回滚完成后,通过在所有副本上运行 ghe-repl-start 来重新启动复制。

有关详细信息,请参阅“命令行实用工具”。

回滚功能版本

要从功能版本回滚,请从 VM 快照恢复,以确保根分区和数据分区处于一致的状态。 有关详细信息,请参阅“拍摄快照”。

延伸阅读