애플리케이션 배포 재사용 및 변경하기

소개

애플리케이션 배포를 변경할 때 모든 변경이 인스턴스 교체를 필요로 하는 것은 아닙니다. 제공된 로컬 모듈을 사용하여 워크로드를 유지하는 태그 업데이트를 검토한 뒤, 워크로드를 교체하는 새 시작 구성을 배포합니다. 애플리케이션은 제공된 외부 스토리지에서 보고서를 읽습니다.

이 실습은 기본적인 Terraform 모듈 호출, 계획, 상태와 앞선 EC2 및 워크로드 역할 실습에 대한 지식을 전제로 합니다. 새로운 환경에는 초기 배포, 네트워크, AMI, 역할과 프로파일, 비공개 보고서, 참조 애플리케이션이 제공됩니다. 모듈 호출을 변경하고 각 단계에서 리소스 식별 정보, 로컬 파일, 외부 데이터를 관찰합니다.

관련 자격증 시험 항목

실습 개요

모듈 인터페이스 읽기 및 업데이트 적용하기

이 단계에서는 제공된 모듈의 입력과 출력값을 읽고, 릴리스 태그 입력값을 변경한 뒤, 기존 인스턴스와 로컬 파일이 온전히 유지되는지 확인합니다.

위쪽 AWS View는 Terminal과 같은 리소스를 관찰하며 실제 워크로드 요청을 보냅니다. 모듈 배포는 이미 실행 중입니다. 제공된 역할과 프로파일은 필요한 보고서 읽기만 허용합니다. 네트워크, 역할, 보고서 버킷은 이 루트의 소유권 밖에 있습니다.

루트 호출과 작은 모듈 인터페이스를 확인합니다.

cd /home/labex/project/application-releases
cat application.tf
cat modules/application/variables.tf
cat modules/application/outputs.tf
cat modules/application/main.tf
terraform state list
ORIGINAL_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

source = "./modules/application"은 로컬 모듈 디렉터리를 선택합니다. 호출은 준비된 인프라 입력값과 함께 message, release_label을 전달합니다. 자식 모듈은 EC2 리소스를 생성하며 출력값을 통해 실제 인스턴스 ID를 루트 출력으로 노출합니다. 따라서 상태 주소는 module.application으로 시작합니다.

모듈은 release_label을 ReleaseNote 태그에 매핑합니다. message는 User Data에 매핑하며 user_data_replace_on_change를 활성화합니다. 제공된 이 구현을 유지하면서 호출 측 입력값을 변경합니다. modules/application/ 아래의 세 파일을 모두 변경하지 않고 제공된 로컬 모듈을 사용하세요. 변경은 루트 호출에서 수행합니다.

AWS View에서 application-server, User · 198.51.100.10, Application · 8081, Health를 선택한 다음 Send request를 클릭하세요. Connected · 200과 Application release one이 표시되어야 합니다. Local report file을 선택하여 다시 보냅니다. 준비된 인스턴스에는 local,existing-record가 있습니다. Private report를 선택하여 별도의 S3 보고서인 period,total / Q1,320을 읽습니다.

태그 입력값만 initial에서 reviewed로 바꿉니다. 모든 인프라 참조와 시작 메시지는 유지하면서 작은 루트 호출을 다시 작성합니다.

cat > application.tf <<'HCL'
module "application" {
  source = "./modules/application"
  ami_id = var.ami_id
  subnet_id = var.subnet_id
  security_group_id = var.security_group_id
  profile_name = var.profile_name
  report_bucket = var.report_bucket
  message = "Application release one"
  release_label = "reviewed"
}
output "instance_id" { value = module.application.instance_id }
output "image_id" { value = module.application.image_id }
output "report_bucket" { value = var.report_bucket }
HCL
terraform fmt
terraform validate
terraform plan

인스턴스 생성이나 삭제 없이 모듈의 인스턴스 태그가 제자리 업데이트되는지 검토합니다. 적용하고 yes를 입력합니다.

terraform apply

실제 ID와 태그를 비교합니다.

echo "$ORIGINAL_ID"
terraform output -raw instance_id
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Tags:Tags}'

ID는 변경되지 않고 ReleaseNote는 reviewed입니다. AWS View에서 같은 인스턴스에 Health와 Local report file 요청을 보냅니다. 메시지는 여전히 Application release one이며 기존 로컬 기록도 남아 있습니다. 태그 업데이트는 시작 초기화를 다시 실행하지 않습니다.

terraform plan

No changes.가 표시되어야 합니다.

시작 구성 교체 검토 및 적용하기

이 단계에서는 시작 메시지를 바꾸고, 저장된 교체 계획을 확인하며, 외부 보고서를 보존하면서 새 워크로드를 검증합니다.

