Configurer la CI/CD pour stocker la configuration Terraform en tant que code

Ce tutoriel explique comment gérer une infrastructure sous forme de code avec Terraform et Cloud Build à l'aide de la méthodologie GitOps. Le terme GitOps a été inventé par Weaveworks. Son concept clé consiste à utiliser un dépôt Git pour stocker l'état que vous souhaitez pour votre environnement. Terraform est un outil Open Source d'HashiCorp qui vous permet de créer, de modifier et d'améliorer de manière prévisible votre infrastructure cloud en utilisant du code. Dans ce tutoriel, vous allez utiliser Cloud Build, un service d'intégration continue Google Cloud , pour appliquer automatiquement des fichiers manifestes Terraform à votre environnement.

Ce tutoriel s'adresse aux développeurs et aux opérateurs qui recherchent une stratégie conviviale pour apporter des modifications prévisibles à l'infrastructure. Dans cet article, nous partons du principe que vous connaissez Google Cloudet Linux.

Les rapports sur l'état du DevOps identifient les capacités qui améliorent les performances de livraison de logiciels. Ce tutoriel vous permettra d'effectuer les opérations suivantes :

• Contrôle des versions
• Intégration continue
• Livraison continue
• Tests continus

Architecture

Ce tutoriel applique les pratiques GitOps pour gérer les exécutions Terraform. Notez que les branches Secure Source Manager dev et prod sont utilisées pour représenter des environnements réels. Ces environnements sont définis par des réseaux de cloud privé virtuel (VPC), respectivement dev et prod, dans un projetGoogle Cloud .

Le processus commence lorsque vous envoyez le code Terraform à la branche dev ou prod. Dans ce scénario, Cloud Build se déclenche, puis applique les fichiers manifestes Terraform pour obtenir l'état souhaité dans l'environnement concerné. D'autre part, lorsque vous transférez du code Terraform vers une autre branche, par exemple une branche de fonctionnalité, Cloud Build s'exécute pour exécuter terraform plan, mais rien n'est appliqué aux environnements.

Idéalement, les développeurs ou les opérateurs doivent faire des propositions d'infrastructure à des branches de développement ou de fonctionnalité, puis les soumettre par le biais de demandes d'extraction. Ainsi, vous pouvez discuter des modifications potentielles et les examiner avec les collaborateurs, et ajouter des commits de suivi avant que les modifications ne soient fusionnées dans la branche de base.

Si aucun problème n'est soulevé, vous devez d'abord fusionner les modifications dans la branche dev. Cette fusion déclenche un déploiement d'infrastructure dans l'environnement dev, ce qui vous permet de tester cet environnement. Une fois que vous avez testé votre infrastructure et que vous êtes sûr de la fiabilité de votre déploiement, vous devez fusionner la branche dev dans la branche prod pour déclencher l'installation de l'infrastructure dans l'environnement de production.

Objectifs

• Configurez votre instance et votre dépôt Secure Source Manager.
• Configurez Terraform pour stocker l'état dans un bucket Cloud Storage.
• Accordez des autorisations à votre compte de service Cloud Build.
• Connectez Cloud Build à votre dépôt Secure Source Manager.
• Modifiez la configuration de votre environnement dans une branche de fonctionnalité.
• Faites la promotion des modifications dans l'environnement de développement.
• Faites la promotion des modifications dans l'environnement de production.

Coûts

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

• Cloud Build
• Cloud Storage
• Compute Engine

Vous pouvez obtenir 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, supprimez les ressources que vous avez créées pour éviter que des frais vous soient facturés. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Dans Cloud Shell, récupérez l'ID du projet que vous venez de sélectionner :

   gcloud config get-value project

   Si cette commande ne renvoie pas l'ID du projet, configurez Cloud Shell pour utiliser votre projet. Remplacez PROJECT_ID par l'ID du projet.

   gcloud config set project PROJECT_ID

3. Activez les API requises :

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   Cette étape peut prendre quelques minutes..
4. Si vous n'avez jamais utilisé Git dans Cloud Shell, configurez-le avec votre nom et votre adresse e-mail :

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

   Git utilise ces informations pour vous identifier en tant qu'auteur des commits que vous créez dans Cloud Shell.

Configurer votre dépôt Secure Source Manager

