[Terraform] State

• State(.tfstate) = Terraform이 “코드 ↔ 실제 클라우드” 동기화를 위해 유지하는 싱크 파일.
• 빠른 Plan, 최소 변경, 스택 간 의존(Outputs)까지 모두 State에 의존.
• 팀/CI는 원격 백엔드(S3+KMS, DynamoDB 락) 가 표준. State는 절대 Git에 올리지 말 것.

1) State란?

• 리소스 주소(address), 속성 스냅샷, 모듈 경로, 출력(outputs) 등을 저장하는 파일.
• 민감값이 포함될 수 있으므로 백엔드 암호화/권한이 매우 중요.

동작 흐름(이미지)

flowchart LR
  A[코드(HCL)] -- plan --> B{현재 State 로드}
  B -- 리프레시 --> C[실제 클라우드와 비교]
  C -- diff --> D[Plan 생성]
  D -- apply --> E[실제 변경]
  E -- 결과 반영 --> F[State 쓰기(.tfstate/원격)]

• 리프레시 : 지금 클라우드의 진짜 값을 API로 다시 읽어오는 과정

2) 왜 중요한가?

• 최소 변경: 무엇이 이미 있는지 알기 때문에 불필요한 recreate 방지
• 성능: 방대한 API 전체 스캔 대신 State로 빠르게 계획
• 연결: 다른 스택이 outputs를 통해 의존(terraform_remote_state)

3) 드리프트와 리프레시

• 드리프트: 콘솔 수작업 등으로 실제와 코드/State가 어긋난 상태
• 해결/확인
  • terraform plan : 기본 리프레시 후 차이를 보여줌
  • terraform apply -refresh-only : 실물 값을 State에만 반영(구성 변경 없음)
  • 코드로 의도 상태를 정의하고 일반 apply로 수습

4) 대표 명령

terraform state list                          # 상태에 기록된 주소 나열
terraform state show aws_instance.web         # 특정 리소스 상태 보기
terraform state mv old.addr new.addr          # 주소 변경(신중! 일반적으론 moved 권장)
terraform state rm addr                       # 상태에서만 제거(실물은 남음)
terraform plan -replace=aws_instance.web      # 해당 리소스 재생성 강제
terraform apply -refresh-only                 # 리프레시만 반영

리팩터링(이름/키 변경)은 가급적 moved 블록을 코드에 남겨 수행.

5) 스택 간 참조(원격 상태 읽기)

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "my-tfstate-bucket"
    key    = "project/prod/network.tfstate"
    region = "ap-northeast-2"
  }
}

output "public_subnet_ids" {
  value = data.terraform_remote_state.network.outputs.public_subnet_ids
}

6) 베스트 프랙티스

• 원격 백엔드 사용(S3+KMS, DynamoDB 락). 로컬은 개인 실습 정도로만
• State/백업을 Git에 커밋 금지 (.tfstate, .tfstate.backup, .terraform/)
• 환경/스택별 State 분리(예: project/env/stack.tfstate)
• 민감값 저장 가능 → 암호화/권한 최소화 필수
• 항상 plan -out → apply plan.bin 패턴으로 리뷰/적용

7) 트러블슈팅

• 충돌/동시 실행: 원격 락(DynamoDB) 설정 확인
• “항상 바뀐다”: 외부 비결정 값(시간, 랜덤 keepers)이 State를 흔들지 않는지 점검
• 주소 리팩터링: moved { from = ... to = ... }로 파괴 없이 이전