Modifications pour la création et le déploiement dans Google Cloud

Ce document vous explique les différences entre Container Registry et Artifact Registry lorsque vous créez des images de conteneur avec Cloud Build et les déployez dans des environnements d'exécution tels que Cloud Run ou Google Kubernetes Engine. Google Cloud

Dans ce guide, les comparaisons portent sur les dépôts Artifact Registry standards, qui sont des dépôts Artifact Registry standards indépendants de Container Registry et compatibles avec toutes les fonctionnalités d'Artifact Registry. Si votre administrateur a configuré des dépôts avec prise en charge du domaine gcr.io, les requêtes envoyé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 à l'aide d'un client Docker, consultez la page Modifications apportées à l'importation et à l'exportation avec Docker.

Utilisez ces informations pour vous aider à adapter les commandes, la configuration ou la documentation existantes axées sur Container Registry avec Cloud Build.

Avant de commencer

Ce document suppose que vous disposez des éléments suivants:

1. Vous avez activé Artifact Registry dans votre projet.
2. Activez l'API Cloud Build et l'API de tout autre Google Cloud service 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:

1. Créez, ajoutez un tag 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 suivant crée l'image my-image, la tague avec tag1 et la transfère à l'hôte gcr.io dans le projet my-project:

   gcloud builds submit --tag gcr.io/my-project/my-image:tag1
   

2. Les environnements d'exécutionGoogle 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 les responsabilités de l'administrateur avec la création et le déploiement.

• Lorsque vous activez certaines Google Cloud API, l'API Container Registry est automatiquement activée. 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 vers des dépôts et ajouter des hôtes de dépôt par défaut.
• Le compte de service Cloud Build dispose des autorisations nécessaires pour créer des buckets Cloud Storage. Cela signifie que le compte peut ajouter automatiquement des hôtes Container Registry à un projet la première fois qu'il transfère une image vers l'hôte. Cela signifie également que le compte peut créer, lire et écrire dans des buckets de stockage dans l'ensemble du projet, y compris les buckets qui ne sont pas utilisés par Container Registry.

Dans Artifact Registry, la séparation claire des rôles d'administrateur et de compilation modifie les étapes du workflow de compilation et de déploiement. Pour adapter le workflow Container Registry à Artifact Registry, effectuez les modifications suivantes. Chaque étape renvoie à des informations supplémentaires sur la modification du workflow.

1. Nouveau: activez l'API Artifact Registry.

   Vous devez activer l'API Artifact Registry. Cloud Build et les environnements d'exécution tels que Cloud Run et GKE n'activent pas automatiquement l'API pour vous.

2. Nouveau: créez le dépôt Docker cible s'il n'existe pas déjà. Vous devez créer un dépôt pour 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.

3. Modifié: compilez, ajoutez un tag et transmettez une image au dépôt avec Cloud Build, à l'aide d'un fichier Dockerfile ou de configuration de compilation.

   L'exemple de commande suivant est identique à celui de Container Registry, mais utilise un chemin d'accès 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
   

4. Modifié: déployez l'image dans un Google Cloud environnement d'exécution tel que Cloud Run ou GKE.

   L'exemple de commande suivant est identique à celui de Container Registry, mais utilise le chemin d'accès du 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 cas suivants:

• Les environnements d'exécution ou Cloud Build se trouvent dans un projet différent d'Artifact Registry. Google Cloud
• Vous utilisez des comptes de service personnalisés pour Google Cloud des services 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 Google Cloud services 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 Run Functions
• Cloud Run
• Analyse des conteneurs ou analyse à la demande dans l'analyse des artefacts
• Google Kubernetes Engine

Avec les autorisations par défaut, les utilisateurs autorisés à exécuter des builds dans Cloud Build, à analyser des conteneurs avec Artifact Analysis ou à déployer des conteneurs dans des environnements d'exécutionGoogle 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 l'API Cloud Build et l'API 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 de transférer une image vers celui-ci.
• Container Registry stocke toutes les images dans une seule région multirégionale dans le même bucket de stockage. Dans Artifact Registry, vous pouvez créer plusieurs dépôts dans la même région ou dans plusieurs régions avec des règles d'accès distinctes.

La comparaison suivante décrit la configuration des dépôts 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, transférez la première image.

1. Pour ajouter un registre tel que gcr.io à votre projet, un compte disposant du rôle "Administrateur de l'espace de stockage" au niveau du projet envoie une image initiale.

   Par exemple, si l'hôte gcr.io n'existe pas dans le projet my-project, le transfert de l'image gcr.io/my-project/my-image:1.0 déclenche les étapes suivantes:

   1. Ajouter l'hôte gcr.io au projet
   2. Créez un bucket de stockage pour gcr.io dans le projet.
   3. Stocker l'image en tant que gcr.io/my-project/my-image:1.0

