Rejeter une infrastructure invalide avant la planification

Introduction

Votre équipe dispose déjà d'un stockage de rapports géré par Terraform. Avant d'ajouter des déploiements automatisés, vous avez besoin d'une tâche qui refuse les configurations mal formatées ou structurellement invalides avant la planification.

Vous allez configurer deux contrôles statiques bloquants, observer chacun arrêter une véritable exécution de la tâche, puis corriger la configuration. Vous devez déjà connaître la configuration Terraform, le plan et l'état, les bases de Git et les codes de sortie du shell. L'environnement préparé ne nécessite aucun compte AWS personnel.

Liens avec les certifications

Ajouter des contrôles avant le plan

Dans cette étape, vous allez intégrer des contrôles statiques à une tâche séquentielle fournie. Le bucket et le rapport existants constituent l'infrastructure de départ : ce lab doit laisser leurs données et leur état Terraform inchangés.

Utilisez l'interface Terminal. Entrez dans le dépôt Git fourni et chargez son environnement d'outils. source applique les variables préparées à votre shell actuel ; cette commande ne déploie pas d'infrastructure.

cd /home/labex/project/report-delivery
source environment.sh

Inspectez la configuration de la ressource et les étapes actuelles de la tâche. cat affiche chaque fichier pour vous permettre de voir ce que la tâche gère et exécute.

cat main.tf pipeline.json

Le bucket possède un tag Purpose. La tâche ne comporte actuellement qu'une étape plan. Un plan réussi ne démontre pas à lui seul que les contrôles de formatage et de structure ont été exécutés auparavant.

terraform fmt -check contrôle le formatage canonique de Terraform sans réécrire les fichiers. terraform validate vérifie la cohérence interne de la configuration initialisée, notamment les attributs de ressources pris en charge. Aucun des deux ne prouve que la configuration répond aux exigences métier ; les assertions de module seront abordées dans le prochain lab.

L'exécuteur fourni associe les noms d'étapes à des commandes Terraform fixes et s'arrête à la première erreur. Conservez run-job.py inchangé : votre tâche consiste à configurer pipeline.json, pas à réécrire l'exécuteur fourni. Les vérifications confirment que le point d'entrée utilisé correspond à l'original fourni avant d'évaluer son comportement. Ajoutez les deux contrôles avant la planification. Le document intégré écrit le JSON compris entre ses délimiteurs dans pipeline.json ; les guillemets autour de EOF préservent son contenu littéral.

cat > pipeline.json <<'EOF'
{"stages":["fmt","validate","plan"]}
EOF

Exécutez la tâche avec l'interpréteur standard de Python. Il s'agit d'un runner local pédagogique ; ses étapes exécutent des commandes Terraform standard.

python3 run-job.py

Les résultats attendus sont [fmt] native exit 0, [validate] native exit 0 et [plan] native exit 0. Le plan n'indique aucune modification, car l'infrastructure fournie correspond déjà à sa configuration. Une erreur arrête les étapes suivantes. Un plan comportant des modifications utilise le code de sortie natif 2, que le runner traite comme un aperçu réussi, jamais comme une autorisation d'appliquer les changements.

Inspectez votre modification avec Git. -- sépare le chemin des options de la commande.

git diff -- pipeline.json

Le diff doit montrer les deux nouveaux contrôles avant plan. Cette tâche ne comporte aucune étape d'application.

Arrêter la tâche sur une erreur de formatage

Dans cette étape, vous allez introduire une expression HCL valide dont l'espacement n'est pas canonique, puis prouver que le contrôle de formatage arrête la tâche avant la planification.

Ajoutez un petit bloc de sortie à la fin du fichier. >> ajoute du contenu au fichier existant. L'espacement compact est intentionnel ; la sortie ne gère pas de nouvelle ressource.

cat >> main.tf <<'EOF'

output "format_probe" {value="spacing"}
EOF

Exécutez à nouveau la tâche. Cette commande doit échouer ; cet échec est le résultat utile recherché.

python3 run-job.py

La première étape indique le code de sortie natif 3 et mentionne main.tf. La tâche affiche Job stopped; later stages did not run. Aucune ligne [validate] ou [plan] ne doit apparaître. Le formatage peut être corrigé sans contacter AWS.

