Supervision

Deux services auto-hébergés accompagnent mes projets : GlitchTip, qui recueille les erreurs des applications, et SonarQube, qui analyse le code et la couverture de quatre dépôts de Sanu à chaque passage sur leur branche principale.

Rôle: Auteur unique des deux dépôts d’installation
Période: Septembre 2026
État: En service. En service ; SonarQube relié à quatre dépôts, GlitchTip à un site
Technologies: GlitchTip 6, SonarQube Community, PostgreSQL 17, Docker Compose, nginx, GitLab CI
Dépôts: Deux

Figure 1. Les deux services partagent le serveur des environnements de recette, ce qui explique la plupart des choix décrits ici.

Contexte

Les erreurs d’une application en service et la qualité de son code se suivent d’ordinaire par des services en ligne. GlitchTip et SonarQube Community en offrent l’équivalent à héberger soi-même : le premier parle le protocole de Sentry, de sorte que toute bibliothèque qui accepte une adresse Sentry lui envoie ses rapports sans modification, et le second reçoit les analyses lancées par les pipelines.

Problème

Ces deux services s’installent sur un serveur qui porte déjà les environnements de recette et deux exécuteurs de pipelines, sans mémoire d’échange. SonarQube, qui fait tourner trois machines virtuelles Java et un moteur de recherche, peut à lui seul épuiser la mémoire et entraîner l’arrêt d’un service voisin. L’installation manipule par ailleurs des jetons et un mot de passe d’administration, qu’un script écrit sans précaution laisse dans la liste des processus ou dans un journal.

Réponse apportée

Un budget de mémoire et une victime désignée

SonarQube est plafonné à trois gigaoctets et à deux processeurs. Son score d’élimination est en outre relevé, de façon que le noyau, si la mémoire vient tout de même à manquer, arrête SonarQube plutôt qu’un environnement de recette.

# The server also carries the staging stacks and two docker runners allowed 3 GB per
# job, with no swap. The cap keeps SonarQube (three JVMs at 512 MB heap each, plus
# Elasticsearch off-heap) inside a known budget, and the OOM score makes the kernel
# pick SonarQube rather than a staging container if memory still runs out.
mem_limit: 3g
cpus: 2
oom_score_adj: 500
# Lets Elasticsearch close its indices cleanly on stop.
stop_grace_period: 2m

Extrait 1. Limites imposées au conteneur de SonarQube, avec leur raison.

Des secrets qui ne passent ni par la ligne de commande ni par une adresse

Les scripts d’installation transmettent les identifiants à curl par un fichier de configuration lu sur l’entrée standard : ils n’apparaissent ni parmi les arguments, que la liste des processus afficherait, ni dans une adresse, que le journal d’accès enregistrerait. Le mot de passe d’administration est généré sur le serveur et n’y est jamais affiché, et chaque dépôt analysé reçoit son propre jeton, que le script remplace à chaque exécution.

Un déploiement rejouable

Le déploiement de SonarQube peut être relancé sans précaution, y compris après un changement de version : le contrôle de santé tient une migration en attente pour un état sain, ce qui laisse le script la déclencher lui-même. Le greffon d’analyse du langage Dart est épinglé par sa version et par son empreinte, puis copié dans le volume du service et non dans l’image, un volume nommé n’étant rempli depuis l’image qu’à sa création.

Un contournement mesuré

Les contrôles de disponibilité de GlitchTip recevaient un refus de la part d’un site placé derrière un réseau de diffusion. Sept requêtes comparées ont montré que la réponse dépendait de la présence d’un jeu d’en-têtes et non de leur contenu. Le correctif reprend les réglages d’origine et n’en retire qu’une clé, pour le seul processus concerné, afin qu’une montée de version conserve tout le reste ; le fichier indique lui-même à quelle condition il pourra être supprimé.

Limites et perspectives

GlitchTip n’a aujourd’hui qu’un seul site pour client, les interfaces de Sanu ayant prévu leur raccordement sans l’avoir fait. Aucune sauvegarde n’est planifiée pour l’un ou l’autre service : elle se fait à la main avant une montée de version, et reste sur le même serveur.

SonarQube Community n’analyse qu’une branche par projet, ce qui écarte l’analyse des demandes de fusion, et l’analyse du langage Dart dépend d’une reprise communautaire d’un greffon que son auteur n’entretient plus. Depuis septembre 2026, un seuil de qualité non atteint bloque enfin le déploiement en recette des quatre dépôts : le service que le noyau doit sacrifier le premier se trouve désormais sur le chemin de ces livraisons, contradiction qu’il conviendra de lever en lui donnant sa propre machine.

Retour aux autres projets