État profond : Extraire le code et les ressources du fichier d’état Terraform | de Joe Tavin | janvier 2023

Astuces Terraform — #1

HashiCorp Terraform est un outil formidable et utile que tout praticien DevOps devrait connaître pour créer et maintenir Infrastructure en tant que code. Nous utilisons largement Terraform ici à GrandPanda pour gérer et définir entièrement notre infrastructure SAAS en tant que code. Je voudrais partager une série de conseils utiles sur l’utilisation de Terraform.

Un jour, alors que je testais différentes manières de créer une grande ressource en tant que code, j’ai accidentellement supprimé une ressource complexe que j’avais créée manuellement. J’avais besoin de trouver un moyen simple de recréer la ressource supprimée, même si je n’avais pas encore de fichier de définition de code Terraform local. Ce que j’ai trouvé m’a amené à plonger profondément dans le fichier d’état de Terraform, pour une solution qui m’a permis de créer un Terraform HCL complet (Langage de configuration HashiCorp) fichier de 750 lignes de code, en utilisant seulement quelques commandes Terraform simples.

Ce fut une expérience d’apprentissage précieuse pour moi afin de mieux comprendre Terraform et comment l’État fonctionne sous le capot et j’espère que cela pourra également vous aider.

La ressource que j’ai supprimée a été créée manuellement, et j’avais besoin de trouver un moyen de le recréer facilement sans avoir à tout réécrire à partir de zéro. Heureusement dans mon cas, bien que j’aie supprimé la ressource à distance sur le fournisseur de cloud, j’avais importé la ressource dans mon Terraform local État. En utilisant une manipulation minutieuse de l’état de Terraform, j’ai réussi à créer un fichier de définition Terraform complet à partir de zéro et à recréer avec succès la ressource supprimée à l’aide de quelques commandes Terraform simples que je vais partager avec vous.

Mais d’abord, couvrons quelques concepts de base de Terraform.

Terraform utilise une architecture de fournisseur de sorte que lorsque vous travaillez avec une configuration, vous devez définir quel Fournisseur vous travaillez avec. Une Terraforme Fournisseur est essentiellement un module de code Terraform qui peut être utilisé pour créer des ressources d’un service Cloud Infrastructure ou SAAS en tant que code. Terraform utilise les définitions et les paramètres du module pour savoir comment créer et mettre à jour vos ressources dans le fournisseur choisi.

Par exemple, lorsque vous travaillez avec le fournisseur de services Web Amazon, vous devez spécifier la région AWS dans laquelle vous travaillez et vous assurer de vous authentifier à l’aide de Rôles IAM ou AWS Clés d’accès et secrètes.

Terraform utilise les fournisseurs pour créer différents objets en tant que code, il peut s’agir d’un VPC AWS, d’un compartiment S3 ou d’une instance RDS.

Lors de l’écriture du code Terraform, cela est généralement appelé comme suit :

resource "resource_type" "resource_name" {
<RESOURCE_PARAMETERS_AND_CONFIGURATION>
}

Le fichier le plus important à connaître lorsque vous travaillez avec Terraform est le fichier Terraform Fichier d’état. Le fichier d’état, comme son nom l’indique, est ce que terraform binary interagit avec pour pouvoir connaître l’état actuel de l’infrastructure distante par rapport à l’état souhaité configuré dans le code de langage de configuration de Terraform. L’état est conservé entre les exécutions de Terraform en tant que fichier physique sur un stockage local ou distant, et le fichier est généralement appelé terraform.tfstate. Avant chaque exécution, Terraform commence par vérifier l’état connu, puis compare les fichiers de définition Terraform à l’environnement d’infrastructure distant.

Plongeons-nous dans un exemple terraform.tfstate déposer.

{
"version": 4,                 # Version of Terraform state file syntax
"terraform_version": "1.1.2", # Version of Terraform binary being used
"serial": 31,                 # Serial number of this version of the state
"lineage": "4978360c-2654-49fc-38d2-c86f4dc0abfe", # Unique state ID
"outputs": {},                # Outputted resources
"resources": [
{
<ACTUAL RESOURCES LISTED HERE>
}
]
}