2. Après ce transfert initial, vous pouvez accorder des autorisations au 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, l'envoi initial de l'image et les envois suivants sont indiscernables.

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'une se trouve directement sous l'ID de 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 n'est pas autorisé à créer un dépôt standard sur le domaine pkg.dev d'Artifact Registry.

Un compte disposant du rôle Administrateur du dépôt Artifact Registry doit créer le dépôt avant de pouvoir y transférer des images. Vous pouvez ensuite accorder des autorisations au dépôt pour 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 aux 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 à l'image non valide (ne comprend pas de dépôt) :

us-central1-docker.pkg.dev/my-project/web-app:1.0

Les exemples suivants montrent des situations où le transfert d'une image vers un dépôt manquant échoue.

• Transfert d'une image vers us-central1-docker.pkg.dev/my-project/team1 si us-central1-docker.pkg.dev/my-project/team1 n'existe pas.
• Transfert d'une image vers us-central1-docker.pkg.dev/my-project/team2 lorsque us-central1-docker.pkg.dev/my-project/team1 existe, mais que us-central1-docker.pkg.dev/my-project/team2 n'existe pas.

Accord d'autorisations...

Points essentiels :

• Les servicesGoogle 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 qui accèdent à Artifact Registry.
• Container Registry prend en charge le contrôle des accès au niveau du bucket de stockage. Artifact Registry est compatible avec le contrôle des accès au niveau du dépôt.

Le tableau suivant décrit les autorisations pour chaque service:

Container Registry

Container Registry utilise les rôles Cloud Storage pour contrôler l'accès. Cloud Build dispose des autorisations requises dans le rôle d'administrateur Storage pour ajouter des hôtes Container Registry à un projet.

Lecteur des objets Storage au niveau du bucket de stockage

Extrayez (lisez) des images à partir des hôtes de registre existants du projet.

Rédacteur des anciens buckets de l'espace de stockage au niveau du bucket de stockage

Transférez (écriture) et extrayez (lecture) des images pour les hôtes de registre existants du projet.

Administrateur de l'espace de stockage au niveau du projet

Ajoutez un hôte de registre à un projet en transmettant une image initiale à l'hôte.

Après l'envoi initial de l'image vers un registre, vous accordez des rôles Cloud Storage aux autres comptes qui ont besoin d'accéder au bucket de stockage. Notez que tout compte disposant de toutes les autorisations du rôle "Storage Admin" peut lire, écrire et supprimer des buckets 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 référentiel. Par exemple, tout utilisateur disposant d'autorisations de lecteur des objets Storage sur le bucket pour gcr.io/my-project peut lire les images de 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 l'accès. Ces rôles permettent de séparer clairement les rôles d'administrateur et d'utilisateur de dépôt.

Cloud Build dispose des autorisations du rôle "Écrivain Artifact Registry", car il ne doit transférer et extraire que 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ôts Artifact Registry" ou "Administrateur Artifact Registry".

Lecteur Artifact Registry

Répertoriez les artefacts et les dépôts. Téléchargez les artefacts.

Rédacteur Artifact Registry

Répertoriez les artefacts et les dépôts. Téléchargez des artefacts, importez de nouvelles versions d'artefacts et ajoutez ou mettez à jour des balises.

Administrateur de dépôts Artifact Registry

Autorisations Artifact Registry Writer et autorisations de supprimer des artefacts et des tags.

Administrateur Artifact Registry

Autorisations d'administrateur de dépôt Artifact Registry et autorisations de 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 à us-central1-docker.pkg.dev/my-project/team1 à l'équipe 1
• Accordez l'accès à us-central1-docker.pkg.dev/my-project/team2 à l'équipe 2.

Pour en savoir plus sur l'octroi 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 de transférer une image vers celui-ci.
• Les noms d'hôte Artifact Registry sont différents des noms d'hôte Container Registry.

Cloud Build peut créer, taguer et transférer une image 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 est autorisé à ajouter automatiquement l'hôte du registre au projet.

Pour adapter un workflow Container Registry:

1. Configurez vos dépôts avant de les transférer.
2. Mettez à jour les chemins d'accès aux images dans votre fichier de configuration de compilation ou 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 le chemin d'accès à 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 avec 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 le chemin d'accès à un dépôt Artifact Registry existant.

L'exemple de commande suivant crée 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

Point essentiel:

• 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'image 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 Google Cloud services qui déploient des images.

Cloud Build

Remplacez les chemins d'accès Container Registry des images que vous déployez par le chemin d'accès à 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 le chemin d'accès à 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 le chemin d'accès à un dépôt Artifact Registry existant.

Les exemples suivants pour Artifact Registry utilisent l'exemple d'image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0.

Créer un cluster à partir de la ligne de commande:

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-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/google-samples/containers/gke/hello-app:1.0