4nk/4NK_node
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity
4NK_node/docs/CONFIGURATION.md
Nicolas Cantu 9e0c5634d7 docs(config): centralisation conf monitoring + ports prometheus(9092) signer(9093) 
- docker-compose: montages depuis conf/monitoring pour grafana/prometheus/promtail/loki
- script: scripts/setup-monitoring-symlinks.sh (liens symboliques idempotents)
- bitcoin: bind/rpcbind/zmq sur 0.0.0.0 pour éviter erreurs de bind
- docs: CONFIGURATION.md (ports, montages, bitcoin), CHANGELOG.md (Unreleased)
2025-09-11 15:21:52 +02:00

5.4 KiB
Raw Blame History

Configuration réseau et résolution de noms (4NK_node)

Réseau Docker 4nk_network

  • Sous-réseau: 172.20.0.0/16
  • Passerelle: 172.20.0.1
  • IPs statiques par service (extrait):
    • tor.local: 172.20.0.10
    • bitcoin.local: 172.20.0.11
    • blindbit-oracle.local: 172.20.0.12
    • sdk-storage.local: 172.20.0.13
    • sdk-relay{1,2,3}.local: 172.20.0.14-16
    • sdk-signer.local: 172.20.0.17
    • ihm-client.local: 172.20.0.18
    • grafana-central.local: 172.20.0.50
    • loki.local: 172.20.0.51
    • prometheus.local: 172.20.0.52
    • promtail.local: 172.20.0.53

DNS local (dnsmasq)

  • Fichier chargé par le service système: /etc/dnsmasq.d/4nk_node.conf (lien symbolique vers conf/dnsmasq/dnsmasq.conf).
  • Port d’écoute: 53.
  • Les entrées address=/.../172.20.x.x assurent la résolution des hôtes *.local du réseau projet.

Compose: DNS et extra_hosts

  • Les services utilisent dns: [172.20.0.1] pour interroger dnsmasq côté hôte.
  • Un ancrage YAML x-4nk-extra-hosts fournit une liste extra_hosts pour garantir la résolution intra-conteneur, y compris au tout début du cycle de vie.

Démarrage ordonné et attentes réseau

  • bitcoin.local: entrypoint attend brièvement la disponibilité réseau/DNS avant de lancer bitcoind.
  • blindbit-oracle.local et sdk_relay{1,2,3}.local: entrypoint attend la résolution de bitcoin.local et la présence de /home/bitcoin/.bitcoin/signet/.cookie avant d’exécuter la commande du service.

Commandes utiles

  • Redémarrer dnsmasq: systemctl restart dnsmasq
  • Vérifier une résolution depuis un conteneur: docker exec tor.local nslookup bitcoin.local 172.20.0.1

Configuration des images, réseaux et paramètres

Politique de tags et registres

  • Référence: les services 4NK tirent les images :dev depuis git.4nkweb.com.
  • Images externes stables: dperson/torproxy:latest, ruimarinho/bitcoin-core:latest.
  • Blindbit: git.4nkweb.com/4nk/blindbit-oracle:dev.
  • Relais: git.4nkweb.com/4nk/sdk_relay:dev (image unique pour 1/2/3).
  • Signer/Storage/UI/Coffre: images git.4nkweb.com/4nk/*:dev.

Réseaux et adresses

  • 4nk_network : 172.20.0.0/16 avec IP statiques et hostnames .4nk.local par service.
  • 4nk_projects_net : 172.21.0.0/16 réservé pour des projets additionnels.

Montages (configuration, données, logs)

  • Configuration : montée en lecture seule lorsque possible depuis conf/monitoring (centralisé) et projects/*/*/conf. Les fichiers suivants sont référencés par docker-compose.yml :
    • conf/monitoring/grafana.ini → /etc/grafana/grafana.ini
    • conf/monitoring/datasources.yml → /etc/grafana/provisioning/datasources/datasources.yml
    • conf/monitoring/prometheus.yml → /etc/prometheus/prometheus.yml
    • conf/monitoring/promtail-config.yml → /etc/promtail/config.yml
    • conf/monitoring/loki-config.yaml → /etc/loki/local-config.yaml
    • Un script idempotent scripts/setup-monitoring-symlinks.sh assure l’alignement par liens symboliques avec modules/grafana-central/conf.
  • Données : volumes persistants locaux (modules/*/data, projects/*/*/data).
  • Journaux : modules/*/logs, projects/*/*/logs, et ./log pour la stack d’observabilité.

Variables d’environnement (exemples typés)

  • Journalisation :
    • RUST_LOG : chaîne (ex. debug,bitcoincore_rpc=trace).
  • Bitcoin :
    • BITCOIN_COOKIE_PATH : chemin absolu vers le cookie RPC.
  • Synchronisation (selon besoins locaux) :
    • ENABLE_SYNC_TEST : booléen (0/1) activant certains scénarios de test.

Nota : ces variables sont documentées pour référence et ne modifient pas la configuration existante.

Healthchecks et supervision

  • Services HTTP/WS instrumentés par des healthchecks (requêtes HTTP simples sur ports exposés).
  • Stack observabilité : Promtail collecte les logs montés et les pousse vers Loki ; Grafana consomme Loki.
  • Conformément à USAGE.md, Grafana peut être exécuté localement (hors Docker) ou via le service de l’orchestrateur.

Nginx et routage

  • Nginx agit en reverse‑proxy et expose des routes stables : /, /blindbit/, /sdk_storage/, /relay1|2|3/ (+ /ws/), /signer/ (+ /ws/), /coffre/, /grafana/.
  • L’exécution locale (hors Docker) est supportée ; les fichiers de configuration existants ne sont pas modifiés par ce document.

Procédures usuelles

  • Initialiser les configurations: copier tous les fichiers *.exemple vers leur homonyme sans suffixe.
  • Vérifier les images : docker-compose pull.
  • Démarrer la stack : docker-compose up -d.
  • Consulter les logs : docker-compose logs --tail=100.

Paramètres Bitcoin (signet)

  • Liaison RPC et P2P : rpcbind=0.0.0.0:38332, bind=0.0.0.0:38333.
  • ZMQ publication : zmqpubhashblock=tcp://0.0.0.0:29000, zmqpubrawtx=tcp://0.0.0.0:29000.
  • Ces paramètres évitent les erreurs de bind/résolution liées à l’hôte bitcoin.local.

Ports exposés (hôte → conteneur)

  • prometheus.local : 9092 → 9090 (au lieu de 9091 → 9090 précédemment)
  • sdk-signer.local : 9093 → 9090 (conflit évité avec 9090 hôte)

Conclusion

Cette page consolide les paramètres clefs (tags :dev, topologie réseau, montages, variables, healthchecks, routage) afin d’harmoniser l’usage sans modifier les fichiers de configuration. Les évolutions futures seront répercutées dans docs/ARCHITECTURE.md et consignées dans CHANGELOG.md.