terraform state show : lire une instance, et ce que la fiche cache

terraform state show <adresse> affiche la fiche d'une instance enregistrée dans le state. Là où state list donne l'inventaire, state show ouvre le détail. C'est la lecture de confort du quotidien, et la documentation officielle précise pour qui : cette sortie est destinée à la consommation humaine, pas programmatique. Ce guide montre comment l'obtenir, ce qu'elle omet, ce qu'elle caviarde, et par quoi la remplacer dès qu'un script en dépend.

Tous les comportements de ce guide ont été exécutés sur Terraform v1.15.4 avec les providers random et local : aucun hyperviseur ni compte cloud n'est nécessaire pour les reproduire.

Ce que vous allez apprendre

• Afficher la fiche d'une instance, y compris indexée par count ou for_each
• Les attributs nuls, qui disparaissent de la fiche sans disparaître du state
• Les valeurs sensibles, caviardées, et l'objet sensitive_values du JSON
• terraform show -json : la voie machine, et son revers sur les secrets
• Pourquoi state show ne diagnostique pas un écart avec l'infrastructure

Prérequis

• Terraform 1.11 ou plus récent (installer Terraform).
• Savoir obtenir une adresse avec terraform state list, et connaître le rôle du state.

Afficher la fiche d'une instance

La commande prend une adresse et rend la fiche correspondante. Le projet de démonstration déclare un random_pet, un random_password, trois répliques en count et une data source :

terraform state show random_pet.env

# random_pet.env:
resource "random_pet" "env" {
    id        = "happy-lizard"
    length    = 2
    separator = "-"
}

La fiche est mise en forme comme du HCL, avec l'adresse en commentaire sur la première ligne. Elle se lit de haut en bas, sans outil. Une data source s'inspecte de la même façon, avec son préfixe data. :

terraform state show data.local_file.relecture

# data.local_file.relecture:
data "local_file" "relecture" {
    content              = <<-EOT
        env=happy-lizard
    EOT
    content_base64       = "ZW52PWhhcHB5LWxpemFyZAo="
    content_base64sha256 = "k0hX0NbbCdEz35/9IztEB9nPepaPOI+xCOC3DbY/Ev4="
    ...
}

Retenez le nombre d'attributs de la première fiche : trois. Nous y reviendrons.

L'adresse doit désigner une instance précise

C'est le premier mur après un state list, et le message est explicite. Sur une ressource créée avec count, l'adresse sans index ne désigne aucune instance :

terraform state show random_pet.replicas

No instance found for the given address!

This command requires that the address references one specific instance.
To view the available instances, use "terraform state list". Please modify
the address to reference a specific instance.

Le code de retour vaut 1. Il faut donc l'index, ou la clé pour un for_each :

terraform state show 'random_pet.replicas[1]'
terraform state show 'random_pet.zone["eu-west"]'
terraform state show 'module.reseau.random_pet.sous_reseau["a"]'

Sous zsh, les crochets se quotent

Sans guillemets, zsh interprète les crochets comme un motif de nom de fichier et la commande échoue avant d'atteindre Terraform, sur un no matches found. Les guillemets simples règlent le cas, et ne coûtent rien quand ils sont inutiles.

Les attributs nuls sont omis

Voici le premier angle mort. Un attribut qui vaut null n'apparaît pas dans la fiche. Il existe pourtant dans le state, et la sortie JSON le montre :

terraform show -json | jq '.values.root_module.resources[]
  | select(.address == "random_pet.env") | .values'

{
  "id": "happy-lizard",
  "keepers": null,
  "length": 2,
  "prefix": null,
  "separator": "-"
}

Cinq attributs dans le state, trois dans la fiche. keepers et prefix existent, à null, et la fiche les passe sous silence.

La conséquence pratique est un faux diagnostic classique : un grep keepers sur la sortie de state show ne renvoie rien, et l'on en conclut que le provider ne gère pas cet attribut. La bonne question n'est pas « le provider le connaît-il », mais « vaut-il null », et seule la sortie JSON y répond.