Ce que nous pouvons voir, c’est qu’il y a beaucoup d’informations utiles à notre disposition dans le fichier d’état. Ces informations peuvent être inspectées manuellement pour vérifier ce que Terraform sait actuellement de l’état actuel de l’infrastructure.

Il existe même une commande pour afficher le contenu complet du fichier d’état actuel :

terraform state pull

On peut aussi lister les ressources gérées par le fichier d’état courant en utilisant la commande :

terraform state list

Il est également possible d’afficher une ressource spécifique en spécifiant l’ID de la ressource comme suit :

terraform state show resource_type.resource_name

Une fois que nous avons des ressources dans le cloud, même s’il n’y a pas de fichiers Terraform localement qui les décrivent comme du code, nous pouvons import les dans notre fichier d’état local en utilisant le terraform import commande.

terraform import resource_type.resource_name unique_resource_id

Une fois les ressources importées dans Terraform stateils apparaîtront dans le fichier d’état et pourront être référencés à partir des nouveaux fichiers de code Terraform ou du terraform binaire.

Maintenant que nous en savons un peu plus sur l’état de Terraform, essayons de combiner les commandes que nous avons apprises pour recréer notre ressource supprimée !

Comme mentionné précédemment, bien que la ressource distante ait été supprimée, j’avais toujours la définition de ressource importée dans mon fichier d’état local. Je savais donc que la définition de ressource était là et j’avais juste besoin de quelques commandes de manipulation d’état pour extraire la définition de l’état.

1. Création d’un bloc de ressources vide dans un Terraform main.tf fichier de représentation de la ressource distante.
Dans mon cas, il s’agissait d’un datadog_synthetics_test Ressource.

resource "datadog_synthetics_test" "my_test" {
}

2. Importation de la ressource distante dans l’état Terraform local

terraform import datadog_synthetics_test.my_test <RESOURCE_ID>

3. Exporté la ressource de l’état vers un nouveau fichier my_test.tf

terraform state show -no-color datadog_synthetics_test.my_test > my_test.tf

NOTE: j’ai utilisé le -no-color flag, pour que le fichier cible soit aussi propre que possible sans aucun caractère de couleur de shell étrange.

4. Identifiants supprimés du fichier créé.

Dans mon cas avec datadog_synthetics_test ressource, les ID de ressource sont l’ID de ressource Terraform et l’ID de moniteur DataDog.
(Alternativement, vous pouvez simplement les commenter dans le fichier de sortie)

resource "datadog_synthetics_test" "my_test" {
# id = "***-***-***"
# monitor_id      = ******
.
.
.
}

5. Appliqué les modifications

terraform apply my_test.tf

6. Voilà !
Mon datadog_synthetics_test la ressource a été recréée avec succès !

Comme mentionné, les étapes ci-dessus ont fonctionné pour moi avec le datadog_synthetics_test Ressource.
Les versions de Terraform et du fournisseur DataDog que j’ai utilisées étaient :

❯ terraform -version
Terraform v1.1.2
+ provider registry.terraform.io/datadog/datadog v3.12.0

J’espère que cette solution pourra vous aider à recréer vos ressources et à générer du code Terraform.
Bien que cela ait fonctionné pour moi ici, mon intuition est que cela ne se traduira probablement pas facilement pour fonctionner pour toutes les ressources et tous les fournisseurs.

Il est utile de comprendre le fichier d’état Terraform, son format et son contenu lors de l’utilisation de Terraform pour gérer l’infrastructure en tant que code.

Bien que Terraform soit généralement utilisé pour définir l’infrastructure de manière proactive du code au cloud, cette solution peut nous aider à faire l’inverse, restaurer et recréer des ressources du cloud au code.

J’aimerais savoir si vous trouvez cela utile et si cela vous a également aidé !