day-log

프로그레시브 딜리버리 도구를 고르라고 하면 대부분 두 개로 좁혀진다. Argo Rollouts와 Flagger. 둘 다 CNCF 프로젝트고, 둘 다 카나리를 자동화한다. 그런데 실제로 붙여보면 두 도구가 세상을 바라보는 방식이 꽤 다르다.우리 팀에서는 작년 초에 Argo Rollouts로 시작했다가, 서비스 메시를 Linkerd로 굳히면서 Flagger를 병행하는 상황이 됐다. 반년 정도 두 개를 같이 굴려보면서 느낀 걸 정리해본다. 결론부터 말하면 어느 한 쪽이 압도적으로 낫다고는 못 하겠고, "우리가 이미 뭘 쓰고 있느냐"에 따라 답이 갈린다.근본적인 차이: 워크로드를 소유하느냐Argo Rollouts는 Deployment를 대체한다. Deployment 대신 Rollout이라는 CRD를 쓰고, 이게..

GitHub Actions self-hosted runner를 Kubernetes 위에 굴리는 방법으로 요즘 표준은 사실상 Actions Runner Controller(ARC)다. 근데 올해 3월에 0.14.0이 GA로 풀리면서 꽤 큰 변화가 있었다. multilabel 지원이 들어왔고, 내부 클라이언트도 actions/scaleset 라이브러리로 교체됐다. 우리 팀도 이번 주에 0.11 → 0.14로 올리면서 몇 가지 정리한 게 있어서 가이드 형태로 남긴다.이 글은 "ARC 처음 세팅한다" 시나리오를 기준으로 쓴다. 이미 legacy(runner deployment) 모드로 굴리고 있는 팀이라면 뒷부분 마이그레이션 노트만 봐도 된다.왜 scale set 모드인가ARC는 두 가지 모드가 있다. 예전부터..

컨테이너 이미지 업데이트를 자동화하려고 이것저것 붙여본 지 꽤 됐다. GitHub 표준인 Dependabot을 쓰다가, 결국 Renovate로 옮겨온 팀들이 주변에도 늘고 있다. 두 도구는 언뜻 비슷해 보이지만 컨테이너 이미지 관점에서 뜯어보면 결이 꽤 다르다. 이번 글은 지금 우리 팀이 어떤 기준으로 골랐고, 왜 그런 결정을 했는지 정리한 것에 가깝다.우리가 원했던 것시작은 단순했다. 사내 서비스 20여 개, Helm chart 60여 개, GitHub Actions 워크플로 100개 이상에서 쓰이는 이미지 태그를 자동으로 최신화하고 싶었다. 규모가 커지면서 수작업 업데이트가 자꾸 밀렸고, 오래된 base image 하나가 CVE 리포트에 걸려서 리뷰가 늘어나는 일이 반복됐다.그리고 원한 건 세 가지였..

ArgoCD ApplicationSet Progressive Sync 실무 가이드멀티 클러스터로 ArgoCD를 굴리다 보면 한 번은 겪는 상황이 있다. 앱 매니페스트를 하나 바꿨는데 그게 20개 클러스터에 동시에 동기화되면서, 하필 그 변경이 문제였을 때 20개가 같이 뻗어버리는 케이스. 우리 팀도 지난 분기에 한 번 크게 데었고, 그 이후로 ApplicationSet Progressive Sync를 프로덕션에 도입했다.이 글은 도입하면서 정리한 내용이다. 문서만 보고 따라 하면 놓치기 쉬운 부분 위주로 적었다. Progressive Sync 자체는 2026년 현재 Beta로 승격됐는데, 여전히 experimental 플래그로 활성화해야 한다는 점을 먼저 짚어둔다.Progressive Sync가 뭘 하는..

지난주 화요일 새벽 3시 반쯤, 슬랙 알림에 깼다. "CI 전체 실패 중" 이라는 온콜 메시지. 눈 비비고 노트북 열었더니 GitHub Actions 화면이 온통 빨간색이었다. 로그를 열어보니 다들 같은 메시지를 뱉고 있었다.No space left on device우리 팀은 self-hosted runner를 EC2 위에 올려서 쓴다. 처음 세팅했을 때부터 "언젠가 디스크 문제 터진다"는 거 알고 있었는데, 대응을 미루다가 결국 새벽에 얻어맞은 케이스였다. 그날 겪은 삽질을 정리해둔다.상황우리 러너 구성은 대략 이랬다.c6i.2xlarge EC2 3대, ephemeral 아니고 long-runninggp3 100GB 루트 볼륨 하나Docker in Docker로 이미지 빌드/테스트하루 평균 400개 정..

