TerraformによるAWSリソースの更新

今日は、Terraformを使用してAWSリソースの更新についてご紹介します。

背景

前回の記事では、Terraformで最初のインフラストラクチャであるAWS上の1つのEC2インスタンスを作成しました。この記事では、そのリソースを変更し、変更をTerraformプロジェクトに適用する方法をご紹介します。

インフラは絶えず進化しており、Terraformはその変化を管理するのに役立ちます。Terraformの設定を変更すると、Terraformは目的の状態に到達するために必要なものだけを変更する実行計画を構築します。

Terraformを本番で使用する場合は、バージョン管理システムで設定ファイルを管理し、Terraform CloudやTerraform Enterpriseなどのリモートバックエンドに状態を保存することをお勧めします。

事前準備

この記事は、前回の記事から継続していることを前提としています。前回の記事を参照していない方は、前回の記事を参照することをおすすめします。

AWSリソースの更新

TerraformでEC2を構築

更新する前に、下記の手順で前回作成したEC2を構築します。

cd learn-terraform-aws-instance

export AWS_ACCESS_KEY_ID=[Terraformを実行するIAMユーザーのアクセスキーを入力]

export AWS_SECRET_ACCESS_KEY=[Terraformを実行するIAMユーザーのシークレットキーを入力]

terraform init

terraform apply

TerraformでEC2を更新

次に、インスタンスの ami を更新します。現在の AMI ID を新しい ID に置き換えて、main.tf のプロバイダー ブロックの下にある aws_instance.app_server リソースを変更します。

更新内容は赤文字になっている箇所になります。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }

  required_version = ">= 1.2.0"
}

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "app_server" {
  ami           = "ami-0bccc42bba4dedac1"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

このアップデートにより、AMI が RHEL-8.4.0 AMI に変更されます。 AWS プロバイダーは、インスタンスの作成後にその AMI を変更できないことを認識しているため、Terraform は古いインスタンスを破棄し、新しいインスタンスを作成します。

AWSリソースの更新

構成を変更した後、terraform apply を再度実行して、Terraform がこの変更を既存のリソースにどのように適用するかを確認します。

terraform apply

接頭語の-/+は、Terraformがその場で更新するのではなく、リソースを破棄して再作成することを意味しています。Terraformは一部の属性を内部で更新できますが（プレフィックスが~の場合）、EC2インスタンスのAMIを変更する場合は再作成が必要です。Terraformはこれらの詳細を処理し、実行計画はTerraformが何を行うかを表示します。

aws_instance.app_server: Refreshing state... [id=i-014e6c5976ed6072f]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # aws_instance.app_server must be replaced
-/+ resource "aws_instance" "app_server" {

さらに、実行計画では、AMIの変更がTerraformにインスタンスの置き換えを強制するものであることがわかります。この情報を使って、必要であれば破壊的な更新を避けるように変更を調整することができます。

もう一度、Terraformは実行計画を進める前に承認を求めるプロンプトを表示します。計画したステップを実行するために、「yes」と答えてください。

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: 

aws_instance.app_server: Destroying... [id=i-014e6c5976ed6072f]
aws_instance.app_server: Still destroying... [id=i-014e6c5976ed6072f, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-014e6c5976ed6072f, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-014e6c5976ed6072f, 30s elapsed]
aws_instance.app_server: Destruction complete after 31s
aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Creation complete after 33s [id=i-0c576726ba8363199]

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.

実行計画で示されているように、Terraformはまず既存のインスタンスを破棄し、その場所に新しいインスタンスを作成しました。terraform show を使うと、Terraformにこのインスタンスに関連する新しい値を出力させることができます。

AWSコンソールマネジメントで下記のようになっていれば成功です。

この画面は、EC2で検索 -> サービスのEC2 -> インスタンス の順でクリックすると見れます。

おわりに

今日は、Terraformを利用してAWSリソースの更新を実施しました。次回は、このリソースの破棄をしたいと思います。

今回使用したTerraformのソースは下記のGitHubにあります。