Automatisation réseau : intégrer NetBox DCIM avec Ansible et Terraform

Comment NetBox, Terraform et Ansible fonctionnent-ils ensemble ?‍

‍

Ce trio forme l'architecture standard de l'automatisation réseau (NetOps) grâce à une séparation stricte des rôles :

‍

• NetBox (la source de vérité) : Centralise l'état attendu du réseau et gère l'IPAM.
• Terraform (le provisioning) : Demande une adresse IP libre à NetBox et déploie la ressource (VM, cloud, réseau).
• Ansible (la configuration) : Utilise l'API de NetBox comme inventaire dynamique pour cibler cette nouvelle machine et installer les services.

Le résultat : une infrastructure pilotée par le code, sans fichiers Excel ni erreur humaine.

‍

‍

Pendant des décennies, l'administration réseau s'est heurtée à un mur immuable : le décalage entre la documentation et la réalité du terrain. Les fichiers Excel d'adressage IP finissent toujours par être obsolètes, et les scripts de configuration isolés créent des failles de sécurité par manque de standardisation.

‍

Avec l'avènement de l'Infrastructure as Code (IaC) et des pratiques NetOps, la gestion du datacenter a radicalement muté. L'objectif n'est plus de documenter ce qui existe, mais de définir ce qui doit exister, puis de laisser des outils d'automatisation déployer cette vision. Dans cette architecture moderne, un outil s'est imposé comme le cerveau des opérations : NetBox.

‍

Ce guide technique détaille comment coupler la puissance de NetBox, en tant que « Source of Truth », avec les moteurs d'exécution que sont Ansible et Terraform.

‍

1. De l'inventaire passif à la Source de Vérité (SoT)

La majorité des logiciels DCIM traditionnels ont été conçus autour du Facility Management et de la supervision. Ils interrogent le réseau via SNMP pour découvrir ce qui est branché et surveiller la température ou l'énergie. NetBox prend le contre-pied de cette approche : il a été pensé par l'équipe réseau de DigitalOcean à partir d'un besoin fondamental : l'IPAM (la gestion des adresses IP).

‍

En fusionnant la modélisation physique (DCIM) et l'adressage logique (IPAM) dès sa création, NetBox ne cherche pas à faire de la supervision. Il s'est imposé comme la véritable Source de Vérité des ingénieurs réseaux.

‍

Dans une architecture automatisée, le réseau n'a pas le droit de dicter son état à la documentation. C'est la documentation qui détient la vérité absolue. Si un commutateur Cisco possède une configuration qui diffère de ce qui est renseigné dans la base de données, c'est le commutateur qui a tort.

‍

Pour imposer cette vérité aux équipements physiques et virtuels, NetBox s'appuie sur une API REST et GraphQL. C'est cette API qui va être interrogée et manipulée par vos pipelines d'intégration continue (CI/CD) via Ansible et Terraform.

‍

2. Ansible et NetBox : la fin du fichier Hosts statique

Ansible est le moteur d'exécution privilégié pour pousser des configurations (VLANs, règles de pare-feu, mise à jour d'OS...) sur un parc de routeurs ou de serveurs. Historiquement, les ingénieurs devaient maintenir un fichier texte statique (le fameux fichier hosts) listant les adresses IP des machines à cibler. Sur un parc de milliers de nœuds, cette méthode est intenable.

‍

L'intégration de NetBox résout ce problème grâce au concept d'inventaire dynamique. Avant d'exécuter son playbook, Ansible va interroger l'API de NetBox pour lui demander la liste des équipements physiques et des machines virtuelles (VMs) correspondant à des critères précis. Si vous ajoutez un nouveau serveur Web dans NetBox le lundi, Ansible le prendra automatiquement en compte dans son déploiement du mardi, sans aucune intervention humaine.

‍

Voici à quoi ressemble un fichier de configuration réel utilisant la collection officielle certifiée, tout en respectant les bonnes pratiques de cybersécurité (chiffrement du token) :

‍

# Appel du plugin officiel NetBox pour l'inventaire
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.straton-dcim.local
validate_certs: yes

