L’objectif de ce groupe de travail était le prototypage d’une application “cahier de suivi de production”.

Le projet “cahier de suivi de production” peut être vu comme un journal de bord dans lequel sont concentrés les logs et les commandes saisies sur une flotte de serveurs, d’où le choix du nom de code : Admirallog.

Admirallog

L’idée est d’obtenir un flux d’événements formatés à l’aide d’une syntaxe “markdown”.

Ces événements sont tagués afin de permettre un filtrage de l’affichage et une recherche “full-text”.

Un client en ligne de commande permettra ensuite de créer des entrées directement depuis le serveur (en mode interactif ou non) avec possibilité d’enregistrer des sessions shell.

Les événements ne sont ni supprimables, ni modifiables.

L’outil est accessible soit au travers d’une interface spécifique, soit directement dans l’application Zéphir en cours de réalisation. Il pourra éventuellement être accessible dans d’autre applications (gestion de parc, gestion de tickets, …).

La configuration de l’outil s’effectue au travers d’un modèle de filtres. Celui-ci peut être hérité de Zéphir, ou décrit pour un usage hors périmètre EOLE.

Les événements pertinents

Les événements sont générés par l’activité des serveurs de façon automatisée mais il est possible d’en insérer dans le flux :

  • journaux d’activités : logs Elasticsearch, logger, …
  • commandes exécutées
  • commentaires saisis directement  au travers d’une commande shell dédiée
  • événements saisis par un opérateur humain

Deux modes de fonctionnement sont possibles pour récupérer les informations:

  • mode actif : le service systemd-journal-updload du serveur client, pousse les informations vers le serveur Admiralllog
  • mode passif : le serveur Admirralllog récupère les données sur le serveur passif

Les composants à étudier

Plusieurs composants ont été identifiés afin de mettre en œuvre les différents éléments de ce projet :

Le périmètre abordé lors du hackathon

Durant les deux jours du hackathon, l’attention s’est portée sur deux composants du système :

  • un client pour la création d’entrées de trois types dans le journal d’exploitation (enregistrement de session, texte formaté en markdown  ;
  • l’application de consultation de ces entrées.

Le transport est assuré par systemd-journal. Le format d’enregistrement de session est celui de asciinema.

Architecture de la plateforme de test

Cette architecture n’a pas été mise à profit dans son intégralité lors de la restitution du hackathon. Un problème de configuration de systemd-journal-remote a impliqué une démonstration entre l’émetteur et le récepteur sur le même serveur.

Côté émetteur

Le client développé permet de produire assez simplement un événement à enregistrer dans le journal d’exploitation. Ces événements peuvent être  des messages courts, des textes plus conséquents saisis dans un éditeur de texte, ou l’enregistrement d’une session shell complète. Chaque événement peut être accompagné de tags permettant leur filtrage ultérieur lors d’une consultation.

La version 0.1 créée à l’issue du hackathon utilise assez naïvement les commandes asciinema et vim pour le côté création de l’entrée et system-cat pour la transmission.

L’émetteur en version 0.1 : https://forge.cadoles.com/bbohard/caplo/src/v0.1

asciinema

Le format asciinema propose l’enregistrement d’une session en chronométrant les saisies clavier. Le fichier au format JSON produit peut être interprété pour jouer à nouveau la session.

La version disponible dans les dépôts d’Ubuntu au moment du hackathon ne disposait pas de l’enregistrement en local de la session mais uniquement d’export directement vers un serveur asciinema. C’est la version du PPA ppa:zanchey/asciinema qui a été utilisée.

system-cat

La commande system-cat permet de transmettre les entrées de journaux via systemd-journal.

Côté récepteur

L’application développée pour l’affichage des entrées du journal d’exploitation propose une présentation adaptée au deux types de contenu envoyés par le client :

  • une interprétation du markdown pour les entrées textuelles
  • un lecteur asciinema pour les enregistrements de session

Conclusion

Quoique l’un des éléments fondamentaux du dispositif, la transmission sécurisée entre deux serveurs via systemd-journal, n’ait pas pu être testé sur le moment, le bilan de ce groupe de travail est plutôt positif. Il est apparu que les fonctionnalités basiques sont assez faciles à implémenter en s’appuyant sur des projets comme systemd-journal et asciinema. Tous les points n’ont cependant pas pu être abordés.

Depuis la fin du hackathon, des améliorations ont été apportées au client et la configuration de systemd-journal a pu être testée avec succès. Le manque d’une gestion des ACL ne permet toutefois pas d’envisager un déploiement dans un contexte de production dans l’état actuel des composants du système.