Points de contrôle
Working with Backends
/ 100
Gérer l'état Terraform
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) ;
- vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Démarrer l'atelier et se connecter à la console Google Cloud
-
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
-
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. -
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.
-
Cliquez sur Suivant.
-
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.
-
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. -
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.
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.
- 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 :
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.
- (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :
-
Cliquez sur Autoriser.
-
Vous devez à présent obtenir le résultat suivant :
Résultat :
- (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :
Résultat :
Exemple de résultat :
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.
- Dans une nouvelle fenêtre Cloud Shell, créez votre fichier de configuration
main.tf
:
- Pour récupérer l'ID de votre projet, exécutez la commande suivante :
- 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.
- Copiez le code de ressource de bucket Cloud Storage dans votre fichier de configuration
main.tf
en remplaçant les définitions des variablesproject
etname
par l'ID de votre projet :
Pour en savoir plus sur les ressources Cloud Storage, consultez la documentation Terraform.
- Ajoutez un backend local dans votre fichier
main.tf
:
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.
- Dans la barre d'outils Cloud Shell, cliquez sur Ouvrir le terminal, puis initialisez Terraform :
- Appliquez les modifications. Saisissez yes lorsque vous êtes invité à confirmer votre choix :
L'éditeur Cloud Shell devrait maintenant afficher le fichier d'état intitulé terraform.tfstate
dans le répertoire terraform/state
.
- Examinez le fichier d'état :
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é.
-
Revenez au fichier
main.tf
dans l'éditeur. Vous allez maintenant remplacer le backend local actuel par un backendgcs
. -
Pour modifier la configuration du backend local existant, copiez la configuration suivante dans votre fichier (vous allez remplacer le backend
local
) :
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.
- Initialisez à nouveau votre backend, cette fois pour migrer automatiquement l'état :
Saisissez yes lorsque vous êtes invité à confirmer votre choix.
-
Dans la console Cloud, accédez au menu de navigation, puis cliquez sur Cloud Storage > Buckets.
-
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.
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.
-
Revenez à votre bucket de stockage dans la console Cloud. Cochez la case située à côté du nom.
-
Cliquez sur l'onglet Étiquettes.
-
Cliquez sur Ajouter une étiquette. Indiquez
key
dans le champ Clé 1 etvalue
dans le champ Valeur 1. -
Cliquez sur Enregistrer.
-
Retournez dans Cloud Shell et exécutez la commande suivante pour mettre à jour le fichier d'état :
- Examinez les mises à jour :
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.
Nettoyer l'espace de travail
Avant de passer à la tâche suivante, détruisez votre infrastructure provisionnée.
- Commencez par rétablir la valeur
local
pour votre backend afin de pouvoir supprimer le bucket de stockage. Copiez la configurationgcs
et remplacez-la par ce qui suit :
- Initialisez à nouveau le backend
local
:
Saisissez yes lorsque vous êtes invité à confirmer votre choix.
- Dans le fichier
main.tf
, ajoutez l'argumentforce_destroy = true
à votre ressourcegoogle_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 :
- Appliquez les modifications :
Saisissez yes
lorsque vous êtes invité à confirmer votre choix.
- Vous pouvez maintenant détruire votre infrastructure :
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é.
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
- 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) :
- Vérifiez que le conteneur est en cours d'exécution comme suit :
- 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
- Clonez l'exemple de dépôt :
- Accédez au répertoire ci-dessous :
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.
- Initialisez votre espace de travail Terraform :
terraform init -upgrade
.
-
Dans l'éditeur Cloud Shell, accédez à
learn-terraform-import/main.tf
. -
Cherchez la ressource
provider: docker
et mettez en commentaire ou supprimez l'argumenthost
:
-
Ensuite, accédez à
learn-terraform-import/docker.tf
. -
Sous le code mis en commentaire, définissez une ressource vide
docker_container
dans votre fichierdocker.tf
, qui représente un conteneur Docker avec l'ID de ressource Terraformdocker_container.web
:
- Recherchez le nom du conteneur que vous voulez importer. Ici, il s'agit de celui que vous avez créé à l'étape précédente :
- Exécutez la commande
terraform import
suivante pour associer le conteneur Docker existant à la ressourcedocker_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 commandedocker inspect -f {{.ID}} hashicorp-learn
affiche l'ID complet du conteneur SHA256 :
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.
- Assurez-vous que le conteneur a été importé dans votre état Terraform :
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.
- Exécutez le code suivant :
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.
- Copiez l'état Terraform dans le fichier
docker.tf
:
>
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.
-
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. -
Exécutez le code suivant :
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.
- Vous pouvez désormais retirer un par un ces attributs facultatifs. Supprimez tous ces attributs, sauf ceux qui sont obligatoires :
image
,name
etports
. Une fois que vous avez supprimé ces attributs facultatifs, votre configuration doit se présenter comme suit :
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.
- Assurez-vous que les erreurs ont été résolues :
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.
- 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.
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".
- 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 fichierdocker.tf
:
- Ajoutez la configuration suivante à votre fichier
docker.tf
pour représenter cette image comme une 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.
- Créez une ressource image dans l'état :
Maintenant que Terraform a créé une ressource pour l'image, vous pouvez la référencer dans la configuration de votre conteneur.
- Modifiez la valeur de l'image dans
docker_container.web
afin de référencer la nouvelle ressource image :
- Examinez les changements :
É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
.
Gérer le conteneur avec Terraform
Utilisez Terraform pour modifier la configuration maintenant que cet outil gère le conteneur Docker.
- Dans le fichier
docker.tf
, remplacez le port externe du conteneur8080
par le port8081
:
- Appliquez la modification :
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.
- Assurez-vous que le conteneur a été remplacé par un autre conteneur avec la nouvelle configuration :
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.
- Détruisez le conteneur et l'image :
Saisissez yes
lorsque vous êtes invité à confirmer votre choix.
- Validez la destruction du conteneur :
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.