CI에서 Docker 빌드 시간이 아깝다는 얘기를 최근에도 팀에서 몇 번 들었다. 로컬에선 5초 만에 끝나는데 GitHub Actions에서만 3분씩 걸리는, 그 짜증나는 상황. 오늘 알게 된 건 아니지만 의외로 모르는 분들 꽤 많더라. 짧게 정리해둔다.문제는 러너가 매번 새거라는 점BuildKit의 RUN --mount=type=cache는 원래 로컬에서 잘 돈다. 예를 들면 이런 식.# syntax=docker/dockerfile:1.7FROM node:20WORKDIR /appCOPY package*.json ./RUN --mount=type=cache,target=/root/.npm \ npm ciCOPY . .RUN --mount=type=cache,target=/app/node_modul..

지난달 우리 팀에서 ArgoCD ApplicationSet의 Progressive Sync를 처음 붙여봤다. 클러스터 6대에 걸쳐 있는 인프라 성격의 앱들을 한 번에 롤아웃할 때 폭발 반경을 줄여보자는 목적이었는데, 결론부터 말하면 절반은 살렸고 절반은 원래 하던 대로 되돌렸다. 그 과정에서 배운 걸 좀 정리해둔다.왜 갑자기 Progressive Sync였나우리는 ApplicationSet의 cluster generator로 6개 EKS 클러스터에 fluent-bit, node-exporter, cert-manager, ExternalDNS 같은 인프라 워크로드를 뿌리고 있다. 문제는 이게 진짜로 6대에 동시에 나가버린다는 거였다. 지난 분기에 fluent-bit config를 잘못 바꿔서 6대 전부에서..

왜 OIDC인가 — 30초 요약한동안 "AWS Access Key를 Secrets에 넣지 마세요"가 마치 mantra처럼 돌았다. 대안은 오래전부터 있었다. GitHub Actions의 OIDC 토큰을 AWS IAM Role의 web identity federation으로 교환하는 방식. 우리 팀도 재작년쯤 다 옮겼는데, 최근 이걸 다시 손 볼 일이 생겼다. 2026년 4월과 7월에 걸쳐 GitHub가 OIDC 토큰의 sub 클레임 포맷을 immutable ID 기반으로 바꿨기 때문이다. 새로 만드는 리포는 자동으로 새 포맷을 쓴다. 기존에 잘 돌던 IAM trust policy가 새 리포에서는 안 붙는다는 얘기다.이 글은 처음 세팅하는 사람과, 이미 쓰고 있지만 최근 트러스트 정책이 실패한 사람 둘 다..

지난주 화요일 밤, 스테이징에서 새 서비스를 릴리즈하는 중이었다. ArgoCD 앱 하나 만들고, sync 눌렀고, 커피 한 잔 뜨러 갔다 왔다. 돌아왔더니 sync 상태가 Progressing에서 멈춰 있었다. 40분째. 그때부터 새벽 두 시까지 이걸 풀었다.뭐가 문제였나우리 팀은 요즘 ArgoCD 앱에 argocd.argoproj.io/sync-wave annotation을 적극적으로 쓴다. 이유는 단순하다. Helm chart 하나에 CRD, Namespace, ConfigMap, Deployment, Service, Ingress가 다 들어 있으면 순서가 꼬인다. CRD가 만들어지기 전에 Custom Resource가 apply되면 sync가 실패한다. 그래서 CRD는 wave 0, Namespac..

카나리 배포 도구를 다시 고를 일이 생겼다. 원래 팀에서 자체 스크립트로 트래픽을 조금씩 옮기던 방식을 쓰고 있었는데, 서비스가 늘어나면서 이런 로직을 CD 파이프라인에 직접 박아 넣는 게 한계에 왔다. "이제 진짜 프로그레시브 딜리버리 컨트롤러를 붙이자"는 결론에 도달했고, 후보는 사실상 둘이었다. Argo Rollouts와 Flagger.둘 다 CNCF 프로젝트고, 둘 다 production 레퍼런스가 충분하다. 근데 이 둘이 문제를 푸는 방식이 꽤 다르다. 한 달 정도 병렬로 굴려보고 결국 하나를 골랐는데, 그 과정에서 정리한 내용을 남겨둔다.워크로드를 대하는 태도가 다르다가장 큰 구조적 차이는 이거다. Argo Rollouts는 Deployment 리소스를 Rollout이라는 커스텀 리소스로 대체..