day-log

작년 말부터 우리 팀은 GitHub Actions 한 곳에 모든 파이프라인을 몰아넣던 구조를 깨기 시작했다. 빌드/배포는 Actions에 두고, 데이터 파이프라인과 K8s 안에서 도는 무거운 잡들은 클러스터 안에서 돌리자는 결정이었다. 후보는 Tekton Pipelines와 Argo Workflows 두 개. 결정을 못 내려서 결국 둘 다 6개월씩 굴려봤다.올해 들어 두 프로젝트 모두 큰 릴리즈가 있었다. Tekton Pipelines는 작년 5월에 v1.0 GA 찍고 올 2월에 v1.9.0 LTS를 냈고, Argo Workflows는 v4.0.0이 2월 4일에 떨어졌다. 둘 다 안정성과 운영 편의 쪽으로 방향이 잡혀가는 시점이라 비교하기 딱 좋았다.우리가 본 워크로드비교가 의미 있으려면 어떤 잡을 돌렸..

이거 모르는 분 꽤 많더라. 우리 팀도 작년 말까지 모르고 있었고, 우연히 디플로이 파이프라인 디버깅하다가 발견했다.concurrency: 블록을 workflow 레벨에 걸어 둔 상태에서 matrix strategy로 OS 3개를 동시에 돌리면 어떻게 될까. 정답은 3개가 서로를 취소시킨다.name: teston: [push]concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: truejobs: test: strategy: matrix: os: [ubuntu-latest, macos-latest, windows-latest] runs-on: ${{ matrix.os }} ..

작년 이맘때쯤 progressive delivery를 본격적으로 도입하기로 결정했다. 그 때만 해도 우리 팀은 "둘 다 비슷한 거 아니야?"라는 분위기였고, 사실 데모만 보면 정말 비슷해 보였다. 캐너리, 블루그린, 메트릭 기반 자동 promotion. 똑같은 단어들이 양쪽 문서에 다 나온다.그래서 우리는 좀 무책임한 결정을 했다. 둘 다 써보기로 했다. 일부 서비스는 Flagger, 일부는 Argo Rollouts. 1년이 지난 지금, 한쪽으로 통일하기로 했고, 그 과정에서 알게 된 차이들을 정리해 본다.시작 환경우리 환경을 먼저 짧게 적는다. 비교는 결국 환경 의존적이라서.EKS 1.32 클러스터 두 대 (스테이지/프로덕션)서비스 메시는 Istio (ambient 아니고 sidecar)GitOps는 ..

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

GitHub-hosted runner 비용이 매달 슬금슬금 오르더니, 우리 팀에서도 결국 self-hosted로 옮길지를 진지하게 검토하게 됐다. 처음에는 옛날 ARC(legacy mode, RunnerDeployment CRD 쓰던 그거)를 떠올리고 망설였는데, 알아보니 ARC는 2년 전부터 scale set 기반으로 완전히 재설계됐고, 올해 3월에 나온 0.14.0에서는 내부 GitHub API 클라이언트마저 공개 라이브러리(actions/scaleset)로 교체됐다. 즉, 지금 ARC는 사실상 "scale set 전용"이라고 봐도 된다.이 글은 처음부터 ARC scale set으로 시작하려는 사람을 위한 도입 가이드다. 우리 팀이 PoC 단계에서 겪은 함정도 함께 정리했다.무엇이 바뀌었나기존 ARC..

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

배포 자동화는 다들 잘 해놨는데, 정작 "이 배포 잘 된 거 맞아?"를 판단하는 건 사람이 대시보드 보고 있다. 우리도 그랬다. ArgoCD가 알아서 sync까지는 해주는데, P99가 튀거나 에러율이 올라가면 누군가는 새벽에 깨서 롤백을 해야 했다.올해 초 Argo Rollouts을 본격적으로 도입했고, AnalysisTemplate으로 Prometheus 메트릭을 보고 자동 롤백까지 시키는 데까지 왔다. 이 글은 그동안 정리해둔 셋업 노트다. 처음 도입하는 팀이 보면 30분 안에 동작하는 canary는 만들 수 있게 썼다.왜 Rollout인가 (Deployment로는 안 되나)솔직히 Deployment + RollingUpdate로도 canary 비슷한 흉내는 낼 수 있다. 그런데 두 가지가 안 된다...

지난주에 우리 팀 dev/staging 클러스터의 ArgoCD를 2.14에서 3.0으로 올렸다. 공식 블로그에서는 "small but mighty"라고 했고, 업그레이드 노트도 "low-risk upgrade"라고 적혀 있길래 점심 먹기 전에 끝낼 수 있을 줄 알았다. 근데 점심을 굶었다. 그리고 저녁도 거의 굶을 뻔했다.운영 클러스터 올리기 전에 dev에서 한 번 더 정리하고 가는 게 좋을 것 같아서, 우리가 어디서 발이 걸렸는지 기록으로 남긴다. 공식 문서가 빠뜨린 건 없는데, 문서가 짧고 담백해서 "어 이게 진짜 우리한테 영향 있나?" 라고 흘려 보기 쉽다. 우리는 흘려 봤고 결과는 위 문단대로다.첫 번째 지뢰: logs RBAC 강제3.0부터 logs RBAC enforcement가 default..

작년 봄에 우리 팀 CI/CD 표준을 정리하면서 GitHub Actions의 Reusable Workflow와 Composite Action을 둘 다 도입했다. 그땐 "쓰임새가 다르니까 둘 다 쓰자"가 결론이었는데, 1년 굴려보니 둘의 경계가 처음 생각보다 훨씬 명확하게 갈렸다. 그리고 최근 GitHub이 2026 Actions 보안 로드맵을 발표하면서 Composite action의 nested dependency 노출 방식, scoped secrets 같은 변경이 들어오기 시작해서, 이참에 한번 정리해두면 좋을 것 같다.이 글은 단순히 둘의 문법 차이를 비교하는 글은 아니다. 실제로 우리 팀이 어떤 기준으로 갈라 썼고, 어디서 후회했고, 지금 어떻게 운영하는지에 대한 회고에 가깝다.단도직입적으로, 우..

지난주 화요일 새벽 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..