Un récit de terrain · Incus · First access
Cinq composants
sur notre propre matériel
Les cinq composants qu’achète l’offre First access, déployés sur un petit cluster Incus à nous, sans compte cloud nulle part, mis au travail par un pipeline pendant une heure, puis démontés.
Le code
Un endroit pour le code, de quoi le construire
La première chose dont un projet a besoin, c’est d’un endroit pour son code et d’une machine qui le construit. La plateforme déploie GitLab et un runner, et le runner s’enregistre de lui-même auprès du GitLab voisin.
Son jeton d’enregistrement n’est jamais écrit dans un fichier de configuration. Le pipeline de déploiement le dépose dans la machine du runner une fois celle-ci créée, et le runner démarre déjà en ligne.
Le runner appartient au projet, sur une machine du cluster, et non à un pool partagé ailleurs. Rien de ce que le projet construit ne quitte le matériel que son propriétaire maîtrise.
Le pipeline
Construire, calculer, tester, enregistrer
Chaque commit lance le même pipeline. Il compile un petit programme, puis fait un peu d’arithmétique sur le numéro de build : pair ou impair, et premier ou non.
Il teste contre le PostgreSQL du projet et y enregistre le build. À côté des tests tournent un job d’endurance de quatre minutes et un contrôle de connexion qui échoue de temps en temps, comme les contrôles des vrais projets. Le pipeline tolère l’échec de ce contrôle, si bien que le build passe quand même.
L’enregistrement
Chaque job laisse une ligne
Quand un job se termine, quel que soit son résultat, il écrit une ligne dans une base prévue à cet effet, à côté des données de l’application dans le même PostgreSQL.
Un dernier job écrit le résultat du pipeline : le numéro de build, sa parité, s’il est premier, et combien de jobs ont réussi ou échoué.
Le dashboard de la base est celui qu’une équipe surveillerait en production : connexions, transactions, lignes écrites et lues.
Le travail
Des jobs qui tournent, des jobs qui échouent, tout est visible
Les commits arrivent toutes les une à deux minutes, si bien que le runner est rarement inactif. Son dashboard montre les jobs en cours à chaque instant, leur durée, et les échecs au moment où ils surviennent.
GitLab a son propre dashboard à côté, si bien qu’un build lent peut être rattaché au runner ou au serveur sans deviner.
Les échecs viennent du contrôle de connexion instable. Il échoue au hasard sur environ deux builds sur cinq, ce qui donne aux panneaux d’échecs quelque chose de réel à montrer.
Les métriques
Un seul stockage, toutes les machines y rendent compte
VictoriaMetrics est le cinquième composant, et c’est lui qui donne son intérêt à Grafana. Chaque machine lui envoie ses métriques d’hôte dès sa naissance, avec celles du service qu’elle fait tourner.
Grafana lit ce seul stockage pour chaque dashboard, si bien que la base, le serveur de code, le runner et le stockage lui-même sont surveillés au même endroit.
Personne n’a eu à l’ajouter. La collecte des métriques fait partie du déploiement de chaque machine, ce n’est pas un composant auquel penser.
Le bilan de la journée
- Composants
- 5 : quatre conteneurs, GitLab en machine virtuelle
- Infrastructure
- Un cluster Incus à nous, sans compte cloud
- Pipelines
- 38 sur main, 35 réussis, dont 11 malgré l’échec du contrôle instable
- Jobs
- 215, tous sur le runner du projet
- Secrets dans la configuration
- Aucun : déposés dans chaque machine par le pipeline