Chez onway, nous avons regroupé des scripts jusqu’ici dispersés pour NetBox, Observium et la génération de configurations réseau dans ontool, un outil en ligne de commande (CLI) commun pour les tâches d’ingénierie récurrentes. Une configuration centrale, un accès uniforme à plus de 40 types de données NetBox et une séparation claire entre l’interface d’utilisation et la logique métier permettent d’ajouter de nouvelles fonctions sans refonte. La commande ontool get commands affiche à tout moment l’ensemble des commandes disponibles. Résultat : moins de code dupliqué, une maintenance centralisée et une prise en main plus simple pour les nouveaux membres de l’équipe.

Comment des scripts isolés sont devenus une plateforme structurée et extensible.

Dans une équipe réseau et infrastructure, de petits scripts voient le jour en permanence. Quelqu’un a rapidement besoin d’une liste des adresses IP en double dans l’IPAM. Quelqu’un d’autre veut vérifier si les interfaces d’une VM concordent dans NetBox et dans le monitoring. Une autre personne encore écrit un script qui génère, à partir des données IPAM, la configuration réseau d’un nouvel environnement client. Chacun de ces scripts est utile et résout un problème concret de la personne qui l’a écrit.

Avec le temps, c’est précisément ce qui devient le véritable problème. Un script n’est utile que si l’on sait qu’il existe, où il se trouve, comment l’appeler et s’il est encore à jour. Chez nous, toute une série de scripts s’est ainsi accumulée : pour travailler avec notre IPAM (NetBox), pour des comparaisons avec notre monitoring (Observium) et pour générer des configurations réseau. Les membres de l’équipe ne savaient pas tous quels scripts existaient. Et les améliorations apportées à un endroit, par exemple à l’authentification auprès de NetBox, devaient dans le pire des cas être reportées dans plusieurs scripts.

C’est ainsi qu’est né ontool : une application CLI dans laquelle nous regroupons ces tâches récurrentes.

ontool s’installe comme n’importe quel autre outil et est ensuite disponible dans le terminal sous la forme d’une seule commande. Toutes les tâches récurrentes sont regroupées sous ce point d’entrée unique.

Lorsqu’on appelle ontool sans autre argument, il affiche un aperçu des domaines qu’il couvre actuellement :

• get – informations sur ontool lui-même et sur sa propre configuration
• check – détecter les écarts entre systèmes
• export – exporter des données depuis l’IPAM
• ipam – tâches liées à la gestion des adresses
• network – générer des configurations réseau
• oncloud – utilitaires pour nos environnements cloud
• sync – synchroniser les données entre systèmesdiagram – générer des diagrammes réseau

Chacun de ces domaines possède ses propres sous-commandes, par exemple ontool check observium-to-netbox ou ontool ipam duplicate-ips. Ce qui compte, ce n’est pas leur nombre, mais le principe : le point de départ de l’application ne contient aucune logique métier, il se contente de relier les domaines en un tout. Un nouveau domaine peut être ajouté sans toucher aux domaines existants.

Pour que plus personne n’ait à deviner ce qui existe, ontool get commands affiche la structure à tout moment. La commande la lit directement dans le programme en cours d’exécution et la présente sous forme d’arborescence dans le terminal. Il n’existe donc pas de liste séparée qui pourrait devenir obsolète : l’aperçu correspond toujours exactement à l’état réel de l’outil.

Une seule configuration pour toutes les commandes.
Presque chaque commande a besoin, tôt ou tard, d’accéder à NetBox ou à Observium, et donc d’une adresse et d’un jeton d’accès ou d’un mot de passe. Plutôt que de régler cette question à chaque fois, il existe un seul endroit qui lit ces informations au démarrage d’ontool. Si une valeur requise manque, ontool s’arrête immédiatement avec un message compréhensible, en indiquant par exemple quelle variable d’accès manque dans la configuration. Ainsi, aucune commande n’échoue au bout de quelques secondes avec un message d’erreur cryptique provenant d’un système tiers. Lorsque la suite de tests automatisés s’exécute, ontool bascule automatiquement sur une configuration de test distincte ; les tests ne peuvent donc jamais s’exécuter par erreur contre les systèmes de production. Chaque nouvelle commande utilise automatiquement la même configuration : pendant le développement, personne n’a à se demander d’où proviennent les identifiants.

Un accès uniforme à NetBox.
NetBox gère pour nous notamment les VLAN, les adresses IP, les plages réseau, les clients et les équipements, soit plus de 40 types de données au total. Sans structure commune, chaque script devrait savoir lui-même comment communiquer avec l’interface de NetBox et préparer lui-même les réponses. Dans ontool, cela est réglé à un seul endroit. Chaque type de données dispose des quatre mêmes requêtes : une entrée par son ID, une entrée par son nom, toutes les entrées, ou toutes les entrées correspondant à un filtre. Ces quatre requêtes sont définies une seule fois et réutilisées par tous les types de données. Si l’on demande par exemple un VLAN, le site ou le client associé est fourni en même temps. Le même principe s’applique à Observium, avec une mise en œuvre technique légèrement différente, car ce système renvoie toutes les valeurs sous forme de texte brut plutôt que sous forme de nombres ou de dates.

