Livraison continue de type GitOps avec Cloud Build

---

Cette page explique comment créer un pipeline d'intégration et de livraison continues (CI/CD) sur Google Cloud en n'utilisant que des produits hébergés et la méthodologie bien connue GitOps.

Les ingénieurs Google stockent les fichiers de configuration et de déploiement dans notre dépôt de code source principal depuis très longtemps. Cette méthodologie est décrite dans le chapitre 8 du livre Site Reliability Engineering (Beyer et. al., 2016). Kelsey Hightower en a fait la démonstration lors du discours d'ouverture de Google Cloud Next '17.

L'un des éléments clés de GitOps est le concept des "Environnements en tant que code" : cette approche permet de décrire les déploiements de manière déclarative à l'aide de fichiers (par exemple, des manifestes Kubernetes) stockés dans un dépôt Git.

Dans ce tutoriel, vous allez créer un pipeline CI/CD qui compile automatiquement une image de conteneur à partir d'un code validé, stocke l'image dans Artifact Registry, met à jour un manifeste Kubernetes dans un dépôt Git, puis déploie l'application sur Google Kubernetes Engine (GKE) à l'aide de ce manifeste.

Ce tutoriel utilise deux dépôts Git :

• dépôt de l'application (app) : contient le code source de l'application
• dépôt de l'environnement (env) : contient les manifestes pour le déploiement Kubernetes

Lorsque vous déployez une modification dans le dépôt app, le pipeline Cloud Build exécute des tests, compile une image de conteneur, puis déploie cette image sur Artifact Registry. Après avoir déployé l'image, Cloud Build met à jour le manifeste de déploiement et le transfère vers le dépôt env. Cette opération déclenche un autre pipeline Cloud Build, qui applique le manifeste au cluster GKE et, en cas de succès, le stocke dans une autre branche du dépôt env.

Nous gardons les dépôts app et env séparés, car leur utilisation et leur cycle de vie diffèrent. Les principaux utilisateurs du dépôt app sont des humains et ce dépôt est dédié à une application spécifique. Les principaux utilisateurs du dépôt env sont des systèmes automatisés (comme Cloud Build), et ce dépôt peut être partagé par plusieurs applications. Le dépôt env peut contenir plusieurs branches, chacune d'entre elles correspondant à un environnement spécifique (vous n'utiliserez que l'environnement de production dans ce tutoriel) et faisant référence à une image de conteneur spécifique, ce qui n'est pas le cas avec le dépôt env.

Une fois ce tutoriel terminé, vous disposerez d'un système dans lequel vous pourrez facilement :

• distinguer les déploiements en échec des déploiements réussis en consultant l'historique de Cloud Build ;
• accéder au manifeste actuellement utilisé en consultant la branche production du dépôt env ;
• revenir à n'importe quelle version précédente en exécutant une nouvelle fois la compilation Cloud Build correspondante.

À propos de ce tutoriel

Ce tutoriel utilise Cloud Source Repositories pour héberger des dépôts Git, mais vous pouvez obtenir les mêmes résultats avec des produits tiers, tels que GitHub, Bitbucket ou GitLab.

Ce pipeline ne met pas en œuvre de mécanisme de validation avant le déploiement. Si vous utilisez GitHub, Bitbucket ou GitLab, vous pouvez le modifier pour qu'il utilise une demande d'extraction à cette fin.

Bien que nous recommandions Spinnaker aux équipes souhaitant mettre en œuvre des schémas de déploiement avancés (bleu-vert, analyse Canary, multicloud, etc.), ses fonctionnalités ne sont pas vraiment indispensables au succès d'une stratégie CI/CD pour les petites entreprises et les projets de moindre envergure. Dans ce tutoriel, vous allez apprendre à créer un pipeline CI/CD adapté aux applications hébergées sur GKE à l'aide d'outils.

Pour des raisons de simplicité, ce tutoriel utilise un seul environnement (production) dans le dépôt env, mais vous pouvez étendre le déploiement sur plusieurs environnements si nécessaire.

Objectifs

• Créer les dépôts Git dans Cloud Source Repositories
• Créer une image de conteneur avec Cloud Build et la stocker dans Artifact Registry
• Créer un pipeline CI
• Créer un pipeline CD
• Tester le pipeline CI/CD

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• GKE
• Cloud Source Repositories
• Artifact Registry
• Cloud Build

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

