Transition vers les dépôts standards

Si vous utilisez actuellement Container Registry pour gérer vos images de conteneurs, cette page explique comment configurer un dépôt Artifact Registry standard et en quoi l'utilisation des dépôts diffère de celle de Container Registry.

Ces instructions sont principalement destinées aux administrateurs de dépôt. Pour en savoir plus sur les modifications apportées à la création, au transfert, à l'extraction et au déploiement d'images, consultez les informations suivantes:

Avant de commencer

  1. Activez l'API Artifact Registry à partir de la console Google Cloud ou à l'aide de la commande suivante:

    gcloud services enable artifactregistry.googleapis.com
    
  2. Si ce n'est pas déjà fait, installez la gcloud CLI. Pour une installation existante, exécutez la commande suivante afin de mettre à jour les composants vers les dernières versions:

    gcloud components update
    
  3. Découvrez les pricing d'Artifact Registry avant de commencer la transition.

Rôles requis

Pour obtenir les autorisations nécessaires à la configuration des dépôts gcr.io, demandez à votre administrateur de vous attribuer les rôles IAM suivants sur le projet Google Cloud:

  • Pour créer des dépôts Artifact Registry et accorder l'accès à des dépôts individuels : Administrateur Artifact Registry (roles/artifactregistry.admin)
  • Pour afficher et gérer la configuration Container Registry existante appliquée aux buckets de stockage Cloud Storage : Administrateur de l'espace de stockage (roles/storage.admin)
  • Pour accorder l'accès au dépôt au niveau du projet : Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) ou rôle comprenant des autorisations équivalentes, comme Administrateur de dossier (roles/resourcemanager.folderAdmin) ou Administrateur de l'organisation (roles/resourcemanager.organizationAdmin)

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Présentation

Les dépôts standards sont des dépôts Artifact Registry standards compatibles avec toutes les fonctionnalités.

Par souci de simplicité, les instructions de cette page partent du principe que Container Registry et Artifact Registry se trouvent dans le même projet Google Cloud. Vous pouvez continuer à utiliser les deux services lors de la transition vers Artifact Registry afin d'effectuer progressivement les étapes de configuration et de mettre à jour votre automatisation. Si nécessaire, vous pouvez configurer Artifact Registry dans un projet distinct et effectuer les mêmes étapes globales.

Artifact Registry propose également des dépôts gcr.io. Ces dépôts peuvent rediriger le trafic gcr.io de vos registres existants vers les dépôts Artifact Registry correspondants. Elles offrent une rétrocompatibilité avec Container Registry, mais présentent également certaines limites de fonctionnalités. Toutefois, si vous disposez d'un grand nombre de configurations d'outils, de scripts ou de code avec des références gcr.io, une approche plus tactique peut être nécessaire pour passer à Artifact Registry. Consultez la documentation de transition pour les dépôts compatibles avec les domaines gcr.io pour vous aider à prendre la décision appropriée.

Étapes de transition

Ce guide vous explique comment effectuer les opérations suivantes:

  1. Créer un dépôt Docker pour vos conteneurs. Vous devez créer un dépôt pour pouvoir y transférer des images.
  2. Accorder des autorisations sur le dépôt.
  3. Configurer l'authentification afin de pouvoir vous connecter au nouveau dépôt.
  4. Si nécessaire, copiez les images de Container Registry que vous souhaitez utiliser dans votre nouveau dépôt.
  5. Essayer de transférer et récupérer vos conteneurs.
  6. Essayer de déployer vos images dans un environnement d'exécution.
  7. Configurer des fonctionnalités supplémentaires.
  8. Nettoyez les images dans Container Registry une fois la transition terminée.

Créer des dépôts

Container Registry crée automatiquement un bucket de stockage dans un emplacement multirégional si vous n'y avez pas encore stocké d'image.

Dans Artifact Registry, vous devez créer un dépôt avant de pouvoir importer des images. Lorsque vous créez un dépôt, vous devez spécifier les éléments suivants :

  • Le format du dépôt. Artifact Registry stocke les conteneurs dans des dépôts Docker.
  • Un emplacement régional ou multirégional pour le dépôt.

    Lorsque vous choisissez un emplacement pour vos dépôts Artifact Registry, tenez compte de la proximité des dépôts avec votre autre infrastructure et vos utilisateurs. Si vous envisagez de copier des images depuis Container Registry vers Artifact Registry, les différences d'emplacement peuvent avoir une incidence sur le coût de la copie.

  • Une clé Cloud Key Management Service, si vous utilisez des clés de chiffrement gérées par le client (CMEK) pour le chiffrement.

    Dans Container Registry, vous configurez le bucket de stockage Container Registry pour qu'il utilise des CMEK. Dans Artifact Registry, vous configurez les dépôts pour qu'ils utilisent des CMEK lors de leur création. Pour en savoir plus sur l'utilisation des CMEK avec Artifact Registry, consultez la section Activer les clés de chiffrement gérées par le client.

