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 bref, le kit Cloud Foundation fournit des modèles recommandés pour vous aider à vous lancer rapidement sur Google Cloud Platform. Dans ce tutoriel, vous allez apprendre à contribuer au kit Cloud Foundation.

Prérequis

Un compte GitHub
Docker installé sur votre machine ou utilisant Cloud Shell ( installation sur Mac, installation pour Windows)
Éditeur de code pour modifier le code (exemple: Visual Studio Code)
Connaissances de base sur Git et GitHub
Connaissance pratique de Terraform et de l'Infrastructure as Code
Autorisation permettant d'accorder 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 Cloud Foundation.

Vous découvrirez comment :

Configurer un environnement de développement pour contribuer au kit Cloud Foundation
Ajouter une fonctionnalité à un module du kit Cloud Foundation
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 le 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 une étiquette appelée "silly_label", qui sera automatiquement ajoutée à tous les buckets créés via le module CFT de GCS. Vous pourrez également écrire des tests pour valider votre fonctionnalité et garantir son intégration de bout en bout.

2. Configurer un 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 toutes les opérations liées à GitHub qui se produisent localement sur votre machine ou dans Cloud Shell.

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 ordinateur, 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 est différent de votre nom d'utilisateur GitHub.

Vous pouvez modifier le nom associé à vos commits Git à l'aide de la commande git config. La modification du nom associé à vos commits Git à l'aide de git config n'affectera que les futurs commits et ne modifiera pas le nom utilisé pour les commits antérieurs.

Vous avez correctement configuré Git, et vous devriez pouvoir dupliquer, créer et cloner des branches. Nous utiliserons beaucoup Git dans cet atelier de programmation.

3. Dépôt GCS de Fork CFT

Dupliquer un dépôt Cloud Foundation

Vous avez configuré Git sur votre ordinateur local 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 copie est une copie d'un dépôt. La duplication d'un dépôt vous permet de tester librement les modifications sans affecter le projet d'origine.

Le plus souvent, les fourchettes sont utilisées pour proposer des modifications au projet de quelqu'un d'autre ou pour utiliser le projet de quelqu'un d'autre comme point de départ de votre propre idée.

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

Dupliquez le dépôt.
Résolvez le problème.
Envoyez une demande d'extraction 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 serez invité à indiquer l'emplacement souhaité de la duplication. Sélectionnez votre profil, et le dépôt sera dupliqué.

Cloner votre copie 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é.

Étapes pour cloner votre copie:

Ouvrez votre navigateur Web et accédez à votre copie sur terraform-google-modules/terraform-google-cloud-storage.
Dans l'angle supérieur droit se trouve le "Code" cliquez dessus.

Après avoir cliqué sur le "Code", cliquez sur le bouton "Copier" pour copier l'URL de la duplication. 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 duplication localement, vous devez accéder à votre dépôt, créer une nouvelle branche et modifier le 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 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 à travailler sur 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 ordinateur à 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, puis 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 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 télécharger une clé de compte de service dans votre environnement de test. Ce compte de service doit disposer des rôles Créateur de projet, Utilisateur de compte de facturation et Lecteur d'organisation. Cette procédure vous permet de 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 source

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 sur votre projet source:

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 Attribuer les rôles Créateur de projet, Utilisateur de compte de facturation et Lecteur d'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 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é. Si nécessaire, vous pourrez recréer une clé ultérieurement à l'aide de la 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

Le résultat ci-dessous s'affiche lorsque vous exécutez make docker_test_prepare. À la fin, vous recevez l'ID de 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 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 venez de créer un projet de test référencé par project_id, comme vous pouvez le voir dans le résultat de la console. Votre environnement de développement et de test est configuré.

5. Ajouter une nouvelle fonctionnalité au module du kit Cloud Foundation

Maintenant que vos environnements de développement et de test sont configurés, ajoutez l'élément "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.

Depuis "silly_label" est un libellé, ajoutez l'élément géographique à 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" au 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é à un 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.

"silly_label" doit être ajouté au répertoire "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" 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 plan pour vérifier la fonctionnalité

Vous avez ajouté la fonctionnalité 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é "silly_label" sur 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 le kit Cloud Foundation

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 du plan 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 exemples de modules, afin de s'assurer que le module racine, les sous-modules et les exemples de modules fonctionnent tous correctement.

Lors d'une 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 et des bibliothèques exécutables à partir du code source en lisant des fichiers appelés Makefiles, qui spécifient comment extraire 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 ci-dessous 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 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

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 de 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. Généralement, la vérification s'effectue en exécutant une commande gcloud afin de récupérer la sortie JSON de l'état actuel d'une ressource et en affirmant 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 supprimer l'exemple.

Cette étape détruit l'infrastructure que vous avez créée aux étapes précédentes. Cette étape détruira également les buckets GCS créés dans le projet, ainsi que l'étiquette que vous avez ajoutée 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 d'entrées et de sorties dans les fichiers README du module racine, des sous-modules et des exemples de modules sont automatiquement générées en fonction des variables et outputs des modules respectifs. Ces tables doivent être actualisées en cas de modification des interfaces des modules.

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 lint 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 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 localement et que vous l'avez testé lors des tests d'intégration, vous pouvez le publier dans le dépôt maître.

Pour rendre votre code disponible dans le dépôt maître, vous devez valider les modifications de code dans votre branche et les transférer vers le dépôt maître. Pour que votre code soit ajouté au dépôt principal que vous avez dupliqué au début de l'atelier de programmation, vous devez envoyer une demande d'extraction (PR) dans le dépôt maître 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 les modifications apportées à votre code. Le PR déclenchera une compilation Cloud Build qui exécutera des tests dans 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 apportées à votre code, s'assurera que celui-ci est conforme au dépôt et pourra à nouveau vous demander d'apporter des modifications avant de fusionner votre code dans le dépôt maître.

Exécutez les étapes suivantes pour valider le code dans votre branche dupliquée et transférer le code vers votre branche dupliquée:

La première étape consiste à ajouter les fichiers modifiés dans le 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 à présent en préproduction. 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.

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

Vous pouvez maintenant envoyer vos modifications de code pour une demande d'extraction.

Procédez comme suit pour créer une demande d'extraction 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.
Vous verrez une suggestion via une bannière vous invitant à ouvrir un communiqué de presse depuis votre copie. Cliquez sur "Compare and pull request" (Comparer et demander d'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 en vue de son examen, cliquez sur "Créer une demande d'extraction".
Vous verrez que les déclencheurs Cloud Build sont en cours d'exécution et sont déclenchés en raison du PR.
Si vous rencontrez des problèmes, consultez les documents officiels GitHub sur l'ouverture des demandes d'extraction à partir des duplications.

Vous venez d'appliquer votre première modification de code à votre branche dupliqué et de générer votre premier PR CFT sur la branche principale.

12. Félicitations

Félicitations ! Vous venez d'ajouter une fonctionnalité à un module du kit Cloud Foundation et d'envoyer une demande d'approbation pour examen.

Vous avez ajouté une fonctionnalité à un module du kit Cloud Foundation, l'avez testée en local via un exemple et effectué des tests avant de valider votre code sur GitHub. Enfin, vous avez envoyé un PR pour examen et fusion finale dans le kit Cloud Foundation.

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