자동 초기화되는 애플리케이션 시작하기

소개

실행 중인 인스턴스는 애플리케이션이 올바르게 초기화되었을 때 비로소 유용합니다. Terraform으로 준비된 애플리케이션 AMI를 읽고, 제공된 네트워크에 EC2 인스턴스를 시작하며, User Data로 애플리케이션을 구성합니다.

Terraform 변수와 리소스 참조, 퍼블릭 서브넷 라우팅, 보안 그룹, EC2 시작의 기초를 알고 있어야 합니다. 이 새로운 환경에는 AMI, 키 페어, 네트워크, 별도의 참조 애플리케이션이 제공됩니다. 여러분은 자신의 애플리케이션 인스턴스를 생성하고 삭제합니다.

관련 자격증 시험 항목

실습 개요

AMI 읽기 및 애플리케이션 시작하기

이 단계에서는 준비된 AMI, 네트워크 입력값, User Data를 Terraform EC2 리소스에 연결한 뒤 초기화된 애플리케이션의 응답을 확인합니다.

Terminal과 AWS View를 여세요. 참조 서버는 이미 실행 중입니다. 애플리케이션 네트워크는 준비되어 있지만 아직 application-server는 없습니다. 이 실습은 이전 실습의 VM이나 리소스를 재사용하지 않습니다.

작업 디렉터리로 이동하여 준비된 입력값을 확인합니다.

cd /home/labex/project/application-launch
cat terraform.tfvars.json

이 값들은 제공된 AMI, 서브넷, 보안 그룹을 식별합니다. 네트워크는 이미 인스턴스 시작 시 퍼블릭 IP를 할당하며, 인터넷 경로가 있고, User 클라이언트의 애플리케이션 포트 8081 접근을 허용합니다. Terraform은 이 과정의 환경에 맞게 준비되어 있으므로 개인 자격 증명은 필요하지 않습니다.

독립적인 AWS 조회로 제공된 애플리케이션 이미지를 찾습니다. AMI는 인스턴스 생성 시 사용하는 이미지를 설명합니다. 기존 AMI를 읽는다고 새 이미지가 생성되지는 않습니다.

aws ec2 \
  describe-images \
  --filters Name=name,Values=report-server-ubuntu-2204 \
  --query 'Images[].{Image:ImageId,Name:Name,Architecture:Architecture}'

이름은 report-server-ubuntu-2204, 아키텍처는 x86_64이며, ID는 ami_id 입력값과 일치합니다. Terraform 데이터 소스는 기존 객체를 읽고, 리소스는 객체의 수명 주기를 관리합니다. data.aws_ami.application으로 이 AMI를 읽은 다음 aws_instance.application으로 인스턴스를 생성합니다.

application.tf를 생성합니다. 따옴표를 사용한 바깥쪽 heredoc은 셸 확장 없이 HCL을 씁니다. HCL 안에서 ${...}는 Terraform 표현식의 값을 삽입하고, jsonencode는 메시지를 유효한 JSON으로 변환합니다. 안쪽의 따옴표로 감싼 CONFIG heredoc은 새 게스트에서 User Data가 실행될 때 해당 JSON을 준비된 애플리케이션의 구성 파일에 씁니다.

cat > application.tf <<'HCL'
data "aws_ami" "application" {
  most_recent = true
  filter {
    name   = "image-id"
    values = [var.ami_id]
  }
}

resource "aws_instance" "application" {
  ami                    = data.aws_ami.application.id
  instance_type          = "t3.micro"
  key_name               = "report-key"
  subnet_id              = var.subnet_id
  vpc_security_group_ids = [var.security_group_id]

  user_data_replace_on_change = true
  user_data = <<-SCRIPT
    #!/bin/bash
    set -eu
    cat > /etc/report-app/config.json <<'CONFIG'
    ${jsonencode({ message = var.message })}
    CONFIG
  SCRIPT

  tags = {
    Name = "application-server"
  }
}

output "instance_id" {
  value = aws_instance.application.id
}

output "image_id" {
  value = data.aws_ami.application.id
}
HCL

