agence 9 juin 2025

Ajouter des fenêtres de maintenance à Komodo

Nous améliorons les outils open source que nous utilisons au quotidien. Dernier exemple : des fenêtres de maintenance ajoutées à Komodo et fusionnées en amont, pour suspendre les alertes pendant les interventions planifiées.

Ajouter des fenêtres de maintenance à Komodo

Nous exploitons une partie de notre infrastructure avec Komodo, un outil open source de build et de déploiement basé sur Docker. Son monitoring déclenche des alertes dès qu'un serveur ou un conteneur dérape, ce qu'on attend précisément de lui, sauf pendant une maintenance planifiée : là, il alerte sur des problèmes que nous avons nous-mêmes provoqués et que nous connaissons déjà. Couper toutes les alertes le temps d'une intervention n'est pas une solution : on finit par en oublier une, et par manquer une vraie panne. Nous avons donc ajouté à Komodo de vraies fenêtres de maintenance, et la fonctionnalité est aujourd'hui fusionnée dans le projet en amont.

Le principe : pour chaque serveur, on définit des créneaux pendant lesquels Komodo suspend ses alertes. Trois types de fenêtres, tenant compte du fuseau horaire :

  • Quotidienne : un créneau qui revient chaque jour, par exemple pour une fenêtre de sauvegarde ou un redéploiement nocturne.
  • Hebdomadaire : un créneau récurrent le même jour chaque semaine.
  • Ponctuelle : une intervention unique, planifiée à une date et une heure précises.

Le tout se gère depuis un onglet Maintenance dédié dans la configuration du serveur, avec une table pour créer, modifier et suivre les fenêtres. Pendant une fenêtre active, les alertes de ce serveur sont mises en sourdine ; en dehors, le monitoring reprend normalement.

Sous le capot

La fonctionnalité traverse toute la stack de Komodo : la logique d'alerte côté serveur en Rust, les entités partagées et leurs types (Rust et TypeScript), et l'interface React avec le nouvel onglet et sa table de gestion. Environ deux mille lignes réparties sur une douzaine de fichiers, où la planification et la gestion des fuseaux horaires font le gros du travail.

Pourquoi nous l'avons envoyé en amont

Comme pour nos autres contributions, nous aurions pu garder cette fonctionnalité dans notre fork. Nous ne le faisons pas : un fork privé s'éloigne un peu plus du projet à chaque nouvelle version, jusqu'à devenir ingérable. Fusionnée en amont, la fonctionnalité est maintenue par le projet, validée par sa CI et livrée à tous ses utilisateurs, nous compris, à chaque mise à jour.

C'est aussi ce que veut dire héberger et exploiter chez nous : l'infrastructure qui fait tourner vos instances Odoo et vos applications repose sur des outils que nous améliorons activement, plutôt que de simplement les subir. Vous cherchez un partenaire qui maîtrise vraiment votre hébergement ? Écrivez-nous à contact@eclypsys.ch.

Autres actualités
VOTRE PROJET

Un projet similaire en tête ?

Discutons de vos besoins et construisons ensemble la solution adaptée.