Déployer node_exporter avec Ansible sans exposer le port 9100

Déployer node_exporter avec Ansible ne consiste pas seulement à installer un binaire. Le vrai sujet est d’exposer des métriques Prometheus sans ouvrir inutilement le port 9100. L’objectif est d’obtenir un déploiement répétable, vérifiable et maintenable, avec un filtrage réseau clair.

Pourquoi le port 9100 pose vite problème

node_exporter expose les métriques CPU, mémoire, disque, réseau et noyau Linux au format Prometheus. Le problème n’est pas l’exporter lui-même : c’est le moment où le port 9100 se retrouve accessible plus largement que prévu.

Avec Ansible, vous contrôlez la version, l’utilisateur système, le fichier systemd, le port d’écoute et les règles de pare-feu. C’est plus propre qu’une procédure copiée de serveur en serveur, et surtout plus simple à auditer.

Architecture cible sans exposition inutile du port 9100

Le serveur Prometheus interroge chaque exporter sur le port 9100. Les nœuds supervisés ne poussent rien vers Prometheus, ce qui simplifie les flux réseau, mais impose de bien cadrer qui peut joindre ce port.

En production, n’exposez pas ce port sur Internet. Filtrez-le avec un groupe de sécurité cloud, une règle firewall locale ou un réseau privé réservé à la supervision.

Rôle Ansible minimal pour installer node_exporter

Le rôle peut rester simple : créer un utilisateur dédié, télécharger l’archive officielle, installer le binaire, poser un service systemd, puis démarrer le service.

# inventory.ini
[linux_exporters]
srv-app-01 ansible_host=10.0.10.11
srv-db-01  ansible_host=10.0.10.12

[linux_exporters:vars]
node_exporter_version=1.8.2
prometheus_server_ip=10.0.20.5

La variable prometheus_server_ip permet de garder la règle réseau explicite. Elle évite les ouvertures trop larges pendant les tests.

# playbook.yml
- name: Deploy node_exporter
  hosts: linux_exporters
  become: true
  roles:
    - node_exporter

Le template systemd doit rester lisible. Le service peut écouter sur toutes les interfaces, mais l’accès réel doit être limité par le filtrage réseau et non laissé au hasard.

[Unit]
Description=Prometheus Node Exporter
After=network-online.target

[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter --web.listen-address=:9100
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Mini-lab en 20 minutes avant production

Commencez par un dry-run. Il confirme les changements sans modifier la machine cible.

ansible-playbook -i inventory.ini playbook.yml --check --diff

Si le résultat est cohérent, lancez le déploiement sur la VM pilote uniquement.

ansible-playbook -i inventory.ini playbook.yml --limit srv-app-01

Le résultat attendu est un service actif et une page métriques exploitable. Vérifiez systemd puis l’endpoint HTTP.

systemctl status node_exporter --no-pager
curl -s http://127.0.0.1:9100/metrics | head

Pour nettoyer le test, arrêtez le service et retirez le binaire. Gardez cette tâche séparée pour éviter un rollback accidentel.

systemctl disable --now node_exporter
rm -f /usr/local/bin/node_exporter
userdel node_exporter || true

Sécurité : comment garder le port 9100 sous contrôle

node_exporter ne doit pas devenir une porte ouverte sur votre parc. Même sans authentification applicative, il révèle beaucoup d’informations système. Le bon réflexe est simple : Prometheus doit voir le port 9100, pas le reste du monde.

Côté Prometheus, déclarez des targets explicites. Ajoutez des labels utiles comme l’environnement, le rôle applicatif et le site.

scrape_configs:
  - job_name: linux-node-exporter
    static_configs:
      - targets:
          - srv-app-01.example.net:9100
          - srv-db-01.example.net:9100
        labels:
          env: production
          team: platform

Dimensionnement et conventions d’inventaire

Avant de généraliser le déploiement, classez les serveurs par environnement. Un inventaire plat fonctionne pour un test, mais il devient fragile dès que plusieurs équipes consomment les métriques.

Une convention simple consiste à distinguer production, préproduction et plateformes internes. Les labels Prometheus doivent reprendre cette logique pour faciliter les tableaux de bord et les alertes.

Ce découpage aide aussi à limiter les permissions Ansible. Un compte d’automatisation n’a pas besoin d’agir sur tout le parc si le pilote concerne seulement quelques hôtes.

Quelles métriques surveiller après le déploiement ?

L’installation de node_exporter n’a de valeur que si elle débouche sur des alertes utiles. Évitez de déclencher une alerte sur chaque variation normale du système.

Les premiers signaux à suivre sont l’espace disque, la pression mémoire, la charge CPU soutenue, l’état des filesystems et la disponibilité de l’exporter lui-même.

Gardez les seuils simples au départ. Une alerte imparfaite mais comprise par l’équipe vaut mieux qu’une règle complexe ignorée par tout le monde.

Industrialiser sans casser l’exploitation

Sur un parc important, utilisez serial pour limiter le nombre de machines modifiées en même temps. Cela réduit le risque opérationnel pendant les mises à jour.

- name: Deploy node_exporter safely
  hosts: linux_exporters
  become: true
  serial: 10
  roles:
    - node_exporter

Ajoutez aussi un tag Ansible dédié. Vous pourrez relancer uniquement la supervision sans toucher aux autres rôles d’administration système.

ansible-playbook -i inventory.ini site.yml --tags node_exporter --limit linux_exporters

Documentez enfin la procédure de rollback dans le dépôt d’infrastructure. Le jour où une version pose problème, l’équipe doit savoir revenir rapidement à l’état précédent.

Erreurs courantes et corrections rapides

Maintenance, mises à jour et preuve de conformité

Un déploiement réussi doit rester prouvable dans le temps. Conservez la version attendue dans les variables du rôle et affichez-la dans les changements Ansible.

Lors d’un audit interne, vous pourrez montrer quels serveurs exposent node_exporter, quelle version est installée et quelle règle réseau limite l’accès.

Cette traçabilité est souvent plus importante que la commande d’installation elle-même. Elle rassure les équipes sécurité et facilite les reprises d’exploitation.

Planifiez une revue trimestrielle de la version. node_exporter évolue peu, mais les correctifs et changements de collecteurs doivent être suivis proprement.

ansible linux_exporters -m command -a "/usr/local/bin/node_exporter --version" -b

Le résultat attendu doit lister la même version sur les hôtes du groupe. Toute différence doit déclencher une correction ou une exclusion documentée.

Pensez aussi à surveiller la cible Prometheus up. Si elle passe à zéro, vous perdez la visibilité sur le serveur concerné.

up{job="linux-node-exporter"} == 0

Cette alerte simple détecte un service arrêté, un problème DNS, une route cassée ou une règle firewall trop restrictive. Elle doit rester prioritaire.

Pour les environnements sensibles, ajoutez un contrôle externe. Une vérification depuis le réseau de supervision confirme que le chemin complet fonctionne.

Enfin, documentez les exceptions. Un serveur isolé, une appliance ou une machine temporaire peut avoir une règle différente, mais elle doit être visible.

FAQ sur Ansible node_exporter

Conclusion : un petit exporter, une vraie discipline d’exploitation

Déployer node_exporter avec Ansible est un chantier court, mais il structure durablement votre supervision Linux. Le gain principal vient de la répétabilité et du contrôle réseau.

Commencez petit, validez une VM, puis élargissez progressivement. Vous obtiendrez des métriques fiables sans transformer la supervision en dette opérationnelle.