Hvorfor køre min egen runner i stedet for GitHub-hostet?

Tre reelle grunde: dine egne afhængigheder og din værktøjskæde bagt ind (ingen geninstallering af dem hver kørsel), adgang til private ressourcer som et internt register eller en database, og kontrol over maskinen — dens størrelse, dens caches, dens netværk. Hvis GitHub-hostede minutter og et rent miljø passer dig, bliv på dem. Self-host, når du specifikt har brug for en af de tre.

Er det sikkert at bruge en self-hostet runner?

På et privat repo, ja. På et offentligt repo, nej — aldrig. Et workflow kører vilkårlig kode fra den, der udløser det, og på et offentligt repo kan en fremmeds pull request køre deres kode på din runner. GitHubs egen dokumentation siger det samme. Hold self-hostede runnere til private repos, eller accepter, at du overrækker din boks til internettet.

Hvor meget CPU og RAM har en runner brug for?

Afhænger fuldstændig af dit build. Et typisk compile-og-test-job er komfortabelt med 2 kerner og 4-8 GB — Small eller Medium her. Tunge builds (store native kompileringer, store Docker-images, hukommelses-sultne testsuiter) vil have mere, og du bør dimensionere til dit faktiske job, ikke et gæt. Se én rigtig kørsel, og du vil vide det.

Kan én runner håndtere flere repos?

En runner kan registreres til en organisation og opsamles af flere repos, ét job ad gangen som standard. For mere parallelisme, kør flere runnere — hver er sin egen systemd-tjeneste. Bare hold dem alle på private repos.

Skal jeg give jer et ID?

Nej. E-mail for at tilmelde dig, USDC eller USDT for at betale. Ingen dokumenter, root på omkring et minut.

At køre en self-hostet GitHub Actions-runner på en VPS

GitHub-hostede runnere er en fin standard. Du holder op med at have brug for dem i det øjeblik, et build vil have noget, de ikke har — dit private pakke-register, en specifik værktøjskæde-version, du er træt af at geninstallere hver kørsel, en database på dit eget netværk, eller bare mere kontrol over maskinen. Det er, når en self-hostet runner på en VPS tjener sit brød.

Denne guide får en kørende ordentligt: installeret, registreret, i live under systemd, og — den del folk får forkert — sikker. Lad os starte med den sidste, fordi det er den del, der bider.

Den ene sikkerhedsregel

Et GitHub Actions-workflow kører vilkårlig kode — hvad end der er i workflow-filen, og hvad end den kode trækker ind. På dit eget repo er det din kode, og det er fint. På et offentligt repo kan en pull request fra en fremmed køre deres kode på din runner. Det er ikke en fejl; det er, hvordan CI virker. GitHubs egen dokumentation siger det ligeud: brug ikke self-hostede runnere med offentlige repositorier.

Så reglen er simpel og ikke til forhandling: self-hostede runnere er til private repos. Hvis dit repo er offentligt, brug GitHub-hostede runnere og kom videre. Alt nedenfor antager et privat repo.

Hvad en runner har brug for fra boksen

Det afhænger af buildet, og du bør dimensionere til dit frem for et tal fra en side:

Et typisk compile-og-test-job — 2 kerner og 4-8 GB er komfortabelt. Small ($8, 4 vCPU / 4 GB) eller Medium ($12, 6 vCPU / 6 GB) dækker de fleste af disse.
Tungere builds — store native kompileringer, store Docker-image-builds, hukommelses-sultne testsuiter — vil have mere hovedrum. Se én rigtig kørsel (htop mens den bygger) og dimensionér til, hvad du faktisk ser, ikke til håb.

Disk betyder også noget: build-caches, Docker-lag og klonede repos lægger op. Hold øje med det og beskær.

1. Forbered boksen

Opret en ikke-root-bruger til runneren — GitHubs installer nægter at køre som root alligevel, og du vil have det sådan:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # kun hvis dine builds genuint har brug for sudo

Installér, hvad end dine builds har brug for — en sprog-værktøjskæde, Docker, build-værktøjer. For eksempel, hvis dine jobs bygger containere:

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

2. Download og registrér runneren

I dit repo (eller din org) på GitHub, gå til Settings → Actions → Runners → New self-hosted runner. GitHub giver dig de nøjagtige download-kommandoer og et registrerings-token (det er kortlivet — tag det friskt). Som runner-brugeren:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# brug den nøjagtige URL GitHub viser dig for dit OS/arch:
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 beder om et runner-navn, labels og en arbejdsmappe — standarderne er fine at starte med. Labels er, hvordan dit workflow retter sig mod denne runner (runs-on: self-hosted).

3. Kør den som en systemd-tjeneste

Runneren leveres med en hjælper, der installerer en systemd-tjeneste for dig — brug den, så runneren overlever genstarter og genstarter ved fejl. Stadig som runner-brugerens installation, men tjeneste-kommandoerne har brug for root:

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

Det registrerer actions.runner.* som en systemd-unit, der kører som runner-brugeren og starter ved boot. Logs går til journald:

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

Tilbage på GitHubs Runners-side viser din runner nu Idle — grøn prik. Peg et workflow mod den:

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

Push, og jobbet kører på din boks.

4. Hold den ren

En self-hostet runner genbruger sit filsystem mellem jobs — det er hastigheds-gevinsten (varme caches) og fodgeværet (efterladt tilstand). To vaner holder den sund:

Beskær regelmæssigt. Docker især — docker system prune på en cron, eller disken fyldes stille med døde lag.
Gem ikke hemmeligheder på boksen. Brug GitHub Actions-hemmeligheder, injiceret per-kørsel, ikke filer der ligger i runnerens hjem. Hvis runneren kompromitteres, går alt på disken med den.

Hvis du har brug for et virkelig rent miljø per job, kør hvert job inde i et container-trin — runneren bliver, jobbets rod gør ikke.

Hvornår man skal self-hoste, ærligt

Self-host, når du har brug for din egen værktøjskæde bagt ind, adgang til private netværks-ressourcer eller kontrol over maskinen. Bliv på GitHub-hostede runnere, når et rent, engangs-miljø og deres minutter passer dig — det er genuint enklere, og enklere er noget værd. Og aldrig, på et offentligt repo, self-host. Den ene er ikke en præference.

Hvis en privat-repo-runner er, hvad du har brug for: vælg et abonnement — Small ($8) til lettere builds, Medium ($12) når de bliver tungere — betal i USDC eller USDT (ingen KYC, ingen dokumenter), og du vil have root på omkring 60 sekunder. Arbejd derefter ned ad denne side, og du vil have en runner, der opsamler jobs et par minutter senere.

Se abonnementet og bestil en VPS →