day-log

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

GitHub-hosted runner 비용이 슬슬 부담스러워서 self-hosted로 갈아탈 때, 요즘은 거의 ARC(Actions Runner Controller) + Karpenter 조합이 정석처럼 굳어가는 분위기다. 우리 팀도 작년 말부터 이 구성으로 전환했고, 그 과정에서 정리해둔 내용을 가이드로 풀어본다.작년 6월에 ARC 0.12가 나오면서 ephemeral runner 설치가 큐잉되고 실패 시 5번까지 재시도하는 식으로 바뀌었다. 노드 스케일 다운 도중에 러너 파드가 휘말려 죽는 케이스에서 체감이 꽤 좋아졌다. 이 글은 0.12 이상 기준이다.왜 Karpenter랑 묶나처음엔 Cluster Autoscaler로도 충분하지 않을까 했었다. 결론부터 말하면, CI 워크로드 특성상 Karpent..

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