Container Registry héberge les conteneurs sur le domaine gcr.io. Artifact Registry héberge les conteneurs sur le domaine pkg.dev.

Pour en savoir plus sur la création de dépôts, notamment les dépôts qui utilisent des CMEK pour le chiffrement, consultez la page Créer des dépôts.

Octroyer des autorisations

Container Registry utilise des rôles Cloud Storage pour contrôler les accès. Artifact Registry dispose de ses propres rôles IAM, qui distinguent plus clairement les rôles de lecture, d'écriture et d'administration de dépôt que Container Registry.

Pour mapper rapidement les autorisations existantes accordées sur les buckets de stockage avec les rôles Artifact Registry suggérés, utilisez l'outil de mappage de rôles.

Vous pouvez également afficher la liste des comptes principaux ayant accès aux buckets de stockage à l'aide de la console Google Cloud.

  1. Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.

    Accéder à la page "Buckets"

  2. Cliquez sur le bucket de stockage de l'hôte de registre que vous souhaitez afficher. Dans les noms des buckets, PROJECT-ID correspond à l'ID de votre projet Google Cloud.

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
  3. Cliquez sur l'onglet Autorisations.

  4. Dans l'onglet "Autorisations", cliquez sur le sous-onglet Afficher par rôle.

  5. Développez un rôle pour afficher les comptes principaux qui l'appartiennent.

La liste comprend les rôles IAM attribués directement sur le bucket, ainsi que les rôles hérités du projet parent. En fonction du rôle, vous pouvez choisir le rôle Artifact Registry le plus approprié à attribuer.

Cloud Storage et rôles de base

Accordez aux utilisateurs et aux comptes de service qui accèdent actuellement à Container Registry un accès aux dépôts Artifact Registry. Pour les rôles Cloud Storage hérités du projet parent, vous devez vérifier que le compte principal utilise actuellement Container Registry. Il est possible que certains comptes principaux n'accèdent qu'à d'autres buckets Cloud Storage qui ne sont pas liés à Container Registry.

Les rôles de base Propriétaire, Éditeur et Lecteur qui existaient avant IAM disposent d'un accès limité aux buckets de stockage. Ils n'accordent pas intrinsèquement tous les accès aux ressources Cloud Storage que leur nom implique, et fournissent des autorisations supplémentaires pour d'autres services Google Cloud. Vérifiez quels utilisateurs et comptes de service ont besoin d'accéder à Artifact Registry, et utilisez la table de mappage de rôles pour vous aider à attribuer les rôles appropriés si l'accès à Artifact Registry est approprié.

Le tableau suivant mappe les rôles Artifact Registry en fonction des autorisations accordées par les rôles Cloud Storage prédéfinis pour l'accès à Container Registry. Les rôles Artifact Registry fournissent une séparation supplémentaire des autorisations qui n'est pas disponible dans les rôles Cloud Storage prédéfinis.

Accès obligatoire Rôle actuel Rôle Artifact Registry Où attribuer le rôle
Extraire uniquement des images (lecture seule) Lecteur des objets Storage
(roles/storage.objectViewer)
Lecteur Artifact Registry
(roles/artifactregistry.reader)
Dépôt Artifact Registry ou projet Google Cloud
Transférer et extraire des images (lecture et écriture) Rédacteur des anciens buckets de l'espace de stockage
(roles/storage.legacyBucketWriter)
Rédacteur Artifact Registry
(roles/artifactregistry.writer)
Dépôt Artifact Registry ou projet Google Cloud
Transférer, extraire et supprimer des images Rédacteur des anciens buckets de l'espace de stockage
(roles/storage.legacyBucketWriter)
Administrateur de dépôt Artifact Registry
(roles/artifactregistry.repoAdmin)
Dépôt Artifact Registry ou projet Google Cloud
Créer, gérer et supprimer des dépôts Administrateur de l'espace de stockage
(roles/storage.admin)
Administrateur Artifact Registry
(roles/artifactregistry.Admin)
Projet Google Cloud
Rôles d'agent de service hérités du projet

