Zu Secure Source Manager migrieren

In diesem Leitfaden wird beschrieben, wie Sie ein Git-Repository mit allen zugehörigen Informationen von Cloud Source Repositories (CSR) von Google zu Secure Source Manager (SSM) migrieren. Bei dieser Migration werden Standard-Git-Befehle zum Klonen und Übertragen von Repository-Daten verwendet.

Vorbereitung

Bevor Sie mit der Migration beginnen, sollten Sie prüfen, ob die folgenden Voraussetzungen erfüllt sind:

  • Berechtigungen: Die Nutzer oder Dienstkonten müssen die folgenden Berechtigungen haben, um die Migration durchzuführen:
    • source.repos.get, die im Quell-CSR-Repository in der Rolle roles/source.reader verfügbar ist
    • securesourcemanager.instances.access, die in der Rolle roles/securesourcemanager.instanceAccessor verfügbar ist, und securesourcemanager.repositories.fetch, die in der Rolle roles/securesourcemanager.repoWriter verfügbar ist, in der Ziel-SSM-Instanz und im Ziel-Repository. Wenn Sie neue Repositories erstellen, lesen Sie den Abschnitt Repository erstellen.
  • Git-Client: Sie benötigen einen Computer, auf dem das Git-Befehlszeilentool installiert ist.
  • Google Cloud SDK: Wenn Sie sich bei der Verwendung von HTTPS authentifizieren möchten, müssen Sie Version 395.0.0 oder höher auf demselben Computer installieren, auf dem Sie das Git-Tool installiert haben. Wenn Sie das Google Cloud SDK nicht haben, müssen Sie sowohl eine Verbindung zu CSR als auch zu SSM mit SSH-Schlüsseln herstellen.
  • SSM-Instanz: Prüfen Sie, ob Sie von Ihrem Computer aus auf die SSM-Instanz zugreifen können. Wenn Ihre Instanz mit Private Service Connect konfiguriert ist, finden Sie unter Auf eine private Instanz zugreifen weitere Informationen zum Zugriff.
  • Lokaler Speicher: Sie benötigen genügend lokalen Speicherplatz, um Klone der zu migrierenden Repositorys vorübergehend zu speichern.

Migrationsschritte

Beim Migrationsprozess wird das gesamte Repository von CSR auf Ihren lokalen Computer geklont und dann in das SSM-Repository übertragen.

Zugriffsprinzipal und -methode für CSR- und SSM-Repositories festlegen

Sie können eine Verbindung zu CSR über HTTP- oder SSH-Transports herstellen, wenn Sie sich als Nutzer-Principal authentifizieren, oder über HTTP, wenn Sie sich als Dienstkonto authentifizieren. Sie können eine Verbindung zu SSM herstellen und sich authentifizieren, indem Sie HTTP- oder SSH-Transports als Nutzer- oder Dienstkontohauptkonto verwenden.

Sie müssen nicht denselben Transport oder Prinzipal für CSR und SSM verwenden. Legen Sie für jede Plattform den Haupt- und Transport fest, den Sie verwenden möchten. Weitere Informationen zum Identitätswechsel für Dienstkonten finden Sie unter Identitätswechsel für Dienstkonten.

CSR-Repository schreibgeschützt machen

In diesem Migrationsleitfaden werden keine automatische Spiegelung oder Synchronisierung verwendet. Achten Sie daher darauf, dass während oder nach der Migration niemand in das CSR-Repository schreibt. Aktualisieren Sie die IAM-Berechtigungen, sodass kein Nutzer eine andere Rolle als roles/source.reader für das Repository hat. Alternativ können Sie mit Ihren Nutzern vereinbaren, dass während der Migration keine Commits erfolgen.

Secure Source Manager-Repository erstellen

Sie können diesen Schritt überspringen, wenn ein Administrator das Repository bereits für Sie erstellt hat.

Wenn Sie ein leeres Repository in Ihrer SSM-Instanz erstellen möchten, folgen Sie der Anleitung zum Erstellen eines neuen Repositorys. Sie müssen Folgendes sicherstellen:

  • Wenn Sie die Benutzeroberfläche verwenden, wählen Sie Repository initialisieren nicht aus, da dadurch ein nicht leeres Repository erstellt wird.
  • Wenn Sie die Google Cloud CLI verwenden, legen Sie die Flags --gitignores, --readme und --licenses nicht fest, da dadurch ein nicht leeres Repository erstellt wird.
  • Wenn Sie die API verwenden, legen Sie die Felder gitignores, license und readme des InitialConfig nicht fest, da dadurch ein nicht leeres Repository erstellt wird.

