day-log

라이선스 이슈로 시끄러웠던 게 벌써 2년 전이다. 그때는 "일단 지켜보자"로 넘어간 팀이 많았는데, 요즘 다시 이 얘기가 올라온다. 나도 최근에 팀 내부에서 마이그레이션 검토를 했고, 결과적으로는 OpenTofu 쪽으로 기울었다. 이유를 정리해본다.지금 어디까지 왔나Terraform은 1.15 라인이 stable, 1.16이 alpha다. OpenTofu는 1.12.2가 stable. 버전 넘버만 보면 Terraform이 앞서가는 것 같지만 실제 CLI 오픈소스 기능은 그 반대다.HashiCorp가 BSL로 넘어간 뒤 IBM에 인수됐고, 오픈소스 CLI에는 신규 기능이 거의 안 들어간다. 대신 HCP Terraform(관리형)과 AI 어시스트 쪽으로 투자가 몰려 있다. 반면 OpenTofu는 Linux ..

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 대까지 오면..

지난주 금요일 저녁, 슬랙에서 얼굴이 화끈거리는 알림이 하나 왔다. "누가 지금 prod 계정에 terraform apply 돌리고 있어요?" 확인해 보니 아무도 돌리고 있지 않았다. 근데 state lock은 걸려 있었다. terraform-state-lock DynamoDB 테이블에 유령 락 하나가 남아 있었던 거다. 이런 걸 마주칠 때마다 매번 force-unlock으로 때웠는데, 이번엔 좀 다르게 해결해보고 싶었다. 마침 팀 내부에서 "DynamoDB 이거 언제까지 붙이고 있을 거냐"는 얘기가 몇 주째 돌고 있었고, Terraform 1.11에서 S3 네이티브 락킹이 GA로 승격된 지도 꽤 됐다.그동안 DynamoDB가 왜 있었나우리 팀 backend 설정은 5년 넘게 이 모양이었다.terrafo..

작년 이맘때만 해도 이 얘기를 꺼내면 팀 슬랙 채널이 뜨거워졌다. HashiCorp가 BSL로 라이선스를 바꾼 뒤 OpenTofu 포크가 나왔고, 마침 우리 팀은 Pulumi로 옮겨야 하나 하는 논의도 있었다. 1년 반 정도가 흘렀고, 세 도구 모두 조금씩 다른 방향으로 자라났다. OpenTofu는 최근 1.9까지 오면서 state 암호화 같은 걸 Terraform보다 먼저 넣었고, Terraform은 HCP 통합을 계속 강화하고 있고, Pulumi는 여전히 "진짜 프로그래밍 언어로 IaC"라는 자리를 지키고 있다.우리 팀은 6개월 동안 세 개를 실제 프로젝트에 나눠 쓰면서 비교해봤다. 결론부터 말하면 하나로 통일하지 못했다. 상황마다 다르더라. 이 글은 그 과정에서 느낀 것들이다.라이선스와 거버넌스, ..

지난 3주 동안 팀 인프라 코드를 Terraform 1.5.7에서 OpenTofu 1.10으로 넘겼다. "5분이면 된다"는 블로그 글들에 낚였다. 실제로는 5분이 아니라 3주였고, 그 중 절반은 예상 못 한 곳에서 시간이 갔다.기록해둔다. 언젠가 같은 삽을 뜨는 사람이 이 글을 보길.왜 굳이 지금 옮겼나솔직히 얼마 전까지는 옮길 이유가 별로 없다고 봤다. HCL 문법도 거의 같고 프로바이더도 호환되고, 우리 팀 규모(모듈 40개, workspace 12개)에서 라이선스 이슈가 당장 발등의 불도 아니었다.바뀐 계기는 두 가지였다.첫째, state encryption. OpenTofu 1.10에는 native state encryption이 들어있는데 Terraform은 아직 없다. 우리는 지금까지 S3 b..

새벽 2시에 알림이 울렸다. 배포 파이프라인이 Error acquiring the state lock을 뱉고 멈춰 있었다. 락 ID를 들고 DynamoDB 콘솔에 들어가 강제로 항목을 지우고, 파이프라인을 재실행. 익숙한 절차였다. 근데 그날따라 이 절차가 어이없게 느껴졌다.우리 팀은 Terraform 1.11 무렵부터 S3 backend + DynamoDB 락을 써 왔다. 몇 년 잘 돌던 조합이다. 그런데 올봄에 팀 내부 논의 끝에 DynamoDB 락 테이블을 정리하기로 했다. 이유는 두 가지였다. 하나는 Terraform과 OpenTofu 양쪽 다 S3 네이티브 락을 밀고 있고 DynamoDB 방식이 사실상 deprecated가 됐다는 것. 다른 하나는 우리 조직에 IaC state가 40개 넘게 흩..

작년 이맘때만 해도 사내에서 "OpenTofu 쓸까요?" 얘기가 나오면 반응은 두 종류였다. "일찍 넘어가는 건 위험하다" 아니면 "어차피 언젠간 넘어갈 텐데". 그 사이에서 결정을 못 하고 시간이 흘렀다.포크된 지 만 3년, BSL 전환 이슈가 터진 지도 그만큼 지났다. 이제는 어느 쪽이든 "지켜본다"라는 답이 힘을 잃었다. Fidelity가 상태 파일 5만 개, 리소스 400만 개를 OpenTofu로 옮겼다는 발표가 올해 초에 나왔고, 우리 팀 슬랙에도 그 링크가 다시 돌았다. 결국 지난달 두 주짜리 스파이크를 잡고 실제로 병행 운영을 해봤다. 그 기록을 정리한다.두 도구가 실제로 얼마나 벌어졌나핵심 CLI 동작만 놓고 보면 plan, apply, import, state mv 같은 워크플로우는 99..

지난주에 몇 년 방치된 AWS 계정 정리를 맡았다. 상태 파일이랑 실물 리소스가 서로 다른 우주에 있는 그런 계정. 늘 하던 대로 콘솔에서 목록 뽑아서 `terraform import`를 한 줄씩 돌리려다가 옆 팀 시니어가 "요즘 그거 안 써도 돼요, `terraform query` 있잖아요" 하길래 처음 알았다. 지난해 11월 GA된 Terraform 1.14 신규 기능인데, 소문만 들었지 실제로 안 써봤었다. 써보고 나서 후회했다. 이거 진작에 알았어야 했다.`.tfquery.hcl`이 하는 일이름 그대로 새로운 파일 타입이다. 확장자가 `.tfquery.hcl`이어야 인식한다. 안에는 `list` 블록이 들어간다. import 블록이 "이 리소스를 상태로 끌어와줘"라면, list 블록은 "일단 계정..

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

Terraform 1.11에서 S3 backend에 use_lockfile = true 옵션이 GA로 들어온 뒤로, 팀에서도 슬슬 DynamoDB lock table을 걷어내자는 얘기가 나왔다. 이유는 단순했다. DynamoDB 테이블 하나 유지하려고 IAM 정책 관리, provisioned capacity 알람, TTL 스크립트까지 붙어 있는 게 웃긴 상황이었다. state 파일 하나 지키자고 별도 서비스를 하나 더 굴리는 셈이니까.그런데 "S3 하나로 lock까지 다 처리한다"는 말이 처음엔 어색했다. S3는 오래도록 eventual consistency로 유명했던 스토리지고, DynamoDB의 conditional write처럼 원자적인 락을 걸 수 있는 프리미티브가 없다고 알고 있었기 때문이다. ..