Cette page a été traduite par l'API Cloud Translation.

Présentation du kit Cloud Foundation

1. Présentation de CFT 101

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

Qu'est-ce que le kit Cloud Foundation ?

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

Prérequis

Un compte GitHub
Docker doit être installé sur votre machine ou utiliser Cloud Shell ( installation Mac, installation Windows).
Éditeur de code pour modifier le code (par exemple, Visual Studio Code)
Connaissances de base de Git et GitHub
Expérience avec Terraform et l'infrastructure as code
Autorisation d'attribuer le rôle de 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 kit d'outils Cloud Foundation (CFT).

Vous découvrirez comment :

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

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

2. Configurer l'environnement de développement

Si vous le souhaitez, vous pouvez utiliser Cloud Shell à des fins de développement. Si vous ne souhaitez pas utiliser Cloud Shell pour contribuer au kit Cloud Foundation, 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 se passe localement sur votre machine ou dans Cloud Shell en lien avec GitHub.

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.

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. Modifier le nom associé à vos commits Git à l'aide de git config n'a d'incidence que sur les futurs commits et ne modifie pas le nom utilisé pour les commits précédents.

Vous avez correctement configuré Git et vous devriez pouvoir créer des branches, les cloner et les forker. Nous allons utiliser 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 de Google Cloud Storage pour commencer à contribuer.

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

Le plus souvent, les forks sont utilisés pour proposer des modifications à un projet d'un autre développeur ou pour utiliser son projet comme point de départ pour votre propre idée.

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

Dupliquez le dépôt.
Apportez la correction.
Envoyez une requête pull au propriétaire du projet.

Étapes pour dupliquer un dépôt CFT:

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

Vous pouvez choisir l'emplacement de la duplication. Choisissez votre profil, et le dépôt sera dupliqué.

Cloner votre fork localement

La copie que vous avez créée 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é.

Procédure de clonage de votre fork:

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

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 la copie dans votre environnement local.

Accédez à un terminal de votre VSCode ou de votre machine, puis clonez la duplication.

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

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 de code à 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 nouvelle 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 à utiliser le kit Cloud Foundation.

4. Créer un environnement de test

Le processus de développement standard du kit Cloud Foundation repose sur l'utilisation d'un projet de test isolé à des fins de test. Cette étape vous aide à créer le 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.

1. Installer le SDK Google Cloud

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

Accédez au SDK Google Cloud et téléchargez l'installateur interactif pour votre plate-forme.

2. Définir la configuration

Pour créer un environnement de test, vous avez besoin d'une organisation Google Cloud, d'un dossier de test et d'un compte de facturation. Ces valeurs doivent être définies via des 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 y télécharger une clé de compte de service. Ce compte de service doit disposer des rôles Créateur de projet, Utilisateur de compte de facturation et Lecteur d'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 référence

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 référence:

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 bien é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 que vous pouvez utiliser 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 interface système.

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és. Vous pourrez recréer une clé plus tard si nécessaire à l'aide de la même commande 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

Lorsque vous exécutez make docker_test_prepare, la sortie ci-dessous s'affiche. À la fin, vous recevrez l'ID de projet de test créé, dans lequel vous déploierez et testerez votre module Cloud Storage avec votre nouvelle fonctionnalité. Si vous rencontrez des problèmes pour associer un compte de facturation, consultez la procédure 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 maintenant 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 vos environnements de développement et de test sont configurés, ajoutons la fonctionnalité "silly_label" au module CFT de google-cloud-storage.

Vérifiez que vous êtes bien dans terraform-google-cloud-storage et ouvrez le fichier main.tf comme indiqué ci-dessous dans la structure de dossiers.

Étant donné que "silly_label" est un libellé, vous allez ajouter la fonctionnalité à la ligne 27 dans la variable "labels" dans 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 et ajoutez-le à la ligne 31 dans variables.tf. Assurez-vous d'avoir un nouveau caractère de ligne au-dessus et en dessous du bloc "variable" 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 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.

Vous devrez ajouter "silly_label" à examples/multiple-buckets/main.tf.

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

Copiez et collez la ligne "silly_label" de la variable ci-dessous à la ligne 27 du fichier main.tf sous 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 modèle pour vérifier la fonctionnalité

