Présentation du kit Cloud Foundation

1. Introduction à CFT 101

Dernière mise à jour : 11/02/2022

Qu'est-ce que le kit Cloud Foundation ?

En substance, le CFT fournit des modèles de bonnes pratiques pour vous aider à vous lancer rapidement sur Google Cloud Platform. Dans ce tutoriel, vous allez apprendre à contribuer au Cloud Foundation Toolkit.

Prérequis

• Un compte GitHub.
• Docker installé sur votre machine ou utilisation de Cloud Shell ( installation sur Mac, installation sur Windows)
• Éditeur de code pour modifier le code (par exemple, Visual Studio Code)
• Connaître les bases de Git et GitHub
• Vous avez déjà utilisé Terraform et l'Infrastructure as Code.
• Autorisation d'attribuer le rôle "Créateur de projet" à un compte de service
• Une organisation Google Cloud, un dossier de test et un compte de facturation

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez apprendre à contribuer au Cloud Foundation Toolkit (CFT).

Vous découvrirez comment :

• Configurer un environnement de développement pour contribuer à CFT
• Ajouter une fonctionnalité à un module CFT
• Ajouter des tests pour la fonctionnalité ajoutée
• Exécuter des tests d'intégration dans CFT
• Exécuter des tests lint
• Valider le code sur GitHub et envoyer une demande d'extraction

Vous allez exécuter toutes les étapes ci-dessus en ajoutant une nouvelle fonctionnalité au module CFT Google Cloud Storage. Vous allez ajouter un libellé appelé "silly_label", qui sera automatiquement ajouté à tous les buckets créés à l'aide du module CFT GCS. Vous apprendrez également à écrire des tests pour valider votre fonctionnalité et assurer l'intégration de bout en bout.

2. Configurer l'environnement de développement

Si vous le souhaitez, vous pouvez utiliser Cloud Shell pour vos besoins de développement. Si vous ne souhaitez pas utiliser Cloud Shell pour contribuer à CFT, vous pouvez configurer votre environnement de développement sur votre machine.

Configurer Git

GitHub est basé sur un système de contrôle des versions (VCS) Open Source appelé Git. Git est responsable de tout ce qui concerne GitHub et qui se passe localement sur votre machine ou dans Cloud Shell.

1. Lorsque vous utilisez Cloud Shell, vous n'avez pas besoin d'installer Git, car il est préinstallé.

$ git --version
# This will display the git version on the Cloud Shell.

Si vous configurez votre environnement de développement sur votre machine, vous devez installer Git.

 Téléchargez et installez la dernière version de Git.

Définir votre nom d'utilisateur et votre adresse e-mail dans Git

Git utilise un nom d'utilisateur pour associer les commits à une identité. Le nom d'utilisateur Git n'est pas le même que votre nom d'utilisateur GitHub.

Vous pouvez modifier le nom associé à vos commits Git à l'aide de la commande git config. Si vous modifiez le nom associé à vos commits Git à l'aide de git config, cela n'aura d'incidence que sur les futurs commits. Le nom utilisé pour les commits passés ne sera pas modifié.

Définir votre nom d'utilisateur Git pour chaque dépôt sur votre ordinateur

Pour Mac/Linux : ouvrez un terminal.

Pour Windows : ouvrez Git Bash.

Définissez un nom d'utilisateur Git :

$ git config --global user.name "Your Name"

$ git config --global user.email "[e-mail]"

Vérifiez que vous avez correctement défini le nom d'utilisateur Git :

$ git config --list

> Your Name

> Your Email

Vous avez configuré Git avec succès et vous devriez pouvoir créer des forks, des branches et des clones. Nous utiliserons Git de manière intensive dans cet atelier de programmation.

3. Dupliquer le dépôt GCS de CFT

Dupliquer un dépôt CFT

Vous avez configuré Git sur votre machine locale ou dans Cloud Shell à l'étape précédente. Vous devez maintenant dupliquer le dépôt CFT Google Cloud Storage pour commencer à contribuer.

Un fork est une copie d'un dépôt. Le forking d'un dépôt vous permet de tester librement des modifications sans affecter le projet d'origine.

Les forks sont généralement utilisés pour proposer des modifications au projet d'un autre utilisateur ou pour utiliser le projet d'un autre utilisateur comme point de départ pour votre propre idée.

Par exemple, vous pouvez utiliser des forks pour proposer des modifications liées à la correction d'un bug. Pour corriger un bug, vous pouvez :

