day-log

Composition Function을 쓰기 시작하면 한 번쯤은 이런 상황을 겪는다. XR을 만들었는데 리소스가 안 만들어지고, kubectl describe를 봐도 "function pipeline failed"만 나오고, 정확히 어느 단계의 어느 함수가 뭘 받아서 뭘 뱉었는지는 깜깜하다. 사실상 추측 디버깅이었다.v2.2에서 alpha로 들어왔던 Pipeline Inspector가 v2.3에서 beta로 승격됐다. OpenTelemetry 통합도 같이 들어와서 이제는 함수 파이프라인을 진짜로 들여다볼 수 있게 됐다. 우리 팀이 지난 2주간 도입하면서 정리한 내용을 공유한다.Pipeline Inspector가 정확히 뭘 보여주나이름이 좀 추상적인데, 실제로는 gRPC interceptor다. Cross..

이거 모르는 분 꽤 많더라. 우리 팀 모듈 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까지 같이 터진다.그래서 이렇게..

state 파일은 IaC를 운영하는 사람한테 늘 골치 아픈 물건이다. RDS 마스터 패스워드, IAM access key, 가끔은 슬랙 토큰까지, 다 평문으로 박혀있다. S3에 SSE 걸어두면 됐다고 생각했었는데, 작년에 인턴이 실수로 state 파일을 깃에 푸시한 일이 있고 나서 그 마음이 좀 달라졌다. S3 암호화는 결국 S3 안에서만 의미가 있다. 다운로드 받는 순간 끝이다.OpenTofu 1.7에서 state encryption이 GA로 풀린 게 2024년 5월이다. 우리 팀은 그때는 "재밌네" 정도로만 보고 넘겼는데, 1.10 즈음에서 진지하게 검토를 시작했고 결국 올해 초에 도입했다. 그러다 1.11.4의 보안 픽스 노트를 보고 한 번 더 들여다보게 됐다. 이번 글은 도입 과정에서 내가 결국 ..

작년 이맘때 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..

OpenTofu 1.0이 나온 게 2024년 초였다. 당시 팀에서 "일단 지켜보자"고 결정한 뒤로 약 2년이 지났고, 그 사이에 우리 팀은 한쪽 서비스 군을 OpenTofu로 옮겨봤다. 나머지는 여전히 Terraform이다. 의도한 건 아니고 어쩌다 보니 그렇게 됐는데, 결과적으로는 같은 조직 안에서 둘을 병행 운영하는 꽤 좋은 비교 실험이 됐다.요즘 들어 "이제 OpenTofu로 갈아타야 하는 거 아니냐"는 질문을 사내외에서 자주 받는다. 특히 작년 12월에 IBM이 HashiCorp 인수 마무리하면서 분위기가 또 한 번 바뀌었다. 이 글은 그 질문에 대한 내 나름의 답이다. 결론부터 말하면 "상황에 따라 다르다"는 재미없는 답이 맞는데, 적어도 어떤 상황에서 뭘 고려해야 하는지는 좀 정리가 됐다.2년..

오늘 알게 된 건데, 이거 모르는 분 꽤 많더라. 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..