Hopwise Labs
Hopwise Labs
Demander un pilote
Étape 06 · Source de vérité

NetBox, source de vérité : ce qu’il tient, ce qu’il laisse

NetBox est un logiciel libre qui sert de source de vérité à une infrastructure réseau et physique : sites, baies, câblage, alimentation, circuits, adresses IP. Il décrit l’état voulu, pas l’état observé : il ne découvre pas, ne supervise pas et ne pousse pas de configuration. Il reste juste avec un auteur par donnée et un rapprochement régulier.

Installer NetBox ne coûte rien, puisqu’il est publié en logiciel libre (open source). Ce qui coûte, c’est de le tenir juste.

Qu’est-ce que NetBox, et que veut dire « source de vérité » ?

Sa page d’introduction le dit en une phrase : « NetBox vise à représenter l’état voulu d’un réseau, par opposition à son état opérationnel » (traduit de l’anglais). L’état voulu est celui que l’équipe a décidé, pas celui observé sur le terrain. C’est le sens de « source de vérité » dans sa documentation : un référentiel vérifié par des personnes, d’où les autres outils tirent leurs données.

Publié en 2016 sous licence Apache 2, le projet existe en version communautaire, gratuite et auto-hébergée, et en versions Cloud et Enterprise vendues par NetBox Labs. Une instance de démonstration publique permet de l’essayer. Sa documentation pose deux principes :

  • l’import automatique de l’état réel y est fortement déconseillé ;
  • toute donnée doit être vérifiée par une personne avant d’y entrer, pour alimenter ensuite la supervision et le provisionnement en confiance.

Que modélise NetBox pour un opérateur d’infrastructure ?

NetBox couvre le physique, le réseau et le rattachement aux clients dans un même modèle de données. Les objets utiles à un opérateur se regroupent ainsi :

Domaine Objets NetBox Question à laquelle il répond
Implantation Régions, groupes de sites, sites, emplacements (étage, salle), baies, réservations d’unités Où poser un équipement, et qu’est-ce qui est déjà promis ?
Équipements Types d’équipements, modules, interfaces, ports console, ports avant et arrière De quoi est fait cet équipement, et qu’est-ce qui est libre dessus ?
Câblage Câbles entre composants, panneaux de brassage via les ports avant et arrière Par où passe ce lien, de bout en bout ?
Alimentation Tableaux électriques, départs, ports d’alimentation, PDU et prises Sur quel départ cet équipement est-il branché, principal ou redondant ?
Circuits Fournisseurs, circuits, terminaisons A et Z, réseaux de fournisseurs Quel lien loué arrive dans quelle salle, et chez qui ?
Adressage (IPAM) Agrégats, préfixes, plages, adresses IP, VRF, VLAN, numéros d’AS Quelle adresse est libre, et quel préfixe est saturé ?
Virtualisation Clusters, machines virtuelles, interfaces virtuelles Sur quel cluster tourne cette machine, et pour quel client ?
Clients Locataires (tenants) et groupes de locataires, contacts À quel client appartient cette baie, ce port, ce préfixe ?

Deux détails comptent en exploitation. Les composants d’un équipement sont copiés depuis son type au moment de sa création : modifier le type ensuite ne change pas les équipements existants. Et chaque objet ne peut appartenir qu’à un seul locataire ; une ressource partagée entre clients ne doit être affectée à aucun.

Pour l’espace, l’énergie et la capacité restante d’une salle, voir notre guide sur le DCIM en datacenter : NetBox y tient le registre, pas la mesure.

Que ne fait pas NetBox ?

NetBox ne découvre pas, ne supervise pas et ne pousse pas de configuration. Sa documentation exclut cinq usages de son périmètre : la supervision, le serveur DNS, le serveur RADIUS, la gestion de configuration et la gestion des installations techniques.

Il n’interagit pas directement avec les équipements ; il sert ses données à d’autres outils. Trois versions de l’infrastructure coexistent :

Version Où elle vit Ce qu’elle sait
Voulue NetBox Ce qui devrait exister, où, pour quel client
Découverte Scans, interrogation des équipements, tables des commutateurs Ce qui répond réellement, avec sa configuration
Supervisée Outil de supervision Ce qui est surveillé, dans quel état

Leurs écarts sont des informations à traiter, pas une panne.

Que faut-il pour faire tourner NetBox ?

NetBox est une application web en Python, construite sur Django, qui s’appuie sur PostgreSQL pour les données et sur Redis pour le cache et les files de tâches. Sa documentation décrit une installation sur Ubuntu, derrière nginx ou Apache. Le projet communautaire netbox-docker fournit une image en conteneurs. L’instance elle-même s’exploite : version épinglée, mises à jour suivies, sauvegarde de la base, restauration testée.

Comment tenir NetBox juste dans la durée ?

NetBox reste juste si chaque donnée a un seul auteur et si un rapprochement régulier le compare à la découverte et à la supervision.

Qui écrit quoi. Un auteur par type d’objet, écrit dans une table courte :

Donnée Auteur Moment
Baies, réservations, câblage physique Équipe d’installation À la clôture de l’intervention
Préfixes, adresses, VLAN Équipe réseau Avant la mise en service
Circuits et terminaisons Équipe réseau ou achats À la livraison du lien
Locataire d’un objet Personne qui valide la commande À la réservation

