Migrieren von GitHub Enterprise 11.10.x zu 2.1.23

Migrationen von GitHub Enterprise 11.10.348 und höher werden unterstützt. Die Migration von GitHub Enterprise 11.10.348 und früher wird nicht unterstützt. Du musst zuerst in mehreren Schritten auf 11.10.348 upgraden. Weitere Informationen findest du im Upgradeverfahren 11.10.348 unter Durchführen eines Upgrades auf das neueste Release.

Um auf die neueste Version von GitHub Enterprisezu aktualisieren, müssen Sie zuerst zu GitHub Enterprise Server 2.1 migrieren, dann können Sie dem normalen Upgradeprozess folgen. Weitere Informationen finden Sie unter Übersicht über den Upgradeprozess.

Vorbereitungen für die Migration

1. Überprüfen Sie das Bereitstellungs- und Installationshandbuch, und überprüfen Sie, ob alle erforderlichen Voraussetzungen für die Bereitstellung und Konfiguration GitHub Enterprise von 2.1.23 in Ihrer Umgebung erfüllt sind. Weitere Informationen findest du unter Bereitstellen und Installieren.

2. Überprüfe, dass die aktuelle Instanz eine unterstützte Upgradeversion ausführt.

3. Richten Sie die neueste Version der GitHub Enterprise Server Backup Utilities. Weitere Informationen findest du unter GitHub Enterprise Server Backup Utilities.

   • Wenn Sie bereits geplante Sicherungen mit GitHub Enterprise Server Backup Utilitieskonfiguriert haben, stellen Sie sicher, dass Sie auf die neueste Version aktualisiert haben.
   • Wenn Sie zurzeit keine geplanten Sicherungen ausführen, richten GitHub Enterprise Server Backup UtilitiesSie ein.

4. Führen Sie den Befehl ghe-backup aus, um einen ersten vollständigen Sicherungsschnappschuss der aktuellen Instanz zu erstellen. Falls du bereits geplante Backups für deine aktuelle Instanz konfiguriert hast, musst du keine Momentaufnahme deiner Instanz erstellen.

   Tipp

   Während der Erstellung der Momentaufnahme kann die Instanz weiterhin online und aktiv sein. Während der Wartungsphase der Migration erstellst du einen weiteren Schnappschuss. Da Backups inkrementell sind, reduziert der anfängliche Snapshot die im finalen Snapshot übertragenen Daten, was wiederum das Wartungsfenster kürzt.

5. Bestimme die Methode zum Umleiten des Benutzernetzwerk-Datenverkehrs auf die neue Instanz. Nach der Migration wird der gesamte HTTP- und Git-Netzwerk-Traffic an die neue Instanz geleitet.

   • DNS: Du solltest diese Methode für alle Umgebungen verwenden, da sie unkompliziert und selbst dann ordnungsgemäß funktioniert, wenn eine Migration zwischen Rechenzentren vorgenommen wird. Reduzieren Sie vor dem Start der Migration den TTL-Wert des vorhandenen DNS-Eintrags auf fünf Minuten oder weniger und lassen Sie die Änderung sich ausbreiten. Aktualisiere nach Abschluss der Migration den DNS-Eintrag bzw. die DNS-Einträge so, dass er bzw. sie auf die IP-Adresse der neuen Instanz verweisen.
   • IP-Adressenzuweisung: Diese Methode steht nur für die VMware-zu-VMware-Migration zur Verfügung und wird nicht empfohlen, es sei denn, die DNS-Methode ist nicht verfügbar. Vor dem Starten der Migration musst du die alte Instanz herunterfahren und ihre IP-Adresse der neuen Instanz zuweisen.

6. Plane ein Wartungsfenster. Das Wartungsfenster sollte lang genug sein, um Daten vom Backup-Host auf die neue Instanz zu übertragen. Es variiert entsprechend der Größe des Backup-Snapshots und der verfügbaren Netzwerkbandbreite. In diesem Zeitraum ist deine aktuelle Instanz nicht verfügbar und im Wartungsmodus, während du zur neuen Instanz migrierst.

Durchführen der Migration

1. Stellen Sie eine neue GitHub Enterprise 2.1-Instanz bereit. Weitere Informationen findest du im Leitfaden Bereitstellen und Installieren für deine Zielplattform.

2. Navigieren Sie in einem Browser zur IP-Adresse der neuen Replikat-Appliance, und laden Sie Ihre GitHub Enterprise Lizenz hoch.

3. Lege ein Administratorkennwort fest.

4. Klicke auf Migrieren.

5. Füge im Textfeld „Neuen SSH-Schlüssel hinzufügen“ deinen SSH-Schlüssel für den Zugriff auf den Sicherungshost ein.

6. Klicke auf Schlüssel hinzufügen und anschließend auf Weiter.

7. Kopiere den Befehl ghe-restore, den du auf dem Sicherungshost ausführst, um Daten zur neuen Instanz zu migrieren.

8. Aktiviere den Wartungsmodus auf der alten Instanz, und warte auf den Abschluss sämtlicher aktiver Prozesse. Weitere Informationen finden Sie unter Wartungsmodus aktivieren und planen.

   Hinweis

   Ab diesem Zeitpunkt steht die Instanz nicht mehr zur normalen Verwendung zur Verfügung.

9. Führe auf dem Sicherungshost den Befehl ghe-backup aus, um eine finale Sicherungsmomentaufnahme zu erstellen. Dadurch wird sichergestellt, dass alle Daten von der alten Instanz erfasst werden.

10. Führe auf dem Sicherungshost den Befehl ghe-restore aus, den du auf den Bildschirm mit dem Wiederherstellungsstatus der neuen Instanz kopiert hast, um die neueste Momentaufnahme wiederherzustellen.

    $ ghe-restore 169.254.1.1
    The authenticity of host '169.254.1.1:122' can't be established.
    RSA key fingerprint is fe:96:9e:ac:d0:22:7c:cf:22:68:f2:c3:c9:81:53:d1.
    Are you sure you want to continue connecting (yes/no)? yes
    Connect 169.254.1.1:122 OK (v2.0.0)
    Starting restore of 169.254.1.1:122 from snapshot 20141014T141425
    Restoring Git repositories ...
    Restoring GitHub Pages ...
    Restoring asset attachments ...
    Restoring hook deliveries ...
    Restoring MySQL database ...
    Restoring Redis database ...
    Restoring SSH authorized keys ...
    Restoring Elasticsearch indices ...
    Restoring SSH host keys ...
    Completed restore of 169.254.1.1:122 from snapshot 20141014T141425
    Visit https://169.254.1.1/setup/settings to review appliance configuration.
    

11. Kehre zum Bildschirm mit dem Wiederherstellungsstatus der neuen Instanz zurück, um zu sehen, dass die Wiederherstellung abgeschlossen ist.

12. Klicke auf Weiter zu Einstellungen, um die von der vorherigen Instanz importierten Konfigurationsinformationen und -einstellungen zu überprüfen und anzupassen.

13. Klicke auf Save settings (Einstellungen speichern).

    Hinweis

    Du kannst die neue Instanz verwenden, nachdem du die Konfigurationseinstellungen angewendet und den Server neu gestartet hast.

14. Leite mittels DNS oder IP-Adressenzuweisung den Benutzernetzwerk-Datenverkehr von der alten Instanz zur neuen Instanz.

15. Aktualisieren Sie auf die neueste Patchversion von GitHub Enterprise Server. Weitere Informationen finden Sie unter Übersicht über den Upgradeprozess.