Fix sdk_relay configuration and Docker setup - Update ws_url to port 8090 - Fix Dockerfile context path - Add specs documentation - Add .conf file

This commit is contained in:
Nicolas Cantu 2025-08-22 14:24:42 +02:00
parent 4f4fec33be
commit 7ba333bfb1
6 changed files with 362 additions and 9 deletions

View File

@ -59,7 +59,7 @@ services:
sdk_relay:
build:
context: ..
dockerfile: lecoffre_node/sdk_relay/Dockerfile
dockerfile: 4NK_node/sdk_relay/Dockerfile
container_name: sdk_relay
depends_on:
bitcoin:
@ -93,6 +93,14 @@ services:
cp /home/bitcoin/.conf.docker /home/bitcoin/.conf &&
cp /home/bitcoin/.bitcoin/signet/.cookie /home/bitcoin/.4nk/bitcoin.cookie &&
chmod 600 /home/bitcoin/.4nk/bitcoin.cookie &&
echo 'Configuration loaded:' &&
cat /home/bitcoin/.conf &&
echo 'Testing DNS resolution:' &&
getent hosts bitcoin &&
echo 'Testing connectivity:' &&
curl -s --connect-timeout 5 http://bitcoin:18443 &&
echo 'Bitcoin accessible via curl' &&
echo 'Starting sdk_relay:' &&
/usr/local/bin/sdk_relay --config .conf"
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8091/health"]

17
sdk_relay/.conf Normal file
View File

@ -0,0 +1,17 @@
# Configuration sdk_relay pour Docker
# Services connectés via réseau Docker
# Bitcoin Core RPC (utilise le nom d'hôte Docker et le cookie)
core_url=http://bitcoin:18443
core_wallet=relay_wallet
ws_url=127.0.0.1:8080
wallet_name=relay_wallet.json
network=signet
blindbit_url=http://blindbit:8000
zmq_url=tcp://bitcoin:29000
data_dir=.4nk
cookie_path=/home/bitcoin/.4nk/bitcoin.cookie
# Mode développement
dev_mode=true
standalone=false

View File

@ -2,14 +2,15 @@
# Services connectés via réseau Docker
# Bitcoin Core RPC (utilise le nom d'hôte Docker et le cookie)
core_url=http://bitcoin:18443
core_url=http://172.19.0.3:18443
core_wallet=relay_wallet
ws_url=127.0.0.1:8080
ws_url=0.0.0.0:8090
wallet_name=relay_wallet.json
network=signet
blindbit_url=http://blindbit:8000
zmq_url=tcp://bitcoin:29000
zmq_url=tcp://172.19.0.3:29000
data_dir=.4nk
cookie_path=/home/bitcoin/.4nk/bitcoin.cookie
# Mode développement
dev_mode=true

View File

@ -3,13 +3,13 @@ FROM rust:1.89 as builder
WORKDIR /app
# Copier les sources
COPY sdk_relay/ /app/sdk_relay/
COPY sdk_common/ /app/sdk_common/
# Cloner les repositories avec les branches docker-support
RUN git clone --branch docker-support --depth 1 https://git.4nkweb.com/4nk/sdk_relay.git /app/sdk_relay
RUN git clone --branch docker-support --depth 1 https://git.4nkweb.com/4nk/sdk_common.git /app/sdk_common
# Compiler sdk_relay
WORKDIR /app/sdk_relay
RUN sed -i 's|path = "../sdk_common"|path = "/app/sdk_common"|' Cargo.toml && \
RUN sed -i 's|git = "https://git.4nkweb.com/4nk/sdk_common.git", branch = "dev"|path = "/app/sdk_common"|' Cargo.toml && \
cargo build --release
# Image finale
@ -36,7 +36,7 @@ WORKDIR /home/bitcoin
RUN mkdir -p /home/bitcoin/.4nk
# Copier la configuration
COPY sdk_relay/.conf /home/bitcoin/.conf
COPY 4NK_node/sdk_relay/.conf /home/bitcoin/.conf
# Changer les permissions
RUN chown -R bitcoin:bitcoin /home/bitcoin

215
specs/spec-fonctionnel.md Normal file
View File

