Nicolas Cantu
9e0c5634d7
- 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)
111 lines
5.4 KiB
Markdown
111 lines
5.4 KiB
Markdown
# 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`.
|