Skip to main content

Upgrade-Anforderungen

Überprüfen Sie vor dem Upgrade GitHub Enterprise Serverdiese Empfehlungen und Anforderungen, um Ihre Upgradestrategie zu planen.

In diesem Artikel

Hinweis

  • Upgradepakete für unterstützte Versionen sind unter enterprise.github.com verfügbar. Verifiziere die Verfügbarkeit der Upgrade-Pakete, die du zum Abschließen des Upgrades benötigst. Wenn ein Paket nicht verfügbar ist, besuchen Sie GitHub Enterprise-Support und kontaktieren Sie uns für Unterstützung.
  • Wenn Sie GitHub Enterprise Server Clustering verwenden, siehe Upgrade eines Clusters im GitHub Enterprise Server Clustering-Handbuch für spezifische Anweisungen zum Clustering.
  • Die Versionshinweise für GitHub Enterprise Server enthalten eine umfassende Liste der neuen Funktionen für jede Version von GitHub Enterprise Server. Weitere Informationen finden Sie auf der Release-Seite.

Empfehlungen

  • Du solltest möglichst wenig Upgrades in deinen Upgrade-Prozess einbeziehen. Statt z. B. von GitHub Enterprise3.19 auf 3.20 auf 3.21 zu aktualisieren, könnten Sie von GitHub Enterprise3.19 auf 3.21 aktualisieren. Verwenden Sie die Upgrade-Assistenten Option, um den Upgradepfad aus Ihrer aktuellen Version zu finden.
  • Wenn Sie mehrere Versionen zurückliegen, führen Sie Ihre GitHub Enterprise Server-Instance bei jedem Schritt Ihres Upgrade-Prozesses ein Upgrade so weit wie möglich nach vorne durch. Wenn du nach Möglichkeit die neueste Version für jedes Upgrade verwendest, kannst du von Leistungsverbesserungen und Bug-Korrekturen profitieren. Sie können z. B. ein Upgrade von GitHub Enterprise 2.7 auf 2.8 auf 2.10 durchführen, aber ein Upgrade von GitHub Enterprise 2.7 auf 2.9 auf 2.10 verwendet eine höhere Version im zweiten Schritt.
  • Verwende beim Upgraden die neueste Patch-Veröffentlichung. 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.
  • Verwende eine Testinstanz zum Testen der Upgrade-Schritte. Weitere Informationen finden Sie unter Testinstanz einrichten.
  • Stelle beim Ausführen mehrerer Upgrades sicher, dass Datenmigrationen und Upgradetasks, die im Hintergrund ausgeführt werden, vollständig abgeschlossen sind, bevor du mit dem nächsten Featureupgrade fortfährst. Der Status dieser Prozesse kann mit den Befehlszeilen-Hilfsprogrammen ghe-migrations und ghe-check-background-upgrade-jobs geprüft werden. Weitere Informationen finden Sie unter Befehlszeilenwerkzeuge.
  • Erstelle vor dem Upgrade deines virtuellen Computers eine Momentaufnahme. Weitere Informationen finden Sie unter Snapshot erstellen. Nachdem die Momentaufnahme erstellt wurde, solltest du automatische Momentaufnahmen deaktivieren, um mögliche Auswirkungen auf die Leistung während des Upgrades zu vermeiden.
  • Stelle sicher, dass du über eine aktuelle, erfolgreiche Sicherung deiner Instanz verfügst. Weitere Informationen finden Sie in der GitHub Enterprise Server Backup Utilities datei README.md.

Anforderungen

  • Du musst eine Kapazitätsüberprüfung durchführen. Weitere Informationen finden Sie unter Überprüfen der Systemkapazität vor dem Upgrade.
  • Du musst ein Upgrade aus einem Featurerelease durchführen, das mindestens zwei Releases zurückliegt. Um beispielsweise ein Upgrade auf GitHub Enterprise3.21 durchzuführen, müssen Sie auf GitHub Enterprise3.20 oder 3.19 sein.
  • Planen Sie beim Upgrade mithilfe eines Upgradepakets ein Wartungsfenster für GitHub Enterprise Server Endbenutzer.
  • Sie können ein Upgrade GitHub Enterprise Server auf die neueste Patchversion mit einem Hotpatch durchführen.

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 nicht immer einen 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 einen Konfigurationslauf, der bei einigen oder allen Diensten auf Ihre GitHub Enterprise Server-Instance kurzzeitig zu Fehlern oder Nichtreagieren 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.

  • Ein Hotpatch kann Ausfallzeiten nach sich ziehen, falls für die betroffenen Dienste (z. B. der Kernel, MySQL oder ElasticSearch) ein VM- oder Dienstneustart erforderlich ist. Du wirst benachrichtigt, falls ein Neustart erforderlich ist. Du kannst den Neustart zu einem späteren Zeitpunkt abschließen.
  • Beim Upgrade mittels Hotpatching muss zusätzlicher Root-Storage verfügbar sein, da bis zum Abschluss des Upgrades mehrere Versionen bestimmter Dienste installiert werden. Sie werden bei Vorflugkontrollen benachrichtigt, falls nicht genügend Root-Datenträgerspeicher verfügbar ist.
  • Beim Upgrade mittels Hotpatching darf deine Instanz keine zu große Auslastung aufweisen, da sich dies gegebenenfalls auf den Hotpatchingprozess auswirkt.
  • Beim Upgrade auf GitHub Enterprise Server 2.17 werden Ihre Überwachungsprotokolle von Elasticsearch zu MySQL migriert. Diese Migration erhöht die Zeit und den Speicherplatz, die zum Wiederherstellen eines Snapshots benötigt werden. Überprüfe vor der Migration die Anzahl an Bytes in deinen ElasticSearch-Auditprotokollindizes. Führe dazu den folgenden Befehl aus:
curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

Anhand der Zahl kannst du schätzen, wie viel Speicherplatz die MySQL-Auditprotokolle benötigen werden. Darüber hinaus überwacht das Skript den freien Speicherplatz, während der Import ausgeführt wird. Die Überwachung dieser Zahl ist besonders nützlich, wenn der freie Speicherplatz dem für die Migration erforderlichen Speicherplatz nahekommt.

Bei einem Upgrade bewerten Vorab-Flight-Prüfungen, ob die Mindestanforderungen für Systemhardwareressourcen wie Arbeitsspeicher, CPU-Kerne und Benutzer- und Stammdatenträgerspeicher für Ihre Instanz verfügbar sind. Wenn Vorab-Flight-Prüfungen feststellen, dass nicht genügend Ressourcen vorhanden sind oder anderweitig fehlschlagen, werden Sie benachrichtigt, und das Upgrade wird abgebrochen.

Nächste Schritte

Nachdem Sie diese Empfehlungen und Anforderungen überprüft haben, können Sie ein Upgrade durchführen GitHub Enterprise Server. Weitere Informationen finden Sie unter Übersicht über den Upgradeprozess.