Le rapprochement. Comparez à intervalle fixe NetBox avec ce que voient les commutateurs, la supervision et les PDU. Chaque écart devient une tâche avec un propriétaire. La méthode générale est détaillée dans notre guide CMDB : pourquoi elle est fausse et comment la tenir à jour.

Les mécanismes de NetBox. Ils se combinent :

  • champs personnalisés : ils ajoutent des attributs aux objets sans toucher au schéma et apparaissent dans l’interface et l’API ;
  • scripts personnalisés : exécutés à la demande ou planifiés, ils contrôlent aussi l’intégrité des données, par exemple que chaque équipement actif a assez d’alimentations raccordées ;
  • règles d’événement : à la création, la modification ou la suppression d’un objet, elles lancent un script, envoient un webhook ou notifient un utilisateur ;
  • API : lecture, création, modification et suppression des objets, jetons restreints à la lecture si besoin, et une API GraphQL. La bibliothèque Python pynetbox, la collection Ansible netbox.netbox (inventaire dynamique) et un fournisseur Terraform maintenu par E. Breuninger la consomment ;
  • journal des modifications et notes : chaque changement garde l’auteur, l’heure et l’état avant et après ; les notes (journaling) expliquent pourquoi.

Un script de contrôle lancé sans enregistrement ne modifie rien : il produit la liste des écarts sans écrire.

Qu’est-ce qui reste à la main autour de NetBox ?

Le travail entre les outils reste à la main : NetBox tient le référentiel, mais les demandes, les tickets et les avis aux clients vivent ailleurs. Trois flux le montrent :

  1. les demandes clients : une demande de baie ou de port arrive par courriel ou par le portail client. Quelqu’un vérifie la disponibilité dans NetBox, réserve, ouvre le ticket, puis met à jour après intervention ;
  2. les tickets : un incident sur un équipement se traite dans l’outil de tickets. Retrouver les clients touchés demande de suivre à la main les câbles, les circuits et les locataires dans NetBox ;
  3. les avis de maintenance : un fournisseur annonce une coupure sur un circuit. Il faut remonter aux équipements et aux clients concernés, puis rédiger les avis.

L’enchaînement crée les écarts : réservation oubliée, câble posé mais non saisi, client oublié dans un avis. C’est ce que Hopwise Labs construit autour de la source de vérité : des rapprochements par règles, un agent seulement sur le résidu ambigu, et une personne qui valide avant toute modification dans NetBox.

Quand faut-il un plugin ou un outil maison ?

Un plugin s’impose quand il faut de nouveaux objets dans NetBox ; un outil maison, quand le besoin porte sur le flux entre plusieurs outils. Avant l’un ou l’autre, vérifiez qu’un champ personnalisé ou un script ne suffit pas.

Besoin Réponse adaptée Ce qu’il faut savoir
Un attribut de plus sur un objet existant Champ personnalisé Pas de code, visible dans l’interface et l’API
Un contrôle ou une création en série Script personnalisé Exécutable à la demande ou planifié
Réagir à un changement dans un autre outil Règle d’événement et webhook Traité en tâche de fond par NetBox
Un objet que NetBox ne connaît pas (commande, contrat, intervention) Plugin Ajoute modèles et vues ; ne peut pas modifier les modèles de base
Un flux qui traverse tickets, courriels, supervision et NetBox Outil maison qui appelle l’API À maintenir : documentation, tests, plus d’une personne qui le connaît

En résumé

NetBox décrit l’état voulu d’une infrastructure ; il ne découvre pas, ne supervise pas et ne pousse pas de configuration. Il reste juste avec un auteur par donnée, un rapprochement régulier et des corrections validées par une personne. Le travail à la main se situe entre NetBox et les autres outils.

Questions fréquentes

NetBox peut-il servir d’IPAM ?

Oui. Il gère agrégats, préfixes, plages, adresses IP, VRF, VLAN et numéros d’AS, et calcule automatiquement le taux d’occupation de chaque préfixe. Son API renvoie les préfixes et les adresses encore libres d’un préfixe. Il tient le plan d’adressage sans interagir avec les équipements : d’autres outils l’appliquent.

NetBox découvre-t-il les équipements tout seul ?

Non. Selon sa documentation, NetBox n’interagit pas directement avec les équipements et décrit l’état voulu du réseau, pas son état opérationnel. L’import automatique de l’état réel y est fortement déconseillé : les données doivent être vérifiées par une personne avant d’y entrer.

NetBox remplace-t-il la supervision ?

Non. La supervision fait partie des usages que la documentation de NetBox exclut explicitement, avec le serveur DNS, le serveur RADIUS, la gestion de configuration et la gestion des installations techniques. NetBox fournit en revanche à la supervision la liste de ce qu’elle doit surveiller.

NetBox peut-il servir de DCIM ?

Pour la partie registre, oui : sites, salles, baies, réservations d’unités, tableaux électriques, départs, prises et câbles. Il ne mesure ni la consommation, ni la température, ni les alarmes. Ces relevés viennent d’autres outils et se rapprochent avec lui.

Faut-il un plugin pour gérer les clients dans NetBox ?

Pas pour les rattacher : le modèle des locataires (tenants) représente un client ou une entité interne, et la plupart des objets peuvent lui être affectés. Un plugin devient utile quand il faut suivre des objets que NetBox ne modélise pas, comme une commande ou un contrat.

Sources