
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Working with Backends
/ 100
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.
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.
Dans cet atelier, vous apprendrez à effectuer les tâches suivantes :
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 :
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 :
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.
Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.
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.
Vous trouverez également le mot de passe dans le panneau Détails concernant l'atelier.
Cliquez sur Suivant.
Accédez aux pages suivantes :
Après quelques instants, la console Cloud s'ouvre dans cet onglet.
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.
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.
Cliquez sur Autoriser.
Vous devez à présent obtenir le résultat suivant :
Résultat :
Résultat :
Exemple de résultat :
gcloud
, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.
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.
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.
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.
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é.
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.
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.
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.
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 :
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.
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.
main.tf
:main.tf
en remplaçant les définitions des variables project
et name
par l'ID de votre projet :Pour en savoir plus sur les ressources Cloud Storage, consultez la documentation Terraform.
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
:
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.
L'éditeur Cloud Shell devrait maintenant afficher le fichier d'état intitulé terraform.tfstate
dans le répertoire terraform/state
.
Votre ressource google_storage_bucket.test-bucket-for-state
devrait s'afficher.
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 backend gcs
.
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.
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.
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 et value
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 :
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.
Avant de passer à la tâche suivante, détruisez votre infrastructure provisionnée.
local
pour votre backend afin de pouvoir supprimer le bucket de stockage. Copiez la configuration gcs
et remplacez-la par ce qui suit :local
:Saisissez yes lorsque vous êtes invité à confirmer votre choix.
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 :Saisissez yes
lorsque vous êtes invité à confirmer votre choix.
Saisissez yes lorsque vous êtes invité à confirmer votre choix.
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 :
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.
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) :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.
Ce répertoire contient deux fichiers de configuration Terraform. Ils constituent la configuration que vous utiliserez dans ce guide :
main.tf
configure le fournisseur Docker.docker.tf
contient la configuration nécessaire pour gérer le conteneur Docker que vous avez créé précédemment.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'argument host
:
Ensuite, accédez à learn-terraform-import/docker.tf
.
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
:
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
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.
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.
Vous allez devoir créer une configuration Terraform afin de pouvoir utiliser Terraform pour gérer ce conteneur.
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.
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.
image
, name
et ports
. 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.
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.
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.
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".
<IMAGE-ID>
par l'ID de l'image du fichier docker.tf
: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.
Maintenant que Terraform a créé une ressource pour l'image, vous pouvez la référencer dans la configuration de votre conteneur.
docker_container.web
afin de référencer la nouvelle ressource image :É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
.
Utilisez Terraform pour modifier la configuration maintenant que cet outil gère le conteneur Docker.
docker.tf
, remplacez le port externe du conteneur 8080
par le port 8081
: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.
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.
Vous avez importé votre conteneur Docker et l'image utilisée pour le créer dans Terraform.
Saisissez yes
lorsque vous êtes invité à confirmer votre choix.
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 :
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.
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.
Pour vous familiariser davantage avec Terraform, consultez les ressources suivantes :
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 2025 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.