Inspectez les modifications exactes de formatage proposées. -diff les affiche, tandis que -check laisse le fichier inchangé.

terraform fmt -check -diff

Cette commande renvoie elle aussi intentionnellement un code de sortie non nul. Conservez le défaut de formatage pour la vérification de cette étape ; l'étape suivante le corrige.

Distinguer le formatage de la validité

Dans cette étape, vous allez corriger le formatage, puis introduire une autre erreur que seule la validation structurelle détecte.

Laissez d'abord Terraform réécrire l'espacement sur place. Exécuter fmt sans -check effectue la modification de formatage.

terraform fmt

La sortie mentionne main.tf. Confirmez que la configuration corrigée passe toutes les étapes de la tâche.

python3 run-job.py

Toutes les étapes doivent s'exécuter. La sortie supplémentaire peut amener plan à renvoyer le code de sortie natif 2 ; le plan propose une modification de sortie sans l'appliquer.

Ajoutez maintenant une référence à un attribut que la ressource bucket S3 n'exporte pas. Ce bloc utilise le formatage canonique et peut donc passer le premier contrôle.

cat >> main.tf <<'EOF'

output "missing" {
  value = aws_s3_bucket.reports.missing_attribute
}
EOF

Vérifiez d'abord le formatage seul.

terraform fmt -check

La commande renvoie zéro sans rien afficher. Exécutez ensuite la tâche complète.

python3 run-job.py

Le contrôle de formatage doit réussir, puis validate doit renvoyer le code de sortie natif 1 et un diagnostic Unsupported attribute. Aucune ligne correspondant à l'étape de planification ne doit apparaître. L'expression est correctement formatée, mais référence un attribut non pris en charge. Laissez cette erreur en place pour la vérification de l'étape.

Corriger la configuration et préserver l'environnement

Dans cette étape, vous allez restaurer la configuration de ressource connue comme valide, relancer la tâche avec ses contrôles bloquants et vérifier que le stockage des rapports n'a pas changé.

git restore -- main.tf restaure uniquement ce fichier depuis le commit initial du dépôt. Cette commande retire les deux sorties expérimentales et conserve vos modifications distinctes de pipeline.json.

git restore -- main.tf

Exécutez à nouveau la tâche complète.

python3 run-job.py

Les trois étapes doivent renvoyer le code de sortie natif 0. Le plan ne doit indiquer aucune modification. Réussir les contrôles statiques permet la planification ; cela n'approuve ni n'applique un déploiement.

Lisez le rapport directement depuis le stockage. - envoie son contenu sur la sortie standard au lieu d'enregistrer une autre copie locale.

aws s3   cp s3://delivery-gates-reports/report.csv -

Résultat attendu :

quarter,total
Q1,320

Inspectez le rapport voisin que cet exercice doit préserver.

aws s3   cp s3://delivery-gates-neighbor/keep.txt -

Il doit toujours contenir preserve neighboring report. Examinez le diff Git final pour confirmer que votre modification persistante porte sur la configuration du pipeline.

git diff -- main.tf pipeline.json

Ne détruisez aucun des deux buckets préparés : ils représentent une infrastructure existante appartenant à l'équipe. La tâche ne comporte ni étape de déploiement ni étape d'enregistrement de plan ; elle ne laisse donc aucune nouvelle ressource cloud ni aucun artefact de plan à nettoyer. Les expériences de sorties temporaires ont été retirées par la restauration de main.tf. Conservez vos contrôles qualité pour la vérification finale.

Résumé

Vous avez construit une tâche Terraform séquentielle avec un contrôle du formatage et une validation structurelle avant la planification. Vous avez observé un échec de formatage et un échec distinct lié à un attribut non pris en charge arrêter les étapes suivantes, puis corrigé la configuration et préservé les données des rapports et l'état.

La validité statique constitue une couche de qualité. Dans le prochain lab, des assertions de module exécutables vérifient si une configuration valide produit le comportement attendu. Consultez les références officielles de fmt et de validate pour les contrôles utilisés ici.