Skip to main content

Upgrade mit einem Upgrade-Paket

Erfahre mehr zur Verwendung eines Upgradepakets, um GitHub Enterprise Server auf eine neuere Featureversion zu aktualisieren.

Über die Verwaltungsshell kannst du mit dem ghe-upgrade-Hilfsprogramm ein Upgradepaket installieren.

Wenn Back-to-Back-Upgrades der Featureversion vorgenommen werden, muss sichergestellt werden, dass Hintergrundaufträge abgeschlossen sind, bevor es mit dem folgenden Upgrade auf ein Featurerelease weitergehen kann. GitHub empfiehlt, 24 Stunden zwischen Upgrades zu warten, damit alle Hintergrundupgradeaufgaben abgeschlossen werden können, bevor ein zweites Upgrade vorgenommen wird. Siehe „Übersicht über den Upgradeprozess“ und „Upgrade-Anforderungen“.

Obwohl du einen Hotpatch verwenden kannst, um ein Upgrade auf den neuesten Patchrelease in einer Featureserie durchzuführen, musst du ein Upgradepaket verwenden, um ein Upgrade auf ein neueres Featurerelease durchzuführen. Wenn du beispielsweise ein Upgrade von 2.11.10 auf 2.12.4 durchführen möchtest, musst du ein Upgradepaket verwenden, da es sich um unterschiedliche Featureserien handelt.

Aktualisieren einer eigenständigen Instanz mit einem Upgradepaket

Note

Wenn du die Prüfung auf automatische Updates aktiviert hast, musst du das Upgradepaket nicht herunterladen und kannst die automatisch heruntergeladene Datei verwenden. Weitere Informationen findest du unter Prüfungen auf automatische Updates aktivieren.

  1. Melde dich über SSH bei Ihre GitHub Enterprise Server-Instance an. Wenn deine Instanz mehrere Knoten umfasst, wenn z. B. Hochverfügbarkeit oder Georeplikation konfiguriert ist, wird SSH im primären Knoten konfiguriert. Wenn du einen Cluster verwendest, kannst du SSH in einen beliebigen Knoten einfügen. Ersetzen Sie HOSTNAME durch den Hostnamen Ihrer Instanz bzw. durch den Hostnamen oder die IP-Adresse eines Knotens. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. Navigiere zur Seite „GitHub Enterprise Server-Releases“. Klicke neben dem Release, auf welches das Upgrade durchgeführt wird, auf Herunterladen, und klicke dann auf die Registerkarte Upgrade. Wähle die geeignete Plattform aus, und kopiere die URL für das Upgradepaket (.pkg-Datei).

  3. Lade das Upgradepaket mithilfe von curl auf Ihre GitHub Enterprise Server-Instance herunter:

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
    
  4. Aktiviere den Wartungsmodus, und warte, bis alle aktiven Prozesse auf der GitHub Enterprise Server-Instanz abgeschlossen sind. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.

    Note

    Wenn du in einer Hochverfügbarkeitskonfiguration ein Upgrade des primären Knotens durchführst, sollte sich die Instanz bereits im Wartungsmodus befinden, sofern du die unter „Aktualisieren des primären Knotens“ beschriebenen Anweisungen befolgst“.

  5. Führe den ghe-upgrade-Befehl mithilfe des Paketdateinamens aus:

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
    
  6. Bestätige, dass du das Upgrade fortsetzen möchtest, und führe nach der Überprüfung der Paketsignatur einen Neustart durch. Das neue Root-Dateisystem schreibt in die sekundäre Partition, und die Instanz startet automatisch im Wartungsmodus neu:

    *** 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. Optional kannst du während eines Upgrades auf ein Featurerelease den Status von Datenbankmigrationen mithilfe des Hilfsprogramms ghe-migrations überwachen. Weitere Informationen finden Sie unter Befehlszeilenprogramme.

  8. Nach dem Neustart der Instanz wird das Upgrade im Hintergrund fortgesetzt. Du kannst den Wartungsmodus erst beenden, wenn der Prozess abgeschlossen ist.

Der Status von Hintergrundaufträgen kann mit dem Hilfsprogramm ghe-check-background-upgrade-jobs geprüft werden. Wenn Back-to-Back-Upgrades vorgenommen werden, muss sichergestellt werden, dass Hintergrundaufträge abgeschlossen sind, bevor es mit dem folgenden Upgrade auf ein Featurerelease weitergehen kann. Um dieses Dienstprogramm mit GitHub Enterprise Server 3.11 zu verwenden, muss auf deiner Instanz die Version 3.111 oder höher laufen. Siehe „Befehlszeilenprogramme“.

Zum Überwachen des Fortschritts der Konfigurationsausführung kann man die Ausgabe in /data/user/common/ghe-config.log lesen. Beispielsweise kannst du mit dem folgenden Befehl Einträge an das Protokoll anhängen:

tail -f /data/user/common/ghe-config.log
  1. Optional kannst du nach dem Upgrade zum Validieren eine IP-Ausnahmeliste konfigurieren, um den Zugriff auf eine bestimmte Liste von IP-Adressen zuzulassen. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.

  2. Führe bei Upgrades einzelner Knoten alle Aufgaben nach dem Upgrade durch, einschließlich der Deaktivierung des Wartungsmodus, damit die Benutzer Ihre GitHub Enterprise Server-Instance verwenden können.

    Note

    Nachdem du in einer Hochverfügbarkeitskonfiguration ein Upgrade einer Instanz durchgeführt hast, solltest du im Wartungsmodus bleiben, bis ein Upgrade sämtlicher Replikatknoten durchgeführt wurde und die Replikation aktuell ist. Siehe „Aktualisieren weiterer Knoten mit einem Upgradepaket.“

Aktualisieren einer Instanz mit mehreren Knoten mit einem Upgradepaket

Um eine Instanz mit mehreren Knoten mithilfe eines Upgradepakets zu aktualisieren, musst du zunächst den primären Knoten und danach alle weiteren Knoten aktualisieren.

Aktualisieren des primären Knotens mit einem Upgradepaket

Warning

Wenn die Replikation angehalten wird, geht im Falle eines Fehlschlagens der primären Instanz die Arbeit verloren, die vor dem Upgrade des Replikats und dem Start der Replikation erledigt wird.

  1. Aktiviere auf dem primären Knoten den Wartungsmodus, und warte auf den Abschluss sämtlicher aktiver Prozesse. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.

  2. Stelle per SSH als Benutzer admin über Port 122 eine Verbindung mit dem Replikatknoten her:

    ssh -p 122 admin@REPLICA_HOST
    
  3. Um die Replikation auf allen Knoten zu beenden, führe ghe-repl-stop auf jedem Knoten aus.{ % ifversion ghes > 3.13 %} Alternativ kannst du bei mehreren Replikaten stattdessen ghe-repl-stop-all auf dem primären Knoten ausführen, wodurch die Replikation in einem einzigen Durchlauf beendet wird.{ % endif %}

  4. Befolge zum Aktualisieren des primären Knotens die Anweisungen unter Aktualisieren einer eigenständigen Instanz mithilfe eines Upgradepakets.

Aktualisieren weiterer Knoten mit einem Upgradepaket

  1. Aktualisiere den Knoten gemäß der Anweisungen unter Aktualisieren einer eigenständigen Instanz mithilfe eines Upgradepakets.

  2. Stelle per SSH als Benutzer admin über Port 122 eine Verbindung mit dem Replikatknoten her:

    ssh -p 122 admin@REPLICA_HOST
    
  3. Führe Folgendes aus, um das Upgrade zu überprüfen:

    ghe-version
    
  4. Führe zum Starten der Replikation auf dem Replikatknoten den Befehl ghe-repl-start aus. 1. Führe ghe-repl-status auf dem Replikatknoten aus, um sicherzustellen, dass die Replikationsdienste ordnungsgemäß ausgeführt werden. Dieser Befehl gibt für alle Dienste OK zurück, wenn eine erfolgreiche Replikation verarbeitet wird und für das Replikat ein Upgrade durchgeführt wurde. Wenn der Befehl Replication is not running zurückgibt, wird die Replikation möglicherweise noch gestartet. Warte ungefähr eine Minute, bevor du ghe-repl-status erneut ausführst.

Note

  • Während der Neusynchronisierung kann ghe-repl-status anzeigen, dass die Replikation im Rückstand ist. Es wird möglicherweise die folgende Meldung angezeigt.

    CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
    
  • Wenn GitHub Actions für Ihre GitHub Enterprise Server-Instance aktiviert sind, wird möglicherweise eine Meldung wie folgt angezeigt. Diese Meldung wird erwartet, wenn die Replikation angehalten wird, da Wartungsmodus für die primäre Anwendung festgelegt wird. Sobald Wartungsodus nicht festgelegt ist, sollte diese Meldung gelöscht werden.

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

Wenn ghe-repl-status nicht OK zurückgegeben hat und die Erklärung nicht in der obigen Notiz aufgeführt ist, wenden Sie sich an GitHub Enterprise Support. Weitere Informationen findest du unter Kontaktieren des GitHub-Supports.

  1. Wiederhole die obigen Schritte für jeden zusätzlichen Knoten.
  2. Nachdem der letzte Replikatknoten aktualisiert und die erneute Synchronisierung beendet wurde, deaktivierst du den Wartungsmodus, damit die Benutzer*innen Ihre GitHub Enterprise Server-Instance verwenden können.