Les valeurs sensibles sont caviardées

Second angle mort. Un attribut sensible est remplacé par un marqueur :

terraform state show random_password.api

# random_password.api:
resource "random_password" "api" {
    bcrypt_hash = (sensitive value)
    id          = "none"
    length      = 24
    lower       = true
    ...
    result      = (sensitive value)
}

C'est une protection réelle et utile : la fiche peut être montrée, collée dans un ticket ou partagée en revue sans fuiter le secret. Mais elle rend la valeur inatteignable par ce chemin, et un grep result renverra le marqueur, pas le mot de passe.

Pour savoir quels attributs Terraform tient pour sensibles, ressource par ressource, le JSON expose un objet dédié :

terraform show -json | jq '.values.root_module.resources[]
  | select(.address == "random_password.api") | .sensitive_values'

{
  "bcrypt_hash": true,
  "result": true
}

C'est la trace exploitable : elle dit ce qui sera caviardé, avant même de regarder une fiche.

La voie machine : terraform show -json

Dès qu'une valeur doit servir ailleurs que sous vos yeux, dans un test, un pipeline ou un script, la documentation de state show désigne nommément la voie correcte : produire le document JSON et décoder la structure documentée.

Attention à un détail qui piège : terraform state show n'a pas d'option -json.

terraform state show -json random_pet.env

Failed to parse command-line flags
flag provided but not defined: -json

C'est terraform show -json, sans state, qui produit le document complet du state courant.

Le JSON expose les secrets en clair

La bascule est à double tranchant. La page officielle est explicite : « any sensitive values in Terraform state will be displayed in plain text ». Là où state show protège en caviardant, show -json révèle. Vérifié sur 1.15.4 : le mot de passe caviardé dans la fiche apparaît en clair dans le JSON.

Conséquence directe : un terraform show -json > etat.json redirigé vers un artefact de pipeline y dépose vos secrets. Traitez ce fichier comme un secret, ou n'en extrayez que les champs nécessaires.

state show ne rafraîchit rien

Troisième piège, et le plus coûteux en diagnostic. La commande lit le state enregistré. Elle n'interroge jamais l'infrastructure.

1. Modifiez l'objet hors de Terraform

   echo "modifie a la main" >> inventaire.txt

2. Relancez la fiche : elle est inchangée

   terraform state show local_file.inventaire

   Le content et les empreintes affichés sont toujours ceux du dernier apply. Aucune trace de la modification.

3. C'est le plan qui révèle la dérive

   terraform plan -input=false -detailed-exitcode > /dev/null 2>&1; echo $?

   2

   Le code 2 signale des changements : le plan rafraîchit, lui.

state show montre donc l'écart entre le state et votre code, jamais entre le state et la réalité. Le confondre conduit à conclure « tout va bien » sur une ressource modifiée dans le dos de Terraform.

Les options : une seule, et elle est héritée

La syntaxe s'écrit terraform state show [options] ADRESSE, mais ce pluriel est trompeur : il n'existe qu'une seule option, -state=path, que la documentation qualifie de legacy et réserve au backend local. Pour tout le reste, notamment la sortie machine, la réponse est terraform show -json.

Dépannage

Le réflexe qui résout la majorité des cas : partir de state list pour obtenir l'adresse exacte, puis basculer sur le JSON dès qu'un attribut semble manquer.

Symptôme	Cause probable	Solution
No instance found for the given address!	Adresse sans index sur une ressource en count ou for_each	Ajouter [0] ou ["clé"], en quotant sous zsh
Un attribut est absent de la fiche	Il vaut null (le plus fréquent), ou il est sensible	Lire terraform show -json, section values
(sensitive value) au lieu de la valeur	Attribut marqué sensible par le provider	terraform show -json ou terraform output -json, en protégeant la sortie
flag provided but not defined: -json	state show n'a pas cette option	Utiliser terraform show -json, sans state
La fiche ne montre pas une modification faite à la main	state show ne rafraîchit pas	terraform plan (ou -refresh-only) pour voir la dérive
No state file was found!	Aucun apply, ou state ailleurs	Lancer terraform apply, vérifier le backend