Une séparation claire entre interface, logique métier et accès aux systèmes.
Chaque commande est volontairement légère : elle reçoit l’entrée et la transmet à un autre endroit du programme, qui exécute la tâche proprement dite, par exemple « comparer une machine virtuelle entre NetBox et Observium ». Cette logique métier est écrite indépendamment de la ligne de commande. Elle peut ainsi être testée séparément et réutilisée dans plusieurs commandes, et chaque commande reste assez simple pour qu’on en comprenne l’effet d’un coup d’œil. Dans le journal des modifications d’ontool, cette séparation est consignée comme une opération de nettoyage délibérée.

C’est avec la commande qui génère la configuration réseau d’un client à partir des données de l’IPAM que l’intérêt de cette architecture apparaît le plus clairement. Elle repose sur un processus en plusieurs étapes :

1. ontool recherche le client indiqué dans NetBox.
2. Il charge tous les VLAN, plages réseau, adresses IP et autres données réseau associés, à l’aide des mêmes briques que celles utilisées par les autres commandes.
3. À partir de ces données, des fichiers de configuration prêts à l’emploi sont générés pour chaque site et chaque équipement (routeur, switch, pare-feu). Ils s’appuient sur des modèles qui définissent la structure d’une configuration.
4. Les fichiers de configuration sont enregistrés avec une copie des données brutes. Il reste ainsi possible de retracer l’état des données à partir duquel une configuration a été créée.
5. Enfin, ontool enregistre lui-même les fichiers dans le système de gestion de versions et les transfère sur le serveur.

Les configurations générées sont volontairement conservées à l’écart du code d’ontool, dans un dépôt distinct, lui aussi versionné. Ainsi, quiconque souhaite consulter l’historique des configurations clients n’a pas à parcourir l’historique de développement d’ontool, et inversement, le développement d’ontool reste exempt de données clients.

Pour un script isolé, cela représenterait un travail considérable : connexion propre à NetBox, préparation propre des données, connexion propre au système de gestion de versions. Dans ontool, tout cela existe déjà. La commande elle-même se résume pour l’essentiel à « récupérer les données », « remplir le modèle » et « appeler les briques existantes pour le reste ».

La commande ontool diagram create montre qu’il s’agit d’une architecture réutilisable et non d’une solution ad hoc. Elle suit le même principe que la génération de configurations : charger les données depuis NetBox, les insérer dans un modèle, enregistrer le résultat. Mais au lieu d’une configuration d’équipement, elle produit un fichier de diagramme qui peut être ouvert directement dans un logiciel de diagrammes. S’il manque des informations lors de l’appel, ontool les demande au moyen d’un bref dialogue dans le terminal.

Pour éviter qu’une modification ultérieure ailleurs dans le code ne casse ce comportement sans que personne ne s’en aperçoive, un test automatisé est prévu. Il fait générer un diagramme par ontool et le compare à une version de référence connue pour être correcte. Si le résultat diffère, le test échoue, avant qu’une modification défectueuse ne soit mise en service.

Ajouter une nouvelle fonctionnalité se résume pour l’essentiel à trois étapes : créer un emplacement pour la logique métier, enregistrer pour celle-ci une nouvelle branche dans l’arborescence des commandes, puis déclarer cette branche à un seul endroit du programme principal. Tout le reste suit automatiquement : la configuration, l’auto-description via ontool get commands et, si nécessaire, l’accès à NetBox ou à Observium.

Le journal des modifications montre que la structure est effectivement utilisée de cette manière : le socle de commandes existait dès le début, tandis que les domaines « check » et « diagram » ne sont venus s’ajouter que dans des versions ultérieures. L’éventail des commandes s’est enrichi au fil de plusieurs versions sans que la structure de base ait dû être modifiée.

Visibilité : l’arborescence complète et à jour des commandes peut être consultée à tout moment, générée directement à partir du programme.

Utilisation homogène : toutes les commandes suivent les mêmes règles pour l’appel, le texte d’aide et la sortie.

Maintenance centralisée : la connexion à NetBox et à Observium n’existe qu’une seule fois. Toute modification à cet endroit s’applique à toutes les commandes.

Processus reproductibles : ontool est construit sous forme de paquet versionné et testé automatiquement, au lieu de tourner comme un script isolé sur un ordinateur quelconque. Les configurations générées sont versionnées dans un dépôt dédié plutôt que stockées localement sur un ordinateur portable.

Intégration simplifiée : les nouveaux membres de l’équipe apprennent une seule ligne de commande avec une seule convention, au lieu de devoir se familiariser avec plusieurs scripts indépendants.

Les petits scripts constituent un bon point de départ, souvent le meilleur, pour se lancer dans l’automatisation : vite écrits, vite opérationnels, taillés sur mesure pour un problème précis. Les difficultés n’apparaissent que lorsqu’ils se multiplient et que toute une équipe doit les utiliser. Il ne suffit alors plus qu’un script fonctionne : encore faut-il pouvoir le trouver, le comprendre et s’y fier.

ontool est notre façon de transformer des automatisations isolées en un outil commun : une ligne de commande, une configuration, un accès réutilisable à NetBox et à Observium, et une structure dans laquelle les nouvelles tâches viennent s’intégrer au lieu de se développer en parallèle. L’outil ne sera jamais vraiment terminé. Il s’enrichit de chaque tâche récurrente que nous traiterons désormais à cet endroit plutôt que dans un nouveau script.