TerraformによるAWSリソースの作成

よっしー

こんにちは。よっしーです(^^)

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

背景
事前準備
AWSリソースの作成
解説
おわりに

背景

Terraformは、クラウドインフラストラクチャの自動化とプロビジョニングを支援するためのオープンソースのインフラストラクチャコードツールです。以下に、Terraformを使用してAWSリソースを作成する理由をいくつか挙げます。

インフラストラクチャのコード化: Terraformはインフラストラクチャをコードとして扱います。これにより、インフラストラクチャの状態をバージョン管理し、変更の履歴を追跡することができます。また、コードによるインフラストラクチャの管理は、手動での作業よりも効率的で正確です。
リソースの一貫性: Terraformを使用すると、AWSリソースの作成や変更が一貫性のある方法で行われます。コードで定義されたインフラストラクチャを再現するため、環境間でのリソースの一貫性を維持しやすくなります。
インフラストラクチャの可視性: Terraformのコードは、インフラストラクチャの設計と構成を明確に示します。コードを読むことで、作成されるリソースやその依存関係、設定の詳細が把握できます。これにより、チーム内の共有やコラボレーションが容易になります。
プロビジョニングの自動化: Terraformは、AWSリソースの作成や設定のプロビジョニングを自動化することができます。インフラストラクチャの定義をコードとして記述し、Terraformを実行することで、指定したリソースが自動的に作成されます。これにより、手作業にかかる時間とヒューマンエラーを削減することができます。
インフラストラクチャの変更管理: インフラストラクチャの要件や設計が変更された場合、Terraformのコードを更新することで変更を反映できます。Terraformは既存のリソースと新しい定義との差分を自動的に検出し、必要な変更を適用します。変更の管理が簡単であり、再現性と一貫性が保たれます。

これらの理由から、TerraformはAWSリソースの作成と管理において非常に有用です。Terraformを使用することで、効率的にインフラストラクチャを構築し、柔軟性のある管理が可能になります。

上記の理由と重複する部分もありますが、以下に具体的な利点をいくつか挙げます。

インフラストラクチャの共有と再利用: Terraformのコードは再利用性が高く、モジュール化されています。共通のパターンやベストプラクティスをモジュールとして定義し、プロジェクト間で共有できます。これにより、インフラストラクチャの設計や構成の再利用が容易になり、時間と作業量を削減できます。
クラウドプロバイダの選択の柔軟性: TerraformはAWSだけでなく、他の主要なクラウドプロバイダ（Azure、Google Cloud Platformなど）やオンプレミス環境にも対応しています。同じTerraformのコードを使用して、異なる環境に対して一貫性のあるインフラストラクチャを構築できます。これにより、クラウドプロバイダを変更する場合でも、インフラストラクチャの移行が容易になります。
インフラストラクチャの監視と管理: Terraformは、インフラストラクチャの監視や変更管理に役立ちます。例えば、Terraformを使用して作成されたリソースは、Terraformの状態ファイルに記録されます。この状態ファイルは、インフラストラクチャの現在の状態を示すため、変更の追跡や問題のトラブルシューティングに役立ちます。
インフラストラクチャのスケーラビリティ: Terraformを使用すると、必要に応じてインフラストラクチャをスケーリングすることが容易になります。コードを更新して必要なリソース数や設定を変更し、Terraformを実行するだけで、新しいリソースを追加したり既存のリソースをスケールアップしたりできます。
インフラストラクチャの破棄と再作成: Terraformは、インフラストラクチャの破棄と再作成を簡単に実行できます。不要なリソースを削除するためにTerraformを実行するだけで、環境をクリーンアップできます。これにより、リソースの無駄な使用やコストの節約につながります。
プロビジョニングの再現性と信頼性: Terraformを使用すると、インフラストラクチャのプロビジョニングが再現可能で信頼性が高くなります。コードによる定義と自動化により、手動での作業に比べてエラーの可能性を軽減できます。また、Terraformは依存関係を解決してリソースを正しい順序で作成するため、一貫性が保たれます。
チームの協業と共有: Terraformは、複数の開発者や運用チームとの協業を支援します。コードベースのインフラストラクチャ管理により、変更の履歴やレビューが容易になります。また、Terraformのコードはバージョン管理システムで管理できるため、チームメンバーとの共有や協力的な開発がスムーズに行えます。
インフラストラクチャのセキュリティ: Terraformを使用することで、セキュリティのベストプラクティスを継続的に適用できます。コードでインフラストラクチャのセキュリティルールや設定を明示し、監査やコンプライアンスの要件を満たすことができます。また、Terraformのセキュリティグループやアクセス権限の管理機能を活用することで、リソースへのアクセスを制御し、セキュリティを強化できます。