# Bonne pratique de sécurité : Chiffrement du Token d'API via Ansible Vault
token: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  373639316535383332306232613539356336336531336166...

# Structuration dynamique (inclut le matériel physique ET les VMs)
group_by:
  - device_roles
  - sites
  - is_virtual

# Ne cibler que les équipements déclarés comme "Actifs" dans la salle de Paris
query_filters:
  - status: active
  - site: paris-dc-1

‍

Une fois cet inventaire dynamique configuré, l'exécution devient d'une simplicité redoutable. Il suffit d'une seule commande dans votre terminal pour cibler des groupes croisés.

‍

Par exemple, pour déployer une mise à jour sur tous les serveurs physiques de la salle de Paris (en excluant les VMs) :

‍

ansible-playbook -i inventory/netbox_dynamic.yml --limit 'sites_paris:&!is_virtual' deploy.yml

‍

En une fraction de seconde, Ansible structure vos groupes par rôles (ex: core-switches, web-servers) et exécute ses tâches avec une précision chirurgicale, garantissant que vos déploiements frappent toujours la bonne cible, sans aucune saisie IP manuelle.

‍

3. Terraform : le pilotage de l'IPAM par le code

Si Ansible excelle dans la configuration, Terraform est le maître absolu du provisioning (la création de l'infrastructure). Lorsqu'un ingénieur déploie de nouvelles machines virtuelles sur VMware ou AWS via Terraform, ces machines ont besoin d'adresses IP.

‍

Sans DCIM automatisé, l'ingénieur doit ouvrir un tableur IPAM, chercher un sous-réseau avec des adresses libres, réserver l'IP manuellement, puis l'insérer dans son code. Ce processus casse toute l'agilité du pipeline.

‍

Grâce au Provider officiel Terraform pour NetBox, le code interagit directement avec le module IPAM (IP Address Management). Lors de l'exécution d'un terraform apply, Terraform va ordonner à NetBox de trouver la prochaine adresse IP disponible dans un VLAN spécifique, de la réserver au nom du nouveau serveur, puis de l'injecter dans la machine.

‍

Observez cette logique d'automatisation à travers ce bloc HCL (HashiCorp Configuration Language) :

‍

# 0. Déclaration du provider officiel NetBox
terraform {
  required_providers {
    netbox = {
      source  = "e-netbox/netbox"
      version = "~> 3.8"
    }
  }
}

# 1. Cibler le sous-réseau (Prefix) depuis lequel piocher l'adresse IP
data "netbox_prefix" "prod_subnet" {
  cidr = "10.0.0.0/24"
}

# 2. Demander à NetBox de trouver ET réserver la prochaine IP de manière atomique
resource "netbox_available_ip_address" "new_server_ip" {
  prefix_id   = data.netbox_prefix.prod_subnet.id
  status      = "active"
  description = "Géré par Terraform - Serveur Backend"
}

# L'adresse IP est instantanément verrouillée, sans risque de doublon.

‍

Le bénéfice est double : le déploiement de l'infrastructure devient instantané, et la documentation du réseau est maintenue à jour à la milliseconde près, sans aucune saisie manuelle.

‍

4. Gérer la dérive de configuration (Configuration Drift)

Associer NetBox, Ansible et Terraform exige une rigueur opérationnelle stricte. Le piège le plus destructeur pour une équipe NetOps est la dérive de configuration.

‍

Si vous instaurez NetBox comme Source de Vérité pilotée par Terraform, il devient formellement interdit à un technicien de se connecter à l'interface Web de NetBox pour modifier une adresse IP ou un VLAN à la main.

‍

Pourquoi ? Parce qu'au prochain déploiement automatisé, Terraform constatera une différence entre son fichier d'état (tfstate) et la base de données. Il écrasera purement et simplement la modification manuelle pour rétablir la « vérité » codée.

‍

Pour éviter ce chaos, l'implémentation doit s'accompagner d'une politique de droits d'accès (RBAC) intransigeante. L'interface graphique de NetBox doit passer en mode lecture seule pour la majorité des équipes IT.

‍

Toute modification de l'infrastructure (l'ajout d'une baie, la création d'un VLAN) doit obligatoirement passer par une Pull Request sur Git, validée par les pairs, puis exécutée par le pipeline CI/CD.