인스턴스는 복사한 이미지 ID 대신 AMI 데이터 소스를 참조합니다. 제공된 서브넷과 보안 그룹 입력값이 인스턴스를 준비된 네트워크에 연결합니다. User Data는 최초 부팅 중에 실행되어 애플리케이션을 구성하며, 대화형 로그인 명령이 아닙니다. 기본 message 입력값은 Terraform report application입니다. user_data_replace_on_change는 이후 시작 구성 변경이 명시적인 교체로 이어지게 합니다. 이 릴리스 동작은 이후 실습에서 살펴봅니다.

초기화하고 형식을 정리한 뒤 유효성을 검사합니다.

terraform init
terraform fmt
terraform validate

init에서 Incomplete lock file information for providers가 표시되면 다른 플랫폼의 체크섬에 관한 메시지입니다. 준비된 이 VM은 linux_amd64를 사용합니다. 초기화와 유효성 검사가 성공하면 계속 진행하세요.

계획을 검토합니다. 제공된 AMI를 읽고 EC2 인스턴스 하나를 생성하자고 제안해야 합니다. 참조 서버를 교체하거나 새 AMI를 생성해서는 안 됩니다.

terraform plan

적용하고 확인 요청이 나오면 yes를 입력합니다.

terraform apply

결과로 얻은 인스턴스 및 이미지 ID를 저장하고 표시합니다.

INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"

인스턴스를 독립적으로 조회합니다. 실행 상태, 이미지, 서브넷, 보안 그룹을 준비된 입력값과 비교하여 확인하세요.

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId,Subnet:SubnetId,Groups:SecurityGroups[].GroupId,PublicIP:PublicIpAddress}'

AWS View에서 application-server, User · 198.51.100.10, Application · 8081을 선택한 다음 Send request를 클릭하세요. Connected · 200과 Terraform report application이 표시되어야 합니다. 실제 애플리케이션 응답은 시작 구성이 워크로드에 전달되었음을 보여 줍니다. running만으로는 이 결과를 확인할 수 없습니다.

확인 화면 예시: AWS View에 실행 중인 애플리케이션과 실제 초기화된 메시지가 표시됩니다. 리소스 ID와 주소는 VM마다 다릅니다.

Terraform의 매핑을 살펴보고 수렴을 확인합니다.

terraform state list
terraform plan

상태에는 AMI 데이터 소스와 인스턴스 리소스가 포함되며, 계획에는 No changes.가 표시됩니다.

인스턴스 삭제 및 제공된 인프라 보존하기

이 단계에서는 원본 이미지, 준비된 네트워크, 참조 애플리케이션을 보존하면서 Terraform으로 관리하는 애플리케이션 인스턴스만 삭제합니다.

데이터 소스는 읽는 이미지에 대한 소유권을 갖지 않습니다. VPC, 서브넷, 경로, 보안 그룹, 키 페어도 이 상태의 관리 범위 밖에서 제공되었습니다. 승인하기 전에 삭제 범위를 검토하세요.

terraform plan -destroy

삭제할 관리 대상 인스턴스가 하나여야 합니다. 그런 다음 삭제를 실행하고 yes를 입력합니다.

terraform destroy

같은 인스턴스 ID를 조회합니다. 상태는 terminated여야 합니다. 요청 실패는 인스턴스 종료의 증거가 아닙니다.

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

준비된 이미지는 원래 ID로 계속 존재해야 합니다.

aws ec2 \
  describe-images \
  --image-ids "$IMAGE_ID" \
  --query 'Images[].{Image:ImageId,Name:Name}'

남은 상태를 확인합니다.

terraform state list

관리 중인 애플리케이션 리소스가 없어야 합니다. AWS View에서 종료된 인스턴스는 더 이상 실행 중인 대상으로 선택할 수 없습니다. reference-server, User 출발지, 포트 8081을 선택하여 요청을 보냅니다. 응답은 여전히 Connected · 200과 Reference application이어야 합니다.

검토할 수 있도록 HCL 파일을 유지하세요. 남아 있는 구성은 이후 일반 계획에서 새 인스턴스를 제안하게 됩니다. 이것이 삭제 작업의 실패를 뜻하지는 않습니다.

요약

AMI 데이터 소스와 EC2 리소스를 구분하고, 제공된 네트워크 입력값을 연결하고, User Data로 애플리케이션을 초기화한 뒤 실제 응답을 확인했습니다. 변경 없는 계획을 확인하고 관리 중인 인스턴스만 삭제하면서 이미지, 네트워크, 참조 애플리케이션은 보존했습니다.