day-log

재사용 워크플로우(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..

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 설정이 점점 비대해지고..

작년쯤만 해도 우리 팀 CI 파이프라인의 절반은 Kaniko로 굴러갔다. EKS 안에서 in-cluster 빌드를 돌리는 게 너무 깔끔했기 때문에. 근데 2025년 6월 3일에 GoogleContainerTools/kaniko 리포가 read-only로 archived 돼 버렸다. 그 다음 주에 사내 보안팀에서 "유지보수 안 되는 OSS는 점진적으로 걷어내자"는 공지가 떴고, 우리도 슬슬 다른 길을 찾기 시작했다.이 글은 그 과정에서 Buildx, Kaniko(Chainguard fork 포함), ko 세 가지를 다 돌려보고 결정한 이야기다. "이게 정답이다" 같은 결론은 없다. 워크로드에 따라 답이 갈렸다.우리가 쓰던 환경먼저 맥락을 좀 깔자. 우리 팀 빌드 워크로드는 대략 60개의 서비스 이미지인데,..

오늘 알게 된 건 아니고, 어제 팀 PR 리뷰하다가 "어 이거 아직도 모르는 분들 꽤 많은데" 싶어서 짧게 정리해둔다. 우리 팀에서도 작년 한 분기 동안 같은 사고를 두 번 냈다. 똑같은 워크플로가 동시에 두 개 뜨면서 한쪽이 helm release를 절반쯤 적용한 상태에서 다른 한쪽이 덮어쓰는 그림. 새벽 3시에 슬랙 알림으로 깨면 진짜 멘탈이 묘하게 무너진다.한 줄이면 끝난다concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false이게 전부다. 같은 브랜치에서 deploy 워크플로가 한 번에 하나만 돌게 만든다. PR 빌드용 워크플로면 cancel-in-progress: true로 바꿔서 새 커밋이 들어올 때 진행 중인 빌드를 죽..

지난주 화요일 새벽 2시쯤, 슬랙에 멘션이 떴다. "프론트엔드 빌드 파이프라인이 30분 넘게 안 끝나는데요?" 평소 7~8분이면 끝나던 잡이었다. 멘탈이 한 번 흔들렸고, 노트북을 열었다. 이게 이번 글 주제다.배경부터 짧게 말하면, 우리 팀은 지난달에 GitHub-hosted runner에서 ARC(Actions Runner Controller) 기반 self-hosted runner로 전환했다. 비용이랑 사내망 접근 때문에 어차피 가야 할 길이었고, 동료가 헬름 차트로 깔끔하게 셋업해놨다. ARC의 기본 모드인 ephemeral runner를 그대로 썼다. 잡 하나 끝나면 파드는 폐기되고 새 파드가 뜬다. 보안적으로도 깔끔하니 의심할 이유가 없었다.근데 그게 함정이었다.처음에 의심한 것들새벽 2시에 ..

오늘 PR 리뷰하다가 Dockerfile에서 발견한 게 있어서 짧게 적어둔다. CI 빌드 시간 길다고 투덜대는 동료가 있는데, 정작 Dockerfile에는 RUN apt-get install -y ... 한 줄만 덩그러니 있더라. cache mount를 안 쓰고 있었다.이게 좀 의외였다. Docker 18.09에서 BuildKit 들어온 게 한참 됐고, cache mount도 새 기능이 아닌데, 의외로 실무에서 안 쓰는 사람이 많다. 한번 적용하면 빌드 시간이 절반 이하로 떨어지는 걸 자주 본다.그래서 뭐하는 건데RUN --mount=type=cache,target=... 한 줄을 RUN 명령에 붙이면, BuildKit이 그 디렉토리를 빌드 간에 영속화해준다. 캐시 레이어가 깨져서 RUN을 다시 돌려도,..

클러스터가 3개를 넘어가면서 ArgoCD Application 매니페스트를 하나하나 만들어 관리하는 게 현실적으로 불가능해진 경험이 있을 것이다. dev, staging, production에 각각 마이크로서비스 10개만 배포해도 Application YAML이 30개다. 여기에 리전별 클러스터까지 추가되면 관리 포인트가 기하급수적으로 늘어난다.ArgoCD ApplicationSet Controller는 이 문제를 정면으로 해결한다. 템플릿 하나로 여러 클러스터, 여러 환경에 Application을 자동 생성하고 라이프사이클까지 관리할 수 있다. 이 글에서는 실무에서 바로 적용할 수 있는 ApplicationSet 패턴들을 다룬다.ApplicationSet이 필요한 이유기존 방식에서는 새 클러스터를 추가..