기술 · 실용 가이드
Terraform “Error acquiring the state lock”? force-unlock 전에 backend와 owner를 증명하세요
활성 writer, 버려진 lock, 잘못된 backend, 권한 실패를 구분하고 lock 기록을 보존한 뒤 최소 복구를 선택합니다.
Terraform state lock은 concurrent writer를 막는 안전 경계다. 같은 오류가 활성 terminal, CI job, 중단된 remote session, wrong backend, permission failure에서 나올 수 있으므로 stale file 증거가 아니다.
먼저 전체 lock record를 보존하고 effective backend, state object, workspace, active owner를 증명한다. 같은 state의 abandoned lock만 force-unlock이나 provider lease break 대상이다.
전체 오류와 잠금 기록 보존
재시도 전에 첫 오류를 저장하고 Lock ID, Path, Operation, Who, Version, Created, Info와 정확한 명령, 디렉터리, workspace, Terraform 버전을 기록한다. credential만 가리고 identity는 남긴다.
권한 거부, 없는 table, 잘못된 key, 빈 metadata와 conditional write 충돌은 서로 다른 실패다. 상태 코드와 resource 이름을 보존한다.
실제 backend와 state 객체 증명
실제 작업 디렉터리에서 초기화된 backend의 type, account/project, bucket/container, key/prefix, workspace를 확인한다. 다른 checkout의 명령이 같은 state를 가리킨다고 가정하지 않는다.
S3에서는 .tflock과 deprecated DynamoDB lock을 구분하고 권한을 확인한다. GCS는 bucket/prefix, Azure는 정확한 blob과 lease를 식별한다.
활성 소유자 확인
local terminal과 process, CI job, retry, remote run, deployment concurrency를 검사하고 operation, user, time, workspace, state path를 lock record와 대조한다.
writer가 살아 있으면 기다리거나 정상 중지하여 Terraform이 release하게 한다. -lock=false로 우회하지 않는다.
stale lock과 권한·설정 오류 분리
stale lock은 owner 작업은 끝났지만 자동 release만 실패한 경우다. wrong backend, local fallback, DeleteObject 거부, missing table, broken metadata는 다른 고장이다.
backend 증거를 보존한 뒤 재초기화하고 secret을 노출하지 않으며 lock object에 필요한 최소 권한만 수정한다.
backend별 최소 복구
검증한 configuration에서 자신의 abandoned lock에만 정확한 LOCK_ID로 terraform force-unlock을 쓴다. infrastructure를 바꾸지는 않지만 잘못된 unlock은 다른 writer를 허용한다.
Azure Break lease도 동일한 owner proof 뒤에만 한다. broken lease는 갱신할 수 없고 break period가 있을 수 있다. state 파일은 삭제하지 않는다.
state 신원 검증과 재발 방지
정상 locking으로 read-only plan을 한 번 실행하고 같은 backend, workspace, state serial/version, resource를 확인한다. versioning과 recovery control도 확인한다.
state 객체별 CI writer를 직렬화하고 대체된 job을 안전하게 취소한다. 같은 state가 한 lock owner만 받아들이는 것이 종료 조건이다.
