Skip to main content

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

Узнайте, как использовать пакет обновления для обновления GitHub Enterprise Server до более нового выпуска компонента.

С помощью административной оболочки можно установить пакет обновления с помощью служебной ghe-upgrade программы.

Если вы выполняете обновления версий компонентов обратно на спину, необходимо убедиться, что фоновые задания завершены, прежде чем продолжить следующее обновление до выпуска компонента. GitHub рекомендует ожидать завершения всех задач фонового обновления перед обновлением во второй раз. См. раздел [AUTOTITLE и Обзор процесса обновления](/admin/enterprise-management/updating-the-virtual-machine-and-physical-resources/upgrade-requirements).

В то время как для обновления до последнего выпуска исправления в рамках выпуска с новыми функциями можно использовать горячее исправление, для обновления до более нового выпуска с новыми функциями необходимо использовать пакет обновления. Например, для обновления с версии 2.11.10 до версии 2.12.4 необходимо использовать пакет обновления, так как они находятся в разных рядах компонентов.

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

Примечание.

Если вы включили автоматическую проверку обновлений, вам не нужно скачать пакет обновления и использовать файл, который был автоматически скачан. Дополнительные сведения см. в разделе Включение автоматических проверок обновлений.

  1. SSH в ваш экземпляр GitHub Enterprise Server. Если экземпляр состоит из нескольких узлов, например, если настроен высокий уровень доступности или георепликация, передача осуществляется по SSH в основной узел. При использовании кластера можно использовать для передачи по SSH в любой узел. Замените HOSTNAME именем узла для экземпляра, именем узла или IP-адресом узла. Дополнительные сведения см. в разделе Доступ к административной оболочке (SSH).

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. Перейдите на страницу выпусков GitHub Enterprise Server. Рядом с выпуском, до которого вы обновляетесь, нажмите кнопку Скачать, а затем перейдите на вкладку Обновление. Выберите соответствующую платформу и скопируйте URL-адрес пакета обновления (файл PKG).

  3. Скачайте пакет обновления до ваш экземпляр GitHub Enterprise Server с помощью curl:

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
    
  4. Включите режим обслуживания и дождитесь завершения всех активных процессов в экземпляре GitHub Enterprise Server. См . раздел AUTOTITLE.

    Примечание.

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

  5. Выполните команду ghe-upgrade, используя имя файла пакета:

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
    
  6. Подтвердите, что вы хотите продолжить обновление, и выполните перезапуск после проверки подписи пакета. Новая корневая файловая система запишется в дополнительную секцию, и экземпляр автоматически перезапустится в режиме обслуживания:

    *** applying update...
    This package will upgrade your installation to version VERSION-NUMBER
    Current root partition: /dev/xvda1 [VERSION-NUMBER]
    Target root partition:  /dev/xvda2
    Proceed with installation? [y/N]
    
  7. При необходимости во время обновления до выпуска компонента можно отслеживать состояние миграции базы данных с помощью служебной ghe-migrations программы. См . раздел AUTOTITLE.

  8. После перезапуска экземпляра обновление продолжится в фоновом режиме. Не удается установить режим обслуживания до завершения процесса.

    Чтобы проверить состояние фоновых заданий, используйте служебную ghe-check-background-upgrade-jobs программу. Если выполняется резервное обновление, необходимо убедиться, что фоновые задания завершены, прежде чем продолжить обновление до следующего выпуска компонента.

    См . раздел AUTOTITLE.

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

    tail -f /data/user/common/ghe-config.log
    
  9. При необходимости после обновления проверьте обновление, настроив список исключений IP, чтобы разрешить доступ к указанному списку IP-адресов. См . раздел AUTOTITLE.

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

    Примечание.

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

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

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

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

Предупреждение

При остановке репликации при сбое основной операции все действия перед обновлением реплики и репликация начнется снова.

  1. На основном узле включите режим обслуживания и дождитесь завершения всех активных процессов. См . раздел AUTOTITLE.

  2. Подключитесь к узлу реплики через SSH от имени admin пользователя через порт 122:

    ssh -p 122 admin@REPLICA_HOST
    
  3. Чтобы остановить репликацию на всех узлах, выполните на ghe-repl-stop каждом узле. Кроме того, при наличии нескольких реплик запустите ghe-repl-stop-all на основном узле, который остановит репликацию в одном запуске.

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

Обновление дополнительных узлов с помощью пакета обновления

  1. Обновите узел, выполнив инструкции по обновлению автономного экземпляра с помощью пакета обновления.

  2. Подключитесь к узлу реплики через SSH от имени admin пользователя через порт 122:

    ssh -p 122 admin@REPLICA_HOST
    
  3. Проверьте обновление:

    ghe-version
    
  4. Чтобы запустить репликацию, запустите ghe-repl-startузел реплики. Кроме того, если существует несколько реплик, запуститеся ghe-repl-start-all на основном узле, который запустит репликацию в одном запуске.

  5. Чтобы убедиться, что службы репликации работают правильно, запустите ghe-repl-statusузел реплики. Она возвращает OK для всех служб в случае успешной репликации и обновления реплики. Если команда возвращается Replication is not running, репликация по-прежнему может начинаться. Подождите примерно одну минуту, прежде чем снова выполнять команду ghe-repl-status.

Примечание.

  • Хотя ресинхронная синхронизация выполняется ghe-repl-status , может указывать на то, что репликация находится за пределами. Например, может отображаться следующее сообщение.

    CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
    
  • Если GitHub Actions включен в ваш экземпляр GitHub Enterprise Server, может отображаться следующее сообщение. Это сообщение ожидается, когда репликация приостановлена из-за режима обслуживания, установленного на основном устройстве. После отмены режима обслуживания это сообщение должно быть разрешено.

    CRITICAL: mssql replication is down, didn't find Token_Configuration!
    

Если ghe-repl-status это не было возвращено OK, и объяснение не указано в приведенной выше заметке, обратитесь к Поддержка GitHub Enterprise. Дополнительные сведения см. в разделе Обращение в службу поддержки GitHub.

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