Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-03-26. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Cluster-Upgrade

Verwende die Verwaltungsshell (SSH), um ein Upgrade eines GitHub Enterprise Server-Clusters auf die neueste Version durchzuführen.

Wer kann dieses Feature verwenden?

GitHub bestimmt die Berechtigung zum Clustering und muss die Konfiguration für die Lizenz deiner Instanz aktivieren. Das Clustering erfordert eine sorgfältige Planung und zusätzlichen Verwaltungsaufwand. Weitere Informationen findest du unter Informationen zu Clustering.

Informationen zu Upgrades auf einen GitHub Enterprise Server-Cluster

GitHub Enterprise Server wird ständig mit neuen Funktionen und Fehlerkorrekturen verbessert, die über Feature- und Patchreleases eingeführt werden. Du bist für Upgrades deiner Instanz verantwortlich. Weitere Informationen findest du unter Informationen zu Upgrades auf neue Releases.

Zum Upgrade einer Instanz musst du das Upgrade planen und kommunizieren, das entsprechende Paket auswählen, deine Daten sichern und dann das Upgrade durchführen.

Upgrade mit einem Hotpatch

Du kannst GitHub Enterprise Server auf das neueste Patchrelease mithilfe eines Hotpatches upgraden.

Mittels Hotpatching kannst Du ein Upgrade auf einen neueren Patch-Release durchführen, jedoch keine Feature-Veröffentlichung. Du kannst z. B. ein Upgrade von 2.10.1 auf 2.10.5 durchführen, da sich beide Releases in derselben Featureserie befinden. Ein Upgrade von 2.10.9 auf 2.11.0 ist hingegen nicht möglich, da diese Releases unterschiedlichen Featureserien angehören.

Hotpatches erfordern in der Regel keinen Neustart. Wenn ein Hotpatch einen Neustart erfordert, geben die GitHub Enterprise Server-Versionshinweise die Anforderung an.

Hotpatches erfordern eine Konfigurationsausführung, was für einige oder alle Dienste auf Ihre GitHub Enterprise Server-Instance zu einer kurzen Fehlerperiode oder zu einer ausbleibenden Reaktion führen kann. Du musst den Wartungsmodus während der Installation eines Hotpatches nicht aktivieren, aber dadurch wird sichergestellt, dass Benutzer*innen eine Wartungsseite anstelle von Fehlern oder Timeouts angezeigt wird. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen. Das Hotpatch-Installationsskript installiert den Hotpatch auf jedem Knoten im Cluster und startet die Dienste zum Vermeiden von Ausfallzeiten in ihrer entsprechenden Abfolge neu.

  1. Sichere deine Daten mit GitHub Enterprise Server Backup Utilities.

  2. Führe den Befehl ghe-cluster-hotpatch über die Verwaltungsshell eines beliebigen Knotens aus, um den neuesten Hotpatch zu installieren. Du kannst eine URL für einen Hotpatch bereitstellen oder den Hotpatch manuell herunterladen und einen lokalen Dateinamen angeben.

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

Upgrade mit einem Upgrade-Paket

Verwende ein Upgrade-Paket, um ein Upgrade eines GitHub Enterprise Server-Clusters auf die neueste Feature-Veröffentlichung vorzunehmen. Du kannst beispielsweise ein Upgrade von Version 2.11 auf Version 2.13 durchführen.

Upgrade vorbereiten

  1. Überprüfe die Clusternetzwerkkonfiguration auf die Version, auf die du ein Upgrade durchführst, und aktualisiere deine Konfiguration bei Bedarf.

  2. Sichere deine Daten mit GitHub Enterprise Server Backup Utilities.

  3. Plane ein Wartungsfenster für Endbenutzer deines GitHub Enterprise Server-Clusters, da er während des Upgrades für die normale Nutzung nicht verfügbar ist. Der Wartungsmodus blockiert den Benutzerzugriff und verhindert Datenänderungen, während das Cluster-Upgrade ausgeführt wird.

  4. Kopiere auf der GitHub Enterprise Server-Downloadseite die URL für das Upgrade der PKG-Datei in die Zwischenablage.

  5. Führe über die Verwaltungsshell eines beliebigen Knotens den Befehl ghe-cluster-each in Kombination mit curl aus, um das Releasepaket in einem einzelnen Schritt in jeden Knoten herunterzuladen. Verwende die im vorherigen Schritt von dir kopierte URL als ein Argument.

    $ 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. Identifiziere den primären MySQL-Knoten, der in cluster.conf als mysql-master = <hostname> definiert ist. Dieser Knoten wird zuletzt upgegradet.

Clusterknoten upgraden

  1. Aktiviere den Wartungsmodus gemäß deinem geplanten Fenster, indem du eine Verbindung mit der Verwaltungsshell eines beliebigen Serverknotens herstellst und ghe-cluster-maintenance -s ausführst.

  2. Stelle mit Ausnahme des primären MySQL-Knotens eine Verbindung mit der Verwaltungsshell der jeweiligen GitHub Enterprise Server-Knoten her. Führe den Befehl ghe-upgrade aus, indem du den Namen der Paketdatei angibst, die du in Schritt 4 des Abschnitts Vorbereiten des Upgrades heruntergeladen hast:

    $ 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>"
    
  3. Der Upgrade-Prozess startet den Knoten nach dem Abschluss neu. Stelle sicher, dass du jeden Knoten nach dem Neustart pingen (ping) kannst.

  4. Stelle auf dem primären MySQL-Knoten eine Verbindung zur Verwaltungsshell her. Führe den Befehl ghe-upgrade aus, indem du den Namen der Paketdatei angibst, die du in Schritt 4 des Abschnitts Vorbereiten des Upgrades heruntergeladen hast:

    $ 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>"
    
  5. Der Upgrade-Prozess startet den primären MySQL-Knoten nach dem Abschluss neu. Stelle sicher, dass du jeden Knoten nach dem Neustart pingen (ping) kannst.

  6. Stelle eine Verbindung mit der Verwaltungsshell des primären MySQL-Knotens her, und führe den ghe-cluster-config-apply-Befehl aus.

  7. Überprüfe nach Abschluss von ghe-cluster-config-apply durch das Ausführen von ghe-cluster-status, ob die Dienste problemlos funktionieren.

  8. Beende den Wartungsmodus über die Verwaltungsshell eines beliebigen Knotens, indem du ghe-cluster-maintenance -u ausführst.