애플리케이션 네트워크 정의하기

소개

애플리케이션이 실행되려면 먼저 주소 공간이 필요합니다. Terraform으로 AWS VPC와 서브넷을 정의하고, 배포된 네트워크를 Terraform 상태와 비교한 뒤, 애플리케이션 네트워크만 삭제합니다.

Terraform의 init/plan/apply 워크플로, 리소스 주소, AWS VPC 및 서브넷 CIDR의 기초를 이미 알고 있어야 합니다. Terminal, Terraform 도구, AWS CLI, 별도의 참조 네트워크는 준비되어 있습니다. 각 실습은 독립적으로 시작하므로 이전 VM의 리소스는 필요하지 않습니다.

관련 자격증 시험 항목

실습 개요

VPC 정의 및 배포하기

이 단계에서는 애플리케이션의 주소 계획을 Terraform 리소스로 정의하고 생성된 VPC를 확인합니다.

Terminal을 여세요. AWS View에는 현재 네트워크 리소스가 표시됩니다. AWS View로 토폴로지를 관찰하고, CLI로 정확한 필드를 조회하며, Terraform으로 변경 사항을 관리합니다. 기존 reference-network는 다른 애플리케이션의 소유이므로 변경하지 않아야 합니다.

VPC는 리전 범위의 네트워크 경계입니다. CIDR 블록은 주소 범위를 정의합니다. 10.62.0.0/16은 이 애플리케이션을 위한 주소를 확보합니다. Terraform의 aws_vpc.application은 AWS ID가 아니라 구성 주소입니다. AWS는 생성 후 ID를 할당합니다.

application-network 디렉터리에는 준비된 프로바이더 구성이 있습니다. 이 구성은 제공된 계정과 테스트된 도구 버전을 선택합니다. 해당 디렉터리로 이동하세요.

cd /home/labex/project/application-network

main.tf를 생성합니다. 따옴표를 사용한 heredoc은 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

최종 요약에는 추가할 리소스가 하나로 표시되어야 합니다. 구성을 적용하고 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 매핑을 확인합니다.

서브넷은 정확히 하나의 VPC와 하나의 가용 영역에 속합니다. 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를 교체하지 않고 서브넷을 추가하며 두 출력값을 제공해야 합니다.

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

삭제할 리소스가 두 개여야 합니다. 계속하기 전에 리소스 주소를 확인하세요. 그런 다음 애플리케이션 네트워크를 삭제하고 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은 us-east-1b에서 10.90.1.0/24로 유지됩니다. 이제 AWS View에는 참조 네트워크만 표시됩니다. 애플리케이션 리소스가 삭제되어도 HCL 파일은 남아 있어 검토할 수 있습니다.

요약

HCL로 VPC와 서브넷을 정의하고, 리소스 참조를 사용하여 연결하고, 실제 AWS 네트워크 필드를 Terraform 상태와 비교한 뒤 변경 없는 계획을 확인했습니다. 그런 다음 관리 중인 네트워크만 삭제하고 관련 없는 참조 네트워크는 보존했습니다. 애플리케이션에 접근할 수 있게 하려면 라우팅과 보안 규칙을 별도로 설정해야 합니다.