arrow_back

Interagir avec les modules Terraform

Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Interagir avec les modules Terraform

Lab 1 heure universal_currency_alt 5 crédits show_chart Intermédiaire
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Nous avons développé cet atelier avec notre partenaire HashiCorp. Vos informations personnelles pourront être partagées avec HashiCorp, le sponsor de nos ateliers, si vous avez accepté de recevoir des actualités sur les produits, des annonces et des offres sur la page de profil de votre compte.

GSP751

Google Cloud – Ateliers adaptés au rythme de chacun

Présentation

Gérer une infrastructure avec Terraform implique la création de configurations de plus en plus complexes. La complexité d'un répertoire ou d'un fichier de configuration Terraform n'a pas de limite intrinsèque. Vous pouvez donc continuer à écrire et à mettre à jour des fichiers de configuration dans un seul répertoire. Cependant, si vous procédez ainsi, un ou plusieurs des problèmes suivants pourront se poser :

  • Vous aurez de plus en plus de difficultés à comprendre et à parcourir les fichiers de configuration.
  • La mise à jour de la configuration deviendra plus risquée, puisque la mise à jour d'un bloc pourrait avoir des conséquences inattendues sur les autres blocs de la configuration.
  • La duplication de blocs de configuration similaires peut augmenter, par exemple, lorsque vous configurez des environnements de développement/préproduction/production séparés. La mise à jour de ces parties de la configuration représentera donc une charge de travail de plus en plus lourde.
  • Si vous souhaitez partager des parties de la configuration avec d'autres projets ou équipes, vous risquez de faire des erreurs en coupant et collant des blocs de configuration d'un projet dans un autre. Cette manipulation est par ailleurs difficile à gérer.

Dans cet atelier, vous allez voir comment les modules permettent de faire face à ces problèmes. Vous découvrirez également la structure d'un module Terraform, ainsi que les bonnes pratiques à adopter lorsque vous utilisez et créez des modules.

À quoi servent les modules ?

