day-log

OpenTofu state 암호화, fallback 빼먹으면 일 난다

OpenTofu 1.7에서 state 암호화 기본 기능이 들어온 지도 꽤 됐다. 근데 막상 켜본 분들 중에 method 블록만 설정하고 fallback은 그냥 비워두는 경우가 많더라. 우리 팀도 처음에 그랬다. 결론부터 말하면, fallback 빼면 마이그레이션 순간에 무조건 한 번은 깨진다.무슨 상황에서 깨지나평문 state 파일이 있는 워크스페이스에 처음 암호화를 켤 때가 문제다. OpenTofu는 terraform.encryption 블록에서 지정한 method로 state를 읽으려고 시도하는데, 기존 파일은 평문이라 못 푼다. Error: Failed to decrypt state 한 줄 던지고 끝.키 로테이션도 마찬가지다. PBKDF2 패스프레이즈를 바꿨다? 새 키로 옛날 state는 못 연다...

Terraform 1.10에서 use_lockfile = true 옵션이 추가됐고, 1.11에 와서는 experimental 딱지가 떨어졌다. DynamoDB 테이블 없이 S3만으로 state lock을 거는 기능이다.처음 봤을 때 솔직히 좀 의심스러웠다. lock 메커니즘이라는 게 결국 "동시에 한 명만 쓰게" 만드는 건데, S3는 object storage고 트랜잭션 같은 게 없는데 어떻게? 그리고 DynamoDB는 강한 일관성(strong consistency)을 보장하는 KV store니까 lock 용도로 충분히 합리적이었다. 굳이 S3로 갈아탈 이유가 있나 싶었다.근데 마이그레이션을 준비하면서 내부를 까보니, 생각보다 깔끔하게 잘 만들어둔 구조였다. 단순히 "DynamoDB를 안 써도 된다"는 ..

Terraform 쓰면서 가장 찜찜한 게 뭐였냐고 물으면, 솔직히 나는 terraform.tfstate에 시크릿이 평문으로 박히는 거였다. RDS 마스터 패스워드, API 토큰, OAuth 클라이언트 시크릿. data 블록으로 Secrets Manager에서 가져온 값조차 state에 그대로 기록된다.그동안은 state 백엔드(S3 + KMS)에 의존하거나, write-only 패턴을 억지로 끼워넣거나, 아예 Terraform 밖에서 처리하는 식으로 우회했다. 그런데 작년 말 1.10에서 나온 ephemeral resources가 1년 좀 넘게 실무에서 굴려보니 꽤 쓸 만하다. 최근 6월 기준 AWS, Azure, Vault, Kubernetes, random, 그리고 GCP 프로바이더까지 지원이 거의 ..

이거 모르는 분 꽤 많더라. 우리 팀 모듈 plan에 8분 넘게 걸리던 게 4분으로 줄었다. 코드 한 줄도 안 고쳤다.뭐가 문제였냐면terraform plan 돌리면 기본적으로 state에 있는 모든 리소스를 클라우드 API에 한 번씩 조회한다(refresh). 리소스 200개짜리 모듈이면 200번 API 콜이 도는데, AWS provider 같이 throttling 걸리면 더 느려진다.CI에서 PR마다 plan을 돌리는 입장에서는, 매번 fresh한 state가 필요한 것도 아닌데 이 refresh 때문에 시간을 다 까먹는다. 특히 우리는 monorepo에 모듈 30개 있어서 PR 하나 올리면 plan job 30개가 동시에 돌고, 그러면 AWS API throttling까지 같이 터진다.그래서 이렇게..

작년 이맘때 Terraform 협업 도구를 새로 고르느라 한참 헤맸다. 그동안은 GitHub Actions 위에 얇은 래퍼 스크립트로 plan/apply를 돌렸는데, 모듈이 80개를 넘어가면서부터는 한계가 보였다. PR 코멘트에 plan 결과가 뒤죽박죽 붙고, 누가 언제 apply를 눌렀는지 추적이 안 되고, 가끔 두 사람이 같은 워크스페이스에 동시에 apply를 날려서 state lock 충돌이 나기도 했다.결국 후보를 Atlantis와 Spacelift로 좁혔다. 둘 다 후보로 올린 이유는 단순했다. Atlantis는 공짜고 자체 운영이 익숙했고, Spacelift는 영업 미팅 한 번 했을 때 "이 정도면 우리 페인 포인트는 다 풀리겠다" 싶은 인상을 받았기 때문이다. 1년이 지난 지금 시점에서 솔직..

