스토리지 변경 검토 및 적용하기

소개

팀에서는 스토리지를 다시 생성하거나 보고서를 변경하지 않고 기존 보고서 저장소를 릴리스 2로 표시해야 합니다. 저장된 계획을 검토하고 적용한 다음, 의도적으로 만든 태그 드리프트를 감지하고 수정합니다.

이 독립적인 환경에는 시작점이 되는 작은 저장소와 로컬 상태가 준비되어 있습니다. 계획 및 적용, 변수 파일, S3 조회 지식을 활용하세요. 원격 상태와 자동 승인은 필요하지 않습니다.

관련 자격증 시험 항목

저장된 계획 검토 및 적용하기

이 단계에서는 기존 버킷과 보고서를 보존하면서 저장된 계획으로 준비된 보고서 저장소의 릴리스 태그를 업데이트합니다.

이 새로운 루트는 앞선 실습에서 생성 방법을 배운 작은 저장소를 이미 관리합니다. 변경 검토에 집중할 수 있도록 초기 환경이 제공됩니다. 원하는 새 릴리스는 2이며 기존 보고서는 orders,12로 유지되어야 합니다. 먼저 구성, 값, 현재 태그를 읽어 보세요.

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

입력 파일은 현재 릴리스 1을 선택합니다. 리소스 이름 변경은 스토리지 교체를 유발할 수 있지만, 태그 변경은 기존 버킷을 업데이트할 수 있습니다. 릴리스 입력값만 변경하세요.

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

버킷의 제자리 업데이트인 0 to add, 1 to change, 0 to destroy가 제안되어야 합니다. -out은 이 구성과 입력값을 포함한 Terraform 자체 계획 아티팩트를 씁니다. 저장하지 않은 미리보기와 달리, 이 파일을 적용하면 이후 편집 내용으로 새 계획을 생성하지 않고 검토한 계획을 사용합니다. 실제 프로젝트의 계획에는 민감한 값이 포함될 수 있으므로 프로젝트 아티팩트로 취급하세요.

적용 전에 저장된 계획을 읽습니다.

terraform show change.tfplan

Release가 1에서 2로 바뀌고 객체나 버킷이 교체되지 않는지 확인하세요. 그런 다음 아티팩트를 적용합니다. 저장된 계획에는 추가 yes 프롬프트가 나타나지 않습니다.

terraform apply change.tfplan

현재 태그를 조회하고 보고서를 읽습니다.

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
aws s3api \
  get-object \
  --bucket terraform-change-reports \
  --key reports/current.csv \
  retained.csv
cat retained.csv

릴리스 2와 orders,12가 표시되어야 합니다. 저장된 계획은 적용된 리소스와 보존된 데이터가 검토한 변경과 일치할 때에만 의미가 있습니다.

태그 드리프트 감지 및 수정하기

이 단계에서는 Terraform 외부에서 이루어진 실제 태그 변경을 관찰하고 보고서를 변경하지 않은 채 선언된 구성으로 복구합니다.

드리프트는 배포된 리소스와 원하는 구성 사이의 차이입니다. AWS CLI로 Terraform 외부에서 태그를 변경하세요. 이 의도적인 연습은 프로바이더가 읽을 수 있는 실제 리소스 속성을 변경하며 로컬 성공 표시 파일을 편집하지 않습니다.

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Terraform에 현재 리소스와 원하는 릴리스를 비교하도록 요청합니다. -detailed-exitcode는 0(변경 없음), 2(제안된 변경 있음), 1(오류)을 구분합니다. 다음 계획은 의도적으로 2를 반환합니다. 이는 태그 차이를 발견했다는 뜻이며 배포가 실패했다는 뜻이 아닙니다.

terraform plan -var-file=release.tfvars -detailed-exitcode

계획은 unexpected를 2로 되돌리자고 제안합니다. 수정 계획을 검토하고 저장한 다음 해당 아티팩트를 적용합니다.

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

현재 태그와 수렴한 계획을 확인합니다.

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

태그는 2이며 최종 계획은 No changes를 표시하고 0으로 종료됩니다. 보고서는 변경되지 않습니다. 이는 조회 가능한 태그 드리프트를 보여 주며 Terraform 외부에서 발생할 수 있는 모든 데이터 변경을 감지한다는 뜻은 아닙니다. 저장된 계획과 상세 종료 코드는 Terraform plan을 참고하세요.

변경한 저장소 정리하기

이 단계에서는 변경 및 드리프트 검사를 통과한 뒤 이 루트가 관리하는 저장소만 삭제합니다.

삭제 계획을 검토하고 실행하며, destroy에서 yes를 입력합니다.

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

보고서 객체는 버킷보다 먼저 삭제됩니다. 남은 리소스와 빈 매핑을 조회합니다.

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

팀 참조 보고서는 남아 있습니다. 저장된 로컬 계획은 검토용 아티팩트입니다. 계획 파일이 남아 있다고 삭제된 AWS 리소스가 여전히 존재하는 것은 아닙니다.

요약

검토한 Terraform 자체 계획 아티팩트를 적용하고, 제자리 업데이트와 교체를 구분하고, 프로바이더 조회로 실제 태그 드리프트를 관찰한 뒤, 원하는 구성으로 복구하고 정리 단계까지 보고서 데이터를 보존했습니다.