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

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

Чтобы обновить экземпляр, необходимо выполнить следующие действия.

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

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

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

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

• Просмотрите заметки о выпуске и задокументированные известные проблемы перед обновлением. См. раздел [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 до более новой версии после обновления инстанции.

  См. Настройка резервных копий в экземпляре с помощью служебных программ резервного копирования и README в GitHub Enterprise Server Backup Utilities документации проекта.

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

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

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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