Dawap : développer des applications, puis les faire vivre
Dawap conçoit des applications web, des intégrations et des outils métier. Une fois livrés, ces systèmes continuent d’évoluer : les versions changent, les conteneurs sont remplacés et les ressources des serveurs sont sollicitées différemment. L’exploitation prolonge donc le travail de développement.
Cockpit Ops est un produit interne construit pour cette réalité. Ses utilisateurs sont les administrateurs Dawap qui suivent l’infrastructure et certaines opérations. Le serveur, l’application déployée et son conteneur doivent rester reliés dans la lecture, même lorsqu’on passe d’une vue du parc à un détail technique.
Le périmètre présenté ici décrit les usages et les choix du produit. Les visuels sont des illustrations de fonctionnement, sans identité ni donnée issue d’une infrastructure réelle.
Les questions d’exploitation auxquelles répondre
Un serveur peut afficher une charge importante sans indiquer immédiatement quelle application examiner. Une liste de conteneurs décrit leur état, mais ne suffit pas à comprendre leur consommation au cours de la journée. Une valeur ancienne peut aussi sembler actuelle si sa date n’est pas visible.
Le besoin à traiter était de réunir ces lectures : savoir ce qui tourne sur un hôte, retrouver les stacks associées, examiner leurs ressources et replacer une observation dans le temps. Sans ce contexte, une décision d’exploitation risque de s’appuyer sur une vue partielle.
Les objectifs du cockpit sont de rendre le parc lisible, de conserver une mémoire des consommations et d’encadrer les opérations disponibles. Le produit permet de parcourir ces trois niveaux sans confondre une mesure, un diagnostic et une commande.
Construire le cockpit par capacités successives
La première capacité est la supervision de l’hôte : identité, système, CPU, mémoire et systèmes de fichiers. L’inventaire Docker enrichit ensuite cette lecture avec les stacks, leurs conteneurs, leurs états et leurs consommations. Les deux ensembles conservent leurs dates de collecte.
L’historisation ajoute un recul que l’instantané ne donne pas. Elle enregistre le CPU et la RAM des hôtes, des stacks et des conteneurs pour permettre des consultations sur différentes périodes. Le pilotage de certains conteneurs vient compléter le parcours, avec des accès et une exécution séparés de la supervision.
Cette progression garde chaque capacité utile par elle-même. Une collecte Docker indisponible ne doit pas faire disparaître les mesures valides de l’hôte. Une courbe doit rester consultable pendant l’examen d’une situation. Une demande d’intervention doit disposer de son propre suivi.
Passer du parc à la ressource concernée
La vue des serveurs rassemble les dernières mesures et les informations de collecte. Recherches, filtres et tris permettent de cibler un environnement ou de parcourir les ressources selon leur consommation. L’opérateur retrouve ensuite les stacks observées sur l’hôte, puis les conteneurs qui les composent.
Une stack regroupe les conteneurs d’un projet Compose ou d’un espace de noms détecté sur le serveur. Son total CPU ou mémoire provient des membres observés au même instant. Les conteneurs sans rattachement restent accessibles dans l’inventaire ; ils ne deviennent pas artificiellement une stack.
L’état d’exécution, la santé Docker et la fraîcheur de collecte restent trois informations distinctes. Un conteneur démarré ne prouve pas que son application répond correctement. De même, une collecte ancienne ne prouve pas une panne de l’application. Cette distinction aide l’équipe à choisir la vérification suivante.
Garder la mémoire du CPU et de la RAM
Les fiches serveur, stack et conteneur disposent de deux courbes synchronisées. La sélection de période, le survol, le zoom et la navigation au clavier permettent d’examiner les mêmes instants sur le CPU et la mémoire. Les dernières valeurs, moyennes et pics observés complètent la lecture.
Le détail récent est conservé sept jours par défaut. Des agrégats de dix minutes, d’une heure et d’une journée prolongent l’historique sans expiration automatique. Les longues périodes utilisent une résolution adaptée pour limiter le volume de données transmis à l’interface. Leur conservation suppose de dimensionner et de sauvegarder le stockage.
L’historique suit l’identité de la ressource. Un conteneur supprimé conserve une série consultable dans les archives ; un nouveau conteneur portant le même nom reçoit une identité distincte. Cela évite de présenter deux exécutions différentes comme une seule continuité.
Une période sans mesure crée un trou dans la courbe. Le produit ne reconstitue pas le passé avant l’activation de la collecte et ne remplace pas l’inconnu par zéro. Un tableau et un export CSV permettent de prolonger l’analyse des valeurs disponibles. Les disques disposent aujourd’hui d’une lecture de leur occupation, distincte de ces historiques CPU et RAM.
Collecter sans faire dépendre les pages des serveurs distants
La consultation du cockpit lit des données déjà collectées. Elle ne lance pas une connexion distante à chaque ouverture de page. La collecte travaille en arrière-plan, puis alimente les dernières observations et l’historique. L’équipe peut ainsi consulter les informations conservées même lorsqu’une collecte échoue.
Les collecteurs Linux relèvent les ressources de l’hôte. Des sondes dédiées complètent l’inventaire et les consommations Docker. Le cockpit central est conteneurisé ; dans l’installation actuelle, la récupération des données repose sur des accès SSH dédiés et des opérations de lecture restreintes.
Les mesures de l’hôte restent utiles lorsque les applications sont installées directement sur Linux. Les détails propres aux stacks et conteneurs nécessitent Docker. Ce découpage ouvre des périmètres différents sans attribuer à une application classique les métriques d’un conteneur qui n’existe pas.
Confirmer la cible, puis suivre le résultat d’une action
Certaines situations nécessitent une opération après diagnostic. Cockpit Ops propose le démarrage, l’arrêt et le redémarrage de conteneurs autorisés. Le parcours identifie la cible et l’action, demande une confirmation puis conserve l’auteur, les dates et le résultat de la demande.
Le serveur et le conteneur sont revérifiés avant exécution. Les cibles protégées et les opérations incompatibles avec l’état observé sont refusées. L’authentification renforcée et la confirmation de l’opération participent à un même parcours de contrôle, tandis que les accès de pilotage restent distincts des accès de supervision.
Une demande peut être en attente, en cours, réussie, échouée ou de résultat inconnu. Si la confirmation se perd après l’envoi, le système ne répète pas automatiquement la commande. L’opérateur doit examiner la situation ; une revue conserve l’incertitude originale plutôt que de la transformer en réussite.
Ce périmètre reste volontairement délimité : aucun terminal libre ni déploiement applicatif n’est exposé. La réussite d’un redémarrage confirme l’opération attendue, pas à elle seule la santé de l’application. Les mesures suivantes restent issues de la collecte datée.
Tester les cas d’échec et organiser la mise en service
Les vérifications du produit couvrent les calculs de ressources, les valeurs absentes, les dates de collecte, la déduplication des mesures et la conservation des agrégats. Les parcours d’intervention examinent aussi les refus d’autorisation, les demandes répétées et les résultats incertains.
Les tests automatiques utilisent des doubles pour les connexions externes et une base de test séparée pour les traitements persistants. Ils ne redémarrent pas d’applications réelles. La recette de collecte et la validation d’un parcours d’intervention sont des opérations distinctes, avec un périmètre choisi.
La chaîne de livraison associe tests, analyse statique, contrôles d’architecture et analyse des images. Les versions de production reposent sur des images identifiées et des migrations explicites. La conservation durable des mesures fait aussi de la sauvegarde et de la restauration de la base un sujet d’exploitation du cockpit lui-même.
Ce que le cockpit permet au quotidien
Pour examiner une consommation, l’équipe dispose désormais d’un parcours commun : retrouver le serveur, parcourir les stacks, ouvrir le conteneur et consulter sa période d’activité. La date des mesures accompagne la navigation. Les courbes permettent de vérifier si la valeur remarquée se retrouve dans les observations précédentes.
Après le remplacement d’un conteneur, son historique conservé reste consultable. Lorsqu’une opération est demandée, son résultat dispose d’un suivi propre. L’inventaire courant et le journal des commandes répondent à des questions différentes, tout en restant rattachés à la ressource concernée.
Le bénéfice concret est cette continuité entre inventaire, consommation, historique et intervention. Elle donne à l’opérateur des éléments pour préparer son diagnostic et partager ses observations. Le produit ne transforme pas automatiquement une corrélation dans une courbe en cause certaine d’un incident.
ÉVOLUTION À VENIR / NON DISPONIBLE
Les CVE : une évolution à venir
Le suivi des vulnérabilités connues fait partie des évolutions envisagées pour Cockpit Ops. L’objectif serait de rapprocher les composants et les images utilisés des CVE concernées, puis de rendre les points à traiter accessibles depuis les ressources du parc.
Ce module reste à développer. Le rapprochement des vulnérabilités, leur priorisation et le suivi des corrections ne sont pas des fonctions disponibles dans le cockpit actuel. Les sources d’analyse, le périmètre couvert et les conditions de mise à jour devront être définis avant sa mise en service.
Cette perspective prolonge le même principe de lecture : rattacher une observation à une ressource et à une date, puis laisser l’équipe décider de l’action appropriée. Elle ne constitue ni un audit de sécurité complet ni une promesse de correction automatique.
Un produit interne, un socle pour d’autres environnements
Cockpit Ops relie aujourd’hui la supervision des serveurs, l’inventaire Docker, l’historique CPU/RAM et certaines commandes encadrées. Sa valeur tient au contexte conservé entre ces usages : savoir quelle ressource on consulte, de quand date l’information et ce qu’une opération a effectivement confirmé.
Une adaptation pour une autre organisation commence par ses environnements Linux, ses contraintes d’accès, ses responsabilités et les données à conserver. L’installation actuelle reste accompagnée : les accès, les comptes et les paramètres sont à préparer pour une instance dédiée. Un agent Docker avec enregistrement automatique n’est pas livré à ce jour.
Découvrez le produit Cockpit Ops et son périmètre actuel. Pour un besoin spécifique, notre travail de conception d’applications métier sur mesure permet de définir le cockpit, les connexions et les parcours utiles à vos équipes.
Cofondateur de Dawap · Développement, intégration et exploitation d’applications métier.