De RVTools à NetBox : Construire une source de vérité infra sans perdre la cartographie applicative

Introduction

Dans beaucoup d’environnements SI, la documentation d’infrastructure finit par se disperser : un peu dans vCenter, un peu dans des fichiers Excel, un peu dans des schémas, un peu dans la tête des équipes.

C’est encore plus vrai dans un contexte où l’on doit composer avec des applications critiques, des flux inter-applicatifs, des contraintes d’exploitation, des VLANs, des sauvegardes, des dépendances éditeurs et des périmètres parfois historiques.

Dans cette logique, j’ai commencé à structurer une cartographie applicative avec mon outil it-landscape, un tableau de bord léger basé sur JSON pour représenter des domaines, processus et applications d’un établissement de santé. (GitHub)

Mais assez vite, une question s’est posée :

Est-ce que mon outil doit aussi devenir un référentiel d’infrastructure ?

Ma réponse actuelle : non.

Je préfère spécialiser les outils :

• it-landscape pour les vues applicatives, les flux, les KPI et la lisibilité métier ;
• NetBox pour l’inventaire infrastructure, IPAM, VLANs, clusters, VMs, interfaces et ressources techniques.

NetBox est justement conçu comme une source de vérité réseau et infrastructure, en combinant notamment IPAM, DCIM, API REST et extensions. (netboxlabs.com)

Pourquoi NetBox ?

NetBox n’est pas seulement un inventaire. C’est une base structurée pour documenter et automatiser l’infrastructure.

Dans mon cas, les objets utiles étaient notamment :

• les sites ;
• les clusters VMware ;
• les hôtes ESXi ;
• les machines virtuelles ;
• les interfaces ;
• les adresses IP ;
• les VLANs ;
• les relations VM → cluster → site ;
• les commentaires techniques issus des exports.

L’objectif n’était pas de faire un simple import ponctuel, mais de commencer à bâtir une base propre, réutilisable et exploitable.

Déploiement interne via Docker Compose

Pour démarrer rapidement, j’ai choisi un déploiement interne de NetBox via Docker Compose.

Le dépôt netbox-docker fournit les composants nécessaires pour construire et exécuter NetBox sous forme de conteneurs ; il s’agit d’un projet maintenu par la communauté NetBox. (GitHub)

L’approche Docker Compose est intéressante pour un premier socle interne :

• déploiement rapide ;
• dépendances maîtrisées ;
• PostgreSQL et Redis intégrés ;
• possibilité de versionner la configuration ;
• facilité de reconstruction en environnement de test.

Dans mon contexte, cela permettait de valider rapidement la valeur de NetBox sans lancer immédiatement un chantier d’industrialisation lourd.

La question de l’inventaire VMware

Une fois NetBox déployé, le vrai sujet devient l’alimentation des données.

Pour la virtualisation VMware, plusieurs options existent.

Option 1 : intégration officielle vCenter

NetBox Labs propose une intégration VMware vCenter permettant de synchroniser des données vCenter vers NetBox, notamment pour réduire la saisie manuelle et la dérive documentaire. (netboxlabs.com)

Cette intégration est intéressante, mais elle s’adresse au périmètre NetBox Cloud / Enterprise avec NetBox Assurance. (netboxlabs.com)

Dans un contexte NetBox Community auto-hébergé, ce n’était donc pas l’option la plus directe pour moi.

Option 2 : netbox-sync

En open source, une alternative intéressante existe : bb-Ricardo/netbox-sync.

Le projet permet de synchroniser des objets depuis différentes sources vers NetBox, notamment VMware vCenter et des inventaires Redfish. (GitHub)

C’est probablement l’une des pistes les plus propres si l’on veut une synchronisation plus durable entre vCenter et NetBox.

Mais dans mon cas, je voulais d’abord comprendre le modèle de données, contrôler les mappings et éviter de pousser trop d’informations trop vite.

Option 3 : RVTools + API NetBox

J’ai donc choisi une approche plus progressive :

exporter les données depuis RVTools, puis les pousser dans NetBox via l’API REST avec PowerShell.

Ce choix m’a permis de garder la main sur :

• les champs réellement importés ;
• la correspondance entre datacenters, sites et clusters ;
• la création des VLANs ;
• le rattachement des IPs ;
• les commentaires enrichis ;
• la logique de mise à jour ;
• la correction progressive des erreurs.

