Требования к обновлению

Рекомендации

• Включите как можно меньше обновлений в процесс обновления. Например, вместо обновления версии GitHub Enterprise 3.6 до 3.7 до 3.8, можно выполнить обновление версии GitHub Enterprise 3.6 до 3.8. Используйте Помощник по обновлению, чтобы найти путь обновления текущей версии.
• Если у вас несколько версий, обновите экземпляр GitHub Enterprise Server как можно дальше с каждым этапом процесса обновления. Использование самой актуальной версии в каждом обновлении позволяет использовать преимущества повышенной производительности и исправления ошибок. Например, можно выполнить обновление с GitHub Enterprise 2.7 до 2.8 и 2.10, однако для обновления с GitHub Enterprise 2.7 до 2.9 и 2.10 на втором этапе используется более поздняя версия.
• При обновлении используйте последний выпуск исправлений. Перейдите на страницу выпусков GitHub Enterprise Server. Рядом с выпуском, до которого вы обновляетесь, нажмите кнопку Скачать, а затем перейдите на вкладку Обновление.
• Используйте промежуточный экземпляр для проверки шагов обновления. Дополнительные сведения см. в разделе Настройка промежуточного экземпляра.
• При запуске нескольких обновлений подождите по крайней мере 24 часа между обновлениями компонентов, чтобы обеспечить полноценное выполнение миграции данных и задач обновления в фоновом режиме.
• Создайте моментальный снимок перед обновлением виртуальной машины. Дополнительные сведения см. в разделе Обновление GitHub Enterprise Server.
• Убедитесь, что у вас есть последняя успешная резервная копия экземпляра. Дополнительные сведения см. в файле README.md GitHub Enterprise Server Backup Utilities.

Требования

• Необходимо выполнить обновление выпуска, версия которого отстает не более, чем на две версии. Например, для обновления до версии GitHub Enterprise 3.8, требуется установленная версия GitHub Enterprise 3.7 или 3.6.
• При обновлении с помощью пакета обновления запланируйте период обслуживания для пользователей GitHub Enterprise Server.
• Вы можете обновить GitHub Enterprise Server до последнего выпуска исправлений с помощью горячего исправления.

Для обновления до следующего выпуска исправлений можно использовать горячее исправление, но не выпуск с новыми функциями. Например, можно обновить версию 2.10.1 до 2.10.5, так как они находятся в одном и том же ряде признаков, но не с версии 2.10.9 до 2.11.0, так как они находятся в другом ряде признаков.

Горячее исправление обычно не требует перезагрузки. Если для горячего исправления требуется перезагрузка, это требование указано в заметках о выпуске GitHub Enterprise Server.

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

• Для горячего исправления может потребоваться время простоя, если затрагиваемые службы (например, ядро, MySQL или Elasticsearch) требуют перезагрузки виртуальной машины или перезапуска службы. Вы получите уведомление о необходимости перезагрузки или перезапуска. Вы можете выполнить перезагрузку или перезапуск позднее.
• Дополнительное корневое хранилище должно быть доступно при обновлении посредством горячего исправления, так как при этом до завершения обновления будет установлено несколько версий определенных служб. По результатам предварительной проверки вы получите уведомление в случае, если у вас недостаточно пространства корневого дискового хранилища.
• При обновлении посредством горячего исправления экземпляр нельзя слишком загружать, так как это может повлиять на процесс горячего исправления.
• В процессе обновления до версии GitHub Enterprise Server 2.17 выполняется миграция журналов аудита из Elasticsearch в MySQL. Эта миграция также увеличивает время и место на диске, необходимое для восстановления моментального снимка. Перед миграцией проверьте число байтов в индексах журнала аудита Elasticsearch с помощью следующей команды:

  curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

  Используйте это число для оценки объема дискового пространства, необходимого для журналов аудита MySQL. Скрипт также отслеживает свободное место на диске в процессе импорта. Отслеживать это число особенно полезно, если свободное место на диске близко к объему дискового пространства, необходимого для миграции.

Дальнейшие действия

После просмотра этих рекомендаций и требований можно обновить GitHub Enterprise Server. Дополнительные сведения см. в разделе Обновление GitHub Enterprise Server.