Een CI-runner bij Wolkra is een cloudserver in Frankfurt die je pipelinejobs uitvoert en per uur wordt gefactureerd. Zo draai je een snelle buildmachine alleen wanneer je hem nodig hebt, zonder kosten per minuut.
Runners krijgen volledige roottoegang, onbemeterd dataverkeer voor image pulls en artefacten, en Docker met één klik.
Waarom je eigen runners draaien
- Kies de hardware. Neem een CPU-geoptimaliseerd plan voor compileren of een geheugengeoptimaliseerd plan voor grote testsuites.
- Warme caches. Dependencies, Docker-lagen en buildcaches blijven tussen jobs op de runner staan.
- Geen prijs per minuut. Je betaalt voor de uren van de server, niet voor de minuten van elke job.
- Code blijft in Duitsland. Broncode, secrets en artefacten worden verwerkt op servers in Frankfurt. Zie EU VPS en AVG.
- Privétoegang. Runners in een privénetwerk kunnen interne databases en stagingservers bereiken zonder die bloot te stellen.
Ondersteunde runners
Alles wat op Linux draait, werkt op een KVM-VPS, bijvoorbeeld:
- GitLab Runner, ook in combinatie met onze GitLab-app
- Self-hosted GitHub Actions-runners
- Forgejo-, Gitea- en Woodpecker-runners
- Jenkins-agents, Buildkite-agents en vergelijkbare
De meeste runners gebruiken Docker om jobs te isoleren. De Docker-app installeert Docker CE met Compose, dus een nieuwe runner heeft alleen nog de runnersoftware en een registratietoken nodig.
De juiste grootte kiezen
CPU-geoptimaliseerd
Meer vCPU per GB voor builds, rekenwerk en drukke API's.
| Pakket | vCPU | RAM | Schijf | Dataverkeer | Per uur | Maandelijks maximum |
|---|---|---|---|---|---|---|
| C1 | 2 | 2 GB | 30 GB | Onbemeterd | €0.0112 | €6.99 |
| C2 | 4 | 4 GB | 40 GB | Onbemeterd | €0.0224 | €13.99 |
| C3 | 8 | 8 GB | 70 GB | Onbemeterd | €0.0432 | €26.99 |
- Linting, unittests, kleine builds: een Standard-plan (s).
- Compileren, bundelen, containerimages bouwen: een CPU-geoptimaliseerd plan (c).
- Grote testsuites, databases in tests, JVM-builds: een geheugengeoptimaliseerd plan (m).
Houd de CPU- en geheugengrafieken in de gaten terwijl jobs draaien en vergroot de server als builds op resources wachten. Zie monitoring.
Patronen die goed werken
Runner die altijd aan staat
Eén of twee runners die altijd beschikbaar zijn. Eenvoudig, met altijd warme caches. Goed voor kleine teams met een gestage stroom commits.
Extra runners bij pieken
Houd één basisrunner aan en voeg er meer toe tijdens drukke uren of op releasedagen. Omdat er per begonnen uur wordt gefactureerd, met de maandprijs als maximum, kost een runner die vier uur bestaat ook vier uur. Verwijder hem daarna.
Autoscaling met de API
Gebruik de REST API met een token per project om runnerservers aan te maken als de jobwachtrij groeit en ze te verwijderen als die leeg is. Geef cloud-init user data mee die de runner bij de eerste start installeert en registreert, of maak runners aan vanaf een voorbereide snapshot, zodat ze direct klaarstaan.
Tips voor tokens:
- Geef de autoscaler een eigen project, zodat zijn token alleen runnerservers kan aanraken.
- Gebruik een lees/schrijftoken met vervaldatum en een IP-allowlist voor de machine waarop de autoscaler draait.
Geïsoleerde runners voor gevoelige jobs
Draai deploymentjobs op een aparte runner in een privénetwerk, zonder publiek IP. Een NAT-gateway geeft hem uitgaande toegang om images en pakketten op te halen, en niets op het internet kan hem rechtstreeks bereiken.
Checklist voor beveiliging
- Gebruik SSH-sleutels en schakel inloggen met wachtwoord uit.
- Koppel een gratis firewall zonder inkomende poorten behalve SSH. Runners maken meestal alleen uitgaande verbindingen.
- Draai geen onbetrouwbare pipelines uit publieke forks op runners die productiesecrets bevatten.
- Houd de runnersoftware en het besturingssysteem bijgewerkt, of vervang runners regelmatig door een vers image.
- Geef runnerservers labels, zodat één set firewallregels voor allemaal geldt.
Opslag voor caches en artefacten
Buildcaches groeien snel. Koppel een blokopslagvolume van 10 GB tot 10 TB voor caches of een lokale registry, en vergroot het online als het volloopt. Volumes kunnen voor je worden geformatteerd en gemount.
Tips voor caching
Houd een gedeelde dependencycache op de runner, hergebruik Docker-lagen door Dockerfiles te ordenen van minst naar meest veranderend, en ruim oude images volgens een schema op.
Waarom Wolkra voor CI
- Facturering per uur met een prepaid tegoed en zonder contracten. Zie facturering per uur.
- Onbemeterd dataverkeer op gedeelde poorten tot 10 Gbit/s, met fair use. Base images, dependencies en artefacten lopen niet op tot een bandbreedterekening. Zie netwerk.
- Lage latency in heel Europa vanuit het midden van Europa, dicht bij Europese Git-hosts en registries.
Voor bredere containerworkflows, zie Docker-hosting en ontwikkelomgevingen.
Voeg je eerste runner toe
Maak een account aan, start de Docker-app in Frankfurt en registreer hem binnen een paar minuten bij je CI-systeem.
Veelgestelde vragen
Welke CI-systemen kan ik op Wolkra draaien?
Elke runner die op Linux werkt, waaronder GitLab Runner, self-hosted GitHub Actions-runners, Forgejo- en Gitea-runners, Woodpecker en Jenkins-agents.
Waarom CI-runners zelf hosten?
Je kiest zelf de grootte van de machine, houdt caches warm tussen jobs, vermijdt kosten per minuut en houdt broncode en build-artefacten op servers in Duitsland.
Kunnen runners automatisch op- en afschalen?
Ja, met je eigen tooling. De REST API maakt servers aan en verwijdert ze, dus een script of autoscaler kan runners toevoegen als de wachtrij groeit en ze daarna weer weghalen.
Worden image pulls en uploads van artefacten gefactureerd?
Nee. Dataverkeer is onbemeterd met fair use, dus het ophalen van base images en het uploaden van artefacten kost niets per GB.
Moet een runner op dezelfde server staan als GitLab?
Beter op een eigen server. Builds gebruiken veel CPU en geheugen, en door ze te scheiden blijft GitLab snel reageren.