Dans ce tutoriel, vous utilisez un seul dépôt Secure Source Manager pour définir votre infrastructure cloud. Vous orchestrez cette infrastructure grâce à différentes branches correspondant à différents environnements :

• La branche dev contient les dernières modifications appliquées à l'environnement de développement.
• La branche prod contient les dernières modifications appliquées à l'environnement de production.
• Des branches de fonctionnalités semblables à feature_x sont utilisées pour apporter des modifications avant d'envoyer les données aux branches dev ou prod.

Grâce à cette infrastructure, vous pouvez toujours faire référence au dépôt pour savoir quelle configuration est attendue dans chaque environnement et pour proposer de nouvelles modifications en les fusionnant d'abord dans l'environnement dev. Vous faites ensuite la promotion des modifications en fusionnant la branche dev dans la branche prod suivante.

1. Créez un dépôt Secure Source Manager vide : n'initialisez pas le dépôt.

2. Ajoutez l'outil d'aide à l'authentification Secure Source Manager à votre git config global en exécutant la commande suivante :

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   L'outil d'authentification utilise gcloud CLI pour récupérer vos identifiantsGoogle Cloud lorsque vous utilisez des commandes Git avec Secure Source Manager.

3. Pour vous réauthentifier après la configuration initiale des identifiants, exécutez la commande gcloud CLI suivante :

   gcloud auth login
   

4. Clonez le dépôt solutions-terraform-cloudbuild-gitops dans votre shell local ou votre environnement de travail :

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. Ajoutez votre dépôt Secure Source Manager en tant qu'amont.

   git remote add google HTTPS_REPO_URL
   

   Où HTTPS_REP_URL correspond à l'URL HTTPS de votre dépôt Secure Source Manager. Vous trouverez l'URL en haut de la page de votre dépôt dans l'interface Web Secure Source Manager.

6. Créez votre branche dev et passez à celle-ci.

   git checkout dev
   

7. Transmettez le dépôt cloné à votre dépôt à l'aide de la commande suivante :

   git push -u google --all
   

8. Répétez les deux étapes précédentes pour votre branche prod.

Le code dans ce dépôt est structuré comme suit :

• Le dossier environments/ contient des sous-dossiers représentant des environnements, tels que dev et prod, qui offrent une séparation logique entre les charges de travail à différents stades de maturité (développement et production, respectivement). Bien qu'il soit judicieux d'avoir des environnements aussi similaires que possible, chaque sous-dossier possède sa propre configuration Terraform. Cela permet de garantir qu'ils peuvent avoir des paramètres uniques, si nécessaire.

• Le dossier modules/ contient des modules Terraform intégrés. Ces modules représentent des regroupements logiques de ressources connexes et sont utilisés pour partager du code dans différents environnements.

• Le fichier cloudbuild.yaml est un fichier de configuration de compilation qui contient des instructions pour Cloud Build, par exemple pour indiquer comment effectuer des tâches correspondant à un ensemble d'étapes. Ce fichier spécifie une exécution conditionnelle selon la branche à partir de laquelle Cloud Build récupère le code, par exemple :

  • Pour les branches dev et prod, les étapes suivantes sont exécutées :

    1. terraform init
    2. terraform plan
    3. terraform apply

  • Pour toute autre branche, les étapes suivantes sont exécutées :

    1. terraform init pour tous les sous-dossiers environments
    2. terraform plan pour tous les sous-dossiers environments

Pour vous assurer que les modifications proposées sont appropriées pour chaque environnement, terraform init et terraform plan sont exécutés pour tous les sous-dossiers environments. Avant de fusionner la demande d'extraction, vous pouvez passer en revue les plans pour vous assurer que l'accès n'est pas accordé à une entité non autorisée, par exemple.

Modifier le fichier de configuration de compilation

Pour que l'exemple de fichier de configuration de compilation fonctionne avec Secure Source Manager, vous devez apporter les modifications suivantes :

• Ajoutez une étape pour cloner votre dépôt.
• Ajoutez une étape pour obtenir le nom de la branche et l'attribuer à une variable.

Modifiez le fichier de configuration de compilation dans la branche dev :

1. Accédez à la branche dev :

   git checkout dev
   

2. Ouvrez le fichier cloudbuild.yaml et remplacez son contenu par ce qui suit :

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. Vérifiez que le fichier a été modifié.

   git status
   