Les comptes de service par défaut des services Google Cloud disposent de leurs propres rôles attribués au niveau du projet. Par exemple, l'agent de service pour Cloud Run a le rôle d'agent de service Cloud Run.

Dans la plupart des cas, ces rôles d'agent de service contiennent des autorisations par défaut équivalentes pour Container Registry et Artifact Registry. Vous n'avez pas besoin d'apporter de modifications supplémentaires si vous exécutez Artifact Registry dans le même projet que votre service Container Registry existant.

Consultez la documentation de référence sur les rôles de l'agent de service pour en savoir plus sur les autorisations associées aux rôles de l'agent de service.

Rôles personnalisés

Le tableau de mappage des rôles vous aide à choisir le rôle à attribuer aux utilisateurs ou aux comptes de service en fonction du niveau d'accès dont ils ont besoin.

Pour savoir comment attribuer des rôles Artifact Registry, consultez la page Configurer les rôles et les autorisations.

S'authentifier auprès du dépôt

Artifact Registry est compatible avec les mêmes méthodes d'authentification que Container Registry.

Si vous utilisez l'assistant d'identification Docker :

  • Vous devez utiliser la version 2.0 ou une version ultérieure pour interagir avec les dépôts Artifact Registry. La version autonome est disponible dans GitHub.
  • Vous devez configurer l'assistant d'identification avec les emplacements Artifact Registry que vous souhaitez utiliser. Par défaut, l'assistant d'identification configure uniquement l'accès aux hôtes Container Registry.

Pour en savoir plus sur la configuration de l'authentification, consultez la page Configurer l'authentification pour Docker.

Copier des conteneurs à partir de Container Registry

Si vous souhaitez continuer à utiliser des conteneurs de Container Registry dans Artifact Registry, plusieurs options s'offrent à vous pour les copier. Pour obtenir des instructions détaillées, consultez la page Copier des images à partir de Container Registry.

Transférer et extraire des images

Les commandes Docker que vous utilisez pour ajouter des tags, transférer et extraire des images dans Artifact Registry sont semblables à celles que vous utilisez dans Container Registry. Il existe deux différences principales :

  • Le nom d'hôte des dépôts Docker Artifact Registry comprend un préfixe d'emplacement suivi de -docker.pkg.dev. Par exemple, il peut s'agir de australia-southeast1-docker.pkg.dev, europe-north1-docker.pkg.dev et europe-docker.pkg.dev.
  • Comme Artifact Registry accepte plusieurs dépôts Docker dans un même projet, vous devez spécifier le nom du dépôt dans les commandes.

Par exemple, dans Container Registry, cette commande transfère l'image my-image vers le registre eu.gcr.io du projet my-project.

docker push eu.gcr.io/my-project/my-image

Dans Artifact Registry, cette commande transfère l'image my-image vers le dépôt régional europe-north1-docker.pkg.dev du dépôt my-repo et du projet my-project.

docker push europe-north1-docker.pkg.dev/my-project/my-repo/my-image

Pour plus d'informations sur le transfert et l'extraction d'images dans Artifact Registry, consultez la section Transférer et extraire des images.

Déployer des images

Les comptes de service des intégrations Google Cloud courantes sont configurés avec les autorisations par défaut pour les dépôts du même projet.

La création d'images et leur transfert dans un dépôt avec Cloud Build fonctionnent généralement de la même manière que pour Container Registry. La principale différence dans Artifact Registry réside dans le fait qu'un dépôt cible doit exister pour y transférer des images, y compris la première image que vous transférez.

Assurez-vous de créer les dépôts dont vous avez besoin avant d'exécuter des commandes qui transfèrent des images, y compris la commande Docker docker push et la commande Cloud Build gcloud builds submit.

Les compilateurs Cloud Build sont toujours hébergés sur gcr.io. Pour en savoir plus, consultez la page Intégrer à Cloud Build.

Autres fonctionnalités

Cette section décrit la configuration d'autres fonctionnalités que vous avez peut-être configurées dans Container Registry.

Artifact Analysis

Artifact Analysis est compatible avec Container Registry et Artifact Registry. La documentation Artifact Analysis inclut les deux produits.

  • Les deux produits utilisent les mêmes API Artifact Analysis. Lorsque vous activez les API Artifact Analysis dans Container Registry ou Artifact Registry, les API sont activées pour les deux produits.
  • Les deux produits utilisent les mêmes sujets Pub/Sub pour les notifications Artifact Analysis.
  • Vous pouvez continuer à utiliser les commandes gcloud container images pour répertorier les notes et les occurrences associées aux chemins d'accès des images gcr.io.
