Donner à chaque environnement son propre état

Introduction

Une configuration racine de travail preview sélectionne l'état du mauvais environnement, alors que les deux environnements et leurs objets d'état valides existent déjà. Établissez la bonne relation entre la configuration racine et la clé, puis effectuez une modification limitée à preview sans affecter dev.

Vous devez connaître les modules locaux, l'état distant S3 et le verrouillage natif abordés dans les unités précédentes. Cet environnement neuf et indépendant contient les deux stockages de rapports et les deux états ; aucune VM précédente ni compte AWS personnel ne sont nécessaires.

Liens avec les certifications

Aperçu du lab

Identifier chaque environnement avant toute modification

Dans cette étape, distinguez deux environnements de deux copies d'un même environnement. Chaque configuration racine ci-dessous possède ses propres variables et son bucket de rapports existant. Les deux états distants valides existent déjà dans le backend versionné environment-team-state.

cd /home/labex/project/environment-states
cat dev/terraform.tfvars
cat preview/terraform.tfvars

Les entrées nomment isolated-dev-reports et isolated-preview-reports. Un répertoire racine ou un fichier de variables n'isole pas automatiquement l'état : le bucket et la clé du backend sélectionnent la correspondance que Terraform utilisera.

Inspectez la ressource sélectionnée par la configuration racine preview :

terraform -chdir=preview state show aws_s3_bucket.reports

Elle indique actuellement l'identifiant du bucket dev, alors que les entrées de preview décrivent un autre bucket. Inspectez son choix actuel de backend :

cat preview/environment.s3.tfbackend

Le backend en cache et le fichier sélectionnent environments/dev.tfstate. Les clés prévues existent déjà séparément :

aws s3api \
  list-objects-v2 \
  --bucket environment-team-state \
  --prefix environments/

Confirmez que environments/dev.tfstate et environments/preview.tfstate existent tous deux. AWS View affiche aussi les deux stockages de rapports ; développez leurs objets report.txt pour voir les données d'origine distinctes.

Inspectez le plan risqué de preview sans l'appliquer :

terraform -chdir=preview plan

Il tente de réconcilier les entrées de preview avec la correspondance de dev et peut proposer de remplacer le mauvais bucket. Ne l'appliquez pas. Une valeur de variable différente n'est pas une instruction de prise en charge de l'état d'un autre environnement.

Sélectionner l'état preview existant sans copier d'état

Dans cette étape, reliez à nouveau la configuration racine preview à son état déjà valide. La migration copie une correspondance actuelle dans un autre backend. La reconfiguration abandonne le choix de backend en cache et initialise le backend existant demandé sans copier l'ancienne correspondance.

Gardez le fichier de dev inchangé. Corrigez le choix du bucket et de la clé de preview :

cat > preview/environment.s3.tfbackend <<'HCL'
bucket       = "environment-team-state"
key          = "environments/preview.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

Initialisez cette clé existante avec -reconfigure. Le fichier de connexion fourni reste distinct de votre sélection d'environnement :

terraform -chdir=preview init \
  -reconfigure \
  -backend-config=backend-connection.hcl \
  -backend-config=environment.s3.tfbackend

N'utilisez pas -migrate-state ni -force-copy ici. Copier l'état dev sélectionné vers la clé valide de preview écraserait l'enregistrement de gestion de preview au lieu de le sélectionner.

terraform -chdir=preview state show aws_s3_bucket.reports
terraform -chdir=preview plan

Les résultats attendus sont l'identifiant isolated-preview-reports et No changes. Vérifiez dev indépendamment :

terraform -chdir=dev state show aws_s3_bucket.reports
terraform -chdir=dev plan

Dev sélectionne toujours isolated-dev-reports, également avec No changes. Les deux clés valides et les deux rapports d'origine doivent rester intacts ; il s'agit d'une sélection d'environnement, pas d'une récupération d'état endommagé.

Prouver qu'une modification de preview reste dans preview

Dans cette étape, modifiez uniquement la révision de preview après avoir établi sa bonne liaison. terraform.tfvars fournit les valeurs des variables déclarées par cette configuration racine ; la configuration source et l'adresse de ressource peuvent rester identiques d'un environnement à l'autre.

cat > preview/terraform.tfvars <<'HCL'
bucket_name = "isolated-preview-reports"
environment = "preview"
revision = "two"
HCL

Examinez le plan de preview :

terraform -chdir=preview plan -out=preview.tfplan

Le résultat attendu est 0 to add, 1 to change, 0 to destroy, affectant uniquement le tag de révision de preview. Appliquez le plan enregistré depuis cette même configuration racine :

terraform -chdir=preview apply preview.tfplan

Inspectez les tags actuels de chaque environnement :

aws s3api \
  get-bucket-tagging \
  --bucket isolated-preview-reports

Preview doit avoir Environment=preview et Revision=two.

aws s3api \
  get-bucket-tagging \
  --bucket isolated-dev-reports

Dev doit toujours avoir Environment=dev et Revision=one. Lisez les deux rapports d'origine :

aws s3 \
  cp s3://isolated-preview-reports/report.txt -
aws s3 \
  cp s3://isolated-dev-reports/report.txt -

Les résultats attendus sont preview daily report et dev daily report. Le contrôle en arrière-plan compare aussi les octets d'origine de l'état de dev, les versions des deux objets et les correspondances de ressources dans les deux clés du backend.

terraform -chdir=preview plan
terraform -chdir=dev plan

Les deux configurations racines doivent indiquer No changes. Conservez les deux stockages de rapports et leur backend pour leurs propriétaires. Les noms de répertoires, les clés for_each et les variables Terraform ne remplacent pas une isolation explicite de l'état ; une autre copie de travail de dev doit intentionnellement sélectionner la même clé dev, tandis que preview doit sélectionner sa propre clé.

Résumé

Vous avez distingué les copies de travail des environnements, sélectionné un état existant par reconfiguration du backend et prouvé qu'une mise à jour limitée à preview laissait les ressources, les données et l'état de dev inchangés.