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

GSP752

Présentation

L'outil Terraform doit stocker l'état de votre infrastructure gérée et de votre configuration. Il utilise cet état pour mapper des ressources "réelles" avec votre configuration, effectuer le suivi des métadonnées et améliorer les performances de grandes infrastructures.

Cet état est stocké par défaut dans un fichier local intitulé terraform.tfstate, mais peut aussi être stocké à distance, une solution plus adaptée au travail d'équipe.

Terraform utilise cet état local pour créer des plans et modifier votre infrastructure. Avant toute opération, Terraform effectue une actualisation pour mettre à jour l'état avec la véritable infrastructure.

L'objectif principal de l'état Terraform est de stocker des liaisons entre les objets d'un système distant et les instances ressources déclarées dans votre configuration. Quand Terraform crée un objet distant en réponse à un changement de configuration, il enregistre l'identité de cet objet distant par rapport à une instance ressource particulière. Ensuite, le cas échéant, il met à jour ou supprime cet objet en réponse aux futurs changements de configuration.

Objectifs

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

• Créer un backend local
• Créer un backend Cloud Storage
• Actualiser votre état Terraform
• Importer une configuration Terraform
• Gérer la configuration importée avec Terraform

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 Cloud
   • 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 Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   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 ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau Détails concernant l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau Détails concernant l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. 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 à des essais gratuits.

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

