Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Upgrade von GitHub Enterprise Server

Führen Sie ein GitHub Enterprise Server-Upgrade durch, um die neuesten Features und Sicherheitsupdates zu erhalten.

Upgrade vorbereiten

  1. Bestimmen Sie eine Upgrade-Strategie, und wählen Sie eine Version aus, auf die das Upgrade durchgeführt werden soll. Weitere Informationen finden Sie unter „Upgrade-Anforderungen“.

  2. Erstellen Sie mit den GitHub Enterprise Server Backup-Dienstprogramme ein neues Backup Ihrer primären Instanz. Weitere Informationen finden Sie in der „GitHub Enterprise Server Backup-Dienstprogramme-Datei 'README.md'“.

  3. Wenn Sie mithilfe eines Upgrade-Pakets ein Upgrade durchführen, sollten Sie ein Wartungsfenster für GitHub Enterprise Server-Endbenutzer planen. Bei Verwendung eines Hotpatches muss der Wartungsmodus nicht verwendet werden.

    Hinweis: Das Wartungsfenster hängt vom Typ des Upgrades ab, das Sie ausführen. Für Upgrades mittels Hotpatch ist in der Regel kein Wartungsfenster erforderlich. Manchmal ist ein Neustart erforderlich, den Sie später durchführen können. 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 finden Sie unter „Wartungsmodus aktivieren und planen“.

About minimum requirements for GitHub Enterprise Server 3.0 and later

Before upgrading to GitHub Enterprise Server 3.0 or later, review the hardware resources you've provisioned for your instance. GitHub Enterprise Server 3.0 introduces new features such as GitHub Actions and GitHub Packages, and requires more resources than versions 2.22 and earlier. For more information, see the GitHub Enterprise Server 3.0 release notes.

Increased requirements for GitHub Enterprise Server 3.0 and later are bold in the following table.

BenutzerlizenzenvCPUsArbeitsspeicherAttached-StorageRoot-Storage
Test, Demo oder 10 Benutzer mit eingeschränkten Funktionen4
Up from 2
32 GB
Up from 16 GB
150 GB
Up from 100 GB
200 GB
10–30008
Up from 4
48 GB
Up from 32 GB
300 GB
Up from 250 GB
200 GB
3000–500012
Up from 8
64 GB500 GB200 GB
5000–800016
Up from 12
96 GB750 GB200 GB
8000–10000+20
Up from 16
160 GB
Up from 128 GB
1000 GB200 GB

For more information about hardware requirements for GitHub Actions, see "Getting started with GitHub Actions for GitHub Enterprise Server."

For more information about adjusting resources for an existing instance, see "Increasing storage capacity" and "Increasing CPU or memory resources."

Snapshot erstellen

Ein Snapshot ist ein Checkpoint einer virtuellen Maschine (VM) zu einem bestimmten Zeitpunkt. Es wird dringend empfohlen, ein Snapshot zu erstellen, bevor Sie Ihre virtuelle Maschine upgraden, damit Sie bei einem Fehlschlagen eines Upgrades Ihre VM auf den Snapshot zurücksetzen können. Wenn Sie ein Upgrade auf eine neue Feature-Veröffentlichung durchführen, müssen Sie einen VM-Snapshot erstellen. Wenn Sie ein Upgrade auf eine Patch-Veröffentlichung durchführen, können Sie die vorhandene Daten-Disk anhängen.

Es gibt zwei Snapshot-Typen:

  • VM-Snapshots speichern den gesamten VM-Zustand, einschließlich der Benutzer- und Konfigurationsdaten. Für diese zeitraubende Snapshot-Methode ist viel Speicherplatz erforderlich.

  • Daten-Disk-Snapshots speichern nur die Benutzerdaten.

    Hinweise:

    • Einige Plattformen ermöglichen es Ihnen nicht, einen Snapshot nur von Ihrer Daten-Disk zu erstellen. Bei diesen Plattformen müssen Sie einen Snapshot der gesamten VM erstellen.
    • Wenn von Ihrem Hypervisor keine vollständigen VM-Snapshots unterstützt werden, können Sie in schneller Abfolge einen Snapshot der Root- und Daten-Disk erstellen.
PlattformSnapshot-MethodeURL zur Snapshot-Dokumentation
Amazon AWSDiskhttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureVMhttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VVMhttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute EngineDiskhttps://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServerVMhttps://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

Upgrade mit einem Hotpatch

