アプリケーションのデプロイを再利用して変更する

はじめに

アプリケーションのデプロイは、変更のたびにインスタンスを置き換えるとは限りません。用意されたローカルモジュールを使い、ワークロードを保持するタグ更新を確認してから、インスタンスを置き換える新しい起動設定を公開します。アプリケーションは、用意された外部ストレージからレポートを読み取ります。

Terraform の基本的なモジュール呼び出し、プラン、状態に加えて、前の EC2 とワークロードロールの実験の知識を前提とします。新しい環境には、初期デプロイ、ネットワーク、AMI、ロールとプロファイル、非公開レポート、参照用アプリケーションが用意されています。モジュール呼び出しを変更し、各段階でリソース ID、ローカルファイル、外部データを観察します。

認定試験との関連

実験の概要

モジュールのインターフェースを読んで更新を適用する

このステップでは、用意されたモジュールの入力と出力を読み、リリースタグの入力を変更して、既存のインスタンスとローカルファイルがそのまま残ることを検証します。

上部の AWS View は Terminal と同じリソースを観察し、実際のワークロードへのリクエストを送信します。モジュールのデプロイはすでに稼働しています。用意されたロールとプロファイルは、必要なレポートの読み取りだけを許可します。ネットワーク、ロール、レポート用バケットは、このルートの所有範囲外です。

ルートの呼び出しと、小さなモジュールのインターフェースを確認します。

cd /home/labex/project/application-releases
cat application.tf
cat modules/application/variables.tf
cat modules/application/outputs.tf
cat modules/application/main.tf
terraform state list
ORIGINAL_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

source = "./modules/application" は、ローカルモジュールのディレクトリを選択します。呼び出しは、準備済みのインフラストラクチャ入力に加えて、message と release_label を渡します。子モジュールが EC2 リソースを作成し、その出力がルートの出力を通じて実際のインスタンス ID を公開します。そのため、状態のアドレスは module.application で始まります。

モジュールは release_label を ReleaseNote タグに対応付けます。message を User Data に組み込み、user_data_replace_on_change を有効にします。用意された実装を保持しながら、呼び出し側の入力を変更します。modules/application/ 内の 3 つのファイルはすべて変更せず、用意されたローカルモジュールを使ってください。変更はルートの呼び出しで行います。

AWS View で application-server、User · 198.51.100.10、Application · 8081、Health を選択し、Send request をクリックします。Connected · 200 と Application release one が表示されるはずです。Local report file を選び、再送信します。準備済みインスタンスには local,existing-record が含まれています。Private report を選ぶと、別の S3 レポート period,total / Q1,320 を読み取れます。

タグ入力だけを initial から reviewed に変更します。これにより、すべてのインフラストラクチャ参照と起動メッセージを保持したまま、小さなルートの呼び出しを書き換えます。

cat > application.tf <<'HCL'
module "application" {
  source = "./modules/application"
  ami_id = var.ami_id
  subnet_id = var.subnet_id
  security_group_id = var.security_group_id
  profile_name = var.profile_name
  report_bucket = var.report_bucket
  message = "Application release one"
  release_label = "reviewed"
}
output "instance_id" { value = module.application.instance_id }
output "image_id" { value = module.application.image_id }
output "report_bucket" { value = var.report_bucket }
HCL
terraform fmt
terraform validate
terraform plan

インスタンスの作成や削除がなく、モジュール内のインスタンスタグを置き換えずに更新する操作を確認します。適用し、yes を入力します。

terraform apply

実際の ID とサービス側のタグを比較します。

echo "$ORIGINAL_ID"
terraform output -raw instance_id
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Tags:Tags}'

ID は変更されず、ReleaseNote は reviewed になります。AWS View で、同じインスタンスに Health と Local report file のリクエストを送信してください。メッセージは引き続き Application release one で、既存のローカルレコードも残っています。タグ更新では、起動時の初期化は再実行されません。

terraform plan

No changes. と表示されるはずです。

起動設定による置き換えを確認して適用する

このステップでは、起動メッセージを変更し、保存済みの置き換えプランを確認して、外部レポートを保持しながら新しいワークロードを検証します。

