https://x.com/studiojin_dev/status/2090669625847816489?s=20

X의 Studio Jin님(@studiojin_dev) github self hosted 운영 기록 x.com

처음에는 github runner 비용 아끼기 위해서 시작했습니다.

mac -> linux vm

맥북에 container 를 이용해서 amd64 linux 이미지로 시작했는데 container 의 docker 이용 한계 때문에 폐기 했습니다.

u5825 cpu를 사용하는 nas 에 linux vm 을 올려서 runner 3개를 추가했습니다.

이미지 정리를 workflow 에 추가 했어야 했는데 안했더니 디스크를 다 써서 문제가 발생했습니다.

보안 스크립트 넣고 디스크 용량도 좀 추가 했습니다.

그런데 docker 이미지와 lambda 이미지를 aws 에 올릴 때 보안 업데이트가 안되서 가끔 막히더군요.

이미지 만들 때 Trivy 바이너리 선택하고 로컬에서 먼저 검증하는 단계를 도입했습니다. Lambda 이미지도 주기적으로 검토해서 갱신하는 것을 codex automation 에 추가해서 업데이트 되게 했습니다.

실행형 runner -> ARC

그런데 용량 관리가 잘 안되서 github ARC 라는 쿠버네티스 환경으로 변경합니다. ARC 는 ci 마다 k8s 환경에서 이미지를 만들어서 실행하고 폐기하기 때문에 용량 관리가 자동으로 됩니다. linux vm 에 k3s 라는 경량 쿠버네티스 환경을 설치해서 사용합니다. docker 에서 관리하는 팜으로 운영 할 수도 있는데 DinD 분리하기 위해 vm 설치해서 k3s를 올렸습니다.

오버헤드 줄이기

그런데 매번 runner 이미지 만들고 python library, npm library 를 재설치 하니까 오버헤드가 커졌습니다. PVC 를 통해서 playwright, python, npm 캐쉬 분리해서 로컬 파일을 사용하게 해 네트워크 비용을 줄였습니다. runner toolchain 도구도 내장시켰죠

runner image , base image 도 ci 마다 매번 실행하면 네트워크 비용과 시간이 소요되기 때문에 정기적으로 만들게 했습니다. 그래서 ci 에 새로 이미지 만들거나 dnf 업데이트 하는 시간을 줄였습니다. 이미지는 linux vm 에 registry 설치해서 이용하게 했습니다.

ARM vs x86/amd64

저는 aws graviton 인스턴스를 사용합니다. x86 보다 더 싸기 때문이죠. 그런데 안그래도 저전력 cpu 인데다가 크로스 컴파일 하고 이미지 빌드해야 하니 시간이 많이 걸립니다.

docker desktop 에 쿠버네티스 환경 설정 할 수 있어서 이미지 배포만 맥북을 이용하게 했습니다. 어차피 혼자 개발하니 배포 할 때 맥북이 안켜져 있을 이유가 없습니다.

맺으며

self-hosted runner 를 운영하려면 ARC 에서 하는게 좋습니다. 그러나 오버헤드를 줄이기 위해서 캐쉬, 이미지 미리 만들기 등 구현 해야 할 사항이 많기도 합니다. 그냥 돈으로 발라버리는게 최선이라는 생각 뿐입니다.

원문 네이버 블로그: https://blog.naver.com/kimjj81/224385608234