Sie können ein Upgrade von GitHub Enterprise Server auf die neueste Patch-Version durchführen. Verwenden Sie dazu einen Hotpatch, für den kein Wartungsfenster und in der Regel kein Neustart erforderlich ist. Mittels Hotpatching kannst Du ein Upgrade auf einen neueren Patch-Release durchführen, jedoch keine Feature-Veröffentlichung. So kannst Du beispielsweise ein Upgrade von 2.10.1 auf 2.10.5 durchführen, da sie sich in derselben Featureserie befinden, jedoch nicht von 2.10.9 auf 2.11.0, da sie sich in unterschiedlichen Featureserien befinden. Mit der Managementkonsole können Sie einen Hotpatch sofort installieren oder dessen Installation für einen späteren Zeitpunkt planen. An der Verwaltungsshell können Sie mit dem Dienstprogramm ghe-upgrade einen Hotpatch installieren. Weitere Informationen finden Sie unter „Upgrade-Anforderungen“.

Note:

Installing a hotpatch using the Managementkonsole is not available in clustered environments. Informationen zum Installieren eines Hotpatches in einer Clusterumgebung finden Sie unter „Cluster-Upgrade“.

Upgrade einer einzelnen Appliance mit einem Hotpatch durchführen

Hotpatch mit der Managementkonsole installieren
  1. Aktivieren Sie automatisch Updates. Weitere Informationen finden Sie unter „Automatische Updates aktivieren“.
  2. From an administrative account on GitHub Enterprise Server, click in the upper-right corner of any page. Raumschiffsymbol für den Zugriff auf die Einstellungen des Websiteadministrators
  3. Klicke auf der linken Seitenleiste auf Managementkonsole. Registerkarte „Managementkonsole" in der linken Seitenleiste
  4. Klicken Sie im oberen Bereich der Managementkonsole auf Updates. Menüpunkt „Updates“
  5. Verwenden Sie nach dem Download eines neuen Hotpatches das Dropdownmenü für das Installationspaket:
    • Wählen Sie zur sofortigen Installation Now (Jetzt) aus:
    • Wählen Sie für die spätere Installation ein späteres Datum aus.Dropdownmenü mit Hotpatch-Installationsdatum
  6. Click Install. Schaltfläche zum Installieren des Hotpatches
Hotpatch mit der Verwaltungsshell installieren

Hinweis: Wenn Du die Prüfung auf automatische Updates aktiviert hast, musst Du das Upgrade-Paket nicht herunterladen und kannst die automatisch heruntergeladene Datei verwenden. Weitere Informationen findest Du unter „Prüfung auf automatische Updates aktivieren“.

  1. Stellen Sie eine SSH-Verbindung zu your GitHub Enterprise Server instance her. Weitere Informationen findest Du unter "Auf die administrative Shell (SSH) zugreifen."
    $ ssh -p 122 admin@HOSTNAME
  2. Navigieren Sie zur Seite GitHub Enterprise Server-Veröffentlichungen. Klicke neben dem Release, auf den Du ein Upgrade durchführst, auf Download, und klicke dann auf die Registerkarte Upgrading (Aktualisieren). Kopieren Sie die URL für das Upgrade-Hotpackage (Datei .hpkg).
  3. Laden Sie das Upgrade-Paket mit curl auf your GitHub Enterprise Server instance herunter:
    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Führen Sie den Befehl ghe-upgrade aus, und verwenden Sie dabei den Paketdateinamen:
    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
    *** verifying upgrade package signature...
  5. Wenn für den Kernel, MySQL, ElasticSearch oder andere Programme ein Neustart erforderlich ist, werden Sie vom Hotpatch-Upgrade-Skript dahingehend benachrichtigt.

Upgrade einer über Replikatinstanzen verfügenden Appliance mit einem Hotpatch durchführen

Hinweis: Zur Installation eines Hotpatches müssen Sie nicht in den Wartungsmodus wechseln oder die Replikation beenden.

Für die Hochverfügbarkeit und Geo-Replikation konfigurierte Appliances verwenden zusätzlich zu den primären Instanzen Replikatinstanzen. Zum Upgraden dieser Appliances müssen Sie die primäre Instanz und alle Replikatinstanzen nacheinander upgraden.

Upgrade der primären Instanz durchführen
  1. Führen Sie ein Upgrade der primären Instanz durch. Befolgen Sie dazu die unter „Hotpatch mit der Verwaltungsshell installieren“ beschriebenen Anweisungen.
Upgrade einer Replikatinstanz durchführen

