소개
Terraform 외부에서 생성되어 사용 중인 보고서 버킷을 인수하게 되었습니다. 버킷을 다시 생성하거나 보고서를 다시 쓰지 않고 Terraform 관리 대상으로 편입하세요. 그런 다음 재무 팀의 인접 스토리지를 변경하지 않은 채 작은 구성 조정 사항을 검토하고 적용합니다.
Terraform 구성, 리소스 주소, init, plan, apply, 로컬 상태와 기본적인 S3 객체 작업을 이미 이해하고 있어야 합니다. 이 새로운 환경에는 Terraform, AWS 프로바이더, 접근 설정, 서로 독립적인 두 보고서 버킷이 준비되어 있습니다. 개인 AWS 계정이나 이전 실습의 리소스는 필요하지 않습니다.
관련 자격증 시험 항목
| 자격증 | 시험 과제 | 실습 내용 |
|---|---|---|
| CloudOps Engineer – Associate (SOA-C03) | Task 3.1, Skill 3.1.6 | 기존 스토리지를 관리 대상으로 편입하고 리소스를 파괴하지 않는 변경을 검토 및 적용하는 Terraform 기초 실습입니다. |
실습 개요
기존 스토리지와 원하는 구성 살펴보기
이 단계에서는 AWS에 이미 존재하는 리소스를 앞으로 관리할 구성과 비교합니다. Terminal 위의 AWS View에는 CLI가 읽는 것과 동일한 S3 리소스가 표시됩니다. handover-daily-reports 카드에서 report.txt를 펼쳐 보고서 데이터를 확인하세요. finance-reference-reports는 다른 팀의 소유이므로 변경하지 않아야 합니다.
aws_s3_bucket.reports와 같은 Terraform 리소스 주소는 구성 블록을 식별합니다. 버킷 이름은 원격 AWS 리소스를 식별합니다. 상태는 이 두 식별자 사이의 매핑을 기록합니다. 구성 파일만으로는 이 매핑이 설정되지 않습니다.
준비된 루트 디렉터리로 이동하여 원하는 버킷 구성을 읽어 보세요.
cd /home/labex/project/report-storage
cat main.tf
bucket 인수는 handover-daily-reports를 선택합니다. Owner는 reporting으로 유지해야 하며, 새 ManagedBy 태그는 인수 사실을 기록합니다. force_destroy = false는 나중에 삭제할 때 Terraform이 비어 있지 않은 버킷의 내용을 자동으로 지우지 못하게 합니다. 이는 Terraform의 동작 설정으로, 버킷에 저장된 보고서와는 별개입니다.
기존 태그를 확인합니다.
aws s3api \
get-bucket-tagging \
--bucket handover-daily-reports
처음에는 Owner=reporting만 존재합니다. 대상에 -를 사용하여 원래 보고서를 표준 출력으로 가져옵니다.
aws s3 \
cp s3://handover-daily-reports/report.txt -
예상 보고서 내용:
Daily sales: 120 orders
작업 디렉터리를 초기화합니다. init은 이 루트에 고정된 버전의 프로바이더를 설치하며, 버킷을 가져오거나 생성하지 않습니다.
terraform init
제안된 작업을 적용하지 않고 확인합니다.
terraform plan
이 루트에는 아직 관리 중인 리소스 매핑이 없으므로 계획은 1 to add를 제안합니다. 버킷은 이미 존재합니다. 이는 상태에 관리 매핑이 없다는 증거이지 스토리지를 대체해도 된다는 뜻이 아닙니다. 이 생성 계획을 적용하지 마세요. 다음 단계에서 매핑을 명시적으로 설정합니다.
계속하기 전에 보고서 버킷을 식별하고, 보고서를 읽고, 재무 스토리지와 구별할 수 있는지 직접 확인하세요. 이 확인 단계의 백그라운드 검사는 제공된 초기 리소스의 보존 여부를 검사하며, 표시된 계획을 이해했는지는 검사하지 않습니다.
기존 버킷 가져오기 및 차이 검토하기
이 단계에서는 기존 버킷을 의도한 Terraform 주소에 매핑합니다. CLI import는 원격 리소스를 읽고 상태에 식별 정보를 기록합니다. 원하는 구성을 생성하거나 버킷 안의 모든 객체를 가져오는 것은 아닙니다.
구성 주소를 먼저, 기존 버킷 이름을 두 번째로 지정하여 가져오기를 실행합니다.
terraform import aws_s3_bucket.reports handover-daily-reports
Import successful!가 표시되는지 확인하세요. 이제 어느 주소가 관리되고 있는지 확인합니다.
terraform state list
예상 주소:
aws_s3_bucket.reports
해당 주소의 속성을 읽습니다.
terraform state show aws_s3_bucket.reports
id와 bucket 모두 handover-daily-reports를 가리켜야 합니다. report.txt는 S3에 그대로 저장되어 있습니다. 버킷을 가져온다고 해서 객체가 별도의 aws_s3_object 주소에서 관리되는 것은 아닙니다. 재무 버킷이 이 루트의 상태에 나타나서는 안 됩니다.
가져오기를 수행해도 곧바로 변경 없는 계획이 나온다는 보장은 없습니다. 일부 설정은 원격 서비스에서 가져오지만, force_destroy를 비롯한 다른 설정은 Terraform 자체의 동작을 정의하며 가져온 뒤 구성에 맞추어 조정해야 할 수 있습니다. 이런 차이가 보고서 손상을 뜻하지는 않습니다.
검토할 계획을 저장합니다. -out=handover.tfplan은 계획된 작업을 저장하므로 다음 단계에서 검토한 것과 동일한 계획을 적용할 수 있습니다.
terraform plan -out=handover.tfplan
저장한 계획을 읽습니다.
terraform show handover.tfplan
제자리 업데이트(~), ManagedBy=Terraform 태그 추가가 표시되어야 하며, force_destroy를 false로 맞추는 변경도 표시될 수 있습니다. 요약은 반드시 다음과 같아야 합니다.
Plan: 0 to add, 1 to change, 0 to destroy.
계획에서 삭제, 교체, 생성, 다른 버킷 이름 또는 재무 스토리지 변경을 제안하면 중단하고 루트 디렉터리, 리소스 주소, 가져오기 ID를 검토하세요. 예상치 못한 계획을 해결하기 위해 기존 보고서를 삭제하지 마세요.
구성 조정 적용 및 보존 확인하기
이 단계에서는 검토한 계획만 적용하고 원래 보고서가 유지되었음을 확인합니다. 저장된 계획을 apply에 전달하면 두 번째 승인 프롬프트 없이 해당 계획이 바로 실행됩니다. 이전 단계의 요약에서 생성과 삭제가 모두 0임을 확인한 뒤에만 실행하세요.
terraform apply handover.tfplan
Resources: 0 added, 1 changed, 0 destroyed.가 표시되어야 합니다. 이제 버킷이 관리 대상이며 인수 태그가 구성과 일치합니다.
현재 태그를 읽어 AWS의 결과를 확인합니다.
aws s3api \
get-bucket-tagging \
--bucket handover-daily-reports
Owner=reporting과 ManagedBy=Terraform이 모두 있어야 합니다. 태그 순서는 중요하지 않습니다.
보고서를 다시 읽습니다.
aws s3 \
cp s3://handover-daily-reports/report.txt -
보고서에는 여전히 Daily sales: 120 orders가 포함되어 있어야 합니다. AWS View에서 두 보고서를 모두 펼쳐 보고서 내용과 재무 참조 보고서에 계속 접근할 수 있는지 확인하세요. 태그를 구성에 맞추는 데 새 버킷을 만들거나 객체를 다시 쓸 필요는 없습니다.
현재 구성, 상태, 새로 조회한 AWS 리소스가 일치하여 수렴했는지 확인합니다.
terraform plan
예상 결과:
No changes. Your infrastructure matches the configuration.
변경 없는 계획만으로는 안전하게 인수되었다는 증거가 충분하지 않습니다. 의도한 리소스 주소와 원래 데이터도 확인했습니다. 백그라운드 검사는 원래 객체 버전과 인접 스토리지를 비교하고, 일회용 복사본에서 현재 구성의 계획을 실행하여 수렴 여부를 확인합니다. 이번 인수에서는 두 버킷을 모두 유지하세요. 보고서는 여전히 사용 중이므로 terraform destroy를 실행하지 마세요. 실제 인수에서는 상태를 민감한 운영 데이터로 보호하고 다음 유지관리 담당자의 접근 권한을 마련하세요. 민감한 값이 포함된 상태나 저장된 계획을 공개 저장소에 커밋하지 마세요.
자세한 내용은 HashiCorp의 CLI 가져오기 워크플로를 참고하세요.
요약
기존 버킷을 Terraform 구성과 비교하고, 의도한 상태 주소로 식별 정보를 가져온 뒤, 리소스를 파괴하지 않는 구성 조정을 검토하고 적용했습니다. 원래 보고서와 재무 스토리지를 보존하면서 변경 없는 계획을 확인했습니다. 가져오기는 관리를 설정하고, 구성 검토는 Terraform이 다음에 무엇을 변경해야 할지 결정합니다.
