升级 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 releaseVM 快照是必须的required。升级到 patch release可以不建 VM 快照直接挂回现有的数据盘即可。如果确认需要快照下面各节的时机和类型选择都适用。选择快照类型VM 快照还是数据盘快照文档定义了两类快照见 Taking a snapshot快照类型保存内容代价VM 快照整个 VM 的状态包括用户数据和配置数据需要大量磁盘空间且耗时数据盘快照仅用户数据文档未给出额外代价说明具体能选哪一类由你的宿主机平台决定官方给出了对应关系平台快照方式Amazon AWSDisk磁盘AzureVMHyper-VVMGoogle Compute EngineDisk磁盘VMwareVM在此基础上有两条通用规则有些平台不允许只快照数据盘这类平台必须对整个 VM 做快照。如果你的 hypervisor 不支持整 VM 快照应尽快连续地对根盘root disk和数据盘各打一个快照。各平台的实际操作步骤请参考你所在云平台或虚拟化产品的官方文档本文只给出 GHES 侧要求的时机、类型与前后置动作。进入可创建快照的状态GHES 只建议在下述两种状态之一下创建 VM 快照其他状态下快照可能包含不一致的数据实例的 VM 已关机powered down或实例处于维护模式且所有后台作业background jobs已结束。下面按第二条路径维护模式说明这也是升级 feature release 时的常规做法。开启维护模式进入 Management Console 开启维护模式步骤见 Enabling and scheduling maintenance mode使用具有管理权限的账号登录 GHES在任意页面右上角点击 Site admin 图标火箭图标如不在 Site admin 页面在左上角点击Site admin。在顶部导航栏点击Maintenance。在 Enable and schedule 区域选择Enable maintenance mode然后二选一立即生效在下拉菜单中选择now计划一个未来时间窗选择开始时间官方建议至少预留 30 分钟以上让使用者有时间准备计划后所有用户会看到提示横幅。可选地设置一条自定义维护消息最后点击Save。若选择 now实例会立即进入维护模式。开启后如何确认状态已生效维护模式下所有常规 HTTP 和 Git 访问都会被拒绝——Web 与 API 请求返回503Service UnavailableGit fetch/clone/push 被拒绝并提示站点暂时不可用浏览器访问会看到维护页面。如果你的网络环境无法从外部访问实例也可以通过 SSH 管理壳中的ghe-maintenance -h查看该工具的选项来管理维护模式见 command-line utilities。确认后台作业已结束进入维护模式不等于后台作业已经跑完。在创建快照前可在管理壳中用以下命令确认后台升级相关作业的状态见 command-line utilitiesghe-check-background-upgrade-jobs该工具显示实例上后台升级作业例如 Elasticsearch 索引迁移的状态如果还要确认数据库迁移可用ghe-migrationsghe-migrations会输出迁移的版本标识、名称、状态与已运行时长。确认作业完成后再进入下一步。可选官方还建议在维护模式下配置IP exception listManagement 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请先在测试环境重新验证升级路径。快照只是回滚手段之一官方同时要求升级前还有一份近期且成功的 backupbackup 与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
升级 GitHub Enterprise Server 前如何创建虚拟机快照并选择快照类型
升级 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 releaseVM 快照是必须的required。升级到 patch release可以不建 VM 快照直接挂回现有的数据盘即可。如果确认需要快照下面各节的时机和类型选择都适用。选择快照类型VM 快照还是数据盘快照文档定义了两类快照见 Taking a snapshot快照类型保存内容代价VM 快照整个 VM 的状态包括用户数据和配置数据需要大量磁盘空间且耗时数据盘快照仅用户数据文档未给出额外代价说明具体能选哪一类由你的宿主机平台决定官方给出了对应关系平台快照方式Amazon AWSDisk磁盘AzureVMHyper-VVMGoogle Compute EngineDisk磁盘VMwareVM在此基础上有两条通用规则有些平台不允许只快照数据盘这类平台必须对整个 VM 做快照。如果你的 hypervisor 不支持整 VM 快照应尽快连续地对根盘root disk和数据盘各打一个快照。各平台的实际操作步骤请参考你所在云平台或虚拟化产品的官方文档本文只给出 GHES 侧要求的时机、类型与前后置动作。进入可创建快照的状态GHES 只建议在下述两种状态之一下创建 VM 快照其他状态下快照可能包含不一致的数据实例的 VM 已关机powered down或实例处于维护模式且所有后台作业background jobs已结束。下面按第二条路径维护模式说明这也是升级 feature release 时的常规做法。开启维护模式进入 Management Console 开启维护模式步骤见 Enabling and scheduling maintenance mode使用具有管理权限的账号登录 GHES在任意页面右上角点击 Site admin 图标火箭图标如不在 Site admin 页面在左上角点击Site admin。在顶部导航栏点击Maintenance。在 Enable and schedule 区域选择Enable maintenance mode然后二选一立即生效在下拉菜单中选择now计划一个未来时间窗选择开始时间官方建议至少预留 30 分钟以上让使用者有时间准备计划后所有用户会看到提示横幅。可选地设置一条自定义维护消息最后点击Save。若选择 now实例会立即进入维护模式。开启后如何确认状态已生效维护模式下所有常规 HTTP 和 Git 访问都会被拒绝——Web 与 API 请求返回503Service UnavailableGit fetch/clone/push 被拒绝并提示站点暂时不可用浏览器访问会看到维护页面。如果你的网络环境无法从外部访问实例也可以通过 SSH 管理壳中的ghe-maintenance -h查看该工具的选项来管理维护模式见 command-line utilities。确认后台作业已结束进入维护模式不等于后台作业已经跑完。在创建快照前可在管理壳中用以下命令确认后台升级相关作业的状态见 command-line utilitiesghe-check-background-upgrade-jobs该工具显示实例上后台升级作业例如 Elasticsearch 索引迁移的状态如果还要确认数据库迁移可用ghe-migrationsghe-migrations会输出迁移的版本标识、名称、状态与已运行时长。确认作业完成后再进入下一步。可选官方还建议在维护模式下配置IP exception listManagement 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请先在测试环境重新验证升级路径。快照只是回滚手段之一官方同时要求升级前还有一份近期且成功的 backupbackup 与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
