업데이트 중 보고서 기록 보호하기

소개

새 보고서를 게시해도 팀에서 이전 데이터를 읽을 수 있어야 합니다. 버전 관리를 구성하고 보고서 두 개를 게시한 뒤, 이전 버전 읽기와 현재 버전 읽기를 구분하고, 마지막에 이 일회용 저장소를 의도적으로 정리합니다.

앞선 실습에서 배운 변수, 객체 참조, 독립적인 루트에 대한 지식을 활용합니다. 이 새로운 환경에는 도구, 프로바이더 접근 설정, 관련 없는 참조 보고서만 제공됩니다.

관련 자격증 시험 항목

첫 번째 버전 게시하기

이 단계에서는 첫 번째 보고서를 게시하기 전에 Terraform으로 버킷의 버전 관리 구성을 관리합니다.

S3 객체 버전은 보존된 데이터 복사본이며 각각 버전 ID가 있습니다. HCL의 Git 리비전이나 Terraform의 프로바이더 잠금 파일과는 다릅니다. Terraform으로 버전 관리를 구성하면 데이터가 업데이트될 때 S3가 객체 버전을 보존합니다. 변경 없는 계획만으로는 이전 데이터를 읽을 수 있음을 입증할 수 없습니다.

준비된 루트로 이동하여 스토리지 정의를 작성합니다.

cd /home/labex/project/report-history
cat > main.tf <<'EOF'
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-history-reports"
}

resource "aws_s3_bucket_versioning" "reports" {
  bucket = aws_s3_bucket.reports.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
  depends_on   = [aws_s3_bucket_versioning.reports]
}
EOF

이제 버킷, 버전 관리 설정, 객체의 세 리소스가 있습니다. 객체는 ID 참조를 통해 이미 버킷에 의존합니다. 명시적인 depends_on은 해당 참조만으로 추론할 수 없는 순서를 추가합니다. 첫 업로드 전에 버전 관리를 활성화해야 합니다.

첫 번째 보고서 입력값을 작성하고 초기화합니다.

cat > release1.tfvars <<'EOF'
report = "orders,12\n"
EOF
terraform init
terraform validate
terraform plan -var-file=release1.tfvars

세 리소스가 추가되어야 합니다. 적용하고 yes를 입력합니다.

terraform apply -var-file=release1.tfvars

실제 설정과 첫 번째 버전을 조회합니다.

aws s3api \
  get-bucket-versioning \
  --bucket terraform-history-reports
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

상태는 Enabled입니다. 보고서의 버전 ID는 null이 아니며 Current: true가 표시됩니다. AWS View에는 현재 읽을 수 있는 객체가 표시됩니다. 기록을 확인하려면 버전 조회를 사용하세요.

보고서 업데이트 및 기록 읽기

이 단계에서는 다른 바이트를 게시하고 이전 버전을 명시적으로 읽은 뒤, 기록을 읽어도 현재 보고서가 변경되지 않음을 확인합니다.

두 번째 입력 파일을 생성합니다. 두 파일을 유지하면 의도한 데이터 버전을 쉽게 비교할 수 있지만, 파일 자체가 저장된 기록은 아닙니다.

cat > release2.tfvars <<'EOF'
report = "orders,25\n"
EOF
terraform plan -var-file=release2.tfvars -out=update.tfplan
terraform show update.tfplan

버킷 교체 없이 객체 업데이트 하나가 제안되어야 합니다. -out은 선택한 입력값이 포함된 계획 아티팩트를 저장합니다. 검토한 아티팩트를 적용하세요. 저장된 계획을 이미 선택했으므로 이 명령은 확인을 요청하지 않습니다.

terraform apply update.tfplan

실제 버전을 다시 나열합니다.

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

이전 항목과 현재 항목의 버전 ID는 서로 다릅니다. 이전 보고서의 ID를 선택하여 표시합니다. 쿼리는 보고서 키와 IsLatest == false를 기준으로 필터링합니다. [0]은 이 실습의 두 버전 기록에서 첫 번째로 일치하는 이전 항목을 선택합니다.

