Runners CI auto-hébergés chez Wolkra

Un runner CI chez Wolkra est un serveur cloud à Francfort qui exécute les tâches de vos pipelines, facturé à l'heure : vous faites tourner une machine de build rapide seulement quand vous en avez besoin, sans facturation à la minute.

Les runners bénéficient d'un accès root complet, d'un trafic non mesuré pour les images et les artefacts, et de Docker en un clic.

Pourquoi faire tourner vos propres runners

• Choisissez le matériel. Une offre optimisée CPU pour les compilations, une offre optimisée mémoire pour les grosses suites de tests.
• Des caches chauds. Dépendances, couches Docker et caches de build restent sur le runner d'une tâche à l'autre.
• Pas de tarif à la minute. Vous payez les heures du serveur, pas les minutes de chaque tâche.
• Le code reste en Allemagne. Sources, secrets et artefacts sont traités sur des serveurs à Francfort. Voir VPS européen et RGPD.
• Un accès privé. Des runners dans un réseau privé peuvent atteindre bases de données internes et serveurs de préproduction sans les exposer.

Runners pris en charge

Tout ce qui tourne sous Linux fonctionne sur un VPS KVM, par exemple :

• GitLab Runner, y compris avec notre application GitLab
• Les runners GitHub Actions auto-hébergés
• Les runners Forgejo, Gitea et Woodpecker
• Les agents Jenkins, les agents Buildkite et équivalents

La plupart des runners utilisent Docker pour isoler les tâches. L'application Docker installe Docker CE avec Compose : un nouveau runner n'a plus besoin que du logiciel runner et d'un jeton d'enregistrement.

Dimensionner les runners

• Lint, tests unitaires, petits builds : une offre Standard (s).
• Compilation, bundling, construction d'images de conteneurs : une offre optimisée CPU (c).
• Grosses suites de tests, bases de données dans les tests, builds JVM : une offre optimisée mémoire (m).

Surveillez les graphiques CPU et mémoire pendant l'exécution des tâches et redimensionnez quand les builds attendent des ressources. Voir supervision.

Les schémas qui fonctionnent bien

Runner permanent

Un ou deux runners toujours disponibles. Simple, avec des caches toujours chauds. Idéal pour les petites équipes aux commits réguliers.

Runners de renfort

Gardez un runner de base et ajoutez-en d'autres aux heures chargées ou les jours de release. La facturation se faisant par heure entamée avec un plafond mensuel, un runner qui existe quatre heures coûte quatre heures. Supprimez-le ensuite.

Autoscaling avec l'API

Utilisez l'API REST avec un jeton limité au projet pour créer des serveurs runners quand la file de tâches grossit et les supprimer quand elle se vide. Passez des user data cloud-init qui installent et enregistrent le runner au premier démarrage, ou créez les runners à partir d'un instantané préparé pour qu'ils démarrent prêts à l'emploi.

Conseils pour les jetons :

• Donnez à l'autoscaler son propre projet, pour que son jeton ne puisse toucher qu'aux serveurs runners.
• Utilisez un jeton en lecture/écriture avec expiration et une liste d'IP autorisées pour la machine qui fait tourner l'autoscaler.

Runners isolés pour les tâches sensibles

Exécutez les tâches de déploiement sur un runner séparé, dans un réseau privé, sans IP publique. Une passerelle NAT lui donne un accès sortant pour télécharger images et paquets, et rien sur Internet ne peut l'atteindre directement.

Checklist sécurité

1. Utilisez des clés SSH et désactivez la connexion par mot de passe.
2. Attachez un pare-feu gratuit sans aucun port entrant hormis SSH. Les runners n'établissent généralement que des connexions sortantes.
3. N'exécutez pas de pipelines non fiables provenant de forks publics sur des runners qui détiennent des secrets de production.
4. Maintenez à jour le logiciel runner et le système, ou remplacez souvent les runners à partir d'une image neuve.
5. Posez des labels sur les serveurs runners, pour qu'un même jeu de règles de pare-feu s'applique à tous.

Stockage pour caches et artefacts

Les caches de build grossissent vite. Attachez un volume de stockage en bloc de 10 GB à 10 TB pour les caches ou un registre local, et agrandissez-le à chaud lorsqu'il se remplit. Les volumes peuvent être formatés et montés pour vous.

Astuces de cache

Gardez un cache de dépendances partagé sur le runner, réutilisez les couches Docker en ordonnant vos Dockerfiles du moins modifié au plus modifié, et nettoyez régulièrement les anciennes images.

Pourquoi Wolkra pour la CI

• Facturation à l'heure sur solde prépayé, sans engagement. Voir facturation à l'heure.
• Trafic non mesuré sur des ports jusqu'à 10 Gbit/s partagés, avec usage raisonnable. Images de base, dépendances et artefacts ne se transforment pas en facture de bande passante. Voir réseau.
• Faible latence dans toute l'Europe depuis le centre de l'Europe, à proximité des hébergeurs Git et registres européens.

Pour des workflows de conteneurs plus larges, voir hébergement Docker et environnements de développement.

Ajoutez votre premier runner

Créez un compte, lancez l'application Docker à Francfort et enregistrez-la auprès de votre système de CI en quelques minutes.