@ -0,0 +1,215 @@
# Spécification Fonctionnelle - 4NK_node
## Vue d'ensemble
Ce document décrit les fonctionnalités et les cas d'usage du projet 4NK_node.
## Fonctionnalités principales
### 1. Nœud Bitcoin Core
- **Description** : Nœud Bitcoin Core configuré en mode signet
- **Fonctionnalités** :
- Validation des transactions
- Stockage de la blockchain
- Interface RPC pour les interactions
- Support des wallets
- **Configuration** :
- Port RPC : 18443
- Port ZMQ : 29000
- Réseau : Signet
- Données persistantes via volume Docker
### 2. Service Blindbit
- **Description** : Service pour les paiements silencieux
- **Fonctionnalités** :
- Génération d'adresses de paiement silencieux
- Validation des transactions
- Interface HTTP pour les interactions
- **Configuration** :
- Port : 8000
- Interface : HTTP REST API
### 3. Service SDK Relay
- **Description** : Relais pour les interactions SDK
- **Fonctionnalités** :
- Connexion au nœud Bitcoin Core
- Gestion des wallets
- Interface WebSocket
- Scan des blocs pour les paiements silencieux
- **Configuration** :
- Port WebSocket : 8090
- Port HTTP : 8091
- Retry automatique en cas d'échec de connexion
### 4. Service Tor
- **Description** : Service Tor pour l'anonymat
- **Fonctionnalités** :
- Routage anonyme
- Protection de la vie privée
- Interface SOCKS
- **Configuration** :
- Port SOCKS : 9050
- Port de contrôle : 9051
## Cas d'usage
### 1. Démarrage du système
1. Lancer `docker-compose up -d`
2. Attendre que tous les services soient healthy
3. Vérifier les logs pour s'assurer du bon fonctionnement
4. Le système est prêt à recevoir des transactions
### 2. Connexion au nœud Bitcoin
1. Utiliser l'interface RPC sur le port 18443
2. Authentification via cookie ou credentials
3. Envoyer des commandes JSON-RPC
4. Recevoir les réponses
### 3. Utilisation des paiements silencieux
1. Générer une adresse de paiement silencieux via Blindbit
2. Envoyer des fonds à cette adresse
3. Le SDK Relay scanne automatiquement les blocs
4. Détection et traitement des paiements reçus
### 4. Surveillance du système
1. Consulter les logs des services
2. Vérifier l'état des healthchecks
3. Surveiller l'utilisation des ressources
4. Détecter et résoudre les problèmes
## Interfaces utilisateur
### 1. Interface RPC Bitcoin
- **Protocole** : JSON-RPC
- **Port** : 18443
- **Authentification** : Cookie ou credentials
- **Endpoints** : Standard Bitcoin Core RPC
### 2. Interface HTTP Blindbit
- **Protocole** : HTTP REST
- **Port** : 8000
- **Authentification** : À définir
- **Endpoints** : API Blindbit
### 3. Interface WebSocket SDK Relay
- **Protocole** : WebSocket
- **Port** : 8090
- **Authentification** : À définir
- **Messages** : Événements et commandes SDK
### 4. Interface HTTP SDK Relay
- **Protocole** : HTTP REST
- **Port** : 8091
- **Authentification** : À définir
- **Endpoints** : API SDK Relay
## Gestion des erreurs
### 1. Erreurs de connexion
- **Détection** : Timeout ou erreur de résolution DNS
- **Action** : Retry automatique avec backoff exponentiel
- **Limite** : 5 tentatives maximum
- **Log** : Erreurs détaillées dans les logs
### 2. Erreurs de configuration
- **Détection** : Fichiers de configuration manquants ou invalides
- **Action** : Utilisation de valeurs par défaut
- **Log** : Avertissements dans les logs
### 3. Erreurs de service
- **Détection** : Healthcheck en échec
- **Action** : Redémarrage automatique du service
- **Limite** : 3 redémarrages maximum
- **Log** : Erreurs critiques dans les logs
## Sécurité
### 1. Authentification
- **Bitcoin Core** : Cookie d'authentification
- **Blindbit** : À définir
- **SDK Relay** : À définir
- **Tor** : Pas d'authentification requise
### 2. Chiffrement
- **RPC Bitcoin** : HTTP (non chiffré)
- **HTTP Blindbit** : HTTP (non chiffré)
- **WebSocket SDK Relay** : WSS (chiffré)
- **Tor** : Chiffrement intégré
### 3. Isolation réseau
- **Réseau privé** : btcnet pour la communication inter-services
- **Ports exposés** : Seulement les ports nécessaires
- **Volumes** : Données persistantes isolées
## Performance
### 1. Ressources requises
- **CPU** : Minimum 2 cœurs
- **RAM** : Minimum 4 GB
- **Stockage** : Minimum 50 GB pour la blockchain
- **Réseau** : Connexion stable à Internet
### 2. Optimisations
- **Cache** : Mise en cache des données fréquemment utilisées
- **Compression** : Compression des données de blockchain
- **Parallélisation** : Traitement parallèle des blocs
- **Monitoring** : Métriques de performance
## Maintenance
### 1. Sauvegarde
- **Fréquence** : Quotidienne
- **Contenu** : Volumes Docker et configurations
- **Rétention** : 30 jours
- **Restauration** : Procédure documentée
### 2. Mise à jour
- **Fréquence** : Mensuelle
- **Processus** : Test en environnement de développement
- **Rollback** : Possibilité de revenir à la version précédente
- **Documentation** : Changelog détaillé
### 3. Monitoring
- **Métriques** : CPU, RAM, disque, réseau
- **Logs** : Centralisation et rotation
- **Alertes** : Notification en cas de problème
- **Dashboard** : Interface de visualisation
## Tests
### 1. Tests unitaires
- **Couverture** : Minimum 80%
- **Exécution** : À chaque commit
- **Rapport** : Génération automatique
### 2. Tests d'intégration
- **Environnement** : Docker Compose
- **Scénarios** : Cas d'usage principaux
- **Exécution** : Avant chaque déploiement
- **Rapport** : Résultats détaillés
### 3. Tests de charge
- **Outils** : JMeter ou équivalent
- **Scénarios** : Charge normale et pic
- **Métriques** : Temps de réponse et débit
- **Seuils** : Définis selon les exigences
## Documentation
### 1. Documentation technique
- **API** : Documentation OpenAPI/Swagger
- **Architecture** : Diagrammes et schémas
- **Déploiement** : Guide étape par étape
- **Troubleshooting** : Guide de résolution des problèmes
### 2. Documentation utilisateur
- **Installation** : Guide d'installation
- **Configuration** : Guide de configuration
- **Utilisation** : Guide d'utilisation
- **FAQ** : Questions fréquentes
### 3. Documentation de maintenance
- **Procédures** : Procédures de maintenance
- **Checklists** : Checklists de vérification
- **Contacts** : Contacts d'urgence
- **Escalade** : Procédure d'escalade