これらの理由から、TerraformはAWSリソースの作成と管理において強力なツールとなっています。インフラストラクチャの自動化、一貫性、可視性、変更管理、スケーラビリティ、セキュリティなどの利点を享受することができます。

事前準備

Terraformのインストール

Terraformのインストールに関しては下記の記事を御覧ください。

asdfを利用したterraformコマンドのインストール

よっしーこんにちは。よっしーです(^^) 今日は、asdfコマンドを使用したterraformコマンドのインストール方法をご紹介します。背景これまで、terraformコマンドはHomebrewを利用してインストールしていました。具体...

Terraform実行用のIAMユーザーの作成

Terraform実行用のIAMユーザーの作成に関しては下記の記事を御覧ください。

Terraformの実行用IAMユーザーの作成

よっしーこんにちは。よっしーです(^^) 今日は、Terraformの実行用IAMユーザーの作成についてご紹介します。背景 Terraformを使用してAWSリソースを管理する場合、下記の理由からTerraform専用のIAMユーザーを...

Terraform実行用のIAMユーザーへのポリシー付与

Terraform実行用のIAMユーザーへのポリシー付与に関しては下記の記事を御覧ください。

Pikeを使用した最低限のIAMポリシーの作成

よっしーこんにちは。よっしーです(^^) 今日は、先日作成したTerraformの実行用IAMユーザーへのポリシーの作成についてご紹介します。背景 Terraformを使用してAWSリソースを作成、変更、削除する場合、Terraform...

AWSリソースの作成

Terraformコンフィギュレーションの用意

Terraformでインフラを記述するためのファイル群をTerraformコンフィギュレーションと呼びます。1台のAWS EC2インスタンスを定義するために、最初のコンフィギュレーションを記述します。

Terraformの各設定は、それぞれ独自の作業ディレクトリに置く必要があります。設定用のディレクトリを作成します。

mkdir learn-terraform-aws-instance

cd learn-terraform-aws-instance

touch main.tf

テキストエディタで main.tf を開き、以下の設定を貼り付けて、ファイルを保存します。

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-04310c38b29b29953"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

AWSリソースの作成

IAM 認証情報を使用して Terraform AWS プロバイダーを認証するには、AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY の環境変数を設定します。

export AWS_ACCESS_KEY_ID=[作成したIAMユーザーのアクセスキーを入力]
export AWS_SECRET_ACCESS_KEY=[作成したIAMユーザーのシークレットキーを入力]

新しい設定を作るとき、あるいはバージョン管理から既存の設定をチェックアウトするとき、terraform initでディレクトリを初期化する必要があります。

設定ディレクトリを初期化すると、設定に定義されているプロバイダ（この場合はawsプロバイダ）をダウンロードし、インストールします。

terraform init

すべての設定ファイルにおいて、一貫した書式を使用することをお勧めするため、terraform fmtコマンドを実施します。カレントディレクトリにあるコンフィギュレーションを読みやすさと一貫性のために自動的に更新します。

コンフィギュレーションをフォーマットして検証する