Remarque : Pour afficher un menu contenant la liste des produits et services Google Cloud, cliquez sur le menu de navigation en haut à gauche.

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

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. 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`

5. (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.

Finalité de l'état Terraform

Terraform ne peut pas fonctionner sans état. Les utilisateurs demandent parfois s'il est possible que Terraform fonctionne sans état ou n'utilise pas d'état et inspecte uniquement les ressources cloud à chaque exécution. Le cas échéant, le fonctionnement de Terraform sans état nécessite de passer d'un emplacement (état) à un autre (le concept de remplacement) de façon très complexe. Dans cette section, nous allons vous expliquer pourquoi l'état Terraform est requis.

Mapper la configuration aux ressources "réelles"

Terraform a besoin d'une base de données pour mapper la configuration Terraform aux ressources "réelles". Quand votre configuration contient une ressource resource "google_compute_instance" "foo", Terraform utilise ce mappage pour savoir que l'instance i-abcd1234 est représentée par cette ressource.

Terraform s'attend à ce que chaque objet distant soit lié à une seule instance ressource. C'est ce qui se produit en règle générale, car Terraform se charge de créer les objets et d'enregistrer leurs identités dans l'état. Si, à la place, vous importez des objets qui ont été créés en dehors de Terraform, vous devez vérifier que chacun de ces objets est importé dans une seule instance ressource.

Si un objet distant est lié à plusieurs instances ressources, Terraform peut effectuer des actions inattendues par rapport à ces objets, car le mappage de la configuration à l'état de l'objet distant est devenu ambigu.

Métadonnées

En plus d'effectuer le suivi des mappages entre les ressources et les objets distants, Terraform doit également suivre les métadonnées telles que les dépendances des ressources.

Terraform utilise généralement la configuration pour déterminer l'ordre de dépendance. Toutefois, quand vous supprimez une ressource d'une configuration Terraform, cet outil doit savoir comment supprimer la ressource. Terraform peut voir qu'il existe un mappage pour une ressource qui ne se trouve pas dans votre fichier de configuration et envisager de le détruire. Toutefois, étant donné que la ressource n'existe plus, l'ordre ne peut pas être déterminé uniquement à partir de la configuration.

Pour garantir que tout fonctionne correctement, Terraform conserve une copie du dernier ensemble de dépendances au sein de l'état. L'outil peut tout de même déterminer le bon ordre de destruction à partir de l'état lorsque vous supprimez un ou plusieurs éléments de la configuration.

Cela pourrait être évité si Terraform connaissait l'ordre à respecter pour les types de ressources. Par exemple, Terraform pourrait savoir que les serveurs doivent être supprimés avant les sous-réseaux dont ils font partie. La complexité de cette approche deviendrait rapidement ingérable. Toutefois, en plus de comprendre la sémantique de classement de chaque ressource pour chaque cloud, Terraform doit également comprendre l'ordre à respecter pour les fournisseurs.

Terraform stocke également d'autres métadonnées pour des raisons similaires, comme un pointeur sur la configuration d'un fournisseur qui a été utilisée en dernier avec la ressource dans les cas où plusieurs fournisseurs avec alias sont présents.

Performances

En plus du mappage de base, Terraform stocke un cache des valeurs des attributs pour toutes les ressources présentes dans l'état. Il s'agit d'une fonctionnalité facultative de l'état Terraform qui n'est utilisée que pour améliorer les performances.

Lorsque vous exécutez une commande terraform plan, Terraform doit connaître l'état actuel des ressources afin de déterminer effectivement les changements nécessaires pour parvenir à la configuration de votre choix.

Pour les petites infrastructures, Terraform peut envoyer une requête à vos fournisseurs et synchroniser les derniers attributs de toutes vos ressources. Il s'agit du comportement par défaut de Terraform : pour chaque planification (plan) et application (apply), Terraform synchronisera toutes les ressources dans votre état.

Pour les infrastructures plus grandes, la méthode qui consiste à envoyer une requête à chaque ressource est trop lente. De nombreux fournisseurs cloud ne proposent pas d'API permettant d'envoyer des requêtes à plusieurs ressources en même temps et le délai aller-retour de chaque ressource est de l'ordre de centaines de millisecondes. De plus, les fournisseurs cloud ont presque toujours des limitations de débit d'API. Ainsi, Terraform ne peut envoyer de requêtes qu'à un nombre limité de ressources dans un certain laps de temps. Les utilisateurs intensifs de Terraform se servent fréquemment des options -refresh=false et -target pour contourner ces limitations. Dans ces scénarios, l'état mis en cache est traité comme un enregistrement de la vérité.

Synchronisation

Dans la configuration par défaut, Terraform stocke l'état dans un fichier du répertoire de travail actuel où Terraform a été exécuté. Cette façon de procéder fonctionne dans un premier temps, mais quand Terraform est utilisé par une équipe, il est important que tous ses membres travaillent avec le même état afin que les opérations soient appliquées aux mêmes objets distants.

Nous vous recommandons d'utiliser l'état distant pour contourner ce problème. Avec son backend d'état doté de fonctionnalités complètes, Terraform peut avoir recours au verrouillage à distance afin d'éviter que plusieurs utilisateurs s'en servent accidentellement en même temps. Ainsi, chaque exécution Terraform est lancée avec l'état le plus récent.

Verrouillage de l'état

Si cette fonctionnalité est compatible avec votre backend, Terraform verrouillera votre état pour toutes les opérations qui pourraient écrire un état. Cela évite que d'autres utilisateurs acquièrent le verrou et corrompent votre état.

Le verrouillage de l'état se produit automatiquement pour toutes les opérations qui pourraient écrire un état. Vous ne recevrez aucun message à ce sujet. Si le verrouillage de l'état échoue, Terraform interrompt l'opération. Vous pouvez désactiver le verrouillage de l'état pour la plupart des commandes avec l'option -lock, mais cela n'est pas recommandé.

Si l'acquisition du verrou prend plus de temps que prévu, Terraform affiche un message d'état. S'il n'affiche pas de message, cela signifie que le verrouillage de l'état est en cours.

Le verrouillage n'est pas compatible avec tous les backends. Consultez la liste des types de backends pour connaître leur compatibilité avec le verrouillage.

Espaces de travail

Chaque configuration Terraform a un backend associé qui définit l'exécution des opérations et l'emplacement de stockage des données persistantes telles que l'état Terraform.

Les données persistantes stockées dans le backend appartiennent à un espace de travail. Au départ, le backend n'a qu'un seul espace de travail intitulé default. Ainsi, cette configuration n'est associée qu'à un seul état Terraform.

Certains backends sont compatibles avec plusieurs espaces de travail nommés, ce qui permet d'associer différents états à une seule configuration. La configuration n'a toujours qu'un seul backend, mais plusieurs instances distinctes de cette configuration peuvent être déployées sans configurer de nouveau backend ni changer d'identifiants d'authentification.

Tâche 1 : Utiliser des backends

Dans Terraform, un backend détermine comment l'état est chargé et comment les opérations telles qu'apply sont exécutées. Cette abstraction permet de stocker les états de fichiers non locaux, de les exécuter à distance, etc.

Par défaut, Terraform utilise le backend "local". Il s'agit du comportement normal de cet outil auquel vous êtes habitué. Ce backend correspond à celui qui a été appelé lors des précédents ateliers.

Voici quelques avantages des backends :

• Travailler en équipe : les backends peuvent stocker leur état à distance et le protéger par des verrous pour empêcher les tentatives de corruption. Certains backends, comme Terraform Cloud, stockent même automatiquement l'historique de toutes les révisions de l'état.
• Informations sensibles non enregistrées sur un disque : l'état est récupéré à la demande auprès des backends et n'est stocké qu'en mémoire.
• Opérations à distance : pour les grandes infrastructures ou certains changements, la commande terraform apply peut prendre beaucoup de temps. Certains backends sont compatibles avec les opérations à distance : concrètement, cela signifie qu'elles peuvent s'exécuter, même lorsque vous éteignez votre ordinateur. Ce mode de fonctionnement associé au stockage et au verrouillage de l'état à distance (décrits ci-dessus) favorise le travail en équipe.

Les backends sont entièrement facultatifs : vous pouvez vous servir de Terraform sans avoir à vous familiariser avec les backends ni les utiliser. Toutefois, ils permettent de résoudre les problèmes qui touchent les équipes à une certaine échelle. Si vous travaillez seul, vous pouvez mener vos tâches à bien sans jamais utiliser de backends.

Même si vous prévoyez de ne vous servir que du backend "local", vous avez tout à gagner à vous informer sur les backends, car vous pouvez également modifier le comportement du backend local.

Ajouter un backend local

Dans cette section, vous allez configurer un backend local.

Quand vous configurez un backend pour la première fois (c'est-à-dire lorsqu'aucun backend n'est défini et que vous devez en configurer un explicitement), Terraform vous donne la possibilité de migrer votre état vers le nouveau backend. Ainsi, vous pouvez utiliser des backends sans perdre d'état.

Par souci de vigilance, nous vous conseillons également de toujours sauvegarder manuellement votre état. Pour ce faire, il vous suffit de copier votre fichier terraform.tfstate à un autre emplacement. Le processus d'initialisation devrait aussi créer une sauvegarde, mais il vaut mieux redoubler de prudence.

Configurer un backend pour la première fois et modifier sa configuration sont deux tâches similaires : vous devez créer la configuration et exécuter la commande terraform init. Terraform vous guidera pour le reste de la procédure.

1. Dans une nouvelle fenêtre Cloud Shell, créez votre fichier de configuration main.tf :

touch main.tf

2. Pour récupérer l'ID de votre projet, exécutez la commande suivante :

gcloud config list --format 'value(core.project)'

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

4. Copiez le code de ressource de bucket Cloud Storage dans votre fichier de configuration main.tf en remplaçant les définitions des variables project et name par l'ID de votre projet :

provider "google" { project = "# REPLACE WITH YOUR PROJECT ID" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "# REPLACE WITH YOUR PROJECT ID" location = "US" uniform_bucket_level_access = true }

Pour en savoir plus sur les ressources Cloud Storage, consultez la documentation Terraform.

5. Ajoutez un backend local dans votre fichier main.tf :

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

Ce code fera référence au fichier terraform.tfstate qui se trouve dans le répertoire terraform/state. Pour indiquer un autre chemin d'accès au fichier, modifiez la variable path.

Le backend local stocke l'état dans le système de fichiers local, verrouille cet état à l'aide des API système et effectue des opérations localement.

Terraform doit initialiser tous les backends configurés avant de les utiliser. Pour cela, vous allez avoir besoin de la commande terraform init. Tout d'abord, l'un des membres de votre équipe doit exécuter la commande terraform init sur n'importe quelle configuration Terraform. Vous pouvez l'exécuter plusieurs fois et effectuer toutes les actions de configuration requises pour les environnements Terraform, y compris initialiser le backend.

Vous devez exécuter la commande init :

• sur tout nouvel environnement qui configure un backend ;
• pour tout changement apporté à la configuration du backend (type de backend compris) ;
• pour supprimer l'intégralité de la configuration d'un backend.

Vous n'avez pas besoin de vous souvenir de tous ces cas d'utilisation. En effet, Terraform détecte quand une initialisation est requise et affiche un message d'erreur lorsque la situation se présente. Terraform ne s'initialise pas automatiquement, car il peut avoir besoin de recevoir des informations supplémentaires de la part de l'utilisateur, de réaliser des migrations d'état, etc.

6. Dans la barre d'outils Cloud Shell, cliquez sur Ouvrir le terminal, puis initialisez Terraform :

terraform init

7. Appliquez les modifications. Saisissez yes lorsque vous êtes invité à confirmer votre choix :

terraform apply

L'éditeur Cloud Shell devrait maintenant afficher le fichier d'état intitulé terraform.tfstate dans le répertoire terraform/state.

8. Examinez le fichier d'état :

terraform show

Votre ressource google_storage_bucket.test-bucket-for-state devrait s'afficher.

Ajouter un backend Cloud Storage

Un backend Cloud Storage stocke l'état en tant qu'objet dans un préfixe configurable au sein d'un bucket donné sur Cloud Storage. Ce backend est également compatible avec le verrouillage d'état. Cette fonctionnalité consiste à verrouiller votre état pour toutes les opérations susceptibles d'écrire un état. Cela évite que d'autres utilisateurs acquièrent le verrou et corrompent votre état.

Le verrouillage de l'état se produit automatiquement pour toutes les opérations qui pourraient écrire un état. Vous ne recevrez aucun message à ce sujet. Si le verrouillage de l'état échoue, Terraform interrompt l'opération. Vous pouvez désactiver le verrouillage de l'état pour la plupart des commandes avec l'option -lock, mais cela n'est pas recommandé.

1. Revenez au fichier main.tf dans l'éditeur. Vous allez maintenant remplacer le backend local actuel par un backend gcs.

2. Pour modifier la configuration du backend local existant, copiez la configuration suivante dans votre fichier (vous allez remplacer le backend local) :

terraform { backend "gcs" { bucket = "# REPLACE WITH YOUR BUCKET NAME" prefix = "terraform/state" } } Remarque : Veillez à mettre à jour la définition de la variable bucket. Si vous n'avez pas modifié la configuration, il s'agira du nom (name) de la ressource google_storage_bucket. Ce bucket hébergera le fichier d'état.

3. Initialisez à nouveau votre backend, cette fois pour migrer automatiquement l'état :

terraform init -migrate-state

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

4. Dans la console Cloud, accédez au menu de navigation, puis cliquez sur Cloud Storage > Buckets.

5. Cliquez sur votre bucket et accédez au fichier terraform/state/default.tfstate. Votre fichier d'état se trouve désormais dans un bucket Cloud Storage.

Remarque : Si vous ne souhaitez plus utiliser de backend, il vous suffit de supprimer la configuration dans le fichier. Terraform détectera cette suppression comme tout autre changement et vous invitera à effectuer une réinitialisation.

Lors de cette opération, Terraform vous demandera si vous souhaitez migrer votre état vers l'état local normal. Après la réinitialisation, Terraform retrouve son comportement par défaut.

Actualiser l'état

La commande terraform refresh est utilisée pour rapprocher l'état connu par Terraform (via son fichier d'état) de l'infrastructure réelle. Elle permet de détecter toute dérive par rapport au dernier état connu et de mettre à jour le fichier d'état.

Cette commande modifie le fichier d'état, mais pas l'infrastructure. Le fait de modifier l'état peut entraîner des changements lors de l'application ou du plan suivants.

1. Revenez à votre bucket de stockage dans la console Cloud. Cochez la case située à côté du nom.

2. Cliquez sur l'onglet Étiquettes.

3. Cliquez sur Ajouter une étiquette. Indiquez key dans le champ Clé 1 et value dans le champ Valeur 1.

4. Cliquez sur Enregistrer.

5. Retournez dans Cloud Shell et exécutez la commande suivante pour mettre à jour le fichier d'état :

terraform refresh

6. Examinez les mises à jour :

terraform show

La paire clé/valeur "key" = "value" devrait s'afficher dans l'attribut des étiquettes de la configuration.

Cliquez sur Vérifier ma progression pour valider l'objectif. Utiliser des backends

Nettoyer l'espace de travail

Avant de passer à la tâche suivante, détruisez votre infrastructure provisionnée.

1. Commencez par rétablir la valeur local pour votre backend afin de pouvoir supprimer le bucket de stockage. Copiez la configuration gcs et remplacez-la par ce qui suit :

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

2. Initialisez à nouveau le backend local :

terraform init -migrate-state

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

3. Dans le fichier main.tf, ajoutez l'argument force_destroy = true à votre ressource google_storage_bucket. Quand vous supprimez un bucket, cette option booléenne supprime tous les objets qu'il contient. Si vous essayez de supprimer un bucket comportant des objets, Terraform fera échouer cette exécution. La configuration de votre ressource doit se présenter comme suit :

resource "google_storage_bucket" "test-bucket-for-state" { name = "qwiklabs-gcp-03-c26136e27648" location = "US" uniform_bucket_level_access = true force_destroy = true }

4. Appliquez les modifications :

terraform apply

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

5. Vous pouvez maintenant détruire votre infrastructure :

terraform destroy

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

Tâche 2 : Importer une configuration Terraform

Dans cette section, vous allez importer une image et un conteneur Docker existants dans un espace de travail Terraform vide. Ce faisant, vous allez découvrir les stratégies et les éléments à prendre en compte pour importer une infrastructure réelle dans Terraform.

Le workflow Terraform par défaut implique de créer et de gérer une infrastructure entièrement avec Terraform.

• Écrivez une configuration Terraform qui définit l'infrastructure que vous voulez créer.

• Examinez le plan Terraform pour vous assurer que la configuration permet d'obtenir l'état et l'infrastructure attendus.

• Appliquez la configuration pour créer votre infrastructure et votre état Terraform.

Après avoir créé l'infrastructure avec Terraform, vous pouvez mettre à jour la configuration et le plan, et appliquer ces changements. À terme, vous utiliserez Terraform pour détruire l'infrastructure quand vous n'en aurez plus besoin. Dans ce workflow, nous partons du principe que Terraform va créer une infrastructure entièrement nouvelle.

Toutefois, vous devrez peut-être gérer une infrastructure qui n'a pas été créée par Terraform. La commande "terraform import" résout ce problème en chargeant des ressources compatibles dans l'état de votre espace de travail Terraform.

Cependant, la commande "import" ne génère pas automatiquement la configuration permettant de gérer l'infrastructure. De ce fait, l'importation d'une infrastructure existante dans Terraform est un processus en plusieurs phases.

Voici donc les cinq grandes étapes à suivre :

• Identifiez l'infrastructure existante à importer.
• Importez cette infrastructure dans votre état Terraform.
• Écrivez une configuration Terraform correspondant à cette infrastructure.
• Examinez le plan Terraform pour vous assurer que la configuration correspond à l'état et à l'infrastructure attendus.
• Appliquez la configuration pour mettre à jour votre état Terraform.

Dans cette section, vous allez d'abord créer un conteneur Docker dans la CLI Docker. Ensuite, vous l'importerez dans un nouvel espace de travail Terraform. Vous mettrez à jour la configuration du conteneur avec Terraform, puis la détruirez lorsque vous aurez terminé.

Avertissement : Le fait d'importer l'infrastructure implique de manipuler l'état Terraform, ce qui risque de laisser les projets Terraform existants dans un état non valide. Sauvegardez votre fichier terraform.tfstate et votre répertoire .terraform avant d'utiliser la commande "terraform import" pour un projet Terraform réel et stockez-les en lieu sûr.

Créer un conteneur Docker

1. Créez un conteneur intitulé hashicorp-learn à l'aide de la dernière image NGINX de Docker Hub et prévisualisez le conteneur sur la machine virtuelle Cloud Shell sur le port 80 (HTTP) :

docker run --name hashicorp-learn --detach --publish 8080:80 nginx:latest

2. Vérifiez que le conteneur est en cours d'exécution comme suit :

docker ps

3. Dans le volet Cloud Shell, cliquez sur Aperçu sur le Web, puis sur Prévisualiser sur le port 8080.

Cloud Shell ouvre l'URL d'aperçu sur son service proxy dans une nouvelle fenêtre de navigateur et affiche la page d'index NGINX par défaut. Vous disposez désormais d'une image et d'un conteneur Docker que vous pouvez importer dans votre espace de travail et gérer avec Terraform.

Importer le conteneur dans Terraform

1. Clonez l'exemple de dépôt :

git clone https://github.com/hashicorp/learn-terraform-import.git

2. Accédez au répertoire ci-dessous :

cd learn-terraform-import

Ce répertoire contient deux fichiers de configuration Terraform. Ils constituent la configuration que vous utiliserez dans ce guide :

• Le fichier main.tf configure le fournisseur Docker.
• Le fichier docker.tf contient la configuration nécessaire pour gérer le conteneur Docker que vous avez créé précédemment.

3. Initialisez votre espace de travail Terraform :

terraform init Remarque : Si vous obtenez un message d'erreur du type Error: Failed to query available provider packages (Erreur : Échec de l'interrogation des packages de fournisseurs disponibles), exécutez la commande terraform init -upgrade.

4. Dans l'éditeur Cloud Shell, accédez à learn-terraform-import/main.tf.

5. Cherchez la ressource provider: docker et mettez en commentaire ou supprimez l'argument host :

provider "docker" { # host = "npipe:////.//pipe//docker_engine" } Remarque : Cette solution est actuellement utilisée pour résoudre un problème connu lié à une erreur d'initialisation de Docker.

6. Ensuite, accédez à learn-terraform-import/docker.tf.

7. Sous le code mis en commentaire, définissez une ressource vide docker_container dans votre fichier docker.tf, qui représente un conteneur Docker avec l'ID de ressource Terraform docker_container.web :

resource "docker_container" "web" {}

8. Recherchez le nom du conteneur que vous voulez importer. Ici, il s'agit de celui que vous avez créé à l'étape précédente :

docker ps

9. Exécutez la commande terraform import suivante pour associer le conteneur Docker existant à la ressource docker_container.web que vous venez de créer. Dans la commande "terraform import", vous devez inclure l'ID de cette ressource Terraform et l'ID complet du conteneur Docker. La commande docker inspect -f {{.ID}} hashicorp-learn affiche l'ID complet du conteneur SHA256 :

terraform import docker_container.web $(docker inspect -f {{.ID}} hashicorp-learn) Remarque : L'ID accepté par terraform import varie selon le type de ressource et est indiqué dans la documentation du fournisseur pour toutes les ressources pouvant être importées dans Terraform. Pour cet exemple, consultez la documentation du fournisseur Docker.

10. Assurez-vous que le conteneur a été importé dans votre état Terraform :

terraform show

Cet état contient toutes les informations dont Terraform a connaissance sur le conteneur Docker que vous venez d'importer. Toutefois, la commande "terraform import" ne crée pas de configuration pour cette ressource.

Créer une configuration

Vous allez devoir créer une configuration Terraform afin de pouvoir utiliser Terraform pour gérer ce conteneur.

1. Exécutez le code suivant :

terraform plan Remarque : Terraform affichera des erreurs pour les arguments obligatoires manquants image et name. L'outil ne peut pas générer de plan pour une ressource qui ne contient pas tous les arguments obligatoires.

Il existe deux façons de mettre à jour la configuration dans docker.tf afin qu'elle corresponde à l'état que vous avez importé. Vous pouvez accepter l'état actuel complet de la ressource dans votre configuration ou sélectionner les attributs obligatoires un par un dans votre configuration. La méthode la plus judicieuse dépend des circonstances.

• Il est souvent plus rapide d'utiliser l'état actuel, mais cela peut créer une configuration d'un niveau de verbosité excessif. En effet, chaque attribut est alors inclus dans l'état, qu'il soit nécessaire ou non de l'intégrer dans votre configuration.

• Si vous sélectionnez les attributs obligatoires un par un, vous pouvez obtenir une configuration plus facilement gérable, mais vous devez alors savoir quels attributs doivent être définis dans la configuration.

Dans cet atelier, vous allez utiliser l'état actuel comme ressource.

2. Copiez l'état Terraform dans le fichier docker.tf :

terraform show -no-color > docker.tf Remarque : Le symbole > remplacera l'intégralité du contenu du fichier docker.tf par le résultat de la commande terraform show. Bien que cette méthode fonctionne pour cet exemple, l'importation d'une ressource dans une configuration qui gère déjà des ressources implique que vous modifiiez le résultat de la commande terraform show afin de supprimer les ressources dont vous ne voulez pas remplacer l'intégralité de la configuration et de fusionner les nouvelles ressources avec votre configuration.

3. Inspectez le fichier docker.tf pour voir si son contenu a été remplacé par la sortie de la commande "terraform show" que vous venez d'exécuter.

4. Exécutez le code suivant :

terraform plan

Terraform affichera des avertissements et des erreurs concernant un argument obsolète ("links") et plusieurs arguments en lecture seule (ip_address, network_data, gateway, ip_prefix_length et id).

Ces arguments en lecture seule sont des valeurs que Terraform stocke dans son état pour les conteneurs Docker, mais qu'il ne peut pas définir dans la configuration puisqu'ils sont gérés en interne par Docker. Terraform peut définir l'argument "links" avec la configuration tout en affichant un avertissement, car il est obsolète et risque d'être incompatible avec de futures versions du fournisseur Docker.

Étant donné que la méthode illustrée ici permet de charger tous les attributs représentés dans l'état Terraform, votre configuration inclut des attributs facultatifs dont les valeurs sont identiques à celles définies par défaut. Les attributs facultatifs et leurs valeurs par défaut varient d'un fournisseur à l'autre et sont indiqués dans la documentation du fournisseur.

5. Vous pouvez désormais retirer un par un ces attributs facultatifs. Supprimez tous ces attributs, sauf ceux qui sont obligatoires : image, name et ports. Une fois que vous avez supprimé ces attributs facultatifs, votre configuration doit se présenter comme suit :

resource "docker_container" "web" { image = "sha256:87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02" name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

Au moment d'importer l'infrastructure réelle, consultez la documentation du fournisseur pour connaître le rôle de chaque argument. Cela vous aidera à déterminer comment traiter les erreurs et les avertissements générés lors de l'étape du plan. Par exemple, vous pouvez lire les explications concernant l'argument links dans la documentation du fournisseur Docker.

6. Assurez-vous que les erreurs ont été résolues :

terraform plan

Le plan devrait maintenant s'exécuter correctement. Comme vous pouvez le constater, le plan indique que Terraform mettra à jour le conteneur pour ajouter les attributs attach, logs, must_run et start.

Terraform se sert de ces attributs pour créer des conteneurs Docker, mais Docker ne les stocke pas. Par conséquent, la commande terraform import n'a pas chargé leurs valeurs dans l'état. Quand vous planifiez et appliquez votre configuration, le fournisseur Docker attribue les valeurs par défaut de ces attributs et les enregistre dans l'état. Toutefois, elles n'ont pas d'incidence sur le conteneur en cours d'exécution.

7. Appliquez les changements et terminez de synchroniser votre configuration ainsi que votre état Terraform mis à jour avec le conteneur Docker qu'ils représentent. Saisissez yes lorsque vous êtes invité à confirmer votre choix.

terraform apply

Votre fichier de configuration, votre état Terraform et le conteneur sont désormais tous synchronisés. Vous pouvez utiliser Terraform pour gérer le conteneur Terraform comme à votre habitude.

Créer une ressource image

Dans certains cas, vous pouvez placer toutes les ressources sous le contrôle de Terraform à l'aide de la commande terraform import. C'est souvent ce qu'il se passe pour les ressources définies par un tag ou un identifiant uniques, comme les images Docker.

Dans votre fichier docker.tf, la ressource docker_container.web spécifie l'ID haché SHA256 de l'image utilisée pour créer le conteneur. C'est ainsi que Docker stocke l'ID de l'image en interne. La commande terraform import a donc chargé l'ID de l'image directement dans votre état. Toutefois, l'ID de l'image n'est pas aussi lisible que son tag ou son nom, et il peut ne pas correspondre à votre intent. Par exemple, vous pouvez utiliser la dernière version de l'image "nginx".

1. Pour récupérer le nom du tag de l'image, exécutez la commande suivante en remplaçant <IMAGE-ID> par l'ID de l'image du fichier docker.tf :

docker image inspect -f {{.RepoTags}}

2. Ajoutez la configuration suivante à votre fichier docker.tf pour représenter cette image comme une ressource :

resource "docker_image" "nginx" { name = "nginx:latest" } Remarque : Ne remplacez pas la valeur de l'image dans la ressource docker_container.web pour le moment. Si vous ne respectez pas cette consigne, Terraform détruira et recréera votre conteneur. Comme Terraform n'a pas encore chargé la ressource docker_image.nginx dans l'état, il ne dispose pas d'ID d'image à comparer à l'ID codé en dur. Terraform partira donc du principe que le conteneur doit être remplacé. Pour pallier cette situation, commencez par créer l'image, puis mettez à jour le conteneur afin qu'il l'utilise, comme illustré dans cet atelier.

3. Créez une ressource image dans l'état :

terraform apply

Maintenant que Terraform a créé une ressource pour l'image, vous pouvez la référencer dans la configuration de votre conteneur.

4. Modifiez la valeur de l'image dans docker_container.web afin de référencer la nouvelle ressource image :

resource "docker_container" "web" { image = docker_image.nginx.image_id name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

5. Examinez les changements :

terraform apply

Étant donné que docker_image.nginx.latest correspondra à l'ID de l'image codé en dur que vous avez remplacé, vous ne verrez aucun changement à ce stade après avoir exécuté la commande terraform apply.

Remarque : Si l'ID de l'image pour le tag "nginx:latest" a changé entre la création initiale du conteneur Docker et l'exécution de cette commande, le conteneur sera détruit et recréé avec la nouvelle image.

Gérer le conteneur avec Terraform

Utilisez Terraform pour modifier la configuration maintenant que cet outil gère le conteneur Docker.

1. Dans le fichier docker.tf, remplacez le port externe du conteneur 8080 par le port 8081 :

resource "docker_container" "web" { name = "hashicorp-learn" image = docker_image.nginx.image_id ports { external = 8081 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

2. Appliquez la modification :

terraform apply

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

Terraform détruira alors le conteneur et le recréera avec la nouvelle configuration de port.

3. Assurez-vous que le conteneur a été remplacé par un autre conteneur avec la nouvelle configuration :

docker ps

Comme vous pouvez le constater, l'ID du conteneur a changé. En modifiant la configuration du port, vous avez détruit et recréé le conteneur. Celui-ci est donc entièrement nouveau.

Détruire l'infrastructure

Vous avez importé votre conteneur Docker et l'image utilisée pour le créer dans Terraform.

1. Détruisez le conteneur et l'image :

terraform destroy

Saisissez yes lorsque vous êtes invité à confirmer votre choix.

2. Validez la destruction du conteneur :

docker ps --filter "name=hashicorp-learn" Remarque : Étant donné que vous avez ajouté l'image à votre configuration Terraform et au conteneur, l'image sera supprimée de Docker et du conteneur. Si un autre conteneur utilisait la même image, la destruction échouerait. Souvenez-vous que lorsque vous importez une ressource dans Terraform, l'outil gère l'intégralité du cycle de vie de cette ressource, y compris sa destruction.

Limites et autres considérations

Lorsque vous importez des ressources dans Terraform, vous devez prendre en compte plusieurs aspects importants.

La commande "terraform import" permet uniquement de connaître l'état actuel de l'infrastructure comme indiqué par le fournisseur Terraform, mais pas de savoir :

• si l'infrastructure fonctionne correctement ;
• quel est l'intent de l'infrastructure ;
• quelles sont les modifications apportées à l'infrastructure qui ne sont pas contrôlées par Terraform (par exemple, l'état du système de fichiers d'un conteneur Docker).

L'importation nécessite des étapes manuelles qui peuvent entraîner des erreurs, en particulier si la personne qui importe les ressources manque de contexte sur la création initiale de ces ressources.

Lors de l'importation, le fichier d'état Terraform est manipulé. Par conséquent, nous vous recommandons de créer une sauvegarde avant d'importer la nouvelle infrastructure.

La commande "terraform import" ne détecte pas ni ne génère de relations entre les infrastructures.

Terraform n'identifie pas les attributs par défaut qui n'ont pas besoin d'être définis dans votre configuration.

La commande "terraform import" n'est pas compatible avec tous les fournisseurs et toutes les ressources.

Le fait d'importer l'infrastructure dans Terraform ne signifie pas qu'elle peut être détruite et recréée par cet outil. Par exemple, l'infrastructure importée peut reposer sur une autre configuration ou infrastructure non gérées.

Respecter les bonnes pratiques concernant l'IaC (Infrastructure as Code), telles que le concept de l'infrastructure immuable, contribue à éviter un grand nombre de ces problèmes, mais il est rare qu'une infrastructure créée manuellement suive ces bonnes pratiques.

Les outils comme Terraformer peuvent automatiser quelques étapes manuelles associées à l'importation de l'infrastructure. Toutefois, ils ne font pas partie de Terraform et ne sont ni approuvés ni soutenus par HashiCorp.

Félicitations !

Dans cet atelier, vous avez appris à gérer les backends et l'état avec Terraform. Vous avez créé des backends locaux et Cloud Storage pour gérer un fichier d'état, actualisé un état et importé une configuration dans Terraform. Vous avez ensuite mis à jour la configuration et vous l'avez modifiée manuellement pour gérer entièrement le conteneur Docker avec Terraform.

Étapes suivantes et informations supplémentaires

Pour vous familiariser davantage avec Terraform, consultez les ressources suivantes :

• HashiCorp sur Google Cloud Marketplace
• HashiCorp Learn
• Communauté Terraform
• Exemples d'utilisation de Terraform avec Google

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.