Vous avez ajouté la caractéristique au fichier main.tf du module, puis l'avez ajoutée à l'exemple "multiple_buckets". Vous devez maintenant tester votre fonctionnalité via un test d'intégration de plans écrit en Golang.

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

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

Dans le code ci-dessous, vous obtenez l'étiquette de chaque bucket via 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, modifications et corrections doivent être accompagnés de tests.

Les tests d'intégration sont écrits à l'aide du framework de test de modèle 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 permet de s'assurer que le module racine, les sous-modules et les modules d'exemple sont tous fonctionnels.

Dans l'exécution interactive, vous exécutez chaque étape via plusieurs commandes.

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 exécutables et des bibliothèques à partir du code source en lisant des fichiers appelés Makefiles, qui spécifient comment dériver le programme cible. Lorsque vous modifiez un fichier, 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 suivant s'affiche dans votre terminal:

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

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

Le résultat suivant 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

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'option --verbose pour obtenir des informations supplémentaires lorsque vous exécutez des tests.

Cette étape d'initialisation initialise 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)

Exécutez cft test run <EXAMPLE_NAME> --stage apply pour appliquer l'exemple de module.

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

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

Cette étape exécute la fonction de validation dans TestMultipleBuckets. La vérification est généralement effectuée en exécutant une commande gcloud pour récupérer la sortie JSON de l'état actuel d'une ressource et affirmer que l'état actuel est tel que 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.

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

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

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

Vous pouvez afficher la sortie 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

Exécutez exit pour quitter le conteneur de test.

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

Les tables "Inputs" (Entrées) et "Outputs" (Sorties) des fichiers README du module racine, des sous-modules et des modules d'exemple sont générées 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

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 stylistiques et les constructions suspectes.

De nombreux fichiers du dépôt peuvent être soumis à des fonctions d'analyse lint ou formatés pour maintenir un niveau de qualité. Pour garantir la qualité du kit Cloud Foundation, vous allez utiliser un test lint.

Exécutez la commande suivante :

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

11. Envoyer un PR sur GitHub

Maintenant que vous avez modifié votre code en local et que vous l'avez testé via les tests d'intégration, vous souhaitez le publier 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 créé au début de l'atelier de programmation, vous devez créer une demande de tirage (PR) sur le dépôt principal après avoir validé le code dans votre dépôt.

Lorsque vous envoyez une demande d'extraction, l'administrateur du dépôt est invité à examiner les modifications de code proposées. Vous pouvez également ajouter d'autres utilisateurs en tant qu'examinateurs pour obtenir des commentaires sur vos modifications de code. La demande de pull déclenchera une compilation Cloud Build qui exécutera des tests sur le dépôt.

En fonction des modifications que vous apportez au code, les examinateurs formuleront des commentaires sur votre code et demanderont des modifications si quelque chose doit être modifié sur la base des bonnes pratiques et de la documentation. L'administrateur examinera les modifications de votre code, s'assurera qu'il est conforme au dépôt et pourra à nouveau vous demander d'apporter des modifications avant de le fusionner dans le dépôt principal.

Pour valider et transférer du code vers votre branche issue de la fourchette, procédez comme suit:

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

Vos fichiers sont maintenant mis en scène. Vous allez maintenant 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.

Transférez les modifications validées dans votre dépôt local vers GitHub pour créer une demande d'extraction (PR).

$ 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 à être envoyées sous forme de demande d'extraction.

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

Dans votre navigateur Web, accédez à la page principale du dépôt.
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 demander une extraction".

Saisissez un titre et une description pour votre demande d'extraction afin de décrire les modifications apportées au code. Soyez aussi précis que possible, tout en étant concis.

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

Vous avez bien poussé votre première modification de code dans votre branche dérivée et créé votre premier PR CFT sur la branche principale.

12. Félicitations

Félicitations, vous avez ajouté une fonctionnalité à un module CFT et envoyé une demande de pull pour examen.

Vous avez ajouté une fonctionnalité à un module CFT, l'avez testée localement à l'aide d'un exemple et effectué des tests avant d'ajouter votre code à GitHub. Enfin, vous avez envoyé un PR pour examen et fusion finale dans le kit Cloud Foundation.

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