day-log

Renovate vs Dependabot vs ArgoCD Image Updater — 1년 굴려본 솔직 비교작년 봄에 회사 표준 의존성 업데이트 도구를 정하자는 얘기가 나왔다. 그때 우리 팀에서 굴리던 게 셋이었다. 일부 레포는 Dependabot, 인프라 모듈 레포는 Renovate, 그리고 멀티클러스터 ArgoCD가 관리하는 매니페스트 레포는 ArgoCD Image Updater. 세 개가 동시에 PR을 쏴대니까 리뷰어들이 짜증을 내기 시작했다. "이거 좀 정리하자"가 출발이었다.결과부터 말하면 셋 다 남겼다. 다만 역할을 잘랐다. 어떤 기준으로 잘랐는지, 1년 돌려본 입장에서 솔직하게 적어본다.세 도구가 보는 세계가 다르다처음에 했던 큰 착각이, 이 셋을 같은 카테고리로 묶을 수 있다고 생각한 거..

출발점: 우리 환경ArgoCD 이미 운영 중 (2년 차)Istio 1.24, ambient mode는 일부 네임스페이스만마이크로서비스 약 80개, 일주일 배포 횟수 평균 120건옵저버빌리티는 Prometheus + Thanos + Grafana 조합이 시점에서 Flux CD를 쓰고 있었다면 Flagger를 골랐을 가능성이 높다. 두 도구 모두 기술적으로 충분하지만, 같은 진영의 도구를 모으는 게 운영 단순도 측면에서 유리하다는 게 1년 후 더 분명해졌다.매니페스트 마이그레이션 비용Flagger의 가장 강력한 매력은 "기존 Deployment를 그대로 두고 Canary CR만 추가하면 된다"는 점이다. 처음 PoC 할 때 이게 정말 좋았다. 30분 만에 한 서비스가 카나리 배포로 전환됐다. 반면 Argo ..

GitHub-hosted runner 비용이 슬슬 부담스러워서 self-hosted로 갈아탈 때, 요즘은 거의 ARC(Actions Runner Controller) + Karpenter 조합이 정석처럼 굳어가는 분위기다. 우리 팀도 작년 말부터 이 구성으로 전환했고, 그 과정에서 정리해둔 내용을 가이드로 풀어본다.작년 6월에 ARC 0.12가 나오면서 ephemeral runner 설치가 큐잉되고 실패 시 5번까지 재시도하는 식으로 바뀌었다. 노드 스케일 다운 도중에 러너 파드가 휘말려 죽는 케이스에서 체감이 꽤 좋아졌다. 이 글은 0.12 이상 기준이다.왜 Karpenter랑 묶나처음엔 Cluster Autoscaler로도 충분하지 않을까 했었다. 결론부터 말하면, CI 워크로드 특성상 Karpent..

PR 올라올 때마다 리뷰어한테 "로컬에서 띄워서 봐줘"라고 말하는 게 한두 번이지, 매번 그러기 좀 그렇다. 우리 팀은 PR 하나당 stage 환경에 임시로 배포해서 QA가 직접 클릭해보고 댓글 다는 흐름을 원했는데, 그래서 결국 ArgoCD ApplicationSet의 Pull Request generator를 붙였다.처음엔 "그냥 GitHub Actions로 helm install 돌리면 되는 거 아냐?"라고 생각했는데, 막상 정리되고 나니 GitOps의 일관성이라는 게 꽤 크게 다가왔다. PR 닫으면 알아서 지워주고, 상태도 ArgoCD UI에 그대로 보이고. 이번 글에서는 셋업 과정과 실제로 굴려보면서 부딪힌 몇 가지를 정리한다.PR Generator가 하는 일ApplicationSet은 한 번에..

오늘 알게 된 건 아니고, 어제 팀 PR 리뷰하다가 "어 이거 아직도 모르는 분들 꽤 많은데" 싶어서 짧게 정리해둔다. 우리 팀에서도 작년 한 분기 동안 같은 사고를 두 번 냈다. 똑같은 워크플로가 동시에 두 개 뜨면서 한쪽이 helm release를 절반쯤 적용한 상태에서 다른 한쪽이 덮어쓰는 그림. 새벽 3시에 슬랙 알림으로 깨면 진짜 멘탈이 묘하게 무너진다.한 줄이면 끝난다concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false이게 전부다. 같은 브랜치에서 deploy 워크플로가 한 번에 하나만 돌게 만든다. PR 빌드용 워크플로면 cancel-in-progress: true로 바꿔서 새 커밋이 들어올 때 진행 중인 빌드를 죽..

지난주 화요일 새벽 2시쯤, 슬랙에 멘션이 떴다. "프론트엔드 빌드 파이프라인이 30분 넘게 안 끝나는데요?" 평소 7~8분이면 끝나던 잡이었다. 멘탈이 한 번 흔들렸고, 노트북을 열었다. 이게 이번 글 주제다.배경부터 짧게 말하면, 우리 팀은 지난달에 GitHub-hosted runner에서 ARC(Actions Runner Controller) 기반 self-hosted runner로 전환했다. 비용이랑 사내망 접근 때문에 어차피 가야 할 길이었고, 동료가 헬름 차트로 깔끔하게 셋업해놨다. ARC의 기본 모드인 ephemeral runner를 그대로 썼다. 잡 하나 끝나면 파드는 폐기되고 새 파드가 뜬다. 보안적으로도 깔끔하니 의심할 이유가 없었다.근데 그게 함정이었다.처음에 의심한 것들새벽 2시에 ..

클러스터가 늘어나고 환경이 늘어나면 어느 시점에 Application YAML이 폭발한다. 우리 팀도 그랬다. 클러스터 6개에 환경(dev/stg/prod) 3개, 거기에 공통으로 들어가는 플랫폼 컴포넌트 8개를 곱하니 144개의 Application 리소스가 git에 쌓였다. 사람이 손으로 관리할 수 있는 규모를 넘은 지 오래였다.이걸 ApplicationSet의 matrix generator로 정리한 과정을 적어둔다. Argo CD 공식 문서에는 패턴이 짧게만 소개돼 있고 실전에서 부딪히는 디테일은 잘 안 보여서, 우리 팀이 정착시킨 구성을 그대로 옮긴다. Argo CD 3.0 기준이지만 2.10 이상이면 거의 동일하게 동작한다.왜 matrix generator인가ApplicationSet에는 Lis..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..