如何用 upgrade package 把 GitHub Enterprise Server 升级到新的 feature release【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs当你运行的 GitHub Enterprise Server 实例需要从一个 feature 系列升到另一个 feature 系列时例如从 2.11.10 升到 2.12.4hotpatch 走不通hotpatch 只能升级到同一 feature 系列内的最新 patch release跨 feature release 必须使用 upgrade package。这篇文章给出单节点实例通过 upgrade package 完成 feature release 升级的完整操作路径包括下载包、启用维护模式、执行ghe-upgrade、监控后台迁移以及升级后的验证与收尾并附上 3.22 及以上版本的分阶段执行方式和多节点实例的升级顺序。升级前核对要求并准备回退手段在拿到 upgrade package 之前升级要求文档和升级流程概览给出的是硬性前提不是可选建议版本跨度限制只能从至多落后两个 feature release的版本开始升级。如果落后更多需要分多步升级连续升级时必须等上一轮升级的后台任务全部完成才能开始下一轮 feature 升级。磁盘空间确认数据盘至少 15% 空闲。文档还建议多预留一些空间数据量很大的实例阈值可能不同。快照与备份升级到新的 feature release 时虚拟机快照是必需的patch release 才可以沿用已有数据盘。快照只能在维护模式已启用或实例已关机时创建详见 taking-a-snapshot。同时确保你有一份近期成功的实例备份。维护窗口使用 upgrade package 升级必须为终端用户安排维护窗口。含数据迁移的 feature release 升级可能需要数小时停机具体时间取决于存储性能和迁移的数据量最佳估测方式是先在 staging 环境演练。预检升级会运行 pre-flight checks检查内存、CPU 核心、用户盘和根盘等资源如果资源不足升级会被中止并通知你。防火墙规则自定义防火墙规则在升级后不会保留升级前先把所有自定义规则备份好升级后重新应用。发布候选版本release candidate 构建仅限测试环境使用不要在生产环境安装也不要从 release candidate 升级到后续版本包括 GA。第一步获取 upgrade package如果已启用 automatic update checks站点管理员会收到升级包已自动下载的通知可以直接使用已下载的文件跳过手动下载。否则按以下步骤操作登录实例的管理 shell。多节点实例要 SSH 到主节点ssh -p 122 adminHOSTNAME其中HOSTNAME替换为你的实例主机名或节点的主机名/IP 地址这是源文档中所有HOSTNAME占位符的统一含义。到 GitHub Enterprise Server 的 Releases 页面找到要升级到的 release点击Download再切换到Upgrading标签页选择对应平台并复制 upgrade package.pkg文件的 URL。在实例上用curl下载升级包UPGRADE-PKG-URL替换为上一步复制的 URLadminHOSTNAME:~$ curl -L -O UPGRADE-PKG-URL文档同时建议升级时使用该 feature 系列的最新 patch release 版本并在规划时尽量少的跨升级次数。第二步启用维护模式并执行 ghe-upgrade启用维护模式并等待实例上所有活跃进程完成参见 维护模式文档。有 SSH 权限时可以用ghe-maintenance命令行工具设置维护模式ghe-maintenance -h查看选项。用包文件名运行ghe-upgradeGITHUB-UPGRADE.pkg替换为实际的包文件名adminHOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature...包签名校验通过后会提示升级目标版本并要求确认。新的 root 文件系统会写入次分区secondary partition确认后实例自动重启并进入维护模式*** 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]以上为源文档中的示例输出VERSION-NUMBER和分区名以你的实际环境为准。可选升级到 feature release 时可以用ghe-migrations工具观察数据库迁移状态。它的输出包含迁移的版本标识、名称、状态和已运行时长默认显示 10 行表格、每秒刷新可用ghe-migrations -height LINES和ghe-migrations -refresh_rate SECONDS调整ghe-migrations第三步重启后监控后台升级与配置运行实例重启后升级会在后台继续在后台进程完成前无法解除维护模式。用ghe-check-background-upgrade-jobs检查后台升级作业例如 Elasticsearch 索引迁移的状态ghe-check-background-upgrade-jobs注意这个检查只卡住下一次 feature 升级不是升级 replica 或其他同版本节点的前置条件。通过ghe-config.log观察配置运行进度例如tail -f /data/user/common/ghe-config.log配置在后台运行不需要显式执行ghe-config-apply除非遇到问题。多节点集群注意如果有节点还没升到同一版本此时在命令行运行ghe-config-apply或在管理控制台保存设置可能失败导致升级不完整这种情况应改用ghe-single-config-apply。第四步验证升级并完成收尾可选通过维护模式的IP 例外列表IP exception list放行指定 IP 地址的访问在维护模式下验证服务器健康方法见维护模式文档中的验证章节。按升级流程概览的后置任务逐项检查检查后台作业状态查看升级日志中是否有错误验证基本功能能通过用户界面登录能正常访问若干组织、仓库和 Issue手动执行若干次 Git fetch/clone/pushSSH 或 HTTPS并确认 API 请求和 webhook 投递成功重新应用自定义防火墙规则删除升级前创建的虚拟机快照。单节点升级到此收尾执行完上述后置任务后解除维护模式用户即可正常使用。可选分支分阶段执行phased upgrade execution如果实例运行的是 3.22 及以上版本可以使用分阶段执行把会造成停机的动作隔离到独立阶段从而更好控制停机时间。下载升级包后先执行 pre-upgrade 阶段ghe-upgrade --phase pre-upgrade GITHUB-UPGRADE.pkg启用维护模式并等待活跃进程完成。执行 upgrade 阶段ghe-upgrade --phase upgrade GITHUB-UPGRADE.pkg之后的验证与维护模式收尾与主路径相同。可选分支多节点实例的升级顺序多节点环境如高可用配置必须先升级主节点并等它的配置运行成功完成后才能升级任何 replica 节点主节点未完成时就升级其他节点会导致升级失败。主节点在主节点启用维护模式并等待活跃进程完成。停止复制在每个节点运行ghe-repl-stop如果有多个 replica可以在主节点上直接运行ghe-repl-stop-all一次停掉全部复制。警告复制停止期间如果主节点失败在 replica 升级完成、复制重新运行之前的任何工作都会丢失。按第二步、第三步的流程升级主节点。每个 replica 节点按单节点流程ghe-upgrade逐个升级每个节点升级后 SSH 进去用ghe-version验证版本。在 replica 上运行ghe-repl-start启动复制多个 replica 时可在主节点运行ghe-repl-start-all。运行ghe-repl-status所有服务返回OK说明复制正常运行且 replica 已完成升级。如果返回Replication is not running可能只是复制还在启动等约一分钟再查一次。重同步期间ghe-repl-status提示复制落后如CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists属于文档给出的预期现象启用了 Actions 时可能看到CRITICAL: mssql replication is down, didnt find Token_Configuration!这是主节点处于维护模式时的预期消息解除维护模式后应消失。若未返回OK且不在上述情况说明内需要联系支持。对每个其余节点重复以上步骤。最后一个 replica 升级完成且重同步完成后解除维护模式。限制与注意高可用实例在整个过程中应保持在维护模式直到所有 replica 都升级完成且复制恢复正常。如果连续执行多轮 feature 升级每轮开始前的前置条件是ghe-check-background-upgrade-jobs显示的后台作业全部完成——这是文档明确要求的卡点。升级过程中遇到失败或回滚需求时参考升级故障排查下的文档需要对比 patch 路径时可以查看 upgrading-with-a-hotpatch。【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何用 upgrade package 把 GitHub Enterprise Server 升级到新的 feature release
如何用 upgrade package 把 GitHub Enterprise Server 升级到新的 feature release【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs当你运行的 GitHub Enterprise Server 实例需要从一个 feature 系列升到另一个 feature 系列时例如从 2.11.10 升到 2.12.4hotpatch 走不通hotpatch 只能升级到同一 feature 系列内的最新 patch release跨 feature release 必须使用 upgrade package。这篇文章给出单节点实例通过 upgrade package 完成 feature release 升级的完整操作路径包括下载包、启用维护模式、执行ghe-upgrade、监控后台迁移以及升级后的验证与收尾并附上 3.22 及以上版本的分阶段执行方式和多节点实例的升级顺序。升级前核对要求并准备回退手段在拿到 upgrade package 之前升级要求文档和升级流程概览给出的是硬性前提不是可选建议版本跨度限制只能从至多落后两个 feature release的版本开始升级。如果落后更多需要分多步升级连续升级时必须等上一轮升级的后台任务全部完成才能开始下一轮 feature 升级。磁盘空间确认数据盘至少 15% 空闲。文档还建议多预留一些空间数据量很大的实例阈值可能不同。快照与备份升级到新的 feature release 时虚拟机快照是必需的patch release 才可以沿用已有数据盘。快照只能在维护模式已启用或实例已关机时创建详见 taking-a-snapshot。同时确保你有一份近期成功的实例备份。维护窗口使用 upgrade package 升级必须为终端用户安排维护窗口。含数据迁移的 feature release 升级可能需要数小时停机具体时间取决于存储性能和迁移的数据量最佳估测方式是先在 staging 环境演练。预检升级会运行 pre-flight checks检查内存、CPU 核心、用户盘和根盘等资源如果资源不足升级会被中止并通知你。防火墙规则自定义防火墙规则在升级后不会保留升级前先把所有自定义规则备份好升级后重新应用。发布候选版本release candidate 构建仅限测试环境使用不要在生产环境安装也不要从 release candidate 升级到后续版本包括 GA。第一步获取 upgrade package如果已启用 automatic update checks站点管理员会收到升级包已自动下载的通知可以直接使用已下载的文件跳过手动下载。否则按以下步骤操作登录实例的管理 shell。多节点实例要 SSH 到主节点ssh -p 122 adminHOSTNAME其中HOSTNAME替换为你的实例主机名或节点的主机名/IP 地址这是源文档中所有HOSTNAME占位符的统一含义。到 GitHub Enterprise Server 的 Releases 页面找到要升级到的 release点击Download再切换到Upgrading标签页选择对应平台并复制 upgrade package.pkg文件的 URL。在实例上用curl下载升级包UPGRADE-PKG-URL替换为上一步复制的 URLadminHOSTNAME:~$ curl -L -O UPGRADE-PKG-URL文档同时建议升级时使用该 feature 系列的最新 patch release 版本并在规划时尽量少的跨升级次数。第二步启用维护模式并执行 ghe-upgrade启用维护模式并等待实例上所有活跃进程完成参见 维护模式文档。有 SSH 权限时可以用ghe-maintenance命令行工具设置维护模式ghe-maintenance -h查看选项。用包文件名运行ghe-upgradeGITHUB-UPGRADE.pkg替换为实际的包文件名adminHOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature...包签名校验通过后会提示升级目标版本并要求确认。新的 root 文件系统会写入次分区secondary partition确认后实例自动重启并进入维护模式*** 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]以上为源文档中的示例输出VERSION-NUMBER和分区名以你的实际环境为准。可选升级到 feature release 时可以用ghe-migrations工具观察数据库迁移状态。它的输出包含迁移的版本标识、名称、状态和已运行时长默认显示 10 行表格、每秒刷新可用ghe-migrations -height LINES和ghe-migrations -refresh_rate SECONDS调整ghe-migrations第三步重启后监控后台升级与配置运行实例重启后升级会在后台继续在后台进程完成前无法解除维护模式。用ghe-check-background-upgrade-jobs检查后台升级作业例如 Elasticsearch 索引迁移的状态ghe-check-background-upgrade-jobs注意这个检查只卡住下一次 feature 升级不是升级 replica 或其他同版本节点的前置条件。通过ghe-config.log观察配置运行进度例如tail -f /data/user/common/ghe-config.log配置在后台运行不需要显式执行ghe-config-apply除非遇到问题。多节点集群注意如果有节点还没升到同一版本此时在命令行运行ghe-config-apply或在管理控制台保存设置可能失败导致升级不完整这种情况应改用ghe-single-config-apply。第四步验证升级并完成收尾可选通过维护模式的IP 例外列表IP exception list放行指定 IP 地址的访问在维护模式下验证服务器健康方法见维护模式文档中的验证章节。按升级流程概览的后置任务逐项检查检查后台作业状态查看升级日志中是否有错误验证基本功能能通过用户界面登录能正常访问若干组织、仓库和 Issue手动执行若干次 Git fetch/clone/pushSSH 或 HTTPS并确认 API 请求和 webhook 投递成功重新应用自定义防火墙规则删除升级前创建的虚拟机快照。单节点升级到此收尾执行完上述后置任务后解除维护模式用户即可正常使用。可选分支分阶段执行phased upgrade execution如果实例运行的是 3.22 及以上版本可以使用分阶段执行把会造成停机的动作隔离到独立阶段从而更好控制停机时间。下载升级包后先执行 pre-upgrade 阶段ghe-upgrade --phase pre-upgrade GITHUB-UPGRADE.pkg启用维护模式并等待活跃进程完成。执行 upgrade 阶段ghe-upgrade --phase upgrade GITHUB-UPGRADE.pkg之后的验证与维护模式收尾与主路径相同。可选分支多节点实例的升级顺序多节点环境如高可用配置必须先升级主节点并等它的配置运行成功完成后才能升级任何 replica 节点主节点未完成时就升级其他节点会导致升级失败。主节点在主节点启用维护模式并等待活跃进程完成。停止复制在每个节点运行ghe-repl-stop如果有多个 replica可以在主节点上直接运行ghe-repl-stop-all一次停掉全部复制。警告复制停止期间如果主节点失败在 replica 升级完成、复制重新运行之前的任何工作都会丢失。按第二步、第三步的流程升级主节点。每个 replica 节点按单节点流程ghe-upgrade逐个升级每个节点升级后 SSH 进去用ghe-version验证版本。在 replica 上运行ghe-repl-start启动复制多个 replica 时可在主节点运行ghe-repl-start-all。运行ghe-repl-status所有服务返回OK说明复制正常运行且 replica 已完成升级。如果返回Replication is not running可能只是复制还在启动等约一分钟再查一次。重同步期间ghe-repl-status提示复制落后如CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists属于文档给出的预期现象启用了 Actions 时可能看到CRITICAL: mssql replication is down, didnt find Token_Configuration!这是主节点处于维护模式时的预期消息解除维护模式后应消失。若未返回OK且不在上述情况说明内需要联系支持。对每个其余节点重复以上步骤。最后一个 replica 升级完成且重同步完成后解除维护模式。限制与注意高可用实例在整个过程中应保持在维护模式直到所有 replica 都升级完成且复制恢复正常。如果连续执行多轮 feature 升级每轮开始前的前置条件是ghe-check-background-upgrade-jobs显示的后台作业全部完成——这是文档明确要求的卡点。升级过程中遇到失败或回滚需求时参考升级故障排查下的文档需要对比 patch 路径时可以查看 upgrading-with-a-hotpatch。【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考