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.
-
Sichere deine Daten mit GitHub Enterprise Server Backup Utilities.
-
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
-
Überprüfe die Clusternetzwerkkonfiguration auf die Version, auf die du ein Upgrade durchführst, und aktualisiere deine Konfiguration bei Bedarf.
-
Sichere deine Daten mit GitHub Enterprise Server Backup Utilities.
-
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.
-
Kopiere auf der GitHub Enterprise Server-Downloadseite die URL für das Upgrade der PKG-Datei in die Zwischenablage.
-
Führe über die Verwaltungsshell eines beliebigen Knotens den Befehl
ghe-cluster-each
in Kombination mitcurl
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
-
Identifiziere den primären MySQL-Knoten, der in
cluster.conf
alsmysql-master = <hostname>
definiert ist. Dieser Knoten wird zuletzt upgegradet.
Clusterknoten upgraden
-
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. -
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>"
-
Der Upgrade-Prozess startet den Knoten nach dem Abschluss neu. Stelle sicher, dass du jeden Knoten nach dem Neustart pingen (
ping
) kannst. -
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>"
-
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. -
Stelle eine Verbindung mit der Verwaltungsshell des primären MySQL-Knotens her, und führe den
ghe-cluster-config-apply
-Befehl aus. -
Überprüfe nach Abschluss von
ghe-cluster-config-apply
durch das Ausführen vonghe-cluster-status
, ob die Dienste problemlos funktionieren. -
Beende den Wartungsmodus über die Verwaltungsshell eines beliebigen Knotens, indem du
ghe-cluster-maintenance -u
ausführst.