Mettre en place un nœud blockchain dans un réseau de consortium présente des défis uniques. Contrairement aux réseaux publics où il suffit de se synchroniser avec des bootnodes connus, les réseaux privés nécessitent une connectivité sécurisée entre partenaires, une configuration NAT appropriée et un monitoring robuste.
Cet article documente mon parcours pour déployer un nœud Hyperledger Besu, le connecter aux partenaires du consortium via VPN WireGuard, et construire une observabilité complète avec Prometheus et Grafana.

L’architecture
Le setup comprend plusieurs composants interconnectés :
┌─────────────────────────────────────────────────────────────┐
│ Notre Infrastructure │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ Nomad │────▶│ Besu │────▶│ Métriques Prometheus│ │
│ │ (job) │ │ (nœud) │ │ (port 9545) │ │
│ └──────────┘ └────┬─────┘ └──────────┬───────────┘ │
│ │ │ │
│ │ P2P │ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────────┐ │
│ │WireGuard │ │ Grafana │ │
│ │ (VPN) │ │ Dashboard │ │
│ └────┬─────┘ └──────────────┘ │
└───────────────────────┼─────────────────────────────────────┘
│
│ Tunnel chiffré
▼
┌──────────────────┐
│ Bootnode partner │
│ (Consortium) │
└──────────────────┘
WireGuard VPN : la fondation
Le premier défi était d’établir une connectivité sécurisée vers le bootnode du consortium. WireGuard offre une solution VPN moderne et légère, parfaite pour ce cas d’usage.
Points clés de configuration
[Interface]
PrivateKey = <clé_générée>
Address = 10.0.0.10/32
ListenPort = 51820
[Peer]
PublicKey = <clé_publique_partenaire>
Endpoint = <ip_partenaire>:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25Le PersistentKeepalive est crucial - sans lui, le mapping NAT expire et la connexion tombe silencieusement.
Déploiement du nœud Besu avec Nomad
Exécuter le nœud blockchain via HashiCorp Nomad apporte plusieurs avantages :
- Configuration déclarative : tout le setup est versionné dans git
- Health checks : redémarrage automatique en cas d’échec
- Gestion des ressources : limites CPU et mémoire
- Découverte de services : intégration avec la stack de monitoring
Le piège du NAT
La partie la plus délicate était la découverte P2P. Même avec le VPN connecté, le nœud affichait 0 peers. Après des heures de debug, le problème était clair : Besu annonçait 0.0.0.0 comme adresse P2P au lieu de l’IP VPN.
La solution a nécessité deux flags :
--nat-method=NONE
--p2p-host=10.0.0.10Avec --nat-method=NONE, Besu arrête d’essayer de détecter automatiquement l’IP externe et utilise exactement ce qu’on spécifie avec --p2p-host.
Static nodes pour la fiabilité
Pour assurer la reconnexion automatique après les redémarrages ou les coupures réseau, j’ai ajouté un static-nodes.json :
[
"enode://<node_id>@10.0.0.1:30303"
]Cela indique à Besu de toujours tenter de se connecter au bootnode, même si la découverte échoue.
Construction du dashboard de monitoring
Avec le nœud opérationnel, l’étape suivante était l’observabilité. Besu expose des métriques Prometheus sur un port dédié :
--metrics-enabled
--metrics-host=0.0.0.0
--metrics-port=9545Métriques clés à surveiller
| Métrique | Utilité |
|---|---|
ethereum_best_known_block_number |
Hauteur de bloc - doit augmenter toutes les ~2s (QBFT) |
besu_peers_connected_total |
Nombre de peers - alerter si 0 |
besu_synchronizer_in_sync |
Statut de sync - 1 = synchronisé |
jvm_memory_used_bytes{area="heap"} |
Utilisation mémoire |
besu_transaction_pool_number_of_transactions |
Transactions en attente |
Monitoring du VPN
Le VPN étant critique, j’ai aussi déployé un exporter Prometheus pour WireGuard :
docker run -d \
--name wireguard-exporter \
--cap-add NET_ADMIN \
--network host \
mindflavor/prometheus-wireguard-exporterCela expose des métriques comme :
wireguard_latest_handshake_seconds- Détecter les connexions VPN obsolèteswireguard_sent_bytes_total/wireguard_received_bytes_total- Monitoring du trafic
Le dashboard affiche “VPN Links Foundation: 21s” signifiant que le dernier handshake date de 21 secondes - sain !
Le dashboard
Le dashboard Grafana final (ci-dessus) fournit un statut en un coup d’œil :
Ligne 1 - Stats :
- Block Height (187 070 au moment de la capture)
- Peers Connected (1 - le bootnode)
- Sync Status (vert “In Sync”)
- Chain Difficulty
Ligne 2 - Tendances :
- Progression de la hauteur de bloc
- Connexions peers dans le temps
Ligne 3 - Ressources :
- Utilisation heap JVM (~110 MiB utilisés, 1.93 GiB max)
- Profondeur du pool de transactions
Ligne 4 - Activité :
- Gas utilisé par bloc
- Taux de messages P2P
Ligne 5 - VPN :
- Temps depuis le dernier handshake (vert < 3 min)
- Taux de trafic VPN
Automatisation Ansible
Pour rendre cela reproductible, j’ai créé deux rôles Ansible :
- rôle wireguard : Installe WireGuard, génère les clés, configure le tunnel
- rôle besu : Crée les répertoires de données, génère les clés de nœud, configure les volumes Nomad
Un seul playbook lie le tout :
- hosts: blockchain_nodes
become: true
roles:
- wireguard
- besuLeçons apprises
- Le NAT est un piège : Lors de connexions via VPN, toujours spécifier explicitement l’host P2P
- Les static nodes comptent : Ne pas compter uniquement sur la découverte dans les petits réseaux
- Surveiller le VPN : Un VPN mort signifie un nœud mort, même si le processus tourne
- Prometheus pour tout : Les métriques intégrées de Besu sont complètes
- Documenter au fur et à mesure : Le vous du futur remerciera le vous du présent
Et ensuite ?
- Configurer des alertes pour la perte de peers et les problèmes de sync
- Ajouter plus de partenaires au consortium
- Explorer le monitoring de smart contracts
- Tests de performance sous charge
Les réseaux blockchain privés demandent plus d’attention opérationnelle que les publics, mais avec les bons outils, ils peuvent être tout aussi fiables. La combinaison de Nomad pour l’orchestration, WireGuard pour la connectivité sécurisée, et Prometheus/Grafana pour l’observabilité crée une base solide pour les workloads de production.