メッセージは User Data の一部です。このモジュールの user_data_replace_on_change 設定により、起動設定の変更は明示的なインスタンスの置き換えになります。既存のローカルレコードは古いインスタンスのファイルシステムに属し、S3 レポートは別に用意されたストレージに属します。

呼び出しのメッセージを変更し、プランを保存します。

sed -i 's/Application release one/Application release two/' application.tf
terraform fmt
terraform validate
terraform plan -out=release.tfplan
terraform show release.tfplan

インスタンスの -/+ の置き換えと、変更された User Data を確認してください。用意されたネットワーク、ロール、プロファイル、イメージ、バケット、参照用アプリケーションが削除されてはいけません。release.tfplan は、次のコマンドのために確認済みプランを保存します。

保存済みのプランを適用します。

terraform apply release.tfplan

保存済みプランの適用では、再度 yes は求められません。このコマンドは保存された操作を適用します。完了を待ってから、実際の 2 つのインスタンス ID を比較します。

NEW_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
echo "$NEW_ID"
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId}'

ID は異なります。元のインスタンスは terminated、新しいインスタンスは同じ準備済み AMI 上で running です。行の順序に頼らず、ID を照合してください。

AWS View で、稼働中の application-server エントリーを選択し、Health を送信します。Connected · 200 と Application release two が表示されるはずです。終了した古いインスタンスは、稼働中の対象として選択できなくなります。

Local report file を送信します。内容は、新しいインスタンスで User Data によって作成された local,initialized になっています。古いインスタンスのローカルレコードは、置き換えでは保持されませんでした。次に Private report を送信します。外部 S3 レポートは引き続き Connected · 200 と period,total / Q1,320 を返します。Unrelated private object を送信すると、Connected · 403 と Access denied が表示されるはずです。

最後に reference-server、User、ポート 8081、Health を選び、リクエストを送信します。引き続き Connected · 200 と Reference application を返す必要があります。

terraform plan

No changes. と表示されるはずです。新しいインスタンスはモジュールによって管理され、外部データと参照用環境はそのまま保持されています。

モジュールのワークロードを削除して依存先を保持する

このステップでは、用意されたインフラストラクチャ、ワークロードのロール、外部レポートデータを保持しながら、管理対象の置き換え後のインスタンスを削除します。

ルートの管理対象リソースを削除する前に、イメージ ID を記録します。

IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
terraform plan -destroy

削除対象は管理対象のインスタンス 1 つのはずです。AMI データソースは既存のイメージを読み取り、ネットワーク、プロファイル、ロール、バケットは準備済みの入力としてモジュールに渡されています。削除を適用し、yes を入力します。

terraform destroy

サービス側で置き換え後のインスタンスが終了した状態を照会し、残った状態を確認します。

aws ec2 \
  describe-instances \
  --instance-ids "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

terminated が表示され、状態に管理対象のインスタンスが残っていないはずです。用意されたイメージとプロファイルは、引き続き存在しなければなりません。

aws ec2 describe-images --image-ids "$IMAGE_ID" --query 'Images[].{ID:ImageId,Name:Name}'
aws iam \
  get-instance-profile \
  --instance-profile-name supplied-application-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Terminal の運用担当者で、保持された S3 レポートを読みます。これは外部データの保持を確認するもので、ワークロード自体の限定的なアクセスは削除前に検証済みです。

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/g5-retained-report.csv
cat /tmp/g5-retained-report.csv

バイト列は period,total / Q1,320 のままです。AWS View で reference-server、User、ポート 8081、Health を選び、リクエストを送信します。Connected · 200 と Reference application が表示されるはずです。

ルートとモジュールのファイルは確認用に保持してください。HCL が残っていると、後で通常のプランを実行したときに新しいインスタンスが提案されます。クリーンアップで必要なのは、サービス側で管理対象ワークロードを削除することであり、将来のプランを空にすることではありません。

まとめ

用意されたモジュールの入力と出力を使って、既存のワークロードを更新し、置き換えたワークロードを公開しました。リソースとデータへの影響を確認し、保存済みプランを適用して、インスタンス内のローカルファイルと保持される外部レポートを区別し、モジュールが所有するワークロードだけを削除しました。