Transition vers les dépôts standards

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

Ces instructions sont principalement destinées aux administrateurs de dépôts. Pour en savoir plus en quoi la création, le transfert, l'extraction et le déploiement d'images ont changé, consultez les informations suivantes:

Avant de commencer

  1. Activez l'API Artifact Registry à partir du Console Google Cloud ou en exécutant la commande suivante:

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

    gcloud components update
    
  3. Découvrez les tarifs d'Artifact Registry avant vous commencez la transition.

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer des dépôts gcr.io, demandez à votre administrateur de vous accorder 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 Storage (roles/storage.admin)
  • Pour accorder l'accès au dépôt au niveau du projet: Administrateur de projet IAM (roles/resourcemanager.projectIamAdmin) ou un 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 page Gérer l'accès aux projets, aux dossiers et aux organisations.

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 sont 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, vous pouvez suivre progressivement les étapes de configuration et 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 à partir de vos registres existants aux dépôts Artifact Registry correspondants. Ils fournissent certaines rétrocompatible avec Container Registry, mais ils ont aussi des fonctionnalités Limites. Cependant, si vous avez beaucoup d'outils une configuration, des scripts ou du code avec des références gcr.io, une approche plus stratégique pour passer à Artifact Registry. Consultez la documentation de transition pour les dépôts avec prise en charge du domaine gcr.io pour vous aider à prendre une décision appropriée.

Étapes de transition

Ce guide vous explique comment effectuer les étapes 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 des images à partir 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 lors de la transition. terminé.

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 les rôles Cloud Storage pour contrôler les accès. Artifact Registry dispose de ses propres Les rôles et ces rôles séparent les rôles de lecture, d'écriture et d'administration de référentiels Container Registry.

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

Vous pouvez également afficher la liste des comptes principaux ayant accès à l'espace 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 correspondant à l'hôte de registre que vous souhaitez afficher. Dans les noms des buckets, PROJECT-ID correspond à Google Cloud ID du projet.

    • 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 disposent de ce rôle.

La liste inclut les rôles IAM attribués directement sur le bucket et les rôles hérités du projet parent. Selon le rôle, vous pouvez choisir le rôle Artifact Registry le plus approprié à attribuer.

Cloud Storage et rôles de base

Accorder des autorisations aux utilisateurs et aux comptes de service qui ont actuellement accès à Container Registry avec 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 principal utilise actuellement Container Registry. Certains comptes principaux peuvent n'accéder qu'à d'autres buckets Cloud Storage sans lien avec Container Registry.

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

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

Accès requis Rôle actuel Rôle Artifact Registry Où attribuer le rôle
Extraire des images uniquement (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 Storage
(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 accordés au niveau du projet. Par exemple, l'agent de service Cloud Run dispose du rôle "Agent de service Cloud Run".

Dans la plupart des cas, ces rôles d'agent de service contiennent des valeurs pour Container Registry et Artifact Registry, aucune modification supplémentaire n'est nécessaire si vous exécutez Artifact Registry dans le même projet que votre registre Container Registry existant Google Cloud.

Consultez le documentation de référence sur les rôles d'agent de service pour plus de détails sur les autorisations dans les rôles d'agent de service.

Rôles personnalisés

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

Pour obtenir des instructions sur l'attribution de rôles Artifact Registry, consultez la section Configurer des rôles et des autorisations.

S'authentifier dans le 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 depuis 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 pour les intégrations Google Cloud courantes configurés avec des autorisations par défaut pour les dépôts 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 caractéristiques

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. Quand ? 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 Notifications Artifact Analysis
  • Vous pouvez continuer à utiliser gcloud container images. pour répertorier les notes et les occurrences associées aux chemins d'accès aux images gcr.io.
Container Registry Artifact Registry
Analyse les failles de l'OS et des packages de langage avec une analyse à la demande dans les images avec un OS compatible. L'analyse automatique ne renvoie que l'OS des informations sur les failles. En savoir plus sur les types analyse.
Analyse à la demande
Analyse automatique
  • La commande Google Cloud CLI gcloud container images inclut des options permettant d'afficher les résultats des analyses, y compris les failles et autres métadonnées.
  • Les analyses ne renvoient que des informations sur les failles du système d'exploitation pour les images Container Registry avec systèmes d'exploitation compatibles.
Analyse les failles des packages de système d'exploitation et de langue à la demande et l'analyse automatique. En savoir plus sur les types analyse.
Analyse à la demande
Analyse automatique
  • La commande Google Cloud CLI gcloud les artefacts Docker images qui incluent des options permettant d'afficher les résultats des analyses ; y compris les failles et autres métadonnées.
  • Les analyses renvoient des informations sur les failles de l'OS pour les images d'Artifact Registry avec systèmes d'exploitation et packages de langage compatibles des informations sur les failles concernant les systèmes d'exploitation systèmes.

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 à arrêter d'utiliser Container Registry, supprimez les en supprimant les buckets de stockage pour Container Registry.

Pour supprimer chaque bucket de stockage Container Registry:

Console

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

    • 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.

gcloud

Si vous souhaitez effectuer une suppression groupée pour au moins cent mille images dans un bucket, évitez d'utiliser la gcloud CLI, car le processus de suppression prend beaucoup de temps. Utiliser la console Google Cloud pour effectuer l'opération à la place. Pour en savoir plus, consultez supprimer des objets Cloud Storage de manière groupée.

Pour supprimer un bucket, utilisez la méthode gcloud storage rm avec l'option --recursive.

gcloud storage rm gs://BUCKET-NAME --recursive

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

  • 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 environnement Google Cloud dans votre projet, laissez l'API Container Registry activée. Si vous essayez de désactivez 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 actuellement Container Registry avec ces services.

Étape suivante