78 articles tagués avec « DevOps »

Prometheus mesure ce que les services exposent d'eux-mêmes : consommation CPU, latence des requêtes reçues, erreurs comptées par l'application. Ces métriques internes ne disent rien d'un reverse proxy qui ne route plus, d'un certificat expiré ou d'un DNS qui ne résout plus : si aucune requête n'atteint l'application, aucun compteur d'erreurs n'augmente. Une supervision externe, dite boîte noire, interroge les services comme le ferait un client et constate directement leur disponibilité. Uptime Kuma remplit ce rôle mais se configure dans son interface web : les sondes vivent dans sa base de données, hors de tout dépôt, sans revue ni historique. Gatus déclare ces mêmes sondes dans un fichier YAML versionné. Cet article fait suite à l'article Alertmanager et décrit Gatus, son modèle de configuration, son déploiement sous Docker Compose et Kubernetes, et les pièges rencontrés en pratique.

Sur un cluster Kubernetes, chaque application exposée par l'ingress controller pose la même question d'authentification : certaines n'en ont aucune (tableau de bord, interface de supervision, outil interne), d'autres gèrent leurs propres comptes et ignorent ceux des autres. Un fournisseur d'identité unique, interrogé par Traefik en forward-auth pour les premières et en OpenID Connect par les secondes, ramène ces décisions à un seul annuaire. Authentik remplit ce rôle avec deux capacités absentes d'une configuration minimale : l'inscription en libre-service et les connexions par fournisseur externe (GitHub, LDAP, SAML). Son déploiement sur Kubernetes ajoute des pièges propres à Traefik en mode CRD : priorité des routers, références entre namespaces et route de callback de l'outpost.

Sur un cluster on-premise sans provisionneur dynamique, le stockage persistant repose souvent sur des PersistentVolumes local ou hostPath : un répertoire d'un nœud précis, déclaré à la main. Le pod qui consomme le volume est épinglé à ce nœud ; si celui-ci tombe, aucun pod ne peut être replanifié ailleurs, puisque les données n'existent nulle part ailleurs. Longhorn, projet de la CNCF, fournit à la place des volumes bloc répliqués de façon synchrone sur plusieurs nœuds, exposés à Kubernetes par un driver CSI.

Un chart Helm qui référence image.tag: latest, un workflow qui reconstruit l'image puis lance helm upgrade : le schéma fonctionne en apparence, jusqu'au jour où les pods tournent toujours sur l'ancienne image après un déploiement réussi, ou où un helm rollback ne ramène pas la version précédente. Les contournements classiques (annotation aléatoire rollme, option --recreate-pods) forcent le redémarrage des pods mais ne rendent pas le déploiement traçable. Cet article décrit l'alternative : un tag d'image immuable sha-<commit> produit par la CI et transmis au chart, complété par une empreinte de configuration qui ne redémarre les pods que lorsque quelque chose a réellement changé.

Collecter des métriques ne suffit pas : un disque saturé ou un conteneur qui redémarre en boucle n'est découvert qu'au prochain coup d'œil sur un dashboard. Une chaîne d'alerting mal conçue produit cependant l'effet inverse : cinq messages pour un seul incident, des déclenchements sur des pics légitimes, un canal si bruyant qu'il finit ignoré. Cet article fait suite à l'introduction à Prometheus et décrit la chaîne complète : règles d'alerte, traitement par Alertmanager, conception de règles robustes et notifications push.

Dans un déploiement Docker Compose, l'état persistant des services (bases de données, fichiers utilisateurs, configuration générée) vit dans des volumes nommés, sous /var/lib/docker/volumes. La commande docker volume sait créer, inspecter, lister et supprimer ces volumes, mais n'offre aucune fonction d'export ni de sauvegarde. Sans mécanisme dédié, la perte du disque hôte, une suppression accidentelle (docker compose down -v) ou une migration applicative ratée emportent les données. offen/docker-volume-backup comble ce manque avec un conteneur qui archive, chiffre et expédie périodiquement le contenu des volumes vers un stockage distant.

Outils de sauvegarde, backends de state Terraform, applications qui stockent des fichiers : une part croissante des logiciels d'infrastructure parle l'API S3. Hors d'un cloud public, il faut donc un serveur qui expose cette API sur du matériel maîtrisé. Ceph RGW suppose un cluster Ceph complet, et l'édition communautaire de MinIO a été restreinte. Garage, développé par l'association Deuxfleurs, se situe à l'autre extrémité : un binaire Rust unique, conçu pour des machines modestes réparties sur plusieurs sites, qui implémente le sous-ensemble de S3 utilisé par la majorité des clients.

Sur un hôte Docker, certains services consomment des ressources en permanence pour un usage de quelques minutes par semaine : une application JVM embarquant un moteur de conversion bureautique occupe environ 1 Go de RAM au repos, une application web accompagnée de sa base PostgreSQL et de son cache Redis mobilise trois conteneurs pour une consultation mensuelle. Kubernetes traite ce cas par le scale-to-zero ; avec Docker seul, aucun mécanisme natif n'arrête un conteneur inactif ni ne le redémarre à la requête suivante. Sablier comble ce manque : il arrête un groupe de conteneurs après une période sans trafic et le redémarre à la première requête entrante, en s'intégrant au reverse proxy.

Un hôte unique qui fait tourner une vingtaine de services Docker Compose, un dépôt Git qui contient un dossier par stack : la question du déploiement se pose dès la deuxième modification. Se connecter en SSH, faire un git pull, relancer docker compose up -d dans le bon dossier fonctionne, mais l'opération est manuelle, oubliable et non tracée. Cet article décrit un workflow GitHub Actions qui déploie, à chaque push sur la branche principale, uniquement les stacks modifiées, sans orchestrateur et sans agent installé sur l'hôte.

Un fichier Compose qui référence une vingtaine d'images vieillit sans bruit : nouvelles versions, correctifs de sécurité, changements de comportement, rien dans le dépôt ne le signale. Vérifier les registres à la main ne tient pas dans la durée ; utiliser latest rend les mises à jour invisibles et non reproductibles. Renovate automatise cette veille : il analyse le dépôt, interroge les registres et ouvre une pull request par mise à jour disponible, que la CI valide avant fusion manuelle ou automatique.