アプリケーションのネットワークを定義する

はじめに

アプリケーションを実行するには、まずアドレス空間が必要です。Terraform で AWS の VPC とサブネットを定義し、デプロイしたネットワークを Terraform の状態と比較して、アプリケーションのネットワークだけを削除します。

Terraform の init/plan/apply ワークフロー、リソースアドレス、および AWS の VPC とサブネットの CIDR の基礎を理解していることを前提とします。Terminal、Terraform ツール、AWS CLI、独立した参照用ネットワークは準備済みです。各実験は独立して開始するため、以前の VM のリソースは必要ありません。

認定試験との関連

実験の概要

VPC を定義してデプロイする

このステップでは、アプリケーションのアドレス計画を Terraform のリソースとして表し、作成された VPC を確認します。

Terminal を開きます。AWS View には現在のネットワークリソースが表示されるので、トポロジーの観察に使用します。CLI で正確なフィールドを取得し、Terraform で変更を管理します。既存の reference-network は別のアプリケーションの所有物なので、変更せずに残す必要があります。

VPC はリージョン内のネットワーク境界です。その CIDR ブロックがアドレス範囲を定めます。10.62.0.0/16 は、このアプリケーション用のアドレスを確保します。Terraform の aws_vpc.application は設定のアドレスであり、AWS の ID ではありません。ID は作成後に AWS が割り当てます。

application-network ディレクトリには準備済みのプロバイダー設定が含まれています。用意されたアカウントとテスト済みのツールバージョンを選択する設定です。このディレクトリに移動します。

cd /home/labex/project/application-network

main.tf を作成します。引用符で囲んだ区切り語を使うヒアドキュメントは、HCL までの HCL をそのまま書き込みます。> はこのファイルを作成または置き換えます。Name タグにより、アプリケーションのネットワークを参照用ネットワークから簡単に区別できます。

cat > main.tf <<'HCL'
resource "aws_vpc" "application" {
  cidr_block = "10.62.0.0/16"
  tags = {
    Name = "application-network"
  }
}
HCL

作業ディレクトリを初期化して必要なプロバイダーを選択し、設定を整形して検証します。検証では設定の構造を確認しますが、リソースの存在を証明するものではありません。

terraform init
terraform fmt
terraform validate

init が Incomplete lock file information for providers と表示した場合は、他のプラットフォーム向けのチェックサムについての説明です。この準備済み VM は linux_amd64 を使用します。初期化と検証が成功したら続行してください。

プランを確認します。Terraform は VPC のデフォルト設定も表示します。追加予定のリソースで cidr_block と Name タグを探してください。

terraform plan

最後の要約には、追加するリソースが 1 つと表示されるはずです。設定を適用し、Terraform が確認を求めたら yes を入力します。

terraform apply

実際の VPC を照会します。--filters はアプリケーションのタグで絞り込み、--query は ID と CIDR だけを表示します。ID は実行ごとに異なりますが、CIDR は必ず 10.62.0.0/16 でなければなりません。

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].{ID:VpcId,CIDR:CidrBlock}'

AWS View で表示を更新して確認してください。アプリケーションの VPC が参照用 VPC の隣に表示されます。新しい VPC には、まだアプリケーション用のサブネットがありません。

リソース参照でサブネットを接続する

このステップでは、アプリケーションの VPC 内にサブネットを作成し、そのアドレス範囲、アベイラビリティーゾーン、Terraform の対応付けを検証します。

サブネットは、必ず 1 つの VPC と 1 つのアベイラビリティーゾーンに属します。us-east-1a で、VPC の /16 に含まれる小さな範囲 10.62.1.0/24 を使用します。この CIDR やアベイラビリティーゾーンだけでサブネットがパブリックになるわけではありません。インターネットへのルーティングとアクセスルールは、後で扱います。

subnet.tf を作成します。式 aws_vpc.application.id は VPC リソースを参照します。Terraform はこの依存関係に基づき、サブネットより先に VPC を作成し、実際の ID を自動的に取得します。コマンド出力から ID を HCL にコピーする必要はありません。

