Migrer vers Secure Source Manager

Ce guide explique comment migrer un dépôt Git, y compris toutes ses informations, de Cloud Source Repositories (CSR) de Google vers Secure Source Manager (SSM). Cette migration utilise des commandes Git standards pour cloner et transférer les données du dépôt.

Prérequis

Avant de commencer la migration, assurez-vous de remplir les conditions préalables suivantes :

  • Autorisations : les utilisateurs ou les comptes de service doivent disposer des autorisations suivantes pour effectuer la migration :
    • source.repos.get, disponible dans le rôle roles/source.reader, sur le dépôt CSR source
    • securesourcemanager.instances.access, disponible dans le rôle roles/securesourcemanager.instanceAccessor, et securesourcemanager.repositories.fetch, disponible dans le rôle roles/securesourcemanager.repoWriter, sur l'instance et le dépôt SSM cibles. Si vous créez des dépôts, consultez Créer un dépôt.
  • Client Git : vous avez besoin d'un ordinateur sur lequel l'outil de ligne de commande Git est installé.
  • SDK Google Cloud : pour vous authentifier lorsque vous utilisez HTTPS, vous devez installer la version 395.0.0 ou ultérieure sur le même ordinateur que celui sur lequel vous avez installé l'outil Git. Si vous ne disposez pas de Google Cloud SDK, vous devez vous connecter à CSR et à SSM à l'aide de clés SSH.
  • Instance SSM : assurez-vous de pouvoir accéder à l'instance SSM depuis votre ordinateur. Si votre instance est configurée à l'aide de Private Service Connect, consultez Accéder à une instance privée pour en savoir plus sur l'accès.
  • Stockage local : vous devez disposer de suffisamment d'espace disque local pour stocker temporairement les clones des dépôts que vous migrez.

Procédure de migration

Le processus de migration consiste à cloner le dépôt complet de CSR sur votre ordinateur local, puis à transférer le clone vers le dépôt SSM.

Déterminer le compte principal et la méthode d'accès pour les dépôts CSR et SSM

Vous pouvez vous connecter à CSR à l'aide des transports HTTP ou SSH lorsque vous vous authentifiez en tant qu'entité principale utilisateur, ou via HTTP lorsque vous vous authentifiez en tant que compte de service. Vous pouvez vous connecter et vous authentifier auprès de SSM à l'aide des transports HTTP ou SSH, en tant que compte principal utilisateur ou de service.

Vous n'avez pas besoin d'utiliser le même transport ou le même principal pour la RSE et SSM. Déterminez le principal et le transport que vous utiliserez pour chaque plate-forme. Pour en savoir plus sur l'emprunt d'identité des comptes de service, consultez Emprunter l'identité d'un compte de service.

S'assurer que le dépôt CSR est en lecture seule

Ce guide de migration n'utilise pas la mise en miroir ni la synchronisation automatiques. Par conséquent, assurez-vous que personne n'écrive dans le dépôt CSR pendant ou après la migration. Mettez à jour les autorisations IAM afin qu'aucun utilisateur ne dispose d'un rôle autre que roles/source.reader sur le dépôt. Vous pouvez également coordonner avec vos utilisateurs pour arrêter tous les commits pendant la migration.

Créer un dépôt Secure Source Manager

Vous pouvez ignorer cette étape si un administrateur a déjà créé le dépôt pour vous.

Pour créer un dépôt vide dans votre instance SSM, suivez le guide Créer un dépôt. Vérifiez les points suivants :

  • Si vous utilisez l'interface utilisateur, ne sélectionnez pas Initialize Repository (Initialiser le dépôt), car cela crée un dépôt non vide.
  • Si vous utilisez Google Cloud CLI, ne définissez pas les indicateurs --gitignores, --readme et --licenses, car cela crée un dépôt non vide.
  • Si vous utilisez l'API, ne définissez pas les champs gitignores, license et readme de InitialConfig, car cela crée un dépôt non vide.

Valider les paramètres du dépôt SSM

Vérifiez que le dépôt est vide en consultant l'UI ou en clonant le dépôt et en exécutant git show-ref. La sortie est vide si le dépôt est vide.

Assurez-vous qu'aucune règle de protection de branche n'est active en consultant l'interface utilisateur ou en utilisant l'API. Aucune règle ne doit être définie, ou toutes les règles doivent être désactivées pour éviter de bloquer la migration.

Vérifier l'espace disque local et distant

Avant de cloner le dépôt CSR, déterminez sa taille totale. Exécutez gcloud source repos describe <var>CSR_REPO_NAME</var>. Cette commande affiche le nombre total d'octets dans le dépôt. Pour évaluer l'espace disque disponible sur un système Linux, exécutez df . pour afficher le nombre d'octets disponibles dans le répertoire actuel.

SSM est soumis à une limite par défaut de 100 Go de stockage par instance. Vérifiez que le dépôt CSR est adapté avant de le cloner.

Cloner le dépôt CSR

Clonez l'historique complet du dépôt depuis CSR sur votre ordinateur local.

  1. Accédez au répertoire local dans lequel vous souhaitez stocker temporairement le dépôt.
  2. Clonez le dépôt : sh git clone <var>CSR_REPO_URL</var> --mirror

Cette commande crée un clone nu, qui est optimisé pour envoyer l'intégralité du contenu du dépôt à un autre dépôt distant. Vous remarquerez que le répertoire ne contient que des fichiers tels que config et HEAD, au lieu du contenu de votre dépôt. Ce comportement est normal : tout le contenu du dépôt a été cloné et se trouve dans le répertoire objects et d'autres, mais il n'y a pas de copie de travail.

Ajouter le dépôt Secure Source Manager en tant que dépôt distant

Exécutez la commande suivante :

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

Transférer le dépôt complet vers Secure Source Manager

Transférez toutes les branches, tous les tags et toutes les références du clone local vers le dépôt distant SSM :

git push --mirror ssm

Validation

Une fois l'opération d'envoi terminée, clonez le dépôt SSM dans un autre répertoire. Comparez ensuite les copies CSR et SSM du dépôt :

  • Nombre de branches : exécutez git branch -r dans chaque dépôt et vérifiez que le nombre de branches est identique. Sur les systèmes Linux ou macOS, le transfert de la commande vers wc -l permet de compter les lignes de sortie.
  • Nombre de tags : exécutez git tag dans chaque dépôt et vérifiez que le nombre de tags est identique. Sur les systèmes Linux ou macOS, le transfert de la commande vers wc -l permet de compter les lignes de sortie.
  • Commit HEAD : exécutez git rev-parse HEAD dans chaque dépôt et vérifiez que le hachage du commit est identique.
  • Nombre de commits : exécutez git rev-list --all --count dans chaque dépôt et vérifiez que le nombre de commits est identique.

Nettoyage

  • Si vous avez emprunté l'identité d'un compte de service lors de la migration, exécutez gcloud config set account pour réinitialiser vos identifiants.
  • Si vous avez désactivé les règles de protection des branches, réactivez-les sur le dépôt SSM.
  • Supprimez les copies brutes du dépôt CSR de l'ordinateur que vous avez utilisé pour la migration.
  • Supprimez le dépôt CSR d'origine.

Étapes suivantes