day-log

지난주 화요일 새벽 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이 필요한 이유기존 방식에서는 새 클러스터를 추가..