Hébergement de runners CI
Réponse
Les runners CI auto-hébergés exécutent vos pipelines de build sur des serveurs que vous contrôlez, plutôt que sur le pool partagé d'un fournisseur. Un plan Incognito VPS VECTOR à 14 $ par mois surpasse généralement un runner hébergé, tout en éliminant la facturation à la minute et les files d'attente.
| Scénario | Minimum |
|---|---|
| Petit projet | 2 vCPU, 4 Go de RAM |
| Monorepo typique | 6 vCPU, 16 Go de RAM |
| Compilation lourde (Rust, C++) | 16 vCPU, 64 Go de RAM |
| Cache de couches Docker | 140 Go+ NVMe |
L'arithmétique est généralement décisive
Les minutes de CI hébergée semblent bon marché jusqu'à ce que vous les comptiez. Une équipe qui exécute quelques centaines de builds par mois sur des runners hébergés à 2 cœurs dépense généralement plus que le coût d'un VPS dédié à 6 cœurs, et obtient des builds plus lents pour son argent, car les runners hébergés sont des machines modestes sous contention.
L'autre économie est une question de temps plutôt que d'argent. Un runner auto-hébergé n'a pas de file d'attente : votre tâche démarre dès que vous poussez. Sur un pool hébergé occupé, attendre plusieurs minutes pour un runner est normal, et ce délai affecte chaque développeur, chaque push.
La mise en cache est là que réside la véritable accélération
Un NVMe local persistant change l'économie de la CI plus que le nombre de cœurs bruts. Les couches Docker, les registres Cargo, node_modules, les caches Gradle et ccache survivent entre les exécutions sur un runner auto-hébergé, alors qu'un runner hébergé démarre propre et télécharge tout à nouveau.
Pour un grand projet Rust ou C++, cela représente souvent une réduction de cinq à dix fois du temps de build réel, et c'est entièrement gratuit.
Isolation, car les runners exécutent du code arbitraire
Un runner auto-hébergé exécute ce qui se trouve dans le pipeline, ce qui pour un dépôt public signifie ce qu'un contributeur met dans une pull request. N'attachez jamais un runner auto-hébergé à un dépôt public sans exécution éphémère et isolée.
Utilisez des runners éphémères dans des conteneurs ou des machines virtuelles à courte durée de vie, donnez au runner uniquement les identifiants dont il a besoin, et placez-le sur un serveur sans rien d'autre dessus. Une machine à 14 $ par projet est une assurance bon marché contre un pipeline compromis atteignant le reste de votre infrastructure.
Questions fréquentes
01 Quel plan pour un runner CI ?
VECTOR (4 vCPU, 8 Go) pour un projet typique ; BASTION (6 vCPU, 16 Go) pour un monorepo ou une compilation lourde. Le cache NVMe persistant compte plus que le nombre de cœurs pour la plupart des pipelines.
02 Est-ce compatible avec GitHub Actions ?
Oui. Enregistrez la machine en tant que runner auto-hébergé et ciblez-la avec runs-on. GitLab, Forgejo, Woodpecker et Drone fonctionnent tous de la même manière.
03 Un runner auto-hébergé est-il sûr pour les dépôts publics ?
Non, sans isolation éphémère. Une pull request peut exécuter du code arbitraire sur le runner. Utilisez des conteneurs éphémères ou des VMs jetables, et n'accordez jamais d'identifiants dont le pipeline n'a pas besoin.
04 Quelle est l'accélération ?
Typiquement deux à quatre fois sur la puissance de calcul brute, et cinq à dix fois sur les pipelines gourmands en cache, car les couches Docker et les caches de dépendances persistent entre les exécutions au lieu d'être téléchargés à nouveau.
Liés