1. Sélectionnez ou créez un projet Google Cloud.

   Accéder à la page Gérer les ressources

2. Activez la facturation pour votre projet.

   Activer la facturation

3. Ouvrez Cloud Shell pour exécuter les commandes répertoriées dans ce tutoriel. Cloud Shell est un environnement shell interactif pour Google Cloud qui vous permet de gérer vos projets et vos ressources depuis un navigateur Web.

   Accéder à Cloud Shell

4. Si la commande gcloud config get-value project ne renvoie pas l'ID du projet que vous avez sélectionné, configurez Cloud Shell pour utiliser votre projet.

   gcloud config set project [PROJECT_ID]
   

5. Dans Cloud Shell, activez les API nécessaires.

   gcloud services enable container.googleapis.com \
       cloudbuild.googleapis.com \
       sourcerepo.googleapis.com \
       artifactregistry.googleapis.com
   

6. Créez un dépôt Docker Artifact Registry nommé my-repository dans la région us-central1 pour stocker vos images de conteneurs.

   gcloud artifacts repositories create my-repository \
     --repository-format=docker \
     --location=us-central1
   

7. Dans Cloud Shell, créez un cluster GKE que vous utiliserez pour déployer l'exemple d'application de ce tutoriel.

   Autopilot

   Créez un cluster Autopilot nommé hello-cloudbuild :

   gcloud container clusters create-auto hello-cloudbuild \
       --region us-central1
   

   Standard

   Créez un cluster standard à nœud unique nommé hello-cloudbuild :

   gcloud container clusters create hello-cloudbuild \
       --num-nodes 1 --region us-central1
   

8. Si vous n'avez jamais utilisé Git dans Cloud Shell, configurez-le avec votre nom et votre adresse e-mail. Git les utilisera pour vous identifier en tant qu'auteur des commits que vous créerez dans Cloud Shell.

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

Une fois que vous avez terminé ce tutoriel, évitez de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Créer les dépôts Git dans Cloud Source Repositories

Dans cette section, vous allez créer les deux dépôts Git (app et env) utilisés dans ce tutoriel, puis initialiser l'application avec un exemple de code.

1. Dans Cloud Shell, créez les deux dépôts Git.

   gcloud source repos create hello-cloudbuild-app
   gcloud source repos create hello-cloudbuild-env
   

2. Clonez l'exemple de code depuis GitHub.

   cd ~
   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   

3. Configurez Cloud Source Repositories en tant que dépôt distant.

   PROJECT_ID=$(gcloud config get-value project)
   git remote add google \
       "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"
   

Le code que vous avez cloné contient une application "Hello World".

from flask import Flask
app = Flask('hello-cloudbuild')

@app.route('/')
def hello():
  return "Hello World!\n"

if __name__ == '__main__':
  app.run(host = '0.0.0.0', port = 8080)

Créer une image de conteneur avec Cloud Build

Le code que vous avez cloné contient le fichier Dockerfile suivant :

FROM python:3.7-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]

Vous pouvez utiliser ce fichier Dockerfile pour créer une image de conteneur avec Cloud Build, puis stocker cette image dans Artifact Registry.

1. Dans Cloud Shell, créez une compilation Cloud Build basée sur le dernier commit à l'aide de la commande suivante :

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   COMMIT_ID="$(git rev-parse --short=7 HEAD)"
   gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
   

   Cloud Build diffuse les journaux générés par la création de l'image de conteneur sur votre terminal lorsque vous exécutez cette commande.

2. Une fois la compilation achevée, vérifiez que votre nouvelle image de conteneur est disponible dans Artifact Registry.

   Accéder à Artifact Registry

   

Créer le pipeline d'intégration continue

Dans cette section, vous allez configurer Cloud Build afin qu'il exécute automatiquement un petit test unitaire, qu'il génère l'image de conteneur, puis qu'il déploie cette dernière sur Artifact Registry. L'envoi d'un nouveau commit vers Cloud Source Repositories déclenche automatiquement ce pipeline. Le fichier cloudbuild.yaml (inclus dans le code) correspond à la configuration du pipeline.

steps:
# This step runs the unit tests on the app
- name: 'python:3.12-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'