4. Validez et déployez vos modifications :

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. Ouvrez une demande d'extraction pour promouvoir rapidement vos modifications dans la branche prod.

   1. Dans l'interface Web Secure Source Manager, accédez à votre dépôt.
   2. Cliquez sur l'onglet Pull requests (Demandes d'extraction).
   3. Cliquez sur New pull request (Nouvelle demande d'extraction).
   4. Dans le champ Fusionner dans, sélectionnez la branche prod.
   5. Dans le champ pull from: (extraire de), sélectionnez la branche dev.
   6. Vérifiez les modifications, puis cliquez sur Nouvelle demande d'extraction.
   7. Cliquez sur Create pull request (Créer une demande d'extraction).
   8. Cliquez sur Merge pull request (Fusionner la demande d'extraction).

   9. Cliquez à nouveau sur Fusionner la requête d'extraction.

      Les modifications sont fusionnées dans votre branche prod.

Configurer Terraform pour stocker l'état dans un bucket Cloud Storage

Par défaut, Terraform stocke l'état localement dans un fichier nommé terraform.tfstate. Cette configuration par défaut peut rendre l'utilisation de Terraform difficile pour les équipes, en particulier lorsque de nombreux utilisateurs exécutent Terraform en même temps et que chaque ordinateur possède sa propre compréhension de l'infrastructure actuelle.

Pour vous aider à éviter de tels problèmes, cette section permet de configurer un état distant qui pointe vers un bucket Cloud Storage. Un état distant est une fonctionnalité des backends. Dans ce tutoriel, il est configuré dans les fichiers backend.tf. Par exemple :

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

Dans les étapes suivantes, vous allez créer un bucket Cloud Storage et modifier quelques fichiers pour qu'ils pointent vers votre nouveau bucket et votre projet Google Cloud .

1. Dans Cloud Shell, créez le bucket Cloud Storage.

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. Activez la gestion des versions des objets pour conserver l'historique de vos déploiements :

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   L'activation de la gestion des versions des objets augmente les coûts de stockage. Vous pouvez limiter cette augmentation des coûts en configurant la gestion du cycle de vie des objets afin de supprimer les anciennes versions d'état.

3. Créez une branche cloud-storage-bucket pour y apporter vos modifications :

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. Remplacez l'espace réservé PROJECT_ID par l'ID de projet dans les fichiers terraform.tfvars et backend.tf :

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   Sous OS X ou macOS, vous devrez peut-être ajouter deux guillemets ("") après sed -i, comme suit :

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. Vérifiez que tous les fichiers ont bien été mis à jour :

   git status
   

   Le résultat ressemble à ceci :

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. Validez et déployez vos modifications :

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   Votre nouvelle branche cloud-storage-bucket est transférée vers votre dépôt.

7. Fusionnez vos modifications cloud-storage-bucket dans vos branches dev et prod en ouvrant et en envoyant des demandes de fusion pour chaque branche.

Accordez des autorisations à votre compte de service Cloud Build.

Pour permettre au compte de service Cloud Build d'exécuter des scripts Terraform dans le but de gérer des ressources Google Cloud , vous devez lui accorder l'accès approprié à votre projet. Pour plus de simplicité, l'accès à l'éditeur de projet est accordé dans ce tutoriel. Pour les environnements de production, suivez les bonnes pratiques de votre entreprise en matière de sécurité informatique, généralement en fournissant un accès selon la stratégie du moindre privilège.

Remarque : Le compte de service Cloud Build par défaut utilisé pour exécuter les compilations va être modifié. Nous vous recommandons de spécifier votre propre compte de service pour exécuter vos builds. Pour en savoir plus, consultez Modification du compte de service Cloud Build.

1. Pour trouver l'adresse e-mail du compte de service Cloud Build, accédez à Paramètres sur la page Cloud Build.

   Accéder aux paramètres Cloud Build

2. Copiez la valeur de l'adresse e-mail du compte de service.

3. Accordez l'accès requis à votre compte de service Cloud Build :

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   Remplacez les éléments suivants :

   • PROJECT_ID par votre ID de projet.
   • CLOUDBUILD_SA par l'adresse e-mail du compte de service Cloud Build.

Se connecter à Cloud Build

Pour déclencher Cloud Build lors d'un push vers une branche, configurez un webhook Secure Source Manager. Le fichier de configuration de compilation vérifie le nom de la branche pour déterminer si des modifications doivent être apportées aux environnements dev ou prod.

1. Activez et configurez Cloud Build dans votre projet.

2. Ouvrez la page Déclencheurs dans la console Google Cloud .

   Ouvrir la page Déclencheurs

3. Sélectionnez votre projet dans le menu déroulant du sélecteur de projet, en haut de la page.

4. Cliquez sur Ouvrir.

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

6. Entrez les paramètres de déclencheur suivants :

   • Nom : trigger-on-push

   • Région : sélectionnez la région pour votre déclencheur. Si le fichier de configuration de compilation associé à votre déclencheur spécifie un pool privé, la région que vous sélectionnez pour votre déclencheur doit correspondre à celle du pool privé.

     Remarque : Si vous utilisez un pool privé, vous devez attribuer des adresses IP externes pour permettre à votre pool privé d'accéder à l'Internet public. Pour en savoir plus, consultez Créer un pool privé.

     Si vous sélectionnez global comme région, Cloud Build utilise la région spécifiée dans votre fichier de configuration de compilation pour exécuter votre compilation. Il peut s'agir de la région du pool privé, si vous spécifiez un pool privé dans votre fichier de configuration de compilation, ou du pool par défaut global si vous ne spécifiez pas de pool privé.

   • Description (facultative) : saisissez une description du déclencheur.

   • Événement : sélectionnez Événement de webhook comme événement de dépôt pour appeler le déclencheur.

     Si Secret Manager n'est pas installé, vous êtes invité à l'activer.

   • URL du webhook : sélectionnez l'une des options suivantes :

     • Utilisez un nouveau secret si vous souhaitez générer un secret à l'aide de Cloud Build. Cliquez sur Créer un secret pour créer votre secret.
     • Utilisez un secret existant ou créez-en un si vous souhaitez utiliser un secret existant. Saisissez le secret et la version dans les zones de sélection déroulantes.

     Si vous utilisez un secret existant, vous devrez peut-être attribuer manuellement le rôle Accesseur de secrets Secret Manager à l'agent de service Cloud Build [e-mail].

     Pour en savoir plus, consultez Attribuer un rôle à l'agent de service Cloud Build.

7. Cliquez sur Afficher l'aperçu de l'URL et notez l'URL. Vous aurez besoin de cette URL pour configurer le webhook dans Secure Source Manager.

   • Configuration : pour Type, sélectionnez Fichier de configuration Cloud Build (YAML ou JSON), puis pour Emplacement, sélectionnez Intégré.

8. Cliquez sur le bouton Ouvrir l'éditeur pour modifier votre fichier de configuration de compilation.

9. Copiez le contenu de votre fichier cloudbuild.yaml dans l'éditeur.

   Comme indiqué précédemment, ce pipeline présente différents comportements en fonction de la branche à récupérer. La compilation vérifie si la variable ${branch} correspond à un dossier d'environnement. Si oui, Cloud Build exécute terraform plan pour cet environnement. Sinon, Cloud Build exécute terraform plan pour tous les environnements afin de s'assurer que la modification proposée est valable pour tous. Si l'exécution de l'un de ces plans échoue, la compilation échoue.

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   La commande terraform apply s'exécute pour les branches de l'environnement, mais elle est complètement ignorée dans les autres cas.

10. Cliquez sur + Ajouter une variable et ajoutez les deux variables de substitution suivantes :

    • Variable : _REPO_URL, Valeur :$(body.repository.clone_url)
    • Variable : _REF, Valeur :$(body.ref)

11. Cliquez sur Créer.

Configurer un webhook dans Secure Source Manager

Créez un webhook pour déclencher des compilations lors des envois vers vos branches dev ou prod.

1. Dans l'interface Web Secure Source Manager, accédez au dépôt pour lequel vous souhaitez créer un webhook.
2. Cliquez sur Paramètres.
3. Cliquez sur Webhooks, puis sur Add webhook (Ajouter un Webhook).

4. Dans le champ ID du hook, saisissez un ID pour le webhook.

   Remarque : Les ID de hook doivent respecter la convention d'attribution de noms des ressources. Ils ne doivent contenir que des lettres minuscules, des chiffres ou des tirets, doivent commencer par une lettre et ne peuvent pas être modifiés après la création du webhook.

5. Dans le champ URL cible, saisissez l'URL du webhook que vous avez copiée lorsque vous avez configuré un déclencheur de webhook dans Cloud Build.

   Pour trouver l'URL du webhook :

   1. Ouvrez la page Déclencheurs dans la console Google Cloud .

      Ouvrir la page Déclencheurs

   2. Cliquez sur votre déclencheur.

   3. Dans la section URL du Webhook, cliquez sur Afficher l'aperçu d'URL, puis copiez l'URL.

6. L'URL du webhook contient les valeurs de clé et de code secret que vous avez saisies lorsque vous avez créé votre déclencheur Cloud Build. Pour éviter de divulguer ces valeurs, supprimez-les de la fin de l'URL cible et copiez-les dans le champ Chaîne de requête sensible.

   Pour trouver votre clé et votre secret dans l'URL du webhook, recherchez le texte commençant par key=.

   Par exemple, pour l'URL suivante : https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   Copiez et supprimez la partie commençant par le point d'interrogation ?key=... dans le champ URL cible. Supprimez ensuite le point d'interrogation initial et déplacez la partie restante key=... dans le champ Chaîne de requête sensible.

7. Cliquez sur Add webhook (Ajouter un Webhook).

8. Le webhook s'affiche sur la page Webhooks.

   Remarque : Lorsque vous ajoutez ou modifiez un webhook, la longueur de Sensitive Query String peut ne pas correspondre à celle saisie. Cela est normal, car des chaînes d'espace réservé sont utilisées pour garantir la sécurité.

Modifier la configuration de votre environnement dans une nouvelle branche de fonctionnalité

1. Assurez-vous d'être dans la branche dev :

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. Récupérez les dernières modifications :

   git pull
   

3. Créez une branche bug-fix pour modifier la configuration de l'environnement.

   git checkout -b bug-fix
   

4. Ouvrez modules/firewall/main.tf pour le modifier.

5. À la ligne 30, corrigez la faute de frappe "http-server2" dans le champ target_tags.

   La valeur doit être égale à "http-server".

6. Validez et déployez vos modifications :

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. Ouvrez la page Historique de Cloud Build dans la console Google Cloud  :

   Ouvrir la page "Historique"

8. Cliquez sur Build (Compilation) pour afficher plus d'informations, y compris le résultat de la commande terraform plan.

Notez que la tâche Cloud Build a exécuté le pipeline défini dans le fichier cloudbuild.yaml. Comme indiqué précédemment, ce pipeline présente différents comportements en fonction de la branche à récupérer. La compilation vérifie si la variable ${branch} correspond à un dossier d'environnement. Si oui, Cloud Build exécute terraform plan pour cet environnement. Sinon, Cloud Build exécute terraform plan pour tous les environnements afin de s'assurer que la modification proposée est valable pour tous. Si l'exécution de l'un de ces plans échoue, la compilation échoue.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

De même, la commande terraform apply s'exécute pour les branches de l'environnement, mais elle est complètement ignorée dans les autres cas. Dans cette section, vous avez soumis une modification de code à une nouvelle branche, et aucun déploiement d'infrastructure n'a été appliqué à votre projet Google Cloud .

- id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

Promouvoir des modifications dans l'environnement de développement

Il est temps d'appliquer l'état de votre choix à votre environnement dev.

1. Dans l'interface Web Secure Source Manager, accédez à votre dépôt.
2. Cliquez sur New pull request (Nouvelle demande d'extraction).
3. Dans le champ Fusionner dans, sélectionnez votre branche dev.
4. Dans le champ pull from: (extraire de), sélectionnez votre branche bug-fix.
5. Cliquez sur New pull request (Nouvelle demande d'extraction).
6. Cliquez sur Create pull request (Créer une demande d'extraction).
7. Cliquez sur Merge pull request (Fusionner la demande d'extraction), puis à nouveau sur Merge pull request (Fusionner la demande d'extraction).

8. Vérifiez qu'une nouvelle compilation Cloud Build a été déclenchée :

   Accéder à la page Cloud Build

9. Ouvrez la compilation et vérifiez les journaux.

   Lorsque la compilation est terminée, vous devez voir quelque chose de semblable à ceci :

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. Copiez EXTERNAL_IP_VALUE et ouvrez l'adresse dans un navigateur Web.

    http://EXTERNAL_IP_VALUE
    

    Ce provisionnement peut prendre quelques secondes pour démarrer la machine virtuelle et propager la règle de pare-feu. À terme, Environment: dev s'affiche dans le navigateur Web.

11. Accédez à Cloud Storage :

    Accéder à la page Cloud Storage

12. Sélectionnez votre projet.

13. Cliquez sur votre bucket de stockage d'état Terraform. Le nom du bucket se présente ainsi :

    PROJECT_ID-tfstate
    

14. Cliquez sur env, puis sur dev pour afficher votre fichier d'état Terraform.

Promouvoir des modifications dans l'environnement de production

Maintenant que votre environnement de développement est entièrement testé, vous pouvez promouvoir votre code d'infrastructure en production.

1. Dans l'interface Web Secure Source Manager, accédez à votre dépôt.
2. Cliquez sur l'onglet Pull requests (Demandes d'extraction).
3. Cliquez sur New pull request (Nouvelle demande d'extraction).
4. Pour merge into (fusionner dans), sélectionnez la branche prod de votre dépôt.
5. Pour pull from (extraire de), sélectionnez la branche dev de votre dépôt.
6. Cliquez sur New pull request (Nouvelle demande d'extraction).
7. Sous title (titre), saisissez un titre tel que "Promoting networking changes" (Promouvoir les modifications réseau), puis cliquez sur Create pull request (Créer une demande d'extraction).

8. Examinez les modifications proposées, puis cliquez sur Merge pull request (Fusionner la demande d'extraction).

   La date et l'URL du dépôt sont ajoutées dans le champ de commentaire.

9. Cliquez de nouveau sur Fusionner la requête d'extraction pour confirmer.

10. Dans la console Google Cloud , ouvrez la page Build History (Historique de compilation) pour voir vos modifications appliquées à l'environnement de production :

    Accéder à la page Cloud Build

11. Attendez la fin de la compilation, puis consultez les journaux.

    À la fin des journaux, vous devez voir quelque chose de semblable à ceci :

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. Copiez EXTERNAL_IP_VALUE et ouvrez l'adresse dans un navigateur Web.

    http://EXTERNAL_IP_VALUE
    

    Ce provisionnement peut prendre quelques secondes pour démarrer la machine virtuelle et propager la règle de pare-feu. À terme, Environment: prod s'affiche dans le navigateur Web.

13. Accédez à Cloud Storage :

    Accéder à la page Cloud Storage

14. Sélectionnez votre projet.

15. Cliquez sur votre bucket de stockage d'état Terraform. Le nom du bucket se présente ainsi :

    PROJECT_ID-tfstate
    

16. Cliquez sur env, puis sur prod pour afficher votre fichier d'état Terraform.

Vous avez configuré avec succès un pipeline d'Infrastructure as Code (IaC) sans serveur sur Cloud Build. À l'avenir, vous voudrez peut-être essayer les opérations suivantes :

• Ajouter des déploiements pour des cas d'utilisation distincts
• Créer des environnements supplémentaires pour répondre à vos besoins
• Utiliser un projet par environnement au lieu d'un VPC par environnement

Effectuer un nettoyage

Une fois le tutoriel terminé, nettoyez les ressources créées surGoogle Cloud afin d'éviter qu'elles ne vous soient facturées à l'avenir.

Supprimer le projet

Attention : La suppression d'un projet aura les effets suivants :

• 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.

Étapes suivantes

• Envisagez d'utiliser les modèles du kit Cloud Foundation pour créer rapidement une base reproductible adaptée aux entreprises dansGoogle Cloud.
• Observez les environnements Google Cloud reproductibles à grande échelle grâce à des pipelines d'Infrastructure as Code Cloud Build de la conférence Next 2019 sur le flux de travail GitOps décrit dans ce tutoriel.
• Consultez le tutoriel sur la livraison continue de type GitOps avec Cloud Build.
• Découvrez certaines fonctionnalités Cloud Build avancées : Configurer l'ordre des étapes de compilation, Compiler, tester et déployer des artefacts et Créer des étapes de compilation personnalisées.
• Consultez le blog Garantir l'évolutivité et la conformité de votre déploiement Terraform avec Cloud Build.
• Consultez nos ressources sur DevOps.
• Obtenez davantage d'informations sur les fonctionnalités DevOps associées à ce tutoriel :
  • Contrôle des versions
  • Intégration continue
  • Livraison continue
  • Tests continus
• Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.