112
specs/spec-technical.md Normal file
View File

@ -0,0 +1,112 @@
# Spécification Technique - 4NK_node
## Vue d'ensemble
Ce document décrit les modifications techniques apportées au projet 4NK_node pour résoudre les problèmes de déploiement Docker.
## Problèmes identifiés
### 1. Résolution DNS dans Docker
- **Problème** : Le service `sdk_relay` ne pouvait pas résoudre les noms d'hôtes `bitcoin` et `blindbit`
- **Cause** : Configuration réseau Docker incorrecte
- **Solution** : Amélioration de la gestion des erreurs et ajout de retry logic
### 2. Dépendances Git
- **Problème** : Les dépendances pointaient vers des repositories distants
- **Cause** : Cargo.toml utilisait des URLs Git au lieu de chemins locaux
- **Solution** : Modification des dépendances pour utiliser des chemins locaux
### 3. Configuration du cookie Bitcoin
- **Problème** : Le chemin du cookie Bitcoin était codé en dur
- **Cause** : Utilisation de `env::var("HOME")` dans un contexte Docker
- **Solution** : Ajout d'une option de configuration personnalisée pour le chemin du cookie
## Modifications apportées
### sdk_relay
- **Branche** : `docker-fixes`
- **Modifications** :
- Ajout de la méthode `get_cookie_path()` dans `Config`
- Modification de la signature de `rpc_connect()` pour accepter un chemin de cookie personnalisé
- Ajout de logique de retry pour la connexion au daemon Bitcoin
- Amélioration de la gestion des erreurs de résolution DNS
### sdk_common
- **Branche** : `docker-fixes`
- **Modifications** :
- Modification de la dépendance `sp_client` pour utiliser un chemin local
- Correction de la feature `blindbit-backend` vers `blindbit-native`
### sdk_client
- **Branche** : `docker-fixes`
- **Modifications** :
- Modification de la dépendance `sdk_common` pour utiliser un chemin local
### 4NK_node
- **Modifications** :
- Mise à jour du Dockerfile pour cloner les branches `docker-fixes`
- Amélioration de la configuration Docker avec healthchecks
- Ajout de la gestion des erreurs et retry logic
## Architecture Docker
### Services
1. **bitcoin** : Nœud Bitcoin Core en mode signet
2. **blindbit** : Service Blindbit
3. **sdk_relay** : Service de relais SDK (modifié)
4. **tor** : Service Tor pour l'anonymat
### Réseau
- **btcnet** : Réseau privé pour la communication entre services
### Volumes
- **bitcoin_data** : Données Bitcoin Core
- **sdk_relay_data** : Données du relais SDK
## Problèmes restants
### 1. Compilation sdk_relay
- **Erreur** : Signatures de traits incompatibles
- **Cause** : Différences entre les versions des traits `SpScanner` et `ChainBackend`
- **Impact** : Le service ne peut pas être compilé actuellement
### 2. Collision de noms de fichiers
- **Erreur** : `libsp_client.rlib` en collision
- **Cause** : Plusieurs packages avec le même nom
- **Impact** : Compilation échoue
## Recommandations
### Court terme
1. Corriger les signatures de traits dans sdk_relay
2. Résoudre les collisions de noms de fichiers
3. Tester la compilation complète
### Moyen terme
1. Implémenter les méthodes manquantes dans `DummyBackend`
2. Ajouter des tests unitaires pour les nouvelles fonctionnalités
3. Documenter l'API des nouvelles méthodes
### Long terme
1. Migrer vers une architecture plus modulaire
2. Implémenter une gestion d'état centralisée
3. Ajouter des métriques et monitoring
## Fichiers modifiés
### sdk_relay
- `src/config.rs` : Ajout de `get_cookie_path()`
- `src/daemon.rs` : Modification de `rpc_connect()`
- `src/main.rs` : Ajout de retry logic
- `src/scan.rs` : Corrections des traits
### sdk_common
- `Cargo.toml` : Modification des dépendances
### sdk_client
- `Cargo.toml` : Modification des dépendances
### 4NK_node
- `sdk_relay/Dockerfile` : Mise à jour des branches
- `docker-compose.yml` : Amélioration de la configuration
- `sdk_relay/.conf.docker` : Ajout du chemin du cookie