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 ef4f769f89 feat: Réécriture complète de dnsmasq.conf et décentralisation des configurations .env 
- Réécriture complète de dnsmasq.conf avec résolution DNS pour tous les services .4nk-local
- Décentralisation des configurations .env vers chaque service (modules/projects)
- Création de fichiers .env et .env.exemple pour chaque service concerné
- Suppression du fichier .env global
- Mise à jour de la structure 4nk-local avec configurations décentralisées
- Amélioration de la sécurité et de l isolation des configurations par service
2025-09-12 13:20:35 +02:00

6.6 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.modules.4nk-local: 172.20.0.10
    • bitcoin.modules.4nk-local: 172.20.0.11
    • blindbit-oracle.modules.4nk-local: 172.20.0.12
    • sdk-storage.modules.4nk-local: 172.20.0.13
    • sdk-relay{1,2,3}.4nk-local: 172.20.0.14-16
    • sdk-signer.4nk-local: 172.20.0.17
    • ihm.client.modules.4nk-local: 172.20.0.18
    • grafana.grafanalocal: 172.20.0.50
    • loki.4nk-local: 172.20.0.51
    • prometheus.4nk-local: 172.20.0.52
    • promtail.4nk-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 *.4nk-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.modules.4nk-local: entrypoint attend brièvement la disponibilité réseau/DNS avant de lancer bitcoind.
  • blindbit-oracle.modules.4nk-local et sdk_relay{1,2,3}.4nk-local: entrypoint attend la résolution de bitcoin.modules.4nk-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.modules.4nk-local nslookup bitcoin.modules.4nk-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.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

  • Setup automatique : Le script scripts/setup-bitcoin-dirs.sh s'exécute automatiquement via le service bitcoin-setup avant le démarrage de Bitcoin. Il crée tous les dossiers nécessaires et corrige les fichiers de configuration.
  • Setup manuel (si nécessaire) : ./scripts/setup-bitcoin-dirs.sh pour préparer manuellement les dossiers Bitcoin.
  • 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.

Setup automatique des dossiers Bitcoin

Le service bitcoin-setup s'exécute automatiquement avant le démarrage de Bitcoin et effectue les opérations suivantes :

  • Création des dossiers : wallets, signet, blocks, chainstate dans modules/bitcoin/data/
  • Correction des fichiers de configuration : Supprime les répertoires incorrects et recrée les fichiers depuis les exemples
  • Vérification des services : Contrôle les configurations des relay et ihm_client

Script manuel : ./scripts/setup-bitcoin-dirs.sh pour un setup manuel avec logs détaillés.

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.
  • Dossier wallets : walletdir=/home/bitcoin/.bitcoin/wallets (créé automatiquement par le setup).
  • Ces paramètres évitent les erreurs de bind/résolution liées à l'hôte bitcoin.modules.4nk-local.

Ports exposés (hôte → conteneur)

  • prometheus.4nk-local : 9092 → 9090 (au lieu de 9091 → 9090 précédemment)
  • sdk-signer.4nk-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.