Déplacer l’état local vers S3

Introduction

Un responsable de maintenance a besoin d'un emplacement partagé pour les correspondances de ressources d'une pile opérationnelle. Migrez un état local vers un backend S3 distinct et versionné tout en préservant le rapport existant, puis observez l'historique de l'état et le cycle de vie indépendant du backend.

Vous devez connaître l'état Terraform, l'import, les plans enregistrés et les versions d'objets S3. Toutes les ressources de ce lab sont préparées dans cet environnement neuf ; aucun état antérieur ni compte AWS personnel ne sont nécessaires.

Liens avec les certifications

Aperçu du lab

Définir la frontière entre l'état local et le backend

Dans cette étape, identifiez le bucket métier et la destination distincte de l'état. La configuration racine de rapports fournie gère déjà migration-daily-reports ; son état local est indépendant de la référence de la finance. Le bucket versionné maintenance-team-state est préparé par l'équipe plateforme pour qu'il existe avant que cette configuration racine commence à l'utiliser.

cd /home/labex/project/state-migration
terraform state list
terraform state show aws_s3_bucket.reports

Confirmez que l'identifiant du bucket distant est migration-daily-reports. Un backend stocke les correspondances des ressources ; ce n'est pas le fournisseur qui crée et lit les ressources AWS. Les paramètres de connexion du fournisseur et du backend sont préparés séparément dans cet environnement.

Enregistrez une sauvegarde locale privée avant de modifier l'emplacement de stockage de l'état. La redirection (>) écrit le JSON de l'état dans un fichier ; ne versionnez pas l'état ni les plans dans un dépôt public :

terraform state pull > local-before-migration.json
chmod 600 local-before-migration.json

Vérifiez la gestion des versions du backend et son inventaire initialement vide :

aws s3api \
  get-bucket-versioning \
  --bucket maintenance-team-state

Le résultat attendu est Status: Enabled.

aws s3api \
  list-objects-v2 \
  --bucket maintenance-team-state

Aucun objet d'état ne doit encore exister. Le choix d'une destination vide est important : migrer vers une clé qui appartient déjà à un autre environnement peut écraser son enregistrement de gestion. Laissez migration-finance-reference intact.

Migrer la correspondance existante vers la clé S3 prévue

Dans cette étape, configurez un backend distant et copiez la correspondance locale existante des ressources vers sa destination vide. Une clé est le nom de l'objet d'état dans le bucket du backend ; choisissez-la pour un environnement précis.

Écrivez une déclaration partielle de backend S3. Les paramètres de connexion sont fournis séparément, et le fichier suivant fournit votre choix de bucket et de clé :

cat > backend.tf <<'HCL'
terraform {
  backend "s3" {}
}
HCL

Créez la configuration de backend propre à l'environnement. use_lockfile = true active le fichier de verrouillage S3 natif de Terraform pour les futurs processus d'écriture :

cat > reports.s3.tfbackend <<'HCL'
bucket       = "maintenance-team-state"
key          = "reports/production.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

-migrate-state demande à Terraform de déplacer la correspondance existante vers le nouveau backend. Terraform demande s'il doit copier l'état existant ; le pipeline printf fournit la réponse yes. N'exécutez cette commande qu'après avoir confirmé que la clé de destination de ce lab était vide :

printf 'yes\n' | terraform init \
  -backend-config=backend-connection.hcl \
  -backend-config=reports.s3.tfbackend \
  -migrate-state

La configuration du backend S3 doit réussir et l'initialisation se terminer. N'utilisez pas la migration pour basculer vers un environnement déjà existant : sélectionner un état existant est une opération différente, abordée plus tard dans ce cours.

Inspectez la correspondance depuis son nouvel emplacement :

terraform state show aws_s3_bucket.reports

L'identifiant de ressource doit toujours être migration-daily-reports. Confirmez que S3 contient maintenant le véritable objet d'état :

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Un ETag et un VersionId indiquent l'objet d'état stocké. Ces métadonnées seules ne suffisent pas : le contrôle en arrière-plan lit aussi sa correspondance de ressources et compare l'identité et les octets du rapport existant.

terraform plan

Le résultat attendu est No changes. Migrer l'état ne doit pas recréer le bucket métier.

Observer une nouvelle version de l'état distant

Dans cette étape, effectuez une mise à jour de configuration examinée et observez l'historique de l'état qui en résulte. La gestion des versions conserve les objets d'état antérieurs ; ce lab observe l'historique plutôt que de restaurer un état endommagé.

Ajoutez un tag de révision tout en gardant le nom du bucket, le propriétaire et le paramètre de destruction inchangés :

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "reports" {
  bucket        = "migration-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting", Revision = "two" }
}
HCL

Examinez un plan enregistré :

terraform plan -out=revision.tfplan

Le résultat attendu est 0 to add, 1 to change, 0 to destroy. Appliquez uniquement cette mise à jour sur place :

terraform apply revision.tfplan

Inspectez les versions de l'objet du backend :

aws s3api \
  list-object-versions \
  --bucket maintenance-team-state \
  --prefix reports/production.tfstate

Au moins deux versions de l'état doivent exister après la migration et la mise à jour. Elles décrivent l'historique de gestion ; elles sont distinctes des versions du rapport métier dans l'autre bucket.

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

Le rapport reste Daily sales: 120 orders. AWS View affiche le stockage métier, la référence de la finance et le backend comme des buckets distincts. Les fichiers d'état peuvent contenir des valeurs sensibles ; inspectez uniquement les métadonnées nécessaires à cet exercice.

terraform plan

Le résultat attendu est No changes. Vérifiez cet état opérationnel avant de commencer la phase distincte de nettoyage.

Supprimer les ressources métier en conservant le backend

Dans cette étape, retirez cette pile métier jetable après la réussite des contrôles de fonctionnement et de préservation des données. Le backend de l'équipe plateforme et la référence indépendante de la finance sont en dehors du périmètre de suppression de la pile.

force_destroy = false empêche Terraform de vider silencieusement le bucket de rapports versionné. Identifiez explicitement la version d'origine du rapport avant de supprimer le rapport de ce lab. La substitution de commande enregistre son identifiant ; affichez cet identifiant non secret :

VERSION_ID=$(aws s3api \
  head-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --query VersionId \
  --output text)
echo "$VERSION_ID"

Supprimez cette version jetable précise, puis détruisez la ressource métier. Ces commandes mettent intentionnellement fin à la disponibilité du rapport uniquement après le contrôle de préservation de l'étape précédente :

aws s3api \
  delete-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --version-id "$VERSION_ID"
terraform destroy -auto-approve

-auto-approve évite une demande de confirmation ; utilisez cette option ici uniquement pour le seul bucket métier jetable que vous venez d'examiner. Le résultat attendu est 1 destroyed.

Confirmez que son enregistrement de gestion existe toujours dans le backend :

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Le backend est conservé et contient désormais un état sans ressources métier gérées. La référence de la finance doit toujours être disponible. Détruire une pile ne supprime pas le stockage utilisé par son backend. Laissez ce backend intact pour son propriétaire ; ne lancez pas une nouvelle application normale, qui recréerait le bucket métier souhaité.

Consultez la documentation du backend S3 pour la configuration du backend et les fichiers de verrouillage natifs.

Résumé

Vous avez distingué les rôles du fournisseur et du backend, sauvegardé et migré une correspondance existante vers S3, observé les versions de l'état et supprimé une pile métier sans effacer son backend détenu indépendamment.