- Correction de l'erreur Mixed Content - Configuration des URLs WebSocket sécurisées (WSS) - Documentation de la solution appliquée - Leçons apprises pour éviter ce problème
124 lines
4.7 KiB
Markdown
124 lines
4.7 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)
|