各環境に独自の状態を持たせる

はじめに

両方の環境と有効な状態オブジェクトがすでに存在しているにもかかわらず、preview の作業ルートが別の環境の状態を選択しています。ルートとキーの正しい関係を確立し、dev に影響を与えずに preview だけを変更してください。

前の実験で扱ったローカルモジュール、S3 のリモート状態、標準のロックの概念の知識が必要です。この独立した新しい環境には、両方のレポートストアと両方の状態が含まれています。以前の VM や個人の AWS アカウントは不要です。

認定試験との関連

実験の概要

変更する前に各環境を識別する

このステップでは、2 つの環境と、同じ環境の 2 つのコピーを区別します。以下の各ルートには、独自の変数と既存のレポート用バケットがあります。両方の有効なリモート状態は、バージョン管理された environment-team-state バックエンドにすでに存在しています。

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

入力には isolated-dev-reports と isolated-preview-reports という名前が指定されています。ルートディレクトリや変数ファイルによって、状態が自動的に分離されるわけではありません。バックエンドのバケットとキーが、Terraform の使用する対応付けを選択します。

preview ルートが選択しているリソースを確認します。

terraform -chdir=preview state show aws_s3_bucket.reports

preview の入力は別のバケットを指定していますが、現在表示されるのは dev のバケット ID です。現在のバックエンドの選択を確認します。

cat preview/environment.s3.tfbackend

キャッシュされたバックエンドとファイルは、environments/dev.tfstate を選択しています。本来使うキーは、すでに別々に存在しています。

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

environments/dev.tfstate と environments/preview.tfstate の両方が存在することを確認します。AWS View にも両方のレポートストアが表示されます。それぞれの report.txt オブジェクトを展開して、異なる元のデータを確認してください。

安全でない preview のプランを、適用せずに確認します。

terraform -chdir=preview plan

このプランは preview の入力を dev の対応付けと整合させようとするため、誤ったバケットの置き換えを提案する場合があります。適用しないでください。変数の値が異なることは、別の環境の状態を管理下に置く指示ではありません。

状態をコピーせずに既存の preview 状態を選択する

このステップでは、preview ルートを、すでに有効なその状態に関連付け直します。移行は、現在の対応付けを別のバックエンドにコピーします。再設定は、キャッシュされたバックエンドの選択を破棄し、古い対応付けをコピーせずに、指定された既存のバックエンドを初期化します。

dev のファイルは変更せずに残してください。preview のバケットとキーの選択を修正します。

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

-reconfigure を使って、その既存のキーを初期化します。用意された接続ファイルは、環境の選択とは別のままです。

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

ここでは -migrate-state や -force-copy を使ってはいけません。選択中の dev の状態を preview の有効なキーにコピーすると、preview の管理記録を選択するのではなく、上書きしてしまいます。

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

ID isolated-preview-reports と No changes が表示されるはずです。dev を独立して確認します。

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

dev は引き続き isolated-dev-reports を選択し、こちらも No changes となるはずです。両方の有効なキーと、両方の元のレポートをそのまま保持する必要があります。これは環境の選択であり、破損した状態の復旧ではありません。

preview の変更が preview だけにとどまることを確かめる

このステップでは、正しい関連付けを確立した後、preview のリビジョンだけを変更します。terraform.tfvars は、そのルートで宣言された変数に値を渡します。環境間で、ソースの設定とリソースアドレスは同じままにできます。

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

preview のプランを確認します。

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

0 to add, 1 to change, 0 to destroy と表示され、影響するのは preview のリビジョンタグだけのはずです。同じルートから保存済みプランを適用します。

terraform -chdir=preview apply preview.tfplan

各環境の現在のタグを確認します。

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

preview には Environment=preview と Revision=two があるはずです。

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

dev には引き続き Environment=dev と Revision=one があるはずです。両方の元のレポートを読み取ります。

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

preview daily report と dev daily report が表示されるはずです。バックグラウンドチェックでは、dev の元の状態のバイト列、両方のオブジェクトバージョン、両方のバックエンドキーにあるリソースの対応付けも比較します。

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

両方のルートが No changes と表示するはずです。両方のレポートストアとそのバックエンドは、所有者のために保持してください。ディレクトリ名、for_each のキー、Terraform の変数は、明示的な状態の分離の代わりにはなりません。dev の別の作業コピーは意図的に同じ dev キーを選択すべきですが、preview は独自のキーを選択しなければなりません。

まとめ

作業コピーと環境を区別し、バックエンドの再設定によって既存の状態を選択して、preview だけの更新で dev のリソース、データ、状態が変更されないことを確かめました。