Migration des externen Speichers für GitHub Actions

Informationen zum Migrieren des externen Speichers GitHub Actions

Sie können GitHub Actions einen externen Speicher zu einem neuen Bucket, Konto oder in eine neue Region beim selben Anbieter migrieren, wenn Sie Cloud-Konten konsolidieren, Residenzanforderungen erfüllen oder die Speicherzuordnung neu organisieren.

Die Migration funktioniert, da GitHub Actions gespeicherte Objekte anhand ihres Schlüssels (Pfad) innerhalb eines Buckets oder Containers identifiziert werden, nicht durch den Bucket- oder Kontonamen. Solange Sie das interne Schlüssellayout beibehalten und Ihre Konfiguration so aktualisieren, dass sie auf den neuen Speicherort verweist, bleiben vorhandene Workflow-Protokolle und Artefakte ohne Unterbrechung zugänglich.

Considerations

Bevor Sie beginnen, überprüfen Sie die folgenden Einschränkungen. Jeder einzelne prägt den Migrationsansatz, und mehrere davon können zu Datenverlust führen, wenn sie ignoriert werden.

Nur derselbe Anbieter. Dieses Verfahren unterstützt Migrationen innerhalb desselben Speicheranbietertyps, z. B. Amazon S3 zu Amazon S3, Azure Blob zu Azure Blob, Google Cloud Storage zu Google Cloud Storage oder MinIO zu MinIO. Anbieterübergreifende Migrationen werden hier nicht behandelt. Für eine anbieterübergreifende Migration wenden Sie sich an GitHub Enterprise-Support.
Ändern Sie die Authentifizierungsmethode während der Migration nicht. Wenn Sie derzeit die anmeldeinformationenbasierte Authentifizierung verwenden, muss Ihre Zielkonfiguration auch die anmeldeinformationenbasierte Authentifizierung verwenden. Das gleiche gilt für OpenID Connect. Das Wechseln der Authentifizierungsmethode während einer Änderung der Speicherkonfiguration kann zu Datenverlust führen. Weitere Informationen findest du unter Aktualisierung der Anmeldeinformationen für die GitHub Actions Storage. Um die Authentifizierungsmethode zu ändern, schließen Sie zuerst die Speichermigration ab, und planen Sie dann eine separate Änderung.
Die Schlüsselstruktur im Bucket oder Container muss beibehalten werden. Objektschlüssel (Pfade) innerhalb des Quell-Buckets oder -Containers müssen im Ziel unverändert bleiben. Der Ziel-Bucketname, das Speicherkonto, die Region und andere Verbindungsparameter können sich ändern. Sie aktualisieren diese im Verwaltungskonsole Cutover. Die meisten nativen Kopierwerkzeuge der Anbieter bewahren die Schlüsselstruktur beim Kopieren eines gesamten Buckets oder Containers automatisch, aber vergewissern Sie sich vor der Umschaltung, dass das Ziel mit der Quelle übereinstimmt.
GitHub Packages verfügt über zusätzliche Einschränkungen. Wenn Sie auch verwenden GitHub Packages, lesen Sie den GitHub Packages nachstehenden Abschnitt "Überlegungen ", bevor Sie beginnen.

Voraussetzungen

Sie haben Websiteadministratorzugriff auf Ihre GitHub Enterprise Server-Instance.
Sie haben den Zielspeicher beim selben Anbieter wie die Quelle im gewünschten Konto, in der gewünschten Region oder in der gewünschten Mandantschaft bereitgestellt.
Das Ziel ist leer.
Das Ziel gewährt Ihre GitHub Enterprise Server-Instance die gleichen Berechtigungen wie die Quelle. Die erforderlichen Berechtigungen finden Sie im entsprechenden Konfigurationsartikel:
Sie verfügen über Administratoranmeldeinformationen sowohl für den Quell- als auch für den Zielspeicher, die zum Lesen aller Quellobjekte und zum Schreiben an das Ziel ausreichen.
Sie haben eine aktuelle Sicherung von Ihre GitHub Enterprise Server-Instance. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf Ihrer Instanz mit Sicherungshilfsprogrammen.
Sie haben die Migration in einer Staging-Umgebung geprobt. Siehe nächster Abschnitt.

Durchspielen der Migration in einer Staging-Umgebung

Bevor Sie die Migration in der Produktionsumgebung durchführen, spielen Sie den vollständigen Ablauf auf einer Staging-Instanz durch. Stellen Sie eine Staginginstanz GitHub Enterprise Server aus einer aktuellen Produktionssicherung bereit, verweisen Sie sie auf ein temporäres Ziel, das dem vorgesehenen Produktionsziel entspricht, und führen Sie jeden Schritt in diesem Artikel von Anfang bis Ende aus. Weitere Informationen findest du unter Testinstanz einrichten und Verwenden einer Staging-Umgebung.

Eine Generalprobe in der Staging-Umgebung bestätigt, dass:

Anbieterseitige Berechtigungen, Netzwerkzugriff und Richtlinien für das Ziel sind korrekt.
Das von Ihnen ausgewählte Kopiertool arbeitet mit repräsentativen Datenmengen erfolgreich.
Die erwartete Objektanzahl und die Gesamtgröße stimmen zwischen Quelle und Ziel überein.
Vorhandene Workflowausführungsprotokolle und Artefakte können nach der Umstellung über die Benutzeroberfläche abgerufen werden.

Warnung

Ihre Staginginstanz muss einen anderen Speicher als Ihre Produktionsinstanz verwenden. Wenn Sie die Speicherkonfiguration nicht ändern, kann die Staginginstanz in Ihren Produktionsspeicher schreiben und Datenverlust verursachen. Weitere Informationen findest du unter Verwenden einer Staging-Umgebung.

Durchführung der Migration

Führen Sie die folgenden Schritte in der angegebenen Reihenfolge durch. GitHub Actions kann weiterhin Traffic bedienen, bis Sie den Wartungsmodus aktivieren.

Führen Sie die erste Datenkopie aus. Kopieren Sie alle Objekte aus der Quelle mithilfe eines anbietereigenen Tools in das Ziel. Neue Objekte, die während des Kopiervorgangs in die Quelle geschrieben werden, werden nach dem Cutover durch die endgültige Delta-Synchronisierung erfasst.

Verwenden Sie die Beispielbefehle als Ausgangspunkt. In der Upstreamdokumentation finden Sie die vollständigen Optionen, einschließlich Anmeldeinformationen, Verschlüsselung und Durchsatzoptimierung.

Verwenden Sie aws s3 sync für Amazon S3 die AWS-Befehlszeilenschnittstelle. Führen Sie zuerst einen Testlauf durch, um den Vorgang zu validieren, und führen Sie anschließend den Kopiervorgang durch.
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET --dryrun
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Für Azure Blob Storage verwenden Sie azcopy copy mit einer Shared Access Signature auf der Quelle.
```
azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER?SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER' --recursive
```
Verwenden Sie für Google Cloud Storagegcloud storage rsync über die Befehlszeilenschnittstelle von Google Cloud.
```
gcloud storage rsync --recursive gs://SOURCE-BUCKET gs://DESTINATION-BUCKET
```
Verwenden Sie mc mirror für MinIO den MinIO-Client.
```
mc mirror SOURCE-ALIAS/SOURCE-BUCKET DESTINATION-ALIAS/DESTINATION-BUCKET
```
Überprüfen Sie nach Abschluss des Kopiervorgangs die Objektanzahl und die Gesamtgröße am Ziel mithilfe der standardmäßigen Auflistungstools Ihres Anbieters. Untersuchen Sie alle Diskrepanzen, bevor Sie fortfahren.
Aktivieren sie den Wartungsmodus. Um zu verhindern, dass während des Umschaltvorgangs neue Objekte in die Quelle geschrieben werden, aktivieren Sie auf Ihre GitHub Enterprise Server-Instance den Wartungsmodus. Dies nimmt die Instanz für Endbenutzer kurz offline. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
Führen Sie die endgültige Delta-Synchronisierung aus. Wenn der Wartungsmodus aktiviert ist, führen Sie denselben Kopierbefehl aus dem ersten Kopierschritt erneut aus. Dadurch werden alle Objekte erfasst, die seit Beginn des ersten Kopiervorgangs in die Quelle geschrieben wurden.

Beispiel: für Amazon S3:
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Aktualisieren Sie die Speicherkonfiguration. Aktualisieren Sie Ihre GitHub Enterprise Server-Instance, sodass es auf den neuen Speicherort verweist. Behalten Sie die gleiche Authentifizierungsmethode wie zuvor bei.
1. Melden Sie sich bei Verwaltungskonsole an. Weitere Informationen findest du unter Zugreifen auf die Verwaltungskonsole.
2. Klicken Sie in der Randleiste "Einstellungen" auf "Aktionen".
3. Unter „Artefakt- und Protokollspeicher“ aktualisieren Sie die Felder, die den Speicherort angeben, z. B. den Bucketnamen, den Kontonamen, die Region, die Rollen-ARN oder die Verbindungszeichenfolge. Ändern Sie die Authentifizierungsmethode nicht.
4. Klicken Sie auf Speichereinstellungen testen, um die neue Konfiguration zu validieren.
  
  Warnung
  
  Wenn der Test fehlschlägt, speichern Sie die Einstellungen nicht. Untersuchen Sie den Fehler, und testen Sie den Vorgang erneut, bevor Sie fortfahren. Das Speichern einer ungültigen Speicherkonfiguration kann zu einem Ausfall führen.
5. Klicken Sie auf " Einstellungen speichern" , und warten Sie, bis Dienste vollständig neu gestartet werden.
Alternativ können Sie die Konfiguration über die Befehlszeile mithilfe ghe-actions-precheck der anmeldeinformationenbasierten Authentifizierung aktualisieren. Weitere Informationen findest du unter Befehlszeilenwerkzeuge.
Überprüfen Sie die Migration. Vergewissern Sie sich nach der Konfigurationsänderung, dass GitHub Actions aus dem neuen Speicherort lesen kann.
1. Deaktivieren Sie den Wartungsmodus. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
2. Öffnen Sie in der Web-UI für Ihre GitHub Enterprise Server-Instanceeinen zuletzt ausgeführten Workflow, der vor der Migration abgeschlossen wurde. Bestätigen Sie Folgendes:
  - Protokolle der Workflow-Ausführung werden geladen.
  - Build-Artefakte erfolgreich heruntergeladen.