메시지는 User Data의 일부입니다. 이 모듈의 user_data_replace_on_change 설정은 시작 구성 변경을 명시적인 인스턴스 교체로 만듭니다. 기존 로컬 기록은 이전 인스턴스의 파일 시스템에 속하며, S3 보고서는 별도로 제공된 스토리지에 속합니다.

호출의 메시지를 바꾸고 계획을 저장합니다.

sed -i 's/Application release one/Application release two/' application.tf
terraform fmt
terraform validate
terraform plan -out=release.tfplan
terraform show release.tfplan

인스턴스의 -/+ 교체와 변경된 User Data를 검토하세요. 계획은 제공된 네트워크, 역할, 프로파일, 이미지, 버킷, 참조 애플리케이션을 삭제해서는 안 됩니다. release.tfplan은 다음 명령에서 사용할 검토된 계획을 저장합니다.

해당 저장된 계획을 적용합니다.

terraform apply release.tfplan

저장된 계획을 적용할 때는 다시 yes를 묻지 않습니다. 명령은 저장된 작업을 적용합니다. 완료를 기다린 뒤 실제 두 인스턴스 식별 정보를 비교하세요.

NEW_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
echo "$NEW_ID"
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId}'

ID는 서로 다릅니다. 원래 인스턴스는 terminated이고 새 인스턴스는 같은 준비된 AMI에서 running입니다. 행 순서에 의존하지 말고 ID를 대조하세요.

AWS View에서 실행 중인 application-server 항목을 선택하고 Health 요청을 보냅니다. Connected · 200과 Application release two가 표시되어야 합니다. 종료된 이전 인스턴스는 더 이상 실행 중인 대상으로 선택할 수 없습니다.

Local report file 요청을 보냅니다. 이제 내용은 새 인스턴스의 User Data로 생성된 local,initialized입니다. 교체 과정에서 이전 인스턴스의 로컬 기록은 보존되지 않았습니다. 그런 다음 Private report 요청을 보냅니다. 외부 S3 보고서는 여전히 Connected · 200과 period,total / Q1,320을 반환합니다. Unrelated private object 요청을 보내 Connected · 403과 Access denied가 표시되는지 확인합니다.

마지막으로 reference-server, User, 포트 8081, Health를 선택하여 요청을 보냅니다. 여전히 Connected · 200과 Reference application을 반환해야 합니다.

terraform plan

No changes.가 표시되어야 합니다. 새 인스턴스는 모듈이 관리하며 외부 데이터와 참조 환경은 온전히 유지됩니다.

모듈 워크로드 삭제 및 의존 리소스 보존하기

이 단계에서는 제공된 인프라, 워크로드 역할, 외부 보고서 데이터를 보존하면서 관리 중인 교체 인스턴스를 삭제합니다.

루트의 관리 대상 리소스를 삭제하기 전에 이미지 ID를 기록합니다.

IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
terraform plan -destroy

삭제할 관리 대상 인스턴스가 하나여야 합니다. AMI 데이터 소스는 기존 이미지를 읽습니다. 네트워크, 프로파일, 역할, 버킷은 제공된 입력값으로 모듈에 전달되었습니다. 삭제를 적용하고 yes를 입력합니다.

terraform destroy

교체 인스턴스가 실제로 종료되었는지 조회하고 남은 상태를 확인합니다.

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

terminated가 표시되고 상태에 관리 중인 인스턴스가 남아 있지 않아야 합니다. 제공된 이미지와 프로파일은 계속 존재해야 합니다.

aws ec2 describe-images --image-ids "$IMAGE_ID" --query 'Images[].{ID:ImageId,Name:Name}'
aws iam \
  get-instance-profile \
  --instance-profile-name supplied-application-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Terminal 운영자로 보존된 S3 보고서를 읽습니다. 이는 외부 데이터 보존을 확인합니다. 워크로드 자체의 제한된 접근은 삭제 전에 검증했습니다.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/g5-retained-report.csv
cat /tmp/g5-retained-report.csv

바이트는 period,total / Q1,320으로 유지됩니다. AWS View에서 reference-server, User, 포트 8081, Health를 선택하여 요청을 보냅니다. Connected · 200과 Reference application이 표시되어야 합니다.

검토할 수 있도록 루트와 모듈 파일을 유지하세요. 남아 있는 HCL은 이후 일반 계획에서 새 인스턴스를 제안합니다. 정리 완료의 기준은 관리 대상 워크로드의 실제 삭제이며 향후 계획이 비어 있는 것이 아닙니다.

요약

제공된 모듈의 입력과 출력값을 사용하여 기존 워크로드를 업데이트하고 교체 인스턴스를 배포했습니다. 리소스와 데이터에 미치는 영향을 검토하고, 저장된 계획을 적용하고, 인스턴스 로컬 파일과 보존된 외부 보고서를 구분한 뒤, 모듈이 소유한 워크로드만 정리했습니다.