day-log

Terraform state 정리, 아직도 terraform state mv 로컬에서 치고 있는지? 우리 팀도 얼마 전까지는 그랬다. 리소스 하나 옮길 때마다 누군가 로컬에서 state 조작을 하고, PR에는 코드만 올라가고, "state는 내가 미리 옮겨놨어요" 슬랙 메시지가 흘러가고. 그러다 한 명이 실수하면 다음 사람이 apply 돌릴 때 리소스가 destroy/create 로 뜬다. 새벽에.이 문제를 해결하려고 나온 게 declarative state 관리 블록 세 개다. moved (1.1+), import (1.5+), removed (1.7+). 이름만 들으면 뻔한데, 실제로 팀 컨벤션으로 못박아 놓으면 state 관련 사고가 눈에 띄게 줄어든다. 최근 Terraform 1.11 대까지 오면..

Terraform을 몇 년 굴려본 팀이면 한 번쯤은 겪는 상황이 있다. state 파일 하나에 리소스가 500개, 800개 넘게 쌓이면 plan 한 번 돌리는 데 몇 분씩 걸리고, 누구 하나가 apply 걸어놓으면 다른 사람은 하염없이 기다려야 한다. 그러다 어느 날 실수로 리소스 하나 잘못 지우면 blast radius가 너무 커서 롤백도 쉽지 않다.우리 팀도 초기에는 그냥 terraform/ 폴더 하나에 다 몰아넣고 시작했다. 편하긴 한데, 팀 규모가 커지고 환경이 dev/stage/prod로 늘어나면서 이 구조가 점점 부담스러워졌다. 이 글은 state 파일을 어떻게 쪼개고, 원격 백엔드는 어떻게 설정하고, drift는 어떻게 감지하는지 실무 관점에서 정리한 가이드다.최근에 OpenTofu 1.10..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. Terraform 1.10부터 S3 backend에 native state locking이 들어왔다. 그동안 DynamoDB 테이블 하나 따로 만들어서 lock 걸던 그거, 이제 안 해도 된다.우리 팀도 스테이지/프로덕션 합쳐서 DynamoDB lock 테이블 5개를 굴리고 있었는데, 최근에 신규 모듈 정리하면서 이걸 다 걷어냈다. 후기 짧게 남긴다.뭐가 달라졌나기존에는 backend "s3" 블록에 dynamodb_table을 반드시 지정해야 동시성 제어가 됐다. 1.10부터는 use_lockfile = true 한 줄이면 끝. S3 객체 자체에 conditional write로 lock 파일을 만들어 거는 방식이다.terraform { backend..