Эта версия GitHub Enterprise Server была прекращена 2024-12-19. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Обновление кластера

Чтобы обновить кластер GitHub Enterprise Server до последнего выпуска, используйте административную оболочку (SSH).

Кто может использовать эту функцию?

GitHub определяет право кластеризации и должен включить конфигурацию лицензии вашего экземпляра. Кластеризация требует тщательного планирования и дополнительных административных накладных расходов. Дополнительные сведения см. в разделе Сведения о кластеризации.

В этой статье

Об обновлении до кластера GitHub Enterprise Server

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

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

Обновление с помощью горячего исправления

Вы можете обновить GitHub Enterprise Server до последнего выпуска исправления с помощью горячего исправления.

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

Горячие патчи не всегда требуют перезагрузки. При установке горячего исправления вы увидите сообщение в терминале, если для завершения обновления потребуется перезагрузка пакетов. Вы можете запланировать эту перезагрузку в удобное время, но мы рекомендуем перезагрузить как можно скорее практически, особенно если есть какие-либо исправления безопасности.

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

  1. Создайте резервную копию данных с помощью GitHub Enterprise Server Backup Utilities.

  2. В административной оболочке любого узла выполните команду ghe-cluster-hotpatch, чтобы установить последнюю версию горячего исправления. Вы можете указать URL-адрес для горячего исправления или вручную скачать горячее исправление и указать имя локального файла.

    ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg

Обновление с помощью пакета обновления

Используйте пакет обновления для обновления кластера GitHub Enterprise Server до последней версии компонента. Например, можно выполнить обновление с 2.11 до 2.13.

Подготовка к обновлению

  1. Просмотрите Конфигурация сети кластера для версии, на который выполняется обновление, и при необходимости обновите конфигурацию.

  2. Создайте резервную копию данных с помощью GitHub Enterprise Server Backup Utilities.

  3. Запланируйте период обслуживания для конечных пользователей кластера GitHub Enterprise Server, так как он будет недоступен для нормального использования во время обновления. Режим обслуживания блокирует доступ пользователей и предотвращает изменения данных во время обновления кластера.

  4. На странице скачивания GitHub Enterprise Server скопируйте URL-адрес для PKG-файла обновления в буфер обмена.

  5. В административной оболочке любого узла используйте команду ghe-cluster-each вместе с curl для скачивания пакета выпуска на каждый узел за один шаг. Используйте URL-адрес, скопированный на предыдущем шаге, в качестве аргумента.

    $ ghe-cluster-each -- "cd /home/admin && curl -L -O https://PACKAGE-URL.pkg"
> ghe-app-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  24.2M      0  0:00:20  0:00:20 --:--:-- 27.4M
> ghe-data-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  21.3M      0  0:00:23  0:00:23 --:--:-- 25.8M
> ghe-data-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.6M
> ghe-app-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.8M      0  0:00:25  0:00:25 --:--:-- 17.6M
> ghe-data-node-3:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-3:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.5M

  6. Определите основной узел MySQL, который определен как mysql-master = <hostname> в cluster.conf. Этот узел будет обновлен последним.

Обновление узлов кластера

  1. Включите режим обслуживания в соответствии с запланированным периодом, подключившись к административной оболочке любого узла кластера и выполнив команду ghe-cluster-maintenance -s.

  2. При обновлении с версии 3.11 или 3.12 до версии 3.13 или более поздней, Elasticsearch будет обновлен в рамках обновления кластера. Дополнительные сведения см. в разделе Подготовка к обновлению Elasticsearch в GitHub Enterprise Server 3.13.

    Перед обновлением необходимо запустить скрипт для подготовки кластера к обновлению до версии 3.13 или 3.14.

    1. Убедитесь, что вы используете необходимый выпуск исправления для текущей версии: 3.11.9 или более поздней версии для версии 3.11 или 3.12.3 или более поздней версии.
    2. На любом elasticsearch-server узле выполните команду /usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance.

  3. Подключитесь к административной оболочке каждого узла GitHub Enterprise Server, за исключением основного узла MySQL. ghe-upgrade Выполните команду, указав имя файла пакета, скачаемое на шаге 4 подготовки к обновлению:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

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

  5. Подключитесь к административной оболочке основного узла MySQL. ghe-upgrade Выполните команду, указав имя файла пакета, скачаемое на шаге 4 подготовки к обновлению:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

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

    Important

    Прежде чем перейти к следующему шагу, необходимо дождаться завершения настройки после обновления. Чтобы отслеживать ход выполнения конфигурации, ознакомьтесь с выходными данными /data/user/common/ghe-config.log. Например, журнал можно хвостить, выполнив следующую команду:

    tail -f /data/user/common/ghe-config.log

  7. Подключитесь к административной оболочке основного узла MySQL и выполните команду ghe-cluster-config-apply.

  8. После ghe-cluster-config-apply завершения убедитесь, что службы находятся в работоспособном состоянии, выполнив команду ghe-cluster-status.

  9. Выйдите из административной оболочки любого узла, выполнив команду ghe-cluster-maintenance -u.