Terraform fmtは、変更したファイル名があればそれを出力します。今回の場合、設定ファイルはすでに正しくフォーマットされているので、Terraformはファイル名を返すことはありません。

terraform fmt

また、terraform validateコマンドを使用することで、設定が構文的に有効であり、内部的に一貫していることを確認することができます。

設定を有効化します。上記で提供した設定例は有効なので、Terraformは成功メッセージを返します。

terraform validate

インフラストラクチャの作成

terraform apply コマンドを使用して構成を適用します。

terraform apply

変更を適用する前に、Terraformは実行計画を出力します。これは、インフラを構成に合わせて変更するためにTerraformが取る行動を記述したものです。

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.app_server will be created
  + resource "aws_instance" "app_server" {
以下省略

出力形式は、Gitなどのツールで生成されるdiff形式に似ています。出力にはaws_instance.app_serverの横に+があり、Terraformがこのリソースを作成することを意味しています。その下には、設定される属性が表示されています。表示される値が(known after apply)の場合、リソースが作成されるまで値がわからないことを意味しています。例えば、AWSは作成時にインスタンスにAmazon Resource Names（ARN）を割り当てるので、変更を適用してAWSプロバイダがAWS APIからその値を返すまで、Terraformはarn属性の値を知ることができません。

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

  Enter a value:

Terraformはこれで一時停止し、あなたの承認を待ってから処理を進めます。もし計画の中に間違ったことや危険なことがあれば、Terraformがあなたのインフラを修正する前にここで中止するのが安全です。

今回の場合、計画は受け入れられますので、確認プロンプトで「yes」と入力して次に進んでください。プランの実行には数分かかります

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: Still creating... [40s elapsed]
aws_instance.app_server: Creation complete after 43s [id=xxx]

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

これで、Terraform を使用してインフラストラクチャが作成されました。 EC2 コンソールにアクセスして、新しい EC2 インスタンスを見つけます。赤丸で囲ったようにEC2インスタンスができていれば、成功です。

検査

設定を適用すると、Terraformはterraform.tfstateというファイルにデータを書き込んでいます。Terraformはこのファイルに管理しているリソースのIDやプロパティを保存し、今後リソースを更新したり破棄したりできるようにします。

Terraformのステートファイルは、Terraformが管理するリソースを追跡する唯一の方法であり、しばしば機密情報を含むため、ステートファイルを安全に保存し、インフラを管理する必要がある信頼できるチームメンバーのみにアクセスを制限する必要があります。本番環境では、Terraform CloudまたはTerraform Enterpriseでステートをリモートで保存することをお勧めします。Terraformは、ステートの保存と管理に使用できる他のいくつかのリモートバックエンドもサポートしています。

terraform show を使用して現在の状態を確認します。

terraform show

TerraformはこのEC2インスタンスを作成する際に、AWSプロバイダからリソースのメタデータを収集し、メタデータを状態ファイルに書き込んでいます。後日、これらの値を参照して他のリソースや出力値を設定するように設定を変更します。

状態を手動で管理する

Terraformには、高度な状態管理を行うためのterraform stateというビルトインコマンドがあります。プロジェクトの状態にあるリソースを一覧表示するにはlistサブコマンドを使用します。

terraform state list

解説

main.tf

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-04310c38b29b29953"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleAppServerInstance"
  }
}

このコードは、Terraformを使用してAWSのインフラストラクチャを構築するための設定ファイルです。以下に各部分の解説を示します。

terraform ブロック:
- required_providers ブロック: このブロックでは、Terraformが使用するプロバイダの設定を指定します。この例では、aws プロバイダが必要であることが示されています。
  - source: プロバイダのソースを指定します。この例では、HashiCorpが提供する aws プロバイダを使用しています。
  - version: プロバイダのバージョンを指定します。~> 4.16 は、4.16以上で4.x系の最新バージョンまでの範囲を指定しています。