1. Accédez à la page Déclencheurs de Cloud Build.

   Accéder à la page "Déclencheurs"

2. Cliquez sur Créer un déclencheur.

3. Indiquez les options suivantes :

   • Dans le champ Nom, saisissez hello-cloudbuild.
   • Sous Événement, sélectionnez Déployer sur une branche.
   • Sous Source, sélectionnez le dépôt hello-cloudbuild-app et la branche ^master$.
   • Sous Configuration de la compilation, sélectionnez Fichier de configuration Cloud Build.
   • Dans le champ Emplacement du fichier de configuration Cloud Build, saisissez cloudbuild.yaml après /.

4. Cliquez sur Créer pour enregistrer le déclencheur de compilation.

   Conseil : Si vous devez créer des déclencheurs de compilation pour de nombreux projets, vous pouvez utiliser l'API Build Triggers.

5. Dans Cloud Shell, transférez le code de l'application vers Cloud Source Repositories pour déclencher le pipeline d'intégration continue (CI) dans Cloud Build.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git push google master
   

6. Ouvrez la console Cloud Build.

   Accéder à Cloud Build

   Les compilations récemment exécutées et terminées s'affichent. Vous pouvez cliquer sur une compilation pour suivre son exécution et examiner ses journaux.

Créer le pipeline de livraison continue

Cloud Build est également utilisé pour le pipeline de livraison continue. Le pipeline s'exécute chaque fois qu'un commit (validation) est déployé sur la branche candidate du dépôt hello-cloudbuild-env. Le pipeline applique la nouvelle version du manifeste au cluster Kubernetes et, en cas de succès, copie le manifeste dans la branche production. Ce processus a les propriétés suivantes :

• La branche candidate correspond à l'historique des tentatives de déploiement.
• La branche production correspond à l'historique des déploiements réussis.
• Dans Cloud Build, une vue permet d'identifier les déploiements réussis et en échec.
• Vous pouvez restaurer n'importe quel déploiement antérieur (opération de "rollback") en exécutant à nouveau la compilation correspondante dans Cloud Build. Lors d'un rollback, la branche production est également mise à jour afin de refléter fidèlement l'historique des déploiements.

Dans cette étape, vous allez modifier le pipeline d'intégration continue pour mettre à jour la branche candidate du dépôt hello-cloudbuild-env, ce qui entraînera le déclenchement du pipeline de livraison continue.

Remarque : Vous pouvez étendre le système décrit dans ce tutoriel pour gérer plusieurs environnements. Pour ce faire, le moyen le plus simple consiste à avoir une paire de branches pour chaque environnement env : une branche env et une branche env.

Autoriser Cloud Build à accéder à GKE

Pour déployer l'application dans votre cluster Kubernetes, Cloud Build a besoin du rôle Identity and Access Management de développeur Kubernetes Engine.

Shell

Dans Cloud Shell, exécutez la commande suivante :

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')"
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

Console

1. Dans Google Cloud Console, accédez à la page Paramètres de Cloud Build :

   Accéder à la page Paramètres de Cloud Build

   La page Autorisations de compte de service s'affiche :

   

2. Passez le rôle de Développeur sur Kubernetes Engine à l'état Activé.

Initialiser le dépôt hello-cloudbuild-env

Vous devez initialiser le dépôt hello-cloudbuild-env avec deux branches (hello-cloudbuild-env et hello-cloudbuild-env) et un fichier de configuration Cloud Build décrivant le processus de déploiement.

1. Dans Cloud Shell, clonez le dépôt hello-cloudbuild-env, puis créez la branche hello-cloudbuild-env.

   cd ~
   gcloud source repos clone hello-cloudbuild-env
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git checkout -b production
   