Container Registry Artifact Registry
Détecte les failles du système d'exploitation et des packages de langage grâce à une analyse à la demande dans les images avec un système d'exploitation compatible. L'analyse automatique ne renvoie que des informations sur les failles de l'OS. En savoir plus sur les types d'analyse
Analyse à la demande
Analyse automatique
  • La commande gcloud container images de la Google Cloud CLI inclut des indicateurs permettant d'afficher les résultats d'analyse, y compris les failles et d'autres métadonnées.
  • Les analyses ne renvoient des informations sur les failles du système d'exploitation que pour les images stockées dans Container Registry avec des systèmes d'exploitation compatibles.
Détecte les failles du système d'exploitation et des packages de langue à l'aide d'une analyse à la demande ou automatique. En savoir plus sur les types d'analyse
Analyse à la demande
Analyse automatique
  • La commande gcloud artifacts docker images de la Google Cloud CLI inclut des indicateurs permettant d'afficher les résultats d'analyse, y compris les failles et d'autres métadonnées.
  • Les analyses renvoient des informations sur les failles du système d'exploitation pour les images stockées dans Artifact Registry avec des systèmes d'exploitation compatibles et des informations sur les failles des packages de langage pour les systèmes d'exploitation compatibles et non compatibles.

Notifications Pub/Sub

Artifact Registry publie les modifications apportées dans le même sujet gcr que Container Registry. Aucune configuration supplémentaire n'est requise si vous utilisez déjà Pub/Sub avec Container Registry dans le même projet qu'Artifact Registry.

Si vous configurez Artifact Registry dans un projet distinct, le sujet gcr peut ne pas exister. Pour obtenir des instructions de configuration, consultez la section Configurer les notifications Pub/Sub.

Périmètres de service

VPC Service Controls vous permet de configurer des périmètres de sécurité autour des ressources de vos services gérés par Google et de contrôler le déplacement des données au-delà des limites des périmètres.

Pour savoir comment procéder, consultez la section Sécuriser les dépôts dans un périmètre de service.

Nettoyer les images Container Registry

Lorsque vous êtes prêt à cesser d'utiliser Container Registry, supprimez les images restantes en supprimant les buckets de stockage de Container Registry.

Pour supprimer chaque bucket de stockage Container Registry, procédez comme suit:

Console

  1. Accédez à la page Cloud Storage de la console Google Cloud.
  2. Sélectionnez le bucket de stockage à supprimer. Dans les noms des buckets, PROJECT-ID correspond à l'ID de votre projet Google Cloud.

    • gcr.io: artifacts.PROJECT-ID.appspot.com
    • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
    • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
    • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com
  3. Cliquez sur Supprimer. Une boîte de dialogue de confirmation s'affiche.

  4. Pour confirmer la suppression, saisissez le nom du bucket, puis cliquez sur Supprimer.

gsutil

Si vous souhaitez effectuer une suppression groupée de cent mille images ou plus dans un bucket, évitez d'utiliser gsutil, car le processus de suppression prend beaucoup de temps. Utilisez plutôt la console Google Cloud pour effectuer l'opération.

Pour supprimer un bucket, exécutez la commande gsutil rm avec l'option -r.

gsutil rm -r gs://BUCKET-NAME

Remplacez BUCKET-NAME par le nom du bucket de stockage Container Registry. Dans les noms des buckets, PROJECT-ID correspond à l'ID de votre projet Google Cloud.

  • gcr.io: artifacts.PROJECT-ID.appspot.com
  • asia.gcr.io: asia.artifacts.PROJECT-ID.appspot.com
  • eu.gcr.io: eu.artifacts.PROJECT-ID.appspot.com
  • us.gcr.io: us.artifacts.PROJECT-ID.appspot.com

La réponse est semblable à ceci :

Removing gs://artifacts.my-project.appspot.com/...

Si d'autres services Google Cloud s'exécutent dans le même projet Google Cloud, laissez l'API Container Registry activée. Si vous essayez de désactiver l'API Container Registry. Container Registry affiche un avertissement si d'autres services avec une dépendance configurée sont activés dans le projet. La désactivation de l'API Container Registry désactive automatiquement tous les services du même projet avec une dépendance configurée, même si vous n'utilisez pas Container Registry avec ces services actuellement.

Étapes suivantes