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 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 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 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. -
Wenn Sie ein Upgrade von Version 3.11 oder 3.12 auf Version 3.13 oder höher durchführen, wird Elasticsearch als Teil des Upgrades auf Ihren Cluster aktualisiert. Weitere Informationen findest du unter Upgrading a cluster.
Vor dem Upgrade müssen Sie ein Skript ausführen, um Ihren Cluster für ein Upgrade auf 3.13 oder 3.14 vorzubereiten.
- Stellen Sie sicher, dass Sie die erforderliche Patchversion für Ihre aktuelle Version ausführen: 3.11.9 oder höher für 3.11 oder 3.12.3 oder höher für 3.12.
- Bei jedem/r
elasticsearch-server
Node, Ausführung/usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance
.
-
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 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.