3. Lösen Sie eine neue Workflowausführung aus, und bestätigen Sie Folgendes:
  - Der Vorgang wird erfolgreich abgeschlossen.
  - Protokolle und alle artefakte, die von der Ausführung erzeugt werden, sind sichtbar.
Wenn eine dieser Validierungsprüfungen fehlschlägt, behalten Sie den Quellspeicher bei und lesen Sie den Abschnitt Zurücksetzen weiter unten.
Nehmen Sie den Quellspeicher außer Betrieb. Fahren Sie erst fort, nachdem die Überprüfung erfolgreich abgeschlossen wurde und Sie genügend Zeit haben, um sicher zu sein, dass der neue Speicherort fehlerfrei ist. Behalten Sie als Richtlinie den Quellspeicher in einem schreibgeschützten Zustand für mindestens einen vollständigen Sicherungszyklus bei, bevor Sie ihn löschen.

Wenn Sie bereit sind, den Quellspeicher zu entfernen, befolgen Sie das Standardverfahren Ihres Anbieters zum Löschen eines Buckets oder Containers.

Rollback ausführen

Wenn die Überprüfung fehlschlägt oder nach der Umstellung Probleme auftreten, führen Sie ein Rollback durch, indem Sie Ihre GitHub Enterprise Server-Instance wieder auf den Quellspeicherort verweisen. Der Quellspeicher ist Ihre nachweislich funktionierende Kopie. Kopieren Sie im Rahmen eines Rollbacks keine Daten aus dem Ziel zurück in die Quelle, da Daten, die während einer fehlgeschlagenen Umschaltung in das Ziel geschrieben wurden, unvollständig oder inkonsistent sein können und das Zurückschreiben in die Quelle Ihre einzige intakte Kopie beschädigen könnte.

Warnung

Ein Rollback verwirft alle Daten, die nach dem Cutover geschrieben oder gelöscht wurden. Wenn die Validierung fehlschlägt, führen Sie sofort einen Rollback durch, anstatt eine umfangreichere Fehlersuche zu versuchen. Je länger Sie warten, desto mehr Daten sind gefährdet.

Wenn die Überprüfung fehlschlägt oder Probleme auftreten:

Aktivieren Sie den Wartungsmodus sofort.
Stellen Sie die Verwaltungskonsoleursprünglichen Speicherkonfigurationswerte wieder her, und klicken Sie auf " Speichereinstellungen testen" und dann auf " Einstellungen speichern".
Deaktivieren Sie den Wartungsmodus, und führen Sie die Überprüfungsschritte mit dem ursprünglichen Speicher erneut aus.

Untersuchen Sie nach einem erfolgreichen Rollback den Fehler, und planen Sie einen neuen Migrationsversuch.

Überlegungen zu GitHub Packages

Sie können den gleichen Migrationsansatz auf GitHub Packages externen Speicher anwenden, wobei die folgenden wichtigen Unterschiede bestehen. Lesen Sie diesen Abschnitt vollständig durch, bevor Sie den Speicher einer Instanz migrieren, bei der GitHub Packages aktiviert ist.

OpenID Connect ist für GitHub Packages nicht verfügbar. GitHub Packages unterstützt nur die anmeldeinformationenbasierte Authentifizierung für den externen Speicher. Die Einschränkung der Authentifizierungsmethode in diesem Artikel gilt weiterhin: Halten Sie die Authentifizierungsmethode während der Migration unverändert.
GitHub Packages ist sensibler für zeitliche Missübereinstimmungen. Wenn Pakete während des Migrationsfensters veröffentlicht werden, erstellt das System sowohl neue Speicherobjekte als auch Datenbankdatensätze. Um Inkonsistenzen zu vermeiden, lassen Sie den Wartungsmodus vom Beginn der finalen Delta-Synchronisierung bis zur erfolgreichen Validierung der neuen Konfiguration durchgehend aktiviert.
Aktualisieren Sie beide Konfigurationen zusammen, wenn derselbe Anbieter beide Produkte bedient. Wenn Sie GitHub Actions und GitHub Packages so konfiguriert haben, dass sie denselben Anbietertyp verwenden, und Sie beide migrieren, planen Sie die Umstellung als ein einziges Wartungsfenster und aktualisieren Sie beide Konfigurationen, bevor Sie den Wartungsmodus deaktivieren.
Für anbieterübergreifende Migrationen des Speichers GitHub Packages wenden Sie sich an GitHub Enterprise-Support. Anbieterübergreifende Verschiebungen werden hier nicht behandelt.

Weitere Informationen zum Konfigurieren des GitHub Packages Speichers finden Sie unter Erste Schritte mit GitHub-Paketen für Ihr Unternehmen.

Wer kann dieses Feature verwenden?

In diesem Artikel