Informationen zu Upgrades auf GitHub Enterprise Server
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.
Voraussetzungen
Für ein erfolgreiches Upgrade von Ihre GitHub Enterprise Server-Instance muss der Datenträger der Instanz zu mindestens 15 % frei sein. GitHub empfiehlt jedoch mehr freien Speicherplatz auf dem Datenträger. In einigen seltenen Fällen kann dieser Schwellenwert für Kundschaft mit großen Datenvolumen abweichen.
Upgrade vorbereiten
Zur Vorbereitung eines Upgrades planst du den Upgradepfad, führst optional ein Upgrade für GitHub Actions-Runner durch, und planst ein Wartungsfenster.
-
Bestimme eine Upgrade-Strategie, und wähle eine Version aus, auf die das Upgrade durchgeführt werden soll. Weitere Informationen findest du unter Upgrade-Anforderungen und im Upgrade-Assistent, mit dem du den Upgradepfad für deine aktuelle Version ermitteln kannst.
-
Erstelle mit den GitHub Enterprise Server Backup Utilities ein neues Backup des primären Knotens deiner Instanz. Weitere Informationen findest du in der Datei README der Projektdokumentation zu GitHub Enterprise Server Backup Utilities.
Hinweis: Deine GitHub Enterprise Server Backup Utilities-Version darf nicht älter als die vorletzte Version von Ihre GitHub Enterprise Server-Instance sein. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf einer Instanz.
-
Wenn Ihre GitHub Enterprise Server-Instance kurzlebige selbstgehostete Runner für GitHub Actions verwendet und du automatische Updates deaktiviert hast, führe für deine Runner ein Upgrade auf die Version der Runneranwendung durch, die auf deiner aktualisierten Instanz ausgeführt werden soll.
-
Wenn du mithilfe eines Upgrade-Pakets ein Upgrade durchführst, solltest du ein Wartungsfenster für GitHub Enterprise Server-Endbenutzer*innen einplanen. Bei Verwendung eines Hotpatches muss der Wartungsmodus nicht verwendet werden.
Hinweis: Das Wartungsfenster hängt vom Typ des Upgrades ab, das du ausführst. Für Upgrades mittels Hotpatch ist in der Regel kein Wartungsfenster erforderlich. Manchmal ist ein Neustart erforderlich, den du später durchführen kannst. Entsprechend dem Versionierungsschema von MAJOR.FEATURE.PATCH führen Patch-Veröffentlichungen mit einem Upgrade-Paket in der Regel zu weniger als fünf Minuten Ausfallzeit. Feature-Veröffentlichungen mit enthaltenen Datenmigrationen dauern anhand der Speicherleistung und der zu migrierenden Daten entsprechend länger. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
Snapshot erstellen
In einer Momentaufnahme wird der Zustand einer VM (virtueller Computer) zu einem bestimmten Zeitpunkt gespeichert. GitHub empfiehlt dringend, eine Momentaufnahme zu erstellen, bevor du ein Upgrade für deine VM durchführst, damit du bei einem fehlerhaften Upgrade deine VM auf die Momentaufnahme zurücksetzen kannst. GitHub empfiehlt, nur dann eine VM-Momentaufnahme zu erstellen, wenn die VM der Instanz heruntergefahren wurde oder sich die Instanz im Wartungsmodus befindet und alle Hintergrundaufträge abgeschlossen sind.
Wenn du ein Upgrade auf ein neues Featurerelease durchführst, musst du eine VM-Momentaufnahme erstellen. Wenn du ein Upgrade auf ein Patchrelease durchführst, kannst du den vorhandenen Datenträger anhängen.
Es gibt zwei Snapshot-Typen:
-
VM-Momentaufnahmen speichern den gesamten VM-Zustand, einschließlich der Benutzer- und Konfigurationsdaten. Für diese zeitraubende Snapshot-Methode ist viel Speicherplatz erforderlich.
-
Datendatenträger-Momentaufnahmen speichern nur deine Benutzerdaten.
Hinweise:
- Bei einigen Plattformen kannst du nicht nur eine Momentaufnahme deines Datenträgers erstellen. Bei diesen Plattformen musst du eine Momentaufnahme der gesamten VM erstellen.
- Wenn von deinem Hypervisor keine vollständigen VM-Momentaufnahmen unterstützt werden, kannst du in schneller Abfolge Momentaufnahmen von Root-Disk und Datenträger erstellen.
Plattform | Momentaufnahmenmethode | Dokumentation |
---|---|---|
Amazon AWS | Datenträger | Erstellen von Amazon EBS-Momentaufnahmen in der AWS-Dokumentation |
Azure | VM | Erstellen eines Snaphots einer virtuellen Festplatte auf einer Azure-VM in Microsoft Learn |
Hyper-V | VM | Aktivieren oder Deaktivieren von Prüfpunkten in Hyper-V in Microsoft Learn |
Google Compute Engine | Datenträger | Erstellen und Verwalten von Datenträgermomentaufnahmen in der Google Cloud-Dokumentation |
VMware | VM | Erstellen von Momentaufnahmen eines virtuellen Computers in der VMware-Dokumentation |
Auswählen eines Upgradepakets
Du kannst eine GitHub Enterprise Server-Instanz auf ein neues Patchrelease oder ein neues Featurerelease aktualisieren. Für ein Upgrade auf ein Patchrelease kannst du einen Hotpatch oder ein Upgradepaket verwenden. Für ein Upgrade auf ein Featurerelease musst du ein Upgradepaket verwenden.
Eine GitHub Enterprise Server-Instanz umfasst mindestens einen Knoten. Dein Upgradeprozess hängt davon ab, wie viele Knoten deine Instanz hat. Weitere Informationen findest du unter Informationen zu GitHub Enterprise Server.
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.
Mit der Verwaltungskonsole kannst du einen Hotpatch sofort installieren oder für die spätere Installation planen. Über die Verwaltungsshell kannst du mit dem ghe-upgrade
-Hilfsprogramm einen Hotpatch installieren. Weitere Informationen findest du unter Upgrade-Anforderungen.
Hinweise:
-
Wenn Ihre GitHub Enterprise Server-Instance einen Release Candidate-Build ausführt, kannst du kein Upgrade mit einem Hotpatch durchführen.
-
Für Cluster ist die Installation eines Hotpatches mithilfe der Verwaltungskonsole nicht verfügbar. Informationen zum Installieren eines Hotpatches für einen Cluster findest du unter Cluster-Upgrade.
- Aktualisieren einer eigenständigen Instanz mit einem Hotpatch
- Aktualisieren einer Instanz mit mehreren Knoten mit einem Hotpatch
Aktualisieren einer eigenständigen Instanz mit einem Hotpatch
Wenn du ein Upgrade einer Instanz mit einem Knoten mit einem Hotpatch durchführst und dein Ziel ein Patchrelease ist, kannst du die Verwaltungskonsole verwenden. Um ein Upgrade auf ein Featurerelease durchzuführen, musst du die Verwaltungsshell verwenden.
Hotpatch mit der Verwaltungskonsole installieren
Du kannst die Verwaltungskonsole verwenden, um ein Upgrade mit einem Hotpatch durchzuführen, indem du automatische Updates aktivierst. Anschließend erhältst du die neueste verfügbare Version von GitHub Enterprise Server, auf die du ein Upgrade ausführen kannst.
Wenn das Upgrade-Ziel ein Featurerelease anstatt eines Patchrelease ist, kannst du die Verwaltungskonsole nicht verwenden, um einen Hotpatch zu installieren. Du musst den Hotpatch stattdessen mithilfe der Verwaltungsshell installieren. Weitere Informationen findest du unter Installieren eines Hotpatches mithilfe der Verwaltungsshell.
-
Aktivieren automatischer Updates. Weitere Informationen findest du unter Prüfungen auf automatische Updates aktivieren.
-
Klicke in einem Verwaltungskonto auf GitHub Enterprise Server und dann in der rechten oberen Ecke einer beliebigen Seite auf „“.
-
Wenn du dich nicht bereits auf der Seite „Websiteadministrator“ befindest, klicke in der oberen linken Ecke auf Websiteadministrator.
-
Wähle auf der Randleiste „ Websiteadministrator“ die Option Verwaltungskonsole aus.
-
Klicke auf der oberen Navigationsleiste auf Updates.
-
Verwende nach dem Herunterladen eines neuen Hotpatches das Dropdownmenü Paket installieren.
- Für eine sofortige Installation wählst du Jetzt aus.
- Wähle für die spätere Installation ein späteres Datum aus.
-
Klicke auf Installieren.
Hotpatch mit der Verwaltungsshell installieren
Hinweis: 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.
-
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
ssh -p 122 admin@HOSTNAME
-
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. Kopiere die URL für das Upgrade-Hotpackage (.hpkg-Datei).
-
Lade das Upgradepaket mithilfe von
curl
auf Ihre GitHub Enterprise Server-Instance herunter:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
Führe den
ghe-upgrade
-Befehl mithilfe des Paketdateinamens aus:admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg *** verifying upgrade package signature...
-
Wenn mindestens eine Dienst- oder Systemkomponente einen Neustart erfordert, wirst du vom Upgradeskript für den Hotpatch benachrichtigt. Beispielsweise ist für Updates des Kernels, von MySQL oder von Elasticsearch ein Neustart erforderlich.
Aktualisieren einer Instanz mit mehreren Knoten mit einem Hotpatch
Zum Installieren eines Hotpatches musst du nicht in den Wartungsmodus wechseln oder die Replikation beenden.
- Aktualisieren des primären Knotens mit einem Hotpatch
- Aktualisieren weiterer Knoten mit einem Hotpatch
Aktualisieren des primären Knotens mit einem Hotpatch
Anweisungen zum Aktualisieren des primären Knotens findest du unter Installieren eines Hotpatches mithilfe der Verwaltungsshell.
Aktualisieren weiterer Knoten mit einem Hotpatch
Um eine Instanz zu aktualisieren, die mehrere Knoten umfasst, z. B. eine Hochverfügbarkeits- oder Georeplikationskonfiguration, musst du das folgende Verfahren nacheinander auf jedem Replikatknoten wiederholen.
-
Befolge zum Aktualisieren des Knotens die Anweisungen unter Installieren eines Hotpatches mithilfe der Verwaltungsshell.
-
Stelle per SSH als Benutzer
admin
über Port 122 eine Verbindung mit dem Replikatknoten her:ssh -p 122 admin@REPLICA_HOST
-
Führe Folgendes aus, um das Upgrade zu überprüfen:
ghe-version
-
Wiederhole die obigen Schritte für jeden zusätzlichen Knoten.
Upgrade mit einem Upgrade-Paket
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. Weitere Informationen findest du unter Upgrade-Anforderungen.
- Aktualisieren einer eigenständigen Instanz mit einem Upgradepaket
- Aktualisieren einer Instanz mit mehreren Knoten mit einem Upgradepaket
Aktualisieren einer eigenständigen Instanz mit einem Upgradepaket
Hinweis: 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.
-
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
ssh -p 122 admin@HOSTNAME
-
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).
-
Lade das Upgradepaket mithilfe von
curl
auf Ihre GitHub Enterprise Server-Instance herunter:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
Aktiviere den Wartungsmodus, und warte, bis alle aktiven Prozesse auf der GitHub Enterprise Server-Instanz abgeschlossen sind. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
Hinweis: 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.
-
Führe den
ghe-upgrade
-Befehl mithilfe des Paketdateinamens aus:admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature...
-
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]
-
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. Für die Verwendung dieses Hilfsprogramms mit GitHub Enterprise Server 3.8 muss die Instanz die Version 3.8.12 oder eine höhere Version haben. Weitere Informationen zum Hilfsprogramm sind unter „Befehlszeilenprogramme“ zu finden.
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
-
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 findest du unter Wartungsmodus aktivieren und planen.
-
Deaktiviere bei Upgrades einzelner Knoten den Wartungsmodus, damit Benutzer*innen Ihre GitHub Enterprise Server-Instance verwenden können.
Hinweis: 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. Weitere Informationen findest du unter 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
- Aktualisieren weiterer Knoten mit einem Upgradepaket
Aktualisieren des primären Knotens mit einem Upgradepaket
Warnung: 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.
-
Aktiviere auf dem primären Knoten den Wartungsmodus, und warte auf den Abschluss sämtlicher aktiver Prozesse. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
-
Stelle per SSH als Benutzer
admin
über Port 122 eine Verbindung mit dem Replikatknoten her:ssh -p 122 admin@REPLICA_HOST
-
Um die Replikation auf allen Knoten zu beenden, führst du auf jedem Knoten
ghe-repl-stop
aus. -
Befolge zum Aktualisieren des primären Knotens die Anweisungen unter Aktualisieren einer eigenständigen Instanz mithilfe eines Upgradepakets.
Aktualisieren weiterer Knoten mit einem Upgradepaket
Um eine Instanz zu aktualisieren, die mehrere Knoten umfasst, z. B. eine Hochverfügbarkeits- oder Georeplikationskonfiguration, musst du das folgende Verfahren nacheinander auf jedem Replikatknoten wiederholen.
-
Aktualisiere den Knoten gemäß der Anweisungen unter Aktualisieren einer eigenständigen Instanz mithilfe eines Upgradepakets.
-
Stelle per SSH als Benutzer
admin
über Port 122 eine Verbindung mit dem Replikatknoten her:ssh -p 122 admin@REPLICA_HOST
-
Führe Folgendes aus, um das Upgrade zu überprüfen:
ghe-version
-
Führe zum Starten der Replikation auf dem Replikatknoten den Befehl
ghe-repl-start
aus. -
Führe
ghe-repl-status
auf dem Replikatknoten aus, um sicherzustellen, dass die Replikationsdienste ordnungsgemäß ausgeführt werden. Dieser Befehl gibt für alle DiensteOK
zurück, wenn eine erfolgreiche Replikation verarbeitet wird und für das Replikat ein Upgrade durchgeführt wurde. Wenn der BefehlReplication is not running
zurückgibt, wird die Replikation möglicherweise noch gestartet. Warte ungefähr eine Minute, bevor dughe-repl-status
erneut ausführst.Hinweise:
-
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
nichtOK
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. -
-
Wiederhole die obigen Schritte für jeden zusätzlichen Knoten.
-
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.
Wiederherstellung nach einem fehlgeschlagenen Upgrade
Wenn ein Upgrade fehlschlägt oder unterbrochen wird, solltest du deine Instanz in ihren vorherigen Zustand zurücksetzen. Der entsprechende Prozess hängt vom Upgrade-Typ ab.
Rollback einer Patch-Veröffentlichung durchführen
Um einen Patchrelease zurückzusetzen, verwende den ghe-upgrade
-Befehl mit dem --allow-patch-rollback
-Parameter. Vor eine Rollback muss die Replikation vorübergehend angehalten werden, indem auf allen Replikatinstanzen ghe-repl-stop
ausgeführt wird. Wenn du ein Rollback eines Upgrades durchführst, musst du eine Upgradepaketdatei mit der Erweiterung .pkg verwenden. Hotpatchpaketdateien mit der Erweiterung .hpkg werden nicht unterstützt.
ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg
Nach Ausführung des Befehls ist ein Neustart erforderlich. Der Rollback wirkt sich nicht auf die Datenpartition aus, da Migrationen nicht mit Patch-Releases ausgeführt werden.
Nachdem der Rollback abgeschlossen ist, startest du die Replikation neu, indem du auf allen Replikaten ghe-repl-start
ausführst.
Weitere Informationen findest du unter Befehlszeilenprogramme.
Rollback einer Feature-Veröffentlichung durchführen
Um ein Rollback eines Featurereleases durchzuführen, führe eine Wiederherstellung über eine VM-Momentaufnahme aus, um sicherzustellen, dass die Root- und Datenpartitionen einen konsistenten Zustand aufweisen. Weitere Informationen findest du unter Eine Momentaufnahme erstellen.