CrestVPS

self hosted github runner

CI and build runners

Des builds qui se terminent avant que vous n'ayez changé d'onglet.

Ce que nous déploierions

44,03 €/mois

62,90 €30% annuel

Les minutes CI hébergées sont comptées, mises en file d'attente et lentes, et la courbe de coûts devient moche dès qu'une équipe est productive. Une paire d'instances à cœurs dédiés avec NVMe rapide surpassera la plupart des niveaux hébergés et coûtera un montant fixe chaque mois, peu importe la fréquence de vos pushs. La virtualisation imbriquée est incluse, donc les suites de tests Docker-in-Docker et basées sur KVM fonctionnent sans contournement.

Pourquoi cette configuration

TORQUE vous donne le nombre de cœurs, le NVMe Gen5 vous donne le débit d'artefacts, et la virtualisation imbriquée ne coûte rien. Enregistrez les runners contre votre forge et supprimez le plan hébergé.

Ce que nous déploierions

PlanTORQUE T2
vCPU8 (dedicated)
RAM32 GB
Stockage400 GB
ImageUbuntu Server 24.04 LTS

Dimensionnement

Deux cœurs dédiés et 4 Go par job concurrent est le minimum ; les langages compilés veulent 4 cœurs et 8 Go. Un nœud TORQUE de 32 cœurs exécute donc 8 jobs lourds ou environ 14 légers, pas 32. Le disque scratch compte plus que l'un ou l'autre — prévoyez 30-50 Go par job concurrent sur NVMe pour les couches d'images, les arbres de dépendances et la sortie de build. Ajoutez un cœur par nœud si les jobs nécessitent une virtualisation imbriquée. Le temps d'attente en file, pas la durée des jobs, vous indique quand ajouter un nœud.

Virtualisation imbriquée, et quand vous en avez besoin

La plupart des CI fonctionnent bien dans un conteneur. Trois cas nécessitent un vrai hyperviseur dans l'invité : tester des images de VM et cloud-init, exécuter des émulateurs Android ou embarqués avec accélération KVM, et tout job où une pull request non fiable exécute du code qui ne doit pas atteindre le runner. TORQUE expose SVM à l'invité, donc KVM fonctionne dans votre VPS et l'émulateur tourne à vitesse native plutôt que via l'émulation logicielle, ce qui fait environ un ordre de grandeur de différence sur les suites de tests Android. Le coût est un cœur de surcharge pour l'hyperviseur externe et un disque légèrement plus lent dans l'invité interne. Prévoyez les deux.

Le chemin des artefacts est généralement le goulot d'étranglement

Profilez un pipeline lent et l'étape de compilation est rarement la plus grande barre. Tirer les images de base, restaurer les caches, téléverser les artefacts et pousser le résultat représentent la plupart du temps réel dans les builds typiques. Trois correctifs, par ordre de retour : gardez un cache pull-through de registre sur le même VLAN privé pour que les couches arrivent sur le réseau local plutôt que sur l'internet public ; mettez scratch sur NVMe pour que le déballage des couches ne soit pas limité par la recherche ; et rendez la clé de cache précise, pour restaurer ce dont vous avez besoin au lieu d'une archive monolithique. Les cœurs denses Bergamo sont bon marché. Attendre sur le réseau ne l'est pas.

Ce qui va de travers

  • Empiler overlayfs sur overlayfs pour Docker-in-Docker. Les pilotes overlay imbriqués sont lents et corrompent parfois les couches. Utilisez un périphérique de bloc dédié dans le job, ou exécutez le builder via KVM imbriqué à la place.
  • Ne jamais nettoyer. Les images dangling, les caches de build et les volumes obsolètes remplissent le NVMe scratch en quelques semaines, et le premier symptôme est un build qui échoue sur une étape qui a fonctionné pendant un an. Nettoyez sur un minuteur, pas sur l'échec.
  • Laisser le transfert de cache dépasser le temps de build. Un cache de dépendances de 3 Go extrait et poussé par job peut coûter plus cher que de compiler à partir de zéro. Mesurez les deux et gardez le cache sur le même VLAN privé que les runners.

Réglez la machine

  • Tout le resteVirtualisation imbriquée · Inclus
  • Planification CPUPinned physical cores · 9 €
  • Stockage et chiffrementZFS with hourly snapshots · 7 €