OLD_VERSION=$(aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[?Key==`reports/current.csv` && IsLatest==`false`].VersionId | [0]' \
  --output text)
echo "$OLD_VERSION"
CURRENT_VERSION=$(aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text)
echo "$CURRENT_VERSION"

ID를 지정하여 이전 버전을 다운로드한 다음, 버전 ID를 지정하지 않고 현재 버전을 다운로드합니다.

aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --version-id "$OLD_VERSION" \
  old-report.csv
cat old-report.csv
aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  current-report.csv
cat current-report.csv

이전 파일에는 orders,12, 현재 파일에는 orders,25가 있어야 합니다. 버전을 지정한 GET은 기존 버전을 읽으며 현재 객체 위에 복사하지 않습니다. 현재 ID를 다시 조회하여 표시된 CURRENT_VERSION과 비교합니다.

aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text

ID는 변경되지 않았습니다. 어떤 버전도 삭제하기 전에 이 단계의 검사를 완료하세요. 검사는 실제 이전 바이트와 현재 바이트를 읽으며 두 버전을 모두 보존합니다. 객체 키, 버전, 삭제 마커의 차이는 S3 버전 관리를 참고하세요.

직접 만든 버전 기록을 의도적으로 삭제하기

이 단계에서는 Terraform 구성 리소스를 삭제하기 전에 자신의 일회용 보고서 버킷에 있는 모든 버전의 목록을 확인하고 삭제합니다.

인프라를 삭제하는 것과 보고서 기록을 폐기하기로 결정하는 것은 서로 다른 작업입니다. 비어 있지 않은 버전 관리 버킷은 보통 삭제할 수 없습니다. 버전 ID 없이 현재 객체를 삭제하면 이전 버전은 남아 있는 채 현재 객체를 숨기는 삭제 마커가 생성될 수 있습니다. 여기서는 이전 단계에서 보존을 확인한 뒤, 목록에서 확인한 버전을 ID로 명시적으로 삭제합니다.

서비스의 버전 목록을 바탕으로 삭제 요청을 생성합니다. 이 실습에는 소수의 보고서 버전만 있고 기존 삭제 마커는 없습니다. 나열된 모든 버전은 자신의 버킷에 속합니다. --query는 각 항목을 delete-objects에서 받는 Key/VersionId 필드로 재구성합니다.

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query '{Objects: Versions[].{Key:Key,VersionId:VersionId}}' \
  > owned-versions.json
cat owned-versions.json

파일에 terraform-history-reports의 버전만 포함되어 있는지 검토하세요. 그런 다음 정확히 해당 버전을 삭제합니다. file://는 AWS CLI에 로컬 파일에서 JSON 요청을 읽도록 지시합니다.

aws s3api \
  delete-objects \
  --bucket terraform-history-reports \
  --delete file://owned-versions.json
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports

성공한 목록 조회에 Versions나 DeleteMarkers 항목이 없습니다. 이제 이 루트의 리소스를 삭제하고 yes를 입력합니다.

terraform destroy -var-file=release2.tfvars

Terraform은 먼저 상태를 새로 조회하며 객체가 이미 삭제되었음을 감지할 수 있습니다. 그런 다음 남은 버전 관리 구성과 빈 버킷을 삭제합니다. 마지막으로 매핑과 보존된 참조 리소스를 확인합니다.

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

상태 목록은 비어 있고 팀 참조 버킷만 남아 있습니다. 기록을 보존해야 하는 저장소에는 이 데이터 폐기 절차를 사용하지 마세요.

요약

구성 변경과 데이터 버전을 구분하고, 업로드 전에 버전 관리를 활성화하고, 현재 버전을 덮어쓰지 않은 채 서로 다른 이전 및 현재 보고서 바이트를 읽은 뒤, 자신이 만든 버전의 목록을 명시적으로 확인하고 해당 버전만 폐기했습니다.