day-log

PR 올릴 때마다 QA 환경 하나씩 띄우는 거, 다들 어떻게 하시나요. 우리 팀도 한참 동안은 PR 댓글에 /deploy preview 같은 슬래시 커맨드를 달고 Jenkins job을 트리거하는 방식을 썼는데, 결국에는 항상 누군가 환경을 안 지워서 노드가 터져 있곤 했다. 그래서 작년 말부터 ArgoCD ApplicationSet의 Pull Request generator로 전환했다. 지금까지 6개월 정도 돌려보니 만족도가 꽤 높아서, 셋업 가이드를 정리해둔다.이 글은 GitHub + ArgoCD 2.x 환경 기준이다. GitLab/Gitea도 거의 비슷하다.어떻게 동작하나핵심은 단순하다. ApplicationSet이 GitHub API를 폴링해서 열려 있는 PR 목록을 가져오고, 각 PR마다 App..

ArgoCD ApplicationSet은 보통 "여러 클러스터에 같은 앱을 자동으로 배포해주는 도구" 정도로 설명된다. 우리 팀도 처음엔 그렇게 썼다. List generator로 환경 별 파라미터 넘기고, 템플릿에 변수 박아 넣고. 잘 돌아갔다. 문제가 터지기 전까지는.작년 가을, 멀티 리전에 깔린 60개 가까운 Application이 사일런트하게 drift나기 시작했다. ApplicationSet 매니페스트는 그대로인데 일부 Application만 sync 상태가 이상했다. 그때 처음으로 ApplicationSet 컨트롤러 코드를 직접 까봤다. 그러고 보니 이 컨트롤러, 생각보다 단순하지 않다.reconcile 루프의 4단계ApplicationSet 컨트롤러를 한 줄로 요약하면 "Application..

ArgoCD ApplicationSet으로 12개 클러스터 한 번에 날린 이야기지난 금요일 저녁이었다. 정확히는 금요일 저녁 8시 47분. 슬랙이 한 번에 12번 울렸다. PagerDuty도 같이 울렸다. 12개 리전 prod 클러스터의 핵심 워크로드가 동시에 CrashLoopBackOff에 빠진 거였다.원인은 단순했다. ArgoCD ApplicationSet의 matrix generator에 새 컨테이너 이미지 tag를 commit했고, 그게 모든 클러스터에 동시에 sync된 거다. 캐너리도 없고, 단계적 롤아웃도 없었다. 그냥 한 방에 전부.이 글은 그날 밤 11시 40분까지 이어진 복구 과정과, 그 후에 progressive sync를 도입하면서 배운 것들에 대한 회고다.우리가 어쩌다 12개를 한 ..

GitOps 도구 고민은 의외로 끝나지 않는다. 작년 이맘때 우리 팀은 ArgoCD를 쓰고 있었는데, 어쩌다보니 한 분기를 Flux로 갈아엎고 돌렸다가 결국 다시 ArgoCD로 돌아왔다. 비교 글은 인터넷에 차고 넘치지만, 둘 다 운영 환경에서 한 사이클씩 굴려본 입장에서 쓸 만한 글은 의외로 적었다. 그래서 정리해본다.전제부터 깔자. 우리 팀은 EKS 클러스터 7개(prod 3, staging 2, dev 2), 약 220개 마이크로서비스, 배포는 하루 평균 60건쯤이다. 큰 조직은 아니지만 작지도 않다. 이 규모에서 우리가 겪은 차이를 적는다.왜 갈아탔다가 다시 돌아왔나원래 ArgoCD 2.10대를 1년 정도 잘 쓰고 있었다. 그런데 ApplicationSet generator 설정이 점점 비대해지고..

지난주 화요일 새벽 3시쯤. 휴대폰이 울렸다. 온콜 알림이었다. prod의 메인 API가 503을 뱉고 있다는. 솔직히 그날따라 몸이 너무 무거워서 한 5분쯤은 침대에서 멍하니 알림을 봤다. 그 5분이 정말 길었다.원인을 미리 말하자면, 전날 머지된 PR에서 ArgoCD argocd.argoproj.io/sync-wave 값을 한 줄 바꾼 게 문제였다. app-of-apps 패턴을 쓰는 우리 클러스터에서, 그 한 줄이 컨트롤 플레인 컴포넌트보다 워크로드를 먼저 띄우게 만들었다. 결과적으로 cert-manager가 뜨기 전에 ingress webhook이 호출돼서 발급이 꼬였고, 그게 ALB target health check를 흔들었고, 503이 떴다.새벽 3시반에 침대에서 일어나면서 든 생각: "syn..

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 ..

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

Helm lookup 함수, ArgoCD랑 같이 쓰면 함정 있다오늘 동료가 PR 리뷰 부탁한다고 해서 봤는데, Helm chart에서 lookup 함수를 쓰는 부분이 있었다. 클러스터에 이미 떠 있는 ConfigMap을 읽어서 그 값을 기반으로 다른 리소스를 만드는 패턴. 코드는 깔끔했고 로컬 helm install로도 잘 돌았는데, 내가 한 마디 했다. "이거 ArgoCD에서 안 될걸요."근데 동료는 "어 저번에 다른 차트에서도 비슷하게 썼는데 됐는데?"라고 했고, 결국 같이 한 번 더 들여다보기로 했다. 그 김에 정리.lookup이 뭐였더라lookup은 Helm 3에서 추가된 템플릿 함수다. 차트 렌더링 시점에 K8s API 서버를 쳐서 기존 리소스를 읽어올 수 있다. 예를 들면 이런 식.{{- $e..

지난주 금요일 오후 4시. 평화롭던 사무실에 메신저 알림이 떴다. "스테이징 클러스터 새로 만든 거 거의 다 됐는데, ArgoCD가 SealedSecret 못 푼다고 에러 토하는 중인데 좀 봐주실 수 있어요?" 그 메시지를 본 순간 명치가 싸늘해졌다.왜냐면 그 이전 클러스터의 sealed-secrets controller에서 발급된 master key를 백업해뒀는지 기억이 안 났거든. 결론부터 말하면 안 해놨다. 그래서 그날 퇴근은 새벽 1시였다.무슨 일이 벌어진 건가상황을 좀 정리해보자. 우리 팀은 EKS 1.28 → 1.31 업그레이드를 in-place로 안 하고 새 클러스터를 만들어서 옮기는 방식으로 진행하고 있었다. 스테이징부터. 매니페스트는 ArgoCD GitOps로 관리되니까 그냥 ArgoCD..