Hinweis: Wenn Sie als Teil der Geo-Replikation mehrere Replikatinstanzen ausführen, sollten Sie diese Prozedur für jede Replikatinstanz nacheinander wiederholen.

  1. Upgrade the replica instance by following the instructions in "Installing a hotpatch using the administrative shell." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. Verbinden Dich mit der Replika-Instanz über SSH als "admin" Benutzer auf Port 122:

    $ ssh -p 122 admin@replica-host
  3. Führe Folgendes aus, um das Upgrade zu überprüfen:

    $ ghe-version

Upgrade mit einem Upgrade-Paket

Obwohl Sie einen Hotpatch verwenden können, um ein Upgrade auf die neueste Patch-Veröffentlichung in einer Featureserie durchzuführen, müssen Sie ein Upgrade-Paket verwenden, um ein Upgrade auf eine neuere Feature-Veröffentlichung durchzuführen. Wenn Sie beispielsweise ein Upgrade von 2.11.10 auf 2.12.4 durchführen möchten, müssen Sie ein Upgrade-Paket verwenden, da es sich um unterschiedliche Featureserien handelt. Weitere Informationen finden Sie unter „Upgrade-Anforderungen“.

Upgrade einer einzelnen Appliance mit einem Upgrade-Paket durchführen

Hinweis: Wenn Du die Prüfung auf automatische Updates aktiviert hast, musst Du das Upgrade-Paket nicht herunterladen und kannst die automatisch heruntergeladene Datei verwenden. Weitere Informationen findest Du unter „Prüfung auf automatische Updates aktivieren“.

  1. Stellen Sie eine SSH-Verbindung zu your GitHub Enterprise Server instance her. Weitere Informationen findest Du unter "Auf die administrative Shell (SSH) zugreifen."

    $ ssh -p 122 admin@HOSTNAME
  2. Navigieren Sie zur Seite GitHub Enterprise Server-Veröffentlichungen. Klicke neben dem Release, auf den Du ein Upgrade durchführst, auf Download, und klicke dann auf die Registerkarte Upgrading (Aktualisieren). Wählen Sie die entsprechende Plattform aus, und kopieren Sie die URL für das Upgrade-Paket (Datei .pkg).

  3. Laden Sie das Upgrade-Paket mit curl auf your GitHub Enterprise Server instance herunter:

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. Aktivieren Sie den Wartungsmodus, und warten Sie, bis alle aktiven Prozesse auf der GitHub Enterprise Server-Instanz abgeschlossen sind. Weitere Informationen finden Sie unter „Wartungsmodus aktivieren und planen“.

    Hinweis: Wenn Sie in einer Hochverfügbarkeitskonfiguration ein Upgrade der primären Appliance durchführen, sollte sich die Appliance bereits im Wartungsmodus befinden, sofern Sie die unter „Upgrade der primären Instanz durchführen“ beschriebenen Anweisungen befolgen.

  5. Führen Sie den Befehl ghe-upgrade aus, und verwenden Sie dabei den Paketdateinamen:

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
  6. Bestätigen Sie, dass Sie das Upgrade fortsetzen möchten, und führen Sie 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]
  7. Deaktivieren Sie bei einzelnen Appliance-Upgrades den Wartungsmodus, damit Benutzer your GitHub Enterprise Server instance verwenden können.

    Hinweis: Wenn Sie in einer Hochverfügbarkeitskonfiguration ein Upgrade der Appliances durchführen, sollten Sie im Wartungsmodus bleiben, bis ein Upgrade sämtlicher Replikate durchgeführt wurde und die Replikation aktuell ist. Weitere Informationen finden Sie unter „Upgrade einer Replikatinstanz durchführen“.

Upgrade einer über Replikatinstanzen verfügenden Appliance mit einem Upgrade-Paket durchführen

Für die Hochverfügbarkeit und Geo-Replikation konfigurierte Appliances verwenden zusätzlich zu den primären Instanzen Replikatinstanzen. Zum Upgraden dieser Appliances müssen Sie die primäre Instanz und alle Replikatinstanzen nacheinander upgraden.

