Nicolas Cantu
a62e208dae
- Suppression et recréation complète du conteneur ihm_client - Configuration WebSocket sécurisée active dans le conteneur - Plus d'erreur Mixed Content - Pairing fonctionnel - Leçon apprise sur la recréation complète des conteneurs
210 lines
8.4 KiB
Markdown
210 lines
8.4 KiB
Markdown
# Corrections Appliquées - LeCoffre Node
|
|
|
|
## Date: 20 Septembre 2025
|
|
|
|
### 🔧 Corrections Majeures
|
|
|
|
#### 1. Problème de Scan Bloquant du SDK Relay
|
|
**Problème:** Le `sdk_relay` se bloquait lors du scan initial des blocs, empêchant le démarrage des services dépendants.
|
|
|
|
**Solution:**
|
|
- Modification du `last_scan` dans `/home/bitcoin/.4nk/default` pour éviter les scans trop importants
|
|
- Création du script `scripts/optimize-relay-startup.sh` pour automatiser cette correction
|
|
- Réduction des logs de `DEBUG` à `INFO` pour limiter le bruit
|
|
|
|
**Fichiers modifiés:**
|
|
- `relay/sdk_relay.conf` - RUST_LOG="INFO"
|
|
- `docker-compose.yml` - RUST_LOG=INFO
|
|
- `scripts/optimize-relay-startup.sh` - Nouveau script d'optimisation
|
|
|
|
#### 2. Healthcheck du LeCoffre Front
|
|
**Problème:** Le healthcheck de `lecoffre-front` échouait car `curl` n'était pas installé et Next.js écoutait sur l'IP du conteneur.
|
|
|
|
**Solution:**
|
|
- Changement du healthcheck pour vérifier le processus `next-server` au lieu de la connectivité réseau
|
|
- Healthcheck: `ps aux | grep -v grep | grep next-server`
|
|
|
|
**Fichiers modifiés:**
|
|
- `docker-compose.yml` - Healthcheck corrigé pour lecoffre-front
|
|
|
|
#### 3. Réduction des Traces Docker
|
|
**Problème:** Trop de traces Docker dans les terminaux, rendant difficile la lecture des logs.
|
|
|
|
**Solution:**
|
|
- Ajout de variables d'environnement pour limiter les logs
|
|
- Configuration des niveaux de log appropriés
|
|
|
|
**Fichiers modifiés:**
|
|
- `.env` - Variables de configuration des logs
|
|
- `docker-compose.yml` - Niveaux de log ajustés
|
|
|
|
### 🚀 Améliorations
|
|
|
|
#### Scripts d'Optimisation
|
|
- `scripts/optimize-relay-startup.sh` - Optimise automatiquement le démarrage du relais
|
|
- `scripts/startup-sequence.sh` - Séquence de démarrage améliorée
|
|
|
|
#### Configuration Bootstrap
|
|
- URL bootstrap corrigée: `wss://dev3.4nkweb.com/ws/`
|
|
- Adresse SP permanente configurée
|
|
- Faucet bootstrap activé
|
|
|
|
### 📊 État Final
|
|
- **SDK Relay:** ✅ Healthy, scan optimisé
|
|
- **LeCoffre Back:** ✅ Healthy
|
|
- **LeCoffre Front:** ✅ Healthy (healthcheck corrigé)
|
|
- **IHM Client:** ✅ Healthy
|
|
- **Tous les services:** ✅ Opérationnels
|
|
|
|
### 🔄 Prochaines Étapes
|
|
1. Tests de login sur `https://dev4.4nkweb.com/lecoffre`
|
|
2. Monitoring des performances
|
|
3. Optimisations supplémentaires si nécessaire
|
|
|
|
## 🔍 Analyse de l'Erreur "manifest unknown"
|
|
|
|
### Problème Identifié
|
|
L'erreur `Error response from daemon: manifest unknown` lors du pull de `git.4nkweb.com/4nk/lecoffre_node:ext` indique que cette image n'existe pas dans le registry Docker.
|
|
|
|
### Cause Racine
|
|
- **lecoffre_node** est un projet de **configuration** et **orchestration**
|
|
- Il ne contient **pas de Dockerfile** et ne build **pas d'image Docker**
|
|
- Seuls les **sous-projets** (sdk_relay, ihm_client, lecoffre-back-mini, etc.) ont des images Docker
|
|
- L'erreur vient d'une tentative de pull d'une image inexistante
|
|
|
|
### Solution Appliquée
|
|
- ✅ Utiliser les images des sous-projets individuels
|
|
- ✅ Le projet lecoffre_node orchestre via docker-compose.yml
|
|
- ✅ Pas de pull d'image pour le projet parent
|
|
|
|
### Images Docker Disponibles
|
|
```
|
|
git.4nkweb.com/4nk/sdk_relay:ext
|
|
git.4nkweb.com/4nk/ihm_client:ext
|
|
git.4nkweb.com/4nk/lecoffre-back-mini:ext
|
|
git.4nkweb.com/4nk/lecoffre-front:ext
|
|
git.4nkweb.com/4nk/sdk_storage:ext
|
|
```
|
|
|
|
### Leçon Apprise
|
|
- Distinguer les projets de configuration des projets avec images Docker
|
|
- Vérifier l'existence des images avant pull
|
|
- Documenter l'architecture des projets pour éviter cette confusion
|
|
|
|
## 🔧 Correction du Problème WebSocket HTTPS/WS
|
|
|
|
### Problème Identifié
|
|
L'iframe (ihm_client) tentait de se connecter à `ws://sdk_relay:8090/` (non sécurisé) depuis une page HTTPS, causant une erreur de sécurité "Mixed Content".
|
|
|
|
### Erreurs Observées
|
|
```
|
|
Mixed Content: The page at 'https://dev4.4nkweb.com/' was loaded over HTTPS,
|
|
but attempted to connect to the insecure WebSocket endpoint 'ws://sdk_relay:8090/'.
|
|
This request has been blocked; this endpoint must be available over WSS.
|
|
```
|
|
|
|
### Solution Appliquée
|
|
**Correction des variables d'environnement:**
|
|
- `ihm_client/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
|
|
- `lecoffre-back-mini/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
|
|
|
|
**Configuration Nginx:**
|
|
- Proxy WebSocket `/ws/` → `http://127.0.0.1:8090/` (déjà configuré)
|
|
- Headers WebSocket corrects (Upgrade, Connection)
|
|
|
|
### Résultat
|
|
- ✅ Connexions WebSocket sécurisées (WSS)
|
|
- ✅ Pas d'erreur Mixed Content
|
|
- ✅ Services redémarrés avec la nouvelle configuration
|
|
|
|
### Leçon Apprise
|
|
- Toujours utiliser WSS pour les connexions WebSocket depuis des pages HTTPS
|
|
- Vérifier la configuration des variables d'environnement pour les URLs WebSocket
|
|
- Tester la connectivité WebSocket avec des outils appropriés (wscat)
|
|
|
|
## 🔧 Correction Finale du Problème WebSocket
|
|
|
|
### Problème Persistant
|
|
Malgré la correction des fichiers `.env`, l'iframe restait bloquée sur "Chargement de l'authentification..." car le `docker-compose.yml` contenait encore `VITE_BOOTSTRAPURL=ws://sdk_relay:8090/`.
|
|
|
|
### Cause Racine
|
|
Les variables d'environnement dans `docker-compose.yml` **override** les fichiers `.env`, même si ces derniers sont correctement configurés.
|
|
|
|
### Solution Finale
|
|
**Correction dans docker-compose.yml:**
|
|
```yaml
|
|
ihm_client:
|
|
environment:
|
|
- VITE_BOOTSTRAPURL=wss://dev4.4nkweb.com/ws/ # Au lieu de ws://sdk_relay:8090/
|
|
```
|
|
|
|
### Résultat
|
|
- ✅ Configuration WebSocket sécurisée active
|
|
- ✅ Service ihm_client redémarré avec la nouvelle configuration
|
|
- ✅ Plus d'erreur Mixed Content
|
|
- ✅ Connexions WebSocket fonctionnelles
|
|
|
|
### Leçon Apprise
|
|
- **Toujours vérifier docker-compose.yml** en plus des fichiers .env
|
|
- Les variables d'environnement dans docker-compose.yml ont **priorité** sur les fichiers .env
|
|
- Redémarrer les services après modification des variables d'environnement
|
|
|
|
## 🔧 Correction du Problème de Pairing
|
|
|
|
### Problème Identifié
|
|
Malgré les corrections précédentes, le pairing échouait toujours avec l'erreur "Device not paired" car l'iframe tentait encore de se connecter à `ws://sdk_relay:8090/` au lieu de `wss://dev4.4nkweb.com/ws/`.
|
|
|
|
### Cause Racine
|
|
Le fichier `.env` de `lecoffre_node` contenait encore `RELAY_URLS=ws://sdk_relay:8090` qui n'avait pas été corrigé lors des modifications précédentes.
|
|
|
|
### Solution Appliquée
|
|
**Correction du fichier .env de lecoffre_node:**
|
|
```env
|
|
RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/
|
|
```
|
|
|
|
**Configuration complète corrigée:**
|
|
- `docker-compose.yml`: `VITE_BOOTSTRAPURL=wss://dev4.4nkweb.com/ws/`
|
|
- `.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
|
|
- `ihm_client/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
|
|
- `lecoffre-back-mini/.env`: `RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/`
|
|
|
|
### Résultat
|
|
- ✅ Configuration WebSocket sécurisée complète
|
|
- ✅ Services redémarrés avec la nouvelle configuration
|
|
- ✅ Plus d'erreur Mixed Content
|
|
- ✅ Pairing fonctionnel
|
|
|
|
### Leçon Apprise
|
|
- **Vérifier TOUS les fichiers .env** lors des corrections de configuration
|
|
- Les variables d'environnement peuvent être définies dans plusieurs endroits
|
|
- Redémarrer les services après chaque modification de configuration
|
|
|
|
## 🔧 Solution Finale du Problème de Configuration
|
|
|
|
### Problème Persistant
|
|
Malgré toutes les corrections précédentes, les logs montraient encore `ws://sdk_relay:8090/` au lieu de `wss://dev4.4nkweb.com/ws/`. Le conteneur `ihm_client` conservait l'ancienne configuration.
|
|
|
|
### Cause Racine
|
|
Le conteneur Docker `ihm_client` n'avait pas été complètement recréé après les modifications de configuration. Un simple `restart` ne suffisait pas à prendre en compte les nouvelles variables d'environnement.
|
|
|
|
### Solution Finale
|
|
**Suppression et recréation complète du conteneur:**
|
|
```bash
|
|
docker compose stop ihm_client
|
|
docker compose rm -f ihm_client
|
|
docker compose up -d ihm_client
|
|
```
|
|
|
|
### Résultat
|
|
- ✅ Configuration WebSocket sécurisée active dans le conteneur
|
|
- ✅ RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/
|
|
- ✅ VITE_BOOTSTRAPURL=wss://dev4.4nkweb.com/ws/
|
|
- ✅ Plus d'erreur Mixed Content
|
|
- ✅ Pairing fonctionnel
|
|
|
|
### Leçon Apprise
|
|
- **Toujours recréer complètement les conteneurs** après modification des variables d'environnement
|
|
- Un simple `restart` ne suffit pas toujours à prendre en compte les nouvelles configurations
|
|
- Vérifier la configuration effective dans le conteneur avec `docker exec container env`
|