• Dupliquez le dépôt.
• Corrigez le problème.
• Envoyez une demande d'extraction au propriétaire du projet.

Étapes à suivre pour forker un dépôt CFT :

1. Ouvrez votre navigateur Web et accédez au dépôt terraform-google-modules/terraform-google-cloud-storage. Nous utiliserons ce dépôt pour l'ensemble de l'atelier de programmation.
2. En haut à droite de la page, cliquez sur Fork (Dupliquer).

3. Vous serez invité à choisir l'emplacement où vous souhaitez dupliquer le dépôt. Sélectionnez votre profil, et le dépôt sera dupliqué.

Cloner votre copie localement

Le fork que vous avez créé est une copie du dépôt du module GCS. Vous allez maintenant cloner ce dépôt dans votre environnement local pour ajouter votre nouvelle fonctionnalité.

Étapes à suivre pour cloner votre copie :

1. Ouvrez votre navigateur Web et accédez à votre fork sur terraform-google-modules/terraform-google-cloud-storage.
2. En haut à droite, vous trouverez le bouton "Code". Cliquez dessus.

3. Après avoir cliqué sur le bouton "Code", cliquez sur l'icône "Copier" pour copier l'URL du fork. Vous utiliserez cette URL pour cloner votre copie dans votre environnement local.

4. Accédez à un terminal dans VSCode ou sur votre ordinateur, puis clonez le fork.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

5. Maintenant que vous avez cloné votre fork en local, vous devez accéder à votre dépôt, créer une branche à partir du fork et apporter des modifications au code de la branche temporaire.

Par convention, vous pouvez nommer votre branche comme suit :

• Pour les demandes de fonctionnalités : feature/feature-name
• Pour les mises à jour internes, internal/change-name
• Pour les corrections de bugs : bugfix/issue-name

Comme vous ajoutez une fonctionnalité, vous pouvez appeler votre branche temporaire feature/silly_label.

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

Vous êtes maintenant prêt à commencer à travailler sur le kit Cloud Foundation.

4. Créer un environnement de test

Le processus de développement CFT standard repose sur l'utilisation d'un projet de test isolé. Cette étape vous guidera dans la création du projet de test (basé sur une configuration standard) via un compte de service.

0. Installer Docker Engine

Si vous utilisez votre machine à des fins de développement, vous devez installer Docker Engine.

Remarque : Si vous utilisez Cloud Shell, vous n'avez pas besoin d'installer Docker, car Cloud Shell l'inclut déjà.

1. Installer le SDK Google Cloud

Vous n'avez pas besoin d'installer le SDK Google Cloud si vous utilisez Cloud Shell sur GCP.

Accédez au SDK Google Cloud et téléchargez le programme d'installation interactif pour votre plate-forme.

2. Définir la configuration

Pour créer un environnement de test, vous aurez besoin d'une organisation Google Cloud, d'un dossier de test et d'un compte de facturation. Ces valeurs doivent être définies à l'aide de variables d'environnement :

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. Configurer votre compte de service

Avant de créer un environnement de test, vous devez télécharger une clé de compte de service dans votre environnement de test. Ce compte de service aura besoin des rôles Créateur de projet, Utilisateur de compte de facturation et Lecteur de l'organisation. Ces étapes vous aident à créer un compte de service, mais vous pouvez également réutiliser un compte existant.

3.1 Créer ou sélectionner un projet GCP de départ

Avant de créer votre compte de service, vous devez sélectionner un projet dans lequel l'héberger. Vous pouvez également créer un projet.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Activer les API Google Cloud

Activez les API Google Cloud suivantes dans votre projet de départ :

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 Créer un compte de service

Créez un compte de service pour gérer l'environnement de test :

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

Vérifiez que votre compte de service a été créé :

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 Attribuez les rôles Créateur de projet, Utilisateur du compte de facturation et Lecteur de l'organisation au compte de service :

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

Vous disposez maintenant d'un compte de service qui peut être utilisé pour gérer l'environnement de test.

4. Préparer les identifiants Terraform

Pour créer l'environnement de test, vous devez télécharger la clé du compte de service dans votre shell.

4.1 Clé de compte de service

Créer et télécharger une clé de compte de service pour Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 Configurer les identifiants Terraform