- required_version: Terraformのバージョン要件を指定します。この例では、バージョン1.2.0以上である必要があります。
provider "aws" ブロック:
- region: AWSリソースが作成されるリージョンを指定します。この例では、ap-northeast-1（東京リージョン）が指定されています。この設定により、後続のリソースがこのリージョンで作成されます。
resource "aws_instance" "app_server" ブロック:
- aws_instance リソース: AWSのEC2インスタンスを作成するためのリソースタイプを指定します。
- "app_server": リソースインスタンスの識別子として使用されます。この例では、aws_instance リソースの名前が app_server となります。
- ami: EC2インスタンスに使用するAMI（Amazon Machine Image）のIDを指定します。この例では、指定されたAMI IDが使用されます。
- instance_type: インスタンスのタイプを指定します。この例では、t2.microが指定されています。
- tags: インスタンスに適用されるタグを指定します。この例では、Name タグが ExampleAppServerInstance となります。

このコードの目的は、AWSのap-northeast-1リージョンにt2.microインスタンスを作成し、指定したAMI IDとタグを適用することです。この設定をTerraformで適用すると、AWS上に指定された設定に基づいてインスタンスが作成されます。

terraform ブロック

terraform ブロックには、Terraformがインフラのプロビジョニングに使用する必須プロバイダを含む、Terraformの設定が含まれています。各プロバイダーについて、source属性はオプションのホスト名、名前空間、プロバイダーの種類を定義します。TerraformはデフォルトでTerraform Registryからプロバイダをインストールします。この設定例では、awsプロバイダのソースはhashicorp/awsと定義されており、これはregistry.terraform.io/hashicorp/awsの略記となっています。

また、required_providersブロックで定義された各プロバイダーに対して、バージョン制約を設定することができます。バージョン属性はオプションですが、Terraformが設定に合わないバージョンのプロバイダをインストールしないように、プロバイダバージョンを制約するために使用することをお勧めします。プロバイダのバージョンを指定しない場合、Terraformは初期化時に自動的に最新バージョンをダウンロードします。

詳しくは、プロバイダーソースのドキュメントを参照してください。

Provider Requirements - Configuration Language | Terraform | HashiCorp Developer

Providers are plugins that allow Terraform to interact with services, cloud providers, and other APIs. Learn how to decl...

provider ブロック

providerブロックは、指定されたプロバイダ（この場合はaws）を設定します。プロバイダとは、Terraformがリソースを作成・管理するために使用するプラグインです。

Terraformの設定で複数のプロバイダブロックを使用し、異なるプロバイダのリソースを管理することができます。異なるプロバイダを一緒に使うこともできます。例えば、AWS EC2インスタンスのIPアドレスをDataDogの監視リソースに渡すことができます。

resources ブロック

resourcesブロックを使って、インフラストラクチャのコンポーネントを定義します。リソースは、EC2インスタンスのような物理的または仮想的なコンポーネントである場合もあれば、Herokuアプリケーションのような論理的なリソースである場合もあります。

resourcesブロックは、ブロックの前にリソースタイプとリソース名という2つの文字列があります。この例では、リソースタイプはaws_instanceで、名前はapp_serverです。タイプのプレフィックスは、プロバイダの名前に対応します。設定例では、Terraformはaws_instanceリソースをawsプロバイダで管理しています。リソースタイプとリソース名を合わせて、リソースのユニークなIDを形成します。例えば、EC2インスタンスのIDはaws_instance.app_serverです。

resourcesブロックには、リソースを設定するために使用する引数が含まれています。引数には、マシンサイズ、ディスクイメージ名、VPC IDなどが含まれます。プロバイダーのリファレンスには、各リソースの必須およびオプションの引数が記載されています。EC2インスタンスでは、AMI IDをAmazon Linux イメージに、インスタンスタイプをt2.micro（AWSの無料ティアに該当）に設定しています。また、インスタンスに名前を付けるためのタグも設定する。