142 lines
7.6 KiB
Markdown
142 lines
7.6 KiB
Markdown
# Configuration réseau et résolution de noms (4NK_node)
|
||
|
||
> Mise à jour (réseaux et variables d’environnement)
|
||
>
|
||
> - DNS central: `dnsmasq.4nk-local` avec IP statique `172.30.0.1`.
|
||
> - Segmentation réseaux Docker:
|
||
> - `modules.4nk-local`: 172.31.0.0/16
|
||
> - `sdk-relay.modules.4nk-local`: 172.31.1.0/16
|
||
> - `ia.modules.4nk-local`: 172.31.2.0/16
|
||
> - `grafana.modules.4nk-local`: 172.31.3.0/16
|
||
> - `data.modules.4nk-local`: 172.31.4.0/16
|
||
> - `client.modules.4nk-local`: 172.31.5.0/16
|
||
> - `lecoffre.projects.4nk-local`: 172.31.6.0/16
|
||
> - Résolution FQDN vers IP alignée entre `docker-compose.yml` (extra_hosts) et `4nk-local/dnsmasq/conf/dnsmasq.conf`.
|
||
> - Gestion des variables par service via fichiers `conf/.env` montés avec `env_file` dans `docker-compose.yml` (plus de redondance dans `environment`).
|
||
>
|
||
> Impact:
|
||
> - Les secrets et paramètres (Postgres/MinIO/Neo4j/IA) sont centralisés par service dans `4nk-local/**/conf/.env`.
|
||
> - Les commandes et healthchecks utilisent désormais des valeurs littérales ou des variables issues des `env_file`.
|
||
|
||
## 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`.
|