Fournissez la clé à Terraform à l'aide de la variable d'environnement SERVICE_ACCOUNT_JSON, en définissant la valeur sur le contenu de votre clé de compte de service.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Après avoir stocké les informations d'identification dans la variable d'environnement, supprimez le fichier de clé. Si nécessaire, vous pourrez recréer une clé ultérieurement en utilisant la même commande que ci-dessus.

rm -rf cft.json

5. Créer un projet de test pour les déploiements Terraform

Maintenant que tout est prêt, vous pouvez créer le projet de test à l'aide d'une seule commande. Exécutez cette commande à partir de la racine du répertoire terraform-google-cloud-storage :

make docker_test_prepare

Le résultat ci-dessous s'affiche lorsque vous exécutez make docker_test_prepare. À la fin, vous recevez l'ID du projet de test qui a été créé, dans lequel vous allez déployer et tester votre module Cloud Storage avec votre nouvelle fonctionnalité. Si vous rencontrez des problèmes pour associer un compte de facturation, consultez les étapes de dépannage.

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

Vous avez créé un projet de test référencé par project_id, comme vous pouvez le voir dans la sortie de la console. Votre environnement de développement et de test est configuré.

5. Ajouter une fonctionnalité au module CFT

Maintenant que votre environnement de développement et de test est configuré, commençons à ajouter votre fonctionnalité "silly_label" au module CFT google-cloud-storage.

Assurez-vous d'être dans terraform-google-cloud-storage et ouvrez le fichier main.tf comme indiqué ci-dessous dans la structure de dossiers.

Comme "silly_label" est un libellé, vous allez ajouter la fonctionnalité à la ligne 27 dans la variable "labels" de main.tf, comme indiqué ci-dessous :

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

Vous allez maintenant ajouter la variable silly_label dans le fichier variables.tf que vous voyez dans la structure de dossiers ci-dessus.

Copiez et collez le code ci-dessous à la ligne 31 de variables.tf, en veillant à insérer un caractère de nouvelle ligne au-dessus et en dessous du bloc de variables que vous ajoutez.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6. Ajouter une nouvelle fonctionnalité à l'exemple de bucket de stockage

Vous avez ajouté votre fonctionnalité au fichier main.tf du module. Vous allez maintenant la tester à l'aide d'un exemple.

Le libellé "silly_label" devra être ajouté à l'exemple examples/multiple-buckets/main.tf.

Cet exemple sera utilisé à l'étape suivante pour effectuer des tests d'intégration.

Copiez et collez la ligne de variable silly_label ci-dessous à la ligne 27 de main.tf dans terraform-google-cloud-storage/examples/multiple-buckets/, comme indiqué dans la structure de dossiers :

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. Mettre à jour le test du plan pour vérifier la fonctionnalité

Vous avez ajouté votre fonctionnalité au fichier main.tf du module, puis à l'exemple multiple_buckets. Vous devez maintenant tester votre fonctionnalité à l'aide d'un test d'intégration de blueprint écrit en Golang.

Vous ajouterez vos nouveaux tests dans le fichier multiple_buckets_test.go qui se trouve dans la structure de dossiers ci-dessous :

Vous avez ajouté le libellé "silly_label" à tous les buckets créés via le module multiple_buckets et vous devez maintenant écrire des tests pour tester la nouvelle fonctionnalité.

Dans le code ci-dessous, vous obtenez le libellé de chaque bucket à l'aide de la commande gcloud alpha storage, puis vous vérifiez le résultat renvoyé par la commande.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. Exécuter des tests d'intégration dans CFT

Tests d'intégration

Les tests d'intégration permettent de vérifier le comportement du module racine, des sous-modules et des exemples. Les ajouts, les modifications et les corrections doivent être accompagnés de tests.

Les tests d'intégration sont écrits à l'aide du framework de test Blueprint et exécutés à l'aide de la CLI CFT. Pour plus de commodité, ces outils sont empaquetés dans une image Docker.

La stratégie générale de ces tests consiste à vérifier le comportement des modules d'exemple, ce qui garantit que le module racine, les sous-modules et les modules d'exemple sont tous fonctionnellement corrects.

Dans l'exécution interactive, vous exécutez chaque étape à l'aide de plusieurs commandes.

1. Exécutez make docker_run pour démarrer le conteneur Docker de test en mode interactif.

Make est un outil d'automatisation de compilation qui compile automatiquement des programmes et des bibliothèques exécutables à partir du code source en lisant des fichiers appelés Makefiles, qui spécifient comment dériver le programme cible. Lorsque vous modifiez des fichiers, le conteneur Docker doit être mis à jour automatiquement.