Glissez pour voir

Mettre en pratique

Le lab terraform state show fait remplir cinq sorties qui ne peuvent venir que du state : deux adresses, dont une indexée, une empreinte à référencer, un mot de passe que la fiche caviarde, et la liste des attributs nuls que la fiche omet. Les tests recalculent chaque vérité depuis le JSON et n'utilisent la fiche que pour prouver ce qu'elle cache. Le lab se joue hors ligne.

À retenir

• terraform state show rend la fiche d'une instance : l'adresse doit être précise, index ou clé compris, sinon No instance found for the given address! en code 1.
• La sortie est faite pour un humain. La doc l'écrit, et interdit d'en extraire des données par programme.
• Un attribut à null est omis de la fiche : son absence ne veut pas dire que le provider l'ignore.
• Un attribut sensible est caviardé en (sensitive value) ; l'objet sensitive_values du JSON dit lesquels le sont.
• Tout usage machine passe par terraform show -json, et state show n'a pas d'option -json.
• Le JSON expose les secrets en clair : protégez le fichier produit.
• state show ne rafraîchit rien : c'est terraform plan qui révèle une dérive, avec le code 2 en -detailed-exitcode.

FAQ : questions fréquentes

Les questions ci-dessous portent sur ce qui bloque le plus souvent : l'adresse refusée, l'attribut introuvable, et la valeur qu'on n'arrive pas à récupérer. Chaque réponse donne la commande de vérification.

Pourquoi terraform state show répond No instance found for the given address ?

Parce que l'adresse ne designe pas une instance unique. Sur une ressource creee avec count ou for_each, il faut l'index ou la cle : terraform state show 'random_pet.replicas[1]'. Le code de retour vaut 1 sans cet index.

Pourquoi un attribut est absent de la sortie de terraform state show ?

Parce qu'il vaut null : la fiche omet purement les attributs nuls. Ce n'est donc pas que le provider ne le gere pas. terraform show -json les expose explicitement a null, ce qui leve le doute.

Comment récupérer une valeur affichée en (sensitive value) ?

Par terraform show -json ou terraform output -json, qui rendent la valeur en clair. state show caviarde volontairement les attributs sensibles, et l'objet sensitive_values du JSON dit lesquels sont concernes.

terraform state show a-t-il une option -json ?

Non. La commande echoue en code 1 sur flag provided but not defined: -json. C'est terraform show -json, sans le mot state, qui produit le document machine. state show n'a qu'une option, -state, qualifiee de legacy.

terraform state show permet-il de diagnostiquer un écart avec l'infrastructure réelle ?

Non. La commande lit le state enregistre sans rien rafraichir. Apres une modification hors Terraform, sa sortie reste inchangee ; c'est terraform plan qui revele la derive, avec le code 2 en -detailed-exitcode.

Quelle différence entre terraform state show et terraform show ?

terraform state show cible UNE instance et rend une fiche lisible par un humain. terraform show rend tout le state, et son option -json produit le document structure destine aux scripts, avec les valeurs sensibles en clair.

Comment inspecter une data source ou une ressource dans un module ?

En donnant l'adresse complete : data.local_file.lecture pour une data source, module.reseau.random_pet.zone pour une ressource de module. Ce sont les adresses que terraform state list affiche, a reprendre telles quelles.

Pour aller plus loin

• Sauvegarder et restaurer le state : ce qui reste quand une fiche revele un state abime.
• terraform state rm : la retirer du state sans détruire l'objet réel.
• Diagnostiquer le state : quand la fiche ne correspond plus à la réalité.
• terraform state show : la référence officielle : l'avertissement sur l'usage humain et l'option -state.
• Format JSON du state : values, sensitive_values et la hiérarchie des modules.

×

📖 Voir la documentation →