リソースを再作成せずに名前を変更する

はじめに

設定に分かりやすい名前を付けるために、稼働中のストレージを再作成する必要はないはずです。管理対象のレポート用バケットの Terraform アドレスを変更し、安全でない直接の名前変更と、宣言による移動の違いを確認して、元のデータを保持します。

前のガイド付き実験、または同等の演習で、Terraform のインポート、状態、プランを扱った経験が必要です。この新しい環境には、この実験用の管理対象レポートと、独立した財務チームの参照用レポートが用意されています。Terraform の操作には Terminal、既存レポートの確認には AWS View を使用します。個人の AWS アカウントは不要です。

認定試験との関連

認定資格	試験のタスク	演習内容
CloudOps Engineer – Associate (SOA-C03)	Task 3.1, Skill 3.1.6	稼働中のリソースを保持しながら、確認済みの設定と状態の変更を通じてインフラストラクチャを保守する、Terraform の基礎演習です。

実験の概要

概念図：保守作業で、設定、状態、既存のレポート用ストレージの関係を保持します。

論理アドレスとリモートの ID を比較する

このステップでは、リソースの名前を変更する前に、稼働中の Terraform ルートを確認します。ルートと、バージョン管理された 2 つのレポートは、この実験のために独立して用意されています。レポート用バケットはここで管理されていますが、財務チームのストレージはこのルートの管理対象外です。

cd /home/labex/project/report-refactor
terraform state list

元のアドレスは aws_s3_bucket.reports です。そのリモート ID を読み取ります。

terraform state show aws_s3_bucket.reports

id = "rename-daily-reports" は既存の AWS バケットを識別します。Terraform ブロックの名前変更で変わるのは論理アドレスであり、このバケット名ではありません。

用意された設定を読み、変更のない状態を基準として確認します。

cat main.tf
terraform plan

No changes と表示されるはずです。AWS View で rename-daily-reports 内のレポートを展開してください。rename-finance-reference は変更せずに残します。同じレポートのデータを Terminal で読み取ります。

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

Daily sales: 120 orders と表示されるはずです。目的は、ストレージの ID と元のオブジェクトバージョンを保持したまま、このストレージを管理するアドレスを変更することです。

moved ブロックで名前変更を記述する

このステップでは、アドレスを直接変更すると破壊的な操作として見える理由を観察し、その後で、新しいアドレスが同じリソースを指すことを Terraform に伝えます。

ヒアドキュメントは、HCL の区切り語の間にある設定を main.tf に書き込みます。> はそのファイルを置き換えます。リモートのバケット名と属性は変更せず、ローカルのブロックラベルだけを report_archive に変更してください。

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "report_archive" {
  bucket        = "rename-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting" }
}
HCL

何も適用する前に、結果を確認します。

terraform plan

アドレス間の関係がない場合、Terraform は古いアドレスがなくなり、状態に記録されていない新しいアドレスが現れたと判断します。1 to add, 0 to change, 1 to destroy と表示されるはずです。このプランを適用したり、削除を可能にするためにレポートを消したりしてはいけません。

moved ブロックは、古いアドレスから新しいアドレスへの関係を宣言します。これは AWS バケットの名前変更とは異なり、設定のリファクタリングを記録するものです。宣言を別の .tf ファイルに置きます。Terraform は、このルート内のすべての .tf ファイルをまとめて読み取ります。

cat > moved.tf <<'HCL'
moved {
  from = aws_s3_bucket.reports
  to   = aws_s3_bucket.report_archive
}
HCL

修正したプランを保存して確認します。

terraform plan -out=rename.tfplan

aws_s3_bucket.reports has moved to aws_s3_bucket.report_archive と 0 to add, 0 to change, 0 to destroy が表示されるはずです。計画される状態のアドレスは変わりますが、AWS リソースを再作成する必要はありません。古い状態のコピーでもこのリファクタリングを認識できるよう、宣言を設定と一緒に保持してください。

アドレス移行を適用してレポートを保持する

このステップでは、保存した安全なプランを適用し、論理アドレスだけが変更されたことを確認します。保存済みプランは再度の承認プロンプトなしで実行されるため、まず要約で作成も削除もゼロであることを確認してください。

terraform apply rename.tfplan

リソースの要約には 0 added, 0 changed, 0 destroyed と表示されるはずです。変更後の対応付けを確認します。

terraform state list
terraform state show aws_s3_bucket.report_archive

一覧には新しいアドレスだけが表示され、そのバケット ID は rename-daily-reports のままです。実際のレポートを確認します。

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

元の文面 Daily sales: 120 orders が保持されています。AWS View にも同じレポート用バケットと財務チームのバケットが表示されたままです。論理的な名前変更で新しいリソースカードが現れることは想定していません。

terraform plan

No changes と表示されるはずです。独立したチェックでは、元の VersionId と隣接ストレージも比較し、使い捨てのコピーで現在の設定のプランを作成します。次の保守担当者のために、使用中の両方のレポートをそのまま保持してください。

保持した moved 宣言がモジュールの発展で果たす役割については、HashiCorp のリソースのリファクタリングに関するドキュメントを参照してください。

まとめ

Terraform のアドレスと AWS のリソース ID を区別し、直接の名前変更による破壊的なプランを適用せずに退け、バケットやレポートを再作成することなく moved 宣言を適用しました。