# 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`.