Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

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

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

Примечания.

  • Пакеты обновления доступны в enterprise.github.com для поддерживаемых версий. Убедитесь в доступности пакетов обновления, которые вам потребуются для обновления. Если пакет недоступен, обратитесь к GitHub Enterprise Support для получения помощи.
  • Если вы используете кластеризацию GitHub Enterprise Server, см. раздел Обновление кластера в руководстве по кластеризации GitHub Enterprise Server, где приведены конкретные инструкции по кластеризации.
  • Заметки о выпуске для GitHub Enterprise Server предоставляют полный список новых возможностей для каждой версии GitHub Enterprise Server. Дополнительные сведения см. на страницах, посвященных выпускам.

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

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

Требования

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

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

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

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

  • Для горячего исправления может потребоваться время простоя, если затрагиваемые службы (например, ядро, 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.