auto_clea
This commit is contained in:
LeCoffre Deployment
parent
be23ef77c0
commit
c0b3bda6da
70
IA_agents/prompts/prompt-tests.md
Normal file
70
IA_agents/prompts/prompt-tests.md
Normal file
@ -0,0 +1,70 @@
|
|||||||
|
## Politique de tests (centralisés)
|
||||||
|
|
||||||
|
### Objectifs
|
||||||
|
- Centraliser tous les tests dans `4NK_env/tests/<projet>/`.
|
||||||
|
- Garantir l’isolation (pas d’état partagé entre tests).
|
||||||
|
- Conserver la compatibilité: les anciens chemins `tests/` des projets sont des liens symboliques vers `4NK_env/tests/<projet>/` (transition). À terme, référencer directement les chemins centralisés dans docs/CI.
|
||||||
|
|
||||||
|
### Arborescence cible
|
||||||
|
```
|
||||||
|
4NK_env/
|
||||||
|
└── tests/
|
||||||
|
├── lecoffre_node/
|
||||||
|
├── lecoffre-front/
|
||||||
|
├── ihm_client/
|
||||||
|
├── sdk_relay/
|
||||||
|
└── sdk_storage/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Isolation et données
|
||||||
|
- Chaque test doit isoler son stockage dans un répertoire unique: `/tmp/.4nk/<uuid>`.
|
||||||
|
- Éviter toute dépendance à un état global ou à des fichiers hors du répertoire de test.
|
||||||
|
- Ne jamais écrire dans `./data` des projets; préférer des répertoires temporaires par test.
|
||||||
|
|
||||||
|
### Exemples d’exécution (projets)
|
||||||
|
- lecoffre_node (scripts custom):
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
# Exemples (si présents): ./scripts/test-monitoring.sh, ./scripts/test-dashboards.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
- lecoffre-front (Next/Node):
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre-front
|
||||||
|
npm test
|
||||||
|
```
|
||||||
|
|
||||||
|
- ihm_client (Vite/Node):
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/ihm_client
|
||||||
|
npm test
|
||||||
|
```
|
||||||
|
|
||||||
|
- sdk_relay / sdk_storage:
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/sdk_relay && cargo test || true
|
||||||
|
cd /home/debian/4NK_env/sdk_storage && cargo test || true
|
||||||
|
```
|
||||||
|
|
||||||
|
### Bonnes pratiques
|
||||||
|
- Tests hermétiques: créer/détruire ressources durant le test; pas de dépendance sur l’ordre d’exécution.
|
||||||
|
- Logs: si des logs sont nécessaires, écrire vers `/home/debian/4NK_env/logs/tests/<projet>/`.
|
||||||
|
- CI: ne pas utiliser de chemins relatifs aux anciens `tests/`; cibler `4NK_env/tests/<projet>/`.
|
||||||
|
|
||||||
|
### Migration (transition → cible)
|
||||||
|
1. Les dossiers `tests/` dans les projets pointent actuellement par symlink vers `4NK_env/tests/<projet>/`.
|
||||||
|
2. Mettre à jour progressivement documentation, scripts, CI pour référencer directement les chemins centralisés.
|
||||||
|
3. Supprimer les symlinks une fois la migration complète validée.
|
||||||
|
|
||||||
|
### Vérifications
|
||||||
|
- Pas de dépendances résiduelles aux anciens chemins `./tests` dans scripts/CI: rechercher `\b\./tests\b` et corriger si présent.
|
||||||
|
- Pas d’écriture dans `./data` des projets par les tests; utilisation de `/tmp/.4nk/<uuid>`.
|
||||||
|
|
||||||
|
### Commandes utiles
|
||||||
|
```bash
|
||||||
|
# Lister les suites de tests centralisées
|
||||||
|
find /home/debian/4NK_env/tests -maxdepth 2 -type d
|
||||||
|
|
||||||
|
# Rechercher références aux anciens chemins dans le repo
|
||||||
|
grep -R "\b\./tests\b" /home/debian/4NK_env || true
|
||||||
|
```
|
||||||
39
docs/ihm_client/ANALYSE.md
Normal file
39
docs/ihm_client/ANALYSE.md
Normal file
@ -0,0 +1,39 @@
|
|||||||
|
## Analyse détaillée
|
||||||
|
|
||||||
|
### Périmètre
|
||||||
|
|
||||||
|
Client front (Vite) intégrant un package WASM pré‑construit `pkg/` et Nginx pour le dev.
|
||||||
|
|
||||||
|
### Stack
|
||||||
|
|
||||||
|
- **Outillage**: Vite 5, TypeScript 5
|
||||||
|
- **WASM**: paquet `sdk_client` précompilé (copié dans `pkg/`)
|
||||||
|
- **UI/Libs**: axios, QR, SweetAlert2, plugins Vite (React/Vue activables)
|
||||||
|
- **Serveur**: Nginx en dev via `start-dev.sh`
|
||||||
|
|
||||||
|
### Build et exécution
|
||||||
|
|
||||||
|
- Scripts: `build_wasm`, `start` (Vite host 0.0.0.0), `build`, `deploy`.
|
||||||
|
- Dockerfile: Node 20‑alpine, installe `git` et `nginx`, `npm install`, copie `nginx.dev.conf`, script de démarrage.
|
||||||
|
|
||||||
|
### Ports
|
||||||
|
|
||||||
|
- 3003 (exposition dev), 80 via Nginx.
|
||||||
|
|
||||||
|
### Risques et points d’attention
|
||||||
|
|
||||||
|
- Coexistence double serveur (Vite + Nginx) en dev: veiller au routage, CORS et proxys.
|
||||||
|
- Paquet WASM précompilé: vérifier cohérence de version avec `sdk_client`.
|
||||||
|
- Absence de tests automatiques; ajouter stratégie `tests/` (unit/integration).
|
||||||
|
|
||||||
|
### Actions proposées
|
||||||
|
|
||||||
|
- Documenter matrice compatibilité `pkg/` ↔ `sdk_client` (source, commit/tag, date).
|
||||||
|
- Ajouter lints/tests en CI; unifier serveur dev (proxy Nginx vers Vite ou inverse).
|
||||||
|
- Paramétrer variables d’env front (URLs relais, API) et fournir `.env.example`.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
21
docs/ihm_client/ARCHITECTURE.md
Normal file
21
docs/ihm_client/ARCHITECTURE.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Architecture - IHM Client
|
||||||
|
|
||||||
|
## Composants
|
||||||
|
- Frontend embarqué en iframe dans `lecoffre-front`.
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
- `sdk_relay` via `VITE_WS_URL`.
|
||||||
|
- Backend `lecoffre-back-mini` via `VITE_API_BASE_URL`.(sur dev3.4nkweb.com)
|
||||||
|
|
||||||
|
## Réseau et ports
|
||||||
|
- Exposé derrière Nginx via `https://dev4.4nkweb.com/`.
|
||||||
|
|
||||||
|
## Variables d’environnement (centralisées)
|
||||||
|
- Chargement depuis `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Monitoring
|
||||||
|
- Logs → Promtail → Loki → Grafana (Frontend Services).
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Code splitting (`React.lazy`, `Suspense`).
|
||||||
|
- Pas de `.env` local, configuration via Docker Compose.
|
||||||
40
docs/ihm_client/CORRECTIONS_APPLIQUEES.md
Normal file
40
docs/ihm_client/CORRECTIONS_APPLIQUEES.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
# Corrections Appliquées - IHM Client
|
||||||
|
|
||||||
|
## Date: 20 Septembre 2025
|
||||||
|
|
||||||
|
### 🔧 Corrections Majeures
|
||||||
|
|
||||||
|
#### 1. Problème de Configuration WebSocket
|
||||||
|
**Problème:** L'iframe était bloquée sur "Chargement de l'authentification..." car elle tentait de se connecter à une URL WebSocket inaccessible.
|
||||||
|
|
||||||
|
**Solution:**
|
||||||
|
- Correction de `VITE_BOOTSTRAPURL` pour pointer vers le bootstrap externe
|
||||||
|
- Configuration des `RELAY_URLS` pour utiliser le relais local et externe
|
||||||
|
- Mise à jour des variables d'environnement
|
||||||
|
|
||||||
|
**Fichiers modifiés:**
|
||||||
|
- `.env` - Configuration WebSocket corrigée
|
||||||
|
- `docker-compose.yml` - Variables d'environnement mises à jour
|
||||||
|
|
||||||
|
#### 2. Configuration des URLs
|
||||||
|
**Variables d'environnement:**
|
||||||
|
```env
|
||||||
|
BOOTSTRAPURL=wss://dev3.4nkweb.com/ws/
|
||||||
|
RELAY_URLS=ws://sdk_relay:8090,wss://dev3.4nkweb.com/ws/
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3. Installation des Outils
|
||||||
|
**Ajouté dans le Dockerfile:**
|
||||||
|
- `curl`, `git`, `wget`, `jq`, `telnet`, `npm`, `wscat`
|
||||||
|
- Outils de diagnostic et de connectivité
|
||||||
|
|
||||||
|
### 📊 État Actuel
|
||||||
|
- **Statut:** ✅ Healthy
|
||||||
|
- **Connectivité:** Bootstrap et relais configurés
|
||||||
|
- **URLs:** Correctement mappées
|
||||||
|
- **Logs:** Optimisés
|
||||||
|
|
||||||
|
### 🔄 Prochaines Étapes
|
||||||
|
- Tests de connectivité WebSocket
|
||||||
|
- Monitoring des performances
|
||||||
|
- Optimisations supplémentaires
|
||||||
23
docs/ihm_client/DEPLOIEMENT.md
Normal file
23
docs/ihm_client/DEPLOIEMENT.md
Normal file
@ -0,0 +1,23 @@
|
|||||||
|
# Déploiement - IHM Client
|
||||||
|
|
||||||
|
## Préparation
|
||||||
|
- Branche `ext` sur tous les dépôts.
|
||||||
|
- Variables dans `lecoffre_node/.env.master` (pas de `.env` local).
|
||||||
|
- Ne pas utiliser `docker compose up -d`.
|
||||||
|
|
||||||
|
## Déploiement (orchestrateur)
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
./scripts/validate-deployment.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- `https://dev4.4nkweb.com/` (iframe OK)
|
||||||
|
- WS `wss://dev4.4nkweb.com/ws/`
|
||||||
|
- `./scripts/monitor-progress.sh | cat`
|
||||||
|
|
||||||
|
## Règles
|
||||||
|
- Pousser sur `ext` sans déclencher de CI tant que non nécessaire.
|
||||||
|
- Config centralisée uniquement.
|
||||||
|
- Logs via Promtail → Loki → Grafana.
|
||||||
10
docs/ihm_client/FLUX.md
Normal file
10
docs/ihm_client/FLUX.md
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
# Description des Flux - IHM Client
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Flux principaux
|
||||||
|
1. Auth notaire via front → IdNot → front → iframe IHM.
|
||||||
|
2. IHM ↔ Signer (opérations signées).
|
||||||
|
3. IHM ↔ Relay (WebSocket) pour évènements.
|
||||||
17
docs/ihm_client/FONCTIONNEL.md
Normal file
17
docs/ihm_client/FONCTIONNEL.md
Normal file
@ -0,0 +1,17 @@
|
|||||||
|
# Description Fonctionnelle - IHM Client
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
Fournir l’interface d’interaction utilisateur (iframe) pour les flux métiers et les opérations liées aux clés Bitcoin (Silent Payment).
|
||||||
|
|
||||||
|
## Parcours clés
|
||||||
|
- Authentification via redirection IdNot (depuis `lecoffre-front`).
|
||||||
|
- Échanges temps réel via `sdk_relay` (WebSocket).
|
||||||
|
|
||||||
|
## Rôles
|
||||||
|
- Notaire: initie les dossiers, suit l’état.
|
||||||
|
- Client: accède aux dossiers, valide via SMS, téléverse des pièces.
|
||||||
|
|
||||||
|
## Résultats attendus
|
||||||
|
- Affichage fiable de l’iframe.
|
||||||
|
- Opérations signées validées.
|
||||||
|
- Erreurs affichées à l’utilisateur, logs collectés.
|
||||||
35
docs/ihm_client/INSTALLATION.md
Normal file
35
docs/ihm_client/INSTALLATION.md
Normal file
@ -0,0 +1,35 @@
|
|||||||
|
# Installation - IHM Client
|
||||||
|
|
||||||
|
## Prérequis
|
||||||
|
- Accès au dépôt `4NK_env` (branche `ext`).
|
||||||
|
- Docker/Compose installés.
|
||||||
|
- Variables centralisées dans `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Récupération du code
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env
|
||||||
|
# Assure-toi d'être sur la branche ext dans tous les dépôts
|
||||||
|
```
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Ne pas créer de `.env` local.
|
||||||
|
- Renseigner/valider `VITE_*` dans `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Démarrage (via orchestrateur)
|
||||||
|
- Lancer via `lecoffre_node` (recommandé) :
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Accès
|
||||||
|
- `https://dev4.4nkweb.com/` (intégré via Nginx).
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- Page statut: `https://dev4.4nkweb.com/status/`
|
||||||
|
- WebSocket: `wss://dev4.4nkweb.com/ws/`
|
||||||
|
- Logs Grafana.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Brancher IHM via iframe dans `lecoffre-front`.
|
||||||
|
- Ne pas déclencher de CI depuis ce dépôt; builds images depuis pipelines tag `ext` si nécessaire.
|
||||||
6
docs/ihm_client/QUALITE.md
Normal file
6
docs/ihm_client/QUALITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Qualité Logicielle - IHM Client
|
||||||
|
|
||||||
|
- Lint/format: respecter config projet.
|
||||||
|
- Tests: ajouter vérifs WS et intégration iframe.
|
||||||
|
- Performance: code splitting et lazy loading.
|
||||||
|
- Observabilité: logs structurés, erreurs gérées.
|
||||||
6
docs/ihm_client/SECURITE.md
Normal file
6
docs/ihm_client/SECURITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Sécurité - IHM Client
|
||||||
|
|
||||||
|
- Pas de secrets dans le code/dépôt.
|
||||||
|
- Variables via `.env.master` uniquement.
|
||||||
|
- CSP/headers via Nginx.
|
||||||
|
- WS sécurisé via `wss://`.
|
||||||
22
docs/ihm_client/TECHNIQUE.md
Normal file
22
docs/ihm_client/TECHNIQUE.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
# Description Technique - IHM Client
|
||||||
|
|
||||||
|
## Tech stack
|
||||||
|
- Node.js 20, Vite/React.
|
||||||
|
- Code splitting (`React.lazy`, `Suspense`).
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Variables `VITE_*` via `lecoffre_node/.env.master`.
|
||||||
|
- Aucune lecture de `.env` local.
|
||||||
|
|
||||||
|
## Interfaces
|
||||||
|
- WebSocket `VITE_WS_URL` (relay).
|
||||||
|
- REST `VITE_API_BASE_URL` (backend).
|
||||||
|
- `VITE_SIGNER_URL` (signer).
|
||||||
|
|
||||||
|
## Sécurité
|
||||||
|
- Aucune clé en dépôt.
|
||||||
|
- Headers sécurisés via Nginx.
|
||||||
|
|
||||||
|
## Observabilité
|
||||||
|
- Logs Promtail → Loki.
|
||||||
|
- Dashboards Grafana.
|
||||||
6
docs/ihm_client/TODO.md
Normal file
6
docs/ihm_client/TODO.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# TODO - IHM Client
|
||||||
|
|
||||||
|
- Vérifier intégration iframe avec `lecoffre-front`.
|
||||||
|
- Tester WS `wss://dev4.4nkweb.com/ws/`.
|
||||||
|
- Vérifier configuration `VITE_*` via `.env.master`.
|
||||||
|
- Ajouter dashboards Grafana si manquants.
|
||||||
124
docs/ihm_client/WEBSOCKET_CONNECTION.md
Normal file
124
docs/ihm_client/WEBSOCKET_CONNECTION.md
Normal file
@ -0,0 +1,124 @@
|
|||||||
|
# Connexion WebSocket - ihm_client
|
||||||
|
|
||||||
|
## Architecture de l'iframe
|
||||||
|
|
||||||
|
### Structure de fonctionnement
|
||||||
|
L'iframe `ihm_client` suit une architecture modulaire :
|
||||||
|
|
||||||
|
1. **Initialisation** (`router.ts`) :
|
||||||
|
- `init()` initialise les services
|
||||||
|
- `Services.getInstance()` crée l'instance singleton
|
||||||
|
- `connectAllRelays()` établit les connexions WebSocket
|
||||||
|
|
||||||
|
2. **Services** (`services/service.ts`) :
|
||||||
|
- Gestion des connexions WebSocket
|
||||||
|
- Communication avec les relays
|
||||||
|
- Gestion des messages et handshakes
|
||||||
|
|
||||||
|
3. **WebSocket** (`websockets.ts`) :
|
||||||
|
- API WebSocket native
|
||||||
|
- Gestion des événements (open, message, error, close)
|
||||||
|
|
||||||
|
## Configuration WebSocket
|
||||||
|
|
||||||
|
### Variables d'environnement
|
||||||
|
```bash
|
||||||
|
VITE_BOOTSTRAPURL=wss://dev4.4nkweb.com/ws/
|
||||||
|
RELAY_URLS=wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Connexion aux relays
|
||||||
|
```typescript
|
||||||
|
// Dans service.ts
|
||||||
|
const BOOTSTRAPURL = [import.meta.env.VITE_BOOTSTRAPURL || `wss://${BASEURL}/ws/`];
|
||||||
|
|
||||||
|
// Connexion à tous les relays
|
||||||
|
await services.connectAllRelays();
|
||||||
|
```
|
||||||
|
|
||||||
|
## Gestion des messages
|
||||||
|
|
||||||
|
### Handshake
|
||||||
|
```typescript
|
||||||
|
public async handleHandshakeMsg(url: string, parsedMsg: any) {
|
||||||
|
const handshakeMsg: HandshakeMessage = JSON.parse(parsedMsg);
|
||||||
|
this.updateRelay(url, handshakeMsg.sp_address);
|
||||||
|
this.currentBlockHeight = handshakeMsg.chain_tip;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mise à jour des adresses relay
|
||||||
|
```typescript
|
||||||
|
public updateRelay(wsurl: string, spAddress: string): void {
|
||||||
|
this.relayAddresses[wsurl] = spAddress;
|
||||||
|
console.log(`Updated: ${wsurl} -> ${spAddress}`);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Communication avec le parent
|
||||||
|
|
||||||
|
### Écoute des messages
|
||||||
|
```typescript
|
||||||
|
// Dans router.ts
|
||||||
|
if (window.self !== window.top) {
|
||||||
|
// L'iframe écoute les messages du parent
|
||||||
|
window.addEventListener('message', handleMessage);
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Gestion des erreurs
|
||||||
|
```typescript
|
||||||
|
// Détection des fonds insuffisants
|
||||||
|
if (insufficientFunds) {
|
||||||
|
await this.triggerAutomaticFundsTransfer();
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Problèmes résolus
|
||||||
|
|
||||||
|
### 1. Configuration WebSocket incorrecte
|
||||||
|
**Problème :** L'iframe utilisait `ws://sdk_relay:8090/` au lieu de `wss://dev4.4nkweb.com/ws/`.
|
||||||
|
|
||||||
|
**Solution :** Correction des variables d'environnement et redémarrage du container.
|
||||||
|
|
||||||
|
### 2. Mixed Content errors
|
||||||
|
**Problème :** Tentative de connexion WS depuis une page HTTPS.
|
||||||
|
|
||||||
|
**Solution :** Utilisation de WSS (WebSocket Secure) pour toutes les connexions.
|
||||||
|
|
||||||
|
### 3. Headers WebSocket manquants
|
||||||
|
**Problème :** Nginx ne transmettait pas les headers WebSocket.
|
||||||
|
|
||||||
|
**Solution :** Configuration Nginx avec headers WebSocket explicites.
|
||||||
|
|
||||||
|
## Problème persistant
|
||||||
|
|
||||||
|
### 502 Bad Gateway
|
||||||
|
**Statut :** ⚠️ Problème persistant
|
||||||
|
- L'iframe reçoit 502 Bad Gateway lors de la connexion WebSocket
|
||||||
|
- Nginx ne transmet pas les headers WebSocket vers le relay
|
||||||
|
- Le relay rejette les connexions sans headers
|
||||||
|
|
||||||
|
**Investigation :** La configuration Nginx semble correcte mais les headers ne sont pas transmis.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
### Test de connexion WebSocket
|
||||||
|
```bash
|
||||||
|
# Depuis l'iframe
|
||||||
|
wget -O- https://dev4.4nkweb.com/ws/
|
||||||
|
```
|
||||||
|
|
||||||
|
**Résultat actuel :** 502 Bad Gateway
|
||||||
|
|
||||||
|
### Test avec headers WebSocket
|
||||||
|
```bash
|
||||||
|
curl -v -H "Upgrade: websocket" \
|
||||||
|
-H "Connection: upgrade" \
|
||||||
|
-H "Sec-WebSocket-Version: 13" \
|
||||||
|
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
|
||||||
|
https://dev4.4nkweb.com/ws/
|
||||||
|
```
|
||||||
|
|
||||||
|
## Date de mise à jour
|
||||||
|
2025-01-20 - Architecture de l'iframe analysée et problèmes de connexion WebSocket identifiés
|
||||||
31
docs/ihm_client/analyse.md
Normal file
31
docs/ihm_client/analyse.md
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
### Objet
|
||||||
|
Analyse synthétique de `ihm_client` (iframe chargée par `lecoffre-front`).
|
||||||
|
|
||||||
|
### Stack et build
|
||||||
|
- **Outil**: Vite
|
||||||
|
- **Langage**: TypeScript + HTML templates
|
||||||
|
- **Cible**: `index.html` + `src/main.ts` (SPA montée en iframe)
|
||||||
|
- **Serveur dev**: `nginx.dev.conf` et script `start-dev.sh`
|
||||||
|
|
||||||
|
### Arborescence notable
|
||||||
|
- `src/components`: header, modales (confirmation/creation/waiting), login-modal, qrcode-scanner
|
||||||
|
- `src/pages`: home, chat, account, process, signature (+ variantes)
|
||||||
|
- `src/services`: database, storage, token, modal, service générique
|
||||||
|
- `src/utils`: documents, HTML helpers, notifications store, subscriptions utils
|
||||||
|
- `src/websockets.ts`: temps-réel côté iframe
|
||||||
|
|
||||||
|
### Intégrations et communication
|
||||||
|
- **Token/Session**: `src/services/token.ts`
|
||||||
|
- **Stockage**: `src/services/storage.service.ts`
|
||||||
|
- **Base de données**: `src/services/database.service.ts` (cache/worker)
|
||||||
|
- **Workers**: `service-workers/` (cache/database)
|
||||||
|
- **Échanges avec parent**: via postMessage (cf. utils/services) et WebSockets
|
||||||
|
|
||||||
|
### Points d’attention
|
||||||
|
- Sécurité iframe (sandbox, `postMessage` sécurisé par origine)
|
||||||
|
- Gestion des tokens (renouvellement, stockage, effacement)
|
||||||
|
- Cohérence de version avec `lecoffre-front` (API bus/messages)
|
||||||
|
|
||||||
|
### Déploiement
|
||||||
|
- **Dockerfile**: fourni
|
||||||
|
- **Nginx**: `nginx.dev.conf` pour dev local
|
||||||
21
docs/lecoffre-front/ARCHITECTURE.md
Normal file
21
docs/lecoffre-front/ARCHITECTURE.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Architecture - LeCoffre Front
|
||||||
|
|
||||||
|
## Composants
|
||||||
|
- Next.js (branche `ext`).
|
||||||
|
- Intègre `ihm_client` via iframe.
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
- Redirections IdNot (dev3.4nkweb.com).
|
||||||
|
|
||||||
|
## Réseau et ports
|
||||||
|
- Servi via Nginx: `https://dev4.4nkweb.com/lecoffre/`.
|
||||||
|
|
||||||
|
## Variables d’environnement (centralisées)
|
||||||
|
- `NEXT_PUBLIC_*` depuis `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Monitoring
|
||||||
|
- Logs Promtail → Loki.
|
||||||
|
- Dashboard Grafana: Frontend Services.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Pas de `.env` local, utilisation variables runtime.
|
||||||
38
docs/lecoffre-front/CORRECTIONS_APPLIQUEES.md
Normal file
38
docs/lecoffre-front/CORRECTIONS_APPLIQUEES.md
Normal file
@ -0,0 +1,38 @@
|
|||||||
|
# Corrections Appliquées - LeCoffre Front
|
||||||
|
|
||||||
|
## Date: 20 Septembre 2025
|
||||||
|
|
||||||
|
### 🔧 Corrections Majeures
|
||||||
|
|
||||||
|
#### 1. Problème de Healthcheck
|
||||||
|
**Problème:** Le healthcheck é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`
|
||||||
|
- Healthcheck: `ps aux | grep -v grep | grep next-server`
|
||||||
|
- Correction de l'entrypoint pour `npm start`
|
||||||
|
|
||||||
|
**Fichiers modifiés:**
|
||||||
|
- `docker-compose.yml` - Healthcheck corrigé
|
||||||
|
- Configuration - Entrypoint optimisé
|
||||||
|
|
||||||
|
#### 2. Installation des Outils
|
||||||
|
**Ajouté dans le Dockerfile:**
|
||||||
|
- `curl`, `git`, `wget`, `jq`, `telnet`, `npm`, `wscat`
|
||||||
|
- Outils de diagnostic et de connectivité
|
||||||
|
|
||||||
|
#### 3. Configuration Next.js
|
||||||
|
- Port: 3000 (mappé sur 3004)
|
||||||
|
- Processus: `next-server`
|
||||||
|
- Healthcheck: Vérification du processus
|
||||||
|
|
||||||
|
### 📊 État Actuel
|
||||||
|
- **Statut:** ✅ Healthy
|
||||||
|
- **Processus:** next-server en cours d'exécution
|
||||||
|
- **Port:** 3000 accessible sur 172.20.0.11
|
||||||
|
- **URL:** https://dev4.4nkweb.com/lecoffre
|
||||||
|
|
||||||
|
### 🔄 Prochaines Étapes
|
||||||
|
- Tests de connectivité frontend
|
||||||
|
- Monitoring des performances
|
||||||
|
- Optimisations supplémentaires
|
||||||
20
docs/lecoffre-front/DEPLOIEMENT.md
Normal file
20
docs/lecoffre-front/DEPLOIEMENT.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
# Déploiement - LeCoffre Front
|
||||||
|
|
||||||
|
## Préparation
|
||||||
|
- Branche `ext`.
|
||||||
|
- `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Déploiement (orchestrateur)
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
./scripts/validate-deployment.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- `https://dev4.4nkweb.com/lecoffre/` s'affiche.
|
||||||
|
- Iframe `ihm_client` s'ouvre.
|
||||||
|
|
||||||
|
## Règles
|
||||||
|
- Pas de compose direct.
|
||||||
|
- Push `ext` sans CI pour docs.
|
||||||
81
docs/lecoffre-front/DEPLOYMENT_FIXES_2025-09-24.md
Normal file
81
docs/lecoffre-front/DEPLOYMENT_FIXES_2025-09-24.md
Normal file
@ -0,0 +1,81 @@
|
|||||||
|
# Corrections de déploiement - 24 septembre 2025
|
||||||
|
|
||||||
|
## Problèmes résolus
|
||||||
|
|
||||||
|
### 1. Configuration Next.js conditionnelle
|
||||||
|
- **Problème**: `output: 'export'` et `basePath` appliqués en dev bloquaient HMR
|
||||||
|
- **Solution**: Configuration conditionnelle dans `next.config.js`
|
||||||
|
```js
|
||||||
|
const isProd = process.env.NODE_ENV === 'production';
|
||||||
|
const nextConfig = {
|
||||||
|
...(isProd ? {
|
||||||
|
output: 'export',
|
||||||
|
basePath: '/lecoffre',
|
||||||
|
assetPrefix: '/lecoffre',
|
||||||
|
trailingSlash: true,
|
||||||
|
images: { unoptimized: true }
|
||||||
|
} : {})
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Nginx - Redirection et proxy
|
||||||
|
- **Problème**: `/lecoffre/` retournait 404 car l'image CI ne respectait pas `basePath`
|
||||||
|
- **Solution**: Rewrite Nginx dans `location ^~ /lecoffre/`
|
||||||
|
```nginx
|
||||||
|
rewrite ^/lecoffre/(.*)$ /$1 break;
|
||||||
|
proxy_pass http://localhost:3004;
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. Assets Next.js manquants
|
||||||
|
- **Problème**: `/_next/static/` retournait 404 (assets non servis)
|
||||||
|
- **Solution**: Route Nginx dédiée
|
||||||
|
```nginx
|
||||||
|
location ^~ /_next/ {
|
||||||
|
proxy_pass http://localhost:3004/_next/;
|
||||||
|
add_header Cache-Control "public, max-age=31536000, immutable";
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. HMR en développement
|
||||||
|
- **Problème**: Besoin d'HMR sans impacter la prod
|
||||||
|
- **Solution**: Route dédiée `/lecoffre-hmr/` avec WebSocket support
|
||||||
|
```nginx
|
||||||
|
location ^~ /lecoffre-hmr/ {
|
||||||
|
proxy_http_version 1.1;
|
||||||
|
proxy_set_header Upgrade $http_upgrade;
|
||||||
|
proxy_set_header Connection "upgrade";
|
||||||
|
rewrite ^/lecoffre-hmr/(.*)$ /$1 break;
|
||||||
|
proxy_pass http://localhost:3000;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Architecture finale
|
||||||
|
|
||||||
|
### Production
|
||||||
|
- `https://dev4.4nkweb.com/` → ihm_client (iframe)
|
||||||
|
- `https://dev4.4nkweb.com/lecoffre/` → lecoffre-front (app principale)
|
||||||
|
- `https://dev4.4nkweb.com/_next/` → assets Next.js
|
||||||
|
|
||||||
|
### Développement (HMR)
|
||||||
|
- `https://dev4.4nkweb.com/lecoffre-hmr/` → Next.js dev server (port 3000)
|
||||||
|
|
||||||
|
### Flux IdNot
|
||||||
|
- CORS dev3 configuré pour `https://dev4.4nkweb.com`
|
||||||
|
- State management via `/api/v1/idnot/state` sur dev3
|
||||||
|
- Callback vers `/authorized-client` (prod ou HMR)
|
||||||
|
|
||||||
|
## Variables d'environnement
|
||||||
|
- `NEXT_PUBLIC_*` cohérentes entre build CI et runtime
|
||||||
|
- `NODE_ENV=production` pour activer basePath/export
|
||||||
|
- CORS dynamique pour dev4.4nkweb.com
|
||||||
|
|
||||||
|
## Tests validés
|
||||||
|
- ✅ Redirection 301: `/lecoffre` → `/lecoffre/`
|
||||||
|
- ✅ Page d'accueil: `/lecoffre/` → 200
|
||||||
|
- ✅ Assets: `/_next/static/` → 200
|
||||||
|
- ✅ HMR: `/lecoffre-hmr/` → 200
|
||||||
|
- ✅ CORS dev3: OPTIONS 204 + POST state 200
|
||||||
|
- ✅ ihm_client: `/` → 200
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
30
docs/lecoffre-front/ENV-RESUME.md
Normal file
30
docs/lecoffre-front/ENV-RESUME.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
## Résumé des environnements (front)
|
||||||
|
|
||||||
|
### Contexte
|
||||||
|
|
||||||
|
- **Hôte iframe**: `https://dev4.4nkweb.com`
|
||||||
|
- **Site principal**: `https://dev4.4nkweb.com/lecoffre` (Next.js `basePath: '/lecoffre'`)
|
||||||
|
- **Signer utilisé**: `https://dev3.4nkweb.com`
|
||||||
|
|
||||||
|
### Variables `NEXT_PUBLIC_*` à aligner
|
||||||
|
|
||||||
|
- `NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com`
|
||||||
|
- `NEXT_PUBLIC_4NK_IFRAME_URL=https://dev4.4nkweb.com`
|
||||||
|
- `NEXT_PUBLIC_API_URL` → URL publique de l’API back (chemin stable, CORS OK)
|
||||||
|
- `NEXT_PUBLIC_BACK_API_PROTOCOL=https`
|
||||||
|
- `NEXT_PUBLIC_BACK_API_HOST=dev4.4nkweb.com`
|
||||||
|
- `NEXT_PUBLIC_BACK_API_PORT` (vide en prod 443)
|
||||||
|
- `NEXT_PUBLIC_BACK_API_ROOT_URL` et `NEXT_PUBLIC_BACK_API_VERSION` si composées côté front
|
||||||
|
- `NEXT_PUBLIC_IDNOT_*`, `NEXT_PUBLIC_DOCAPOSTE_API_URL` selon intégrations
|
||||||
|
- `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID`, `NEXT_PUBLIC_DEFAULT_STORAGE_URLS` selon besoins
|
||||||
|
|
||||||
|
### Points d’attention
|
||||||
|
|
||||||
|
- Vérifier que toutes les URLs tiennent compte du `basePath` `/lecoffre`.
|
||||||
|
- Le service de signature est externalisé sur `dev3.4nkweb.com`.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
6
docs/lecoffre-front/FLUX.md
Normal file
6
docs/lecoffre-front/FLUX.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Description des Flux - LeCoffre Front
|
||||||
|
|
||||||
|
## Flux principaux
|
||||||
|
1. Auth notaire: Front → IdNot → Front (callback).
|
||||||
|
2. Intégration IHM: Front → iframe → IHM.
|
||||||
|
3. API: Front → Back (REST).
|
||||||
15
docs/lecoffre-front/FONCTIONNEL.md
Normal file
15
docs/lecoffre-front/FONCTIONNEL.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# Description Fonctionnelle - LeCoffre Front
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
Fournir l’interface principale (Next.js) orchestrant l’UX, incluant l’iframe IHM Client.
|
||||||
|
|
||||||
|
## Parcours clés
|
||||||
|
- Authentification notaire (redirections IdNot).
|
||||||
|
- Navigation dossiers et intégration iframe IHM.
|
||||||
|
- Appels API backend, feedback utilisateur et gestion d’erreurs.
|
||||||
|
|
||||||
|
## Rôles
|
||||||
|
- Notaire, utilisateur interne.
|
||||||
|
|
||||||
|
## Résultats attendus
|
||||||
|
- UX fluide, chargements différés (code splitting), gestion session robuste.
|
||||||
43
docs/lecoffre-front/HMR_IDNOT_STATE.md
Normal file
43
docs/lecoffre-front/HMR_IDNOT_STATE.md
Normal file
@ -0,0 +1,43 @@
|
|||||||
|
HMR + IdNot + dev3 via state (mise à jour: 2025-09-24)
|
||||||
|
|
||||||
|
Vue d’ensemble
|
||||||
|
|
||||||
|
- HMR (Hot Module Replacement)
|
||||||
|
- En local, Next.js sert le HMR (ex: port 3000) et recharge les modules sans redémarrage.
|
||||||
|
- Les appels API sont effectués en same-origin via le proxy Nginx/compose: le front cible `/api/...`, Nginx route vers dev3. Pas de CORS ni reconfig lors des reloads.
|
||||||
|
- En dev4/prod, pas de HMR: `next start` sert l’app buildée sous `/lecoffre/`.
|
||||||
|
|
||||||
|
- Émission du state (dev3)
|
||||||
|
- Front → `POST /api/v1/idnot/state` (same-origin `/api`). Nginx (dev4) relaie vers `https://dev3.4nkweb.com/api/v1/idnot/state`.
|
||||||
|
- Body: `{ "next_url": "https://dev4.4nkweb.com/lecoffre/authorized-client" }`.
|
||||||
|
- Réponse: `{ "state": "<state_signé>" }`. CORS dynamique côté Nginx (dev3) autorise l’origine dev4.
|
||||||
|
|
||||||
|
- Redirection IdNot avec state
|
||||||
|
- URL d’autorisation:
|
||||||
|
- base = `NEXT_PUBLIC_IDNOT_BASE_URL + NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT`
|
||||||
|
- `client_id = NEXT_PUBLIC_IDNOT_CLIENT_ID`
|
||||||
|
- `redirect_uri = NEXT_PUBLIC_IDNOT_REDIRECT_URI_FIXED` (stable)
|
||||||
|
- `scope = openid,profile`, `response_type = code`
|
||||||
|
- `state = <state_signé>` (depuis l’API state dev3)
|
||||||
|
- IdNot renvoie `code` (et le `state` validé côté backend) vers dev3, qui enchaîne selon `next_url`.
|
||||||
|
|
||||||
|
- Pourquoi ça marche bien avec HMR
|
||||||
|
- Le front n’appelle pas dev3 directement depuis le navigateur: toujours `/api` (reverse-proxy Nginx).
|
||||||
|
- Nginx masque les headers CORS upstream et réinjecte des headers valides dynamiquement (Origin dev4/local).
|
||||||
|
- Le `state` est demandé via `/api`, donc indépendant du HMR.
|
||||||
|
- Les `NEXT_PUBLIC_*` pilotent IdNot et `next_url`; endpoints de debug: `/api/env` et `/env`.
|
||||||
|
|
||||||
|
- Canonicalisation URL
|
||||||
|
- Canonical sous-sous-chemin: `/lecoffre/`.
|
||||||
|
- Next: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true`.
|
||||||
|
- Nginx (dev4): rediriger `/lecoffre` → `/lecoffre/`; proxy `^~ /lecoffre/` vers `http://localhost:3004`.
|
||||||
|
|
||||||
|
- Validation (script `scripts/deploy_front_ext.sh`)
|
||||||
|
- Vérifie: variables `NEXT_PUBLIC_*` (conteneur vs `.env.master`).
|
||||||
|
- CORS dev3: OPTIONS 204 + en-têtes (A-C-A-Origin = dev4).
|
||||||
|
- `POST /api/v1/idnot/state`: 200 + `state` présent.
|
||||||
|
- Checks publics: `/lecoffre` = 301 → `/lecoffre/`, `/lecoffre/` = 200.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
26
docs/lecoffre-front/INSTALLATION.md
Normal file
26
docs/lecoffre-front/INSTALLATION.md
Normal file
@ -0,0 +1,26 @@
|
|||||||
|
# Installation - LeCoffre Front
|
||||||
|
|
||||||
|
## Prérequis
|
||||||
|
- Dépôts sous `/home/debian/4NK_env` (branche `ext`).
|
||||||
|
- Docker/Compose.
|
||||||
|
- Variables `NEXT_PUBLIC_*` dans `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Pas de `.env` local.
|
||||||
|
- Vérifier URLs backend et iframe IHM.
|
||||||
|
|
||||||
|
## Démarrage (orchestrateur)
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Accès
|
||||||
|
- `https://dev4.4nkweb.com/lecoffre/`
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- Ouverture iframe IHM.
|
||||||
|
- Appels API vers `/api/` OK.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- CI via tag `ext`.
|
||||||
27
docs/lecoffre-front/PORTS.md
Normal file
27
docs/lecoffre-front/PORTS.md
Normal file
@ -0,0 +1,27 @@
|
|||||||
|
Ports et usages (mise à jour: 2025-09-24)
|
||||||
|
|
||||||
|
Contexte: déploiement sur dev4 avec Nginx en frontal, lecoffre-front en Docker.
|
||||||
|
|
||||||
|
- 80 (TCP) — Nginx HTTP (host)
|
||||||
|
- 443 (TCP) — Nginx HTTPS (host)
|
||||||
|
|
||||||
|
- 3004 (TCP) — docker-proxy → lecoffre-front:8080 (port public du front via Docker)
|
||||||
|
- Interne conteneur: 8080 (Next.js `next start`)
|
||||||
|
|
||||||
|
- 3005 (TCP) — docker-proxy → Grafana:3000
|
||||||
|
- 3006 (TCP) — docker-proxy → status-api:3006
|
||||||
|
- 3100 (TCP) — docker-proxy → Loki:3100
|
||||||
|
- 8000 (TCP) — docker-proxy → blindbit-oracle:8000
|
||||||
|
- 8081 (TCP) — docker-proxy → sdk_storage:8080
|
||||||
|
|
||||||
|
Ports désactivés/libérés
|
||||||
|
|
||||||
|
- 3000 (TCP) — vhost local Nginx `local.4nkweb.com-3000` désactivé
|
||||||
|
- 7777/7778 (TCP) — anciens processus Node arrêtés
|
||||||
|
- 8080 (TCP host) — ancien Node local arrêté (ne pas confondre avec 8080 interne du conteneur front)
|
||||||
|
|
||||||
|
Notes
|
||||||
|
|
||||||
|
- Canonical front sous sous-chemin: `/lecoffre/`
|
||||||
|
- Next.js: `basePath: '/lecoffre'`, `assetPrefix: '/lecoffre'`, `trailingSlash: true`
|
||||||
|
- Nginx: rediriger `/lecoffre` → `/lecoffre/`, et proxy sur `^~ /lecoffre/` vers `http://localhost:3004`
|
||||||
6
docs/lecoffre-front/QUALITE.md
Normal file
6
docs/lecoffre-front/QUALITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Qualité Logicielle - LeCoffre Front
|
||||||
|
|
||||||
|
- Lint/format: respecter règles Next/TS.
|
||||||
|
- Tests: E2E parcours IdNot et iframe IHM.
|
||||||
|
- Performance: audit Lighthouse, lazy loading.
|
||||||
|
- Observabilité: logs client minimaux, erreurs capturées.
|
||||||
159
docs/lecoffre-front/RESUME-ANALYSE.md
Normal file
159
docs/lecoffre-front/RESUME-ANALYSE.md
Normal file
@ -0,0 +1,159 @@
|
|||||||
|
# Résumé de l'Analyse - lecoffre-front
|
||||||
|
|
||||||
|
## Vue d'ensemble
|
||||||
|
|
||||||
|
L'analyse complète du repository **lecoffre-front** a été effectuée le $(date). Ce document présente un résumé des principales découvertes et recommandations.
|
||||||
|
|
||||||
|
## Structure du projet
|
||||||
|
|
||||||
|
### Type d'application
|
||||||
|
- **Framework**: Next.js 14.2.3 avec TypeScript 4.9.5
|
||||||
|
- **Architecture**: Application frontend SPA avec intégrations multiples
|
||||||
|
- **Déploiement**: Docker multi-stage + Kubernetes
|
||||||
|
- **Version actuelle**: v0.1.6 (package.json) / v2.5.1 (frontend)
|
||||||
|
|
||||||
|
### Architecture technique
|
||||||
|
```
|
||||||
|
Frontend (Next.js) → API Backend → Services externes
|
||||||
|
↓ ↓ ↓
|
||||||
|
Material-UI Base de données 4NK/IDNot/Docaposte
|
||||||
|
```
|
||||||
|
|
||||||
|
## Variables d'environnement
|
||||||
|
|
||||||
|
### Configuration identifiée
|
||||||
|
- **21 variables d'environnement** configurées
|
||||||
|
- **4 environnements** supportés (dev/staging/preprod/production)
|
||||||
|
- **Gestion centralisée** via Next.js config et FrontendVariables
|
||||||
|
|
||||||
|
### Variables critiques
|
||||||
|
```bash
|
||||||
|
# API Backend
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL=https://
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST=api.example.com
|
||||||
|
NEXT_PUBLIC_BACK_API_PORT=443
|
||||||
|
|
||||||
|
# Intégrations
|
||||||
|
NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
|
||||||
|
NEXT_PUBLIC_IDNOT_BASE_URL=https://idnot.example.com
|
||||||
|
NEXT_PUBLIC_DOCAPOSTE_API_URL=https://api.docaposte.com
|
||||||
|
```
|
||||||
|
|
||||||
|
## Déploiement et infrastructure
|
||||||
|
|
||||||
|
### Docker
|
||||||
|
- **Multi-stage build** avec 4 cibles (deps/development/builder/ext)
|
||||||
|
- **Sécurité**: Utilisateur non-root, support SSH agent
|
||||||
|
- **Optimisation**: Cache npm, build standalone Next.js
|
||||||
|
|
||||||
|
### Kubernetes
|
||||||
|
- **Namespace**: lecoffre
|
||||||
|
- **Ressources**: 1Gi RAM (request) / 2Gi RAM (limit)
|
||||||
|
- **Sécurité**: Vault Agent pour injection des secrets
|
||||||
|
- **Ingress**: TLS avec cert-manager
|
||||||
|
|
||||||
|
### CI/CD
|
||||||
|
- **Registre**: git.4nkweb.com (Docker registry)
|
||||||
|
- **Tagging**: Contrôlé par message de commit
|
||||||
|
- **Secrets**: Gestion via Vault + External Secrets
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
### État général
|
||||||
|
- **46 dépendances** principales
|
||||||
|
- **5 dépendances** de développement
|
||||||
|
- **Statut**: Majoritairement à jour et sécurisées
|
||||||
|
|
||||||
|
### Recommandations
|
||||||
|
- ✅ **Maintenir**: Next.js 14.2.3, React 18.2.0, MUI 5.11.13
|
||||||
|
- ⚠️ **Mettre à jour**: TypeScript 4.9.5 → 5.x
|
||||||
|
- ✅ **Sécurisé**: Toutes les autres dépendances
|
||||||
|
|
||||||
|
## Points forts identifiés
|
||||||
|
|
||||||
|
### Architecture
|
||||||
|
- ✅ Structure modulaire bien organisée
|
||||||
|
- ✅ Séparation claire des responsabilités
|
||||||
|
- ✅ Configuration multi-environnement
|
||||||
|
- ✅ Intégration Docker/Kubernetes robuste
|
||||||
|
|
||||||
|
### Sécurité
|
||||||
|
- ✅ Variables d'environnement externalisées
|
||||||
|
- ✅ Gestion des secrets via Vault
|
||||||
|
- ✅ Utilisateur non-root dans Docker
|
||||||
|
- ✅ Support SSH agent pour dépendances privées
|
||||||
|
|
||||||
|
### Développement
|
||||||
|
- ✅ TypeScript pour le typage statique
|
||||||
|
- ✅ ESLint + Prettier pour la qualité du code
|
||||||
|
- ✅ Tests organisés dans le dossier tests/
|
||||||
|
- ✅ Documentation complète
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Améliorations recommandées
|
||||||
|
|
||||||
|
1. **TypeScript**
|
||||||
|
- Mettre à jour vers la version 5.x
|
||||||
|
- Bénéficier des dernières fonctionnalités
|
||||||
|
|
||||||
|
2. **Monitoring**
|
||||||
|
- Ajouter des métriques de performance
|
||||||
|
- Monitoring des erreurs en production
|
||||||
|
|
||||||
|
3. **Tests**
|
||||||
|
- Étendre la couverture de tests
|
||||||
|
- Tests d'intégration avec les services externes
|
||||||
|
|
||||||
|
4. **Documentation**
|
||||||
|
- Maintenir la documentation des variables d'environnement
|
||||||
|
- Documenter les processus de déploiement
|
||||||
|
|
||||||
|
### Risques identifiés
|
||||||
|
|
||||||
|
1. **Dépendances privées**
|
||||||
|
- Dépendance à git.4nkweb.com pour le-coffre-resources
|
||||||
|
- Nécessite un accès SSH configuré
|
||||||
|
|
||||||
|
2. **Variables d'environnement**
|
||||||
|
- Variables NEXT_PUBLIC_* exposées côté client
|
||||||
|
- Nécessite une validation stricte des valeurs
|
||||||
|
|
||||||
|
3. **Intégrations externes**
|
||||||
|
- Dépendance à plusieurs services externes
|
||||||
|
- Nécessite une gestion des pannes
|
||||||
|
|
||||||
|
## Recommandations prioritaires
|
||||||
|
|
||||||
|
### Court terme (1-2 semaines)
|
||||||
|
1. Mettre à jour TypeScript vers la version 5.x
|
||||||
|
2. Effectuer un audit de sécurité complet (`npm audit`)
|
||||||
|
3. Vérifier la configuration des variables d'environnement
|
||||||
|
|
||||||
|
### Moyen terme (1-2 mois)
|
||||||
|
1. Étendre la couverture de tests
|
||||||
|
2. Ajouter des métriques de monitoring
|
||||||
|
3. Documenter les processus de déploiement
|
||||||
|
|
||||||
|
### Long terme (3-6 mois)
|
||||||
|
1. Évaluer l'optimisation des performances
|
||||||
|
2. Considérer l'ajout de tests d'intégration
|
||||||
|
3. Planifier les mises à jour des dépendances
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Le projet **lecoffre-front** présente une architecture solide et bien structurée. Les technologies utilisées sont modernes et appropriées pour le contexte. La configuration Docker/Kubernetes est robuste et sécurisée.
|
||||||
|
|
||||||
|
Les principales améliorations concernent la mise à jour de TypeScript et l'extension des tests. Le projet est globalement en bon état et prêt pour la production.
|
||||||
|
|
||||||
|
## Documentation créée
|
||||||
|
|
||||||
|
1. **ANALYSE-REPOSITORY.md**: Analyse complète du repository
|
||||||
|
2. **VARIABLES-ENVIRONNEMENT.md**: Documentation détaillée des variables d'environnement
|
||||||
|
3. **ANALYSE-DEPENDANCES.md**: Analyse des dépendances et recommandations
|
||||||
|
4. **RESUME-ANALYSE.md**: Ce résumé exécutif
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Analyse effectuée le $(date) - Repository lecoffre-front*
|
||||||
|
*Analyste: Assistant IA Claude*
|
||||||
6
docs/lecoffre-front/SECURITE.md
Normal file
6
docs/lecoffre-front/SECURITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Sécurité - LeCoffre Front
|
||||||
|
|
||||||
|
- Aucune donnée sensible côté client.
|
||||||
|
- Variables exposées en `NEXT_PUBLIC_*` contrôlées.
|
||||||
|
- CSP/headers via Nginx.
|
||||||
|
- Sanitation des entrées utilisateur.
|
||||||
19
docs/lecoffre-front/TECHNIQUE.md
Normal file
19
docs/lecoffre-front/TECHNIQUE.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# Description Technique - LeCoffre Front
|
||||||
|
|
||||||
|
## Tech stack
|
||||||
|
- Next.js, Node.js 19.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Variables `NEXT_PUBLIC_*` via `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Interfaces
|
||||||
|
- Iframe vers `ihm_client`.
|
||||||
|
- REST vers `/api/`.
|
||||||
|
|
||||||
|
## Sécurité
|
||||||
|
- Aucun secret côté client.
|
||||||
|
- Headers via Nginx.
|
||||||
|
|
||||||
|
## Observabilité
|
||||||
|
- Logs Promtail → Loki.
|
||||||
|
- Dashboards Grafana.
|
||||||
6
docs/lecoffre-front/TODO.md
Normal file
6
docs/lecoffre-front/TODO.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# TODO - LeCoffre Front
|
||||||
|
|
||||||
|
- Vérifier URLs backend et iframe IHM.
|
||||||
|
- Tester parcours IdNot.
|
||||||
|
- Valider variables `NEXT_PUBLIC_*`.
|
||||||
|
- Vérifier dashboards Grafana Frontend.
|
||||||
336
docs/lecoffre-front/VARIABLES-ENVIRONNEMENT.md
Normal file
336
docs/lecoffre-front/VARIABLES-ENVIRONNEMENT.md
Normal file
@ -0,0 +1,336 @@
|
|||||||
|
# Variables d'Environnement - lecoffre-front
|
||||||
|
|
||||||
|
## Vue d'ensemble
|
||||||
|
|
||||||
|
Ce document détaille toutes les variables d'environnement utilisées dans l'application lecoffre-front, leur utilisation et leur configuration.
|
||||||
|
|
||||||
|
## Variables d'environnement supportées
|
||||||
|
|
||||||
|
### 1. Configuration API Backend
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_BACK_API_PROTOCOL`
|
||||||
|
- **Description**: Protocole utilisé pour communiquer avec l'API backend
|
||||||
|
- **Valeurs possibles**: `https://`, `http://`
|
||||||
|
- **Exemple**: `https://`
|
||||||
|
- **Utilisation**: Construction des URLs d'API
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_BACK_API_HOST`
|
||||||
|
- **Description**: Nom d'hôte de l'API backend
|
||||||
|
- **Exemple**: `api.lecoffre.com`, `dev4.4nkweb.com`
|
||||||
|
- **Utilisation**: Construction des URLs d'API
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_BACK_API_PORT`
|
||||||
|
- **Description**: Port de l'API backend
|
||||||
|
- **Exemple**: `443`, `8080`, `3001`
|
||||||
|
- **Utilisation**: Construction des URLs d'API
|
||||||
|
- **Note**: Peut être vide pour les ports par défaut (80/443)
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_BACK_API_ROOT_URL`
|
||||||
|
- **Description**: Chemin racine de l'API
|
||||||
|
- **Exemple**: `/api`, `/`
|
||||||
|
- **Utilisation**: Construction des URLs d'API
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_BACK_API_VERSION`
|
||||||
|
- **Description**: Version de l'API
|
||||||
|
- **Exemple**: `v1`, `v2`
|
||||||
|
- **Utilisation**: Construction des URLs d'API
|
||||||
|
|
||||||
|
### 2. Configuration Frontend
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_FRONT_APP_HOST`
|
||||||
|
- **Description**: URL de base de l'application frontend
|
||||||
|
- **Exemple**: `https://app.lecoffre.com`
|
||||||
|
- **Utilisation**: Redirections et liens internes
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_FRONT_APP_PORT`
|
||||||
|
- **Description**: Port de l'application frontend
|
||||||
|
- **Exemple**: `443`, `3000`
|
||||||
|
- **Utilisation**: Construction des URLs frontend
|
||||||
|
|
||||||
|
### 3. Intégration IDNot (Authentification)
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT`
|
||||||
|
- **Description**: Point d'entrée pour l'autorisation OAuth
|
||||||
|
- **Exemple**: `/oauth/authorize`
|
||||||
|
- **Utilisation**: Flux d'authentification
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_IDNOT_CLIENT_ID`
|
||||||
|
- **Description**: Identifiant client OAuth
|
||||||
|
- **Exemple**: `lecoffre-client-id`
|
||||||
|
- **Utilisation**: Authentification OAuth
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_IDNOT_BASE_URL`
|
||||||
|
- **Description**: URL de base du service IDNot
|
||||||
|
- **Exemple**: `https://idnot.lecoffre.com`
|
||||||
|
- **Utilisation**: Authentification OAuth
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_IDNOT_REDIRECT_URI`
|
||||||
|
- **Description**: URI de redirection après authentification
|
||||||
|
- **Exemple**: `https://app.lecoffre.com/callback`
|
||||||
|
- **Utilisation**: Flux d'authentification
|
||||||
|
|
||||||
|
### 4. Intégration Docaposte
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_DOCAPOSTE_API_URL`
|
||||||
|
- **Description**: URL de l'API Docaposte
|
||||||
|
- **Exemple**: `https://api.docaposte.com`
|
||||||
|
- **Utilisation**: Services postaux
|
||||||
|
|
||||||
|
### 5. Intégration 4NK (Blockchain)
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_4NK_URL`
|
||||||
|
- **Description**: URL de base des services 4NK
|
||||||
|
- **Exemple**: `https://dev4.4nkweb.com`
|
||||||
|
- **Utilisation**: Services blockchain et signature
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_4NK_IFRAME_URL`
|
||||||
|
- **Description**: URL spécifique pour l'iframe 4NK
|
||||||
|
- **Exemple**: `https://dev4.4nkweb.com`
|
||||||
|
- **Utilisation**: Communication iframe
|
||||||
|
- **Note**: Peut être différente de `NEXT_PUBLIC_4NK_URL`
|
||||||
|
|
||||||
|
### 6. Analytics et Monitoring
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_HOTJAR_SITE_ID`
|
||||||
|
- **Description**: Identifiant du site Hotjar
|
||||||
|
- **Exemple**: `123456`
|
||||||
|
- **Utilisation**: Analytics et heatmaps
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_HOTJAR_VERSION`
|
||||||
|
- **Description**: Version de Hotjar
|
||||||
|
- **Exemple**: `6`
|
||||||
|
- **Utilisation**: Analytics et heatmaps
|
||||||
|
|
||||||
|
### 7. Configuration système
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_API_URL`
|
||||||
|
- **Description**: URL générique de l'API
|
||||||
|
- **Exemple**: `https://api.lecoffre.com`
|
||||||
|
- **Utilisation**: Appels API génériques
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_DEFAULT_VALIDATOR_ID`
|
||||||
|
- **Description**: Identifiant du validateur par défaut
|
||||||
|
- **Exemple**: `862406317a35064537ac959cb5d8bbdf4f849283b63db3ffa9904de2b3427c43:0`
|
||||||
|
- **Utilisation**: Validation des entités système
|
||||||
|
- **Valeur par défaut**: Définie dans `AppConstants.ts`
|
||||||
|
|
||||||
|
#### `NEXT_PUBLIC_DEFAULT_STORAGE_URLS`
|
||||||
|
- **Description**: URLs de stockage par défaut (séparées par des virgules)
|
||||||
|
- **Exemple**: `https://dev3.4nkweb.com/storage,https://backup.4nkweb.com/storage`
|
||||||
|
- **Utilisation**: Stockage des données
|
||||||
|
- **Valeur par défaut**: `https://dev3.4nkweb.com/storage`
|
||||||
|
|
||||||
|
### 8. Variables d'environnement système
|
||||||
|
|
||||||
|
#### `NEXTJS_APP_ENV_NAME`
|
||||||
|
- **Description**: Nom de l'environnement
|
||||||
|
- **Valeurs possibles**: `development`, `staging`, `preprod`, `production`
|
||||||
|
- **Utilisation**: Sélection de la configuration par environnement
|
||||||
|
- **Valeur par défaut**: `development`
|
||||||
|
|
||||||
|
#### `NODE_ENV`
|
||||||
|
- **Description**: Environnement Node.js
|
||||||
|
- **Valeurs possibles**: `development`, `production`
|
||||||
|
- **Utilisation**: Configuration Next.js
|
||||||
|
|
||||||
|
## Configuration par environnement
|
||||||
|
|
||||||
|
### Développement
|
||||||
|
```bash
|
||||||
|
NEXTJS_APP_ENV_NAME=development
|
||||||
|
NODE_ENV=development
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL=http://
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST=localhost
|
||||||
|
NEXT_PUBLIC_BACK_API_PORT=3001
|
||||||
|
NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
|
||||||
|
```
|
||||||
|
|
||||||
|
### Staging
|
||||||
|
```bash
|
||||||
|
NEXTJS_APP_ENV_NAME=staging
|
||||||
|
NODE_ENV=production
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL=https://
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST=stg-api.lecoffre.com
|
||||||
|
NEXT_PUBLIC_BACK_API_PORT=443
|
||||||
|
NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
|
||||||
|
```
|
||||||
|
|
||||||
|
### Production
|
||||||
|
```bash
|
||||||
|
NEXTJS_APP_ENV_NAME=production
|
||||||
|
NODE_ENV=production
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL=https://
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST=api.lecoffre.com
|
||||||
|
NEXT_PUBLIC_BACK_API_PORT=443
|
||||||
|
NEXT_PUBLIC_4NK_URL=https://4nk.lecoffre.com
|
||||||
|
```
|
||||||
|
|
||||||
|
## Utilisation dans le code
|
||||||
|
|
||||||
|
### Configuration Next.js
|
||||||
|
|
||||||
|
Les variables sont configurées dans `next.config.js`:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
const nextConfig = {
|
||||||
|
publicRuntimeConfig: {
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL,
|
||||||
|
// ... autres variables
|
||||||
|
},
|
||||||
|
serverRuntimeConfig: {
|
||||||
|
// Même configuration pour le serveur
|
||||||
|
},
|
||||||
|
env: {
|
||||||
|
// Configuration pour le build
|
||||||
|
}
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
### Initialisation dans l'application
|
||||||
|
|
||||||
|
Les variables sont initialisées dans `_app.tsx`:
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
const { publicRuntimeConfig } = getConfig();
|
||||||
|
|
||||||
|
MyApp.getInitialProps = async () => {
|
||||||
|
return {
|
||||||
|
backApiProtocol: publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL,
|
||||||
|
// ... autres variables
|
||||||
|
};
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
### Utilisation dans les services
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
// DatabaseService.ts
|
||||||
|
private static buildBaseUrl(): string {
|
||||||
|
return `${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PROTOCOL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_HOST}:${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_PORT}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_ROOT_URL}${publicRuntimeConfig.NEXT_PUBLIC_BACK_API_VERSION}`;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Déploiement Docker
|
||||||
|
|
||||||
|
### Variables de build
|
||||||
|
|
||||||
|
```dockerfile
|
||||||
|
ARG NEXT_PUBLIC_BACK_API_PROTOCOL
|
||||||
|
ARG NEXT_PUBLIC_BACK_API_HOST
|
||||||
|
# ... autres variables
|
||||||
|
```
|
||||||
|
|
||||||
|
### Variables d'environnement runtime
|
||||||
|
|
||||||
|
```dockerfile
|
||||||
|
ENV NEXT_PUBLIC_BACK_API_PROTOCOL=${NEXT_PUBLIC_BACK_API_PROTOCOL} \
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST=${NEXT_PUBLIC_BACK_API_HOST} \
|
||||||
|
# ... autres variables
|
||||||
|
```
|
||||||
|
|
||||||
|
### Exécution
|
||||||
|
|
||||||
|
```bash
|
||||||
|
docker run -e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_HOST=api.example.com \
|
||||||
|
lecoffre/front:latest
|
||||||
|
```
|
||||||
|
|
||||||
|
## Déploiement Kubernetes
|
||||||
|
|
||||||
|
### Via Vault (recommandé)
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
annotations:
|
||||||
|
vault.hashicorp.com/agent-inject: "true"
|
||||||
|
vault.hashicorp.com/agent-inject-secret-envs: secret/data/lecoffre-front-stg/config/envs
|
||||||
|
vault.hashicorp.com/agent-inject-template-envs: |
|
||||||
|
{{ with secret "secret/data/lecoffre-front-stg/config/envs" }}
|
||||||
|
{{ range $k, $v := .Data.data }}
|
||||||
|
export {{ $k }}="{{ $v }}"
|
||||||
|
{{ end }}
|
||||||
|
{{ end }}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Via ConfigMap
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: ConfigMap
|
||||||
|
metadata:
|
||||||
|
name: lecoffre-front-config
|
||||||
|
data:
|
||||||
|
NEXT_PUBLIC_BACK_API_PROTOCOL: "https://"
|
||||||
|
NEXT_PUBLIC_BACK_API_HOST: "api.example.com"
|
||||||
|
# ... autres variables
|
||||||
|
```
|
||||||
|
|
||||||
|
## Validation et tests
|
||||||
|
|
||||||
|
### Vérification des variables requises
|
||||||
|
|
||||||
|
```typescript
|
||||||
|
const requiredVars = [
|
||||||
|
'NEXT_PUBLIC_BACK_API_PROTOCOL',
|
||||||
|
'NEXT_PUBLIC_BACK_API_HOST',
|
||||||
|
'NEXT_PUBLIC_BACK_API_PORT',
|
||||||
|
'NEXT_PUBLIC_BACK_API_ROOT_URL',
|
||||||
|
'NEXT_PUBLIC_BACK_API_VERSION'
|
||||||
|
];
|
||||||
|
|
||||||
|
for (const varName of requiredVars) {
|
||||||
|
if (!publicRuntimeConfig[varName]) {
|
||||||
|
throw new Error(`${varName} is not defined in environment variables`);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Tests d'environnement
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Vérifier les variables définies
|
||||||
|
env | grep NEXT_PUBLIC_
|
||||||
|
|
||||||
|
# Tester la construction d'URL
|
||||||
|
curl -I $(echo $NEXT_PUBLIC_BACK_API_PROTOCOL$NEXT_PUBLIC_BACK_API_HOST:$NEXT_PUBLIC_BACK_API_PORT$NEXT_PUBLIC_BACK_API_ROOT_URL$NEXT_PUBLIC_BACK_API_VERSION/health)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Bonnes pratiques
|
||||||
|
|
||||||
|
1. **Sécurité**: Ne jamais exposer de secrets dans les variables `NEXT_PUBLIC_*`
|
||||||
|
2. **Validation**: Toujours valider la présence des variables requises
|
||||||
|
3. **Documentation**: Maintenir la documentation des variables
|
||||||
|
4. **Tests**: Tester avec différentes configurations d'environnement
|
||||||
|
5. **Fallbacks**: Prévoir des valeurs par défaut quand possible
|
||||||
|
|
||||||
|
## Dépannage
|
||||||
|
|
||||||
|
### Variables non définies
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Vérifier les variables d'environnement
|
||||||
|
docker exec -it <container> env | grep NEXT_PUBLIC_
|
||||||
|
|
||||||
|
# Vérifier la configuration Vault
|
||||||
|
vault kv get secret/data/lecoffre-front-stg/config/envs
|
||||||
|
```
|
||||||
|
|
||||||
|
### URLs malformées
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Tester la construction d'URL
|
||||||
|
node -e "
|
||||||
|
const config = {
|
||||||
|
protocol: process.env.NEXT_PUBLIC_BACK_API_PROTOCOL,
|
||||||
|
host: process.env.NEXT_PUBLIC_BACK_API_HOST,
|
||||||
|
port: process.env.NEXT_PUBLIC_BACK_API_PORT,
|
||||||
|
root: process.env.NEXT_PUBLIC_BACK_API_ROOT_URL,
|
||||||
|
version: process.env.NEXT_PUBLIC_BACK_API_VERSION
|
||||||
|
};
|
||||||
|
console.log(\`\${config.protocol}\${config.host}:\${config.port}\${config.root}\${config.version}\`);
|
||||||
|
"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Documentation mise à jour le $(date) - Variables d'environnement lecoffre-front*
|
||||||
115
docs/lecoffre-front/ci.md
Normal file
115
docs/lecoffre-front/ci.md
Normal file
@ -0,0 +1,115 @@
|
|||||||
|
### CI/CD — Fonctionnement observé et architecture de déploiement
|
||||||
|
|
||||||
|
Cette documentation décrit le pipeline CI/CD tel qu’il peut être déduit des artefacts présents dans le dépôt : `Dockerfile`, `package.json`, et les manifestes Kubernetes rendus dans `temp.yaml`. Aucune configuration de pipeline explicite n’est présente dans le dépôt (pas de `.gitea/`, `.github/workflows/`, `.gitlab-ci.yml`, `.drone.yml`). Le flux ci-dessous s’appuie donc sur ces éléments pour décrire le fonctionnement attendu.
|
||||||
|
|
||||||
|
### Portée
|
||||||
|
|
||||||
|
- **Build applicatif**: Next.js (Node 19-alpine) avec dépendance privée `le-coffre-resources` via SSH.
|
||||||
|
- **Image Docker**: construction multi-étapes, publication vers le registre Docker hébergé sur `git.4nkweb.com` (accès via clés SSH).
|
||||||
|
- **Déploiement Kubernetes**: namespace `lecoffre`, intégration Vault Agent pour l’injection d’ENV, `ExternalSecret` pour le secret de pull Docker, `Ingress` TLS via cert-manager, ressources de `Deployment`/`Service`.
|
||||||
|
- **Variables front ajoutées**: `NEXT_PUBLIC_4NK_IFRAME_URL` pour distinguer l’URL complète de l’iframe de son origin (`NEXT_PUBLIC_4NK_URL`).
|
||||||
|
|
||||||
|
### Chaîne de build
|
||||||
|
|
||||||
|
- **Dépendances**
|
||||||
|
- `package.json` indique Next.js 14, TypeScript 4.9, ESLint 8.36, etc.
|
||||||
|
- La dépendance privée `le-coffre-resources` est récupérée depuis `git.4nkweb.com` via SSH (`git+ssh`).
|
||||||
|
|
||||||
|
- **Dockerfile** (multi-étapes, Node 19-alpine)
|
||||||
|
- Étape `deps`: installation des dépendances avec `npm install` en utilisant BuildKit et le forward d’agent SSH pour accéder au dépôt privé.
|
||||||
|
- Étape `development`: copie du code, exécution sous un utilisateur non-root, commande par défaut `npm run dev` (pour le développement local). Pour la prod, l’image utilisée en cluster exécute `npm run start` (cf. manifeste).
|
||||||
|
|
||||||
|
- **Build Next.js**
|
||||||
|
- Script `build`: `NEXT_TELEMETRY_DISABLED=1 next build --no-lint`
|
||||||
|
- Script `start`: `next start`
|
||||||
|
- Le lint n’est pas bloquant au build (flag `--no-lint`).
|
||||||
|
|
||||||
|
### Image, registre et version
|
||||||
|
|
||||||
|
- **Registre**: Docker registry interne sur `git.4nkweb.com`.
|
||||||
|
- **Tagging**: contrôlé par la CI via le message de commit (préfixe `ci: docker_tag=<valeur>`), sinon fallback `dev-test`. La branche peut être utilisée comme tag par défaut selon la CI. Recommandation: utiliser un tag non versionné `ext`.
|
||||||
|
|
||||||
|
### Déploiement Kubernetes (extrait de `temp.yaml`)
|
||||||
|
|
||||||
|
- **Namespace**: `lecoffre`
|
||||||
|
- **ServiceAccount**: `lecoffre-front-sa` avec `Secret` token associé.
|
||||||
|
- **ExternalSecret**: création de `imagePullSecret` à partir de Vault via `external-secrets.io` en lisant `secret/data/lecoffre-front-stg/config/dockerpullsecret` (clé `.dockerconfigjson`).
|
||||||
|
- **Deployment**: `apps/v1` nommé `lecoffre-front` avec:
|
||||||
|
- `image`: `rg.fr-par.scw.cloud/lecoffre/front:v0.1.9`
|
||||||
|
- `imagePullPolicy`: `Always`
|
||||||
|
- `resources`: `requests` (cpu 200m, ram 1Gi), `limits` (ram 2Gi)
|
||||||
|
- **Vault Agent Injector**: annotations pour injecter des variables d’environnement depuis `secret/data/lecoffre-front-stg/config/envs` en exportant chaque paire `clé=valeur` dans `/vault/secrets/envs`.
|
||||||
|
- **Commande de démarrage**: `['sh','-c', '. /vault/secrets/envs && npm run start']`
|
||||||
|
|
||||||
|
- **Service**: type ClusterIP exposant le port 80 vers le `targetPort` 3000 du conteneur Next.js.
|
||||||
|
|
||||||
|
- **Ingress**: classe `nginx` avec TLS géré par `cert-manager` (ClusterIssuer `letsencrypt-prod`) pour `app.stg.lecoffre.smart-chain.fr`.
|
||||||
|
|
||||||
|
### Flux CI/CD attendu (déduit)
|
||||||
|
|
||||||
|
1. **Checkout + préparation**
|
||||||
|
- Récupération du code et configuration de l’agent SSH (accès à `git.4nkweb.com`).
|
||||||
|
|
||||||
|
2. **Installation des dépendances**
|
||||||
|
- `npm install` avec BuildKit (`--mount=type=ssh`) pour la dépendance privée.
|
||||||
|
|
||||||
|
3. **Build applicatif**
|
||||||
|
- `npm run build` (désactive la télémétrie et le lint bloquant).
|
||||||
|
|
||||||
|
4. **Construction de l’image**
|
||||||
|
- Réalisée par la CI (BuildKit + forward d’agent SSH) après un `git push` sur `git.4nkweb.com`.
|
||||||
|
- Taggage déterminé par le message de commit et/ou la branche.
|
||||||
|
|
||||||
|
5. **Push au registre**
|
||||||
|
- Réalisé par la CI vers le registre `git.4nkweb.com`.
|
||||||
|
|
||||||
|
6. **Déploiement Kubernetes**
|
||||||
|
- Application des manifestes (ou rendu Helm) dans le namespace `lecoffre`.
|
||||||
|
- Les secrets de pull sont fournis via `ExternalSecret` connecté à Vault.
|
||||||
|
- Au runtime, Vault Agent injecte les variables d’environnement nécessaires avant `npm run start`.
|
||||||
|
|
||||||
|
### Sécurité et secrets
|
||||||
|
|
||||||
|
- **Build**: le forward d’agent SSH évite d’écrire la clé privée dans l’image.
|
||||||
|
- **Runtime**: aucune variable sensible n’est stockée dans l’image; elles sont injectées à l’exécution par Vault.
|
||||||
|
- **Pull de l’image**: la config Docker (`.dockerconfigjson`) est fournie par `ExternalSecret` à partir de Vault.
|
||||||
|
|
||||||
|
### Secrets CI requis
|
||||||
|
|
||||||
|
- **USER**: identifiant du compte CI sur `git.4nkweb.com` disposant des droits requis (lecture repo, push d’image vers le registry).
|
||||||
|
- **TOKEN**: jeton d’accès (API/registry) associé à `USER`. Utilisé par la CI pour:
|
||||||
|
- Authentifier les actions git/HTTP vers `git.4nkweb.com` (si nécessaire)
|
||||||
|
- Authentifier le `docker login` vers le registry Gitea si la CI ne repose pas sur des credentials intégrés.
|
||||||
|
|
||||||
|
Notes:
|
||||||
|
- Préférer des tokens à portée restreinte, régénérés périodiquement.
|
||||||
|
- Stocker `USER` et `TOKEN` dans le gestionnaire de secrets CI et ne jamais les committer.
|
||||||
|
|
||||||
|
### Points à confirmer
|
||||||
|
|
||||||
|
- Outil CI utilisé (Gitea Actions, Woodpecker/Drone, GitLab CI, autre) et fichiers de pipeline hébergés ailleurs.
|
||||||
|
- Règles de nommage des tags d’image et gouvernance de version (`vX.Y.Z`, tags d’environnement).
|
||||||
|
- Stratégie de déploiement (Helm chart source exact, commandes d’apply, gestion multi-env: dev/stg/prod).
|
||||||
|
- Politique de lint/test avant build (actuellement `--no-lint` au build Next.js).
|
||||||
|
- Passage des variables `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` à l’étape de build Docker (ARG/ENV) dans la CI.
|
||||||
|
|
||||||
|
### Bonnes pratiques recommandées
|
||||||
|
|
||||||
|
- Activer un job de lint et tests unitaires avant build d’image.
|
||||||
|
- Signer les images (Cosign) et activer des scans SCA/Container.
|
||||||
|
- Gérer explicitement les tags et le changelog en CI.
|
||||||
|
- Déployer via Helm chart versionné, avec valeurs par environnement (`values.{env}.yaml`).
|
||||||
|
|
||||||
|
### Validation de l'image Docker « ext » (intégration des variables)
|
||||||
|
|
||||||
|
- Objectif: vérifier que les variables `NEXT_PUBLIC_*` sont bien injectées dans l'image construite par la CI.
|
||||||
|
- Commande:
|
||||||
|
|
||||||
|
```
|
||||||
|
docker pull git.4nkweb.com/4nk/lecoffre-front:ext
|
||||||
|
docker run --rm git.4nkweb.com/4nk/lecoffre-front:ext sh -lc "env | grep '^NEXT_PUBLIC_' | sort"
|
||||||
|
```
|
||||||
|
|
||||||
|
- Attendus clés:
|
||||||
|
- `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` doivent être définies.
|
||||||
|
- Les URLs API (`NEXT_PUBLIC_API_URL`, `NEXT_PUBLIC_BACK_API_*`) doivent refléter l'environnement.
|
||||||
58
docs/lecoffre-front/ext.md
Normal file
58
docs/lecoffre-front/ext.md
Normal file
@ -0,0 +1,58 @@
|
|||||||
|
### Image Docker "ext" (Next.js) – variables d'environnement et publication
|
||||||
|
|
||||||
|
Cette image exécute l'app Next.js en mode production via `next start` et lit la configuration via les variables d'environnement exposées (préfixe `NEXT_PUBLIC_`). L'objectif est d'éviter toute dépendance à `localhost` dans les appels API : les URLs sont construites dynamiquement côté front à partir de ces variables.
|
||||||
|
|
||||||
|
#### Variables d'environnement supportées
|
||||||
|
|
||||||
|
- **NEXT_PUBLIC_BACK_API_PROTOCOL**: protocole de l'API (ex: `https://`)
|
||||||
|
- **NEXT_PUBLIC_BACK_API_HOST**: hôte de l'API (ex: `api.example.com`)
|
||||||
|
- **NEXT_PUBLIC_BACK_API_PORT**: port de l'API (ex: `443`)
|
||||||
|
- **NEXT_PUBLIC_BACK_API_ROOT_URL**: racine (ex: `/` ou `/api`)
|
||||||
|
- **NEXT_PUBLIC_BACK_API_VERSION**: version (ex: `v1`)
|
||||||
|
- **NEXT_PUBLIC_FRONT_APP_HOST**: base publique du front (ex: `https://app.example.com`)
|
||||||
|
- **NEXT_PUBLIC_FRONT_APP_PORT**: port front si nécessaire (ex: `443`)
|
||||||
|
- **NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT**
|
||||||
|
- **NEXT_PUBLIC_IDNOT_CLIENT_ID**
|
||||||
|
- **NEXT_PUBLIC_IDNOT_BASE_URL**
|
||||||
|
- **NEXT_PUBLIC_DOCAPOSTE_API_URL**
|
||||||
|
- **NEXT_PUBLIC_HOTJAR_SITE_ID**
|
||||||
|
- **NEXT_PUBLIC_HOTJAR_VERSION**
|
||||||
|
- **NEXT_PUBLIC_4NK_URL**
|
||||||
|
- **NEXT_PUBLIC_API_URL**
|
||||||
|
- **NEXT_PUBLIC_DEFAULT_VALIDATOR_ID**
|
||||||
|
- **NEXT_PUBLIC_DEFAULT_STORAGE_URLS** (liste séparée par des virgules)
|
||||||
|
|
||||||
|
Notes:
|
||||||
|
|
||||||
|
- Le front initialise ses variables via `next.config.js` et `_app.tsx`, ce qui alimente `FrontendVariables`. Les appels API utilisent ces valeurs et n'emploient pas `localhost`.
|
||||||
|
- Les valeurs doivent être passées au conteneur au runtime (`docker run -e ...` ou manifest K8s via `env:`/`secretRef`).
|
||||||
|
|
||||||
|
#### Construction de l'image (cible "ext")
|
||||||
|
|
||||||
|
Prérequis: Docker BuildKit activé et agent SSH opérationnel pour cloner `le-coffre-resources` depuis `git.4nkweb.com`.
|
||||||
|
|
||||||
|
1. `cd /home/debian/lecoffre-front`
|
||||||
|
2. `export DOCKER_BUILDKIT=1`
|
||||||
|
3. `docker build --target ext --ssh default -t lecoffre/front:ext -f /home/debian/lecoffre-front/Dockerfile /home/debian/lecoffre-front`
|
||||||
|
|
||||||
|
#### Exécution locale (validation)
|
||||||
|
|
||||||
|
Exemple minimal (adapter les valeurs):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
docker run --rm -p 3000:3000 \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_PROTOCOL=https:// \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_HOST=api.example.com \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_PORT=443 \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_ROOT_URL=/ \
|
||||||
|
-e NEXT_PUBLIC_BACK_API_VERSION=v1 \
|
||||||
|
-e NEXT_PUBLIC_FRONT_APP_HOST=https://app.example.com \
|
||||||
|
-e NEXT_PUBLIC_4NK_URL=https://app.example.com \
|
||||||
|
lecoffre/front:ext
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Publication via CI (git.4nkweb.com)
|
||||||
|
|
||||||
|
- Le push d'image est effectué par la CI de `git.4nkweb.com` suite à un `git push`.
|
||||||
|
- Définir le tag Docker dans le message de commit: `ci: docker_tag=ext` (fallback CI: `dev-test`).
|
||||||
|
- La branche peut être utilisée par la CI comme tag en l’absence d’override.
|
||||||
43
docs/sdk_relay/AMELIORATIONS_RECENTES.md
Normal file
43
docs/sdk_relay/AMELIORATIONS_RECENTES.md
Normal file
@ -0,0 +1,43 @@
|
|||||||
|
# Améliorations Récentes - SDK Relay
|
||||||
|
|
||||||
|
## Date: 20 Septembre 2025
|
||||||
|
|
||||||
|
### 🔧 Corrections Majeures
|
||||||
|
|
||||||
|
#### 1. Problème de Scan Bloquant
|
||||||
|
**Problème:** Le service se bloquait lors du scan initial des blocs Bitcoin.
|
||||||
|
|
||||||
|
**Solution:**
|
||||||
|
- Optimisation du `last_scan` pour éviter les scans trop importants
|
||||||
|
- Réduction des logs de `DEBUG` à `INFO`
|
||||||
|
- Amélioration du healthcheck
|
||||||
|
|
||||||
|
**Fichiers modifiés:**
|
||||||
|
- `Dockerfile` - Ajout des outils système
|
||||||
|
- `Cargo.toml` - Mise à jour des dépendances
|
||||||
|
- Configuration - Optimisation des paramètres
|
||||||
|
|
||||||
|
#### 2. Installation des Outils Système
|
||||||
|
**Ajouté dans le Dockerfile:**
|
||||||
|
```dockerfile
|
||||||
|
RUN apt-get update && apt-get upgrade -y && \
|
||||||
|
apt-get install -y ca-certificates dnsutils jq curl git wget telnet npm coreutils && \
|
||||||
|
npm install -g wscat && \
|
||||||
|
rm -rf /var/lib/apt/lists/* /root/.npm
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3. Configuration Bootstrap
|
||||||
|
- URL bootstrap: `wss://dev3.4nkweb.com/ws/`
|
||||||
|
- Faucet activé: `bootstrap_faucet=true`
|
||||||
|
- Adresse SP permanente configurée
|
||||||
|
|
||||||
|
### 📊 État Actuel
|
||||||
|
- **Version:** 0.1.2
|
||||||
|
- **Statut:** ✅ Healthy
|
||||||
|
- **Logs:** Niveau INFO (optimisé)
|
||||||
|
- **Scan:** Optimisé pour éviter les blocages
|
||||||
|
|
||||||
|
### 🔄 Prochaines Étapes
|
||||||
|
- Monitoring des performances
|
||||||
|
- Tests de connectivité bootstrap
|
||||||
|
- Optimisations supplémentaires si nécessaire
|
||||||
85
docs/sdk_relay/ANALYSE.md
Normal file
85
docs/sdk_relay/ANALYSE.md
Normal file
@ -0,0 +1,85 @@
|
|||||||
|
## Analyse détaillée
|
||||||
|
|
||||||
|
### Périmètre
|
||||||
|
|
||||||
|
Service Rust `sdk_relay` interfaçant Bitcoin (RPC), Blindbit et WebSocket, avec configuration injectée.
|
||||||
|
|
||||||
|
### Stack
|
||||||
|
|
||||||
|
- **Langage**: Rust 2021
|
||||||
|
- **Dépendances**: `tokio`, `tokio-tungstenite`, `zeromq`, `bitcoincore-rpc`, `serde[_json]`, `env_logger`, `futures-util`, `sdk_common` (git, branche `dev`, features `parallel`, `blindbit-backend`).
|
||||||
|
|
||||||
|
### Build et image
|
||||||
|
|
||||||
|
- Docker multi‑étapes: build dans `rust:latest` avec SSH pour deps privées, exécution `debian:bookworm-slim`.
|
||||||
|
- Binaire: `/usr/local/bin/sdk_relay`.
|
||||||
|
- Conf: build‑arg `CONF` écrit dans `/home/bitcoin/.conf`.
|
||||||
|
- Volumes: `/home/bitcoin/.4nk`, `/home/bitcoin/.bitcoin`.
|
||||||
|
|
||||||
|
### Réseau et healthcheck
|
||||||
|
|
||||||
|
- **WebSocket**: serveur lié sur `Config.ws_url` (ex. `0.0.0.0:8090`) via `tokio_tungstenite`.
|
||||||
|
- **Health**: serveur TCP léger interne sur port `8091` retournant `{"status":"ok"}`.
|
||||||
|
- **Ports exposés**: `8090` (WS), `8091` (HTTP /health) dans le `Dockerfile`.
|
||||||
|
|
||||||
|
Références code:
|
||||||
|
|
||||||
|
```396:625:src/main.rs
|
||||||
|
async fn handle_health_endpoint(mut stream: TcpStream) {
|
||||||
|
let response = "HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: 15\r\n\r\n{\"status\":\"ok\"}";
|
||||||
|
let _ = stream.write_all(response.as_bytes()).await;
|
||||||
|
let _ = stream.shutdown().await;
|
||||||
|
}
|
||||||
|
|
||||||
|
async fn start_health_server(port: u16) { /* ... */ }
|
||||||
|
|
||||||
|
// Start health server on port 8091
|
||||||
|
tokio::spawn(start_health_server(8091));
|
||||||
|
```
|
||||||
|
|
||||||
|
Configuration:
|
||||||
|
|
||||||
|
```1:7:.conf.model
|
||||||
|
core_url=""
|
||||||
|
ws_url=""
|
||||||
|
wallet_name="default"
|
||||||
|
network="signet"
|
||||||
|
electrum_url="tcp://localhost:60601"
|
||||||
|
blindbit_url="tcp://localhost:8000"
|
||||||
|
zmq_url=""
|
||||||
|
```
|
||||||
|
|
||||||
|
### Logs
|
||||||
|
|
||||||
|
- `RUST_LOG` géré par env; dans `lecoffre_node`, sortie tee vers `/home/bitcoin/.4nk/logs/sdk_relay.log`.
|
||||||
|
|
||||||
|
### Risques et points d’attention
|
||||||
|
|
||||||
|
- Dépendance `sdk_common` via git/branche `dev`: geler par tag/commit pour reproductibilité.
|
||||||
|
- Image d’exécution embarque `strace`; vérifier nécessité en prod.
|
||||||
|
- Permissions volume Windows: note de chown partiel dans compose parent.
|
||||||
|
|
||||||
|
### Actions proposées
|
||||||
|
|
||||||
|
- Pinner `sdk_common` sur un commit ou tag; documenter politique de mise à jour.
|
||||||
|
- Séparer images `-dev` et `-prod` si `strace` non requis.
|
||||||
|
- Documenter format du fichier de conf (`sdk_relay.conf`) et valeurs par défaut.
|
||||||
|
|
||||||
|
### CI / Image
|
||||||
|
|
||||||
|
- Pipeline `build-and-push-ext` construit et pousse l’image avec un tag calculé depuis le message de commit (préfixe `ci: docker_tag=` sinon `dev-test`).
|
||||||
|
- L’image expose `8090 8091` et lance `sdk_relay --config /home/bitcoin/.conf`.
|
||||||
|
|
||||||
|
Références:
|
||||||
|
|
||||||
|
```1:46:Dockerfile
|
||||||
|
EXPOSE 8090 8091
|
||||||
|
ENTRYPOINT ["sdk_relay", "--config", "/home/bitcoin/.conf"]
|
||||||
|
```
|
||||||
|
|
||||||
|
```1:73:.gitea/workflows/build-ext.yml
|
||||||
|
name: build-and-push-ext
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
20
docs/sdk_relay/ARCHITECTURE.md
Normal file
20
docs/sdk_relay/ARCHITECTURE.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
# Architecture - SDK Relay
|
||||||
|
|
||||||
|
## Composants
|
||||||
|
- Service Rust WebSocket relay + intégration Bitcoin/BlindBit.
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
- `bitcoin` (RPC/ZMQ), `blindbit-proxy`, `sdk_storage`.
|
||||||
|
|
||||||
|
## Réseau et ports
|
||||||
|
- WS: `0.0.0.0:8090` (exposé derrière Nginx `wss://dev4.4nkweb.com/ws/`).
|
||||||
|
|
||||||
|
## Variables d’environnement (centralisées)
|
||||||
|
- `SDK_RELAY_*` depuis `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Monitoring
|
||||||
|
- Healthcheck avec progression IBD/attentes.
|
||||||
|
- Logs centralisés Loki/Grafana (SDK Services).
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Démarre après Bitcoin et BlindBit.
|
||||||
74
docs/sdk_relay/CONFIGURATION.md
Normal file
74
docs/sdk_relay/CONFIGURATION.md
Normal file
@ -0,0 +1,74 @@
|
|||||||
|
# Configuration SDK Relay
|
||||||
|
|
||||||
|
## Variables d'environnement
|
||||||
|
|
||||||
|
Le service `sdk_relay` peut être configuré via les variables d'environnement suivantes :
|
||||||
|
|
||||||
|
### Variables principales
|
||||||
|
|
||||||
|
- **`SDK_RELAY_WS_URL`** : URL WebSocket pour les tests (défaut: `ws://0.0.0.0:8090`)
|
||||||
|
- **`WS_BIND_URL`** : URL de binding WebSocket (override de la configuration, défaut: valeur de `ws_url`)
|
||||||
|
- **`HEALTH_PORT`** : Port du serveur de santé (défaut: `8091`)
|
||||||
|
- **`HEALTH_BIND_ADDRESS`** : Adresse de binding du serveur de santé (défaut: `0.0.0.0`)
|
||||||
|
- **`RUST_LOG`** : Niveau de logging (défaut: `INFO`)
|
||||||
|
|
||||||
|
### Configuration via fichier
|
||||||
|
|
||||||
|
Le service utilise un fichier de configuration (`sdk_relay.conf`) avec les paramètres suivants :
|
||||||
|
|
||||||
|
```ini
|
||||||
|
core_url="http://bitcoin:38332"
|
||||||
|
ws_url="0.0.0.0:8090"
|
||||||
|
wallet_name="default"
|
||||||
|
network="signet"
|
||||||
|
blindbit_url="http://blindbit-oracle:8000"
|
||||||
|
zmq_url="tcp://bitcoin:29000"
|
||||||
|
storage="https://dev4.4nkweb.com/storage"
|
||||||
|
data_dir="/home/bitcoin/.4nk"
|
||||||
|
bitcoin_data_dir="/home/bitcoin/.bitcoin"
|
||||||
|
bootstrap_url="wss://dev3.4nkweb.com/ws/"
|
||||||
|
bootstrap_faucet=true
|
||||||
|
RUST_LOG="INFO"
|
||||||
|
sp_address="tsp1qqgmwp9n5p9ujhq2j6cfqe4jpkyu70jh9rgj0pwt3ndezk2mrlvw6jqew8fhsulewzglfr7g2aa48wyj4n0r7yasa3fm666vda8984ke8tuaf9m89"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Changements récents
|
||||||
|
|
||||||
|
### v0.1.3 - Configuration externalisée avancée
|
||||||
|
|
||||||
|
- **Ajout** : Variables d'environnement `WS_BIND_URL`, `HEALTH_PORT`, `HEALTH_BIND_ADDRESS`
|
||||||
|
- **Ajout** : Support de la variable d'environnement `SDK_RELAY_WS_URL` pour les tests
|
||||||
|
- **Modification** : Remplacement de `localhost` par `0.0.0.0` dans les tests WebSocket
|
||||||
|
- **Amélioration** : Configuration plus flexible pour les environnements Docker
|
||||||
|
- **Correction** : Résolution du problème de binding sur 127.0.0.1 au lieu de 0.0.0.0
|
||||||
|
|
||||||
|
### Tests
|
||||||
|
|
||||||
|
Les tests WebSocket utilisent maintenant `ws://0.0.0.0:8090` au lieu de `ws://localhost:8090` pour une meilleure compatibilité avec les environnements Docker.
|
||||||
|
|
||||||
|
## Configuration Docker
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
environment:
|
||||||
|
- WS_BIND_URL=0.0.0.0:8090
|
||||||
|
- HEALTH_PORT=8091
|
||||||
|
- HEALTH_BIND_ADDRESS=0.0.0.0
|
||||||
|
- RUST_LOG=INFO
|
||||||
|
volumes:
|
||||||
|
- ./relay/sdk_relay.conf:/home/bitcoin/.conf:ro
|
||||||
|
```
|
||||||
|
|
||||||
|
## Endpoints
|
||||||
|
|
||||||
|
- **WebSocket** : `0.0.0.0:8090` - Communication WebSocket
|
||||||
|
- **Health** : `0.0.0.0:8091` - Vérification de santé
|
||||||
|
|
||||||
|
## Dépannage
|
||||||
|
|
||||||
|
### Problème de connexion WebSocket
|
||||||
|
|
||||||
|
Si le service n'écoute pas sur `0.0.0.0:8090`, vérifiez :
|
||||||
|
|
||||||
|
1. La configuration `ws_url` dans le fichier de configuration
|
||||||
|
2. Les variables d'environnement Docker
|
||||||
|
3. Les logs du service pour les erreurs de binding
|
||||||
21
docs/sdk_relay/DEPLOIEMENT.md
Normal file
21
docs/sdk_relay/DEPLOIEMENT.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Déploiement - SDK Relay
|
||||||
|
|
||||||
|
## Préparation
|
||||||
|
- Branche `ext`.
|
||||||
|
- `SDK_RELAY_*` dans `lecoffre_node/.env.master`.
|
||||||
|
- Accès `bitcoin` RPC/ZMQ et `blindbit-proxy`.
|
||||||
|
|
||||||
|
## Déploiement (orchestrateur)
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
./scripts/validate-deployment.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- WS: `wss://dev4.4nkweb.com/ws/`.
|
||||||
|
- `./scripts/monitor-progress.sh | cat` (attente IBD/BlindBit).
|
||||||
|
|
||||||
|
## Règles
|
||||||
|
- Pas de compose direct.
|
||||||
|
- Push `ext` sans CI si pas de binaire à reconstruire.
|
||||||
6
docs/sdk_relay/FLUX.md
Normal file
6
docs/sdk_relay/FLUX.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Description des Flux - SDK Relay
|
||||||
|
|
||||||
|
## Flux principaux
|
||||||
|
1. Bitcoin (RPC/ZMQ) → Relay (indexation, signaux IBD).
|
||||||
|
2. BlindBit → Relay (résolution secrets SP).
|
||||||
|
3. Clients WS ↔ Relay (évènements NewTx, notifications).
|
||||||
13
docs/sdk_relay/FONCTIONNEL.md
Normal file
13
docs/sdk_relay/FONCTIONNEL.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Description Fonctionnelle - SDK Relay
|
||||||
|
|
||||||
|
## Objectif
|
||||||
|
Assurer le relais temps réel WebSocket et l’orchestration des évènements blockchain (Bitcoin/BlindBit) pour les services applicatifs.
|
||||||
|
|
||||||
|
## Parcours clés
|
||||||
|
- Abonnement clients WS.
|
||||||
|
- Relais d’évènements (nouveaux blocs, transactions, notifications NewTx).
|
||||||
|
- Attente synchronisation Bitcoin et disponibilité BlindBit avant diffusion.
|
||||||
|
|
||||||
|
## Résultats attendus
|
||||||
|
- Canal temps réel fiable.
|
||||||
|
- Mise en file d’attente/retente en cas d’indisponibilité dépendances.
|
||||||
24
docs/sdk_relay/INSTALLATION.md
Normal file
24
docs/sdk_relay/INSTALLATION.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
# Installation - SDK Relay
|
||||||
|
|
||||||
|
## Prérequis
|
||||||
|
- Dépôts sous `/home/debian/4NK_env` (branche `ext`).
|
||||||
|
- Docker/Compose.
|
||||||
|
- Variables `SDK_RELAY_*` dans `lecoffre_node/.env.master`.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Pas de `.env` local.
|
||||||
|
- Vérifier accès `bitcoin` (RPC/ZMQ) et `blindbit-proxy`.
|
||||||
|
|
||||||
|
## Démarrage (orchestrateur)
|
||||||
|
```bash
|
||||||
|
cd /home/debian/4NK_env/lecoffre_node
|
||||||
|
./scripts/start.sh | cat
|
||||||
|
```
|
||||||
|
|
||||||
|
## Vérifications
|
||||||
|
- WS: `wss://dev4.4nkweb.com/ws/`
|
||||||
|
- Health: scripts `monitor-progress.sh`, `logs-with-progress.sh`.
|
||||||
|
|
||||||
|
## Notes
|
||||||
|
- Démarre après Bitcoin et BlindBit.
|
||||||
|
- CI via tag `ext`.
|
||||||
6
docs/sdk_relay/QUALITE.md
Normal file
6
docs/sdk_relay/QUALITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Qualité Logicielle - SDK Relay
|
||||||
|
|
||||||
|
- Lint/format: Rustfmt/Clippy.
|
||||||
|
- Tests: unitaires, intégration WS, tests de charge.
|
||||||
|
- Performance: backpressure WS, gestion erreurs.
|
||||||
|
- Observabilité: logs structurés, métriques si dispo.
|
||||||
6
docs/sdk_relay/SECURITE.md
Normal file
6
docs/sdk_relay/SECURITE.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Sécurité - SDK Relay
|
||||||
|
|
||||||
|
- Aucune clé ou secret en dur.
|
||||||
|
- Accès Bitcoin RPC/ZMQ sécurisés sur réseau interne Docker.
|
||||||
|
- Validation stricte des messages WS.
|
||||||
|
- Journaux sans secrets.
|
||||||
19
docs/sdk_relay/TECHNIQUE.md
Normal file
19
docs/sdk_relay/TECHNIQUE.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# Description Technique - SDK Relay
|
||||||
|
|
||||||
|
## Tech stack
|
||||||
|
- Rust, WebSocket server.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
- Variables `SDK_RELAY_*` via `lecoffre_node/.env.master`.
|
||||||
|
- Connexion Bitcoin (RPC/ZMQ), BlindBit URL.
|
||||||
|
|
||||||
|
## Interfaces
|
||||||
|
- WS `0.0.0.0:8090` (derrière Nginx).
|
||||||
|
|
||||||
|
## Sécurité
|
||||||
|
- Aucun secret en dur.
|
||||||
|
- Validation stricte des messages.
|
||||||
|
|
||||||
|
## Observabilité
|
||||||
|
- Healthcheck avec progression.
|
||||||
|
- Logs Loki/Grafana.
|
||||||
6
docs/sdk_relay/TODO.md
Normal file
6
docs/sdk_relay/TODO.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# TODO - SDK Relay
|
||||||
|
|
||||||
|
- Vérifier connexion Bitcoin (RPC/ZMQ) et BlindBit.
|
||||||
|
- Tester WebSocket public via Nginx.
|
||||||
|
- Valider healthchecks et progression IBD.
|
||||||
|
- Surveiller logs et mettre en place alertes Grafana.
|
||||||
40
docs/sdk_relay/VALIDATION.md
Normal file
40
docs/sdk_relay/VALIDATION.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
## Validation opérationnelle
|
||||||
|
|
||||||
|
### Pré‑requis
|
||||||
|
|
||||||
|
- Image `git.4nkweb.com/4nk/sdk_relay:<tag>` construite par la CI (workflow `build-and-push-ext`).
|
||||||
|
- Fichier de configuration accessible dans le conteneur à `/home/bitcoin/.conf` avec au minimum: `core_url`, `ws_url`, `wallet_name`, `network`, `blindbit_url`, `zmq_url`.
|
||||||
|
- Ports hôtes libres: `8090` (WebSocket), `8091` (HTTP /health).
|
||||||
|
|
||||||
|
### Démarrage / Redémarrage du service
|
||||||
|
|
||||||
|
1. Arrêter l’instance en cours (si gérée via Docker/compose parent), puis démarrer avec la nouvelle image taggée `ext` (ou le tag CI calculé) en veillant à monter les volumes `/home/bitcoin/.4nk` et `/home/bitcoin/.bitcoin`.
|
||||||
|
2. Vérifier les logs de démarrage et la ligne: `Health server listening on port 8091`.
|
||||||
|
|
||||||
|
### Tests de santé
|
||||||
|
|
||||||
|
- HTTP: `curl -sS http://localhost:8091/health` doit renvoyer `{"status":"ok"}` avec un code 200.
|
||||||
|
|
||||||
|
### Tests WebSocket
|
||||||
|
|
||||||
|
- Connexion: ouvrir un client vers `ws://localhost:8090` (adresse selon `ws_url`). La poignée de main doit réussir.
|
||||||
|
- Réception initiale: un message de type Handshake (avec adresse SP, membres et processus) est diffusé à la connexion.
|
||||||
|
- Diffusion: émettre un message valide (selon protocole `sdk_common`) et vérifier qu’il est redistribué selon le `BroadcastType`.
|
||||||
|
|
||||||
|
### Parcours fonctionnel complet
|
||||||
|
|
||||||
|
1. IdNot: initialiser un identifiant et vérifier la persistance locale dans le volume `.4nk`.
|
||||||
|
2. iframe: intégrer le client (IHM) et établir la communication vers le WebSocket du `sdk_relay`.
|
||||||
|
3. Ajout de service: exécuter le flux d’ajout et confirmer la mise à jour de l’état et la diffusion côté WS.
|
||||||
|
|
||||||
|
### Attendus CI/CD
|
||||||
|
|
||||||
|
- La CI construit automatiquement l’image incluant l’endpoint `/health` et pousse avec le tag calculé (préfixe commit `ci: docker_tag=...`, sinon `dev-test`).
|
||||||
|
- Une fois l’image disponible (tag `ext` si prévu), redémarrer le service pour résoudre les problèmes de connexion.
|
||||||
|
|
||||||
|
### Dépannage
|
||||||
|
|
||||||
|
- Port occupé: vérifier qu’aucun service n’écoute déjà sur `8090/8091`.
|
||||||
|
- Conf manquante/invalide: le binaire échoue avec `Failed to find conf file` ou erreurs `No "..."`; corriger `/home/bitcoin/.conf`.
|
||||||
|
- ZMQ/Blindbit: si pas joignables, les fonctionnalités associées peuvent être dégradées; le `/health` reste OK si le service tourne.
|
||||||
|
- Volumes: en environnement Windows, vérifier les permissions et l’utilisateur `bitcoin`.
|
||||||
68
docs/sdk_relay/WEBSOCKET_CONFIGURATION.md
Normal file
68
docs/sdk_relay/WEBSOCKET_CONFIGURATION.md
Normal file
@ -0,0 +1,68 @@
|
|||||||
|
# Configuration WebSocket - sdk_relay
|
||||||
|
|
||||||
|
## Configuration actuelle
|
||||||
|
|
||||||
|
### Variables d'environnement
|
||||||
|
- `WS_BIND_URL` : URL de binding WebSocket (défaut: `0.0.0.0:8090`)
|
||||||
|
- `HEALTH_PORT` : Port du serveur de santé (défaut: `8091`)
|
||||||
|
- `HEALTH_BIND_ADDRESS` : Adresse de binding du serveur de santé (défaut: `0.0.0.0`)
|
||||||
|
|
||||||
|
### Configuration dans sdk_relay.conf
|
||||||
|
```ini
|
||||||
|
ws_url="0.0.0.0:8090"
|
||||||
|
blindbit_url="http://blindbit-oracle:8000"
|
||||||
|
bootstrap_url="wss://dev3.4nkweb.com/ws/"
|
||||||
|
bootstrap_faucet=true
|
||||||
|
sp_address="tsp1qqgmwp9n5p9ujhq2j6cfqe4jpkyu70jh9rgj0pwt3ndezk2mrlvw6jqew8fhsulewzglfr7g2aa48wyj4n0r7yasa3fm666vda8984ke8tuaf9m89"
|
||||||
|
RUST_LOG="INFO"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Problèmes résolus
|
||||||
|
|
||||||
|
### 1. Binding sur 127.0.0.1 au lieu de 0.0.0.0
|
||||||
|
**Problème :** Le relay se liait sur `127.0.0.1:8090` au lieu de `0.0.0.0:8090`.
|
||||||
|
|
||||||
|
**Solution :** Externalisation de la configuration via variables d'environnement et correction du code Rust.
|
||||||
|
|
||||||
|
### 2. Gestion des erreurs WebSocket
|
||||||
|
**Problème :** Erreurs de handshake WebSocket non gérées correctement.
|
||||||
|
|
||||||
|
**Solution :** Amélioration de la gestion d'erreurs avec `log::warn!` au lieu de `log::error!` pour les tentatives de connexion non-WebSocket.
|
||||||
|
|
||||||
|
### 3. Configuration externalisée
|
||||||
|
**Problème :** IP et ports hardcodés dans le code Rust.
|
||||||
|
|
||||||
|
**Solution :** Externalisation de tous les paramètres de configuration via variables d'environnement.
|
||||||
|
|
||||||
|
## Tests WebSocket
|
||||||
|
|
||||||
|
### Test avec headers corrects
|
||||||
|
```bash
|
||||||
|
curl -v -H "Upgrade: websocket" \
|
||||||
|
-H "Connection: upgrade" \
|
||||||
|
-H "Sec-WebSocket-Version: 13" \
|
||||||
|
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
|
||||||
|
http://127.0.0.1:8090/
|
||||||
|
```
|
||||||
|
|
||||||
|
**Résultat attendu :** `HTTP/1.1 101 Switching Protocols`
|
||||||
|
|
||||||
|
### Test sans headers WebSocket
|
||||||
|
```bash
|
||||||
|
curl -v http://127.0.0.1:8090/
|
||||||
|
```
|
||||||
|
|
||||||
|
**Résultat attendu :** Erreur de handshake WebSocket (normal)
|
||||||
|
|
||||||
|
## Problème persistant
|
||||||
|
|
||||||
|
### Nginx ne transmet pas les headers WebSocket
|
||||||
|
**Statut :** ⚠️ Problème persistant
|
||||||
|
- Nginx configuré avec tous les headers WebSocket
|
||||||
|
- Le relay reçoit toujours des connexions sans headers
|
||||||
|
- Erreur : `"No Upgrade: websocket header"`
|
||||||
|
|
||||||
|
**Investigation :** La configuration Nginx semble correcte mais les headers ne sont pas transmis.
|
||||||
|
|
||||||
|
## Date de mise à jour
|
||||||
|
2025-01-20 - Configuration WebSocket externalisée et problèmes de binding résolus
|
||||||
35
docs/sdk_storage/AMELIORATIONS_RECENTES.md
Normal file
35
docs/sdk_storage/AMELIORATIONS_RECENTES.md
Normal file
@ -0,0 +1,35 @@
|
|||||||
|
# Améliorations Récentes - SDK Storage
|
||||||
|
|
||||||
|
## Date: 20 Septembre 2025
|
||||||
|
|
||||||
|
### 🔧 Améliorations Majeures
|
||||||
|
|
||||||
|
#### 1. Installation des Outils Système
|
||||||
|
**Ajouté dans le Dockerfile:**
|
||||||
|
```dockerfile
|
||||||
|
RUN apt-get update && apt-get upgrade -y && \
|
||||||
|
apt-get install -y ca-certificates dnsutils jq curl git wget telnet npm coreutils && \
|
||||||
|
npm install -g wscat && \
|
||||||
|
rm -rf /var/lib/apt/lists/* /root/.npm
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. Optimisation de l'Image
|
||||||
|
- Mise à jour des packages système
|
||||||
|
- Installation des outils de diagnostic
|
||||||
|
- Nettoyage des caches pour réduire la taille
|
||||||
|
|
||||||
|
#### 3. Configuration des Services
|
||||||
|
- Port: 8081 (mappé sur 8081)
|
||||||
|
- Healthcheck: Vérification de la connectivité
|
||||||
|
- Logs: Niveau optimisé
|
||||||
|
|
||||||
|
### 📊 État Actuel
|
||||||
|
- **Statut:** ✅ Running
|
||||||
|
- **Port:** 8081 accessible
|
||||||
|
- **Outils:** Tous les outils système installés
|
||||||
|
- **Logs:** Optimisés
|
||||||
|
|
||||||
|
### 🔄 Prochaines Étapes
|
||||||
|
- Tests de connectivité storage
|
||||||
|
- Monitoring des performances
|
||||||
|
- Optimisations supplémentaires
|
||||||
40
docs/sdk_storage/ANALYSE.md
Normal file
40
docs/sdk_storage/ANALYSE.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
## Analyse détaillée
|
||||||
|
|
||||||
|
### Périmètre
|
||||||
|
|
||||||
|
Service Rust `sdk_storage` (Tide) offrant stockage clé/valeur avec TTL optionnel.
|
||||||
|
|
||||||
|
### Stack
|
||||||
|
|
||||||
|
- **Langage**: Rust 2021
|
||||||
|
- **Serveur**: `tide@0.16`, runtime `async-std`
|
||||||
|
- **Utilitaires**: `serde`, `serde_json`, `hex`, `env_logger`
|
||||||
|
- **Tests**: `tempfile`, `surf` (h1-client)
|
||||||
|
|
||||||
|
### API
|
||||||
|
|
||||||
|
- POST `/store` { key(hex64), value(hex), ttl? (s) }
|
||||||
|
- GET `/retrieve/:key`
|
||||||
|
|
||||||
|
### Build et image
|
||||||
|
|
||||||
|
- Docker: build dans `rust:1`, exécution `debian:stable-slim`, utilisateur non‑root, `RUST_LOG=info`.
|
||||||
|
- Expose: 8081; `CMD ["--permanent"]` (clé sans TTL).
|
||||||
|
|
||||||
|
### Risques et points d’attention
|
||||||
|
|
||||||
|
- Validation stricte des formats hex requis (taille/charset) à documenter et tester.
|
||||||
|
- Absence de persistance volumée par défaut: fournir stratégie de stockage (répertoire, montage, quotas).
|
||||||
|
- Logging et rotation à cadrer si charge élevée.
|
||||||
|
|
||||||
|
### Actions proposées
|
||||||
|
|
||||||
|
- Documenter schéma d’erreurs (HTTP, payload) et ajouter tests d’intégration dans `tests/`.
|
||||||
|
- Ajouter option de répertoire de stockage configurable et exemple `.env.example`.
|
||||||
|
- Mettre en place CI rust (build, test, fmt, clippy, audit).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
50
docs/sdk_storage/CONFIGURATION.md
Normal file
50
docs/sdk_storage/CONFIGURATION.md
Normal file
@ -0,0 +1,50 @@
|
|||||||
|
# Configuration SDK Storage
|
||||||
|
|
||||||
|
## Variables d'environnement
|
||||||
|
|
||||||
|
Le service `sdk_storage` peut être configuré via les variables d'environnement suivantes :
|
||||||
|
|
||||||
|
### Variables principales
|
||||||
|
|
||||||
|
- **`STORAGE_DIR`** : Répertoire de stockage des données (défaut: `./storage`)
|
||||||
|
- **`PORT`** : Port d'écoute du serveur HTTP (défaut: `8080`)
|
||||||
|
- **`NO_TTL_PERMANENT`** : Si définie, les requêtes sans TTL sont traitées comme permanentes
|
||||||
|
|
||||||
|
### Exemples d'utilisation
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Configuration personnalisée
|
||||||
|
export STORAGE_DIR="/var/lib/sdk_storage"
|
||||||
|
export PORT="8080"
|
||||||
|
export NO_TTL_PERMANENT="1"
|
||||||
|
|
||||||
|
# Lancement du service
|
||||||
|
./sdk_storage
|
||||||
|
```
|
||||||
|
|
||||||
|
## Changements récents
|
||||||
|
|
||||||
|
### v0.2.2 - Configuration externalisée
|
||||||
|
|
||||||
|
- **Ajout** : Support des variables d'environnement pour `STORAGE_DIR` et `PORT`
|
||||||
|
- **Modification** : Remplacement de `127.0.0.1` par `0.0.0.0` dans les tests
|
||||||
|
- **Amélioration** : Configuration plus flexible pour les déploiements Docker
|
||||||
|
|
||||||
|
### Tests
|
||||||
|
|
||||||
|
Les tests utilisent maintenant `0.0.0.0:0` au lieu de `127.0.0.1:0` pour une meilleure compatibilité avec les environnements Docker.
|
||||||
|
|
||||||
|
## Configuration Docker
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
environment:
|
||||||
|
- STORAGE_DIR=/app/storage
|
||||||
|
- PORT=8080
|
||||||
|
- NO_TTL_PERMANENT=1
|
||||||
|
```
|
||||||
|
|
||||||
|
## API Endpoints
|
||||||
|
|
||||||
|
- `GET /health` - Vérification de santé
|
||||||
|
- `POST /store` - Stockage de données
|
||||||
|
- `GET /retrieve/{key}` - Récupération de données
|
||||||
39
docs/sdk_storage/README.md
Normal file
39
docs/sdk_storage/README.md
Normal file
@ -0,0 +1,39 @@
|
|||||||
|
# Documentation du projet sdk_storage
|
||||||
|
|
||||||
|
Ce dossier documente l'API HTTP, l'architecture et les décisions techniques.
|
||||||
|
|
||||||
|
## API
|
||||||
|
|
||||||
|
- POST `/store` : stocke une valeur hex pour une clé hex 64 chars, `ttl` optionnel (secondes). Quand `--permanent` est passé au binaire, l'absence de `ttl` rend la donnée permanente.
|
||||||
|
- GET `/retrieve/:key` : retourne `{ key, value }` où `value` est encodée en hex.
|
||||||
|
|
||||||
|
## Architecture
|
||||||
|
|
||||||
|
- Service `StorageService` (voir `src/lib.rs`) encapsule la logique de stockage, récupération et nettoyage TTL.
|
||||||
|
- `src/main.rs` démarre Tide avec état `StorageService` et une boucle de nettoyage périodique (60s).
|
||||||
|
|
||||||
|
Voir aussi:
|
||||||
|
- `architecture.md`
|
||||||
|
- `configuration.md`
|
||||||
|
- `guides_principaux.md`
|
||||||
|
- `guides_techniques.md`
|
||||||
|
- `guides_test.md`
|
||||||
|
- `tests_monitoring.md`
|
||||||
|
- `reseau_de_relais.md`
|
||||||
|
- `developpement.md`
|
||||||
|
- `depannage.md`
|
||||||
|
- `performance.md`
|
||||||
|
- `api_json_spec.md`
|
||||||
|
- `api_contrats.md`
|
||||||
|
- `release_guide.md`
|
||||||
|
- `ci_docker_registry.md`
|
||||||
|
|
||||||
|
## REX technique
|
||||||
|
|
||||||
|
- Docker
|
||||||
|
- Build local: `docker build -t sdk_storage:local .`
|
||||||
|
- Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
|
||||||
|
- Par défaut `--permanent` est activé via CMD, override possible: `docker run ... sdk_storage -- --permanent`
|
||||||
|
|
||||||
|
- Refactor initial de la logique depuis `main.rs` vers `lib.rs` pour testabilité et séparation des responsabilités.
|
||||||
|
- Durées TTL maintenant validées dans le handler, calcul d'expiration converti en `SystemTime` avant l'appel service.
|
||||||
21
docs/sdk_storage/api_contrats.md
Normal file
21
docs/sdk_storage/api_contrats.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Contrats API
|
||||||
|
|
||||||
|
## Garanties de Contrat
|
||||||
|
- Content-Type JSON, réponses structurées.
|
||||||
|
- Clé: 64 hex (validation stricte), sinon 400.
|
||||||
|
- Valeur: hex valide, sinon 400.
|
||||||
|
- Conflit de clé: 409 si la clé existe déjà.
|
||||||
|
- TTL: min 60, max 31 536 000; par défaut 86 400 si non `--permanent`.
|
||||||
|
- Récupération:
|
||||||
|
- 200 avec `{ key, value }` si trouvée.
|
||||||
|
- 400 si clé invalide.
|
||||||
|
- 404 si absente.
|
||||||
|
|
||||||
|
## Couverture de Tests
|
||||||
|
- Stockage et récupération (succès).
|
||||||
|
- Conflit de clé.
|
||||||
|
- Suppression des expirés via nettoyage.
|
||||||
|
- HTTP `/store`: succès, conflit, clé invalide, valeur invalide.
|
||||||
|
- HTTP `/retrieve`: succès, clé invalide, clé absente.
|
||||||
|
|
||||||
|
Voir `api_json_spec.md` pour les schémas et contraintes détaillés.
|
||||||
113
docs/sdk_storage/api_json_spec.md
Normal file
113
docs/sdk_storage/api_json_spec.md
Normal file
@ -0,0 +1,113 @@
|
|||||||
|
# Spécification JSON des API
|
||||||
|
|
||||||
|
## Généralités
|
||||||
|
- Content-Type: `application/json; charset=utf-8`
|
||||||
|
- Encodage des valeurs: chaînes hexadécimales minuscules (0-9a-f).
|
||||||
|
- Modèle d'erreur: corps `{ "message": string }` avec code HTTP approprié.
|
||||||
|
|
||||||
|
## POST /store
|
||||||
|
- Objet requête: `StoreRequest`
|
||||||
|
- Objet réponse (succès/erreur): `ApiResponse`
|
||||||
|
|
||||||
|
### Schéma JSON (StoreRequest)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||||
|
"title": "StoreRequest",
|
||||||
|
"type": "object",
|
||||||
|
"additionalProperties": false,
|
||||||
|
"required": ["key", "value"],
|
||||||
|
"properties": {
|
||||||
|
"key": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "Clé hexadécimale 64 caractères (32 octets).",
|
||||||
|
"pattern": "^[0-9a-fA-F]{64}$"
|
||||||
|
},
|
||||||
|
"value": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "Valeur encodée en hexadécimal.",
|
||||||
|
"pattern": "^[0-9a-fA-F]+$"
|
||||||
|
},
|
||||||
|
"ttl": {
|
||||||
|
"type": "integer",
|
||||||
|
"minimum": 60,
|
||||||
|
"maximum": 31536000,
|
||||||
|
"description": "Durée de vie en secondes. Si absent: défaut 86400 sauf si mode --permanent (aucune expiration)."
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Règles de validation et sémantique
|
||||||
|
- `key`: exactement 64 caractères hex (
|
||||||
|
32 octets).
|
||||||
|
- `value`: chaîne hex valide, longueur paire recommandée (représentation d'octets).
|
||||||
|
- `ttl`:
|
||||||
|
- min: 60, max: 31 536 000.
|
||||||
|
- si absent et binaire lancé sans `--permanent`: valeur par défaut 86 400.
|
||||||
|
- si absent et binaire lancé avec `--permanent`: aucune expiration.
|
||||||
|
|
||||||
|
### Réponses
|
||||||
|
- 200 OK: `ApiResponse` (message de succès)
|
||||||
|
- 400 Bad Request: `ApiResponse` (clé/ttl/valeur invalides)
|
||||||
|
- 409 Conflict: `ApiResponse` (clé déjà existante)
|
||||||
|
- 500 Internal Server Error: `ApiResponse`
|
||||||
|
|
||||||
|
### Schéma JSON (ApiResponse)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||||
|
"title": "ApiResponse",
|
||||||
|
"type": "object",
|
||||||
|
"additionalProperties": false,
|
||||||
|
"required": ["message"],
|
||||||
|
"properties": {
|
||||||
|
"message": { "type": "string" }
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## GET /retrieve/:key
|
||||||
|
## GET /health
|
||||||
|
- Aucune donnée d'entrée.
|
||||||
|
- Réponse 200 avec `ApiResponse` `{ "message": "ok" }`.
|
||||||
|
|
||||||
|
- Paramètre de chemin: `key` (hex 64).
|
||||||
|
- Objet réponse (succès): `RetrieveResponse`
|
||||||
|
- Objet réponse (erreur): `ApiResponse`
|
||||||
|
|
||||||
|
### Contraintes
|
||||||
|
- `key` doit respecter `^[0-9a-fA-F]{64}$`.
|
||||||
|
|
||||||
|
### Réponses
|
||||||
|
- 200 OK: `RetrieveResponse`
|
||||||
|
- 400 Bad Request: `ApiResponse` (clé invalide)
|
||||||
|
- 404 Not Found: `ApiResponse` (clé inconnue)
|
||||||
|
- 500 Internal Server Error: `ApiResponse`
|
||||||
|
|
||||||
|
### Schéma JSON (RetrieveResponse)
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"$schema": "http://json-schema.org/draft-07/schema#",
|
||||||
|
"title": "RetrieveResponse",
|
||||||
|
"type": "object",
|
||||||
|
"additionalProperties": false,
|
||||||
|
"required": ["key", "value"],
|
||||||
|
"properties": {
|
||||||
|
"key": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "Clé hexadécimale 64 caractères.",
|
||||||
|
"pattern": "^[0-9a-fA-F]{64}$"
|
||||||
|
},
|
||||||
|
"value": {
|
||||||
|
"type": "string",
|
||||||
|
"description": "Valeur encodée en hexadécimal.",
|
||||||
|
"pattern": "^[0-9a-fA-F]+$"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Codes d'état et messages
|
||||||
|
- Les messages d'erreur sont informatifs mais ne divulguent pas d'informations sensibles.
|
||||||
|
- Les champs `message` sont destinés à l'humain; ne pas les parser côté client.
|
||||||
13
docs/sdk_storage/architecture.md
Normal file
13
docs/sdk_storage/architecture.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Architecture
|
||||||
|
|
||||||
|
## Flux de Données
|
||||||
|
|
||||||
|
- Entrées: requêtes HTTP `/store`, `/retrieve/:key`.
|
||||||
|
- Traitements: validation clés/TTL, encodage hex, stockage FS hiérarchique, métadonnées TTL.
|
||||||
|
- Sorties: réponses JSON normalisées.
|
||||||
|
|
||||||
|
## Composants
|
||||||
|
|
||||||
|
- Service `StorageService` (I/O disque, TTL, nettoyage).
|
||||||
|
- Serveur HTTP Tide (routes, état partagé).
|
||||||
|
- Nettoyage périodique (60s) basé sur fichiers `.meta`.
|
||||||
11
docs/sdk_storage/ci_docker_registry.md
Normal file
11
docs/sdk_storage/ci_docker_registry.md
Normal file
@ -0,0 +1,11 @@
|
|||||||
|
# CI - Variables pour Registre Docker
|
||||||
|
|
||||||
|
Le workflow `.gitea/workflows/docker.yml` requiert ces secrets:
|
||||||
|
|
||||||
|
- `DOCKER_REGISTRY`: registre cible (ex: registry.git.4nkweb.com/4nk)
|
||||||
|
- `DOCKER_USERNAME`: utilisateur du registre
|
||||||
|
- `DOCKER_PASSWORD`: mot de passe/token
|
||||||
|
|
||||||
|
Configurer ces secrets dans les paramètres du dépôt (ou de l’organisation) côté Gitea.
|
||||||
|
|
||||||
|
La cible d’image est `DOCKER_REGISTRY/sdk_storage:latest` (et multi-arch si activé).
|
||||||
8
docs/sdk_storage/configuration.md
Normal file
8
docs/sdk_storage/configuration.md
Normal file
@ -0,0 +1,8 @@
|
|||||||
|
# Configuration
|
||||||
|
|
||||||
|
## Services Disponibles
|
||||||
|
- HTTP sur port 8081
|
||||||
|
|
||||||
|
## Variables d'Environnement
|
||||||
|
- `RUST_LOG` (optionnel): niveau de logs.
|
||||||
|
- Pour Docker, monter `/app/storage` si persistance souhaitée.
|
||||||
15
docs/sdk_storage/demarrage_rapide.md
Normal file
15
docs/sdk_storage/demarrage_rapide.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# Démarrage Rapide
|
||||||
|
|
||||||
|
## Prérequis
|
||||||
|
- Rust stable et Cargo
|
||||||
|
- Optionnel: Docker
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
- `cargo build`
|
||||||
|
|
||||||
|
## Lancement
|
||||||
|
- `cargo run -- --permanent`
|
||||||
|
|
||||||
|
## Docker (optionnel)
|
||||||
|
- Build: `docker build -t sdk_storage:local .`
|
||||||
|
- Run: `docker run --rm -p 8081:8081 -v $PWD/storage:/app/storage sdk_storage:local`
|
||||||
12
docs/sdk_storage/depannage.md
Normal file
12
docs/sdk_storage/depannage.md
Normal file
@ -0,0 +1,12 @@
|
|||||||
|
# Dépannage
|
||||||
|
|
||||||
|
## Problèmes Courants
|
||||||
|
1. Ports déjà utilisés: changer le port de publication Docker.
|
||||||
|
2. Permissions storage: vérifier l'UID/GID et droits du volume.
|
||||||
|
3. Clés invalides: s'assurer d'un hex 64 caractères.
|
||||||
|
|
||||||
|
## Logs détaillés
|
||||||
|
- Exécuter avec `RUST_LOG=info`.
|
||||||
|
|
||||||
|
## Healthchecks
|
||||||
|
- Ajouter une route `/health` (évolution possible) ou ping sur `/retrieve` avec clé connue.
|
||||||
13
docs/sdk_storage/developpement.md
Normal file
13
docs/sdk_storage/developpement.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
# Développement
|
||||||
|
|
||||||
|
## Structure du Projet
|
||||||
|
- `src/lib.rs`: service métier
|
||||||
|
- `src/main.rs`: serveur HTTP Tide
|
||||||
|
- `tests/`: scénarios d'intégration
|
||||||
|
|
||||||
|
## Ajout d'un Nouveau Service
|
||||||
|
- Créer une abstraction dédiée dans `src/lib.rs` ou module séparé.
|
||||||
|
- Câbler dans `main.rs` via `tide::with_state` si nécessaire.
|
||||||
|
|
||||||
|
## Modification de la Configuration
|
||||||
|
- Mettre à jour `docs/configuration.md` et secrets CI/CD.
|
||||||
5
docs/sdk_storage/guides_principaux.md
Normal file
5
docs/sdk_storage/guides_principaux.md
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
# Guides Principaux
|
||||||
|
|
||||||
|
- Concepts de base: clés hex 64, valeurs hex, TTL en secondes.
|
||||||
|
- API: `/store` (POST), `/retrieve/:key` (GET).
|
||||||
|
- Persistance: système de fichiers, sous-dossiers par préfixe de clé.
|
||||||
6
docs/sdk_storage/guides_techniques.md
Normal file
6
docs/sdk_storage/guides_techniques.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
# Guides Techniques
|
||||||
|
|
||||||
|
- `StorageService`: abstraction des opérations de stockage.
|
||||||
|
- TTL: sérialisé dans `*.meta` (UNIX timestamp secondes).
|
||||||
|
- Nettoyage: parcours des dossiers, suppression données expirées.
|
||||||
|
- Journalisation: sorties standard, intégration possible avec superviseur.
|
||||||
5
docs/sdk_storage/guides_test.md
Normal file
5
docs/sdk_storage/guides_test.md
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
# Guides de Test
|
||||||
|
|
||||||
|
- Tests unitaires recommandés sur `StorageService` via répertoires temporaires.
|
||||||
|
- Tests d'intégration HTTP optionnels via client HTTP.
|
||||||
|
- Stratégies: cas TTL min/max, clés invalides, conflits de clé.
|
||||||
9
docs/sdk_storage/performance.md
Normal file
9
docs/sdk_storage/performance.md
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
# Performance
|
||||||
|
|
||||||
|
## Ressources Recommandées
|
||||||
|
- Disque rapide si grand volume d'écritures.
|
||||||
|
- Mémoire suffisante pour buffers I/O.
|
||||||
|
|
||||||
|
## Optimisations
|
||||||
|
- Paramétrer la taille des blocs et la stratégie de fsync selon contraintes.
|
||||||
|
- Éviter les collisions de clés, supervision du cleanup TTL.
|
||||||
21
docs/sdk_storage/release_guide.md
Normal file
21
docs/sdk_storage/release_guide.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
# Guide de Release
|
||||||
|
|
||||||
|
## Préparation
|
||||||
|
- S’assurer que la suite `cargo test` est verte.
|
||||||
|
- Mettre à jour `CHANGELOG.md` avec la version cible.
|
||||||
|
|
||||||
|
## Tagging
|
||||||
|
- Créer un tag annoté: `git tag -a vX.Y.Z -m 'vX.Y.Z'`
|
||||||
|
- Pousser le tag: `git push origin vX.Y.Z`
|
||||||
|
|
||||||
|
## CI
|
||||||
|
- Build binaire (workflow release) déclenché sur tag `v*.*.*`.
|
||||||
|
- Build/push image Docker via workflow `docker.yml` (variables `DOCKER_*` requises).
|
||||||
|
|
||||||
|
## Assets
|
||||||
|
- Binaires disponibles via artefacts CI.
|
||||||
|
- Images Docker taggées `latest` (et potentiellement `vX.Y.Z` selon configuration).
|
||||||
|
|
||||||
|
## Post-release
|
||||||
|
- Mettre à jour la documentation si nécessaire.
|
||||||
|
- Ouvrir une issue pour les améliorations/retours.
|
||||||
10
docs/sdk_storage/reseau_de_relais.md
Normal file
10
docs/sdk_storage/reseau_de_relais.md
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
# Réseau de Relais
|
||||||
|
|
||||||
|
## Architecture Mesh
|
||||||
|
- À définir selon déploiement.
|
||||||
|
|
||||||
|
## Ajout de Nœuds Externes
|
||||||
|
- Procédure à documenter si nécessaire.
|
||||||
|
|
||||||
|
## Configuration Externe
|
||||||
|
- Ports, sécurité, endpoints à exposer.
|
||||||
9
docs/sdk_storage/tests_monitoring.md
Normal file
9
docs/sdk_storage/tests_monitoring.md
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
# Tests et Monitoring
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
- Unitaires et intégration via `cargo test`.
|
||||||
|
|
||||||
|
## Monitoring
|
||||||
|
- Healthcheck HTTP: endpoint `/health` retourne `{ "message": "ok" }` et code 200.
|
||||||
|
- Exposer métriques avec un reverse proxy/sidecar si nécessaire.
|
||||||
|
- Configurer l'orchestrateur pour vérifier périodiquement `/health`.
|
||||||
@ -1 +1 @@
|
|||||||
Subproject commit 09c2d1f96915979ef21b233bd1535225f981a4c5
|
Subproject commit b1be8e65ac578f7b2d9ef536ebdb1e4b864bcad7
|
||||||
@ -1 +1 @@
|
|||||||
Subproject commit 573a3e49e5391c49ed8169711d14275fd5d70dad
|
Subproject commit 91ed42e87923f749a54ceb8ebb39cfea325edc5c
|
||||||
@ -1,236 +0,0 @@
|
|||||||
# Scripts LeCoffre Node
|
|
||||||
|
|
||||||
Ce répertoire contient tous les scripts nécessaires au déploiement et à la gestion de l'architecture LeCoffre Node.
|
|
||||||
|
|
||||||
## 🚀 Scripts de Déploiement
|
|
||||||
|
|
||||||
### `start.sh`
|
|
||||||
**Script principal de démarrage séquentiel**
|
|
||||||
- Lance tous les services dans l'ordre logique
|
|
||||||
- Affiche la progression détaillée en temps réel
|
|
||||||
- Compatible avec le réseau Bitcoin Signet
|
|
||||||
- Gestion des timeouts et erreurs
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/start.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `deploy-master.sh`
|
|
||||||
**Déploiement de l'architecture autonome**
|
|
||||||
- Construit et lance le conteneur master
|
|
||||||
- Configure tous les ports et volumes
|
|
||||||
- Lance automatiquement les services
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/deploy-master.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `deploy-autonomous.sh`
|
|
||||||
**Déploiement autonome complet**
|
|
||||||
- Déploiement sans intervention manuelle
|
|
||||||
- Configuration automatique de tous les services
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/deploy-autonomous.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 💾 Scripts de Gestion des Données
|
|
||||||
|
|
||||||
### `backup-data.sh`
|
|
||||||
**Sauvegarde des données critiques**
|
|
||||||
- Sauvegarde Bitcoin, BlindBit, SDK Storage, SDK Signer
|
|
||||||
- Création d'archives compressées
|
|
||||||
- Gestion des permissions
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/backup-data.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `restore-data.sh`
|
|
||||||
**Restauration des données**
|
|
||||||
- Restaure depuis une sauvegarde
|
|
||||||
- Remplace les données existantes
|
|
||||||
- Confirmation de sécurité
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/restore-data.sh <backup_name>
|
|
||||||
```
|
|
||||||
|
|
||||||
### `update-images.sh`
|
|
||||||
**Mise à jour des images Docker**
|
|
||||||
- Sauvegarde automatique avant mise à jour
|
|
||||||
- Téléchargement des nouvelles images
|
|
||||||
- Protection des données
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/update-images.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 📊 Scripts de Monitoring
|
|
||||||
|
|
||||||
### `collect-logs.sh`
|
|
||||||
**Collecte des logs de tous les services**
|
|
||||||
- Collecte automatique ou par service
|
|
||||||
- Organisation par répertoires
|
|
||||||
- Timestamps sur les fichiers
|
|
||||||
|
|
||||||
```bash
|
|
||||||
# Tous les services
|
|
||||||
./scripts/collect-logs.sh
|
|
||||||
|
|
||||||
# Service spécifique
|
|
||||||
./scripts/collect-logs.sh bitcoin-signet
|
|
||||||
```
|
|
||||||
|
|
||||||
### `test-monitoring.sh`
|
|
||||||
**Tests des services de monitoring**
|
|
||||||
- Vérification Grafana, Loki, Promtail
|
|
||||||
- Tests de connectivité
|
|
||||||
- Validation des dashboards
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/test-monitoring.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `test-dashboards.sh`
|
|
||||||
**Tests des dashboards Grafana**
|
|
||||||
- Vérification des dashboards
|
|
||||||
- Tests des données sources
|
|
||||||
- Validation des métriques
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/test-dashboards.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🔧 Scripts de Configuration
|
|
||||||
|
|
||||||
### `sync-configs.sh`
|
|
||||||
**Synchronisation des configurations**
|
|
||||||
- Copie des configs vers les conteneurs
|
|
||||||
- Mise à jour des paramètres
|
|
||||||
- Redémarrage des services
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/sync-configs.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `sync-monitoring-config.sh`
|
|
||||||
**Configuration du monitoring**
|
|
||||||
- Configuration Grafana
|
|
||||||
- Configuration Loki/Promtail
|
|
||||||
- Déploiement des dashboards
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/sync-monitoring-config.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `setup-logs.sh`
|
|
||||||
**Configuration des logs**
|
|
||||||
- Création des répertoires de logs
|
|
||||||
- Configuration des permissions
|
|
||||||
- Setup des rotations
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/setup-logs.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🛠️ Scripts de Maintenance
|
|
||||||
|
|
||||||
### `fix_relay_funds.sh`
|
|
||||||
**Correction des fonds du relay**
|
|
||||||
- Vérification des fonds
|
|
||||||
- Correction des problèmes
|
|
||||||
- Tests de connectivité
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/fix_relay_funds.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `optimize-relay-startup.sh`
|
|
||||||
**Optimisation du démarrage du relay**
|
|
||||||
- Optimisation des paramètres
|
|
||||||
- Amélioration des performances
|
|
||||||
- Tests de stabilité
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/optimize-relay-startup.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `verify_mining_fix.sh`
|
|
||||||
**Vérification du minage**
|
|
||||||
- Tests du minage Signet
|
|
||||||
- Vérification des blocs
|
|
||||||
- Validation des transactions
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/verify_mining_fix.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🔒 Scripts de Sécurité
|
|
||||||
|
|
||||||
### `generate-ssl-certs.sh`
|
|
||||||
**Génération des certificats SSL**
|
|
||||||
- Création des certificats
|
|
||||||
- Configuration HTTPS
|
|
||||||
- Sécurisation des communications
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/generate-ssl-certs.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
### `uninstall-host-nginx.sh`
|
|
||||||
**Désinstallation de Nginx host**
|
|
||||||
- Nettoyage de Nginx
|
|
||||||
- Suppression des configurations
|
|
||||||
- Libération des ports
|
|
||||||
|
|
||||||
```bash
|
|
||||||
./scripts/uninstall-host-nginx.sh
|
|
||||||
```
|
|
||||||
|
|
||||||
## 📁 Structure des Volumes
|
|
||||||
|
|
||||||
Les données sont persistées dans les volumes Docker suivants :
|
|
||||||
|
|
||||||
- `4nk_node_bitcoin_data` : Données Bitcoin Signet
|
|
||||||
- `4nk_node_blindbit_data` : Données BlindBit Oracle
|
|
||||||
- `4nk_node_sdk_data` : Données SDK Relay
|
|
||||||
- `4nk_node_sdk_storage_data` : Données SDK Storage
|
|
||||||
- `4nk_node_grafana_data` : Données Grafana
|
|
||||||
- `4nk_node_loki_data` : Données Loki
|
|
||||||
|
|
||||||
## 🔄 Workflow de Déploiement
|
|
||||||
|
|
||||||
1. **Déploiement initial** : `./scripts/deploy-master.sh`
|
|
||||||
2. **Démarrage des services** : `./scripts/start.sh`
|
|
||||||
3. **Vérification** : `./scripts/test-monitoring.sh`
|
|
||||||
4. **Sauvegarde** : `./scripts/backup-data.sh`
|
|
||||||
|
|
||||||
## 🔄 Workflow de Mise à Jour
|
|
||||||
|
|
||||||
1. **Sauvegarde** : `./scripts/backup-data.sh`
|
|
||||||
2. **Mise à jour** : `./scripts/update-images.sh`
|
|
||||||
3. **Redémarrage** : `./scripts/start.sh`
|
|
||||||
4. **Vérification** : `./scripts/test-monitoring.sh`
|
|
||||||
|
|
||||||
## 🆘 Récupération d'Urgence
|
|
||||||
|
|
||||||
En cas de problème :
|
|
||||||
|
|
||||||
1. **Arrêt des services** : `docker compose down`
|
|
||||||
2. **Restauration** : `./scripts/restore-data.sh <backup>`
|
|
||||||
3. **Redémarrage** : `./scripts/start.sh`
|
|
||||||
|
|
||||||
## 📝 Logs et Debugging
|
|
||||||
|
|
||||||
- **Logs des services** : `./logs/<service>/`
|
|
||||||
- **Collecte des logs** : `./scripts/collect-logs.sh`
|
|
||||||
- **Monitoring** : Grafana sur port 3005
|
|
||||||
- **Status API** : Port 3006
|
|
||||||
|
|
||||||
## ⚠️ Notes Importantes
|
|
||||||
|
|
||||||
- Tous les scripts préservent les données importantes
|
|
||||||
- Les sauvegardes sont automatiques lors des mises à jour
|
|
||||||
- Le réseau Bitcoin Signet est utilisé par défaut
|
|
||||||
- Les volumes Docker garantissent la persistance des données
|
|
||||||
@ -13,44 +13,71 @@ git submodule init >/dev/null 2>&1 || true
|
|||||||
git submodule foreach --recursive '
|
git submodule foreach --recursive '
|
||||||
set -e
|
set -e
|
||||||
echo "[submodule] Enter: $name ($path)"
|
echo "[submodule] Enter: $name ($path)"
|
||||||
git fetch origin ext || true
|
# Ensure remote exists
|
||||||
if ! git rev-parse --verify ext >/dev/null 2>&1; then
|
git remote show origin >/dev/null 2>&1 || { echo "[submodule] missing origin remote"; exit 0; }
|
||||||
|
git config pull.rebase true || true
|
||||||
|
git fetch --prune origin +refs/heads/*:refs/remotes/origin/* || true
|
||||||
|
# Ensure local ext tracking origin/ext when available
|
||||||
if git show-ref --verify --quiet refs/remotes/origin/ext; then
|
if git show-ref --verify --quiet refs/remotes/origin/ext; then
|
||||||
|
if git rev-parse --verify ext >/dev/null 2>&1; then
|
||||||
|
git switch ext
|
||||||
|
git branch --set-upstream-to=origin/ext ext || true
|
||||||
|
else
|
||||||
git switch -C ext origin/ext
|
git switch -C ext origin/ext
|
||||||
|
fi
|
||||||
|
else
|
||||||
|
# Fallback: create ext if missing on remote
|
||||||
|
if git rev-parse --verify ext >/dev/null 2>&1; then
|
||||||
|
git switch ext
|
||||||
else
|
else
|
||||||
git switch -C ext
|
git switch -C ext
|
||||||
fi
|
fi
|
||||||
else
|
|
||||||
git switch ext
|
|
||||||
fi
|
fi
|
||||||
git pull --ff-only || true
|
# Rebase on remote if present to avoid non-fast-forward
|
||||||
|
git fetch origin ext || true
|
||||||
|
git rev-parse --verify origin/ext >/dev/null 2>&1 && git pull --rebase --autostash origin ext || true
|
||||||
|
# Stage and commit if needed
|
||||||
git add -A
|
git add -A
|
||||||
if ! git diff --cached --quiet; then
|
if ! git diff --cached --quiet; then
|
||||||
git commit -m "auto_clea"
|
git commit -m "auto_clea"
|
||||||
git push -u origin ext || true
|
fi
|
||||||
else
|
# Push with upstream set; handle non-FF by one-time rebase+retry
|
||||||
echo "[submodule] No changes to commit"
|
if ! git push -u origin ext; then
|
||||||
|
echo "[submodule] push failed, retrying after rebase"
|
||||||
|
git fetch origin ext || true
|
||||||
|
git pull --rebase --autostash origin ext || true
|
||||||
|
git push -u origin ext || echo "[submodule] push still failing for $name"
|
||||||
fi
|
fi
|
||||||
'
|
'
|
||||||
|
|
||||||
echo "[root] Process root repository"
|
echo "[root] Process root repository"
|
||||||
git fetch origin ext || true
|
git config pull.rebase true || true
|
||||||
if ! git rev-parse --verify ext >/dev/null 2>&1; then
|
git fetch --prune origin +refs/heads/*:refs/remotes/origin/* || true
|
||||||
if git show-ref --verify --quiet refs/remotes/origin/ext; then
|
if git show-ref --verify --quiet refs/remotes/origin/ext; then
|
||||||
|
if git rev-parse --verify ext >/dev/null 2>&1; then
|
||||||
|
git switch ext
|
||||||
|
git branch --set-upstream-to=origin/ext ext || true
|
||||||
|
else
|
||||||
git switch -C ext origin/ext
|
git switch -C ext origin/ext
|
||||||
|
fi
|
||||||
|
else
|
||||||
|
if git rev-parse --verify ext >/dev/null 2>&1; then
|
||||||
|
git switch ext
|
||||||
else
|
else
|
||||||
git switch -C ext
|
git switch -C ext
|
||||||
fi
|
fi
|
||||||
else
|
|
||||||
git switch ext
|
|
||||||
fi
|
fi
|
||||||
git pull --ff-only || true
|
git fetch origin ext || true
|
||||||
|
git rev-parse --verify origin/ext >/dev/null 2>&1 && git pull --rebase --autostash origin ext || true
|
||||||
git add -A
|
git add -A
|
||||||
if ! git diff --cached --quiet; then
|
if ! git diff --cached --quiet; then
|
||||||
git commit -m "auto_clea"
|
git commit -m "auto_clea"
|
||||||
git push -u origin ext
|
fi
|
||||||
else
|
if ! git push -u origin ext; then
|
||||||
echo "[root] No changes to commit"
|
echo "[root] push failed, retrying after rebase"
|
||||||
|
git fetch origin ext || true
|
||||||
|
git pull --rebase --autostash origin ext || true
|
||||||
|
git push -u origin ext || echo "[root] push still failing"
|
||||||
fi
|
fi
|
||||||
|
|
||||||
echo "[push-ext-commit] Done."
|
echo "[push-ext-commit] Done."
|
||||||
|
|||||||
@ -1 +1 @@
|
|||||||
Subproject commit a20dbd2f9f0b51ea08529a3ab4b220b4a89b1535
|
Subproject commit 0133e31bc4ebb0faf5536a388d25f7ba0c85c1c3
|
||||||
@ -1 +1 @@
|
|||||||
Subproject commit bc9bd7b92a3da2a6efa3454997375dd611ca5dba
|
Subproject commit 4dad51241c559f9895f3f986b5deea7484189e88
|
||||||
Loading…
x
Reference in New Issue
Block a user