리소스를 다시 생성하지 않고 이름 변경하기

소개

구성의 이름을 더 명확하게 바꾸기 위해 사용 중인 스토리지를 다시 생성할 필요는 없어야 합니다. 관리 중인 보고서 버킷의 Terraform 주소 이름을 변경하고, 안전하지 않은 직접 이름 변경과 명시적으로 선언한 이동의 차이를 검토하며, 원래 데이터를 보존합니다.

이전 안내형 실습이나 그에 준하는 연습을 통해 Terraform 가져오기, 상태, 계획을 다뤄 본 경험이 필요합니다. 이 새로운 환경에는 관리 중인 보고서와 독립적인 재무 참조 보고서가 별도로 준비되어 있습니다. Terraform 작업에는 Terminal을, 기존 보고서 확인에는 AWS View를 사용하세요. 개인 AWS 계정은 필요하지 않습니다.

관련 자격증 시험 항목

실습 개요

논리적 주소와 원격 리소스 식별 정보 비교하기

이 단계에서는 리소스의 이름을 변경하기 전에 정상적으로 작동하는 Terraform 루트를 살펴봅니다. 이 실습을 위해 루트와 버전이 관리되는 두 보고서가 독립적으로 준비되어 있습니다. 보고서 버킷은 이 루트에서 관리하며, 재무 스토리지는 이 루트의 관리 범위 밖에 있습니다.

cd /home/labex/project/report-refactor
terraform state list

원래 주소는 aws_s3_bucket.reports입니다. 원격 리소스 ID를 읽습니다.

terraform state show aws_s3_bucket.reports

id = "rename-daily-reports"는 기존 AWS 버킷을 식별합니다. Terraform 블록의 이름을 변경하면 논리적 주소가 바뀌며, 이 버킷 이름이 바뀌는 것은 아닙니다.

제공된 구성을 읽고 변경 사항이 없는 기준 상태를 확인합니다.

cat main.tf
terraform plan

No changes가 표시되어야 합니다. AWS View에서 rename-daily-reports의 보고서를 펼치고, rename-finance-reference는 변경하지 마세요. Terminal에서 동일한 보고서 내용을 바이트 단위로 읽습니다.

aws s3 \
  cp s3://rename-daily-reports/report.txt -

Daily sales: 120 orders가 표시되어야 합니다. 목표는 이 스토리지의 식별 정보와 원래 객체 버전을 보존하면서 스토리지를 관리하는 주소를 바꾸는 것입니다.

moved 블록으로 이름 변경 선언하기

이 단계에서는 주소 이름을 직접 변경하면 왜 파괴적인 계획으로 보이는지 살펴본 뒤, 새 주소가 동일한 리소스를 가리킨다는 사실을 Terraform에 알려 줍니다.

here-document는 HCL 표시 사이의 구성을 main.tf에 쓰며, >는 해당 파일을 덮어씁니다. 원격 버킷 이름과 속성은 그대로 유지하고 로컬 블록 레이블만 report_archive로 변경하세요.

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "report_archive" {
  bucket        = "rename-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting" }
}
HCL

적용하기 전에 결과를 확인합니다.

terraform plan

주소 사이의 관계가 없으면 Terraform은 이전 주소가 사라졌으며 새 주소에는 상태가 없다고 판단합니다. 1 to add, 0 to change, 1 to destroy가 표시되어야 합니다. 이 계획을 적용하거나 삭제가 가능하도록 보고서를 지우지 마세요.

moved 블록은 이전 주소와 새 주소의 관계를 선언합니다. AWS 버킷 이름 변경과 달리, 이는 구성 리팩터링을 기록합니다. 선언을 별도의 .tf 파일에 작성하세요. Terraform은 이 루트의 모든 .tf 파일을 함께 읽습니다.

cat > moved.tf <<'HCL'
moved {
  from = aws_s3_bucket.reports
  to   = aws_s3_bucket.report_archive
}
HCL

수정된 계획을 저장하고 확인합니다.

terraform plan -out=rename.tfplan

aws_s3_bucket.reports has moved to aws_s3_bucket.report_archive와 0 to add, 0 to change, 0 to destroy가 표시되어야 합니다. 계획상 상태 주소는 바뀌지만 AWS 리소스를 다시 생성할 필요는 없습니다. 이전 상태 복사본에서도 리팩터링을 이해할 수 있도록 선언을 구성과 함께 유지하세요.

주소 마이그레이션 적용 및 보고서 보존하기

이 단계에서는 저장된 안전한 계획을 적용하고 논리적 주소만 바뀌었는지 확인합니다. 저장된 계획은 추가 승인 프롬프트 없이 실행되므로 먼저 요약에서 생성과 삭제가 모두 0인지 확인하세요.

terraform apply rename.tfplan

리소스 요약에는 0 added, 0 changed, 0 destroyed가 표시되어야 합니다. 결과 매핑을 확인합니다.

terraform state list
terraform state show aws_s3_bucket.report_archive

새 주소만 목록에 표시되며 버킷 ID는 rename-daily-reports로 유지됩니다. 실제 보고서를 확인합니다.

aws s3 \
  cp s3://rename-daily-reports/report.txt -

원래 내용인 Daily sales: 120 orders가 그대로 남아 있습니다. AWS View에는 여전히 동일한 보고서 버킷과 재무 버킷이 표시됩니다. 논리적 이름 변경으로 새 리소스 카드가 나타나지는 않습니다.

terraform plan

No changes가 표시되어야 합니다. 독립적인 검사는 원래 VersionId와 인접 스토리지도 비교하고, 일회용 복사본에서 현재 구성의 계획을 실행합니다. 다음 유지관리 담당자를 위해 사용 중인 두 보고서를 모두 온전히 보존하세요.

모듈이 발전하는 과정에서 유지된 moved 선언이 어떤 역할을 하는지는 HashiCorp의 리소스 리팩터링 문서를 참고하세요.

요약

Terraform 주소와 AWS 리소스 ID를 구분하고, 직접 이름을 변경했을 때 나타나는 파괴적인 계획을 적용하지 않았으며, 버킷이나 보고서를 다시 생성하지 않고 moved 선언을 적용했습니다.