day-log

오늘 삽질하다가 알게 된 건데, 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가 이십 몇 개 애플리케이션을 관리하고 있고, 그중 하나가..

Deployment를 Rollout으로 마이그레이션배포할 때마다 심박수가 올라가는 사람 있으면 손. 나만 그런 거 아닐 거다. 특히 트래픽이 몰리는 시간대에 롤아웃 눌러야 할 때는 정말 부담이다. Deployment의 기본 RollingUpdate 전략이 나쁜 건 아닌데, 문제는 "일단 다 밀리고 나면 되돌리기가 귀찮다"는 점이다. HPA에 물려 있는 상황에서 새 버전이 죽으면 롤백 중에도 오토스케일이 계속 돌아서 상황이 더 꼬인다.그래서 우리 팀은 몇 달 전부터 Argo Rollouts를 도입해서 카나리 배포로 옮기고 있다. 이 글은 도입 과정에서 배운 것과, "이건 처음에 알았으면 좋았을 텐데" 싶은 것들을 정리한 실무 가이드다.이달 말에 열리는 ArgoCon Japan 2026 세션 리스트를 훑어보..

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

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

ArgoCD ApplicationSet으로 멀티 환경 배포 자동화하기ArgoCD를 처음 도입했을 때는 환경마다 Application 리소스를 따로 만들어 썼다. dev, staging, prod 세 환경에 마이크로서비스 12개. 단순 계산으로 36개. 여기에 신규 환경이라도 하나 늘면 또 12개를 복사 붙여넣기. 처음엔 견딜만 했는데, 팀이 커지면서 이 반복 작업이 진짜 골치 아파졌다.ApplicationSet은 이 문제를 푸는 도구다. 한 번 정의해두면 generator가 알아서 N개의 Application을 만들어준다. 이번 글에서는 우리 팀이 실제 운영하면서 정착시킨 패턴을 정리해본다. 참고로 최근 ArgoCD 3.3에서 ApplicationSet의 shallow clone 옵션이 추가돼서 큰 모노..

재사용 워크플로우(reusable workflow) 쓰다 보면 거의 반사적으로 secrets: inherit 한 줄 박아두게 된다. 편하니까. 근데 이게 동작 방식을 정확히 모르고 쓰면 디버깅하다가 한 시간씩 날려먹는 포인트가 몇 개 있다. 오늘은 그 중 자주 걸리는 것들만 짧게 정리.inherit는 "직접 호출한 워크플로우"까지만 간다체인 호출에서 제일 많이 헷갈리는 부분이다. A → B → C 구조라고 하자. A에서 B를 부르면서 secrets: inherit을 줬다. B에서 C를 부르는데 거기에 secrets: inherit을 또 안 적으면, C는 시크릿을 못 본다. inherit는 한 단계만 전파된다.# A.ymljobs: call-b: uses: ./.github/workflows/B.y..

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

Access Key를 GitHub Secrets에 박아두는 거, 이제 진짜 그만할 때가 됐다. 우리 팀도 작년에 한 번 키가 외부로 새서 식겁한 적이 있는데, 그 사건 이후로 모든 리포지토리를 OIDC로 옮겼다. 사실 옮기는 작업 자체가 어렵진 않다. 어려운 건 신뢰 정책(trust policy)을 너무 느슨하게 잡거나, 반대로 너무 빡빡하게 잡아서 워크플로우가 자꾸 깨지는 거다.이번 글에선 GitHub Actions의 OIDC 토큰으로 AWS IAM Role을 assume하는 과정을 실전 기준으로 정리한다. 처음 세팅하는 사람도 따라할 수 있게 단계별로 적었다.왜 OIDC인가장기 credential(Access Key/Secret Key)을 Secrets에 저장하면 두 가지가 걸린다. 하나는 키가 유출..

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