GitHub Enterprise von 11.10.x zu 2.1.23 migrieren

Migrationen von GitHub Enterprise 11.10.348 und höher werden unterstützt. Migrationen von GitHub Enterprise 11.10.348 und früher werden nicht unterstützt. Zu musst zunächst in mehreren Schritten ein Upgrade auf die Version 11.10.348 durchführen. Weitere Informationen findest du im Upgradeverfahren 11.10.348 Durchführen eines Upgrades auf das neueste Release.

Um ein Upgrade auf die neueste Version von GitHub Enterprise durchzuführen, musst du zunächst ein Upgrade auf GitHub Enterprise Server 2.1 vornehmen. Anschließend kannst du dem normalen Upgradeprozess folgen. Weitere Informationen findest du unter Upgrade von GitHub Enterprise Server.

Vorbereitungen für die Migration

1. Konsultiere den Leitfaden „Bereitstellen und Installieren“, und überprüfe, ob alle Voraussetzungen erfüllt sind, um GitHub Enterprise 2.1.23 in deiner Umgebung bereitzustellen und zu konfigurieren. Weitere Informationen findest du unter Bereitstellen und Installieren.

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

3. Richte die neueste Version von GitHub Enterprise Server Backup Utilities ein. Weitere Informationen findest du unter GitHub Enterprise Server Backup Utilities.

   • Wenn du geplante Backups bereits mit GitHub Enterprise Server Backup Utilities konfiguriert hast, solltest du sicherstellen, dass du die neueste Version verwendest.
   • Wenn du aktuell keine geplanten Backups ausführst, richte GitHub Enterprise Server Backup Utilities ein.

4. Führe den Befehl ghe-backup aus, um eine erste vollständige Sicherungsmomentaufnahme 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 Wartung der Migration erstellst du eine weitere Momentaufnahme. 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. Reduziere vor dem Starten der Migration den TTL-Wert des vorhandenen DNS-Eintrags auf maximal fünf Minuten, und lege fest, dass die Änderung auf andere Instanzen angewendet werden kann. 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. Stelle eine neue GitHub Enterprise 2.1-Instanz bereit. Weitere Informationen findest du im Leitfaden Bereitstellen und Installieren für deine Zielplattform.

2. Navigiere in einem Browser zur IP-Adresse der neuen Replikat-Appliance, und lade deine 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 findest du 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. Führe ein Upgrade auf das neueste Patchrelease von GitHub Enterprise Server durch. Weitere Informationen findest du unter Upgrade von GitHub Enterprise Server.