SSM-Repository-Einstellungen validieren

Prüfen Sie, ob das Repository leer ist. Sehen Sie dazu in der Benutzeroberfläche nach oder klonen Sie das Repository und führen Sie git show-ref aus. Die Ausgabe ist leer, wenn das Repository leer ist.

Prüfen Sie in der Benutzeroberfläche oder über die API, ob aktive Regeln zum Schutz von Branches vorhanden sind. Es dürfen keine Regeln vorhanden sein oder alle Regeln müssen deaktiviert sein, damit die Migration nicht blockiert wird.

Lokalen und Remote-Speicherplatz prüfen

Bevor Sie das CSR-Repository klonen, ermitteln Sie seine Gesamtgröße. Führen Sie gcloud source repos describe <var>CSR_REPO_NAME</var> aus. Dieser Befehl gibt die Gesamtzahl der Bytes im Repository aus. Um den verfügbaren Speicherplatz auf einem Linux-System zu ermitteln, führen Sie df . aus, um die Anzahl der im aktuellen Verzeichnis verfügbaren Byte zu sehen.

SSM hat ein Standardlimit von 100 GB Speicherplatz pro Instanz. Prüfen Sie vor dem Klonen, ob das CSR-Repository passt.

CSR-Repository klonen

Klonen Sie den vollständigen Repository-Verlauf von CSR auf Ihren lokalen Computer.

  1. Wechseln Sie in das lokale Verzeichnis, in dem Sie das Repository vorübergehend speichern möchten.
  2. Klonen Sie das Repository: sh git clone <var>CSR_REPO_URL</var> --mirror

Mit diesem Befehl wird ein Bare-Klon erstellt, der für das Übertragen des gesamten Repositoryinhalts an ein anderes Remote-Repository optimiert ist. Das Verzeichnis enthält nur Dateien wie config und HEAD anstelle des Repositoryinhalts. Das ist zu erwarten, da der gesamte Repository-Inhalt geklont wurde und im Verzeichnis objects und anderen Verzeichnissen vorhanden ist, aber keine Arbeitskopie vorhanden ist.

Secure Source Manager-Repository als neues Remote-Repository hinzufügen

Führen Sie dazu diesen Befehl aus:

git remote add ssm <var>SSM_REPOSITORY_URL</var>

Vollständiges Repository per Push an Secure Source Manager übertragen

Übertragen Sie alle Branches, Tags und Referenzen aus dem lokalen Klon in das SSM-Remote-Repository:

git push --mirror ssm

Validierung

Nachdem der Push-Vorgang abgeschlossen ist, klonen Sie das SSM-Repository in ein anderes Verzeichnis. Vergleichen Sie dann die CSR- und SSM-Kopien des Repositorys:

  • Anzahl der Branches: Führen Sie git branch -r in jedem Repository aus und prüfen Sie, ob die Anzahl der Branches gleich ist. Unter Linux- oder macOS-Systemen werden durch das Weiterleiten des Befehls an wc -l die Ausgabezellen gezählt.
  • Anzahl der Tags: Führen Sie git tag in jedem Repository aus und prüfen Sie, ob die Anzahl der Tags identisch ist. Auf Linux- oder macOS-Systemen werden durch Weiterleiten des Befehls an wc -l die Ausgabezellen gezählt.
  • HEAD-Commit: Führen Sie git rev-parse HEAD in jedem Repository aus und prüfen Sie, ob der Commit-Hash identisch ist.
  • Anzahl der Commits: Führen Sie git rev-list --all --count in jedem Repository aus und prüfen Sie, ob die Anzahl der Commits gleich ist.

Bereinigen

  • Wenn Sie während der Migration die Identität eines Dienstkontos angenommen haben, führen Sie gcloud config set account aus, um Ihre Anmeldedaten zurückzusetzen.
  • Wenn Sie Zweigschutzregeln deaktiviert haben, aktivieren Sie Zweigschutzregeln im SSM-Repository wieder.
  • Entfernen Sie alle Kopien des CSR-Repositorys von dem Computer, den Sie für die Migration verwendet haben.
  • Löschen Sie das ursprüngliche CSR-Repository.

Nächste Schritte