‍

5. L'automatisation événementielle grâce aux Webhooks NetBox

Interroger l'API avec Terraform ou Ansible (modèle Pull) n'est qu'une facette de l'automatisation. NetBox excelle également dans l'approche événementielle (modèle Push) grâce à son système de Webhooks.

‍

Imaginez le scénario suivant : un technicien raccorde un nouveau serveur à un commutateur ToR (Top of Rack) et déclare la connexion physique dans NetBox. Plutôt que d'attendre l'exécution d'une routine nocturne, NetBox émet instantanément un Webhook (une requête HTTP POST) contenant les détails de la modification.

‍

Ce Webhook est intercepté par votre orchestrateur (comme Ansible AWX, Rundeck ou un pipeline GitLab CI). L'orchestrateur déclenche alors immédiatement un playbook qui se connecte au commutateur Cisco ou Juniper pour configurer dynamiquement le bon VLAN sur le port réseau concerné.

‍

C'est l'essence même du NetOps : le réseau s'auto-configure en temps réel en fonction de la documentation.

‍

6. Straton DCIM : l'expertise de l'automatisation

La transition d'une gestion artisanale vers une infrastructure 100 % automatisée et API-Driven est un défi d'ingénierie complexe. La maîtrise des webhooks, de GraphQL et des providers IaC demande un savoir-faire spécifique pour garantir la stabilité de vos déploiements.

‍

Chez Straton DCIM, nous concevons nos plateformes en intégrant nativement ces exigences DevOps. Notre approche garantit que votre référentiel d'infrastructure s'intègre naturellement à vos pipelines sans friction.

‍

Vous souhaitez voir comment nos API réagissent en direct ? ➜ contactez nos développeurs pour une démo personnalisée.

‍

‍

Foire aux questions : NetBox et l'automatisation

‍

NetBox est-il le meilleur outil DCIM open source ?

‍Parmi les logiciels de gestion d'infrastructure (open source DCIM tools), NetBox se démarque par son ADN réseau. Contrairement aux solutions traditionnelles axées uniquement sur le facility management et les baies physiques, NetBox intègre un IPAM natif et une architecture API-First. C'est aujourd'hui le standard pour les équipes orientées automatisation et Infrastructure as Code.

‍

Peut-on cartographier son réseau (NetBox Maps / Visual Explorer) ?

‍Nativement, NetBox se concentre sur la donnée structurée brute (tables, adresses, connexions). Cependant, son architecture ouverte permet d'installer des plugins communautaires très populaires (comme NetBox Topology Views ou des équivalents au Visual Explorer) pour générer des cartographies dynamiques de votre topologie réseau directement à partir de votre SoT.

‍

Faut-il utiliser l'API REST ou GraphQL avec NetBox ?

Les deux sont disponibles nativement. L'API REST est idéale pour les scripts simples et l'intégration standard avec les Providers Terraform. GraphQL brille lorsque vous avez besoin d'extraire des données très imbriquées (par exemple, récupérer une baie, ses serveurs, et toutes leurs adresses IP) en une seule requête pour alléger la charge réseau.

‍

Peut-on se passer de NetBox et utiliser uniquement Ansible ?

C'est une erreur commune. Ansible est un outil d'exécution (un marteau), il n'a pas de mémoire persistante de l'état de votre réseau. Sans NetBox (le plan de construction), vous êtes obligés de stocker vos variables dans des fichiers texte (YAML/JSON) éparpillés sur un dépôt Git, ce qui devient ingérable à grande échelle.

‍

Le module Ansible pour NetBox est-il officiel ?

Oui, la collection netbox.netbox est certifiée et maintenue par la communauté Ansible. Elle est compatible avec Ansible Core et AWX/Tower, et fait l'objet de mises à jour régulières pour s'aligner avec les nouvelles versions de l'API NetBox.