Обзор процесса обновления

GitHub Enterprise Server постоянно улучшается, с новыми функциями и исправлениями ошибок, представленными с помощью компонентов и исправлений. Вы несете ответственность за обновление экземпляра. См . раздел AUTOTITLE.

Чтобы обновить экземпляр, необходимо выполнить следующие действия. 1. Запланируйте стратегию обновления, выбрав версию обновления и соответствующий пакет обновления, а также запланируйте период обслуживания. 1. Обмен данными об обновлении до и во время процесса обновления. 1. Подготовьте стратегию резервного копирования, создав резервную копию и создав моментальный снимок виртуальной машины. 1. Установите пакет обновления с помощью соответствующего пакета и метода. 1. Выполните задачи после обновления.

Процесс, который необходимо выполнить для применения пакета обновления, зависит от того, сколько узлов находятся в топологии развертывания. В этой статье приведены общие сведения об обновлении экземпляров в автономной или высокодоступной конфигурации.

Планирование стратегии обновления

Планирование обновления

• Просмотрите заметки о выпуске и задокументированные известные проблемы перед обновлением. См. раздел [AUTOTITLE и Заметки о выпуске](/admin/upgrading-your-instance/troubleshooting-upgrades/known-issues-with-upgrades-to-your-instance).
• Просмотрите Требования к обновлению , чтобы убедиться, что вы понимаете требования и рекомендации по обновлению.
• Убедитесь, что диск данных ваш экземпляр GitHub Enterprise Serverна диске данных не менее 15 %. GitHub рекомендует обеспечить наличие дополнительного свободного хранилища на диске. В некоторых редких случаях для клиентов с большими объемами данных этот порог может отличаться. См . раздел AUTOTITLE.
• Убедитесь, что у вас достаточно аппаратных ресурсов для GitHub Enterprise Server. При обновлении предварительные проверки проверяют, доступны ли минимальные требования к системным аппаратным ресурсам, таким как память, ядра ЦП и хранилище корневого диска пользователя и корневого диска. Если предварительные проверки определяют нехватку ресурсов или в противном случае не удается получить уведомление, и обновление прервано.
• Убедитесь, что у вас есть копия всех пользовательских правил брандмауэра для ваш экземпляр GitHub Enterprise Server, так как настраиваемые правила не будут сохраняться после обновления. После обновления необходимо повторно применить любые пользовательские правила. См . раздел AUTOTITLE.
• Для экземпляров в конфигурации высокой доступности убедитесь, что состояние отчетов OK репликации перед обновлением. См . раздел AUTOTITLE.
• Попробуйте настроить список исключений IP для режима обслуживания, чтобы временно ограничить доступ к ваш экземпляр GitHub Enterprise Server для проверки работоспособности сервера после обновления. См . раздел AUTOTITLE.

Выбор версии обновления и пакета

• Определите стратегию обновления и выберите целевую версию для обновления.
  • Можно обновить экземпляр GitHub Enterprise Server до нового выпуска исправлений или до нового выпуска компонента.
  • Перейдите к Помощник по обновлению , чтобы найти путь обновления от текущей версии выпуска к новой версии исправления или выпуска компонентов.
• Выберите пакет обновления (горячий пакет или пакет обновления).
  • Для обновления до выпуска исправлений можно использовать горячее исправление или пакет обновления. Для обновления до выпуска компонента необходимо использовать пакет обновления.
  • Если вы используете пакет обновления, запланируйте период обслуживания для пользователей GitHub Enterprise Server. Если вы используете горячее исправление, режим обслуживания не требуется.
  • Если вы включили автоматическую проверку обновлений, администраторы сайта получат уведомление о том, что пакет обновления скачан и доступен. См . раздел AUTOTITLE.
  • Сборки кандидатов выпуска предназначены исключительно для использования в тестовой среде. Не устанавливайте сборку кандидата выпуска в рабочей среде. Не обновляйте кандидат на выпуск до более поздних версий, включая общедоступные выпуски.

Рассмотрите, требуются ли другие обновления приложений

Проверьте, нужно ли обновить следующие приложения:

• GitHub Actions необходимо обновить, если ваш экземпляр GitHub Enterprise Server использует эфемерные локальные средства выполнения для GitHub Actions и автоматические обновления отключены. Перед выполнением обновления выполните обновление до минимальной версии приложения, необходимой для обновленного экземпляра. Чтобы найти минимальную требуемую версию для выпуска, см. раздел Релизы GitHub Enterprise Server.

• GitHub Enterprise Server Backup Utilities. Ваша версия GitHub Enterprise Server Backup Utilities должна быть той же версией, что и в до ваш экземпляр GitHub Enterprise Server.

  • Перед обновлением экземпляра может потребоваться обновить GitHub Enterprise Server Backup Utilities до более новой версии.
  • Вы также можете запланировать обновление GitHub Enterprise Server Backup Utilities до более новой версии после обновления экземпляра.

  См. раздел AUTOTITLE и README в документации по проекту GitHub Enterprise Server Backup Utilities.

