ストレージの変更を確認して適用する

はじめに

チームは、ストレージを再作成したり、レポートを変更したりせずに、既存のレポートストアにリリース 2 のラベルを付ける必要があります。保存済みプランを確認して適用し、その後、意図的に発生させたタグのドリフトを検出して修復します。

この独立した環境には、開始時点の小さなストアとローカル状態が用意されています。plan/apply、変数ファイル、S3 クエリの知識を使ってください。リモート状態や自動承認の知識は必要ありません。

認定試験との関連

保存済みプランを確認して適用する

このステップでは、既存のバケットとレポートを保持しながら、保存済みプランを使って、準備済みのレポートストアのリリースタグを更新します。

この新しいルートは、以前の実験で作成方法を学んだ小さなストアをすでに管理しています。変更の確認に集中できるよう、セットアップがその開始状態を用意しています。新しいリリースの目標値は 2 で、既存のレポートは orders,12 のままでなければなりません。まず、設定、値、現在のタグを読み取ります。

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

現在、入力ファイルはリリース 1 を選択しています。リソース名の変更はストレージの置き換えにつながる場合がありますが、タグの変更は既存のバケットを更新できます。リリースの入力だけを変更します。

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

バケットを置き換えずに更新するプラン 0 to add, 1 to change, 0 to destroy が表示されるはずです。-out は、この設定と入力値を含む Terraform 標準のプラン成果物を書き込みます。未保存のプレビューと異なり、このファイルを適用すると、後の編集から新しいプランを生成せずに、その確認済みプランを使用します。実際のプロジェクトではプランに機密値が含まれる場合があるので、プロジェクトの成果物として管理してください。

適用する前に保存済みプランを読みます。

terraform show change.tfplan

Release が 1 から 2 に変わり、オブジェクトもバケットも置き換えられないことを確認してください。その後、成果物を適用します。保存済みプランでは、追加の yes プロンプトは表示されません。

terraform apply change.tfplan

現在のタグを照会し、レポートを読み取ります。

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
aws s3api \
  get-object \
  --bucket terraform-change-reports \
  --key reports/current.csv \
  retained.csv
cat retained.csv

リリース 2 と orders,12 が確認できるはずです。保存済みプランが役立つのは、適用後のリソースと保持されたデータが、確認した変更と一致している場合です。

タグのドリフトを検出して修復する

このステップでは、Terraform 外で行われた実際のタグ変更を観察し、レポートを変更せずに宣言された設定に戻します。

ドリフトとは、デプロイ済みリソースと望ましい設定の差です。AWS CLI を使い、Terraform の外でタグを変更します。この意図的な演習は、プロバイダーが読み取れる実際のリソース属性を変更するもので、ローカルの成功マーカーを編集するものではありません。

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Terraform に、現在のリソースと望ましいリリースを比較させます。-detailed-exitcode は、0（変更なし）、2（変更の提案あり）、1（エラー）を区別します。次のプランは意図的に 2 を返します。これはタグの差を検出したという意味であり、デプロイの失敗を意味しません。

terraform plan -var-file=release.tfvars -detailed-exitcode

プランは unexpected を 2 に戻すことを提案します。修復内容を確認して保存し、その成果物を適用します。

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

現在のタグと、収束したプランを確認します。

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

タグは 2 になり、最後のプランは No changes と表示して 0 で終了します。レポートは変更されていません。ここで実証するのは読み取り可能なタグのドリフトであり、Terraform 外で起こり得るあらゆるデータ変更の検出ではありません。保存済みプランと詳細な終了コードについては、Terraform plan を参照してください。

変更したストアを削除する

このステップでは、変更とドリフトのチェックを通過した後、このルートが管理するストアだけを削除します。

削除内容を確認して実行し、destroy で yes を入力します。

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

レポートオブジェクトはバケットより先に削除されます。残ったリソースと空の対応付けを照会します。

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

チームの参照用レポートは残ります。保存済みのローカルプランは確認用の成果物です。そのファイルが存在しても、削除した AWS リソースが引き続き存在することを意味しません。

まとめ

確認済みの Terraform 標準のプラン成果物を適用し、既存リソースをそのまま更新する操作と置き換えを区別して、プロバイダーによる読み取りで実際のタグのドリフトを観察しました。望ましい設定に戻し、クリーンアップまでレポートデータを保持しました。