Ce que j’ai importé en premier

Je suis parti d’un export RVTools complet, mais je n’ai pas tout importé directement.

Les premiers fichiers réellement utiles ont été :

RVTools_tabvInfo.csv
RVTools_tabvHost.csv
RVTools_tabvCluster.csv
RVTools_tabvNIC.csv
RVTools_tabvDatastore.csv

Le premier socle importé dans NetBox couvre :

• les sites ;
• les clusters VMware ;
• les hosts ESXi ;
• les interfaces physiques ESXi ;
• les VMs ;
• les interfaces VM ;
• les VLANs ;
• les IPs primaires ;
• les datastores en commentaires de cluster.

Le résultat obtenu :

Hosts ESXi créés / MAJ        : X
Interfaces ESXi créées / MAJ  : X
VMs créées / MAJ              : X
Interfaces VM créées / MAJ    : X
VLANs créés / réutilisés      : X
IPs primaires traitées        : X
Templates ignorés             : X
Lignes vides ignorées         : X

À ce stade, NetBox devient déjà utile : on peut rechercher une VM, voir son IP, son VLAN, son cluster, son hôte ESXi d’origine, son OS et ses informations de contexte.

Pourquoi ne pas tout mettre dans NetBox ?

C’est un point important.

NetBox doit rester une source de vérité infrastructure. Il ne doit pas devenir un fourre-tout applicatif.

Par exemple, certaines informations RVTools sont intéressantes pour l’audit, mais pas forcément comme objets natifs NetBox :

• snapshots ;
• VMware Tools obsolètes ;
• ISO montées ;
• USB connectés ;
• alertes RVTools ;
• détails fins des partitions ;
• détails des disques VMDK ;
• licences ;
• multipath ;
• HBA.

Ces données peuvent être utiles, mais plutôt sous forme de :

• tags ;
• commentaires ;
• journal entries ;
• rapports d’audit ;
• custom fields ciblés.

L’objectif est d’éviter de polluer le référentiel.

Articulation avec it-landscape

Mon idée pour la suite est de faire évoluer it-landscape vers un outil plus spécialisé sur la vision applicative.

Je souhaite conserver dans it-landscape :

• les vues applicatives ;
• les domaines métier ;
• les processus ;
• les flux inter-applicatifs ;
• les KPI ;
• les statuts applicatifs ;
• les liens vers la documentation ;
• les dépendances fonctionnelles.

Et déléguer à NetBox :

• les VMs ;
• les IPs ;
• les VLANs ;
• les clusters ;
• les hosts ;
• les interfaces ;
• les ressources techniques ;
• les informations d’infrastructure.

L’idée n’est donc pas de remplacer NetBox, mais de s’y connecter.

À terme, une application dans it-landscape pourrait pointer vers les objets NetBox correspondants :

Application métier
  ├── Flux applicatifs
  ├── KPI
  ├── Statut métier
  └── Ressources infra liées dans NetBox
        ├── VM
        ├── IP
        ├── VLAN
        └── Cluster

Cela permet de séparer proprement deux niveaux :

NetBox       = vérité infrastructure
it-landscape = lecture applicative et gouvernance SI

---

Ce que je retiens

Cette expérimentation confirme plusieurs choses.

D’abord, NetBox prend rapidement de la valeur dès qu’il est alimenté avec un minimum de données propres.

Ensuite, l’API REST est suffisamment simple pour permettre une intégration progressive, sans forcément attendre une solution complète de synchronisation.

Enfin, partir de RVTools est une bonne approche pragmatique pour amorcer le référentiel, surtout lorsque l’on veut comprendre les données avant d’automatiser davantage.

Conclusion

La cartographie ne peut pas être uniquement applicative, ni uniquement technique.

Il faut les deux.

NetBox apporte une base solide pour l’infrastructure.
Un outil comme it-landscape peut rester concentré sur la lecture applicative, les flux, les KPI et la gouvernance.

Le bon équilibre n’est donc pas de tout fusionner, mais de connecter les bons référentiels entre eux.

Pour moi, cette première étape RVTools → PowerShell → API NetBox est surtout une manière pragmatique de poser les fondations :

commencer simple, importer proprement, comprendre le modèle, puis automatiser progressivement.