Cluster-Upgrade

Informationen zu Upgrades auf einen GitHub Enterprise Server-Cluster

GitHub Enterprise Server wird ständig verbessert, mit neuen Funktionen und Fehlerkorrekturen, die über Feature- und Patchversionen eingeführt wurden. 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 immer keinen Neustart. Wenn Sie den Hotpatch installieren, wird eine Meldung im Terminal angezeigt, wenn eines der Pakete einen Neustart benötigt, um das Update abzuschließen. Sie können diesen Neustart zu einem Ihnen passenden Zeitpunkt planen, es wird jedoch empfohlen, den Neustart so schnell wie möglich durchzuführen, insbesondere, wenn Sicherheitsupdates vorhanden sind.

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 finden Sie 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

Prüfen Sie unter Clusternetzwerk-Konfiguration die Version, auf die ein Upgrade vorgenommen werden soll, und aktualisieren Sie Ihre 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 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

Identifiziere den primären MySQL-Knoten, der in cluster.conf als mysql-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ühren Sie den Befehl ghe-upgrade aus, indem Sie den Namen der Paketdatei angeben, die in Schritt 4 des Abschnitts Vorbereiten des Upgrades heruntergeladen wurde:

$ 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ühren Sie den Befehl ghe-upgrade aus, indem Sie den Namen der Paketdatei angeben, die in Schritt 4 des Abschnitts Vorbereiten des Upgrades heruntergeladen wurde:

$ 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. Stellen sicher, dass Sie jeden Knoten nach dem Neustart ping können.
Important

Bevor Sie mit dem nächsten Schritt fortfahren, müssen Sie warten, bis die Konfiguration nach dem Upgrade abgeschlossen ist. 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
```
Stelle eine Verbindung mit der Verwaltungsshell des primären MySQL-Knotens her, und führe den ghe-cluster-config-apply-Befehl aus.
Überprüfen Sie nach Abschluss von ghe-cluster-config-apply durch das Ausführen von ghe-cluster-status, ob die Dienste problemlos funktionieren.
Beende den Wartungsmodus über die Verwaltungsshell eines beliebigen Knotens, indem du ghe-cluster-maintenance -u ausführst.