GitHub 호스팅 대신 자신의 러너를 돌리는 이유는?

진짜 이유가 셋: 자신의 의존성과 툴체인을 구워 넣기(매번 다시 설치 안 함), 내부 레지스트리나 데이터베이스 같은 프라이빗 리소스 접근, 그리고 기기의 통제 — 그 크기, 캐시, 네트워크. GitHub 호스팅 분과 깨끗한 환경이 맞으면 거기 머무세요. 이 셋 중 하나가 특별히 필요할 때 자체 호스팅하세요.

자체 호스팅 러너를 쓰는 게 안전한가요?

프라이빗 리포에서는, 네. 공개 리포에서는, 아니오 — 절대. 워크플로는 트리거한 자의 임의 코드를 돌리고, 공개 리포에서는 낯선 이의 풀 리퀘스트가 그의 코드를 당신 러너에서 돌릴 수 있습니다. GitHub 자체 문서도 같은 말을 합니다. 자체 호스팅 러너는 프라이빗 리포에 두거나, 박스를 인터넷에 넘기고 있음을 받아들이세요.

러너에 CPU와 RAM이 얼마나 필요한가요?

전적으로 빌드에 달렸습니다. 전형적인 컴파일-앤-테스트 작업은 2코어와 4-8 GB로 편안 — 여기서 Small이나 Medium. 무거운 빌드(큰 네이티브 컴파일, 큰 Docker 이미지, 메모리를 먹는 테스트 스위트)는 더 원하고, 짐작이 아니라 실제 작업에 맞춰야 합니다. 실제 실행 한 번을 보면 압니다.

하나의 러너가 여러 리포를 처리할 수 있나요?

러너는 조직에 등록되어 여러 리포에 잡힐 수 있지만, 기본은 한 번에 한 작업입니다. 더 많은 병렬에는 더 많은 러너를 — 각각이 자신의 systemd 서비스. 다만 전부 프라이빗 리포에 두세요.

신분증을 드려야 하나요?

아니요. 가입은 이메일, 결제는 USDC나 USDT. 서류 없음, 약 1분 만에 root.

VPS에서 자체 호스팅 GitHub Actions 러너 돌리기

GitHub 호스팅 러너는 좋은 기본값입니다. 빌드가 그들이 갖지 않은 무언가를 원하는 순간 그것들이 필요 없어집니다 — 당신의 프라이빗 패키지 레지스트리, 매번 다시 설치하기 지친 특정 툴체인 버전, 자신의 네트워크 위 데이터베이스, 아니면 그저 기기의 더 많은 통제. 그때 VPS의 자체 호스팅 러너가 값어치를 법니다.

이 가이드는 하나를 제대로 돌립니다: 설치, 등록, systemd 아래에서 살아, 그리고 — 사람들이 틀리는 부분 — 안전하게. 그 마지막부터 시작합시다, 그것이 무는 부분이니까요.

단 하나의 보안 규칙

GitHub Actions 워크플로는 임의 코드를 돌립니다 — 워크플로 파일에 있는 것, 그리고 그 코드가 끌어오는 무엇이든. 자신의 리포에서는 그것이 당신 코드이고 괜찮습니다. 공개 리포에서는 낯선 이의 풀 리퀘스트가 그의 코드를 당신 러너에서 돌릴 수 있습니다. 그것은 버그가 아니라 CI가 그렇게 작동하는 것입니다. GitHub 자체 문서가 담담히 말합니다: 공개 리포지토리에 자체 호스팅 러너를 쓰지 마라.

그래서 규칙은 단순하고 협상 불가: 자체 호스팅 러너는 프라이빗 리포를 위한 것. 리포가 공개면 GitHub 호스팅 러너를 쓰고 넘어가세요. 아래 모든 것은 프라이빗 리포를 전제합니다.

러너가 박스에 요구하는 것

빌드에 달렸고, 페이지의 숫자가 아니라 당신 것에 맞춰 크기를 잡아야 합니다:

전형적인 컴파일-앤-테스트 작업 — 2코어와 4-8 GB면 편안. Small($8, 4 vCPU / 4 GB)이나 Medium($12, 6 vCPU / 6 GB)이 이들 대부분을 커버.
더 무거운 빌드 — 큰 네이티브 컴파일, 큰 Docker 이미지 빌드, 메모리를 먹는 테스트 스위트 — 는 더 많은 여유를 원합니다. 실제 실행 한 번(빌드 중 htop)을 보고 희망이 아니라 실제로 보이는 것에 맞추세요.

디스크도 중요: 빌드 캐시, Docker 레이어, 클론한 리포가 쌓입니다. 눈을 두고 prune하세요.

1. 박스 준비

러너용 비-root 사용자를 만드세요 — GitHub 설치기는 어차피 root로 도는 걸 거부하고, 그게 바람직합니다:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # 빌드가 정말 sudo가 필요할 때만

빌드가 필요로 하는 무엇이든 설치하세요 — 언어 툴체인, Docker, 빌드 도구. 예를 들어 작업이 컨테이너를 빌드하면:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. 러너 다운로드 및 등록

GitHub의 리포(또는 org)에서 Settings → Actions → Runners → New self-hosted runner로 가세요. GitHub이 정확한 다운로드 명령과 registration token을 줍니다(수명이 짧으니 새것을 받으세요). runner 사용자로:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# 당신 OS/arch용으로 GitHub이 보여주는 정확한 URL을 쓰세요:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh가 러너 이름, 라벨, work 폴더를 묻습니다 — 시작하는 데는 기본값이면 됩니다. 라벨은 워크플로가 이 러너를 겨냥하는 방법입니다(runs-on: self-hosted).

3. systemd 서비스로 돌리기

러너에는 systemd 서비스를 당신을 위해 설치하는 헬퍼가 딸려 옵니다 — 그것을 써서 러너가 재부팅을 견디고 실패에 재시작하게 하세요. 여전히 runner 사용자의 설치이지만, 서비스 명령은 root가 필요합니다:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

그것이 actions.runner.*를 runner 사용자로 도는 systemd 유닛으로 등록하고, 부팅 시 시작합니다. 로그는 journald로:

sudo journalctl -u 'actions.runner.*' -f

GitHub의 Runners 페이지로 돌아오면 러너가 이제 Idle을 보여줍니다 — 초록 점. 워크플로를 그것에 향하게 하세요:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

푸시하면 작업이 당신 박스에서 돕니다.

4. 깨끗이 유지하기

자체 호스팅 러너는 작업 사이에 파일시스템을 재사용합니다 — 그것이 속도의 승리(따뜻한 캐시)이자 함정(남은 상태)입니다. 두 습관이 건강히 유지합니다:

정기적으로 prune. 특히 Docker — cron으로 docker system prune, 아니면 디스크가 죽은 레이어로 조용히 찹니다.
박스에 비밀을 저장하지 않기. GitHub Actions 시크릿을 쓰고, 실행마다 주입, 러너의 home에 놓인 파일이 아니라. 러너가 침해되면 디스크의 것은 함께 갑니다.

작업마다 진짜 깨끗한 환경이 필요하면 각 작업을 컨테이너 스텝 안에서 돌리세요 — 러너는 남고, 작업의 어질러짐은 남지 않습니다.

언제 자체 호스팅할지, 솔직히

자신의 툴체인을 구워 넣고 싶거나, 프라이빗 네트워크 리소스 접근, 기기 통제가 필요할 때 자체 호스팅하세요. 깨끗한 일회용 환경과 그들의 분이 맞으면 GitHub 호스팅 러너에 머무세요 — 그게 정말 더 단순하고, 단순함에는 값어치가 있습니다. 그리고 절대, 공개 리포에서 자체 호스팅하지 마세요. 그건 취향이 아닙니다.

프라이빗 리포 러너가 필요한 것이라면: 요금제를 고르세요 — 가벼운 빌드에는 Small($8), 무거워지면 Medium($12) — USDC나 USDT로 결제하고(KYC 없음, 서류 없음), 약 60초 만에 root를 얻습니다. 그다음 이 페이지를 아래로 진행하면 몇 분 뒤 작업을 잡는 러너를 갖게 됩니다.

요금제 보고 VPS 주문 →