cat > subnet.tf <<'HCL'
resource "aws_subnet" "application" {
  vpc_id            = aws_vpc.application.id
  cidr_block        = "10.62.1.0/24"
  availability_zone = "us-east-1a"
  tags = {
    Name = "application-subnet"
  }
}

output "vpc_id" {
  value = aws_vpc.application.id
}

output "subnet_id" {
  value = aws_subnet.application.id
}
HCL

新しいファイルを整形して検証し、プランを確認します。VPC を置き換えずにサブネットを追加し、2 つの出力を公開するプランになるはずです。

terraform fmt
terraform validate
terraform plan

適用し、yes で確認します。

terraform apply

生成された ID を保存して表示します。$(...) はコマンドの出力を取り込み、terraform output -raw は引用符なしの文字列を返します。

VPC_ID=$(terraform output -raw vpc_id)
echo "$VPC_ID"
SUBNET_ID=$(terraform output -raw subnet_id)
echo "$SUBNET_ID"

AWS に独立して照会します。サブネットの VPC フィールドは表示された VPC ID と一致し、CIDR は 10.62.1.0/24、アベイラビリティーゾーンは us-east-1a でなければなりません。

aws ec2 \
  describe-subnets \
  --subnet-ids "$SUBNET_ID" \
  --query 'Subnets[].{ID:SubnetId,VPC:VpcId,CIDR:CidrBlock,Zone:AvailabilityZone}'

Terraform の状態は、設定のアドレスをデプロイ済みのリソースに対応付けます。この対応付けを確認してください。状態のエントリーがあるだけで動作するネットワークの証拠とせず、VPC とサブネットの ID を AWS と比較します。

terraform state list
terraform state show aws_subnet.application

一覧には aws_vpc.application と aws_subnet.application が含まれます。次に、収束していることを確認します。

terraform plan

No changes. と表示されるはずです。AWS View では、アプリケーションのサブネットが実際に属する VPC の中に表示され、変更されていない参照用ネットワークも並んでいます。

アプリケーションのネットワークだけを削除する

このステップでは、削除の順序を確認し、Terraform のスタックを削除して、参照用ネットワークが残ることを確認します。

Terraform は同じ依存関係グラフを逆順に使い、VPC より先にサブネットを削除します。削除プランはこの作業ディレクトリが管理するリソースを対象とするため、別途用意された参照用ネットワークは含まれないはずです。

予定される削除を確認します。

terraform plan -destroy

削除対象は 2 つのリソースのはずです。続行する前にリソースアドレスを確認してください。その後、アプリケーションのネットワークを削除し、yes を入力します。

terraform destroy

アプリケーションのリソースをタグで照会します。両方のクエリが空の一覧を返すはずです。リクエストの失敗は削除の証拠にはなりません。

aws ec2 \
  describe-vpcs \
  --filters Name=tag:Name,Values=application-network \
  --query 'Vpcs[].VpcId'
aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=application-subnet \
  --query 'Subnets[].SubnetId'

Terraform がリソースを管理していないことを確認します。

terraform state list

このコマンドはリソースアドレスを何も表示しません。最後に、保持された参照用サブネットを確認します。

aws ec2 \
  describe-subnets \
  --filters Name=tag:Name,Values=reference-subnet \
  --query 'Subnets[].{CIDR:CidrBlock,Zone:AvailabilityZone}'

その CIDR は 10.90.1.0/24、アベイラビリティーゾーンは us-east-1b のままです。AWS View には参照用ネットワークだけが表示されます。アプリケーションのリソースを削除しても、HCL ファイルは確認用に残っています。

まとめ

HCL で VPC とサブネットを定義し、リソース参照で接続し、実際の AWS ネットワークのフィールドを Terraform の状態と比較して、変更のないプランを確認しました。その後、管理対象のネットワークだけを削除し、無関係の参照用ネットワークを保持しました。アプリケーションにアクセスできるようにするには、ルーティングとセキュリティルールを別途設定する必要があります。