Upgrade der primären Instanz durchführen

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.

  1. Aktivieren Sie auf der primären Instanz den Wartungsmodus, und warten Sie auf den Abschluss sämtlicher aktiver Prozesse. Weitere Informationen finden Sie unter „Wartungsmodus aktivieren“.
  2. Verbinden Dich mit der Replika-Instanz über SSH als "admin" Benutzer auf Port 122:
    $ ssh -p 122 admin@replica-host
  3. Führen Sie auf der Replikatinstanz oder auf allen Replikatinstanzen, falls Sie als Teil der Geo-Replikation mehrere Replikatinstanzen ausführen, den Befehl ghe-repl-stop zum Anhalten der Replikation aus.
  4. Führen Sie ein Upgrade der primären Instanz durch. Befolgen Sie dazu die unter „Upgrade einer einzelnen Appliance mit einem Upgrade-Paket durchführen“ beschriebenen Anweisungen.
Upgrade einer Replikatinstanz durchführen

Hinweis: Wenn Sie als Teil der Geo-Replikation mehrere Replikatinstanzen ausführen, sollten Sie diese Prozedur für jede Replikatinstanz nacheinander wiederholen.

  1. Upgrade the replica instance by following the instructions in "Upgrading a single appliance with an upgrade package." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. Verbinden Dich mit der Replika-Instanz über SSH als "admin" Benutzer auf Port 122:

    $ ssh -p 122 admin@replica-host
  3. Führe Folgendes aus, um das Upgrade zu überprüfen:

    $ ghe-version
  4. Führe auf der Replikatinstanz zum Starten der Replikation den Befehl ghe-repl-start aus.

  5. Führe auf der Replikatinstanz den Befehl ghe-repl-status aus, um sicherzustellen, dass die Replikationsdienste ordnungsgemäß ausgeführt werden. Dieser Befehl gibt für alle Dienste OK zurück, wenn eine erfolgreiche Replikation verarbeitet wird und für das Replikat ein Upgrade durchgeführt wurde. Wenn der Befehl Replication is not running zurückgibt, wird die Replikation möglicherweise noch gestartet. Warten Sie etwa eine Minute, bevor Sie ghe-repl-status erneut ausführen.

    Hinweis: Während die erneute Synchronisierung verarbeitet wird, gibt der Befehl „ghe-repl-status“ ggf. erwartete Meldungen dahingehend zurück, dass die Replikation im Rückstand ist. Zum Beispiel: CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists

    Falls der Befehl ghe-repl-status nicht den Wert OK zurückgibt, sollten Sie die folgenden Schritte befolgen, um die Replikation manuell neu zu starten.

    1. Führen Sie auf der Replikatinstanz den Befehl ghe-repl-setup <primary-instance-ip> erneut aus.
    2. Führe auf der Replikatinstanz zum Starten der Replikation den Befehl ghe-repl-start aus.
    3. Führe auf der Replikatinstanz den Befehl ghe-repl-status aus, um sicherzustellen, dass die Replikationsdienste ordnungsgemäß ausgeführt werden. Dieser Befehl gibt für alle Dienste OK zurück, wenn eine erfolgreiche Replikation verarbeitet wird und für das Replikat ein Upgrade durchgeführt wurde.
  6. Deaktivieren Sie nach dem Upgrade-Abschluss des letzten Replikats und nach dem Abschluss der erneuten Synchronisierung den Wartungsmodus, damit Benutzer your GitHub Enterprise Server instance verwenden können.

Wiederherstellung nach einem fehlgeschlagenen Upgrade

Wenn ein Upgrade fehlschlägt oder unterbrochen wird, sollten Sie Ihre Instanz in ihren vorherigen Zustand zurücksetzen. Der entsprechende Prozess hängt vom Upgrade-Typ ab.

Rollback einer Patch-Veröffentlichung durchführen

Führen Sie den Befehl ghe-upgrade mit der Option --allow-patch-rollback aus, um ein Rollback einer Patch-Veröffentlichung durchzuführen. Wenn Du ein Rollback eines Upgrades durchführst, musst Du eine Upgrade-Paketdatei mit der Dateinamen-Erweiterung .pkg verwenden. Hotpatch-Paketdateien mit der Dateinamenerweiterung .hpkg werden nicht unterstützt.

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

A reboot is required after running the command. Der Rollback wirkt sich nicht auf die Datenpartition aus, da Migrationen nicht mit Patch-Releases ausgeführt werden.

Weitere Informationen finden Sie unter „Befehlszeilenprogramme“.

Rollback einer Feature-Veröffentlichung durchführen

Um ein Rollback von einer Feature-Veröffentlichung durchzuführen, stellen Sie diese über einen VM-Snapshot wieder her, um sicherzustellen, dass die Root- und Datenpartitionen einen konsistenten Zustand aufweisen. Weitere Informationen finden Sie unter „Snapshot erstellen“.