day-log

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

오늘 팀원한테 Helm values override 얘기를 하다가 알게 됐다. --set-json 플래그 쓰는 사람이 생각보다 적더라. 대부분 --set으로 어떻게든 우겨넣거나 임시 values 파일 만들어서 -f로 넘긴다.근데 CI 파이프라인에서 잠깐 하나만 override할 때는 이게 좀 애매하다. values 파일 만들자니 번거롭고, --set으로 배열/객체 넣자니 콤마 이스케이프 지옥이 시작된다. 이럴 때 --set-json이 답이다.--set의 콤마 지옥sidecar 하나 붙이려고 --set으로 배열 넣어본 적 있으면 안다. 이런 걸 만나게 된다.# 실패 확률 높은 코드helm install redis ./chart \ --set master.sidecars[0].name=logger \ -..

오늘 삽질하다가 알게 된 건데, cancel-in-progress: true 이거 그냥 다 켜두면 안 된다. 우리 팀에서도 몇 달 전에 이거 때문에 한 번 크게 데었다. PR 워크플로우에서는 문제 없이 잘 돌던 설정을 main 브랜치 배포 워크플로우에까지 그대로 붙여놨더니, 연달아 커밋이 두 번 들어왔을 때 앞선 배포가 중간에 잘려버리고 뒤 커밋만 배포됐다. 그 사이에 이미 헬름 릴리즈는 1단계까지 올라가 있었고. 정확히는 ArgoCD sync가 반쪽만 돈 상태였는데, 이걸 새벽에 알림 보고 복구하느라 한참 걸렸다.group 스코프를 어디로 잡을지가 핵심기본 패턴은 이거다.concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-p..

지난 목요일 새벽 두 시. 슬랙에 "prod 배포 30분째 안 끝나요"라는 메시지가 올라왔다. 나는 이미 자고 있었고, 폰 진동에 눈이 번쩍 떠졌다. 노트북을 열어보니 ArgoCD 대시보드가 애매한 상태였다. Application은 Syncing 인데 진행률은 그대로. 사실상 멈춰 있었다.이 글은 그날 새벽에 뭘 삽질했고, 왜 그런 일이 벌어졌는지에 대한 회고다. 결론부터 말하면 sync wave 하나가 조용히 우리 파이프라인을 인질로 잡고 있었다. 최근 ArgoCD 공식 문서와 오퍼레이션 노트를 다시 정리하다 보니 이 삽질담을 남기는 게 낫겠다 싶었다.상황: 어디가 막혔는지도 모르겠다우리 팀은 프로덕션 배포를 GitOps로 굴린다. Argo CD가 이십 몇 개 애플리케이션을 관리하고 있고, 그중 하나가..

오늘 알게 된 건데, GitHub Actions에 queue: max 옵션이 생겼다. 5월 초에 조용히 릴리즈된 것 같다. 이거 모르는 분 꽤 많을 것 같아서 짧게 정리한다.기존 방식의 아쉬움우리 팀은 배포 파이프라인에 concurrency 그룹을 걸어 놨었다. 같은 환경에 두 개가 동시에 배포되면 곤란하니까.concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false문제는 이 설정으로 큐잉되는 최대 개수가 딱 1개였다는 거다. 진행 중 1개 + 대기 중 1개, 총 2개까지만. 세 번째 잡이 들어오면 대기 중이던 잡이 그냥 취소됐다. 배포 트리거가 몰리는 날에는 중간 잡이 스킵돼 버려서, PR 머지 순서움 실제 배포 순서가 어긋나는 상..

지난 주 화요일 아침에 백엔드 팀장이 슬랙 DM으로 물어봤다. "요즘 CI가 왜 이렇게 느려요? 예전에는 8분이면 됐는데 요새는 20분 넘게 걸리는 것 같은데." 확인해보니 정말 그랬다. Go 서비스 하나의 build job이 12분에서 19분으로 늘어나 있었다. 뭐 변경한 것도 없는데.내가 저 CI를 마지막으로 만진 게 6월 초였다. --mount=type=cache를 붙여서 Go module 다운로드를 캐싱하도록 바꿨다. 그때는 확실히 빨라졌다. 첫 빌드가 14분, 두 번째부터는 5분대. 팀 슬랙에 자랑까지 했다. 그런데 한 달 반이 지난 지금은 20분이 나오고 있었다.처음엔 러너 탓인 줄 알았다첫 번째 추측은 GitHub Actions runner가 지역별로 느려졌나 하는 것이었다. 요새 self-..

멀티 클러스터 20개를 한꺼번에 sync 걸어놓고 잠들었던 적이 있다. 다음 날 아침 슬랙이 폭발해 있었다. 카나리 배포한다고 flag까지 걸어뒀는데도 20개 클러스터가 동시에 다 뒤집혀버린 상황. 그때 알았다. ApplicationSet 자체는 "언제 sync할지"에 대해 아무 개념이 없다는 걸.ArgoCD 2.9에서 Progressive Sync가 stable로 승격된 지도 꽤 됐고, 2026년 들어서는 pause/resume 애노테이션 같은 기능도 얹혀서 실전 쓸만해졌다. 그런데 이게 정확히 뭘 하는 놈인지, RollingSync strategy가 내부적으로 어떤 순서로 Application을 다루는지 이해 못한 채 쓰는 사람이 꽤 있는 것 같아서 정리해본다. 사실 나도 최근에 다시 파봐서야 명확해..

BuildKit을 쓰기 시작한 지 꽤 됐다. DOCKER_BUILDKIT=1 넣는 건 이제 반사적으로 나온다. 그런데 얼마 전 팀 내부에서 "왜 RUN apt-get install이 캐시된 건 알겠는데, --mount=type=cache를 걸었을 때 도대체 뭐가 저장되고 뭐가 재사용되는 거냐"는 질문을 받고 답을 얼버무렸다. 그날 저녁에 소스와 문서를 뒤져가며 정리한 내용을 여기 남긴다.이 글은 실행 가이드는 아니다. BuildKit이 캐시를 어떻게 표현하고, 어디에 저장하고, 어떤 기준으로 재사용을 판단하는지 흐름을 따라간다. docker buildx build --cache-to=type=registry 를 쳤을 때 그 뒤에서 일어나는 일이 궁금한 사람이 대상이다.LLB — 캐시의 진짜 단위먼저 알아..

작년 말부터 팀 내부에서 카나리 배포 도구 얘기가 계속 돌았다. 우리 서비스는 그동안 그냥 Deployment의 RollingUpdate maxSurge/maxUnavailable 조합으로만 배포해왔는데, 최근에 P99 레이턴시가 순간적으로 튀는 케이스가 반복되면서 "이거 그냥 롤링 업데이트로는 안 잡히겠다"는 얘기가 나왔다. 새 버전이 트래픽을 5%만 받아본 뒤 지표 보고 승격시키는 구조로 가야 한다는 데는 합의가 됐는데, 문제는 Argo Rollouts를 쓸지 Flagger를 쓸지였다.한 달 정도 두 도구를 실제로 스테이징에 붙여보고 최근에 결론을 냈다. 이 글은 그 과정에서 정리한 노트다. 둘 중 하나가 절대 옳다는 얘기가 아니라, 어떤 상황에서 어느 쪽이 덜 아픈지 정도의 이야기다.근본적인 접근 ..

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