Informationen über Migrationen zwischen Unternehmen mit Datenresidenz
Migrationen zwischen zwei datenansässigen Unternehmen verwenden den standardmäßigen GEI-Archivmigrationsfluss:
- GEI stellt eine Verbindung mit der Quelldomäne GHE.com bereit.
- GEI generiert ein Archiv, das die Repositorydaten enthält.
- GEI lädt das Archiv in den unterstützten Migrationsspeicher hoch.
- GEI startet die Repositorymigration auf der Zieldomäne GHE.com .
- Das Ziel Importer lädt das Archiv herunter und verarbeitet es.
Bei dieser Migration:
- Die Quelle ist eine GHE.com Subdomain, z. B.
https://SOURCE_SUBDOMAIN.ghe.com. - Das Ziel ist eine andere GHE.com Subdomain, z. B.
https://DESTINATION_SUBDOMAIN.ghe.com. - Die Quell- und Zielorganisationen können unterschiedliche Namen haben.
- Das migrierte Repository kann einen anderen Namen in der Zielorganisation haben.
Die Quell- und Ziel-API-Endpunkte müssen unabhängig voneinander angegeben werden. Verwenden Sie die Ziel-API-URL nicht für Quellvorgänge.
Wichtig
GitHub Enterprise-Cloud mit Datenresidenz API-URLs verwenden das Format https://api.SUBDOMAIN.ghe.com. Dies unterscheidet sich von einer GitHub Enterprise Server API-URL, die normalerweise das Format https://HOSTNAME/api/v3verwendet.
Voraussetzungen
Bevor Sie beginnen:
- Vergewissern Sie sich, dass die Quelle und das Ziel unterschiedliche GHE.com Unterdomänen sind.
- Stellen Sie sowohl in der Quell- als auch in der Zielorganisation sicher, dass Sie Organisationsinhaber sind oder Ihnen die Rolle „Migrator“ zugewiesen wurde.
- Erstellen Sie eine personal access token (classic) für die Quellorganisation.
- Erstellen Sie eine personal access token (classic) für die Zielorganisation. Informationen zu erforderlichen Bereichen finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
- Führen Sie eine Testmigration aus, bevor Sie die Produktionsmigration ausführen.
Es wird empfohlen, die Arbeit am Quell-Repository während der Produktionsmigration vorübergehend zu beenden. GitHub Enterprise Importer führt keine Deltamigrationen durch, sodass Änderungen, die nach dem Start der Migration vorgenommen wurden, nicht automatisch einbezogen werden.
Informationen zu den migrierten Daten und bekannten Einschränkungen finden Sie unter Informationen zu Migrationen zwischen den GitHub-Produkten mit GitHub Enterprise Importer.
Installieren Sie GitHub CLI und GEI
Installieren Sie das GitHub CLI, und installieren Sie dann die GEI-Erweiterung:
gh extension install github/gh-gei
gh extension install github/gh-gei
Aktualisieren Sie die Erweiterung vor dem Starten einer Migration:
gh extension upgrade github/gh-gei
gh extension upgrade github/gh-gei
So zeigen Sie die verfügbaren Optionen an:
gh gei migrate-repo --help
gh gei migrate-repo --help
Festlegen von Umgebungsvariablen
Legen Sie die personal access tokens für beide Unternehmen fest:
export GH_SOURCE_PAT="SOURCE_PERSONAL_ACCESS_TOKEN" export GH_PAT="DESTINATION_PERSONAL_ACCESS_TOKEN"
export GH_SOURCE_PAT="SOURCE_PERSONAL_ACCESS_TOKEN"
export GH_PAT="DESTINATION_PERSONAL_ACCESS_TOKEN"
Legen Sie die API-URL für jede GHE.com Unterdomäne fest:
export SOURCE_API_URL="https://api.SOURCE_SUBDOMAIN.ghe.com" export TARGET_API_URL="https://api.DESTINATION_SUBDOMAIN.ghe.com"
export SOURCE_API_URL="https://api.SOURCE_SUBDOMAIN.ghe.com"
export TARGET_API_URL="https://api.DESTINATION_SUBDOMAIN.ghe.com"
Ersetzen Sie SOURCE_SUBDOMAIN und DESTINATION_SUBDOMAIN durch die Unterdomänen Ihres Quell- und Zielunternehmens.
Beispiel:
export SOURCE_API_URL="https://api.source-example.ghe.com" export TARGET_API_URL="https://api.destination-example.ghe.com"
export SOURCE_API_URL="https://api.source-example.ghe.com"
export TARGET_API_URL="https://api.destination-example.ghe.com"
Das GH_SOURCE_PAT Token wird für quellseitige Vorgänge verwendet, einschließlich der Archivgenerierung. Das GH_PAT Token wird für Vorgänge auf der Zielseite verwendet.
Blob-Archivspeicher konfigurieren
GitHub Enterprise Importer exportiert jedes Projekt in ein Archiv und lädt dann das Archiv in blob-Speicher hoch, aus dem GitHub gelesen werden kann. Sie wählen das Speicher-Back-End aus, wenn Sie eine Migration ausführen:
| Speicheroption | So wählen Sie es aus | Hinweise |
|---|
GitHub-owned blob storage (empfohlen) | --use-github-storage | Es ist kein Setup erforderlich.
GitHub löscht das Archiv automatisch nach einer erfolgreichen Migration oder sieben Tage nach einer fehlgeschlagenen Migration.
AWS S3 |
--aws-bucket-name (mit den AWS_REGIONVariablen , AWS_ACCESS_KEY_IDund AWS_SECRET_ACCESS_KEY Umgebungsvariablen und optional AWS_SESSION_TOKEN) | Sie besitzen den Bucket und seinen Lebenszyklus.
GitHub löscht keine Archive aus Ihrem Speicher.
Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten) |
AZURE_STORAGE_CONNECTION_STRING Umgebungsvariable (für einen einzelnen migrate-repo Befehl können Sie stattdessen verwenden --azure-storage-connection-string) | Es werden nur Verbindungszeichenfolgen mit Zugriffsschlüssel für Speicherkonten unterstützt (keine SAS).
GitHub löscht keine Archive aus Ihrem Speicher.
Migrieren eines einzelnen Repositorys
Verwenden Sie den gh gei migrate-repo Folgenden Befehl, um ein einzelnes Repository zu migrieren:
gh gei migrate-repo \ --github-source-org SOURCE_ORGANIZATION \ --source-repo SOURCE_REPOSITORY \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org DESTINATION_ORGANIZATION \ --target-repo DESTINATION_REPOSITORY \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei migrate-repo \
--github-source-org SOURCE_ORGANIZATION \
--source-repo SOURCE_REPOSITORY \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org DESTINATION_ORGANIZATION \
--target-repo DESTINATION_REPOSITORY \
--target-api-url "$TARGET_API_URL" \
--verbose
Ersetzen Sie die Platzhalter durch die folgenden Werte:
| Platzhalter | Description |
|---|---|
SOURCE_ORGANIZATION | Die Organisation, die das Repository im Quellunternehmen besitzt. |
SOURCE_REPOSITORY | Der Name des Repositorys in der Quellorganisation. |
DESTINATION_ORGANIZATION | Die Organisation, die das migrierte Repository im Zielunternehmen besitzt. |
DESTINATION_REPOSITORY | Der Name des neuen Repositorys in der Zielorganisation. |
Beispiel:
gh gei migrate-repo \ --github-source-org source-org \ --source-repo example-repository \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org destination-org \ --target-repo example-repository \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei migrate-repo \
--github-source-org source-org \
--source-repo example-repository \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org destination-org \
--target-repo example-repository \
--target-api-url "$TARGET_API_URL" \
--verbose
Wenn Sie weglassen --target-repo, verwendet GEI den Namen des Quell-Repositorys.
Optionale Argumente
Sie können dem Migrationsbefehl die folgenden Optionen hinzufügen:
| Argument | Description |
|---|---|
--target-repo-visibility TARGET-VISIBILITY | Legt die Sichtbarkeit des neuen Repositorys fest. Unterstützte Werte sind private und internal. |
--skip-releases | Migriert das Repository ohne Releases. |
--queue-only | Stellt die Migration in die Warteschlange, ohne den Abschluss abzuwarten. |
--verbose | Zeigt zusätzliche Migrationsausgabe an. |
Beispiel:
gh gei migrate-repo \ --github-source-org source-org \ --source-repo example-repository \ --github-source-api-url "$SOURCE_API_URL" \ --github-target-org destination-org \ --target-repo example-repository \ --target-api-url "$TARGET_API_URL" \ --target-repo-visibility internal \ --verbose
gh gei migrate-repo \
--github-source-org source-org \
--source-repo example-repository \
--github-source-api-url "$SOURCE_API_URL" \
--github-target-org destination-org \
--target-repo example-repository \
--target-api-url "$TARGET_API_URL" \
--target-repo-visibility internal \
--verbose
Migrieren mehrerer Repositorys
Verwenden Sie gh gei generate-scriptfür mehrere Repositorys .
gh gei generate-script \ --github-source-org SOURCE_ORGANIZATION \ --github-target-org DESTINATION_ORGANIZATION \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL" \ --output migration-script.ps1
gh gei generate-script \
--github-source-org SOURCE_ORGANIZATION \
--github-target-org DESTINATION_ORGANIZATION \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL" \
--output migration-script.ps1
Überprüfen Sie das generierte Skript, bevor Sie es ausführen. Sie haben folgende Möglichkeiten:
- Entfernen Sie Repositorys, die nicht migriert werden sollen.
- Ändern sie die Namen des Ziel-Repositorys.
- Ändern der Sichtbarkeit des Ziel-Repositorys.
- Hinzufügen von Optionen wie
--skip-releases. - Fügen Sie
--download-migration-logshinzu, um Protokolle für jede Migration herunterzuladen.
Führen Sie das generierte Skript mit PowerShell aus:
pwsh ./migration-script.ps1
pwsh ./migration-script.ps1
Überprüfen des Status einer Migration
Wenn Sie die Migration mit --queue-only gestartet haben, verwenden Sie die von GEI ausgegebene Migrations-ID, um ihren Fortschritt zu überwachen:
gh gei wait-for-migration \ --migration-id MIGRATION_ID \ --target-api-url "$TARGET_API_URL" \ --verbose
gh gei wait-for-migration \
--migration-id MIGRATION_ID \
--target-api-url "$TARGET_API_URL" \
--verbose
Ersetzen Sie MIGRATION_ID durch die von gh gei migrate-repo zurückgegebene ID.
Hinweis
Schließen Sie bei der Überprüfung beide API-URL-Argumente ein. Die QUELL-API-URL ist für GEI-Befehle erforderlich, die quellseitige Migrationsinformationen und Protokolle abrufen.
Herunterladen von Migrationsprotokollen
So laden Sie die Migrationsprotokolle herunter:
gh gei download-logs \ --migration-id MIGRATION_ID \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL"
gh gei download-logs \
--migration-id MIGRATION_ID \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
Überprüfen Sie die Protokolle auf Warnungen und Fehler, auch wenn der Migrationserfolg gemeldet wird.
Abbrechen einer Migration
So brechen Sie eine in der Warteschlange befindliche oder laufende Migration ab:
gh gei abort-migration \ --migration-id MIGRATION_ID \ --github-source-api-url "$SOURCE_API_URL" \ --target-api-url "$TARGET_API_URL"
gh gei abort-migration \
--migration-id MIGRATION_ID \
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
Problembehandlung
Der Quellmandant kann nicht erreicht werden.
Verifizieren Sie Folgendes:
--github-source-api-urlwird auf die Quell-Subdomain gesetzt.- Die URL verwendet das Format
https://api.SUBDOMAIN.ghe.com. - Das Quelltoken wird in
GH_SOURCE_PATgespeichert. - Das Token hat Zugriff auf die Quellorganisation und das Repository.
Der Zielmandant kann nicht erreicht werden.
Verifizieren Sie Folgendes:
--target-api-urlwird auf die Zielsubdomäne festgelegt.- Die URL verwendet das Format
https://api.SUBDOMAIN.ghe.com. - Das Zieltoken wird gespeichert in
GH_PAT. - Sie verfügen über die Berechtigung zum Erstellen von Repositorys in der Zielorganisation.
Fehler bei der Migration beim Generieren oder Hochladen des Archivs
Überprüfen Sie die Migrationsausgabe und Protokolle, und vergewissern Sie sich dann, dass:
- Der Speicher des Migrationsarchivs ist ordnungsgemäß konfiguriert.
- Auf den Speicheranbieter kann über den Migrationsdienst zugegriffen werden.
- Das Quell-Repository wird während der Migration nicht geändert.
- Die QUELL- und Ziel-API-URLs wurden nicht ausgetauscht.
Protokolle können nicht heruntergeladen werden.
Bei Verwendung von download-logs, wait-for-migration oder abort-migration geben Sie dieselben Quell- und Ziel-API-URLs an, die zum Starten der Migration verwendet wurden:
--github-source-api-url "$SOURCE_API_URL" \
--target-api-url "$TARGET_API_URL"
Die Quell-URL wird abgelehnt.
Stellen Sie sicher, dass Sie den GHE.com Unterdomänen-API-Endpunkt anstelle eines Endpunkts GitHub Enterprise Server verwenden.
Verwendung:
https://api.SUBDOMAIN.ghe.com
Nicht verwenden:
https://HOSTNAME/api/v3
Das /api/v3 Format ist für GitHub Enterprise Server Quellen vorgesehen und ist nicht das richtige Format für GitHub Enterprise-Cloud mit Datenresidenz.