2. Copiez le fichier cloudbuild-delivery.yaml disponible dans le dépôt hello-cloudbuild-app, puis validez la modification.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/kubernetes-engine-samples/management/gitops-style-delivery/cloudbuild.yaml
   git add .
   git commit -m "Create cloudbuild.yaml for deployment"
   

   Le fichier cloudbuild-delivery.yaml décrit le processus de déploiement qui doit être exécuté dans Cloud Build. Ce processus comporte deux étapes :

   1. Cloud Build applique le manifeste sur le cluster GKE.

   2. En cas de succès, Cloud Build copie le manifeste sur la branche production.

   steps:
   # This step deploys the new version of our container image
   # in the hello-cloudbuild Kubernetes Engine cluster.
   - name: 'gcr.io/cloud-builders/kubectl'
     id: Deploy
     args:
     - 'apply'
     - '-f'
     - 'kubernetes.yaml'
     env:
     - 'CLOUDSDK_COMPUTE_REGION=us-central1'
     - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'
   
   # This step copies the applied manifest to the production branch
   # The COMMIT_SHA variable is automatically
   # replaced by Cloud Build.
   - name: 'gcr.io/cloud-builders/git'
     id: Copy to production branch
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       # Configure Git to create commits with Cloud Build's service account
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
       # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
       git fetch origin production && git checkout production && \
       git checkout $COMMIT_SHA kubernetes.yaml && \
       # Commit the kubernetes.yaml file with a descriptive commit message
       git commit -m "Manifest from commit $COMMIT_SHA
       $(git log --format=%B -n 1 $COMMIT_SHA)" && \
       # Push the changes back to Cloud Source Repository
       git push origin production

3. Créez une branche candidate, puis transférez les deux branches vers Cloud Source Repositories pour qu'elles soient accessibles.

   git checkout -b candidate
   git push origin production
   git push origin candidate
   

4. Accordez le rôle IAM "Rédacteur de dépôt source" au compte de service Cloud Build pour le dépôt hello-cloudbuild-env.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF
   bindings:
   - members:
     - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com
     role: roles/source.writer
   EOF
   gcloud source repos set-iam-policy \
       hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml
   

Créer le déclencheur pour le pipeline de livraison continue

Dans cette section, vous allez configurer Cloud Build pour qu'il soit déclenché par un déploiement vers la branche candidate du dépôt hello-cloudbuild-env.

1. Ouvrez la page Déclencheurs de Cloud Build.

   Accéder à la page "Déclencheurs"

2. Cliquez sur Créer un déclencheur.

3. Indiquez les options suivantes :

   • Dans le champ Nom, saisissez hello-cloudbuild-deploy.
   • Sous Événement, sélectionnez Déployer sur une branche.
   • Sous Source, sélectionnez le dépôt hello-cloudbuild-env et la branche ^candidate$.
   • Dans Configuration : sélectionnez Fichier de configuration Cloud Build (yaml ou json).
   • Dans le champ Emplacement du fichier de configuration Cloud Build, saisissez cloudbuild.yaml après /.

4. Cliquez sur Créer.

Modifier le pipeline d'intégration continue afin de déclencher le pipeline de livraison continue

Dans cette section, vous allez ajouter certaines étapes au pipeline d'intégration continue pour qu'il génère une nouvelle version du manifeste Kubernetes, puis qu'il la déploie dans le dépôt hello-cloudbuild-env afin de déclencher le pipeline de livraison continue.

1. Remplacez le fichier cloudbuild.yaml par l'exemple étendu du fichier cloudbuild-trigger-cd.yaml.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp cloudbuild-trigger-cd.yaml cloudbuild.yaml
   

   Le fichier cloudbuild-trigger-cd.yaml est une version étendue du fichier cloudbuild.yaml. Il ajoute des étapes pour générer le nouveau fichier manifeste Kubernetes et déclencher le pipeline de livraison continue.

   Remarque : Ce pipeline utilise un script sed pour générer le modèle de manifeste. En situation réelle, vous pouvez recourir à un outil dédié tel que kustomize ou skaffold pour le faire. Ces outils offrent un plus grand contrôle sur la génération des modèles de manifeste.

   # This step clones the hello-cloudbuild-env repository
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Clone env repository
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       gcloud source repos clone hello-cloudbuild-env && \
       cd hello-cloudbuild-env && \
       git checkout candidate && \
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')
   
   # This step generates the new manifest
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Generate manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
        sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
        sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml
   
   # This step pushes the manifest back to hello-cloudbuild-env
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Push manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       cd hello-cloudbuild-env && \
       git add kubernetes.yaml && \
       git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
       Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
       Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
       git push origin candidate
   

2. Validez les modifications et déployez-les sur Cloud Source Repositories.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git add cloudbuild.yaml
   git commit -m "Trigger CD pipeline"
   git push google master
   

   Cette opération déclenche le pipeline d'intégration continue dans Cloud Build.

