既存のリソースを管理下に置く

はじめに

Terraform の外で作成され、現在も使われているレポート用バケットを引き継ぎます。バケットを再作成したり、レポートを書き換えたりせずに管理下に置いてください。その後、隣接する財務チームのストレージを変更せずに、設定の小さな調整を確認して適用します。

Terraform の設定、リソースアドレス、init、plan、apply、ローカル状態、および S3 の基本的なオブジェクト操作を理解していることを前提とします。この新しい環境には、Terraform、AWS プロバイダー、アクセス設定、独立した 2 つのレポート用バケットが準備されています。個人の AWS アカウントや、前の実験のリソースは不要です。

認定試験との関連

実験の概要

既存ストレージと望ましい設定を確認する

このステップでは、AWS にすでに存在するリソースを、これから管理する設定と比較します。Terminal の上にある AWS View には、CLI が読み取るものと同じ S3 リソースが表示されます。handover-daily-reports カード内の report.txt を展開して、レポートデータを確認してください。finance-reference-reports は別のチームの所有物なので、変更せずに残す必要があります。

aws_s3_bucket.reports のような Terraform のリソースアドレスは設定ブロックを識別します。バケット名はリモートの AWS リソースを識別します。状態は、この 2 つの ID の対応付けを記録します。設定ファイルがあるだけでは、この対応付けは確立されません。

準備済みのルートディレクトリに移動し、望ましいバケット設定を読みます。

cd /home/labex/project/report-storage
cat main.tf

bucket 引数は handover-daily-reports を選択します。Owner は reporting のままにし、新しい ManagedBy タグで引き継ぎを記録します。force_destroy = false は、後で削除するときに Terraform が空でないバケットの中身を自動的に消すことを防ぎます。これは Terraform の動作設定であり、バケットに保存されたレポートとは別のものです。

既存のタグを確認します。

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

初期状態では Owner=reporting だけが存在します。出力先に - を指定し、元のレポートを標準出力に取得します。

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

想定されるレポート：

Daily sales: 120 orders

作業ディレクトリを初期化します。init は、このルート用に固定されたバージョンのプロバイダーをインストールします。バケットのインポートや作成は行いません。

terraform init

提案される操作を、適用せずに確認します。

terraform plan

このルートにはまだ管理対象リソースの対応付けがないため、プランは 1 to add を提案します。バケットはすでに存在します。これは状態に管理対象として記録されていないことを示すものであり、ストレージを置き換えてよいという意味ではありません。この作成プランは適用しないでください。 次のステップで対応付けを明示的に確立します。

続行する前に、レポート用バケットを識別し、レポートを読み取り、財務チームのストレージと区別できることを手動で確認してください。この確認ステップのバックグラウンドチェックは、用意されたリソースが保持されているかを検証します。表示されたプランを理解したかどうかを検証するものではありません。

既存バケットをインポートして差分を確認する

このステップでは、既存のバケットを意図した Terraform アドレスに対応付けます。CLI の import はリモートリソースを読み取り、その ID を状態に記録します。望ましい設定を生成したり、バケット内の全オブジェクトをインポートしたりはしません。

最初に設定のアドレス、次に既存のバケット名を指定してインポートします。

terraform import aws_s3_bucket.reports handover-daily-reports

Import successful! が表示されることを確認します。どのアドレスが管理対象になったかを確認してください。

terraform state list

想定されるアドレス：

aws_s3_bucket.reports

その属性を読み取ります。

terraform state show aws_s3_bucket.reports

id と bucket は、どちらも handover-daily-reports を示すはずです。report.txt は S3 に保存されたままです。バケットをインポートしても、オブジェクトが別の aws_s3_object アドレスの管理下に置かれるわけではありません。財務チームのバケットがこのルートの状態に含まれていてはいけません。

インポートの直後にプランが必ず空になるとは限りません。リモートサービスから取得される設定もあれば、force_destroy のように Terraform 自体の動作を定める設定もあり、インポート後に設定の調整が必要な場合があります。このような差分は、レポートが破損したことを意味しません。

確認用にプランを保存します。-out=handover.tfplan は計画された操作を保存し、次のステップで確認済みの同じプランを適用できるようにします。

terraform plan -out=handover.tfplan

保存したプランを読みます。

terraform show handover.tfplan

既存リソースをそのまま更新する操作（~）、ManagedBy=Terraform タグの追加、および場合によっては force_destroy を false に合わせる調整が表示されるはずです。要約は必ず次のとおりでなければなりません。

Plan: 0 to add, 1 to change, 0 to destroy.

プランが削除、置き換え、作成、別のバケット名、財務チームのストレージの変更を提案する場合は、作業を止め、ルートディレクトリ、リソースアドレス、インポート ID を見直してください。予期しないプランを解決するために、既存のレポートを削除してはいけません。

調整を適用して保持を確認する

このステップでは、確認済みのプランだけを適用し、元のレポートが保持されることを確かめます。保存済みプランを apply に渡すと、再度の承認プロンプトなしでそのプランが直接実行されます。前のステップの要約で作成も削除もゼロであることを確認してから実行してください。

terraform apply handover.tfplan

Resources: 0 added, 1 changed, 0 destroyed. と表示されるはずです。バケットは管理下に置かれ、引き継ぎ用のタグが設定と一致しました。

現在のタグを読み取り、AWS 側の結果を検証します。

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Owner=reporting と ManagedBy=Terraform の両方が存在するはずです。タグの順序は問いません。

レポートをもう一度読みます。

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

引き続き Daily sales: 120 orders が含まれている必要があります。AWS View で両方のレポートを展開し、レポートの内容と財務チームの参照用レポートが引き続き利用できることを確認してください。タグの調整に、新しいバケットやオブジェクトの書き換えは必要ありません。

現在の設定、状態、再取得した AWS リソースの間で収束していることを確認します。

terraform plan

想定される結果：

No changes. Your infrastructure matches the configuration.

変更のないプランだけでは、安全な引き継ぎの証拠として十分ではありません。意図したリソースアドレスと元のデータも確認しました。さらにバックグラウンドチェックでは、元のオブジェクトバージョンと隣接ストレージを比較し、使い捨てのコピーで現在の設定のプランを作成して収束を確認します。この引き継ぎでは両方のバケットを保持してください。レポートはまだ使用中なので、terraform destroy は実行しないでください。実際の引き継ぎでは、状態を機密性の高い運用データとして保護し、次の保守担当者のアクセスを手配します。機密値を含む状態や保存済みプランを公開リポジトリにコミットしてはいけません。

詳しくは、HashiCorp の CLI インポートのワークフローを参照してください。

まとめ

既存のバケットを Terraform の設定と比較し、意図した状態アドレスにその ID をインポートして、リソースを破壊しない調整を確認してから適用しました。元のレポートと財務チームのストレージを保持しながら、変更のないプランを確認しました。インポートによって管理関係を確立し、設定の確認によって Terraform が次に何を変更すべきかを判断します。