88 articles tagués avec « DevOps »

Une application qui expose des métriques à Prometheus, écrit ses logs pour Loki et envoie des traces à un outil d'APM utilise souvent trois bibliothèques, trois formats et trois agents différents. Changer d'outil de traces oblige alors à réinstrumenter le code, et rien ne relie le log d'une erreur à la requête qui l'a produite. OpenTelemetry part de ce constat : il définit une seule manière de produire, de décrire et de transporter la télémétrie, indépendante de l'outil qui la stockera. Cet article présente ce que couvre le projet, les briques qui le composent et les deux notions qui rendent les données exploitables d'un outil à l'autre, la ressource et les conventions sémantiques.

Sur un poste de développement, la deuxième construction d'une image est rapide : le démon Docker garde les couches de la première, et seules les instructions dont les entrées ont changé sont rejouées. Un runner de CI éphémère n'a pas cette mémoire. Chaque job démarre avec un démon vide, télécharge les images de base, réinstalle toutes les dépendances et recompile tout, même quand seul un fichier de code a changé. BuildKit, le moteur de construction de Docker, sait exporter son cache hors du démon et le relire au build suivant ; reste à choisir où le ranger et comment l'empêcher de s'accumuler.

Dans une organisation de plusieurs dizaines de dépôts, la protection de la branche principale (revue obligatoire, historique linéaire, interdiction du force push) finit configurée à la main, dépôt par dépôt, avec autant de variantes que de personnes qui l'ont réglée. Les rulesets de GitHub remplacent la protection de branche classique par un objet nommé, décrit en JSON et manipulable par l'API, ce qui permet de versionner la règle et de la réappliquer à l'identique partout.

Un runner de CI auto-hébergé qui doit démarrer des conteneurs (valider une stack Docker Compose, lancer des tests d'intégration, construire une image) a besoin d'un démon Docker. Lui donner le socket de l'hôte revient à lui donner la main sur tous les conteneurs de la machine, production comprise. Un démon dédié, lancé dans un conteneur docker:dind (Docker-in-Docker), cantonne les jobs à leurs propres conteneurs, volumes et réseaux. Cette isolation n'est toutefois réelle que si le démon dédié n'est pas lui-même laissé ouvert aux conteneurs qu'il exécute, et si le répertoire de travail partagé avec lui ne contient aucun secret.

Certains tests ne tiennent pas dans un runner de CI. Dans le cas traité ici, un logiciel robotique est validé par une simulation physique headless : chaque scénario démarre un simulateur, joue une situation et enregistre ce que le logiciel a fait, et une campagne complète occupe une dizaine de CPU pendant plus d'une heure. Ces campagnes tournaient déjà sur un cluster Kubernetes, sous forme de Jobs lancés à la main depuis un service web, si bien qu'une régression pouvait atteindre la branche principale sans que personne ne pense à lancer un run. Les brancher sur les pull requests pose plusieurs questions : que bloquer quand les résultats sont bruités, comment donner à la CI le droit de créer des Jobs sans lui donner plus, comment partager une capacité limitée, et comment récupérer un verdict. Cet article décrit les choix faits pour chacune.

En EKS Auto Mode, AWS gère les nœuds, le réseau des pods, le stockage et les load balancers. La supervision des applications reste en revanche à la charge du client : le modèle de responsabilité partagée d'Auto Mode le dit explicitement. Un cluster fraîchement créé n'envoie à CloudWatch aucune métrique de pod et aucune ligne de log applicatif. Un pod qui redémarre en boucle ou une API qui renvoie des erreurs 500 ne laissent alors de trace que dans kubectl, tant que les pods existent encore. Sur un cluster auto-hébergé, ce rôle revient à Prometheus et Loki. Sur AWS, le service natif est CloudWatch. Cet article décrit comment y raccorder un cluster EKS, et les réglages par défaut à corriger dès l'installation.

Promtail, l'agent qui pousse les logs vers Loki, est en fin de vie depuis le 2 mars 2026 : il ne reçoit plus de correctifs. Un cluster qui collecte ses logs avec lui doit changer d'agent, et la migration ne doit casser ni les dashboards ni les requêtes qui reposent sur ses labels. Le même cluster lance souvent un agent par signal : Promtail pour les logs, des exporters pour les métriques, un OpenTelemetry Collector dès que des traces apparaissent. Grafana Alloy, le remplaçant désigné de Promtail, est une distribution de l'OpenTelemetry Collector qui collecte métriques, logs, traces et profils dans un seul processus. Cet article décrit son modèle de configuration, la collecte des logs des pods et des événements Kubernetes, et ce qu'il faut reprendre de Promtail pour une bascule sans rupture.

Un serveur qui plante sans laisser de trace ne donne aucune piste de diagnostic. Dans le cas traité ici, un serveur domestique sous Ubuntu, sans écran ni clavier, s'est arrêté trois fois en quelques jours ; à chaque fois, le journal système s'interrompait net, sans message d'erreur, et la machine restait figée jusqu'à un appui sur le bouton d'alimentation. Trois problèmes se posent alors : capturer la cause du crash, faire redémarrer la machine sans intervention, et être prévenu qu'un redémarrage a eu lieu. Cet article décrit la chaîne qui répond aux trois, kdump, sysctl de panic, watchdog matériel et alerte Prometheus, puis la façon de la valider avant le prochain crash.

Un snapshot de volume ne suffit pas à sauvegarder une base de données. Dans le cas traité ici, une application web stocke ses données dans MariaDB et ses fichiers joints sur un second volume, tous deux sur Longhorn avec des snapshots quotidiens. Restaurer le snapshot du volume de MariaDB revient à redémarrer la base après une coupure de courant : InnoDB sait le plus souvent rejouer son journal, mais rien ne garantit que l'état obtenu corresponde à un instant où l'application était cohérente, et le snapshot n'est lisible que par Longhorn. Un dump logique, produit par la base elle-même, donne une copie cohérente, portable et lisible. Cet article décrit un CronJob qui produit ce dump avec l'archive des fichiers joints, vérifie le résultat avant de le publier et gère sa propre rotation, sur le même principe que la sauvegarde des volumes Docker.

Un Grafana configuré à la main garde dans sa base un état que rien ne trace. Dans le cas traité ici, l'inventaire d'un Grafana en service depuis la création du cluster a relevé une datasource pointant vers un serveur MySQL décommissionné, une autre créée pour un essai et jamais utilisée, des dashboards modifiés au fil des besoins sans trace de qui avait changé quoi ni pourquoi, et un écran d'affichage dont les liens dépendaient de dashboards qu'une fausse manipulation pouvait casser. Surtout, l'ensemble vivait dans la base SQLite de Grafana, sur un unique volume persistant : sa perte effaçait des mois de travail, sans aucune copie. Les manifests du cluster étaient tous versionnés et relus ; Grafana faisait exception. Cet article décrit comment faire de Git la source de ses dashboards et datasources, et les pièges de la transition.