企业官网建设流程全解析

升级 GitHub Enterprise Server 前如何创建虚拟机快照并选择快照类型

【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs

如果你准备把 GitHub Enterprise Server（下文称 GHES）实例升级到新版本，官方强烈建议在升级前先在宿主机（hypervisor）层面为虚拟机的主节点打一个快照：一旦升级失败，可以借助这个快照把 VM 回滚到升级前的状态。这篇文章说明在哪个时间点、以什么状态创建快照，以及如何根据你使用的平台在「VM 快照」和「数据盘快照」之间做选择。

判断是否需要做 VM 快照

是否需要 VM 快照取决于你这次升级的目标版本类型（见 升级流程概述）：

• 升级到新的 feature release：VM 快照是必须的（required）。
• 升级到 patch release：可以不建 VM 快照，直接挂回现有的数据盘即可。

如果确认需要快照，下面各节的时机和类型选择都适用。

选择快照类型：VM 快照还是数据盘快照

文档定义了两类快照（见 Taking a snapshot）：

具体能选哪一类，由你的宿主机平台决定，官方给出了对应关系：

在此基础上有两条通用规则：

• 有些平台不允许只快照数据盘，这类平台必须对整个 VM 做快照。
• 如果你的 hypervisor 不支持整 VM 快照，应尽快连续地对根盘（root disk）和数据盘各打一个快照。

各平台的实际操作步骤请参考你所在云平台或虚拟化产品的官方文档；本文只给出 GHES 侧要求的时机、类型与前后置动作。

进入可创建快照的状态

GHES 只建议在下述两种状态之一下创建 VM 快照，其他状态下快照可能包含不一致的数据：

1. 实例的 VM 已关机（powered down）；或
2. 实例处于维护模式，且所有后台作业（background jobs）已结束。

下面按第二条路径（维护模式）说明，这也是升级 feature release 时的常规做法。

开启维护模式

进入 Management Console 开启维护模式（步骤见 Enabling and scheduling maintenance mode）：

1. 使用具有管理权限的账号登录 GHES，在任意页面右上角点击 Site admin 图标（火箭图标），如不在 Site admin 页面，在左上角点击Site admin。
2. 在顶部导航栏点击Maintenance。

3. 在 "Enable and schedule" 区域选择Enable maintenance mode，然后二选一：
   • 立即生效：在下拉菜单中选择now；
   • 计划一个未来时间窗：选择开始时间（官方建议至少预留 30 分钟以上，让使用者有时间准备，计划后所有用户会看到提示横幅）。
4. 可选地设置一条自定义维护消息，最后点击Save。若选择 now，实例会立即进入维护模式。

开启后如何确认状态已生效：维护模式下所有常规 HTTP 和 Git 访问都会被拒绝——Web 与 API 请求返回503（Service Unavailable），Git fetch/clone/push 被拒绝并提示站点暂时不可用，浏览器访问会看到维护页面。如果你的网络环境无法从外部访问实例，也可以通过 SSH 管理壳中的ghe-maintenance -h查看该工具的选项来管理维护模式（见 command-line utilities）。

确认后台作业已结束

进入维护模式不等于后台作业已经跑完。在创建快照前，可在管理壳中用以下命令确认后台升级相关作业的状态（见 command-line utilities）：

ghe-check-background-upgrade-jobs

该工具显示实例上后台升级作业（例如 Elasticsearch 索引迁移）的状态；如果还要确认数据库迁移，可用：

ghe-migrations

ghe-migrations会输出迁移的版本标识、名称、状态与已运行时长。确认作业完成后再进入下一步。

可选：官方还建议在维护模式下配置IP exception list（Management Console 的 Maintenance 页面中 "Enable and configure IP exception list" 区域），把访问限制到个别 IP，便于在维护操作中做初始的服务器健康验证。

在升级前最后时刻创建快照

满足"已关机，或维护模式 + 后台作业结束"后，按前面选定的类型创建快照，并注意以下要求：

• 时间点：在开始升级前的**最后时刻（immediately before）**为主节点创建快照，避免快照与待升级状态之间隔得太久。
• 按平台方式执行：对照前面的平台表——Azure、Hyper-V、VMware 用 VM 快照；AWS、Google Compute Engine 用磁盘快照；若你的 hypervisor 不支持整 VM 快照，则尽快连续地对根盘和数据盘各打一个快照。具体操作命令或界面步骤以各平台的官方文档为准，本文不重复给出。
• 打完快照后关闭自动快照：升级要求中明确，快照创建后应关闭实例的自动快照功能，以避免升级过程中的性能影响（见 Upgrade requirements）。
• 顺手核对容量：官方要求升级前数据盘至少有 15% 的空闲空间，并建议额外预留；磁盘空间不足时快照本身也需要额外空间。若数据量很大，个别客户的阈值可能不同（见 升级流程概述）。

升级后的收尾：删除快照

升级成功并完成验证（能登录界面、访问关键组织/仓库/Issue、SSH 与 HTTPS 的 fetch/clone/push、API 与 webhook 均正常、后台作业队列清空）之后，官方把"删除升级前创建的 VM 快照"列为明确的升级后任务。快照在完成使命后应删除，而不是长期保留。

限制与边界

• 本文只覆盖 GHES 独立部署与高可用配置下的快照要求；Clustering 部署的升级有单独的操作说明，不在本文范围内。
• ghe-check-background-upgrade-jobs只用于把关下一个 feature 升级是否可以进行，不是升级副本/其他节点到同一版本的前置条件。
• Release candidate 构建只应在测试环境使用，不要在生产环境安装 RC，也不要从 RC 升级到后续版本——如果实例当前处于 RC，请先在测试环境重新验证升级路径。
• 快照只是回滚手段之一；官方同时要求升级前还有一份近期且成功的 backup（backup 与 VM 快照是两件独立的事，backup 不能替代 hypervisor 层快照）。

完成快照后，即可进入实际的升级安装步骤（hotpatch 或 upgrade package），对应文档见 升级流程概述中的 "Installing an upgrade package" 章节。

【免费下载链接】docsThe open-source repo for docs.github.com项目地址: https://gitcode.com/GitHub_Trending/do/docs