Ce document vous présente les différences entre Container Registry et Artifact Registry pour l'authentification, le transfert et l'extraction d'images de conteneurs avec Docker.
Dans ce guide, les comparaisons portent sur les dépôts Artifact Registry standards et les dépôts Artifact Registry standards qui sont indépendants de Container Registry et sont compatibles avec toutes les fonctionnalités d'Artifact Registry.
Si votre administrateur a configuré des dépôts compatibles avec le domaine gcr.io, les requêtes adressées aux noms d'hôte gcr.io
sont automatiquement redirigées vers un dépôt Artifact Registry correspondant. Pour utiliser un dépôt gcr.io hébergé sur Artifact Registry, vous devez disposer d'un rôle Artifact Registry approprié ou d'un rôle doté d'autorisations équivalentes.
Pour en savoir plus sur les différences entre Container Registry et Artifact Registry lors de la compilation avec Cloud Build et du déploiement sur Cloud Run ou Google Kubernetes Engine, consultez la page Modifications pour Cloud Build, Cloud Run et GKE.
Utilisez ces informations pour vous aider à adapter les commandes, la configuration ou la documentation existantes axées sur Container Registry avec Docker.
Avant de commencer
Dans ce document, nous partons du principe que vous disposez des éléments suivants:
- Activez Artifact Registry dans votre projet.
- Vous avez installé Docker. Docker est inclus dans Cloud Shell.
Présentation
De manière générale, le workflow d'utilisation de Docker avec Container Registry ou Artifact Registry est le même.
Container Registry | Artifact Registry |
---|---|
Administrateur
|
Administrateur
|
Utilisateurs du registre
|
Utilisateurs du registre
|
Cependant, un raccourci pour Container Registry combine les rôles d'administrateur et d'utilisateur en un seul workflow. Ce raccourci est courant dans:
- Guides de démarrage rapide et tutoriels pour effectuer des tests dans un environnement disposant d'autorisations étendues
- Workflows qui utilisent Cloud Build, car le compte de service Cloud Build dispose des autorisations nécessaires pour ajouter un hôte de registre dans le même projet Google Cloud.
Voici à quoi ressemble la procédure de création des raccourcis:
- Activer l'API Container Registry.
- Accordez des autorisations au compte qui accédera à Container Registry.
Authentifiez-vous auprès du registre. L'option d'authentification la plus simple consiste à utiliser l'assistant d'identification Docker dans Google Cloud CLI. Il s'agit d'une étape de configuration unique.
gcloud auth configure-docker
Créez l'image et ajoutez-y un tag. Par exemple, cette commande crée l'image
gcr.io/my-project/my-image:tag1
et lui ajoute un tag:docker build -t gcr.io/my-project/my-image:tag1
Transférez l'image vers le registre. Exemple :
docker push gcr.io/my-project/my-image:tag1
Si l'hôte de registre
gcr.io
n'existe pas dans le projet, Container Registry l'ajoute avant d'importer l'image.Extrayez l'image du registre ou déployez-la dans un environnement d'exécution Google Cloud. Exemple :
docker pull gcr.io/my-project/my-image:tag1
Ce workflow repose sur les raccourcis suivants:
- Le compte qui transfère des images dispose du rôle "Administrateur de l'espace de stockage" ou d'un rôle disposant des mêmes autorisations, par exemple "Propriétaire". Les autorisations étendues de ce rôle autorisent un accès en lecture et en écriture à tous les buckets de stockage d'un projet, y compris aux buckets qui ne sont pas utilisés par Container Registry.
- Lorsque vous activez certaines API Google Cloud, l'API Container Registry est activée automatiquement. Cela signifie que les utilisateurs de ces services ont un accès implicite à Container Registry dans le même projet. Par exemple, les utilisateurs autorisés à exécuter des compilations dans Cloud Build peuvent transférer des images dans des registres et ajouter des hôtes de registre par défaut.
Dans Artifact Registry, il existe une séparation claire entre les rôles Administrateur et Utilisateur de dépôt, qui modifie les étapes du workflow de compilation et de déploiement. Pour adapter le workflow Container Registry à Artifact Registry, apportez les modifications suivantes. Chaque étape renvoie vers des informations supplémentaires sur la modification du workflow.
Nouveau: activez l'API Artifact Registry.
Vous devez activer l'API Artifact Registry. Les environnements Cloud Build et d'exécution tels que Cloud Run et GKE n'activent pas automatiquement l'API pour vous.
Nouveau: créez le dépôt Docker cible s'il n'existe pas déjà. Vous devez créer un dépôt avant de pouvoir y transférer des images. Le transfert d'une image ne peut pas déclencher la création d'un dépôt et le compte de service Cloud Build ne dispose pas des autorisations nécessaires pour créer des dépôts.
Accordez des autorisations au compte qui interagira avec Artifact Registry.
Modifié: authentifiez-vous auprès du dépôt. Si vous utilisez l'assistant d'identification dans gcloud CLI, vous devez spécifier les hôtes que vous souhaitez ajouter à la configuration de votre client Docker. Par exemple, cette commande ajoute l'hôte
us-central1-docker.pkg.dev
:gcloud auth configure-docker us-central1-docker.pkg.dev
Modifié: créez l'image et ajoutez-lui un tag.
L'exemple de commande suivant est identique à l'exemple de Container Registry, mais utilise un chemin de dépôt Artifact Registry pour l'image.
docker build -t us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Modifié: transférez l'image vers le dépôt à l'aide du chemin d'accès Artifact Registry. Exemple :
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Modifié: extrayez l'image du dépôt à l'aide du chemin d'accès Artifact Registry. Exemple :
docker pull us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Activer l'API
Points essentiels :
- Vous devez activer l'API Artifact Registry en plus de l'API pour d'autres services Google Cloud tels que Cloud Build, Cloud Run et GKE.
La comparaison suivante décrit l'activation de l'API pour chaque service:
Container Registry
Vous devez activer l'API Container Registry avant d'utiliser Docker ou d'autres clients tiers avec Container Registry.
Lorsque vous activez les API Google Cloud suivantes, l'API Container Registry est également activée automatiquement:
- Environnement flexible App Engine
- Cloud Build
- Cloud Functions
- Cloud Run
- Analyse de conteneurs ou analyse à la demande dans Artifact Analysis
- Google Kubernetes Engine
Avec les autorisations par défaut, les utilisateurs autorisés à exécuter des compilations dans Cloud Build, à analyser des conteneurs avec Artifact Analysis ou à déployer des conteneurs sur des environnements d'exécution Google Cloud ont implicitement accès aux images de Container Registry lorsque le registre se trouve dans le même projet.
Artifact Registry
Vous devez activer l'API Artifact Registry avant d'utiliser des clients Docker ou d'autres services Google Cloud avec Artifact Registry.
Les services tels que Cloud Build, Cloud Run et GKE n'activent pas automatiquement l'API Artifact Registry.
Vous pouvez activer plusieurs API dans le même projet à l'aide de gcloud. Par exemple, pour activer les API Cloud Build et Artifact Registry, exécutez la commande suivante:
gcloud services enable
artifactregistry.googleapis.com \
cloudbuild.googleapis.com
Ajouter des registres et des dépôts
Points essentiels :
Vous devez créer un dépôt Docker Artifact Registry avant d'y transférer une image.
Les étapes de création d'un registre sont souvent exclues dans la documentation qui explique comment transférer des images vers Container Registry, car un compte disposant des autorisations d'administrateur de l'espace de stockage peut ajouter un registre à un projet avec le transfert initial vers l'hôte du registre.
Container Registry stocke toutes les images dans une seule zone multirégionale du même bucket de stockage. Dans Artifact Registry, vous pouvez créer plusieurs dépôts dans la même région ou un emplacement multirégional avec des règles d'accès distinctes.
La comparaison suivante décrit la configuration du dépôt dans chaque service:
Container Registry
Dans Container Registry, vous pouvez ajouter jusqu'à quatre hôtes de registre à votre projet. Pour ajouter un hôte de registre, vous devez transférer la première image.
Pour ajouter un registre tel que
gcr.io
à votre projet, un compte doté du rôle "Administrateur de l'espace de stockage" au niveau du projet transfère une image initiale.Par exemple, si l'hôte
gcr.io
n'existe pas dans le projetmy-project
, le transfert de l'imagegcr.io/my-project/my-image:1.0
déclenche les étapes suivantes:- Ajouter l'hôte
gcr.io
au projet - Créez un bucket de stockage pour
gcr.io
dans le projet. - Stocker l'image en tant que
gcr.io/my-project/my-image:1.0
- Ajouter l'hôte
Après ce transfert initial, vous pouvez accorder des autorisations sur le bucket de stockage pour d'autres utilisateurs.
Dans un projet, un hôte de registre stocke toutes les images dans le même bucket de stockage. Dans l'exemple suivant, le projet my-project
comporte deux images appelées web-app
dans le registre gcr.io
. L'un d'eux se trouve directement sous l'ID du projet : my-project
. L'autre image se trouve dans le dépôt team1
.
gcr.io/my-project/web-app
gcr.io/my-project/team1/web-app
Artifact Registry
Un compte doté du rôle Administrateur de dépôt Artifact Registry doit créer le dépôt avant d'y envoyer des images. Vous pouvez ensuite accorder des autorisations sur le dépôt à d'autres utilisateurs.
Dans Artifact Registry, chaque dépôt est une ressource distincte. Par conséquent, tous les chemins d'accès aux images doivent inclure un dépôt.
Chemins d'accès des images valides:
us-central1-docker.pkg.dev/my-project/team1/web-app:1.0
us-central1-docker.pkg.dev/my-project/team2/web-app:1.0
Chemin d'accès de l'image incorrect (ne comprend pas de dépôt) :
us-central1-docker.pkg.dev/my-project/web-app:1.0
Les exemples suivants illustrent les situations dans lesquelles le transfert d'une image vers un dépôt manquant échoue.
- Transférer une image vers
us-central1-docker.pkg.dev/my-project/team1
sius-central1-docker.pkg.dev/my-project/team1
n'existe pas. - Transfert d'une image vers
us-central1-docker.pkg.dev/my-project/team2
alors queus-central1-docker.pkg.dev/my-project/team1
existe, mais queus-central1-docker.pkg.dev/my-project/team2
n'existe pas.
Accord d'autorisations...
Points essentiels :
- Attribuez le rôle Artifact Registry approprié au compte que vous utilisez avec Artifact Registry.
- Les services Google Cloud disposent d'un accès en lecture ou en écriture équivalent à Container Registry et Artifact Registry. Toutefois, le compte de service Cloud Build par défaut ne peut pas créer de dépôts.
- Container Registry permet de contrôle des accès au niveau du bucket de stockage. Artifact Registry permet de contrôle des accès au niveau du dépôt.
Le tableau comparatif suivant décrit la configuration des autorisations dans chaque service:
Container Registry
Container Registry utilise les rôles Cloud Storage pour contrôler les accès.
- Lecteur des objets Storage au niveau du bucket de stockage
- Extraire (lire) des images à partir d'hôtes de registre existants dans le projet
- Rédacteur des anciens buckets Storage au niveau du bucket de stockage
- Transférer (écrire) et extraire (lire) des images pour les hôtes de registre existants dans le projet.
- Administrateur de l'espace de stockage au niveau du projet
- Ajoutez un hôte de registre à un projet en envoyant une image initiale à l'hôte.
Une fois l'image initiale transférée vers un registre, vous attribuez des rôles Cloud Storage aux autres comptes nécessitant un accès au bucket de stockage. Notez que tout compte disposant de toutes les autorisations du rôle "Administrateur de l'espace de stockage" peut lire, écrire et supprimer des buckets de stockage et des objets de stockage dans l'ensemble du projet.
Les autorisations d'un bucket de stockage s'appliquent à tous les dépôts du registre.
Par exemple, tout utilisateur disposant des autorisations de lecteur des objets Storage sur le bucket pour gcr.io/my-project
peut lire des images dans tous ces dépôts:
gcr.io/my-project/team1
gcr.io/my-project/team2
gcr.io/my-project/test
gcr.io/my-project/production
Artifact Registry
Artifact Registry dispose de ses propres rôles pour contrôler les accès. Ces rôles séparent clairement les rôles administrateur et utilisateur de dépôt.
Seuls les comptes qui gèrent des dépôts doivent disposer du rôle Administrateur de dépôt Artifact Registry ou Administrateur Artifact Registry.
- Lecteur Artifact Registry
- Répertorier les artefacts et les dépôts Téléchargez les artefacts.
- Rédacteur Artifact Registry
- Répertorier les artefacts et les dépôts Téléchargez des artefacts, importez de nouvelles versions d'artefact, et ajoutez ou mettez à jour des balises.
- Administrateur de dépôts Artifact Registry
- Autorisations "Rédacteur Artifact Registry" et autorisations de suppression d'artefacts et de tags.
- Administrateur Artifact Registry
- Autorisations et autorisations d'administrateur de dépôts Artifact Registry pour créer, mettre à jour, supprimer et accorder des autorisations aux dépôts.
Vous pouvez appliquer ces autorisations au niveau du dépôt. Exemple :
- Accorder l'accès à l'équipe 1 pour
us-central1-docker.pkg.dev/my-project/team1
- Accordez à l'équipe 2 l'accès pour
us-central1-docker.pkg.dev/my-project/team2
.
Pour en savoir plus sur l'attribution d'autorisations à Artifact Registry, consultez la documentation sur le contrôle des accès.
Authentification auprès du registre
Points essentiels :
- Artifact Registry est compatible avec les mêmes méthodes d'authentification que Container Registry.
- Pour l'assistant d'identification Docker, vous devez spécifier les hôtes à ajouter à la configuration du client Docker.
- Pour l'authentification à l'aide de
docker login
, utilisez l'hôte Artifact Registry au lieu d'un hôte Container Registry.
Utiliser l'assistant d'identification
Par défaut, la commande gcloud auth configure-docker
et l'assistant d'identification autonome configurent Docker uniquement pour les noms d'hôte *.gcr.io
. Pour Artifact Registry, vous devez spécifier la liste des hôtes Artifact Registry que vous souhaitez ajouter à la configuration du client Docker.
Par exemple, pour configurer l'authentification auprès des dépôts Docker dans la région us-central1
, exécutez la commande suivante:
gcloud auth configure-docker us-central1-docker.pkg.dev
Si vous ajoutez ultérieurement des dépôts dans us-east1
et asia-east1
, vous devez réexécuter la commande pour ajouter les noms d'hôte régionaux correspondants à votre configuration Docker.
gcloud auth configure-docker us-east-docker.pkg.dev,asia-east1-docker.pkg.dev
Pour en savoir plus sur les méthodes d'authentification Artifact Registry, consultez la section Configurer l'authentification pour Docker.
Utiliser l'authentification par mot de passe
Lorsque vous vous connectez à Docker, utilisez le nom d'hôte Artifact Registry au lieu d'un nom d'hôte *.gcr.io
. L'exemple suivant illustre l'authentification auprès de l'hôte us-central1-docker.pkg.dev
avec une clé de compte de service encodée en base64:
cat key.json | docker login -u _json_key_base64 --password-stdin \
https://us-central1-docker.pkg.dev
Créer des images et y ajouter des tags
Points clés : - Artifact Registry utilise un nom d'hôte différent pour les dépôts.
Lorsque vous taguez une image, utilisez le chemin d'accès à Artifact Registry au lieu du chemin d'accès Container Registry. Exemple :
docker tag my-image us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
Transférer des images vers le registre
Points clés : - Dans Artifact Registry, le dépôt cible doit exister avant d'y transférer une image. - Artifact Registry utilise un nom d'hôte différent pour les dépôts.
Lorsque vous transférez une image, utilisez le chemin d'accès à Artifact Registry au lieu du chemin d'accès Container Registry. Exemple :
docker push us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
Extraire des images du registre
Important:
- Les noms d'hôte Artifact Registry sont différents des noms d'hôte Container Registry.
Lorsque vous extrayez une image, utilisez le chemin d'accès à Artifact Registry au lieu du chemin d'accès Container Registry. Exemple :
docker pull us-central1-docker.pkg.dev/my-project/my-repo/my-image:1.0
Pour obtenir des exemples de déploiement d'images dans des environnements d'exécution Google Cloud tels que Cloud Run et GKE, consultez la page Déployer des images.