Ce document explique comment configurer manuellement les dépôts gcr.io
dans
Artifact Registry.
Nous vous recommandons d'utiliser notre outil de migration automatique pour
vers les dépôts gcr.io
dans Artifact Registry.
Si vous souhaitez créer des dépôts gcr.io
dans Artifact Registry à l'aide de
des clés de chiffrement gérées par le client (CMEK),
suivez les étapes de la section Avant de commencer, puis suivez les instructions
suivez les instructions de la section Créer manuellement un dépôt.
Avant de commencer
Si ce n'est pas déjà fait, installez la Google Cloud CLI. installés. Pour une installation existante, exécutez la commande suivante pour mettre à jour les composants les plus récents:
gcloud components update
Activez les API Artifact Registry et Resource Manager. La gcloud CLI utilise l'API Resource Manager pour rechercher l'une des les autorisations requises.
Exécutez la commande suivante :
gcloud services enable \ cloudresourcemanager.googleapis.com \ artifactregistry.googleapis.com
Découvrez les tarifs d'Artifact Registry avant vous commencez la transition.
Rôles requis
Pour obtenir les autorisations dont vous avez besoin pour configurer les dépôts "gcr.io", demandez à votre administrateur de vous accorder le 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 créer un dépôt
gcr.io
la première fois que vous transférez une image vers un nom d'hôtegcr.io
: Rédacteur Artifact Registry avec création lors de l'envoi (roles/artifactregistry.createOnPushWriter
) -
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 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.
Limites
Les limites suivantes s'appliquent aux dépôts compatibles avec les domaines gcr.io
:
- Vous ne pouvez pas mapper un hôte Container Registry avec Artifact Registry dans un autre projet.
- Chaque nom d'hôte Container Registry correspond à un seul
Dépôt
gcr.io
Artifact Registry dans le même emplacement multirégional. - Les noms des dépôts
gcr.io
sont prédéfinis et vous ne pouvez pas les modifier.
Si vous avez besoin de mieux contrôler l'emplacement de vos dépôts, vous pouvez
vers des dépôts standards sur Artifact Registry
pkg.dev
. Étant donné que les dépôts standards ne sont pas compatibles avec le
gcr.io
, cette approche de transition nécessite d'apporter davantage de modifications à votre
l'automatisation et les workflows. Pour en savoir plus, consultez la section Choisir une option de transition.
sur les différences de fonctionnalités.
Créer des dépôts
Créez des dépôts gcr.io
afin de pouvoir configurer l'accès pour vos utilisateurs et
Copiez les images Container Registry existantes dans Artifact Registry avant d'activer
la redirection.
Création rapide d'un dépôt
Cette procédure permet de créer des dépôts gcr.io
chiffrés avec
Clés appartenant à Google et gérées par Google. Si vous souhaitez utiliser le chiffrement géré par le client
clés (CMEK), vous devez créer des dépôts
manuellement.
Pour créer des dépôts gcr.io
:
Ouvrez la page Dépôts de la console Google Cloud.
Sur la page, une bannière affiche le message
You have gcr.io repositories in Container Registry
Dans la bannière, cliquez sur Créer des dépôts
gcr.io
.Le panneau Créer des dépôts
gcr.io
s'ouvre. La page Copier des images répertorie les noms complets de chaque dépôt qui sera créé. Vous aurez besoin de ces noms de dépôts si vous voulez copier de Container Registry avant d'activer la redirection.Cliquez sur Créer.
Artifact Registry crée gcr.io
dépôts pour tous les dépôts Container Registry
noms d'hôte:
Nom d'hôte Container Registry | Nom du dépôt Artifact Registry |
---|---|
gcr.io | gcr.io |
asia.gcr.io | asia.gcr.io |
eu.gcr.io | eu.gcr.io |
us.gcr.io | us.gcr.io |
Pour afficher l'URL Artifact Registry du dépôt, conservez le
Pointer sur l'icône d'avertissement ()
à côté du nom du dépôt.
Avant de rediriger le trafic vers vos nouveaux dépôts, vous devez vous assurer que votre automatisation existante peut accéder au dépôt. L'étape suivante consiste à configurer autorisations pour accorder l'accès aux dépôts.
Création manuelle de dépôts
Créez manuellement des dépôts gcr.io
si vous souhaitez les utiliser
des clés de chiffrement gérées par le client (CMEK) pour chiffrer
du dépôt ou s'il existe une contrainte d'emplacement dans votre
organisation Google Cloud qui bloque la création de ressources
des emplacements spécifiques.
Pour créer manuellement un dépôt gcr.io:
Si vous utilisez des CMEK, créez la clé que vous utiliserez avec ce dépôt et accorder les autorisations nécessaires à l'utilisation de la clé. Voir Activer les clés de chiffrement gérées par le client
Ajoutez le dépôt.
Console
Ouvrez la page Dépôts de la console Google Cloud.
Cliquez sur Créer un dépôt.
Spécifiez le nom du dépôt.
Nom d'hôte Container Registry Nom du dépôt Artifact Registry gcr.io gcr.io asia.gcr.io asia.gcr.io eu.gcr.io eu.gcr.io us.gcr.io us.gcr.io Spécifiez Docker comme format de dépôt.
Sous Type d'emplacement, spécifiez l'emplacement multirégional du dépôt:
Nom d'hôte Container Registry Emplacement du dépôt Artifact Registry gcr.io us asia.gcr.io asia eu.gcr.io europe us.gcr.io us Ajoutez une description pour le dépôt. N'incluez pas de données sensibles, car les descriptions des dépôts ne sont pas chiffrées.
Dans la section Chiffrement, choisissez le mécanisme de chiffrement du dépôt.
- Clé gérée par Google : chiffrez le contenu du dépôt à l'aide d'une Clé appartenant à Google et gérée par Google.
- Clé gérée par le client : chiffre le contenu du dépôt à l'aide d'une clé que vous contrôlez via Cloud Key Management Service. Pour obtenir des instructions sur la configuration de la clé, consultez la page Configurer des CMEK pour les dépôts.
Cliquez sur Create (Créer).
gcloud
Exécutez la commande suivante pour créer un dépôt.
gcloud artifacts repositories create REPOSITORY \ --repository-format=docker \ --location=LOCATION \ --description=DESCRIPTION \ --kms-key=KMS-KEY
Remplacez les valeurs suivantes :
REPOSITORY est le nom du dépôt.
Nom d'hôte Container Registry Nom du dépôt Artifact Registry gcr.io gcr.io asia.gcr.io asia.gcr.io eu.gcr.io eu.gcr.io us.gcr.io us.gcr.io LOCATION est l'emplacement multirégional du dépôt:
Nom d'hôte Container Registry Emplacement du dépôt Artifact Registry gcr.io us asia.gcr.io asia eu.gcr.io europe us.gcr.io us DESCRIPTION est une description du dépôt. À ne pas faire inclure des données sensibles, car les descriptions de référentiel ne sont pas chiffrées.
KMS-KEY est le chemin d'accès complet au chiffrement Cloud KMS. si vous utilisez une clé de chiffrement gérée par le client pour chiffrer le contenu du dépôt. Le chemin est au format suivant :
projects/KMS-PROJECT/locations/KMS-LOCATION/keyRings/KEY-RING/cryptoKeys/KEY
Remplacez les valeurs suivantes :
- KMS-PROJECT est le projet dans lequel votre clé est stockée.
- KMS-LOCATION correspond à l'emplacement de la clé.
- KEY-RING correspond au nom du trousseau de clés.
- KEY correspond au nom de la clé.
Vous pouvez vérifier que le dépôt a bien été créé en listant vos dépôts en exécutant la commande suivante:
gcloud artifacts repositories list
Avant de rediriger le trafic vers vos nouveaux dépôts, vous devez vous assurer que votre automatisation existante peut accéder au dépôt. L'étape suivante consiste à configurer autorisations pour accorder l'accès aux dépôts.
Accorder des autorisations aux dépôts
Container Registry utilise des 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.
- Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.
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
- gcr.io:
Cliquez sur l'onglet Autorisations.
Dans l'onglet "Autorisations", cliquez sur le sous-onglet Afficher par rôle.
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 Cloud Storage hérités du projet parent, vous devez vérifier que le compte 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.
Accès requis Rôle actuel Rôle Artifact Registry Où attribuer un 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 récupérer des images (lecture et écriture)
- Supprimer des images
Rédacteur des anciens buckets Storage
(roles/storage.legacyBucketWriter
)Administrateur de dépôt Artifact Registry
(roles/artifactregistry.repoAdmin)
Dépôt Artifact Registry ou projet Google Cloud Créez un dépôt gcr.io dans Artifact Registry la première fois qu'une image est envoyé vers un nom d'hôte gcr.io dans un projet. Administrateur de l'espace de stockage
(roles/storage.admin
)Administrateur de dépôt Artifact Registry avec création lors de l'envoi
(roles/artifactregistry.createOnPushRepoAdmin)
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 ont leurs propres et les rôles attribué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 requise 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 savoir comment attribuer des rôles Artifact Registry, consultez Configurer les rôles et les autorisations
Copier des conteneurs depuis Container Registry
Nous vous recommandons d'utiliser notre outil de migration automatique pour copier vos images de Container Registry vers Artifact Registry.
Si vous souhaitez utiliser d'autres outils pour copier vos images, consultez Copier des images à partir de Container Registry
Configurer d'autres fonctionnalités
Cette section décrit la configuration d'autres fonctionnalités que vous avez peut-être définies dans Container Registry.
Artifact Analysis
Artifact Analysis est compatible avec Container Registry et Artifact Registry. Les deux produits utilisent le même API Artifact Analysis pour les métadonnées d'image et les failles et les mêmes sujets Pub/Sub pour les notifications Artifact Analysis.
Toutefois, les actions suivantes ne se produisent que lorsque la redirection est activée:
- Analyse automatique de
gcr.io
dépôts dans Artifact Registry. - Inclure l'activité du dépôt
gcr.io
dans les notifications Pub/Sub.
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 de
analyse.
|
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 de
analyse.
|
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. Toutefois, Artifact Registry ne publie pas
messages pour gcr.io
dépôts jusqu'à ce que vous activiez la redirection.
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.
Activer la redirection du trafic gcr.io
Après avoir créé vos dépôts gcr.io
et configuré les autorisations et l'authentification
des clients tiers, vous pouvez activer la redirection du trafic gcr.io
.
Si vous rencontrez un problème après avoir activé la redirection, vous pouvez acheminer le trafic vers Container Registry, puis activez de nouveau la redirection une fois que vous avez résolu le problème.
Vérifier les autorisations pour activer la redirection
Pour activer la redirection, vous devez disposer des autorisations suivantes au niveau du projet:
artifactregistry.projectsettings.update
: autorisations à mettre à jour Paramètres du projet Artifact Registry. Cette autorisation se trouve dans le Rôle d'administrateur Artifact Registry (roles/artifactregistry.admin
).storage.buckets.update
: permet de mettre à jour les buckets de stockage dans le l'ensemble du projet. Cette autorisation est associée au rôle "Administrateur de l'espace de stockage" (roles/storage.admin
).
Si vous ne disposez pas de ces autorisations, demandez à un administrateur de accorder au niveau du projet.
Les commandes suivantes accordent à l'administrateur Artifact Registry et d'administrateur de l'espace de stockage sur un projet.
gcloud projects add-iam-policy-binding PROJECT_ID \
--member='user:PRINCIPAL' \
--role='roles/artifactregistry.admin'
gcloud projects add-iam-policy-binding PROJECT_ID \
--member='user:PRINCIPAL' \
--role='roles/storage.admin'
Remplacez les valeurs suivantes :
- PROJECT_ID correspond à Google Cloud ID du projet.
- PRINCIPAL est l'adresse e-mail du compte que vous mettez à jour.
Exemple :
user:my-user@example.com
Valider la configuration du projet
Pour valider la configuration de votre projet, exécutez la commande suivante:
gcloud artifacts settings enable-upgrade-redirection \
--project=PROJECT_ID --dry-run
Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.
Artifact Registry vérifie les dépôts mappés à Container Registry noms d'hôte.
Bien qu'Artifact Registry puisse créer les dépôts gcr.io manquants pour lorsque vous activez la redirection, nous vous conseillons de commencer par les créer vous pouvez effectuer les actions suivantes avant d'activer la redirection:
- Configurer les autorisations au niveau du dépôt
- Copiez les images de Container Registry que vous souhaitez toujours utiliser
- effectuer toute configuration supplémentaire ;
Activer la redirection
Pour activer la redirection pour le trafic gcr.io
:
Console
Ouvrez la page "Paramètres" dans la console Google Cloud.
Cliquez sur Acheminer le trafic vers Artifact Registry.
gcloud
Pour activer la redirection, exécutez la commande suivante:
gcloud artifacts settings enable-upgrade-redirection \
--project=PROJECT_ID
Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.
Artifact Registry commence à activer la redirection.
Pour vérifier l'état actuel de la redirection, exécutez la commande suivante :
gcloud artifacts settings describe
Lorsque la redirection est activée, le résultat est le suivant:
legacyRedirectionState: REDIRECTION_FROM_GCR_IO_ENABLED
L'ensemble du trafic vers gcr.io
, asia.gcr.io
, eu.gcr.io
et us.gcr.io
est
même si vous n'avez pas créé de dépôts gcr.io pour
Noms d'hôte Container Registry. Si vous transférez une image vers un nom d'hôte qui n'est pas
un dépôt Artifact Registry correspondant, Artifact Registry crée le dépôt
si vous disposez d'un rôle associé au rôle artifactregistry.repositories.createOnPush
l'autorisation. Rôles prédéfinis "Rédacteur Create-on-push"
(artifactregistry.createOnPushWriter
) et dépôt Create-on-push
L'administrateur (artifactregistry.createOnPushRepoAdmin
) dispose de cette autorisation.
Lorsque la redirection est activée, vous pouvez tester votre automatisation et vérifier Transférez et extrayez des images à l'aide de vos nouveaux dépôts gcr.io.
Vérifier la redirection
Vérifiez que les requêtes pull et push sur les noms d'hôte gcr.io
fonctionnent.
Transférez une image de test vers l'un de vos dépôts gcr.io à l'aide de son
gcr.io
chemin d'accès.Ajoutez un tag à l'image à l'aide du chemin d'accès
gcr.io
. Par exemple, cette commande ajoute le tagus.gcr.io/my-project/test-image
à l'imagelocal-image
:docker tag local-image us.gcr.io/my-project/test-image
Transférez l'image à laquelle vous avez ajouté un tag. Par exemple, cette commande transfère image
us.gcr.io/my-project/test-image
:docker push us.gcr.io/my-project/test-image
Lister les images du dépôt pour vérifier qu'elles ont bien été importées avec succès. Par exemple, pour répertorier les images dans
us.gcr.io/my-project
, exécutez la commande suivante : la commande suivante:gcloud container images list --repository=us.gcr.io/my-project
Récupérez l'image depuis le dépôt à l'aide de son chemin d'accès Container Registry. Par exemple, cette commande extrait l'image
us.gcr.io/my-project/test-image
.docker pull us.gcr.io/my-project/test-image
Après ce test initial, vérifiez que votre automatisation existante pour créer et déployer des images fonctionne comme prévu, y compris:
- Les utilisateurs et les comptes de service qui utilisent Container Registry peuvent toujours transférer, extraire, et déployer des images lorsque la redirection est activée.
- Votre automatisation ne transfère les images que vers les dépôts existants.
- Si l'analyse des failles Artifact Analysis est activée, l'analyse identifie les images présentant des failles dans les dépôts gcr.io.
- Si vous utilisez l'autorisation binaire, vos stratégies existantes fonctionnent correctement pour les images déployés à partir de dépôts gcr.io.
- Les abonnements Pub/Sub configurés incluent les notifications dans vos dépôts gcr.io.
Nettoyer les images Container Registry
Lorsque la redirection est activée, les commandes pour supprimer des images dans les chemins d'accès gcr.io
supprimer des images dans le dépôt Artifact Registry gcr.io
correspondant.
Les commandes de suppression permettant de supprimer des images dans les chemins d'accès gcr.io
ne suppriment pas les images stockées sur
Hôtes Container Registry
Pour supprimer en toute sécurité toutes les images Container Registry, supprimez le bucket Cloud Storage des buckets pour chaque nom d'hôte Container Registry.
Pour supprimer chaque bucket de stockage Container Registry:
Console
- Accédez à la page Cloud Storage de la console Google Cloud.
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
- gcr.io:
Cliquez sur Supprimer. Une boîte de dialogue de confirmation s'affiche.
Pour confirmer la suppression, saisissez le nom du bucket, puis cliquez sur Supprimer.
gsutil
Si vous voulez supprimer de manière groupée cent mille images ou plus d'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, utilisez la méthode gsutil rm
avec l'option -r
.
gsutil rm -r gs://BUCKET-NAME
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 un sont activées dans le projet. Désactiver l'API Container Registry désactive automatiquement tous les services du projet avec une configuration même si vous n'utilisez pas Container Registry avec services.
Étape suivante
- Consultez le guide de démarrage rapide de Docker.
- Apprenez-en plus sur les dépôts
gcr.io
.