Lorsque vous exécutez make docker_run, vous créez un espace de travail dans votre conteneur Docker et activez les identifiants de votre compte de service. L'espace de travail sera utilisé lors des prochaines étapes pour exécuter des tests.

Le résultat ci-dessous s'affiche dans votre terminal :

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

2. Exécutez module-swapper -registry-prefix=terraform-google-modules pour ajuster les fichiers main.tf de l'exemple afin d'importer les modules à partir de vos fichiers locaux au lieu des modules publiés.

Vous devriez voir une sortie semblable à ce qui suit dans votre terminal :

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules
2025/08/04 19:26:29 Module name set from remote to cloud-storage
2025/08/04 19:26:29 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:26:29 --- Original
+++ Modified
@@ -21,7 +21,7 @@
 }
 
 module "cloud_storage" {
-  source = "terraform-google-modules/cloud-storage/google"
+  source = "../.."
   # [restore-marker]   version = "~> 10.0"
 
   project_id = var.project_id

3. Exécutez cft test list pour lister tous les tests de plans dans votre espace de travail.

Le résultat ci-dessous s'affiche dans votre terminal :

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go 

4. Exécutez cft test run <EXAMPLE_NAME> --stage init pour initialiser l'exemple. Dans ce cas, pour initialiser l'exécution du test TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Vous pouvez également utiliser l'indicateur --verbose pour obtenir des informations supplémentaires lors de l'exécution des tests.

Cette étape d'initialisation permet d'initialiser l'exemple Terraform.

Le résultat ci-dessous s'affiche dans votre terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

Remarque : Des avertissements tels que Skipping fixtures discovery peuvent s'afficher dans les journaux. Il s'agit d'avertissements de débogage qui peuvent être ignorés. Si des erreurs sont détectées, le test échouera.

5. Exécutez cft test run <EXAMPLE_NAME> --stage apply pour appliquer le module d'exemple.

Cette étape applique l'exemple initialisé à l'étape précédente au projet GCP créé précédemment dans l'atelier de programmation.

Le résultat ci-dessous s'affiche dans votre terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

Remarque : Si vous voyez Request violates constraint 'constraints/storage.uniformBucketLevelAccess' dans les journaux, cela signifie que votre projet n'est pas autorisé à définir uniform_bucket_level_access sur "false". Pour cet atelier de programmation, vous pouvez contourner ce problème en définissant cloud_storage.bucket_policy_only["two"] sur true au lieu de false et en modifiant le test Golang en conséquence.

6. Exécutez cft test run <EXAMPLE_NAME> --stage verify pour vérifier que l'exemple a créé l'infrastructure attendue.

Cette étape exécutera la fonction de validation dans TestMultipleBuckets. La validation s'effectue généralement en exécutant une commande gcloud pour récupérer la sortie JSON de l'état actuel d'une ressource et en s'assurant que l'état actuel est conforme à celui déclaré dans l'exemple.

Si vous obtenez des erreurs, vous verrez ce qui était attendu et ce qui a été reçu par la commande pour le test.

Le résultat ci-dessous s'affiche dans votre terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

7. Exécutez cft test run <EXAMPLE_NAME> --stage teardown pour démonter l'exemple.

Cette étape détruit l'infrastructure que vous avez créée lors des étapes précédentes. Cette étape détruira également les buckets GCS créés dans le projet, ainsi que le libellé que vous avez ajouté au module GCS.

Vous pouvez afficher le résultat ci-dessous dans votre terminal.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

8. Exécutez module-swapper -registry-prefix=terraform-google-modules -restore pour annuler les ajustements apportés aux fichiers main.tf de l'exemple lors de la dernière exécution de module-swapper.

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules -restore
2025/08/04 19:30:41 Module name set from remote to cloud-storage
2025/08/04 19:36:32 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:36:32 --- Original
+++ Modified
@@ -21,8 +21,8 @@
 }
 
 module "cloud_storage" {
-  source = "../.."
-   version = "~> 10.0"
+  source  = "terraform-google-modules/cloud-storage/google"
+  version = "~> 10.0"
 
   project_id = var.project_id
 

9. Exécutez exit pour quitter le conteneur de test.

9. Générer de la documentation pour les entrées et les sorties

Les tableaux "Entrées" et "Sorties" des fichiers README du module racine, des sous-modules et des modules exemples sont générés automatiquement en fonction des variables et outputs des modules respectifs. Ces tables doivent être actualisées si les interfaces de module sont modifiées.

Exécutez la commande suivante :

make generate_docs
# This will generate new Inputs and Outputs tables

Rappel : Exécutez toujours generate_docs pour vous assurer que toute la documentation est complète.

10. Exécuter des tests lint dans CFT

Un linter est un outil qui analyse le code source pour signaler les erreurs de programmation, les bugs, les erreurs de style et les constructions suspectes.

De nombreux fichiers du dépôt peuvent être lintés ou mis en forme pour maintenir un niveau de qualité standard. Pour garantir la qualité dans CFT, vous utiliserez un test lint.

Exécutez la commande suivante :

make docker_test_lint
# This will run all lint tests on your repo

Rappel : Exécutez toujours le test lint, car Cloud Build échouera si le linting n'est pas terminé. Exécutez cette commande avant de valider le code dans votre dépôt local.

11. Envoyer une demande d'extraction sur GitHub

Remarque : L'atelier de programmation est maintenant terminé. Nous vous encourageons à créer une demande d'extraction uniquement si vous êtes débutant sur GitHub et que vous souhaitez en savoir plus sur le processus.

Maintenant que vous avez modifié votre code en local et que vous l'avez testé à l'aide des tests d'intégration, vous souhaitez publier ce code dans le dépôt principal.

Pour rendre votre code disponible dans le dépôt principal, vous devez valider les modifications apportées à votre branche et les transférer vers le dépôt principal. Pour que votre code soit ajouté au dépôt principal que vous avez forké au début de l'atelier de programmation, vous devez créer une demande d'extraction (PR, Pull Request) sur le dépôt maître après avoir transféré le code vers votre dépôt.

Lorsque vous créez une demande de pull, l'administrateur du dépôt est averti et peut examiner les modifications de code proposées. Vous pouvez également ajouter d'autres utilisateurs en tant que réviseurs pour obtenir des commentaires sur les modifications apportées à votre code. La demande de pull déclenchera un Cloud Build qui exécutera des tests sur le dépôt.

En fonction des modifications apportées à votre code, les réviseurs de code vous fourniront des commentaires sur votre code et vous demanderont de le modifier si quelque chose doit être changé en fonction des bonnes pratiques et de la documentation. L'administrateur examinera les modifications apportées à votre code, s'assurera qu'il est conforme au dépôt et pourra vous demander d'apporter d'autres modifications avant de fusionner votre code dans le dépôt maître.

Pour valider le code dans votre branche dupliquée et l'y transférer, procédez comme suit :

1. La première étape consiste à ajouter les fichiers modifiés au dépôt local.

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

2. Vos fichiers sont maintenant mis en scène. Vous allez ensuite valider les modifications.

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

3. Déployez les modifications validées dans votre dépôt local sur GitHub pour créer une demande d'extraction.

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

Vos modifications de code sont maintenant prêtes pour une demande d'extraction.

Suivez les étapes ci-dessous pour créer une demande d'extraction dans le dépôt terraform-google-modules/terraform-google-cloud-storage  :

1. Dans votre navigateur Web, accédez à la page principale du repo.
2. Une suggestion s'affiche sous forme de bannière pour vous inviter à ouvrir une demande de pull à partir de votre fork. Cliquez sur "Comparer et demande d'extraction".

3. Saisissez un titre et une description pour votre demande d'extraction afin de décrire vos modifications de code. Soyez aussi précis que possible, tout en restant concis.

4. Pour créer une demande d'extraction prête à être examinée, cliquez sur "Create Pull Request" (Créer une demande d'extraction).
5. Vous verrez les déclencheurs Cloud Build s'exécuter en raison de la demande d'extraction.
6. Si vous rencontrez des problèmes, consultez la documentation GitHub officielle sur l'ouverture de demandes d'extraction à partir de forks.

Vous avez réussi à déployer votre première modification de code dans votre branche dupliquée et à créer votre première demande d'extraction CFT par rapport à la branche principale.

12. Félicitations

Félicitations, vous avez ajouté une fonctionnalité à un module CFT et envoyé une demande d'extraction pour examen.

Vous avez ajouté une fonctionnalité à un module CFT, l'avez testée localement à l'aide d'un exemple et avez effectué des tests avant de valider votre code sur GitHub. Enfin, vous avez créé une demande d'extraction pour examen et fusion finale dans CFT.

Vous connaissez maintenant les étapes importantes pour commencer à utiliser le kit Cloud Foundation.