Terraform ephemeral과 write-only, 1년 굴리고 정리한 진짜 사용 패턴작년 이맘때쯤 Terraform 1.10이 나왔고, 그때부터 ephemeral 블록과 write-only 인자를 본격적으로 우리 코드베이스에 섞기 시작했다. 1.11에서 managed resource에도 write-only argument가 들어오면서 본격적으로 "state에서 시크릿을 빼는" 작업을 했고, 지금은 1.15.3까지 와있다. 1년이 지난 지금 다시 보면, 처음에 우리가 잘못 이해하고 있던 것들이 꽤 있었다. 단순히 "state에 안 남는 변수"가 아니라, 라이프사이클 자체가 다른 객체라는 것을 운영하면서야 체감했다.이 글은 "ephemeral이 뭔지 알려주는" 글이 아니다. 그건 hashicorp ..

Terraform 코드를 팀에서 같이 굴리다 보면 결국 부딪히는 문제가 있다. 누가 어디서 plan을 돌렸는지 모르고, 로컬에서 apply 친 사람이 state를 깨먹고, PR 리뷰는 코드만 보고 끝나는데 정작 실제 변경 영향은 머지된 뒤에야 보인다. 이걸 해결하는 도구가 Atlantis다. PR에 plan 결과를 코멘트로 붙이고, atlantis apply 같은 명령어로 머지 직전에 실행을 위임한다.이 글은 Atlantis를 GitHub과 EKS 위에 셀프호스팅으로 띄우는 가이드다. 우리 팀에서 최근에 v0.42.0으로 올렸는데, OpenTofu 지원이 정식으로 들어가면서 마이그레이션 부담이 좀 줄었다. 그 과정에서 정리한 내용이다.왜 또 Atlantis인가요즘은 Spacelift, Env0, Scal..

지난주에 사내 보안팀에서 state 파일 감사를 돌렸다. 결과 보고서를 받아보니 우리 팀 모듈 몇 개에 RDS master password가 평문으로 박혀 있었다. random_password로 만들어서 aws_db_instance.password에 넘긴 건데, 그 흐름을 타는 모든 값이 state에 그대로 적힌다. KMS로 백엔드 암호화는 해뒀어도, 누가 terraform show만 치면 그냥 보이는 거라 좀 찜찜했다.이거 사실 1.11부터 들어온 write-only argument로 우회할 수 있다. 1.10에서 ephemeral resource가 먼저 들어왔고, 1.11에서 write-only가 따라 들어온 건데, 모르고 계신 분이 의외로 많길래 짧게 정리해본다.동작 방식1.10의 ephemeral..

월말마다 AWS 비용 리포트 보다가 NAT Gateway 항목에서 한숨 쉬어본 적 있다면 이 글이 도움이 될지도 모르겠다. 우리 팀도 작년에 비슷한 상황이었고, VPC Endpoint 몇 개 깔아둔 것만으로 NAT 처리 비용이 한 달 기준 40% 가까이 빠졌다. 거창한 아키텍처 변경 없이.이번 4월 AWS 비용 가이드들을 다시 훑어봤는데 NAT Gateway 단가는 여전히 시간당 $0.045, GB당 $0.045다. 게이트웨이 하나 띄워놓으면 가만히 있어도 월 $32. 거기에 처리량까지 붙으니 트래픽 많은 클러스터는 NAT 항목 하나가 인스턴스 비용을 추월하는 일도 흔하다. 이 글은 그 비용을 내리는 가장 확실한 방법인 VPC Endpoint 적용 가이드다.어디부터 손대야 하나VPC Endpoint는 두..