Планирование периода обслуживания

• В зависимости от стратегии обновления может потребоваться значительное время простоя.
• Лучший способ определить ожидаемую продолжительность простоя — сначала протестировать обновление в промежуточной среде. См . раздел AUTOTITLE.
• Период обслуживания для обновления зависит от типа выполняемого обновления.

  • Обновления с помощью горячего исправления обычно не требуют периода обслуживания. Иногда требуется перезагрузка, которую можно выполнить позже.

    Примечание.

    Для выполнения исправлений требуется выполнение конфигурации, которое может привести к краткому периоду ошибок или безответственности для некоторых или всех служб на ваш экземпляр GitHub Enterprise Server. Вам не требуется включить режим обслуживания во время установки hotpatch, но это гарантирует, что пользователи увидят страницу обслуживания вместо ошибок или времени ожидания. См . раздел AUTOTITLE.

  • Выпуски исправлений, использующие пакет обновления, обычно требуют меньше пяти минут простоя.

  • Обновление до нового выпуска компонента, включающего миграцию данных, может привести к простою в течение нескольких часов в зависимости от производительности хранилища и объема перенесенных данных. В это время ни один из пользователей не сможет использовать предприятие. Вы можете заметить, что обновление до нового выпуска компонентов занимает меньше времени. Это связано с тем, что выборочные переходы баз данных теперь будут выполняться одновременно, при этом число одновременных рабочих ролей, используемых по умолчанию для числа ядер ЦП, не более 16.

Обмен данными об обновлении

• Перед обновлением вы можете опубликовать баннер глобального объявления, чтобы выделить важные сведения для пользователей, например входящие изменения или возможные простои. См . раздел AUTOTITLE.
• Во время обновления можно включить режим обслуживания и настроить настраиваемое сообщение для информирования пользователей о временной недоступности экземпляра. См . раздел AUTOTITLE.

Подготовка стратегии резервного копирования

Создание моментального снимка резервной копии

Перед началом процесса обновления убедитесь, что у вас есть недавний успешный моментальный снимок резервного копирования основного узла экземпляра. См. раздел AUTOTITLE и README в документации по проекту GitHub Enterprise Server Backup Utilities.

Создание моментального снимка виртуальной машины

При обновлении до нового выпуска компонента требуется моментальный снимок виртуальной машины. При обновлении до выпуска исправления можно подключить существующий диск данных.

Создайте моментальный снимок виртуальной машины основного узла экземпляра непосредственно перед обновлением и только если режим обслуживания включен или экземпляр был отключен. См . раздел AUTOTITLE.

Установка пакета обновления

Ознакомьтесь с рекомендациями по обновлению и выполните все действия по подготовке, как описано выше, прежде чем приступить к установке пакета обновления.

Инструкции по обновлению экземпляра GitHub Enterprise Server отличаются в зависимости от типа выполняемого обновления и количества узлов, которые у вашего экземпляра.

•         [Обновление с помощью горячей патчи](/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-a-hotpatch#upgrading-with-a-hotpatch)
  

  * Обновление автономного экземпляра с помощью горячего исправления * Обновление экземпляра с несколькими узлами с помощью горячего исправления

•         [Обновление с помощью пакета обновления](/admin/upgrading-your-instance/performing-an-upgrade/upgrading-with-an-upgrade-package#upgrading-with-an-upgrade-package)
  

  * Обновление автономного экземпляра с помощью пакета обновления * Обновление экземпляра с несколькими узлами с помощью пакета обновления

Выполнение задач после обновления

• Проверьте состояние фоновых заданий и просмотрите журнал обновления ошибок.
• Проверьте базовые функции GitHub Enterprise Server . Например, убедитесь, что вы можете войти через пользовательский интерфейс и убедиться, что можно достичь нескольких организаций, репозиториев и проблем. Кроме того, рекомендуется вручную запускать несколько наборов, клонов и push-уведомлений с помощью SSH и HTTPS, а также проверять, что запросы API и доставки веб-перехватчиков завершены успешно.
• Повторное применение любых пользовательских правил брандмауэра. См . раздел AUTOTITLE.
• Удалите все моментальные снимки виртуальных машин, сделанные до обновления. См . раздел AUTOTITLE.
• Отключите режим обслуживания и обновите все сообщения перед обновлением, такие как баннеры объявлений. См. раздел [AUTOTITLE и Настройка сообщений для пользователей на предприятии](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
• Отслеживайте все фоновые задания в очереди в экземпляре, чтобы убедиться, что они успешно завершены. См . раздел AUTOTITLE.