3. Examinez la compilation de l'intégration continue.

   Accéder à Cloud Build

   Les compilations récemment exécutées et terminées pour le dépôt hello-cloudbuild-app s'affichent. Vous pouvez cliquer sur le nom d'une compilation pour suivre son exécution et examiner ses journaux. La dernière étape de ce pipeline consiste à déployer le nouveau manifeste sur le dépôt hello-cloudbuild-env, ce qui entraîne le déclenchement du pipeline de livraison continue.

4. Examinez la compilation de livraison continue.

   Accéder à Cloud Build

   Les compilations récemment exécutées et terminées pour le dépôt hello-cloudbuild-env s'affichent. Vous pouvez cliquer sur le nom d'une compilation pour suivre son exécution et examiner ses journaux.

Tester le pipeline complet

Le pipeline CI/CD complet est maintenant configuré. Dans cette section, vous allez le tester de bout en bout.

1. Accédez à la page des services GKE.

   Accéder aux services Google Kubernetes Engine

   La liste contient un seul service nommé hello-cloudbuild, créé par le build de livraison continue récemment terminé.

2. Cliquez sur le point de terminaison associé au service hello-cloudbuild. Le message "Hello World!" s'affiche. Si le point de terminaison n'apparaît pas ou si vous constatez une erreur de l'équilibreur de charge, vous devrez peut-être attendre quelques minutes que l'initialisation de l'équilibreur de charge se termine. Si nécessaire, cliquez sur Actualiser pour mettre à jour la page.

3. Dans Cloud Shell, remplacez "Hello World" par "Hello Cloud Build" (dans l'application comme dans le test unitaire).

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   sed -i 's/Hello World/Hello Cloud Build/g' app.py
   sed -i 's/Hello World/Hello Cloud Build/g' test_app.py
   

4. Validez la modification et déployez-la sur Cloud Source Repositories.

   git add app.py test_app.py
   git commit -m "Hello Cloud Build"
   git push google master
   

   Cette opération déclenche le pipeline CI/CD complet.

5. Attendez quelques minutes, puis rechargez l'application dans votre navigateur. "Hello Cloud Build!" s'affiche.

Tester le rollback

Dans cette section, vous allez restaurer la version de l'application qui affiche la mention "Hello World!".

1. Ouvrez la console Cloud Build pour le dépôt hello-cloudbuild-env.

   Accéder à Cloud Build

2. Cliquez sur la deuxième build (compilation) la plus récente disponible.

3. Cliquez sur Recompiler.

4. Une fois la compilation terminée, rechargez l'application dans votre navigateur. "Hello World!" s'affiche de nouveau.

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Supprimer les ressources

Si vous souhaitez conserver le projet Google Cloud que vous avez utilisé dans ce tutoriel, supprimez les différentes ressources :

1. Supprimez les dépôts Git locaux.

   cd ~
   rm -rf ~/hello-cloudbuild-app
   rm -rf ~/hello-cloudbuild-env
   

2. Supprimez les dépôts Git dans Cloud Source Repositories

   gcloud source repos delete hello-cloudbuild-app --quiet
   gcloud source repos delete hello-cloudbuild-env --quiet
   

3. Supprimez les déclencheurs Cloud Build.

   1. Ouvrez la page Déclencheurs de Cloud Build.

      Accéder à la page "Déclencheurs"

   2. Pour chaque déclencheur, cliquez sur Plus, puis sur Supprimer.

4. Supprimez le dépôt Docker dans Artifact Registry.

   gcloud artifacts repositories delete my-repository \
       --location=us-central1
   

5. Supprimez l'autorisation accordée à Cloud Build pour la connexion à GKE.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

6. Supprimez le cluster GKE.

   gcloud container clusters delete hello-cloudbuild \
      --region us-central1
   

Étape suivante

• Découvrez certaines fonctionnalités avancées de Cloud Build : Configurer l'ordre des étapes de compilation, Compiler, tester et déployer des artefacts et Créer des étapes de compilation personnalisées.
• Découvrez comment mettre en miroir un dépôt GitHub ou Bitbucket dans Cloud Source Repositories.
• Découvrez comment connecter directement Cloud Build à votre dépôt GitHub.