Coordonner deux répertoires de travail Terraform

Introduction

Deux responsables de maintenance disposent de copies de travail du même environnement. Observez un véritable processus écrivant dans l'état partagé, un plan concurrent rejeté par son verrou natif et une opération réussie depuis l'autre répertoire après la libération normale du verrou.

Vous devez connaître l'état distant S3 et les opérations ordinaires de planification et d'application Terraform. Cet environnement neuf fournit les deux copies de travail initialisées, une modification contrôlée et temporisée, le stockage des rapports et une référence de la finance ; aucune VM précédente ni compte AWS personnel ne sont nécessaires.

Liens avec les certifications

Aperçu du lab

Identifier deux copies d'un même environnement

Dans cette étape, établissez que deux répertoires de travail gèrent intentionnellement le même environnement. Il ne s'agit pas de déploiements dev et preview séparés : les deux configurations de backend sélectionnent reports/shared.tfstate dans coordination-team-state.

cd /home/labex/project/shared-state-operators
cat operator-a/shared.s3.tfbackend
cat operator-b/shared.s3.tfbackend

Les deux utilisent use_lockfile = true. Terraform crée un objet de verrouillage S3 natif à côté de cet état pendant qu'un processus d'écriture travaille, afin qu'un autre ne travaille pas sur un instantané en conflit.

terraform -chdir=operator-a state show aws_s3_bucket.reports
terraform -chdir=operator-b state show aws_s3_bucket.reports

Les deux identifient coordinated-daily-reports. Lisez son rapport réel et laissez la référence de la finance inchangée :

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Le résultat attendu est Daily sales: 120 orders. Inspectez la modification contrôlée fournie :

cat operator-a/pending-change.tf

Pour cet exercice uniquement, une ressource terraform_data suspend sa création pendant 30 secondes au moyen de local-exec. Cette pause rend observable le verrou d'un véritable processus d'écriture. Les mises à jour ordinaires de ressources détiennent aussi un verrou ; une attente artificielle n'est pas une recommandation pour les déploiements en production. Cette modification contrôlée de l'état est présente dans les deux configurations, mais n'a pas encore été appliquée.

Observer une contention réelle et une libération normale

Dans cette étape, exécutez un véritable processus d'écriture et un plan concurrent depuis le second répertoire. Utilisez tout le bloc suivant comme une seule opération afin que les pauses de lecture ne consomment pas la fenêtre d'observation.

& lance l'opérateur A en arrière-plan ; $! capture son identifiant de processus. Sa sortie est enregistrée dans un journal pour rendre l'erreur du second opérateur lisible. La boucle bornée attend le véritable verrou S3 au lieu de supposer un délai de démarrage fixe. L'instruction if permet d'inspecter le plan dont l'échec est attendu, et wait renvoie le véritable code de fin du processus d'écriture. Il s'agit de deux processus Terraform indépendants, même si vous les lancez depuis un seul Terminal.

terraform -chdir=operator-a apply -auto-approve > /tmp/operator-a.log 2>&1 &
WRITER_PID=$!
echo "$WRITER_PID"
for attempt in $(seq 1 60); do
  if aws s3api head-object \
    --bucket coordination-team-state \
    --key reports/shared.tfstate.tflock > /dev/null 2>&1; then
    break
  fi
  sleep 1
done
aws s3api get-object \
  --bucket coordination-team-state \
  --key reports/shared.tfstate.tflock \
  /tmp/current-lock.json
cat /tmp/current-lock.json
if terraform -chdir=operator-b plan -lock-timeout=0s; then
  echo 'Unexpected: the competing plan acquired the lock.'
  false
else
  PLAN_EXIT=$?
  echo "$PLAN_EXIT"
fi
wait "$WRITER_PID"
cat /tmp/operator-a.log

Le plan concurrent doit se terminer avec le code 1 et Error acquiring the state lock. Une erreur d'authentification ou de connexion ne démontre pas une contention. Les informations du verrou appartiennent au véritable processus d'écriture ; téléverser un fichier portant le nom du verrou ne démontrerait pas la coordination des processus d'écriture.

L'opérateur A doit terminer sa création contrôlée avec succès et libérer normalement le verrou. Ne désactivez pas le verrouillage, ne supprimez pas le verrou d'un processus d'écriture actif et n'utilisez pas force-unlock pour permettre au second opérateur de continuer. Dans AWS View, les stockages de rapports restent disponibles pendant toute l'opération ; le verrou coordonne la gestion, pas l'accès en lecture aux rapports.

Continuer depuis l'autre copie de travail après la libération

Dans cette étape, laissez l'opérateur B accéder normalement au backend après la fin du processus d'écriture. La seconde copie de travail doit maintenant lire l'état partagé mis à jour, au lieu de créer indépendamment une autre copie des ressources.

terraform -chdir=operator-b plan -lock-timeout=5s

Le résultat attendu est No changes. La même commande qui était bloquée pendant l'écriture peut désormais acquérir et libérer le verrou normalement.

Inspectez l'état final depuis les deux répertoires :

terraform -chdir=operator-a state list
terraform -chdir=operator-b state list

Chacun répertorie aws_s3_bucket.reports et terraform_data.coordination. Il s'agit du même environnement et du même enregistrement de gestion partagé, pas de deux déploiements.

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Le texte d'origine reste disponible. Inspectez l'historique des versions de l'état :

aws s3api \
  list-object-versions \
  --bucket coordination-team-state \
  --prefix reports/shared.tfstate

L'état réel possède un historique et aucun .tflock actif ne doit subsister dans l'inventaire actuel des objets. Des versions historiques du verrou ou des marqueurs de suppression ne sont pas un verrou de processus d'écriture actif.

terraform -chdir=operator-a plan

Le résultat attendu ici aussi est No changes. Les contrôles en arrière-plan distinguent la contention de véritables processus Terraform d'un verrou fourni manuellement et vérifient les versions d'origine des rapports, la libération normale et la réussite d'un accès ultérieur. Laissez le stockage partagé et le backend à leurs propriétaires.

Résumé

Vous avez distingué deux copies de travail d'un même environnement d'environnements séparés, observé une véritable contention de verrou natif et continué en toute sécurité après la libération normale par le processus d'écriture, sans supprimer de verrou actif.