Ce document vous présente les différences entre Container Registry et Artifact Registry lorsque vous créez des images de conteneur avec Cloud Build et que vous les déployez dans des environnements d'exécution Google Cloud tels que Cloud Run ou Google Kubernetes Engine.
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 les domaines 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 et les comptes de service par défaut ayant accès à Container Registry disposent d'autorisations par défaut équivalentes pour Artifact Registry.
Pour en savoir plus sur les différences entre Container Registry et Artifact Registry avec un client Docker, consultez la section Modifications apportées au transfert et à l'extraction avec Docker.
Ces informations vous aideront à adapter les commandes, la configuration ou la documentation existantes axées sur Container Registry avec Cloud Build.
Avant de commencer
Dans ce document, nous partons du principe que vous disposez des éléments suivants:
- Activez Artifact Registry dans votre projet.
- Activez l'API Cloud Build et l'API pour tout autre service Google Cloud que vous utilisez avec Artifact Registry.
Modifications apportées au workflow
Lorsque vous utilisez Cloud Build avec Container Registry dans le même projet, le workflow se présente comme suit:
Créez une image, ajoutez-lui un tag et transférez-la vers le dépôt avec Cloud Build à l'aide d'un
Dockerfile
ou d'un fichier de configuration de compilation.L'exemple suivant compile l'image
my-image
, lui ajoute un tagtag1
et la transmet à l'hôtegcr.io
dans le projetmy-project
:gcloud builds submit --tag gcr.io/my-project/my-image:tag1
Les environnements d'exécution Google Cloud, tels que Cloud Run et Google Kubernetes Engine, extraient des images du registre.
Par exemple, cette commande déploie l'image de l'étape précédente sur Cloud Run en tant que
my-service
.gcloud run deploy my-service --image gcr.io/my-project/my-image:tag1
Le workflow Container Registry combine des responsabilités d'administrateur avec la compilation et le déploiement.
- 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.
- Le compte de service Cloud Build dispose des autorisations nécessaires pour créer des buckets de stockage Cloud Storage. Cela signifie que le compte peut ajouter automatiquement des hôtes Container Registry à un projet la première fois qu'il envoie une image à l'hôte. Cela signifie également que le compte peut créer, lire et écrire dans des buckets de stockage pour l'ensemble du projet, y compris pour les buckets qui ne sont pas utilisés par Container Registry.
Dans Artifact Registry, il existe une séparation claire entre les rôles d'administrateur et de compilation, ce 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.
Modifié: compilez, ajoutez des tags et transférez une image vers le dépôt avec Cloud Build, à l'aide d'un fichier
Dockerfile
ou d'un fichier de configuration de compilation.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.
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Modifié: déployez l'image dans un environnement d'exécution Google Cloud tel que Cloud Run ou GKE.
L'exemple de commande suivant est identique à l'exemple de Container Registry, mais utilise le chemin d'accès au dépôt Artifact Registry pour l'image.
gcloud run deploy my-service --image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
De plus, Artifact Registry utilise des rôles différents de ceux de Container Registry pour contrôler l'accès aux images. Vous devez configurer des autorisations dans les situations suivantes:
- Les environnements d'exécution Cloud Build ou Google Cloud se trouvent dans un projet différent de celui d'Artifact Registry.
- Vous devez utiliser des comptes de service personnalisés pour les services Google Cloud tels que Cloud Build ou GKE au lieu des comptes de service par défaut.
- Vous avez accordé des autorisations à d'autres comptes utilisateur ou de service.
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
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. 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.
- 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.
Par défaut, Cloud Build dispose des autorisations requises pour créer un bucket de stockage. Par conséquent, le transfert de l'image initiale et les transferts ultérieurs ne sont pas différenciables.
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
Cloud Build ne dispose pas des autorisations nécessaires pour créer un dépôt standard sur le domaine Artifact Registry pkg.dev
.
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 :
- 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 standards sur le domaine
pkg.dev
. - Attribuez les rôles Artifact Registry appropriés aux autres comptes ayant accès à Artifact Registry.
- 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.
La comparaison suivante décrit les autorisations pour chaque service:
Container Registry
Container Registry utilise les rôles Cloud Storage pour contrôler les accès. Cloud Build dispose des autorisations requises dans le rôle "Administrateur de l'espace de stockage" pour ajouter des hôtes Container Registry à un projet.
- 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.
Cloud Build dispose d'autorisations dans le rôle "Rédacteur Artifact Registry", car il suffit de transférer et d'extraire des images avec des dépôts standards sur le domaine pkg.dev
.
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.
Créer et transférer des images
Points essentiels :
- Vous devez créer un dépôt Docker Artifact Registry avant d'y transférer une image.
- Les noms d'hôte Artifact Registry sont différents des noms d'hôte Container Registry.
Cloud Build peut créer une image, y ajouter des tags et la transférer en une seule étape.
Avec Container Registry, Cloud Build peut transférer une image vers un hôte de registre qui n'existe pas encore dans le projet Google Cloud. Pour ce transfert d'image initial, Cloud Build dispose des autorisations nécessaires pour ajouter automatiquement l'hôte de registre au projet.
Pour adapter un workflow Container Registry:
- Configurez vos dépôts avant de leur envoyer des images.
- Mettez à jour les chemins d'accès aux images dans votre fichier de configuration ou de compilation, ou dans vos commandes
gcloud builds submit
.
Compiler avec un fichier de configuration de compilation
Remplacez les chemins d'accès Container Registry des images que vous créez par ceux d'un dépôt Artifact Registry existant.
L'exemple de fichier cloudbuild.yaml
suivant crée l'image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
:
steps:
- name: 'gcr.io/cloud-builders/docker'
args: [ 'build', '-t', 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1'
Vous pouvez ensuite créer l'image à l'aide de la commande suivante:
gcloud builds submit --config cloudbuild.yaml
Compiler avec un fichier Dockerfile
Remplacez les chemins d'accès Container Registry des images que vous créez par ceux d'un dépôt Artifact Registry existant.
L'exemple de commande suivant compile l'image us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
avec un Dockerfile
dans le répertoire actuel:
gcloud builds submit --tag us-central1-docker.pkg.dev/my-project/my-repo/my-image:tag1
Déployer des images
Important:
- Les noms d'hôte Artifact Registry sont différents des noms d'hôte Container Registry.
Pour adapter un workflow Container Registry, mettez à jour les chemins d'accès des images dans votre configuration de déploiement et vos commandes de déploiement. Les sections suivantes présentent des exemples pour Cloud Build, Cloud Run et GKE, mais la même approche s'applique à tous les autres services Google Cloud qui déploient des images.
Cloud Build
Remplacez les chemins d'accès Container Registry des images que vous déployez par ceux d'un dépôt Artifact Registry existant.
L'exemple de fichier cloudbuild.yaml
suivant déploie l'exemple d'image us-docker.pkg.dev/cloudrun/container/hello
.
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args:
- 'run'
- 'deploy'
- 'cloudrunservice'
- '--image'
- 'us-docker.pkg.dev/cloudrun/container/hello'
- '--region'
- 'us-central1'
- '--platform'
- 'managed'
- '--allow-unauthenticated'
Cloud Run
Remplacez les chemins d'accès Container Registry des images que vous déployez par ceux d'un dépôt Artifact Registry existant.
Par exemple, cette commande déploie l'exemple d'image us-docker.pkg.dev/cloudrun/container/hello
.
gcloud run deploy my-service --image us-docker.pkg.dev/cloudrun/container/hello
GKE
Remplacez les chemins d'accès Container Registry des images que vous créez par ceux d'un dépôt Artifact Registry existant.
Les exemples suivants pour Artifact Registry utilisent l'exemple d'image us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0
.
Créez un cluster à partir de la ligne de commande:
kubectl create deployment hello-server --image=us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0
Spécifier une image dans un fichier manifeste de déploiement:
In a deployment manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
run: my-app
template:
metadata:
labels:
run: my-app
spec:
containers:
- name: hello-app
image: us-docker.pkg.dev/artifact-registry-samples/containers/gke/hello-app:1.0