Les modules peuvent vous aider à résoudre les problèmes listés ci-dessus de différentes façons :

  • Organiser la configuration : les modules permettent de parcourir, comprendre et mettre à jour plus facilement la configuration, en regroupant des parties connexes de celle-ci. Même pour implémenter une infrastructure moyennement complexe, il peut falloir des centaines ou des milliers de lignes de configuration. Grâce aux modules, vous pouvez organiser la configuration en composants logiques.

  • Encapsuler la configuration : un autre avantage de l'utilisation de modules est que ceux-ci permettent d'encapsuler la configuration en composants logiques distincts. L'encapsulation permet d'éviter des conséquences inattendues (par exemple, modifier accidentellement d'autres infrastructures en modifiant une partie de la configuration) et réduit le risque de commettre des erreurs simples comme utiliser le même nom pour deux ressources différentes.

  • Réutiliser la configuration : écrire toute la configuration sans utiliser de code existant peut être chronophage et source d'erreurs. Lorsque vous vous servez de modules, vous gagnez du temps et réduisez le nombre d'erreurs coûteuses, car vous réutilisez une configuration écrite par vous-même, par des membres de votre équipe ou par d'autres utilisateurs de Terraform qui ont publié des modules que vous pouvez utiliser. Vous avez également la possibilité de partager avec votre équipe ou avec le grand public des modules que vous avez rédigés et de les faire bénéficier du fruit de votre travail.

  • Assurer la cohérence et garantir de bonnes pratiques : les modules permettent également d'assurer la cohérence dans vos configurations. De cette façon, non seulement les configurations complexes sont plus faciles à comprendre, mais vous êtes aussi en mesure d'appliquer les bonnes pratiques dans toute la configuration. Par exemple, les fournisseurs cloud proposent de nombreuses options pour configurer des services de stockage d'objets, comme Amazon S3 (Simple Storage Service) ou les buckets Cloud Storage de Google. De nombreux incidents de sécurité médiatisés impliquaient un stockage d'objets mal sécurisé. En raison du nombre d'options de configuration complexes disponibles, il est facile de se tromper et de mal configurer ces services.

L'utilisation de modules peut contribuer à réduire ces erreurs. Par exemple, vous pouvez en créer un pour décrire la configuration de tous les buckets du site Web public de votre organisation et un autre pour les buckets privés que les applications de journalisation utilisent. Par ailleurs, vous pouvez également vous servir d'un module si vous avez besoin de mettre à jour la configuration d'un type de ressource à un seul endroit et appliquer cette mise à jour partout où vous utilisez le module concerné.

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

  • Utiliser un module du registre
  • Créer un module

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

  • vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;
Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.
  • vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

  1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

    • Le bouton Ouvrir la console Google
    • Le temps restant
    • Les identifiants temporaires que vous devez utiliser pour cet atelier
    • Des informations complémentaires vous permettant d'effectuer l'atelier
  2. Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

    Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

    Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.
  3. Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.

  4. Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.

    Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.
  5. Accédez aux pages suivantes :

    • Acceptez les conditions d'utilisation.
    • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
    • Ne vous inscrivez pas aux essais offerts.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Vous pouvez afficher le menu qui contient la liste des produits et services Google Cloud en cliquant sur le menu de navigation en haut à gauche. Icône du menu de navigation

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

  1. Cliquez sur Activer Cloud Shell Icône Activer Cloud Shell en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

  1. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :
gcloud auth list
  1. Cliquez sur Autoriser.

  2. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :
gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Qu'est-ce qu'un module Terraform ?

Un module Terraform est un ensemble de fichiers de configuration Terraform situés dans un seul répertoire. Même une configuration simple composée d'un répertoire unique contenant un ou plusieurs fichiers .tf est un module. Lorsque vous exécutez des commandes Terraform directement à partir d'un tel répertoire, il est considéré comme le module racine. En ce sens, chaque configuration Terraform fait donc partie d'un module. Vous pouvez avoir un ensemble de fichiers de configuration Terraform très simple, comme celui-ci :

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf

Dans ce cas, lorsque vous exécutez des commandes Terraform à partir du répertoire minimal-module, son contenu est considéré comme le module racine.

Appeler des modules

Les commandes Terraform n'utilisent directement les fichiers de configuration que d'un seul répertoire, qui est généralement le répertoire de travail actuel. Cependant, votre configuration peut se servir de blocs "module" pour appeler des modules qui se trouvent dans d'autres répertoires. Lorsque Terraform rencontre un bloc "module", il charge et traite les fichiers de configuration de ce module.

Un module appelé par une autre configuration est parfois désigné comme étant le "module enfant" de cette configuration.

Modules locaux et distants

Les modules peuvent être chargés soit depuis le système de fichiers local, soit depuis une source distante. Terraform est compatible avec plusieurs sources distantes, telles que le registre Terraform, la plupart des systèmes de contrôle des versions, les URL HTTP, ainsi que les registres de modules privés Terraform Cloud ou Terraform Enterprise.

Bonnes pratiques concernant les modules

Par bien des aspects, les modules Terraform sont semblables aux concepts de bibliothèques, de packages ou de modules que l'on trouve dans la plupart des langages de programmation. De plus, ils présentent un grand nombre de leurs avantages. Comme presque tout programme informatique important, les configurations Terraform en conditions réelles devraient presque toujours utiliser des modules afin d'apporter les avantages mentionnés précédemment.

Nous recommandons à tous les utilisateurs de Terraform de se servir des modules en respectant ces bonnes pratiques :

  • Écrivez votre configuration en pensant aux modules. Même pour les configurations Terraform légèrement complexes gérées par une seule personne, les avantages des modules l'emportent sur le temps nécessaire pour apprendre à les utiliser correctement.

  • Servez-vous de modules locaux pour organiser et encapsuler le code. Même si vous n'utilisez pas ni ne publiez de modules distants, organiser votre configuration en modules dès le départ facilitera considérablement les tâches de gestion et de mise à jour de la configuration à mesure que votre infrastructure deviendra plus complexe.

  • Utilisez le registre Terraform public pour trouver des modules utiles. Ainsi, vous pouvez implémenter votre configuration rapidement et en toute confiance en bénéficiant du travail d'autres utilisateurs.

  • Publiez vos modules et partagez-les avec votre équipe. La plupart des infrastructures sont gérées par une équipe. Les modules peuvent être un atout important pour les équipes chargées de créer et de gérer une infrastructure. Comme nous l'avons évoqué précédemment, vous pouvez publier des modules en mode public ou privé. Vous découvrirez comment procéder dans un prochain atelier de cette série.

Tâche 1. Utiliser des modules du registre

Dans cette section, vous allez utiliser des modules du registre Terraform pour provisionner un exemple d'environnement dans Google Cloud. Les concepts que vous utiliserez ici s'appliqueront à tous les modules de n'importe quelle source.

  • Ouvrez la page du registre Terraform consacrée au module Terraform "network" dans un nouvel onglet ou une nouvelle fenêtre. La page se présente comme suit :

Page du registre Terraform

Cette page comporte des informations sur le module, ainsi qu'un lien vers le dépôt source. À droite de la page, vous trouverez un menu déroulant permettant de sélectionner la version du module et les instructions pour provisionner l'infrastructure à l'aide du module.

Lorsque vous appelez un module, vous devez indiquer l'argument source. Dans cet exemple, Terraform va rechercher un module dans le registre Terraform correspondant à la chaîne en question. Vous pourriez aussi utiliser une URL ou un chemin d'accès à un fichier local pour spécifier la source de vos modules. Consultez la documentation Terraform pour connaître la liste des sources de modules possibles.

L'autre argument qui apparaît ici est la version. Pour les sources compatibles, vous pouvez définir la ou les versions du module qui seront chargées grâce à l'argument version. Dans cet atelier, vous allez spécifier un numéro de version précis pour les modules que vous utiliserez. Pour découvrir d'autres façons de préciser les versions, consultez la documentation sur les modules.

Les autres arguments des blocs "module" sont traités comme des variables d'entrée des modules.

Créer une configuration Terraform

  1. Pour commencer, exécutez les commandes suivantes dans Cloud Shell pour cloner l'exemple de projet simple qui se trouve dans le dépôt GitHub contenant les modules Terraform pour Google et accédez à la branche v6.0.1 :
git clone https://github.com/terraform-google-modules/terraform-google-network cd terraform-google-network git checkout tags/v6.0.1 -b v6.0.1

Vous êtes ainsi sûr d'utiliser la bonne version.

  1. Dans la barre d'outils Cloud Shell, cliquez sur Ouvrir l'éditeur. Pour passer de Cloud Shell à l'éditeur de code et vice versa, cliquez sur Ouvrir l'éditeur ou Ouvrir le terminal selon les besoins, ou cliquez sur Ouvrir dans une nouvelle fenêtre pour laisser l'éditeur ouvert dans un autre onglet.

  2. Dans l'éditeur, accédez à terraform-google-network/examples/simple_project, puis ouvrez le fichier main.tf. Votre configuration main.tf doit se présenter comme suit :

module "test-vpc-module" { source = "terraform-google-modules/network/google" version = "~> 6.0" project_id = var.project_id # Replace this with your project ID network_name = "my-custom-mode-network" mtu = 1460 subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "us-west1" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "us-west1" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "us-west1" subnet_flow_logs = "true" subnet_flow_logs_interval = "INTERVAL_10_MIN" subnet_flow_logs_sampling = 0.7 subnet_flow_logs_metadata = "INCLUDE_ALL_METADATA" subnet_flow_logs_filter = "false" } ] }

Cette configuration comporte un bloc important :

  • Le bloc module "test-vpc-module" définit un cloud privé virtuel (VPC), qui fournira des services de mise en réseau au reste de l'infrastructure.

Définir les valeurs des variables d'entrée du module

Certaines variables d'entrée sont obligatoires, ce qui signifie que le module ne fournit pas de valeur par défaut. Vous devez indiquer une valeur explicite pour que Terraform s'exécute correctement.

  • Dans le bloc du module "test-vpc-module", vérifiez les variables d'entrée que vous définissez. Chacune de ces variables d'entrée est décrite dans le registre Terraform. Pour ce module, les variables d'entrée requises sont les suivantes :

    • network_name : le nom du réseau créé
    • project_id : l'ID du projet dans lequel le VPC sera créé
    • subnets : la liste des sous-réseaux créés

Pour pouvoir utiliser la plupart des modules, vous devez transmettre des variables d'entrée à la configuration des modules. C'est à la configuration qui appelle un module de définir ses valeurs d'entrée, qui sont transmises en tant qu'arguments au bloc "module". À part source et version, la plupart des arguments d'un bloc "module" définissent des valeurs de variables.

Sur la page du registre Terraform consacrée au module Google Cloud "network", un onglet "Inputs" (Entrées) contient la description de toutes les variables d'entrée compatibles avec ce module.

Définir les variables d'entrée racines

L'utilisation de variables d'entrée avec les modules est très semblable à l'utilisation de variables dans n'importe quelle configuration Terraform. Une pratique courante consiste à identifier les variables d'entrée du module que vous pourriez vouloir modifier par la suite, puis à créer des variables correspondantes dans le fichier variables.tf de la configuration avec des valeurs par défaut adaptées. Ces variables peuvent ensuite être transmises au bloc "module" en tant qu'arguments.

  1. Pour récupérer l'ID du projet, exécutez la commande suivante dans Cloud Shell :
gcloud config list --format 'value(core.project)'
  1. Dans l'éditeur, toujours dans le même répertoire, accédez à variables.tf.

  2. Dans la variable project_id, indiquez la valeur de sortie de la commande précédente. Vous devez respecter le format ci-dessous et définir la valeur default pour cette variable :

variable "project_id" { description = "The project ID to host the network in" default = "FILL IN YOUR PROJECT ID HERE" }
  1. Dans variables.tf, ajoutez la variable network_name. Vous pouvez utiliser example-vpc comme nom ou tout autre nom de votre choix. Vous devez respecter le format ci-dessous et définir la valeur default pour cette variable :
variable "network_name" { description = "The name of the VPC network being created" default = "example-vpc" }
  1. Dans le fichier main.tf, remplacez la valeur du paramètre network_name par var.network_name afin d'utiliser la variable que vous venez de définir.
module "test-vpc-module" { ... project_id = var.project_id network_name = var.network_name ...
  1. Dans le fichier main.tf, remplacez la région us-west1 des sous-réseaux aux lignes 35, 40 et 47 par . Ainsi, les sous-réseaux seront créés dans la région autorisée pour votre projet. Votre module doit ressembler à ce qui suit :
subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" ... .. }

Définir les valeurs de sortie racines

Les modules comportent également des valeurs de sortie, qui sont définies dans le module à l'aide du mot clé output. Vous pouvez y accéder en vous reportant à module.<MODULE NAME>.<OUTPUT NAME>. Tout comme les variables d'entrée, les valeurs de sortie du module sont listées dans l'onglet Outputs du registre Terraform.

Généralement, les valeurs de sortie des modules sont soit transmises à d'autres parties de la configuration, soit définies comme sorties dans le module racine. Nous nous intéresserons aux deux utilisations dans cet atelier.

  • Accédez au fichier outputs.tf dans le répertoire de votre configuration. Vérifiez que le fichier contient ce code :
output "network_name" { value = module.test-vpc-module.network_name description = "The name of the VPC being created" } output "network_self_link" { value = module.test-vpc-module.network_self_link description = "The URI of the VPC being created" } output "project_id" { value = module.test-vpc-module.project_id description = "VPC project id" } output "subnets_names" { value = module.test-vpc-module.subnets_names description = "The names of the subnets being created" } output "subnets_ips" { value = module.test-vpc-module.subnets_ips description = "The IP and cidrs of the subnets being created" } output "subnets_regions" { value = module.test-vpc-module.subnets_regions description = "The region where subnets will be created" } output "subnets_private_access" { value = module.test-vpc-module.subnets_private_access description = "Whether the subnets will have access to Google API's without a public IP" } output "subnets_flow_logs" { value = module.test-vpc-module.subnets_flow_logs description = "Whether the subnets will have VPC flow logs enabled" } output "subnets_secondary_ranges" { value = module.test-vpc-module.subnets_secondary_ranges description = "The secondary ranges associated with these subnets" } output "route_names" { value = module.test-vpc-module.route_names description = "The routes associated with this VPC" }

Provisionner l'infrastructure

  1. Dans Cloud Shell, accédez au répertoire simple_project :
cd ~/terraform-google-network/examples/simple_project
  1. Initialisez la configuration Terraform :
terraform init
  1. Créez votre VPC :
terraform apply
  1. Pour appliquer les modifications et continuer, répondez yes à l'invite.

Parfait ! Vous venez d'utiliser votre premier module. Vous devriez obtenir le résultat suivant pour votre configuration :

Outputs: network_name = "example-vpc" network_self_link = "https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-a68489b0625b/global/networks/example-vpc" project_id = "" route_names = [] subnets_flow_logs = [ false, true, true, ] subnets_ips = [ "10.10.10.0/24", "10.10.20.0/24", "10.10.30.0/24", ] subnets_names = [ "subnet-01", "subnet-02", "subnet-03", ] .... ....

Comprendre le fonctionnement des modules

Lorsque vous utilisez un module pour la première fois, vous devez exécuter terraform init ou terraform get pour l'installer. Quand vous exécutez l'une de ces commandes, Terraform installe le nouveau module dans le répertoire .terraform/modules du répertoire de travail de la configuration. Pour les modules locaux, Terraform crée un lien symbolique vers le répertoire du module. C'est pourquoi toute modification apportée aux modules locaux s'appliquera immédiatement, sans que vous ayez besoin de réexécuter terraform get.

Nettoyer votre infrastructure

Vous savez maintenant utiliser des modules du registre Terraform, les configurer à l'aide de variables d'entrée et récupérer leurs valeurs de sortie.

  1. Détruisez l'infrastructure que vous avez créée :
terraform destroy
  1. Répondez yes à l'invite. Terraform détruira l'infrastructure que vous avez créée.

  2. Une fois vos ressources détruites, supprimez le dossier terraform-google-network.

cd ~ rm -rd terraform-google-network -f

Cliquez sur Vérifier ma progression pour valider l'objectif. Provisionner l'infrastructure

Tâche 2. Créer un module

Lors de la dernière tâche, vous avez créé un réseau VPC dans Google Cloud à l'aide d'un module du registre Terraform. Bien qu'il soit important de savoir utiliser des modules Terraform existants, être capable d'en créer constitue un avantage pour tout utilisateur de Terraform. Nous vous recommandons de créer chaque configuration Terraform en partant du principe qu'elle pourra servir de module. Ainsi, vous concevrez des configurations flexibles, réutilisables et composables.

Comme vous le savez peut-être déjà, Terraform traite chaque configuration comme un module. Lorsque vous exécutez des commandes terraform, ou si vous utilisez Terraform Cloud ou Terraform Enterprise pour exécuter Terraform à distance, le répertoire cible contenant la configuration Terraform est considéré comme le module racine.

Dans cette tâche, vous allez créer un module pour gérer des buckets Compute Storage servant à héberger des sites Web statiques.

Structure du module

Terraform traite tout répertoire local référencé dans l'argument source d'un bloc module comme un module. Voici une structure de fichiers classique pour un nouveau module :

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf Remarque : Aucun de ces fichiers n'est obligatoire ni n'a de signification particulière pour Terraform lorsque l'outil utilise votre module. Vous pouvez créer un module avec un seul fichier .tf ou avoir recours à n'importe quelle autre structure de fichiers qui vous convient.

Chacun de ces fichiers a une fonction précise :

  • LICENSE contient la licence sous laquelle le module sera distribué. Lorsque vous partagez un module, le fichier LICENSE informe les utilisateurs des conditions de mise à disposition de ce module. Terraform ne se sert pas de ce fichier.
  • README.md contient la documentation au format Markdown expliquant comment se servir du module. Terraform n'utilise pas ce fichier, mais des services comme le registre Terraform et GitHub afficheront son contenu pour que les utilisateurs qui accèdent au registre Terraform ou à la page GitHub de votre module puissent le consulter.
  • main.tf contient l'ensemble de configurations principal du module. Vous pouvez également créer d'autres fichiers de configuration et les organiser de façon logique pour votre projet.
  • variables.tf contient les définitions des variables du module. Lorsque d'autres utilisateurs se serviront de votre module, les variables seront configurées en tant qu'arguments dans le bloc "module". Étant donné que toutes les valeurs Terraform doivent être définies, les variables n'ayant pas de valeur par défaut deviendront des arguments obligatoires. Une variable ayant une valeur par défaut peut également être fournie sous forme d'argument du module, remplaçant ainsi la valeur par défaut.
  • outputs.tf contient les définitions des sorties du module. Ces sorties sont mises à disposition de la configuration qui l'utilise. Elles servent donc souvent à transmettre des informations sur les parties de l'infrastructure définies par le module aux autres parties de la configuration.

Tenez compte de ces fichiers et veillez à ne pas les distribuer avec votre module :

  • Les fichiers terraform.tfstate et terraform.tfstate.backup contiennent votre état Terraform et permettent à Terraform de suivre la relation entre votre configuration et l'infrastructure qu'elle provisionne.
  • Le répertoire .terraform inclut les modules et plug-ins utilisés pour provisionner votre infrastructure. Ces fichiers sont propres à une instance individuelle de Terraform lorsque l'infrastructure est provisionnée. Ils ne correspondent pas à la configuration de l'infrastructure qui est définie dans les fichiers .tf.
  • Vous n'avez pas besoin de distribuer les fichiers *.tfvars avec votre module, sauf si vous l'utilisez aussi comme configuration Terraform autonome, puisque les variables d'entrée du module sont définies via des arguments du bloc "module" de la configuration.
Remarque : Si vous effectuez le suivi des modifications de votre module dans un système de contrôle des versions tel que Git, nous vous recommandons de configurer ce système pour qu'il ignore ces fichiers. Si vous souhaitez un exemple, consultez ce fichier .gitignore sur GitHub.

Créer un module

Accédez à votre répertoire d'accueil et créez le module racine en créant un fichier de configuration main.tf. Ensuite, créez un répertoire nommé modules contenant un autre dossier intitulé gcs-static-website-bucket. Vous allez travailler avec trois fichiers de configuration Terraform dans le répertoire gcs-static-website-bucket : website.tf, variables.tf et outputs.tf.

  1. Créez le répertoire du nouveau module :
cd ~ touch main.tf mkdir -p modules/gcs-static-website-bucket
  1. Accédez au répertoire du module et exécutez les commandes suivantes pour créer trois fichiers vides :
cd modules/gcs-static-website-bucket touch website.tf variables.tf outputs.tf
  1. Dans le répertoire gcs-static-website-bucket, exécutez la commande suivante pour créer un fichier nommé README.md avec le contenu suivant :
tee -a README.md <<EOF # GCS static website bucket This module provisions Cloud Storage buckets configured for static website hosting.‏ EOF Remarque : La procédure à suivre pour choisir la licence adéquate pour vos modules n'est pas abordée dans cet atelier. Ici, vous utiliserez une licence Open Source Apache 2.0.
  1. Créez un autre fichier nommé LICENSE et ajoutez-y le contenu suivant :
tee -a LICENSE <<EOF Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. EOF Remarque : Terraform ne requiert ni n'utilise aucun de ces fichiers. Il est recommandé de les avoir à disposition pour les modules qui sont susceptibles d'être partagés avec d'autres utilisateurs.

Voici à quoi doit maintenant ressembler la structure actuelle du répertoire de votre module :

main.tf modules/ └── gcs-static-website-bucket ├── LICENSE ├── README.md ├── website.tf ├── outputs.tf └── variables.tf
  1. Ajoutez cette ressource de bucket Cloud Storage au fichier website.tf du répertoire modules/gcs-static-website-bucket :
resource "google_storage_bucket" "bucket" { name = var.name project = var.project_id location = var.location storage_class = var.storage_class labels = var.labels force_destroy = var.force_destroy uniform_bucket_level_access = true versioning { enabled = var.versioning } dynamic "retention_policy" { for_each = var.retention_policy == null ? [] : [var.retention_policy] content { is_locked = var.retention_policy.is_locked retention_period = var.retention_policy.retention_period } } dynamic "encryption" { for_each = var.encryption == null ? [] : [var.encryption] content { default_kms_key_name = var.encryption.default_kms_key_name } } dynamic "lifecycle_rule" { for_each = var.lifecycle_rules content { action { type = lifecycle_rule.value.action.type storage_class = lookup(lifecycle_rule.value.action, "storage_class", null) } condition { age = lookup(lifecycle_rule.value.condition, "age", null) created_before = lookup(lifecycle_rule.value.condition, "created_before", null) with_state = lookup(lifecycle_rule.value.condition, "with_state", null) matches_storage_class = lookup(lifecycle_rule.value.condition, "matches_storage_class", null) num_newer_versions = lookup(lifecycle_rule.value.condition, "num_newer_versions", null) } } } }

Accédez à GitHub pour consulter la documentation du fournisseur.

  1. Accédez au fichier variables.tf du module et ajoutez-y le code suivant :
variable "name" { description = "The name of the bucket." type = string } variable "project_id" { description = "The ID of the project to create the bucket in." type = string } variable "location" { description = "The location of the bucket." type = string } variable "storage_class" { description = "The Storage Class of the new bucket." type = string default = null } variable "labels" { description = "A set of key/value label pairs to assign to the bucket." type = map(string) default = null } variable "bucket_policy_only" { description = "Enables Bucket Policy Only access to a bucket." type = bool default = true } variable "versioning" { description = "While set to true, versioning is fully enabled for this bucket." type = bool default = true } variable "force_destroy" { description = "When deleting a bucket, this boolean option will delete all contained objects. If false, Terraform will fail to delete buckets which contain objects." type = bool default = true } variable "iam_members" { description = "The list of IAM members to grant permissions on the bucket." type = list(object({ role = string member = string })) default = [] } variable "retention_policy" { description = "Configuration of the bucket's data retention policy for how long objects in the bucket should be retained." type = object({ is_locked = bool retention_period = number }) default = null } variable "encryption" { description = "A Cloud KMS key that will be used to encrypt objects inserted into this bucket" type = object({ default_kms_key_name = string }) default = null } variable "lifecycle_rules" { description = "The bucket's Lifecycle Rules configuration." type = list(object({ # Object with keys: # - type - The type of the action of this Lifecycle Rule. Supported values: Delete and SetStorageClass. # - storage_class - (Required if action type is SetStorageClass) The target Storage Class of objects affected by this Lifecycle Rule. action = any # Object with keys: # - age - (Optional) Minimum age of an object in days to satisfy this condition. # - created_before - (Optional) Creation date of an object in RFC 3339 (e.g. 2017-06-13) to satisfy this condition. # - with_state - (Optional) Match to live and/or archived objects. Supported values include: "LIVE", "ARCHIVED", "ANY". # - matches_storage_class - (Optional) Storage Class of objects to satisfy this condition. Supported values include: MULTI_REGIONAL, REGIONAL, NEARLINE, COLDLINE, STANDARD, DURABLE_REDUCED_AVAILABILITY. # - num_newer_versions - (Optional) Relevant only for versioned objects. The number of newer versions of an object to satisfy this condition. condition = any })) default = [] }
  1. Ajoutez une sortie à votre module dans le fichier outputs.tf :
output "bucket" { description = "The created storage bucket" value = google_storage_bucket.bucket }

Tout comme les variables, les sorties des modules ont la même fonction que dans le module racine, mais elles ne sont pas accessibles de la même façon. Les sorties du module sont accessibles en tant qu'attributs en lecture seule de l'objet du module. Cet objet se trouve dans la configuration qui appelle le module.

  1. Retournez dans le fichier main.tf du répertoire racine et ajoutez une référence au nouveau module :
module "gcs-static-website-bucket" { source = "./modules/gcs-static-website-bucket" name = var.name project_id = var.project_id location = "{{{project_0.default_region | REGION}}}" lifecycle_rules = [{ action = { type = "Delete" } condition = { age = 365 with_state = "ANY" } }] }
  1. Dans votre répertoire racine, créez un fichier outputs.tf pour le module racine :
cd ~ touch outputs.tf
  1. Ajoutez le code suivant au fichier outputs.tf :
output "bucket-name" { description = "Bucket names." value = "module.gcs-static-website-bucket.bucket" }
  1. Dans votre répertoire racine, créez un fichier variables.tf :
touch variables.tf
  1. Ajoutez le code suivant au fichier variables.tf. Définissez les valeurs par défaut des variables project_id et name sur l'ID de votre projet : .
variable "project_id" { description = "The ID of the project in which to provision resources." type = string default = "FILL IN YOUR PROJECT ID HERE" } variable "name" { description = "Name of the buckets to create." type = string default = "FILL IN A (UNIQUE) BUCKET NAME HERE" } Remarque : Le nom de votre bucket de stockage doit être unique. Nous vous recommandons d'utiliser votre nom et la date. Il s'agit généralement d'un bon moyen de créer un nom de bucket unique. Vous pouvez aussi vous servir de l'ID du projet.

Installer le module local

Chaque fois que vous ajoutez un module à une configuration, Terraform doit d'abord installer le module avant de pouvoir l'utiliser. Les commandes terraform get et terraform init permettent d'installer et de mettre à jour des modules. La commande terraform init permet également d'initialiser les backends et d'installer des plug-ins.

  1. Installez le module :
terraform init
  1. Provisionnez votre bucket :
terraform apply
  1. Répondez yes à l'invite. Votre bucket et vos autres ressources sont alors provisionnés.

Importer des fichiers dans le bucket

Vous avez maintenant configuré et utilisé votre propre module pour créer un site Web statique. Vous pourriez vouloir accéder à ce site Web statique. Pour l'instant, votre bucket est vide. Il n'y a donc rien à voir sur le site. Pour qu'il affiche des contenus, vous devez importer des objets dans le bucket. Vous pouvez importer le contenu du répertoire www du dépôt GitHub.

  1. Téléchargez les exemples de contenus dans votre répertoire d'accueil :
cd ~ curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/master/modules/aws-s3-static-website-bucket/www/index.html > index.html curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/blob/master/modules/aws-s3-static-website-bucket/www/error.html > error.html
  1. Copiez les fichiers dans le bucket et remplacez YOUR-BUCKET-NAME par le nom de votre bucket de stockage :
gsutil cp *.html gs://YOUR-BUCKET-NAME
  1. Dans un nouvel onglet de votre navigateur, accédez au site https://storage.cloud.google.com/YOUR-BUCKET-NAME/index.html (remplacez YOUR-BUCKET-NAME par le nom de votre bucket de stockage).

Vous devriez voir une page Web HTML de base indiquant Aucun élément à afficher.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un module

Nettoyer le site Web et l'infrastructure

Pour terminer, vous allez nettoyer votre projet en détruisant l'infrastructure que vous venez de créer.

  1. Détruisez vos ressources Terraform :
terraform destroy

Lorsque vous répondez yes à l'invite, Terraform détruit toutes les ressources que vous avez créées pendant cet atelier.

Félicitations !

Dans cet atelier, vous avez découvert les bases des modules Terraform et appris à utiliser un module préexistant du registre. Vous avez ensuite créé votre propre module pour concevoir un site Web statique hébergé dans un bucket Cloud Storage. Pour cela, vous avez défini des entrées, des sorties et des variables pour vos fichiers de configuration. Vous avez également appris les bonnes pratiques à suivre pour créer des modules.

Étapes suivantes et informations supplémentaires

Pour continuer à vous entraîner à utiliser Terraform, consultez ces liens :

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 26 janvier 2024

Dernier test de l'atelier : 11 décembre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.