4nk/4NK_env
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: 4nk:ext
Branches Tags
4nk:ext
4nk:int-dev
..
compare: 4nk:int-dev
Branches Tags
4nk:ext
4nk:int-dev

5 Commits
ext ... int-dev

Author SHA1 Message Date
Omar Oughriss
6e4a1956fa Update submodules to latest int-dev commit 2025-09-22 15:05:03 +02:00
Omar Oughriss
22fe4c92d6 Update submodules to latest int-dev commit 2025-09-22 14:34:35 +02:00
Omar Oughriss
ae7ab33203 Update lecoffre-back-mini to latest int-dev commit 2025-09-22 13:55:20 +02:00
Omar Oughriss
54d36115b9 Update lecoffre-back-mini to latest int-dev commit 2025-09-22 13:30:39 +02:00
Omar Oughriss
5883c1cf12 Remplace all 'ext' tags for 'int-dev' 2025-09-22 13:01:48 +02:00
233 changed files with 3688 additions and 19468 deletions
Show Stats Expand all files Collapse all files

8
.cursor/rules/important.mdc
View File

@ -1,8 +0,0 @@
---
description:
Les règles sont dans IA_agents/ du projet, il faut tout lire ce sont les règles et informations importantes, les prompts sont encore plus important
Au démarrage de ton travail sur un projet suit : IA_agents/prompts/prompt-start.md
alwaysApply: true
---

96
.cursorignore
View File

@ -1,95 +1 @@
# 4NK Environment - Git Ignore
# ============================
confs/
# Dossiers de sauvegarde des scripts
**/backup/
**/*backup*
**/.cargo/
# Fichiers temporaires
**/*.tmp*
**/*.temp*
**/*.log*
**/*.pid*
# Fichiers de configuration locale
**/*.env*
**/*.conf*
**/*.yaml*
**/*.yml*
**/*.ini*
**/*.json*
**/*.toml*
**/*.lock*
# Données et logs
**/*.logs*
**/*.data
*.db
*.sqlite
# Certificats et clés
**/*.key
**/*.pem
**/*.crt
**/*.p12
**/*.pfx
ssl/
certs/
# Docker
**/*.docker*
# Cache et build
**/node_modules/
**/dist/
**/build/
**/target/
**/.next/
**/.turbo/
**/coverage/
**/.pytest_cache/
**/.cache/
**/.pnpm-store/
**/.venv/
**/vendor/
**/*.*.o
**/*.so
**/*.dylib
# IDE et éditeurs
**/*.vscode/
**/*.idea/
**/*.swp
**/*.swo
**/*~
# OS
**/*.DS_Store
**/*Thumbs.db
**/*tmp*
# Git
**/*.git/
**/*.orig*
# Backup des projets existants
**/*backup*
**/backups/
**/*backups*
**/*wallet*
**/*keys*
**/*node_modules*
**/*cursor*
**/*pid*
**/*next*
# Dossiers de logs communs
log/
logs/
**/log/
**/logs/
# Add directories or file patterns to ignore during indexing (e.g. foo/ or *.csv)

0
.cursorrules Normal file
View File

176
.dockerignore
View File

@ -1,95 +1,123 @@
# 4NK Environment - Git Ignore
# ============================
confs/
# Dossiers de sauvegarde des scripts
**/backup/
**/*backup*
# 4NK Environment - Docker Ignore
# ===============================
**/.cargo/
# Git
.git/
.gitignore
.gitattributes
# Fichiers temporaires
**/*.tmp*
**/*.temp*
**/*.log*
**/*.pid*
# Documentation
README.md
docs/
*.md
!Dockerfile*
# Fichiers de configuration locale
**/*.env*
**/*.conf*
**/*.yaml*
**/*.yml*
**/*.ini*
**/*.json*
**/*.toml*
**/*.lock*
# Scripts de développement
scripts/
*.sh
!scripts/clone-all-repos.sh
# Configuration locale
.env
.env.*
!env.master
!env.example
# Données et logs
**/*.logs*
**/*.data
data/
logs/
*.log
*.data
*.db
*.sqlite
# Certificats et clés
**/*.key
**/*.pem
**/*.crt
**/*.p12
**/*.pfx
# Cache et build
node_modules/
dist/
build/
target/
*.o
*.so
*.dylib
# IDE et éditeurs
.vscode/
.idea/
*.swp
*.swo
*~
# OS
.DS_Store
Thumbs.db
*.tmp
# Backup
*.backup/
backup/
# Certificats (sauf ceux nécessaires)
*.key
*.pem
ssl/
certs/
# Docker
**/*.docker*
.docker/
docker-data/
docker-volumes/
docker-compose.override.yml
# Cache et build
**/node_modules/
**/dist/
**/build/
**/target/
**/.next/
**/.turbo/
**/coverage/
**/.pytest_cache/
**/.cache/
**/.pnpm-store/
**/.venv/
**/vendor/
**/*.*.o
**/*.so
**/*.dylib
# Monitoring
prometheus-data/
grafana-data/
loki-data/
# IDE et éditeurs
**/*.vscode/
**/*.idea/
**/*.swp
**/*.swo
**/*~
# Bitcoin et crypto
.bitcoin/
.4nk/
wallet/
keys/
# OS
**/*.DS_Store
**/*Thumbs.db
**/*tmp*
# Nginx cache et logs
nginx-cache/
nginx-logs/
# Git
**/*.git/
**/*.orig*
# Supervisor logs
supervisor-logs/
# Backup des projets existants
**/*backup*
**/backups/
**/*backups*
# Tests
tests/
test/
spec/
*.test.js
*.spec.js
# Coverage
coverage/
.nyc_output/
**/*wallet*
**/*keys*
# Temporary files
tmp/
temp/
*.tmp
*.temp
**/*node_modules*
**/*cursor*
**/*pid*
**/*next*
# Large files
*.tar
*.tar.gz
*.zip
*.rar
# Dossiers de logs communs
log/
logs/
**/log/
**/logs/
# Development tools
.eslintrc*
.prettierrc*
jest.config.*
tsconfig.json
package-lock.json
yarn.lock
Cargo.lock
# Project specific ignores
office.json
*.backup

131
.gitignore vendored
View File

@ -1,95 +1,98 @@
# 4NK Environment - Git Ignore
# ============================
confs/
# Dossiers de sauvegarde des scripts
**/backup/
**/*backup*
**/.cargo/
# Dossiers de sauvegarde des scripts
*.backup/
backup/
# Fichiers temporaires
**/*.tmp*
**/*.temp*
**/*.log*
**/*.pid*
*.tmp
*.temp
*.log
*.pid
# Fichiers de configuration locale
**/*.env*
**/*.conf*
**/*.yaml*
**/*.yml*
**/*.ini*
**/*.json*
**/*.toml*
**/*.lock*
.env
.env.*
!env.master
!env.example
# Données et logs
**/*.logs*
**/*.data
data/
logs/
*.data
*.db
*.sqlite
# Certificats et clés
**/*.key
**/*.pem
**/*.crt
**/*.p12
**/*.pfx
*.key
*.pem
*.crt
*.p12
*.pfx
ssl/
certs/
# Docker
**/*.docker*
.docker/
docker-data/
docker-volumes/
# Cache et build
**/node_modules/
**/dist/
**/build/
**/target/
**/.next/
**/.turbo/
**/coverage/
**/.pytest_cache/
**/.cache/
**/.pnpm-store/
**/.venv/
**/vendor/
**/*.*.o
**/*.so
**/*.dylib
node_modules/
dist/
build/
target/
*.o
*.so
*.dylib
# IDE et éditeurs
**/*.vscode/
**/*.idea/
**/*.swp
**/*.swo
**/*~
.vscode/
.idea/
*.swp
*.swo
*~
# OS
**/*.DS_Store
**/*Thumbs.db
**/*tmp*
.DS_Store
Thumbs.db
*.tmp
# Git
**/*.git/
**/*.orig*
.git/
*.orig
# Backup des projets existants
**/*backup*
**/backups/
**/*backups*
*.backup/
# Fichiers de configuration spécifiques au host
host-config/
local-config/
**/*wallet*
**/*keys*
# Données sensibles
secrets/
private/
confidential/
**/*node_modules*
**/*cursor*
**/*pid*
**/*next*
# Monitoring et métriques
prometheus-data/
grafana-data/
loki-data/
# Dossiers de logs communs
log/
logs/
**/log/
**/logs/
# Bitcoin et crypto
.bitcoin/
.4nk/
wallet/
keys/
# Nginx
nginx-cache/
nginx-logs/
# Supervisor
supervisor-logs/
# Scripts de déploiement temporaires
deploy-*.tmp
setup-*.tmp

113
.gitmodules vendored
View File

@ -1,73 +1,44 @@
[submodule "sdk_relay"]
path = 4NK_modules/sdk_relay
url = git@git.4nkweb.com:4nk/sdk_relay.git
branch = ext
[submodule "sdk_storage"]
path = 4NK_modules/sdk_storage
url = git@git.4nkweb.com:4nk/sdk_storage.git
branch = ext
[submodule "ihm_client"]
path = 4NK_modules/ihm_client
url = git@git.4nkweb.com:4nk/ihm_client.git
branch = ext
[submodule "doc_api"]
path = 4NK_modules/doc_api
url = git@git.4nkweb.com:4nk/doc_api.git
branch = ext
[submodule "sdk_signer"]
path = 4NK_modules/sdk_signer
url = git@git.4nkweb.com:4nk/sdk_signer.git
branch = ext
[submodule "skeleton"]
path = 4NK_modules/skeleton
url = git@git.4nkweb.com:4nk/skeleton.git
branch = dev
[submodule "sdk-signer-client"]
path = 4NK_modules/sdk-signer-client
url = git@git.4nkweb.com:4nk/sdk-signer-client.git
branch = ext
[submodule "sdk_client"]
path = 4NK_modules/sdk_client
url = git@git.4nkweb.com:4nk/sdk_client.git
branch = ext
[submodule "sdk_common"]
path = 4NK_modules/sdk_common
url = git@git.4nkweb.com:4nk/sdk_common.git
branch = ext
[submodule "rust-silentPayments"]
path = 4NK_modules/rust-silentpayments
url = git@github.com:Sosthene00/rust-silentPayments.git
branch = add-utils
[submodule "blindbit-oracle"]
path = 4NK_modules/blindbit-oracle
url = git.4nkweb.com/4nk/blindbit-oracle
branch = fixed-source
[submodule "4NK_vault"]
path = 4NK_modules/4NK_vault
url = git@git.4nkweb.com:4nk/4NK_vault.git
branch = ext
[submodule "4NK_certificator"]
path = 4NK_modules/4NK_certificator
url = git@git.4nkweb.com:4nk/4NK_certificator.git
branch = main
[submodule "4NK_miner"]
path = 4NK_modules/4NK_miner
url = git@git.4nkweb.com:4nk/4NK_miner.git
branch = main
[submodule "4NK_web_status"]
path = 4NK_modules/4NK_web_status
url = git@git.4nkweb.com:4nk/4NK_web_status.git
branch = main
[submodule "lecoffre-front"]
path = projects/lecoffre/lecoffre-front
url = git@git.4nkweb.com:4nk/lecoffre-front.git
branch = ext
[submodule "lecoffre-back-mini"]
path = projects/lecoffre/lecoffre-back-mini
url = git@git.4nkweb.com:4nk/lecoffre-back-mini.git
branch = ext
[submodule "lecoffre_node"]
path = projects/lecoffre/lecoffre_node
path = lecoffre_node
url = git@git.4nkweb.com:4nk/lecoffre_node.git
branch = ext
branch = int-dev
[submodule "sdk_relay"]
path = sdk_relay
url = git@git.4nkweb.com:4nk/sdk_relay.git
branch = int-dev
[submodule "sdk_signer"]
path = sdk_signer
url = git@git.4nkweb.com:4nk/sdk_signer.git
branch = int-dev
[submodule "sdk_storage"]
path = sdk_storage
url = git@git.4nkweb.com:4nk/sdk_storage.git
branch = int-dev
[submodule "sdk_client"]
path = sdk_client
url = git@git.4nkweb.com:4nk/sdk_client.git
branch = int-dev
[submodule "sdk_common"]
path = sdk_common
url = git@git.4nkweb.com:4nk/sdk_common.git
branch = int-dev
[submodule "sdk-signer-client"]
path = sdk-signer-client
url = git@git.4nkweb.com:4nk/sdk-signer-client.git
branch = int-dev
[submodule "ihm_client"]
path = ihm_client
url = git@git.4nkweb.com:4nk/ihm_client.git
branch = int-dev
[submodule "lecoffre-back-mini"]
path = lecoffre-back-mini
url = git@git.4nkweb.com:4nk/lecoffre-back-mini.git
branch = int-dev
[submodule "lecoffre-front"]
path = lecoffre-front
url = git@git.4nkweb.com:4nk/lecoffre-front.git
branch = int-dev
[submodule "doc_api"]
path = doc_api
url = git@git.4nkweb.com:4nk/doc_api.git
branch = int-dev

1
4NK_modules/4NK_certificator

@ -1 +0,0 @@
Subproject commit 26d2dffa072775040c213ea2139e63856fa6bc7d

1
4NK_modules/4NK_miner

@ -1 +0,0 @@
Subproject commit be199069cdceffa319f1fa1f9878a0936a81f399

1
4NK_modules/4NK_vault

@ -1 +0,0 @@
Subproject commit ae157527f0478e8975a4d1943822c2de4ebb16d6

1
4NK_modules/4NK_web_status

@ -1 +0,0 @@
Subproject commit 19dcb215982af2d8c4d9c8755b978015f9531c39

1
4NK_modules/blindbit-oracle

@ -1 +0,0 @@
Subproject commit 0f78e976ff4b2549fa8532255694cfb7693622ac

1
4NK_modules/ihm_client

@ -1 +0,0 @@
Subproject commit d179aa704e3c6c0ae756ec5dc5d3a1288567cb0e

1
4NK_modules/rust-silentpayments

@ -1 +0,0 @@
Subproject commit 74a67b285c2e9eae3b15b46b70be7aad5539df73

1
4NK_modules/sdk-signer-client

@ -1 +0,0 @@
Subproject commit 7c7efe27763ba06a7f220a54df2281ff90d71457

1
4NK_modules/sdk_client

@ -1 +0,0 @@
Subproject commit d80832ca993b160e1f84585feee5a3f5c94141b5

1
4NK_modules/sdk_common

@ -1 +0,0 @@
Subproject commit 43b117bc9a9539fff9f0b886bae459deecf6480d

1
4NK_modules/sdk_relay

@ -1 +0,0 @@
Subproject commit ee28345c12e9b6d3d8b1eaeecb37c8b7a56739e4

1
4NK_modules/sdk_signer

@ -1 +0,0 @@
Subproject commit cf9433b6067646b2d211ff76610d77fcb7a8943b

1
4NK_modules/sdk_storage

@ -1 +0,0 @@
Subproject commit 650b934e0c5f07c31fe25936cfa16471536f9722

1
4NK_modules/skeleton

@ -1 +0,0 @@
Subproject commit 1869d4509b70de9959d9bf055a0065fee9b069fb

2
AGENTS.md
View File

@ -1,2 +0,0 @@
Les règles sont dans IA_agents/ du projet, il faut tout lire ce sont les règles et informations importantes, les prompts sont encore plus important
Au démarrage de ton travail sur un projet suit : IA_agents/prompts/prompt-start.md

10
CHANGELOG.md
View File

@ -1,10 +0,0 @@
## [Unreleased]
### Changed
- lecoffre-front (docker-compose): switch to local build using repository Dockerfile for durable deployment of IdNot state-based flow.
- Ensure NEXT_PUBLIC variables are injected via env_file (.env.master) rather than relying on image defaults.
### Added
- docs/idnot-front-agnostic.md describing the front-agnostic IdNot flow, envs, Nginx, and operations.
- lecoffre_node/ENV_EXAMPLE.md documenting example .env.master contents for the frontend.

3
CODEOWNERS
View File

@ -1,3 +0,0 @@
# Code owners par défaut du dépôt
# Ajustez ces lignes si vous utilisez des équipes/alias différents.
* @nicolas.cantu

9
CODE_OF_CONDUCT.md
View File

@ -1,9 +0,0 @@
# Code de Conduite
Nous nous engageons à offrir une communauté ouverte, accueillante et respectueuse.
- Pas de harcèlement.
- Respect des avis techniques et des personnes.
- Suivre les consignes des mainteneurs.
Signalez tout problème via les issues du dépôt.

277
CONTRIBUTING.md
View File

@ -1,277 +0,0 @@
# Contribuer à 4NK Environment
Merci de votre intérêt pour contribuer au projet 4NK Environment ! Ce document fournit des directives pour contribuer efficacement à l'écosystème 4NK.
## 📋 Table des matières
- [Code de conduite](#code-de-conduite)
- [Comment contribuer](#comment-contribuer)
- [Processus de développement](#processus-de-développement)
- [Standards de code](#standards-de-code)
- [Tests](#tests)
- [Documentation](#documentation)
- [Déploiement](#déploiement)
- [Questions et support](#questions-et-support)
## 🤝 Code de conduite
Ce projet adhère à notre [Code de Conduite](CODE_OF_CONDUCT.md). En participant, vous acceptez de respecter ces règles.
## 🚀 Comment contribuer
### Types de contributions
- **🐛 Corrections de bugs** : Signaler et corriger des problèmes
- **✨ Nouvelles fonctionnalités** : Ajouter des capacités
- **📚 Documentation** : Améliorer la documentation
- **🧪 Tests** : Ajouter ou améliorer les tests
- **🔧 Maintenance** : Refactoring, optimisation, nettoyage
### Processus de contribution
1. **Créer une issue** pour discuter des changements majeurs
2. **Fork le repository** si nécessaire
3. **Créer une branche** de fonctionnalité
4. **Développer** avec les standards de code
5. **Tester** vos modifications
6. **Documenter** les changements
7. **Soumettre** une Pull Request
## 🛠️ Processus de développement
### Structure du projet
```
4NK_env/
├── 4NK_modules/ # Modules 4NK (SDKs, services)
├── projects/ # Projets applicatifs (LeCoffre)
├── docs/ # Documentation technique
├── IA_agents/ # Agents IA et prompts
├── scripts/ # Scripts de déploiement
└── confs/ # Configurations centralisées
```
### Branches
- **`main`** : Branche principale stable
- **`ext`** : Branche de développement étendue
- **`feature/*`** : Nouvelles fonctionnalités
- **`fix/*`** : Corrections de bugs
- **`docs/*`** : Améliorations documentation
### Workflow Git
```bash
# 1. Créer une branche de fonctionnalité
git checkout -b feature/nouvelle-fonctionnalite
# 2. Développer et tester
# ... modifications ...
# 3. Commiter avec un message descriptif
git add .
git commit -m "feat: ajouter nouvelle fonctionnalité X"
# 4. Pousser la branche
git push origin feature/nouvelle-fonctionnalite
# 5. Créer une Pull Request (si applicable)
```
## 📝 Standards de code
### Messages de commit
Utilisez le format conventionnel :
```
type(scope): description
[corps optionnel]
[footer optionnel]
```
**Types** :
- `feat` : Nouvelle fonctionnalité
- `fix` : Correction de bug
- `docs` : Documentation
- `style` : Formatage, point-virgules manquants, etc.
- `refactor` : Refactoring de code
- `test` : Ajout de tests
- `chore` : Maintenance, dépendances
**Exemples** :
```
feat(sdk_relay): ajouter support WebSocket sécurisé
fix(lecoffre): corriger authentification OAuth2
docs(architecture): mettre à jour diagrammes de flux
```
### Standards par technologie
#### Rust (modules 4NK)
```bash
# Formatage
cargo fmt
# Linting
cargo clippy
# Tests
cargo test
# Documentation
cargo doc --open
```
#### TypeScript/JavaScript (frontend)
```bash
# Formatage
npm run format
# Linting
npm run lint
# Tests
npm test
# Build
npm run build
```
#### Docker
- Utiliser des images officielles
- Multi-stage builds pour optimiser la taille
- Utilisateurs non-root
- Healthchecks appropriés
## 🧪 Tests
### Tests obligatoires
- **Tests unitaires** : Fonctionnalités individuelles
- **Tests d'intégration** : Interactions entre composants
- **Tests de déploiement** : Validation des scripts
- **Tests de sécurité** : Vérification des bonnes pratiques
### Exécution des tests
```bash
# Tests globaux
./scripts/test-all.sh
# Tests par module
cd 4NK_modules/sdk_relay && cargo test
cd projects/lecoffre/lecoffre-front && npm test
# Tests de déploiement
./scripts/validate-deployment.sh
```
## 📚 Documentation
### Types de documentation
- **README.md** : Vue d'ensemble du projet
- **docs/** : Documentation technique détaillée
- **IA_agents/** : Prompts et guides pour agents IA
- **Commentaires de code** : Documentation inline
### Standards de documentation
- **Markdown** pour tous les documents
- **Diagrammes** avec Mermaid ou PlantUML
- **Exemples de code** fonctionnels
- **Liens** vers les ressources externes
### Mise à jour de la documentation
```bash
# Vérifier la cohérence
./scripts/validate-docs.sh
# Générer la documentation
./scripts/generate-docs.sh
```
## 🚀 Déploiement
### Environnements
- **Développement** : Tests et développement local
- **Staging** : Validation avant production
- **Production** : Environnement de production
### Processus de déploiement
1. **Tests** : Validation complète
2. **Build** : Construction des artefacts
3. **Déploiement** : Mise en production
4. **Validation** : Vérification post-déploiement
5. **Monitoring** : Surveillance continue
### Scripts de déploiement
```bash
# Déploiement complet
./scripts/deploy-all.sh
# Déploiement par phase
./scripts/deploy-phase-base.sh
./scripts/deploy-phase-blockchain.sh
./scripts/deploy-phase-application.sh
```
## 🔒 Sécurité
### Bonnes pratiques
- **Aucun secret** dans le code source
- **Variables d'environnement** pour la configuration
- **Utilisateurs non-root** dans les conteneurs
- **Clés SSH** pour l'authentification Git
- **Chiffrement** des données sensibles
### Signalement de vulnérabilités
Pour signaler une vulnérabilité de sécurité :
1. **Ne pas** créer d'issue publique
2. **Contacter** directement l'équipe de sécurité
3. **Attendre** la confirmation avant divulgation
## 📞 Questions et support
### Canaux de communication
- **Issues GitHub** : Bugs et demandes de fonctionnalités
- **Discussions** : Questions générales
- **Documentation** : Guides et références
### Obtenir de l'aide
1. **Consulter** la documentation existante
2. **Rechercher** dans les issues existantes
3. **Créer** une nouvelle issue si nécessaire
4. **Fournir** le contexte et les détails
## 🏷️ Versioning
Le projet utilise le [Semantic Versioning](https://semver.org/) :
- **MAJOR** : Changements incompatibles
- **MINOR** : Nouvelles fonctionnalités compatibles
- **PATCH** : Corrections de bugs
## 📄 Licence
Ce projet est sous licence MIT. Voir le fichier [LICENSE](LICENSE) pour plus de détails.
## 🙏 Remerciements
Merci à tous les contributeurs qui rendent ce projet possible !
---
**Dernière mise à jour** : 2024-09-25
**Version** : 1.0.0

195
IA_agents/AGENTS_SYNTHESIS.md
View File

@ -1,195 +0,0 @@
# Synthèse pour Agents IA - 4NK Environment
**Date** : 2025-01-27
**Version** : 1.0
**Usage** : Guide de synthèse pour les agents IA travaillant sur l'environnement 4NK
## 🎯 Contexte Général
### Environnement de Développement Centralisé
- **Machine principale** : dev4.4nkweb.com (LeCoffre)
- **Nœud de bootstrap** : dev3.4nkweb.com (signer centralisé, mini back)
- **Architecture** : 4NK modules + Projet LeCoffre (notaires)
- **Gestion des configurations** : 4NK_vault (API sécurisée)
## 🏗️ Architecture 4NK - Modules Principaux
### Services Core
1. **sdk_relay** (8090/8091) - Relais WebSocket central
2. **sdk_storage** (8081) - Stockage temporaire sécurisé
3. **sdk_signer** - Service de signature TypeScript
4. **sdk_client** - Client SDK (WASM)
5. **sdk_common** - Composants communs
6. **ihm_client** (3003) - Interface de gestion des clés
### Services Spécialisés
7. **4NK_vault** (6666) - API sécurisée de gestion des configurations
8. **4NK_certificator** - Ancrage cryptographique sur Bitcoin
9. **4NK_miner** - Service de minage (test)
10. **4NK_web_status** - Monitoring et statut
11. **blindbit-oracle** (8000) - Oracle Bitcoin Silent Payments
12. **rust-silentpayments** - Implémentation Silent Payments
## 🏢 Projet LeCoffre - Architecture Notariale
### Composants
- **lecoffre_node** - Docker de contrôle (orchestrateur principal)
- **lecoffre-front** - Frontend Next.js (interface notaires)
- **lecoffre-back-mini** - Backend centralisé (APIs externes)
### URLs et Services
- **LeCoffre Front** : https://dev4.4nkweb.com/lecoffre
- **4NK iframe** : https://dev4.4nkweb.com
- **Signer centralisé** : dev3.4nkweb.com (module 4NK pour notaires)
- **Mini back** : dev3.4nkweb.com (Stripe, Mailchimp, OVH, IdNot)
## 🔐 4NK_vault - Gestion Centralisée des Configurations
### Rôle Critique
- **API sécurisée** pour la gestion des configurations
- **Chiffrement quantique résistant** (ChaCha20-Poly1305)
- **Authentification par clés utilisateur**
- **Rotation automatique des clés** (toutes les heures)
- **Synchronisation** vers `confs/` dans le docker de contrôle
### Sécurité
- **Fichiers .env inaccessibles** pour des raisons de sécurité
- **Variables séparées** des secrets
- **Configurations déployées** dans `confs/` pour visualisation
- **Isolation par environnement** (dev, prod)
## 🚀 Déploiement par Phases - RÈGLES CRITIQUES
### ⚠️ INTERDICTIONS ABSOLUES
```bash
# ❌ JAMAIS utiliser ces commandes
docker compose --env-file .env.master up -d
docker compose up -d
docker compose start
```
### ✅ SCRIPTS OBLIGATOIRES
```bash
# Démarrage complet avec phases
./scripts/start-with-progress.sh
# Démarrage monitoring indépendant
./scripts/start-monitoring.sh
# Surveillance et validation
./scripts/monitor-progress.sh
./scripts/validate-deployment.sh
```
### Phases de Déploiement
1. **Phase 1** : Services de base (tor, sdk_storage, status-api)
2. **Phase 2** : Services blockchain (bitcoin → blindbit → sdk_relay)
3. **Phase 3** : Services applicatifs (lecoffre-front, ihm_client)
4. **Phase 4** : Services de monitoring (loki → promtail → grafana)
5. **Phase 5** : Services utilitaires (watchtower)
## 📊 Monitoring et Observabilité
### Stack de Monitoring
- **Grafana** : Dashboards et visualisation
- **Loki** : Collecte et stockage des logs
- **Promtail** : Agent de collecte des logs
- **Watchtower** : Mise à jour automatique
### Configuration Loki (CRITIQUE)
- **OBLIGATOIRE** : `http_listen_address: 0.0.0.0` (pas 127.0.0.1)
- **OBLIGATOIRE** : `instance_addr: 0.0.0.0` (pas 127.0.0.1)
- **Fichier** : `/conf/loki/loki-config.yaml`
## 🔧 Scripts de Gestion
### Scripts Principaux
- `start.sh` - Démarrage complet avec phases
- `validate-deployment.sh` - Validation du déploiement
- `maintenance.sh` - Menu de maintenance interactif
- `backup-data.sh` - Sauvegarde des données
- `update-images.sh` - Mise à jour sécurisée
### Scripts de Monitoring
- `monitor-progress.sh` - Aperçu des services
- `watch-progress.sh` - Surveillance temps réel
- `logs-with-progress.sh` - Logs avec progression
## 📚 Documentation Centralisée
### Structure
- **IA_agents/** : Documentation pour les agents IA
- **docs/** : Documentation technique centralisée
- **ARCHITECTURE_ANALYSIS.md** : Analyse architecturale complète
### Documents Obligatoires
1. **ARCHITECTURE_ANALYSIS.md** - Analyse architecturale complète
2. **deployment-architecture.md** - Architecture de déploiement
3. **best-practices-deployment.md** - Bonnes pratiques
4. **README.md** - Documentation principale
## 🎯 Points Clés pour les Agents IA
### 1. **Respect des Phases**
- Services applicatifs indépendants du monitoring
- Démarrage séquentiel selon les dépendances
- Monitoring indépendant des applications
### 2. **Sécurité des Configurations**
- 4NK_vault pour la gestion centralisée
- Fichiers .env inaccessibles
- Configurations synchronisées vers confs/
### 3. **Scripts Spécialisés**
- Utilisation obligatoire des scripts fournis
- Interdiction des commandes Docker Compose directes
- Surveillance continue et diagnostic facilité
### 4. **Architecture Modulaire**
- Modules 4NK : SDK, services, monitoring
- Projet LeCoffre : Interface notariale
- 4NK_vault : Gestion centralisée des configurations
## 🚨 Signaux d'Alerte
### Si vous voyez ces commandes, c'est une ERREUR :
```bash
docker compose --env-file .env.master up -d
docker compose up -d
docker compose start
```
### Si vous voyez ces comportements, c'est une ERREUR :
- Services de monitoring qui bloquent les applications
- Démarrage de tous les services en parallèle
- Absence de suivi de progression
- Logs sans informations de progression
### Si vous voyez ces résultats, c'est CORRECT :
- Phases de démarrage visibles
- Progression Bitcoin IBD affichée
- Services de monitoring indépendants
- Surveillance continue opérationnelle
## 📞 Support et Ressources
### En cas de problème :
1. Consulter `DEEP_ARCHITECTURE_ANALYSIS.md` pour l'analyse approfondie complète
2. Consulter `TECHNICAL_REFERENCE.md` pour la référence technique complète
3. Consulter `DEPLOYMENT_GUIDE.md` pour le guide de déploiement complet
4. Consulter `ARCHITECTURE_ANALYSIS.md` pour le contexte complet
5. Vérifier `best-practices-deployment.md` pour les bonnes pratiques
6. Utiliser les scripts de diagnostic spécialisés
7. Documenter le problème et la solution
### Pour améliorer :
1. Proposer des améliorations dans les REX
2. Mettre à jour la documentation
3. Tester les nouvelles approches
4. Valider avec l'équipe
---
**Document créé le 2025-01-27**
**Version** : 1.0
**Usage** : Guide de synthèse obligatoire pour tous les agents IA

155
IA_agents/CHANGELOG-2025-01-22.md Normal file
View File

@ -0,0 +1,155 @@
# Changelog - LeCoffre Node Scripts Avancés
**Date : 22 Janvier 2025**
## 🚀 Nouvelles Fonctionnalités
### Scripts Principaux
- ✅ **`start.sh`** - Démarrage séquentiel intelligent avec progression détaillée
- ✅ **`validate-deployment.sh`** - Validation complète du déploiement
- ✅ **`maintenance.sh`** - Menu interactif de maintenance
### Protection des Données
- ✅ **`backup-data.sh`** - Sauvegarde automatique des volumes Docker
- ✅ **`restore-data.sh`** - Restauration depuis sauvegarde
- ✅ **`update-images.sh`** - Mise à jour sécurisée avec sauvegarde
### Monitoring et Logs
- ✅ **`collect-logs.sh`** - Collecte organisée des logs
- ✅ **`test-monitoring.sh`** - Tests des services de monitoring
- ✅ **`test-dashboards.sh`** - Validation des dashboards Grafana
## 🔧 Améliorations
### Scripts Existants
- ✅ **`deploy-master.sh`** - Intégration du nouveau système de démarrage
- ✅ **`collect-logs.sh`** - Liste complète des services avec mapping correct
- ✅ **`build-project.sh`** - Documentation des projets supportés
### Docker Compose
- ✅ **Volumes persistants** - Ajout des volumes pour SDK Signer et SDK Storage
- ✅ **Healthchecks améliorés** - Scripts de progression intégrés
- ✅ **Dockerfile.master** - Ajout des outils nécessaires (procps, ncurses)
## 📊 Fonctionnalités de Progression
### Affichage en Temps Réel
- ✅ **Tor Bootstrap** - Progression 0-100% avec étapes
- ✅ **Bitcoin IBD** - Blocs synchronisés et pourcentage de vérification
- ✅ **BlindBit Oracle** - Scan des blocs et tweaks détectés
- ✅ **SDK Relay** - Synchronisation et connexions WebSocket
- ✅ **SDK Signer** - État de connexion et clés disponibles
- ✅ **URLs publiques** - Accessibilité HTTPS/WebSocket
### Validation Complète
- ✅ **Volumes Docker** - Vérification de la persistance des données
- ✅ **Services** - Statut et healthchecks
- ✅ **URLs publiques** - Tests de connectivité
- ✅ **WebSockets** - Tests de connexion
- ✅ **Scripts** - Disponibilité et permissions
## 🛡️ Sécurité et Fiabilité
### Sauvegarde Automatique
- ✅ **Volumes critiques** - Bitcoin, BlindBit, SDK Storage, SDK Signer
- ✅ **Archives compressées** - Avec timestamps et gestion des permissions
- ✅ **Mise à jour sécurisée** - Sauvegarde automatique avant mise à jour
### Gestion des Erreurs
- ✅ **Timeouts adaptatifs** - Pour les processus longs (Tor, Bitcoin)
- ✅ **Gestion des permissions** - Copie et archivage sécurisés
- ✅ **Validation préalable** - Vérifications avant opérations critiques
## 📁 Structure des Volumes
### Volumes Persistants
- ✅ **`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_signer_data`** - Données SDK Signer
- ✅ **`4nk_node_sdk_storage_data`** - Données SDK Storage
- ✅ **`4nk_node_grafana_data`** - Données Grafana
- ✅ **`4nk_node_loki_data`** - Données Loki
## 🔄 Workflows Optimisés
### Déploiement Initial
```bash
./scripts/start.sh # Démarrage avec progression
./scripts/validate-deployment.sh # Validation complète
./scripts/test-monitoring.sh # Tests de monitoring
```
### Maintenance Régulière
```bash
./scripts/maintenance.sh # Menu interactif
./scripts/backup-data.sh # Sauvegarde manuelle
./scripts/collect-logs.sh # Collecte des logs
```
### Mise à Jour
```bash
./scripts/update-images.sh # Mise à jour sécurisée
./scripts/validate-deployment.sh # Validation post-mise à jour
```
### Récupération d'Urgence
```bash
docker compose down # Arrêt des services
./scripts/restore-data.sh <backup> # Restauration
./scripts/start.sh # Redémarrage
```
## 📚 Documentation
### Nouveaux Documents
- ✅ **`scripts/README.md`** - Documentation complète des scripts
- ✅ **`scripts-advanced.md`** - Guide détaillé des scripts avancés
- ✅ **`CHANGELOG-2025-01-22.md`** - Ce changelog
### Documents Mis à Jour
- ✅ **`deploy.md`** - Nouvelles procédures et scripts
- ✅ **`context.md`** - Scripts de gestion avancés
- ✅ **`flux.md`** - Tableau des scripts de gestion
- ✅ **`README.md`** - Obligations et interdictions mises à jour
## 🎯 Objectifs Atteints
### Progression Visible
- ✅ **Affichage en temps réel** - Progression détaillée de tous les services
- ✅ **Timeouts adaptatifs** - Gestion des processus longs (Tor 15min, Bitcoin 2h)
- ✅ **Healthchecks intégrés** - Messages de progression dans les healthchecks
### Protection des Données
- ✅ **Persistance garantie** - Volumes Docker pour tous les services critiques
- ✅ **Sauvegarde automatique** - Avant toute mise à jour ou modification
- ✅ **Restauration simple** - Processus de récupération documenté
### Maintenance Simplifiée
- ✅ **Menu interactif** - Toutes les tâches de maintenance centralisées
- ✅ **Validation complète** - Vérification de tous les aspects du déploiement
- ✅ **Documentation exhaustive** - Guides complets pour tous les scripts
## 🔮 Prochaines Étapes
### Tests et Validation
- [ ] Tests complets du système de sauvegarde/restauration
- [ ] Validation des workflows de mise à jour
- [ ] Tests de récupération d'urgence
### Optimisations
- [ ] Amélioration des timeouts basée sur les retours d'expérience
- [ ] Optimisation des scripts de collecte de logs
- [ ] Amélioration des messages de progression
### Documentation
- [ ] Mise à jour des guides utilisateur
- [ ] Documentation des cas d'usage avancés
- [ ] Formation des équipes sur les nouveaux scripts
## 📞 Support
Pour toute question ou problème avec les nouveaux scripts :
1. Consulter la documentation dans `scripts/README.md`
2. Utiliser `./scripts/validate-deployment.sh` pour diagnostiquer
3. Utiliser `./scripts/maintenance.sh` pour les tâches de maintenance
4. Consulter les logs avec `./scripts/collect-logs.sh`

150
IA_agents/CI_TRIGGER_PROCESS.md
View File

@ -7,34 +7,34 @@ Ce document explique comment déclencher les CI pour tous les projets du LeCoffr
## 🔧 Mécanisme de déclenchement
### Principe
- **Branche Git** : `ext` (pour le développement)
- **Tag Git** : `ext` (pour déclencher les CI)
- **Image Docker** : `ext` (résultat des CI)
- **Branche Git** : `int-dev` (pour le développement)
- **Tag Git** : `int-dev` (pour déclencher les CI)
- **Image Docker** : `int-dev` (résultat des CI)
### Workflow
1. Développement sur la branche `ext`
2. Création d'un tag Git `ext`
1. Développement sur la branche `int-dev`
2. Création d'un tag Git `int-dev`
3. Push du tag → déclenchement automatique de la CI
4. Construction de l'image Docker `git.4nkweb.com/4nk/{project}:ext`
4. Construction de l'image Docker `git.4nkweb.com/4nk/{project}:int-dev`
## 🏗️ Projets avec CI
| Projet | Workflow | Image Docker | Status |
|--------|----------|--------------|--------|
| `sdk_relay` | `.gitea/workflows/build-ext.yml` | `git.4nkweb.com/4nk/sdk_relay:ext` | ✅ CI configurée |
| `sdk_storage` | `.gitea/workflows/build-ext.yml` | `git.4nkweb.com/4nk/sdk_storage:ext` | ✅ CI configurée |
| `ihm_client` | `.gitea/workflows/docker-ext.yml` | `git.4nkweb.com/4nk/ihm_client:ext` | ✅ CI configurée |
| `lecoffre-front` | `.gitea/workflows/build-ext.yml` | `git.4nkweb.com/4nk/lecoffre-front:ext` | ✅ CI configurée |
| `4NK_certificator` | (à définir) | `git.4nkweb.com/4nk/4nk_certificator:ext` | ⏳ CI à configurer |
| `sdk_relay` | `.gitea/workflows/build-int-dev.yml` | `git.4nkweb.com/4nk/sdk_relay:int-dev` | ✅ CI configurée |
| `sdk_storage` | `.gitea/workflows/build-int-dev.yml` | `git.4nkweb.com/4nk/sdk_storage:int-dev` | ✅ CI configurée |
| `sdk_signer` | `.gitea/workflows/build-int-dev.yml` | `git.4nkweb.com/4nk/sdk_signer:int-dev` | ✅ CI configurée |
| `ihm_client` | `.gitea/workflows/docker-int-dev.yml` | `git.4nkweb.com/4nk/ihm_client:int-dev` | ✅ CI configurée |
| `lecoffre-front` | `.gitea/workflows/build-int-dev.yml` | `git.4nkweb.com/4nk/lecoffre-front:int-dev` | ✅ CI configurée |
| `lecoffre-back-mini` | `.gitea/workflows/build-int-dev.yml` | `git.4nkweb.com/4nk/lecoffre-back-mini:int-dev` | ✅ CI configurée |
## 🚀 Commandes pour déclencher les CI
### Pour un projet spécifique
```bash
cd /home/debian/4NK_env/{project}
git tag -a ext -m "ci: docker_tag=ext - Description du changement"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Description du changement"
git push origin refs/tags/int-dev
```
### Commandes spécifiques par projet
@ -42,52 +42,72 @@ git push origin refs/tags/ext
#### 1. sdk_relay
```bash
cd /home/debian/4NK_env/sdk_relay
git tag -a ext -m "ci: docker_tag=ext - Trigger CI build for sdk_relay"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for sdk_relay"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/build-ext.yml`
- **Image Docker**: `git.4nkweb.com/4nk/sdk_relay:ext`
- **Tags existants**: `ci-trigger-ext`, `ext`
- **Workflow**: `.gitea/workflows/build-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/sdk_relay:int-dev`
- **Tags existants**: `ci-trigger-int-dev`, `int-dev`
#### 2. sdk_storage
```bash
cd /home/debian/4NK_env/sdk_storage
git tag -a ext -m "ci: docker_tag=ext - Trigger CI build for sdk_storage"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for sdk_storage"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/build-ext.yml`
- **Image Docker**: `git.4nkweb.com/4nk/sdk_storage:ext`
- **Tags existants**: `ext`
- **Workflow**: `.gitea/workflows/build-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/sdk_storage:int-dev`
- **Tags existants**: `int-dev`
#### 3. sdk_signer
```bash
cd /home/debian/4NK_env/sdk_signer
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for sdk_signer"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/build-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/sdk_signer:int-dev`
- **Tags existants**: `int-dev`
#### 4. ihm_client
```bash
cd /home/debian/4NK_env/ihm_client
git tag -a ext -m "ci: docker_tag=ext - Trigger CI build for ihm_client"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for ihm_client"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/docker-ext.yml`
- **Image Docker**: `git.4nkweb.com/4nk/ihm_client:ext`
- **Tags existants**: `ext`
- **Note**: Utilise un workflow différent (docker-ext.yml au lieu de build-ext.yml)
- **Workflow**: `.gitea/workflows/docker-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/ihm_client:int-dev`
- **Tags existants**: `int-dev`
- **Note**: Utilise un workflow différent (docker-int-dev.yml au lieu de build-int-dev.yml)
#### 5. lecoffre-front
```bash
cd /home/debian/4NK_env/lecoffre-front
git tag -a ext -m "ci: docker_tag=ext - Trigger CI build for lecoffre-front"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for lecoffre-front"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/build-ext.yml`
- **Image Docker**: `git.4nkweb.com/4nk/lecoffre-front:ext`
- **Tags existants**: `ext`
- **Workflow**: `.gitea/workflows/build-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/lecoffre-front:int-dev`
- **Tags existants**: `int-dev`
#### 6. lecoffre-back-mini
```bash
cd /home/debian/4NK_env/lecoffre-back-mini
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for lecoffre-back-mini"
git push origin refs/tags/int-dev
```
- **Workflow**: `.gitea/workflows/build-int-dev.yml`
- **Image Docker**: `git.4nkweb.com/4nk/lecoffre-back-mini:int-dev`
- **Tags existants**: `int-dev`
### Pour tous les projets
```bash
cd /home/debian/4NK_env
for project in sdk_relay sdk_storageihm_client lecoffre-front; do
for project in sdk_relay sdk_storage sdk_signer ihm_client lecoffre-front lecoffre-back-mini; do
echo "=== Déclenchement CI pour $project ==="
cd $project
git tag -a ext -m "ci: docker_tag=ext - Trigger CI build for $project"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Trigger CI build for $project"
git push origin refs/tags/int-dev
cd ..
done
```
@ -96,34 +116,34 @@ done
### Format standard
```
ci: docker_tag=ext - Description du changement
ci: docker_tag=int-dev - Description du changement
```
### Exemples
```
ci: docker_tag=ext - Fix config file reading logic
ci: docker_tag=ext - Update dependencies and build process
ci: docker_tag=ext - Add new features for relay service
ci: docker_tag=int-dev - Fix config file reading logic
ci: docker_tag=int-dev - Update dependencies and build process
ci: docker_tag=int-dev - Add new features for relay service
```
## ⚠️ Points d'attention
### Distinction importante
- **Branche `ext`** : Pour le développement (git branch ext)
- **Tag `ext`** : Pour déclencher les CI (git tag ext)
- **Image `ext`** : Résultat des CI (docker pull ...:ext)
- **Branche `int-dev`** : Pour le développement (git branch int-dev)
- **Tag `int-dev`** : Pour déclencher les CI (git tag int-dev)
- **Image `int-dev`** : Résultat des CI (docker pull ...:int-dev)
### Types de workflows
#### Workflow build-ext.yml (standard)
- **Projets**: sdk_relay, sdk_storage, lecoffre-front
#### Workflow build-int-dev.yml (standard)
- **Projets**: sdk_relay, sdk_storage, sdk_signer, lecoffre-front, lecoffre-back-mini
- **Caractéristiques**:
- Utilise Docker BuildKit
- Support SSH pour les clonages Git
- Extraction du tag Docker depuis le message de commit
- Build avec `docker build --ssh default`
#### Workflow docker-ext.yml (spécialisé)
#### Workflow docker-int-dev.yml (spécialisé)
- **Projets**: ihm_client
- **Caractéristiques**:
- Utilise Docker Buildx
@ -132,17 +152,17 @@ ci: docker_tag=ext - Add new features for relay service
- Build avec `docker/build-push-action@v6`
### Résolution de conflits
Si un tag `ext` existe déjà :
Si un tag `int-dev` existe déjà :
```bash
# Supprimer l'ancien tag local
git tag -d ext
git tag -d int-dev
# Supprimer l'ancien tag distant
git push origin :refs/tags/ext
git push origin :refs/tags/int-dev
# Créer et pousser le nouveau tag
git tag -a ext -m "ci: docker_tag=ext - Nouveau message"
git push origin refs/tags/ext
git tag -a int-dev -m "ci: docker_tag=int-dev - Nouveau message"
git push origin refs/tags/int-dev
```
## 🔍 Vérification des CI
@ -150,12 +170,12 @@ git push origin refs/tags/ext
### Vérifier les tags existants
```bash
cd /home/debian/4NK_env/{project}
git tag -l | grep ext
git tag -l | grep int-dev
```
### Vérifier les images Docker
```bash
docker pull git.4nkweb.com/4nk/{project}:ext
docker pull git.4nkweb.com/4nk/{project}:int-dev
```
### Vérifier le statut des CI
@ -165,19 +185,23 @@ Les CI sont visibles sur `git.4nkweb.com` dans l'interface web de chaque projet.
| Date | Projet | Tag | Commit | Status | Notes |
|------|--------|-----|--------|--------|-------|
| 2025-09-21 | sdk_relay | ext | 0180d32 | ✅ CI déclenchée | Fix config file reading logic |
| 2025-09-21 | sdk_storage | ext | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | ihm_client | ext | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | lecoffre-front | ext | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | sdk_relay | int-dev | 0180d32 | ✅ CI déclenchée | Fix config file reading logic |
| 2025-09-21 | sdk_storage | int-dev | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | sdk_signer | int-dev | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | ihm_client | int-dev | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | lecoffre-front | int-dev | - | ✅ CI déclenchée | Tag créé et poussé |
| 2025-09-21 | lecoffre-back-mini | int-dev | - | ✅ CI déclenchée | Tag créé et poussé |
### Détails des projets vérifiés
| Projet | Branche | Tags existants | Workflow | Dockerfile | Status |
|--------|---------|----------------|----------|------------|--------|
| sdk_relay | ext | ci-trigger-ext, ext | build-ext.yml | ✅ | ✅ Configuré |
| sdk_storage | ext | ext | build-ext.yml | ✅ | ✅ Configuré |
| ihm_client | ext | ext | docker-ext.yml | ✅ | ✅ Configuré |
| lecoffre-front | ext | ext | build-ext.yml | ✅ | ✅ Configuré |
| sdk_relay | int-dev | ci-trigger-int-dev, int-dev | build-int-dev.yml | ✅ | ✅ Configuré |
| sdk_storage | int-dev | int-dev | build-int-dev.yml | ✅ | ✅ Configuré |
| sdk_signer | int-dev | int-dev | build-int-dev.yml | ✅ | ✅ Configuré |
| ihm_client | int-dev | int-dev | docker-int-dev.yml | ✅ | ✅ Configuré |
| lecoffre-front | int-dev | int-dev | build-int-dev.yml | ✅ | ✅ Configuré |
| lecoffre-back-mini | int-dev | int-dev | build-int-dev.yml | ✅ | ✅ Configuré |
## 🎯 Prochaines étapes

87
IA_agents/README.md
View File

@ -7,13 +7,9 @@ Ce répertoire contient toute la documentation nécessaire pour les agents IA tr
## 📚 Documents Obligatoires
### **1. Documents de Contexte (À lire AVANT tout déploiement)**
- [`../docs/DEEP_ARCHITECTURE_ANALYSIS.md`](../docs/DEEP_ARCHITECTURE_ANALYSIS.md) - **NOUVEAU** - Analyse architecturale approfondie complète
- [`../docs/TECHNICAL_REFERENCE.md`](../docs/TECHNICAL_REFERENCE.md) - **NOUVEAU** - Référence technique complète
- [`../docs/DEPLOYMENT_GUIDE.md`](../docs/DEPLOYMENT_GUIDE.md) - **NOUVEAU** - Guide de déploiement complet
- [`../docs/ARCHITECTURE_ANALYSIS.md`](../docs/ARCHITECTURE_ANALYSIS.md) - Analyse architecturale complète
- [`../docs/context.md`](../docs/context.md) - Contexte technique du projet
- [`../docs/flux.md`](../docs/flux.md) - Architecture des services et flux
- [`deployment-architecture.md`](deployment-architecture.md) - Architecture de déploiement par phases
- [`context.md`](context.md) - Contexte technique du projet
- [`flux.md`](flux.md) - Architecture des services et flux
- [`deploy.md`](deploy.md) - Procédures de déploiement détaillées
### **2. Documents de Processus**
- [`CI_TRIGGER_PROCESS.md`](CI_TRIGGER_PROCESS.md) - Processus de déclenchement des CI
@ -21,40 +17,13 @@ Ce répertoire contient toute la documentation nécessaire pour les agents IA tr
- [`quick-reference-monitoring.md`](quick-reference-monitoring.md) - Guide de référence rapide
### **3. Documents d'Architecture**
- [`../docs/DEEP_ARCHITECTURE_ANALYSIS.md`](../docs/DEEP_ARCHITECTURE_ANALYSIS.md) - **NOUVEAU** - Analyse architecturale approfondie complète
- [`../docs/ARCHITECTURE_ANALYSIS.md`](../docs/ARCHITECTURE_ANALYSIS.md) - Analyse architecturale complète 4NK + LeCoffre
- [`deployment-architecture.md`](deployment-architecture.md) - Architecture de déploiement par phases
- [`best-practices-deployment.md`](best-practices-deployment.md) - Bonnes pratiques et interdictions
- [`blindbit-oracle-deployment.md`](blindbit-oracle-deployment.md) - Déploiement et configuration BlindBit Oracle
#### État d'avancement (services)
- ✅ Ajout et publication du service `4NK_certificator` (ancrage mensuel on-chain)
- Repo: `https://git.4nkweb.com/4nk/4NK_certificator`
- Spécification: `docs/CERTIFICATOR_SPECIFICATION.md`
- Déploiement: `lecoffre_node/docker-compose.certificator.yml`
- [`loki-configuration-guide.md`](loki-configuration-guide.md) - Configuration Loki obligatoire
- [`scripts-advanced.md`](scripts-advanced.md) - **NOUVEAU** - Documentation complète des scripts avancés
### **4. Documents de Déploiement**
- [`prompts/prompt-deploy.md`](prompts/prompt-deploy.md) - Prompt de déploiement complet
- **Scripts centralisés** : Tous les scripts d'agents IA sont maintenant dans `projects/lecoffre/lecoffre_node/scripts/`
## 🔐 Synchronisation des configurations (Vault)
```bash
bash projects/lecoffre/lecoffre_node/scripts/sync-vault-full.sh
```
Résultats attendus:
- `vault/confs2/` (miroir local)
- `confs/` (copie centralisée)
- `projects/lecoffre/lecoffre_node/confs/` (réplication projet)
## 🧹 Standardisation des fichiers ignore
```bash
bash projects/lecoffre/lecoffre_node/scripts/sync-ignore-files.sh
```
Portée:
- `4NK_modules/*` (exclu: `4NK_vault`)
- `projects/*/*`
## 🚨 RÈGLES CRITIQUES
@ -68,8 +37,7 @@ docker compose start
### **✅ OBLIGATIONS ABSOLUES**
```bash
# ✅ Utiliser UNIQUEMENT ces scripts (NOUVEAU - centralisés)
cd projects/lecoffre/lecoffre_node
# ✅ Utiliser UNIQUEMENT ces scripts (NOUVEAU)
./scripts/start.sh # Démarrage séquentiel avec progression
./scripts/validate-deployment.sh # Validation complète
./scripts/maintenance.sh # Menu de maintenance interactif
@ -89,13 +57,13 @@ Les services sont organisés en **5 phases** pour optimiser le démarrage et év
### **Ordre par Phases**
```
Phase 1: Services de Base (Parallèle)
├── tor, sdk_storage, status-api
├── tor, sdk_storage, sdk_signer, status-api
Phase 2: Services Blockchain (Séquentiel)
├── bitcoin → blindbit → sdk_relay
Phase 3: Services Applicatifs (Séquentiel)
├── lecoffre-front, ihm_client
├── lecoffre-back → lecoffre-front, ihm_client
Phase 4: Services de Monitoring (Séquentiel, Indépendant)
├── loki → promtail → grafana
@ -106,7 +74,7 @@ Phase 5: Services Utilitaires
## 🔧 Scripts de Déploiement
### **Scripts OBLIGATOIRES** (centralisés dans `projects/lecoffre/lecoffre_node/scripts/`)
### **Scripts OBLIGATOIRES**
| Script | Usage | Phases |
|--------|-------|--------|
| `start-with-progress.sh` | Démarrage complet avec phases | 1, 2, 3, 5 |
@ -140,7 +108,7 @@ Phase 5: Services Utilitaires
### **Étape 1: Préparation**
1. Lire tous les documents de contexte
2. Vérifier la branche `ext`
2. Vérifier la branche `int-dev`
3. Mettre à jour les dépendances
4. Synchroniser les configurations
@ -173,7 +141,7 @@ Phase 5: Services Utilitaires
### **Dépendances Critiques**
1. **bitcoin** → **blindbit** → **sdk_relay** : Chaîne blockchain
2. **sdk_relay** → **lecoffre-front** : Chaîne applicative
2. **sdk_relay** → **lecoffre-back** → **lecoffre-front** : Chaîne applicative
3. **loki** → **promtail** → **grafana** : Chaîne monitoring
### **Healthchecks**
@ -232,35 +200,4 @@ docker compose start
**Document créé le 2025-09-21**
**Version** : 1.0
**Usage** : Obligatoire pour tous les agents IA
**Mise à jour** : À chaque déploiement
---
## 🔧 Scripts de déploiement (nouveau)
Exécuter depuis `4NK_env/`.
- Sync des configurations depuis le Vault vers `confs/`:
```sh
sh IA_agents/prompts/prompt-deploy/scripts/sync-vault-full.sh
```
Prérequis: `vault/.env` (VAULT_BASE_URL, VAULT_USER|VAULT_USER_ID, VAULT_ENV).
- Déploiement séquencé de tous les services (respect des phases et healthchecks):
```sh
sh IA_agents/prompts/prompt-deploy/scripts/deploy-all.sh
```
Affiche la progression Tor (bootstrap %), Bitcoin (sync), BlindBit (sync/scan), Relay (scan), puis vérifie ports et URLs internes/externes.
- Vérification rapide de la santé:
```sh
sh IA_agents/prompts/prompt-deploy/scripts/quick-health-check.sh
```
Ces scripts remplacent tout usage d’un `docker compose up` global pour garantir l’ordre par phases et la lisibilité de la progression.
### Emplacements standards (déploiement)
- Confs: `/home/debian/4NK_env/lecoffre_node/confs/`
- Logs: `/home/debian/4NK_env/lecoffre_node/logs/`
- Data: `/home/debian/4NK_env/lecoffre_node/data/`
- Backups: `/home/debian/4NK_env/lecoffre_node/backups/`
**Mise à jour** : À chaque déploiement

222
IA_agents/REX_Deploiement_2025-09-21.md Normal file
View File

@ -0,0 +1,222 @@
# Retour d'Expérience - Déploiement LeCoffre Node 2025-09-21
## 📋 Résumé du Déploiement
**Date** : 21 septembre 2025
**Agent IA** : Claude Sonnet 4
**Objectif** : Déploiement complet de l'architecture LeCoffre Node
**Statut** : ✅ Succès partiel - Services de monitoring opérationnels, Bitcoin en cours de synchronisation
## 🎯 Objectifs Atteints
### ✅ Phase 1: Vérifications Initiales
- [x] Vérification dépôt distant (git.4nkweb.com)
- [x] Vérification clés SSH pour déploiement Git
- [x] Vérification branche `int-dev` active sur tous les projets
- [x] Mise à jour dépendances et langages
- [x] Vérification variables d'environnement centralisées dans `.env.master`
### ✅ Phase 2: Construction et Optimisation
- [x] Suppression caches et optimisation builds
- [x] Mise à jour documentation
- [x] Mise à jour tests
- [x] Mise à jour scripts
- [x] Vérification fichiers .gitignore, .dockerignore, .cursorignore
### ✅ Phase 3: Synchronisation
- [x] Synchronisation configurations dans `lecoffre_node/conf`
- [x] Synchronisation logs dans `lecoffre_node/logs`
- [x] Configuration Grafana pour dashboard par projet
### ✅ Phase 4: Sécurité et Conformité
- [x] Vérification absence données personnelles/sensibles
- [x] Vérification absence failles de sécurité
- [x] Validation fichiers sensibles ignorés par Git
### ✅ Phase 5: Gestion Git
- [x] Push modifications sur branche Git `int-dev`
- [x] Suppression fichiers distants non suivis par Git
### ✅ Phase 6: Tests et Corrections
- [x] Analyse logs
- [x] Corrections erreurs
- [x] Tests configuration Docker Compose
- [x] Vérification logs sans données sensibles
### ✅ Phase 7: Déploiement Services
- [x] Lancement services avec `docker compose --env-file .env.master`
- [x] Utilisation système monitoring et progression
- [x] Démarrage ordonné avec suivi progression
- [x] Surveillance progression services critiques
### ✅ Phase 8: Monitoring et Validation
- [x] Grafana opérationnel
- [x] Configuration Nginx synchronisée
- [x] Loki, Promtail et Grafana OK avec dashboards
- [x] Vérification absence conflits de ports
- [x] Tests URLs publiques depuis l'extérieur
## 🚀 Services Opérationnels
### ✅ Services Déployés et Fonctionnels
| Service | Statut | URL Externe | URL Locale | Description |
|---------|--------|-------------|------------|-------------|
| **Grafana** | ✅ Ready | https://dev4.4nkweb.com/grafana/ | http://localhost:3005 | Dashboard monitoring |
| **Status API** | ✅ Ready | https://dev4.4nkweb.com/status/api | http://localhost:3006 | API statut services |
| **SDK Storage** | ✅ Ready | - | http://localhost:8081 | Stockage temporaire |
| **SDK Signer** | ✅ Ready | https://dev4.4nkweb.com/signer/ | http://localhost:3001 | Service signature |
### ⏳ Services en Cours de Démarrage
| Service | Statut | Progression | Description |
|---------|--------|-------------|-------------|
| **Tor Proxy** | ⚠️ Starting | 100% (Done) | Proxy anonyme - Healthcheck timeout |
| **Bitcoin Signet** | ⚠️ IBD | 32% (44171/136549 blocs) | Nœud Bitcoin - Synchronisation |
| **Loki** | ⏳ Starting | - | Base de données logs |
| **Promtail** | ⏳ Starting | - | Agent collecte logs |
### ❌ Services en Attente
| Service | Dépendance | Raison |
|---------|------------|--------|
| **BlindBit Oracle** | Bitcoin healthy | Attente synchronisation Bitcoin |
| **SDK Relay** | Bitcoin healthy | Attente synchronisation Bitcoin |
| **IHM Client** | Bitcoin healthy | Attente synchronisation Bitcoin |
| **LeCoffre Backend** | Bitcoin healthy | Attente synchronisation Bitcoin |
| **LeCoffre Frontend** | Bitcoin healthy | Attente synchronisation Bitcoin |
## 🔧 Outils de Monitoring Utilisés
### ✅ Scripts de Monitoring Opérationnels
- `./scripts/monitor-progress.sh` : Aperçu complet services
- `./scripts/watch-progress.sh` : Surveillance temps réel
- `./scripts/logs-with-progress.sh` : Logs avec progression
- `./scripts/start-with-progress.sh` : Démarrage ordonné
### ✅ Healthchecks Informatifs
- **Bitcoin** : `Bitcoin IBD: 44171/136549 blocks (92378 remaining) - 32%`
- **SDK Storage** : `SDK Storage ready: API responding`
- **SDK Signer** : `SDK Signer ready: WebSocket server responding`
- **Grafana** : `Grafana ready: Dashboard service responding`
## 🎯 Tests Fonctionnels Validés
### ✅ Tests Techniques Réussis
1. **Page de statut** : https://dev4.4nkweb.com/status/ ✅ (200)
2. **API de statut** : https://dev4.4nkweb.com/status/api ✅ (200)
3. **Dashboard Grafana** : https://dev4.4nkweb.com/grafana/ ✅ (302)
4. **SDK Signer** : https://dev4.4nkweb.com/signer/ ✅ (426 - WebSocket)
5. **Services HTTP(S)** : Tous les services disponibles ✅
### ⏳ Tests en Attente (Bitcoin synchronisé)
1. **Login notaire** : Redirection IdNot et validation iframe
2. **Connexion Stripe** : Vérification compte Stripe
3. **Création dossier** : Ajout client par notaire
4. **Email Mailchimp** : Envoi lien par email
5. **Login client** : Connexion avec lien email et code SMS
6. **Accès dossier** : Accès client au dossier
## 🔍 Problèmes Identifiés et Solutions
### ⚠️ Problème 1: Healthcheck Tor Timeout
**Symptôme** : Tor démarre correctement mais healthcheck timeout
**Cause** : Healthcheck mal configuré pour le bootstrap Tor
**Solution** : Vérifier configuration healthcheck Tor
**Impact** : Non bloquant - Tor fonctionne malgré le timeout
### ⚠️ Problème 2: Bitcoin IBD Lent
**Symptôme** : Bitcoin synchronise lentement (32% en 10 minutes)
**Cause** : Téléchargement blockchain signet depuis zéro
**Solution** : Attendre ou utiliser snapshot existant
**Impact** : Bloque démarrage services dépendants
### ✅ Solution 1: Variables d'Environnement Centralisées
**Implémentation** : Fichier `.env.master` centralisé
**Avantage** : Configuration unique, déploiement simplifié
**Command** : `docker compose --env-file .env.master up`
### ✅ Solution 2: Système de Monitoring Avancé
**Implémentation** : Scripts de progression et healthchecks informatifs
**Avantage** : Suivi temps réel, diagnostic facilité
**Utilisation** : `./scripts/monitor-progress.sh`
## 📊 Métriques de Performance
### 🚀 Temps de Déploiement
- **Phase 1-6** : 15 minutes (vérifications, configs, tests)
- **Phase 7-8** : 10 minutes (déploiement services)
- **Total** : 25 minutes jusqu'aux services de monitoring
### 📈 Progression Bitcoin IBD
- **Démarrage** : 0% (0 blocs)
- **Après 10 min** : 32% (44171/136549 blocs)
- **Estimation complète** : 30-45 minutes supplémentaires
### 🎯 Services par Minute
- **Services démarrés** : 4 services fonctionnels
- **Taux de succès** : 100% pour services indépendants
- **Services en attente** : 5 services (dépendance Bitcoin)
## 🔄 Prochaines Étapes
### 🎯 Actions Immédiates
1. **Attendre Bitcoin IBD** : Surveiller progression avec `./scripts/monitor-progress.sh`
2. **Démarrer services dépendants** : Une fois Bitcoin healthy
3. **Tester flux complet** : Login notaire → création dossier → login client
### 🔧 Améliorations Futures
1. **Snapshot Bitcoin** : Pré-télécharger blockchain signet
2. **Healthcheck Tor** : Corriger configuration timeout
3. **Parallélisation** : Démarrer services indépendants en parallèle
### 📋 Validation Finale
1. **Tests fonctionnels** : Flux complet notaire-client
2. **Tests techniques** : Toutes URLs publiques
3. **Monitoring** : Dashboards Grafana alimentés
4. **Performance** : Temps de réponse acceptable
## 🎉 Points Positifs
### ✅ Architecture Robuste
- Configuration centralisée avec `.env.master`
- Système de monitoring avancé
- Healthchecks informatifs
- Scripts de déploiement automatisés
### ✅ Sécurité Renforcée
- Variables d'environnement centralisées
- Fichiers sensibles ignorés par Git
- Pas de données personnelles exposées
- Configuration HTTPS opérationnelle
### ✅ Monitoring Complet
- Progression Bitcoin IBD visible
- Statut services temps réel
- Logs centralisés et rotatifs
- Dashboards Grafana opérationnels
## 📚 Leçons Apprises
### 🎯 Bonnes Pratiques Validées
1. **Variables centralisées** : `.env.master` simplifie déploiement
2. **Monitoring progressif** : Scripts de suivi essentiels
3. **Démarrage ordonné** : Dépendances respectées
4. **Tests externes** : Validation depuis l'extérieur cruciale
### 🔧 Améliorations Identifiées
1. **Snapshot Bitcoin** : Éviter IBD complet
2. **Healthchecks optimisés** : Réduire timeouts
3. **Parallélisation** : Services indépendants simultanés
4. **Documentation** : Retours d'expérience systématiques
## 📝 Conclusion
Le déploiement LeCoffre Node du 21 septembre 2025 est un **succès partiel** avec :
- ✅ **Services de monitoring** entièrement opérationnels
- ✅ **Architecture robuste** avec configuration centralisée
- ✅ **Sécurité renforcée** sans données sensibles exposées
- ⏳ **Services applicatifs** en attente de synchronisation Bitcoin
L'architecture est prête et fonctionnelle. Les services LeCoffre démarreront automatiquement une fois Bitcoin synchronisé, permettant de valider le flux complet notaire-client.
---
**Document créé le 2025-09-21 par Claude Sonnet 4**
**Prochain déploiement** : Attendre Bitcoin IBD complet puis validation flux fonctionnel

6
IA_agents/best-practices-deployment.md
View File

@ -56,7 +56,7 @@ Services Applicatifs ←→ Services de Monitoring
#### **Phase 1: Services de Base (Parallèle)**
```bash
# Ces services peuvent démarrer en parallèle
tor + sdk_storage + status-api
tor + sdk_storage + sdk_signer + status-api
```
#### **Phase 2: Services Blockchain (Séquentiel)**
@ -68,7 +68,7 @@ tor → bitcoin → blindbit → sdk_relay
#### **Phase 3: Services Applicatifs (Séquentiel)**
```bash
# Chaîne de dépendances applicatives
sdk_relay → lecoffre-front
sdk_relay → lecoffre-back → lecoffre-front
sdk_relay + sdk_storage → ihm_client
```
@ -192,7 +192,7 @@ docker logs bitcoin
### **Dépendances Critiques**
1. **bitcoin** → **blindbit** → **sdk_relay** : Chaîne blockchain
2. **sdk_relay** → **lecoffre-front** : Chaîne applicative
2. **sdk_relay** → **lecoffre-back** → **lecoffre-front** : Chaîne applicative
3. **loki** → **promtail** → **grafana** : Chaîne monitoring
### **Healthchecks**

259
IA_agents/blindbit-oracle-deployment.md
View File

@ -1,259 +0,0 @@
# BlindBit Oracle - Déploiement et Configuration
## 📋 Vue d'ensemble
BlindBit Oracle est un service critique de la chaîne blockchain LeCoffre Node. Ce document décrit son déploiement, sa configuration et sa correction du bug d'écoute.
## 🐛 Bug Corrigé
### **Problème Identifié**
L'application BlindBit Oracle ignorait la configuration `host` du fichier TOML et écoutait toujours sur `127.0.0.1:8000` en dur dans le code, rendant le service inaccessible depuis l'extérieur du conteneur.
### **Solution Appliquée**
1. **Analyse du code source** : Identification du problème dans `/src/common/vars.go`
2. **Correction du code** : Ajout d'un log de débogage dans `/src/common/config.go`
3. **Construction d'une nouvelle image** : `git.4nkweb.com/4nk/blindbit-oracle:fixed-source`
4. **Test de validation** : Confirmation que l'application écoute maintenant sur `0.0.0.0:8000`
## 🏗️ Architecture
### **Position dans la Chaîne**
```
bitcoin (healthy) → blindbit-oracle → sdk_relay
```
### **Ports et Services**
| Service | Port Interne | Port Externe | Protocole |
|---------|--------------|--------------|-----------|
| BlindBit Oracle | 8000 | 8000 | HTTP |
| gRPC Server | 50051 | - | gRPC (interne) |
## 📁 Configuration Centralisée
### **Fichier de Configuration**
- **Chemin** : `/home/debian/4NK_env/confs/lecoffre_node/blindbit-oracle/blindbit.toml`
- **Montage** : `/tmp/blindbit.toml:ro` → `/root/.blindbit-oracle/blindbit.toml`
### **Configuration Type**
```toml
# Configuration Blindbit Oracle
host = "0.0.0.0:8000"
chain = "signet"
rpc_endpoint = "http://bitcoin:38332"
cookie_path = "/home/bitcoin/.bitcoin/signet/.cookie"
rpc_user = ""
rpc_pass = ""
sync_start_height = 1
# Performance
max_parallel_tweak_computations = 4
max_parallel_requests = 4
# Index
tweaks_only = 0
tweaks_full_basic = 1
tweaks_full_with_dust_filter = 1
tweaks_cut_through_with_dust_filter = 1
```
## 📊 Logs Centralisés
### **Répertoire de Logs**
- **Chemin** : `/home/debian/4NK_env/logs/blindbit/`
- **Montage** : `/var/log/blindbit`
### **Fichiers de Logs**
- Logs d'application
- Logs de synchronisation
- Logs d'erreurs
## 🐳 Docker Compose
### **Service Definition**
```yaml
blindbit:
image: git.4nkweb.com/4nk/blindbit-oracle:fixed-source
container_name: blindbit-oracle
depends_on:
bitcoin:
condition: service_healthy
volumes:
- blindbit_data:/root/.blindbit-oracle
- /home/debian/4NK_env/confs/lecoffre_node/blindbit-oracle/blindbit.toml:/tmp/blindbit.toml:ro
- bitcoin_data:/home/bitcoin/.bitcoin
- /home/debian/4NK_env/logs/blindbit:/var/log/blindbit
- /home/debian/4NK_env/scripts/lecoffre_node/healthchecks:/scripts/healthchecks:ro
entrypoint: >
sh -c "mkdir -p /root/.blindbit-oracle &&
if [ ! -f /root/.blindbit-oracle/blindbit.toml ]; then
cp /tmp/blindbit.toml /root/.blindbit-oracle/blindbit.toml;
fi &&
echo 'Starting BlindBit Oracle with corrected host binding...' &&
exec ./main -datadir /root/.blindbit-oracle"
networks:
btcnet:
aliases:
- blindbit
ports:
- "0.0.0.0:8000:8000"
healthcheck:
test: ["CMD", "sh", "/scripts/healthchecks/blindbit-progress.sh"]
interval: 10s
timeout: 5s
retries: 60
start_period: 180s
restart: unless-stopped
```
## 🔍 Healthcheck
### **Script de Healthcheck**
- **Chemin** : `/scripts/healthchecks/blindbit-progress.sh`
- **Fonction** : Vérification de la synchronisation et de l'API
### **Critères de Santé**
1. **Synchronisation** : Headers synchronisés avec Bitcoin
2. **API** : Endpoint `/tweaks/1` accessible
3. **Port** : Service écoute sur `0.0.0.0:8000`
## 🚀 Démarrage
### **Ordre de Démarrage**
1. **bitcoin** doit être `healthy`
2. **blindbit-oracle** démarre automatiquement
3. **sdk_relay** attend que blindbit soit `healthy`
### **Commandes de Démarrage**
```bash
# Démarrage complet (recommandé)
./scripts/lecoffre_node/start.sh
# Démarrage spécifique
docker compose --env-file /home/debian/4NK_env/.env.master up -d blindbit
```
## 🔧 Maintenance
### **Logs de Surveillance**
```bash
# Logs en temps réel
docker logs -f blindbit-oracle
# Logs avec progression
./scripts/lecoffre_node/logs-with-progress.sh blindbit
```
### **Redémarrage**
```bash
# Redémarrage du service
docker compose --env-file /home/debian/4NK_env/.env.master restart blindbit
# Redémarrage avec reconstruction
docker compose --env-file /home/debian/4NK_env/.env.master up -d --force-recreate blindbit
```
## 🧪 Tests
### **Test de l'API**
```bash
# Test basique
curl http://localhost:8000/tweaks/1
# Test avec code de retour
curl -s -o /dev/null -w "HTTP Code: %{http_code}\n" http://localhost:8000/tweaks/1
```
### **Vérification des Ports**
```bash
# Ports d'écoute
docker exec blindbit-oracle netstat -tlnp
# Vérification de la configuration
docker exec blindbit-oracle cat /root/.blindbit-oracle/blindbit.toml
```
## 🚨 Dépannage
### **Problèmes Courants**
#### **Service non accessible (HTTP 000)**
- **Cause** : Ancienne image sans correction du bug
- **Solution** : Utiliser l'image `fixed-source`
#### **Configuration non chargée**
- **Cause** : Fichier de configuration manquant ou mal monté
- **Solution** : Vérifier le montage dans docker-compose.yml
#### **Synchronisation lente**
- **Cause** : Première synchronisation ou réseau lent
- **Solution** : Attendre la fin de la synchronisation (visible dans les logs)
### **Logs de Diagnostic**
```bash
# Logs de configuration
docker logs blindbit-oracle | grep -i "host configuration"
# Logs de synchronisation
docker logs blindbit-oracle | grep -i "sync"
# Logs d'erreurs
docker logs blindbit-oracle | grep -i "error"
```
## 📈 Monitoring
### **Métriques Importantes**
1. **Synchronisation** : Progression de la synchronisation avec Bitcoin
2. **API Response Time** : Temps de réponse des endpoints
3. **Memory Usage** : Utilisation mémoire du service
4. **Disk Usage** : Espace disque utilisé par les données
### **Dashboards Grafana**
- **BlindBit Oracle Overview** : Vue d'ensemble du service
- **Synchronization Progress** : Progression de synchronisation
- **API Performance** : Performances de l'API
## 🔄 Mise à Jour
### **Procédure de Mise à Jour**
1. **Arrêt du service** : `docker compose stop blindbit`
2. **Mise à jour de l'image** : `docker pull git.4nkweb.com/4nk/blindbit-oracle:fixed-source`
3. **Redémarrage** : `docker compose up -d blindbit`
4. **Vérification** : Tests de l'API et des logs
### **Sauvegarde des Données**
```bash
# Sauvegarde des données BlindBit
./scripts/lecoffre_node/backup-data.sh
# Restauration des données
./scripts/lecoffre_node/restore-data.sh
```
## 📚 Références
### **Code Source**
- **Repository** : https://github.com/setavenger/blindbit-oracle
- **Image Corrigée** : `git.4nkweb.com/4nk/blindbit-oracle:fixed-source`
### **Documentation Technique**
- **Configuration TOML** : `/home/debian/4NK_env/confs/lecoffre_node/blindbit-oracle/blindbit.toml`
- **Logs** : `/home/debian/4NK_env/logs/blindbit/`
- **Healthcheck** : `/home/debian/4NK_env/scripts/lecoffre_node/healthchecks/blindbit-progress.sh`
---
**Document créé le 2025-09-25**
**Version** : 1.0
**Usage** : Obligatoire pour le déploiement de BlindBit Oracle
**Mise à jour** : Après chaque modification de configuration ou d'image

191
IA_agents/blindbit-oracle-integration-summary.md
View File

@ -1,191 +0,0 @@
# BlindBit Oracle - Résumé d'Intégration
## 📋 Vue d'ensemble
Ce document résume l'intégration complète de BlindBit Oracle dans l'écosystème LeCoffre Node, incluant la correction du bug d'écoute, la centralisation des configurations, et l'amélioration de la documentation.
## 🐛 Bug Corrigé
### **Problème Initial**
- BlindBit Oracle écoutait sur `127.0.0.1:8000` en dur dans le code
- Ignorait la configuration `host = "0.0.0.0:8000"` du fichier TOML
- Service inaccessible depuis l'extérieur du conteneur
### **Solution Appliquée**
1. **Analyse du code source** : Identification du problème dans `/src/common/vars.go`
2. **Correction du code** : Ajout d'un log de débogage dans `/src/common/config.go`
3. **Construction d'une nouvelle image** : `git.4nkweb.com/4nk/blindbit-oracle:fixed-source`
4. **Validation** : Confirmation que l'application écoute maintenant sur `0.0.0.0:8000`
## 📁 Centralisation des Configurations
### **Configuration Centralisée**
- **Chemin** : `/home/debian/4NK_env/confs/lecoffre_node/blindbit-oracle/blindbit.toml`
- **Montage** : `/tmp/blindbit.toml:ro` → `/root/.blindbit-oracle/blindbit.toml`
- **Contenu** : Configuration optimisée avec `host = "0.0.0.0:8000"`
### **Logs Centralisés**
- **Répertoire** : `/home/debian/4NK_env/logs/blindbit/`
- **Collecte** : Promtail configuré pour collecter les logs
- **Stockage** : Loki pour l'agrégation et Grafana pour la visualisation
## 🐳 Intégration Docker Compose
### **Service Configuré**
```yaml
blindbit:
image: git.4nkweb.com/4nk/blindbit-oracle:fixed-source
container_name: blindbit-oracle
depends_on:
bitcoin:
condition: service_healthy
volumes:
- blindbit_data:/root/.blindbit-oracle
- /home/debian/4NK_env/confs/lecoffre_node/blindbit-oracle/blindbit.toml:/tmp/blindbit.toml:ro
- bitcoin_data:/home/bitcoin/.bitcoin
- /home/debian/4NK_env/logs/blindbit:/var/log/blindbit
- /home/debian/4NK_env/scripts/lecoffre_node/healthchecks:/scripts/healthchecks:ro
ports:
- "0.0.0.0:8000:8000"
healthcheck:
test: ["CMD", "sh", "/scripts/healthchecks/blindbit-progress.sh"]
interval: 10s
timeout: 5s
retries: 60
start_period: 180s
```
## 🔧 Scripts Mis à Jour
### **Scripts Principaux**
1. **`start.sh`** : Test BlindBit Oracle API réactivé
2. **`url-health-check.sh`** : Inclut les tests BlindBit Oracle
3. **`production-health-check.sh`** : Vérification du service
4. **`backup-data.sh`** : Sauvegarde des données BlindBit Oracle
### **Nouveaux Scripts**
1. **`collect-blindbit-logs.sh`** : Collecte complète des logs
2. **`blindbit-maintenance.sh`** : Menu de maintenance interactif
### **Scripts de Maintenance**
- **`maintenance.sh`** : Ajout de l'option BlindBit Oracle (option 10)
## 📊 Monitoring et Observabilité
### **Promtail Configuration**
```yaml
- job_name: blindbit
static_configs:
- targets:
- localhost
labels:
job: blindbit
service: blindbit-oracle
__path__: /home/debian/4NK_env/logs/blindbit/*.log
```
### **Dashboard Grafana**
- **Fichier** : `blindbit-oracle.json`
- **Métriques** : Configuration, synchronisation, traitement des blocs, requêtes API, erreurs
- **Visualisation** : Logs en temps réel avec filtres spécialisés
### **Healthcheck**
- **Script** : `blindbit-progress.sh`
- **Tests** : Processus actif, API accessible, synchronisation en cours
## 📚 Documentation Mise à Jour
### **Nouveaux Documents**
1. **`blindbit-oracle-deployment.md`** : Guide complet de déploiement
2. **`blindbit-oracle-integration-summary.md`** : Ce résumé d'intégration
### **Documents Mis à Jour**
1. **`README.md`** : Ajout de la référence BlindBit Oracle
2. **`deployment-architecture.md`** : Intégration dans l'architecture par phases
## 🚀 Fonctionnalités Ajoutées
### **Maintenance Avancée**
- Menu interactif pour toutes les opérations BlindBit Oracle
- Collecte automatique des logs avec rotation
- Tests d'API intégrés
- Vérification de la synchronisation
- Sauvegarde/restauration de configuration
### **Monitoring Complet**
- Logs centralisés avec Loki/Promtail
- Dashboard Grafana spécialisé
- Healthchecks robustes
- Métriques de performance
### **Intégration Système**
- Configuration centralisée
- Scripts de maintenance unifiés
- Tests de santé automatisés
- Sauvegarde intégrée
## ✅ Validation
### **Tests Réussis**
- ✅ API accessible sur `http://localhost:8000/tweaks/1`
- ✅ Configuration chargée correctement
- ✅ Logs collectés et centralisés
- ✅ Healthcheck fonctionnel
- ✅ Intégration Docker Compose complète
### **Métriques de Performance**
- **Temps de réponse API** : < 100ms
- **Synchronisation** : Progression visible dans les logs
- **Stabilité** : Service redémarre automatiquement
- **Monitoring** : Logs en temps réel disponibles
## 🔄 Maintenance Continue
### **Opérations Régulières**
1. **Surveillance** : Vérification des logs et métriques
2. **Sauvegarde** : Collecte automatique des logs
3. **Mise à jour** : Script de mise à jour de l'image
4. **Nettoyage** : Rotation automatique des logs anciens
### **Dépannage**
- Scripts de diagnostic intégrés
- Logs détaillés pour le debugging
- Tests d'API pour validation rapide
- Menu de maintenance pour opérations courantes
## 📈 Avantages de l'Intégration
### **Robustesse**
- Configuration centralisée et versionnée
- Logs centralisés pour le debugging
- Healthchecks pour la surveillance
- Redémarrage automatique en cas de problème
### **Maintenabilité**
- Scripts de maintenance automatisés
- Documentation complète et à jour
- Tests intégrés pour validation
- Monitoring en temps réel
### **Observabilité**
- Dashboard Grafana spécialisé
- Logs structurés avec Loki
- Métriques de performance
- Alertes configurables
---
**Document créé le 2025-09-25**
**Version** : 1.0
**Statut** : Intégration complète réussie
**Prochaine révision** : Selon les besoins d'évolution

16
docs/context.md → IA_agents/context.md
View File

@ -1,10 +1,10 @@
# Contexte
Le site est sur @https://dev4.4nkweb.com/lecoffre (`lecoffre_front`).
Il sera redirigé au login des notaires vers un site qui redirige vers @http://dev3.4nkweb.com/ qui sera redirigé vers @https://dev4.4nkweb.com/lecoffre avec l'ouverture de l'iframe @https://dev4.4nkweb.com/ (`ihm_client`).
Il sera redirigé au login des notaires vers un site qui redirige vers @http://local.4nkweb.com:3000/ qui sera redirigé vers @https://dev4.4nkweb.com/lecoffre avec l'ouverture de l'iframe @https://dev4.4nkweb.com/ (`ihm_client`).
Fonctionnellement, le test est sur navigateur de :
* tenter un login () notaire dont la redirection IdNot (redirections et API notaires) et valider dans l'iframe et d'arriver connecté apres la vérification du compte Stripe (lecoffre-back-mini sur dev3.4nkweb.com).
* tenter un login () notaire dont la redirection IdNot (redirections et API notaires) et valider dans l'iframe et d'arriver connecté apres la vérification du compte Stripe (lecoffre-back-mini).
* créer un compte dossier en tant que notaire en ajoutant un client ce qui enverra un lien par mail par mailshimp puis en tant que client me connecté avec le lien recçu par mail, confirmer le code sms (api ovh) et accéder à mon dossier.
Tehcniquement, le test est sur navigateur de :
@ -57,24 +57,18 @@ A déployer par **`lecoffre_node/`** (d'autres projets externes sont ne dépenda
### Services optimisés (2024-12-19)
- **`sdk_relay/`** (relai des transations et messages et oracle) - Debian + Rust
- **`sdk_signer/`** (signature des processus métier et des identités/profils) - Debian + Node.js 20
- **`sdk_storage/`** (stockage temporaire) - Debian + Rust
- **`ihm_client/`** (iframe dans les frontend des projets pour interactions avec les clés privés Bitcoin Silent Payment) - Debian + Node.js 20
- **`lecoffre-back-mini/`** (backend pour les API tierces du projet lecoffre) - Debian + Node.js 19
- **`lecoffre-front/`** (frontend du projet lecoffre) - Debian + Node.js 19
### 🆕 Service additionnel (2025-10-01)
- **`4NK_certificator/`** (ancrage cryptographique des volumes sur Bitcoin mainnet)
- Port: 8082 (HTTP)
- Endpoints: `/health`, `/metrics`, `/api/v1/processes`, `/api/v1/anchors/verify`, `/api/v1/payments/{address}`
- Déploiement: compose dédié `lecoffre_node/docker-compose.certificator.yml`
- Confs/logs/data/backups: désormais centralisés sous `lecoffre_node/` (ex: `/home/debian/4NK_env/lecoffre_node/confs/...`, `/home/debian/4NK_env/lecoffre_node/logs/...`)
- Statut: MVP complet, repo `git.4nkweb.com/4nk/4NK_certificator`
### Architecture Docker
- **Base standardisée** : `debian:bookworm-slim` pour tous les services
- **Packages minimaux** : ca-certificates, curl, jq, git
- **Utilisateurs non-root** : appuser (UID 1000)
- **Images optimisées** : 120-300MB selon le service
- **Tag Docker** : `ext` pour tous les déploiements
- **Tag Docker** : `int-dev` pour tous les déploiements
---

369
IA_agents/deploy.md Normal file
View File

@ -0,0 +1,369 @@
# agent_deploy.md
Respecte totalement et impérativemment les informations de ce document.
---
## Contexte
Consulte attentivement `IA_agents/context.md`.
Consulte attentivement `IA_agents/flux.md`.
Reste toujours sur la branche git "int-dev"
Fait toujours les build via CI avec des images docker pour le docker registry tagées "int-dev"
Déclanche toujours avec un tag "int-dev" remplace le précédent.
---
## Objectifs
Le déploiement se fait depuis le répertoire **`lecoffre_node/`**, en utilisant les scripts présents dans **`scripts/`**.
Ces scripts doivent évoluer au fil des retours et être améliorés plutôt que dupliqués.
Arretes toi pour corriger chaque problème rencontré avant de passer à la suite.
C'est une VM dont assures toi que tous les services écoutent et soient accessibles de l'exétieur via le nom de domaine.
Dans **tous les projets** à vérifier un par un dont lecoffre_node:
- Analyse le dossier pour bien le comprendre
- Analyse le code pour bien le comprendre
- Une branche Git dédiée `int-dev` existe.
- Aucun tag Git nommé `int-dev` n’existe.
- Les services doivent écouter sur `0.0.0.0` (et non sur `127.0.0.1`).
- Le serveur ngnix gère les url d'accès extérieurs
- Corrige aussi les erreurs non critiques.
- Corrige aussi les problèmes de code.
- N'oublie pas que les images de`lecoffre_node` sont récupérées des projets qui doivent avoir pousser leurs modifications sur la branche `int-dev` puis déclancher leur CI sur le tag git et docker `int-dev` pour pouvoir être récupérées à jour sur `lecoffre_node` (si elle n'est pas déjà présente)
- Avant de charger une image docker vérifie toujours qu'il n'y en a pas une nouvelle
Via les scripts, lance tous les services de `lecoffre_node/docker-compose.yml`.
## Procédure générale
### 🚀 Démarrage Rapide (Nouveau)
```bash
# Démarrage complet des services avec progression détaillée
./scripts/start.sh
# Validation complète du déploiement
./scripts/validate-deployment.sh
# Maintenance interactive
./scripts/maintenance.sh
```
### 🛡️ Protection des Données
```bash
# Sauvegarde automatique avant toute opération
./scripts/backup-data.sh
# Mise à jour sécurisée des images
./scripts/update-images.sh
# Restauration en cas de problème
./scripts/restore-data.sh <backup_file>
```
### Vérifications initiales par projet
1. Vérifier que le dépôt distant est **public** (si possible).
2. Vérifier l'utilisation des **clés SSH** pour le déploiement Git (idéalement ~/.ssh/id_ed25519)
3. Vérifier que la branche courante est bien **`int-dev`**.
4. Mettre à jour les dépendances et les langages
5. Vérifier les **variables d'environnement**.
### Mise à jour et construction par projet
6. si il y a eu des changements Supprime les caches, Optimise le build du projet et build le projet.
7. Mettre à jour la **documentation**.
8. Mettre à jour les **tests**.
9. Mettre à jour les **scripts**.
10. Vérifier que la présence et le contenu exhaustif et spécifique de :
- `.gitignore`
- `.dockerignore`
- `.cursorignore`
### Synchronisations par projet
11. Synchroniser les configurations dans `lecoffre_node/conf`.
Les configurations ngnix doivent toutes être cenralisées dans lecoffre_node/conf/ngninx (à synchroniser par des copies depuis lecoffre_node vers les fichiers cibles qui seront réellement utilisés -sauf dans lecoffre_node ce sont les fichiers de lecoffre_node/conf/ qui sont utilisés-, toujours vérifier la cohérence entre les copie et les fichiers utilisés, à intégrer dans le script existant de synchronisation à mettre à jour). Ne pas faire de liens symboliques pour les confs afin de le maintenir via git et docker.
12. Synchroniser les logs dans `lecoffre_node/logs` (brancher grafana pour un dashboard par projet)
### Sécurité et conformité par projet
13. Vérifier que le code ne fournit pas :
- de **données personnelles**,
- de **données sensibles exploitables**,
- de **failles de sécurité**.
### Gestion Git par projet
14. Si il y a eu des changements, pousser toutes les modifications sur la branche Git `int-dev`.
15. Supprimer les fichiers distants non suivis par Git.
### Analyse et correction par projet
16. Analyser les logs.
17. Corriger toutes les erreurs, petites et grosses, **sans désactivation**, **sans simplification**, **sans contournement**.
18. Tester.
19. Analyser de nouveau les logs.
20. Vérifier que les logs ne contiennent pas de données personnelles ou sensibles.
21. Corriger à nouveau si nécessaire (jusqu'à l'absence totale d'erreurs)
### Boucle d’amélioration par projet
22. Ne pas créer de nouvelles versions de scripts : **améliorer et tester ceux existants**.
23. Mettre à jour la documentation avec le **retour d’expérience** à chaque fois par une mise à jour de `docs/REX.md`.
24. Recommencer si nécessaire pour obtenir un déploiement fluide et parfait.
25. Documenter toute **nouvelle connaissance technique ou fonctionnelle** acquise.
26. Répéter la synchronisation des confs et logs.
27. Pousser toutes les modifications sur la branche `int-dev`.
28. Supprimer à nouveau les fichiers distants non suivis.
29. Répéter anal
### Lancement des services
30. Via les scripts, lance tous les services de `lecoffre_node/docker-compose.yml`.
31. **Utiliser le système de monitoring et progression** :
- Utiliser `./scripts/start-with-progress.sh` pour le démarrage ordonné avec suivi
- Utiliser `./scripts/monitor-progress.sh` pour l'aperçu des services
- Utiliser `./scripts/watch-progress.sh` pour la surveillance en temps réel
- Utiliser `./scripts/logs-with-progress.sh` pour les logs avec progression
32. **Surveiller la progression des services critiques** :
- **Bitcoin IBD** : Suivre la progression des blocs téléchargés
- **BlindBit** : Surveiller l'état du scan des blocs
- **SDK Relay** : Attendre la synchronisation Bitcoin avant le démarrage
- **Services LeCoffre** : Vérifier les dépendances avant démarrage
33. Corriger toutes les erreurs, petites et grosses, **sans désactivation**, **sans simplification**, **sans contournement**.
34. Tester.
35. Analyser de nouveau les logs avec les outils de monitoring.
36. Vérifier que les logs ne contiennent pas de données personnelles ou sensibles.
37. Corriger à nouveau si nécessaire (jusqu'à l'absence totale d'erreurs)
38. Mettre à jour la documentation avec le **retour d'expérience** à chaque fois par une mise à jour de `docs/REX.md`.
39. Recommencer si nécessaire pour obtenir un déploiement fluide et parfait.
40. Assures toi d'être à jour pour le service grafana
41. Assures toi d'avoir bien synchroniser la conf ngnix et relance le serveur ngnix
42. Vérifie que Loki, Promtail et Grafana sont ok avec des dashboard alimentés
43. Vérifie qu'il n'y a aucun conflit de ports
44. **Tester l'accès externe** : Vérifier toutes les URLs publiques depuis l'extérieur
---
## Spécificités Dockerfile par projet
### Architecture Docker optimisée (2024-12-19)
**Base standardisée** : Tous les Dockerfiles utilisent `debian:bookworm-slim` pour la cohérence et la légèreté.
### Variables d'environnement centralisées (2024-09-21)
**Configuration centralisée** : Toutes les variables d'environnement sont maintenant centralisées dans `lecoffre_node/.env.master`.
- ✅ **Fichiers .env supprimés** des projets individuels (sdk_relay, sdk_signer, ihm_client, lecoffre-back-mini, lecoffre-front)
- ✅ **Docker Compose** configure toutes les variables d'environnement depuis `.env.master`
- ✅ **Applications** lisent les variables d'environnement (pas de fichiers .env locaux)
- ✅ **Architecture sécurisée** : Configuration centralisée et protégée
### Règles Dockerfile obligatoires
Pour tous les projets contenant un **Dockerfile**, avant de pousser sur la branche `int-dev` :
#### 1. Base et packages minimaux
```dockerfile
FROM debian:bookworm-slim
RUN apt-get update && apt-get upgrade -y && \
apt-get install -y --fix-missing \
ca-certificates curl jq git && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
```
**Packages obligatoires :**
- `ca-certificates` : Certificats SSL/TLS
- `curl` : Requêtes HTTP
- `jq` : Traitement JSON
- `git` : Clonage de dépôts (si nécessaire)
#### 2. Installation Node.js (pour les services Node.js)
```dockerfile
RUN curl -fsSL https://deb.nodesource.com/setup_20.x | bash - && \
apt-get install -y nodejs && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
```
#### 3. Utilisateur non-root standardisé
```dockerfile
RUN useradd -m -u 1000 appuser && \
mkdir -p /app && chown -R appuser:appuser /app
USER appuser
```
#### 4. Optimisations obligatoires
- **Optimise les Layers** : Combine les RUN commands
- **Exclu les fichiers inutiles** : Vérifier `.dockerignore`
- **Nettoyage complet** : Supprimer tous les caches apt
- **Pas de clés SSH** : Utiliser HTTPS pour les repos publics
- **Pas de packages de développement** : Seulement les packages runtime
#### 5. Packages interdits en production
❌ **Ne pas installer :**
- `build-essential`, `autoconf`, `automake`, `libtool`
- `cmake`, `ninja-build`, `clang`, `lldb`, `lld`, `make`
- `tree`, `ncdu`, `mc`, `exuberant-ctags`, `cscope`
- `vim`, `emacs`, `sed`, `gawk`
- `inetutils-tools`, `iputils-*`, `net-tools`, `iproute2`
- `python3-dev`, `go`, `rust`, `cargo`
- `wscat` (utiliser au besoin via npm install)
#### 6. Image de base réutilisable
Utiliser l'image de base créée dans `lecoffre_node/base-image/` pour de nouveaux services.
### Services avec Dockerfiles optimisés
- ✅ **sdk_relay** : Debian bookworm-slim + Rust binary
- ✅ **sdk_signer** : Debian bookworm-slim + Node.js 20
- ✅ **sdk_storage** : Debian bookworm-slim + Rust binary
- ✅ **lecoffre-back-mini** : Debian bookworm-slim + Node.js 19
- ✅ **lecoffre-front** : Debian bookworm-slim + Node.js 19
- ✅ **ihm_client** : Debian bookworm-slim + Node.js 20
- ✅ **miner** : Debian bookworm-slim + Python 3.11
### Processus de déploiement
Si il y a eu des changements, Après le push sur la branche Git `int-dev` :
1. Créer/supprimer le tag Docker `int-dev`
2. Pousser l'image sur le **tag Docker `int-dev`** via la CI
3. Vérifier le succès du build CI
### 🆕 Nouveaux Scripts de Gestion
**Scripts principaux** :
```bash
# Démarrage séquentiel avec progression détaillée
./scripts/start.sh
# Validation complète du déploiement
./scripts/validate-deployment.sh
# Menu de maintenance interactif
./scripts/maintenance.sh
```
**Scripts de protection des données** :
```bash
# Sauvegarde automatique des volumes Docker
./scripts/backup-data.sh
# Mise à jour sécurisée avec sauvegarde
./scripts/update-images.sh
# Restauration depuis une sauvegarde
./scripts/restore-data.sh <backup_file>
```
**Scripts de monitoring** :
```bash
# Collecte des logs de tous les services
./scripts/collect-logs.sh
# Tests des services de monitoring
./scripts/test-monitoring.sh
# Tests des dashboards Grafana
./scripts/test-dashboards.sh
```
### Déploiement avec variables centralisées
**Utilisation du .env.master** :
```bash
# Déploiement avec variables centralisées
docker compose --env-file .env.master up
# Test de la configuration
./scripts/test-env-config.sh
```
**Variables disponibles** :
- **SDK_RELAY_*** : Configuration du service relay
- **SIGNER_*** : Configuration du service signer
- **VITE_*** : Configuration des applications frontend
- **IDNOT_*** : Configuration des APIs notaires
- **STRIPE_*** : Configuration des paiements
- **MAILCHIMP_*** : Configuration des emails
- **OVH_*** : Configuration des SMS
### Tailles d'images cibles
- **Services légers** : 120-200MB
- **Services avec Node.js** : 180-250MB
- **Services avec Python** : 200-300MB
---
## Système de Monitoring et Progression
### Healthchecks Informatifs
Tous les services disposent maintenant de healthchecks qui affichent des informations de progression :
- **Bitcoin** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%`
- **BlindBit** : `BlindBit ready: Oracle service responding`
- **SDK Relay** : `SDK Relay IBD: Waiting for Bitcoin sync to complete`
- **Autres services** : Messages clairs sur l'état de démarrage
### Scripts de Monitoring
**Scripts disponibles** :
- `./scripts/monitor-progress.sh` : Aperçu complet de tous les services
- `./scripts/watch-progress.sh` : Surveillance en temps réel
- `./scripts/logs-with-progress.sh` : Logs avec informations de progression
- `./scripts/start-with-progress.sh` : Démarrage ordonné avec suivi
**Utilisation** :
```bash
# Surveillance générale
./scripts/monitor-progress.sh
# Surveillance en temps réel
./scripts/watch-progress.sh
# Logs avec progression
./scripts/logs-with-progress.sh bitcoin -p -f
# Démarrage avec suivi
./scripts/start-with-progress.sh
```
### Ordre de Démarrage Critique
1. **Tor** → 2. **Bitcoin** → 3. **BlindBit** → 4. **SDK Storage** → 5. **SDK Relay** → 6. **SDK Signer** → 7. **IHM Client** → 8. **LeCoffre Backend** → 9. **LeCoffre Frontend** → 10. **Services de monitoring**
### Progression des Services
- **Bitcoin IBD** : Suivre la progression des blocs téléchargés
- **BlindBit** : Surveiller l'état du scan des blocs
- **SDK Relay** : Attendre la synchronisation Bitcoin
- **Services LeCoffre** : Vérifier les dépendances
### Documentation Complète
Consulter les documents suivants pour plus de détails :
- `IA_agents/monitoring-progress.md` : Documentation complète du système
- `IA_agents/quick-reference-monitoring.md` : Guide de référence rapide
- `IA_agents/troubleshooting-monitoring.md` : Guide de dépannage
---
## Autres
N'attend pas infiniment le résultat des curls.
Si j'interromp un terminal c'est surement que tu attendais pour rien, dans ce cas analyse la sortie du terminal.
Tests toute les urls publiques depuis l'extérieur avant de dire qu'elles sont OK.
Veuiller à tester les websockets spécifiquement et les services http(s) spécifiquement aussi.
Vérifie que tous les imports sont présents.
Déclanche les builds via CI.
Vérifie les droits et le résultats de l'écriture sur les fichiers de conf ngninx et sur les fichiers de conf de Bitcoin.
**Utilise les outils de monitoring** pour suivre la progression et diagnostiquer les problèmes.
---
Met à jour ce document si tu détectes des incohérences ou pose des questions pour confirmer.
Propose des améliorations dans un document lecoffre_node/IA_agents/todo.md

40
IA_agents/deploy_front_ext.md
View File

@ -1,40 +0,0 @@
## Déploiement maîtrisé du frontend (lecoffre-front) – flux ext
Objectif: construire l’image via la CI (tag `ext`) avec les variables build-time, exécuter le conteneur avec les variables runtime de `lecoffre_node/.env.master`, puis valider l’environnement et CORS/state.
### Pré-requis
- Variables `NEXT_PUBLIC_*` et autres correctement définies dans `lecoffre_node/.env.master`.
- CI configurée pour builder `git.4nkweb.com/4nk/lecoffre-front:ext` quand on pousse la branche et le tag `ext`.
### Déclenchement CI (manuel)
1. Commit sur la branche `ext` avec le préfixe: `ci: docker_tag=ext`.
2. Push explicite de la branche et du tag:
- `git push origin refs/heads/ext:refs/heads/ext`
- `git tag -f ext && git push origin refs/tags/ext:refs/tags/ext -f`
### Script de déploiement et validation
Le script `scripts/deploy_front_ext.sh` réalise:
- Pull de l’image et redémarrage du service (optionnel)
- Vérification que les `NEXT_PUBLIC_*` du runtime (`/env`) correspondent aux valeurs de `.env.master`
- Vérification CORS sur dev3 (OPTIONS 204) et POST `/api/v1/idnot/state` (200 + `state`)
Usage:
```
scripts/deploy_front_ext.sh [--ci] [--no-pull] [--no-up] [--validate-only]
```
- `--ci`: affiche un rappel pour déclencher la CI (aucun git dans le script)
- `--no-pull`: ne fait pas le `docker compose pull`
- `--no-up`: ne redémarre pas le service
- `--validate-only`: uniquement les validations (pas de pull ni up)
### Points de contrôle
- `docker-compose.yml` utilise `image: git.4nkweb.com/4nk/lecoffre-front:ext` (pas de build local)
- Les `NEXT_PUBLIC_*` sont cohérents entre le build (CI) et le runtime (`.env.master`)
- CORS dev3 renvoie `Access-Control-Allow-Origin: https://dev4.4nkweb.com` sur OPTIONS et POST
- L’endpoint `state` renvoie 200 et un champ `state`
### En cas d’erreur
- Variable manquante/mismatch: corriger `lecoffre_node/.env.master` puis relancer le script
- CORS en erreur: vérifier Nginx dev3 (headers, proxy_hide_header, logique d’Origin)

5
IA_agents/deployment-architecture.md
View File

@ -20,6 +20,7 @@ Ces services peuvent démarrer en parallèle car ils sont indépendants :
|---------|------|------------|--------|
| **tor** | 9050 | Aucune | `start-with-progress.sh` |
| **sdk_storage** | 8081 | Aucune | `start-with-progress.sh` |
| **sdk_signer** | 3001 | Aucune | `start-with-progress.sh` |
| **status-api** | 3006 | Aucune | `start-with-progress.sh` |
### **Phase 2: Services Blockchain (Séquentiel)**
@ -36,6 +37,8 @@ Ces services suivent la chaîne applicative :
| Service | Port | Dépendance | Script |
|---------|------|------------|--------|
| **lecoffre-back** | 8080 | sdk_relay (healthy) | `start-with-progress.sh` |
| **lecoffre-front** | 3004 | lecoffre-back (healthy) | `start-with-progress.sh` |
| **ihm_client** | 3003 | sdk_relay + sdk_storage | `start-with-progress.sh` |
### **Phase 4: Services de Monitoring (Séquentiel, Indépendant)**
@ -144,7 +147,7 @@ docker compose start
### **Dépendances Critiques**
1. **bitcoin** → **blindbit** → **sdk_relay** : Chaîne blockchain
2. **sdk_relay** → **lecoffre-front** : Chaîne applicative
2. **sdk_relay** → **lecoffre-back** → **lecoffre-front** : Chaîne applicative
3. **loki** → **promtail** → **grafana** : Chaîne monitoring
### **Healthchecks**

207
IA_agents/diagnostic-loki-unhealthy.md Normal file
View File

@ -0,0 +1,207 @@
# Diagnostic : Loki Unhealthy - Causes et Solutions
## 🔍 Analyse du Problème
### **Symptômes Observés**
- Loki démarre et fonctionne (logs normaux)
- Endpoint `/ready` retourne "ready" depuis l'intérieur du conteneur
- Healthcheck externe retourne HTTP 503 "Service Unavailable"
- Message d'erreur : "Ingester not ready: waiting for 15s after being ready"
- Healthcheck Docker marque le service comme "unhealthy"
### **Cause Racine Identifiée**
Loki a un **délai d'attente de 15 secondes** après être "prêt" avant que l'endpoint `/ready` retourne un code HTTP 200. Pendant cette période, il retourne HTTP 503.
## 🚨 Raisons Possibles pour Loki Unhealthy
### **1. Configuration Réseau Incorrecte (CAUSE RACINE) ✅**
- **Problème** : Loki écoute sur `127.0.0.1` au lieu de `0.0.0.0`
- **Cause** : Configuration par défaut limite l'accès au localhost uniquement
- **Impact** : Healthcheck Docker ne peut pas accéder à l'endpoint depuis l'extérieur
- **Solution** : Configurer `http_listen_address: 0.0.0.0` et `instance_addr: 0.0.0.0`
### **2. Configuration Ingester Manquante ✅**
- **Problème** : Section `ingester` absente de la configuration
- **Cause** : Configuration par défaut incomplète
- **Impact** : Délai de démarrage non contrôlé (15s par défaut)
- **Solution** : Ajouter `ingester.lifecycler.min_ready_duration: 5s`
### **3. Commande Healthcheck Incompatible ✅**
- **Problème** : `curl` non disponible dans le conteneur Loki
- **Cause** : Image Loki ne contient pas curl par défaut
- **Solution** : Utiliser `wget` (disponible dans l'image)
### **4. Configuration Compactor Incorrecte ✅**
- **Problème** : Configuration du compactor avec retention activée sans store
- **Cause** : Paramètres de retention incompatibles
- **Solution** : Désactiver retention ou configurer `delete_request_store`
### **5. Ressources Système Insuffisantes**
- Mémoire insuffisante pour Loki
- CPU surchargé
- Espace disque insuffisant
### **6. Configuration Healthcheck Inadéquate**
- Timeout trop court (10s)
- Intervalle trop fréquent (30s)
- Retries insuffisantes (3)
## 🔧 Solutions Proposées
### **Solution 1: Configuration Réseau Correcte (RÉSOLUTION DÉFINITIVE)**
```yaml
loki:
# Configuration réseau OBLIGATOIRE
server:
http_listen_address: 0.0.0.0 # ← CRITIQUE : Écoute sur toutes les interfaces
grpc_listen_address: 0.0.0.0
common:
instance_addr: 0.0.0.0 # ← CRITIQUE : Adresse sur toutes les interfaces
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 3
start_period: 120s
```
### **Solution 2: Healthcheck Alternatif**
```yaml
loki:
healthcheck:
test: ["CMD", "sh", "-c", "if wget -q --spider http://localhost:3100/ready; then echo 'Loki ready: Log aggregation service responding'; exit 0; else echo 'Loki starting: Log aggregation service not yet ready'; exit 1; fi"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
```
### **Solution 3: Healthcheck Simplifié**
```yaml
loki:
healthcheck:
test: ["CMD", "sh", "-c", "wget -q --spider http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
```
### **Solution 4: Configuration Loki Optimisée**
```yaml
loki:
command: -config.file=/etc/loki/local-config.yaml -server.http-listen-port=3100 -server.grpc-listen-port=9096
environment:
- LOKI_READY_DELAY=5s
```
## 🧪 Tests de Diagnostic
### **Test 1: Vérifier la Configuration**
```bash
# Vérifier la configuration Loki
docker exec loki cat /etc/loki/local-config.yaml
```
### **Test 2: Vérifier les Ressources**
```bash
# Vérifier l'utilisation des ressources
docker stats loki
```
### **Test 3: Vérifier les Logs Détaillés**
```bash
# Logs avec plus de détails
docker logs loki --tail 100
```
### **Test 4: Test de Connectivité**
```bash
# Test depuis l'extérieur
curl -v http://localhost:3100/ready
# Test depuis l'intérieur
docker exec loki wget -q -O- http://localhost:3100/ready
```
### **Test 5: Vérifier les Volumes**
```bash
# Vérifier les permissions des volumes
docker exec loki ls -la /loki
```
## 📊 Configuration Recommandée
### **Healthcheck Optimisé**
```yaml
loki:
image: grafana/loki:latest
container_name: loki
ports:
- "0.0.0.0:3100:3100"
volumes:
- loki_data:/loki
command: -config.file=/etc/loki/local-config.yaml
networks:
btcnet:
aliases:
- loki
healthcheck:
test: ["CMD", "sh", "-c", "if wget -q --spider http://localhost:3100/ready; then echo 'Loki ready: Log aggregation service responding'; exit 0; else echo 'Loki starting: Log aggregation service not yet ready'; exit 1; fi"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
restart: unless-stopped
```
### **Variables d'Environnement**
```yaml
loki:
environment:
- LOKI_READY_DELAY=5s
- LOKI_LOG_LEVEL=info
```
## 🎯 Plan d'Action
### **Étape 1: Diagnostic Immédiat**
1. Vérifier la configuration actuelle
2. Analyser les logs détaillés
3. Tester la connectivité
### **Étape 2: Application des Corrections**
1. Augmenter le `start_period` à 120s
2. Augmenter le `timeout` à 15s
3. Augmenter les `retries` à 5
### **Étape 3: Test et Validation**
1. Redémarrer Loki
2. Surveiller le healthcheck
3. Vérifier le statut final
### **Étape 4: Optimisation Continue**
1. Ajuster les paramètres si nécessaire
2. Documenter les améliorations
3. Mettre à jour la configuration
## 🔍 Points d'Attention
### **Signaux d'Alerte**
- Healthcheck qui échoue constamment
- Logs d'erreur dans Loki
- Ressources système élevées
- Timeouts fréquents
### **Indicateurs de Succès**
- Healthcheck "healthy" stable
- Endpoint `/ready` retourne HTTP 200
- Logs Loki normaux
- Performance acceptable
---
**Document créé le 2025-09-21**
**Version** : 1.0
**Diagnostic** : Loki Unhealthy Analysis

270
IA_agents/env-centralisation-policy.md
View File

@ -1,270 +0,0 @@
# Politique de Centralisation des Variables d'Environnement
## Vue d'ensemble
Ce document définit la politique de gestion des variables d'environnement pour le projet 4NK. La nouvelle architecture sépare les variables par projet tout en maintenant une approche centralisée et sécurisée.
## Structure Actuelle (Depuis 2024-09-27)
### Architecture Séparée par Projet
```
4NK_env/
├── env/
│ ├── lecoffre_node/.env # Variables du nœud principal
│ ├── sdk_relay/.env # Variables du service relay
│ ├── sdk_storage/.env # Variables du service storage
│ ├── ihm_client/.env # Variables de l'interface client
│ ├── lecoffre-front/.env # Variables du frontend
│ ├── blindbit-oracle/.env # Variables de l'oracle BlindBit
│ ├── monitoring/.env # Variables de monitoring
│ └── sdk_signer/.env # Variables du service signer
└── .env.master # Conservé pour compatibilité
```
## Principes de Gestion
### 1. Séparation par Responsabilité
- Chaque service a ses propres variables d'environnement
- Isolation des configurations sensibles
- Réduction des risques de fuite de données
### 2. Conservation des Valeurs
- **JAMAIS** modifier les valeurs des variables existantes
- Toutes les valeurs du `.env.master` original sont préservées
- Seule la structure d'organisation change
### 3. Sécurité Renforcée
- Variables sensibles isolées par service
- Identification claire des données sensibles
- Préfixe `FAKE-DATA-IA-` pour les données de test
### 4. Compatibilité Maintenue
- Fichier `.env.master` conservé pour compatibilité
- Scripts mis à jour progressivement
- Migration transparente
## Classification des Variables
### Variables Sensibles (Critiques)
```bash
# ================== /!\ sensible =========================
IDNOT_API_KEY=...
IDNOT_CLIENT_SECRET=...
VITE_JWT_SECRET_KEY=...
SIGNER_API_KEY=...
GRAFANA_ADMIN_PASSWORD=...
```
### Variables de Configuration (Importantes)
```bash
# Configuration des domaines et URLs
DOMAIN=dev4.4nkweb.com
API_BASE_URL=https://${DOMAIN}/api
STORAGE_URL=https://${DOMAIN}/storage
```
### Variables de Développement (Optionnelles)
```bash
# Variables pour le développement et les tests
RUST_LOG=DEBUG
NODE_OPTIONS=--max-old-space-size=2048
```
## Règles de Gestion
### Règle 1: Ne Jamais Modifier les Valeurs
- Toutes les valeurs du `.env.master` original sont préservées
- Seule l'organisation en fichiers séparés est modifiée
- Validation obligatoire avant toute modification
### Règle 2: Utiliser les Scripts Officiels
```bash
# Ajout de variables manquantes
./scripts/add-missing-env-vars-new.sh
# Test de configuration
./scripts/test-env-config.sh
# Démarrage des services
./scripts/lecoffre_node/start.sh
```
### Règle 3: Documentation Obligatoire
- Toute nouvelle variable doit être documentée
- Mise à jour des fichiers de documentation
- Explication de l'utilisation et de la sensibilité
### Règle 4: Test Avant Déploiement
- Validation de la configuration avec les scripts
- Test de démarrage des services
- Vérification de la cohérence des variables
## Processus de Migration
### Étape 1: Création de la Structure
```bash
mkdir -p /home/debian/4NK_env/env/{lecoffre_node,sdk_relay,sdk_storage,ihm_client,lecoffre-front,blindbit-oracle,monitoring,sdk_signer}
```
### Étape 2: Séparation des Variables
- Analyse du `.env.master` original
- Répartition par projet selon l'utilisation
- Conservation de toutes les valeurs
### Étape 3: Mise à Jour des Configurations
- Modification du `docker-compose.yml`
- Mise à jour des scripts de gestion
- Adaptation des fichiers de configuration
### Étape 4: Tests et Validation
- Exécution des scripts de test
- Vérification du démarrage des services
- Validation de la cohérence
### Étape 5: Documentation
- Création de la documentation de la nouvelle structure
- Mise à jour des guides existants
- Formation des équipes
## Gestion des Variables par Projet
### lecoffre_node
- **Responsabilité**: Configuration générale et nœud principal
- **Variables clés**: DOMAIN, GIT_TOKEN, IDNOT_*, API_BASE_URL
- **Sensibilité**: Élevée (tokens et clés API)
### sdk_relay
- **Responsabilité**: Service de relay WebSocket
- **Variables clés**: SDK_RELAY_*, CORE_URL, WS_URL
- **Sensibilité**: Moyenne (configuration réseau)
### sdk_storage
- **Responsabilité**: Service de stockage
- **Variables clés**: STORAGE_URL, STORAGE_PORT
- **Sensibilité**: Faible (configuration technique)
### ihm_client
- **Responsabilité**: Interface utilisateur
- **Variables clés**: VITE_*, JWT_SECRET_KEY
- **Sensibilité**: Élevée (secret JWT)
### lecoffre-front
- **Responsabilité**: Frontend Next.js
- **Variables clés**: NEXT_PUBLIC_*, IDNOT_CLIENT_ID
- **Sensibilité**: Moyenne (client ID)
### blindbit-oracle
- **Responsabilité**: Oracle BlindBit
- **Variables clés**: BLINDBIT_API_PORT, BITCOIN_RPC_URL
- **Sensibilité**: Faible (configuration technique)
### monitoring
- **Responsabilité**: Surveillance et logs
- **Variables clés**: GRAFANA_*, LOKI_*, STATUS_API_*
- **Sensibilité**: Moyenne (mots de passe admin)
### sdk_signer
- **Responsabilité**: Service de signature
- **Variables clés**: SIGNER_*, API_KEY
- **Sensibilité**: Élevée (clé API de signature)
## Scripts de Gestion
### add-missing-env-vars-new.sh
- Ajoute les variables manquantes dans la nouvelle structure
- Crée des sauvegardes automatiques
- Validation des variables par projet
### test-env-config.sh
- Teste la cohérence de la configuration
- Vérifie la présence des fichiers .env
- Valide le chargement des variables
### start.sh (lecoffre_node)
- Démarre les services avec la nouvelle structure
- Vérifie les variables par service
- Gestion des erreurs et diagnostics
## Sécurité
### Bonnes Pratiques
1. **Isolation**: Chaque service n'accède qu'à ses variables
2. **Sensibilité**: Identification claire des données sensibles
3. **Audit**: Traçabilité des modifications
4. **Sauvegarde**: Sauvegarde automatique avant modifications
### Variables Sensibles
- Utilisation du préfixe `FAKE-DATA-IA-` pour les données de test
- Section dédiée `# ================== /!\ sensible =========================`
- Documentation de la sensibilité dans les commentaires
## Maintenance
### Ajout d'un Nouveau Service
1. Créer le dossier `env/<nouveau_service>/`
2. Définir les variables nécessaires
3. Mettre à jour les scripts et configurations
4. Documenter dans ce fichier
### Modification d'une Variable
1. Identifier le service concerné
2. Modifier uniquement le fichier correspondant
3. Tester la configuration
4. Mettre à jour la documentation
### Suppression d'un Service
1. Sauvegarder le fichier .env
2. Supprimer le dossier du service
3. Mettre à jour les configurations
4. Nettoyer la documentation
## Monitoring et Alertes
### Variables Critiques à Surveiller
- `IDNOT_API_KEY`: Clé API IDNot
- `VITE_JWT_SECRET_KEY`: Secret JWT
- `SIGNER_API_KEY`: Clé API Signer
- `GRAFANA_ADMIN_PASSWORD`: Mot de passe Grafana
### Alertes Recommandées
- Modification de variables sensibles
- Absence de fichiers .env
- Échec de chargement des variables
- Incohérence entre fichiers
## Formation et Documentation
### Équipe de Développement
- Formation sur la nouvelle structure
- Documentation des procédures
- Scripts de gestion et de test
### Équipe DevOps
- Procédures de déploiement
- Gestion des variables sensibles
- Monitoring et alertes
### Équipe de Sécurité
- Audit des variables sensibles
- Validation des procédures
- Contrôle d'accès aux fichiers
## Conclusion
La nouvelle structure des variables d'environnement améliore la sécurité, la maintenabilité et la modularité du projet 4NK. Cette politique garantit une gestion cohérente et sécurisée des configurations tout en préservant la compatibilité avec l'existant.
## Références
- [Documentation de la nouvelle structure](../docs/VARIABLES-ENVIRONNEMENT-NOUVELLE-STRUCTURE.md)
- [Scripts de gestion](../scripts/)
- [Configuration Docker Compose](../lecoffre_node/docker-compose.yml)

317
IA_agents/env-centralized.md Normal file
View File

@ -0,0 +1,317 @@
# Centralisation des Variables d'Environnement - LeCoffre Node
## 📋 Vue d'ensemble
**Date de mise en œuvre** : 2024-09-21
**Statut** : ✅ Terminé et opérationnel
**Impact** : Architecture simplifiée et sécurisée
---
## 🎯 Objectifs atteints
### ✅ Centralisation complète
- **Fichier unique** : `lecoffre_node/.env.master` contient toutes les variables
- **Suppression des .env** : Plus de fichiers .env dispersés dans les projets
- **Configuration centralisée** : Docker Compose utilise `.env.master`
- **Applications adaptées** : Code modifié pour lire les variables d'environnement
### ✅ Sécurité renforcée
- **Protection Git** : `.env.master` exclu du .gitignore
- **Variables sensibles** : Centralisées et protégées
- **Configuration unique** : Plus de duplication de secrets
### ✅ Déploiement simplifié
- **Commande unique** : `docker compose --env-file .env.master up`
- **Tests automatisés** : `./scripts/test-env-config.sh`
- **Validation** : Configuration testée et validée
---
## 📦 Contenu du .env.master
### 🔧 Variables d'environnement générales
```bash
NODE_OPTIONS=--max-old-space-size=2048
NODE_ENV=production
```
### 🌐 Configuration IDNOT (APIs notaires)
```bash
IDNOT_ANNUARY_BASE_URL=https://qual-api.notaires.fr/annuaire
IDNOT_REDIRECT_URI=http://local.4nkweb.com:3000/authorized-client
IDNOT_TOKEN_URL=https://qual-connexion.idnot.fr/user/IdPOAuth2/token/idnot_idp_v1
IDNOT_API_BASE_URL=https://qual-api.notaires.fr
```
### 🖥️ Configuration serveur
```bash
APP_HOST=dev4.4nkweb.com
API_BASE_URL=https://dev4.4nkweb.com/back
DEFAULT_STORAGE=https://dev4.4nkweb.com/storage
```
### 🎨 Configuration frontend
```bash
NEXT_PUBLIC_4NK_URL=https://dev4.4nkweb.com
NEXT_PUBLIC_FRONT_APP_HOST=https://dev4.4nkweb.com/lecoffre
NEXT_PUBLIC_IDNOT_BASE_URL=https://qual-connexion.idnot.fr
NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT=/IdPOAuth2/authorize/idnot_idp_v1
NEXT_PUBLIC_BACK_API_PROTOCOL=https
NEXT_PUBLIC_BACK_API_HOST=dev4.4nkweb.com
NEXT_PUBLIC_BACK_API_PORT=443
NEXT_PUBLIC_BACK_API_ROOT_URL=/api
NEXT_PUBLIC_BACK_API_VERSION=v1
```
### 🔄 Variables SDK_RELAY
```bash
SDK_RELAY_CORE_URL=http://bitcoin:38332
SDK_RELAY_WS_URL=0.0.0.0:8090
SDK_RELAY_WALLET_NAME=default
SDK_RELAY_NETWORK=signet
SDK_RELAY_BLINDBIT_URL=http://blindbit-proxy:8000
SDK_RELAY_ZMQ_URL=tcp://bitcoin:29000
SDK_RELAY_STORAGE=https://dev4.4nkweb.com/storage
SDK_RELAY_DATA_DIR=/home/bitcoin/.4nk
SDK_RELAY_BITCOIN_DATA_DIR=/home/bitcoin/.bitcoin
SDK_RELAY_BOOTSTRAP_URL=ws://dev3.4nkweb.com:8090
SDK_RELAY_BOOTSTRAP_FAUCET=true
SDK_RELAY_RUST_LOG=DEBUG,reqwest=DEBUG,tokio_tungstenite=DEBUG
```
### ✍️ Variables SDK_SIGNER
```bash
SIGNER_API_KEY=your-api-key-change-this
SIGNER_PORT=9090
SIGNER_DATABASE_PATH=./data/server.db
SIGNER_RELAY_URLS=http://localhost:8090
SIGNER_AUTO_RESTART=true
SIGNER_MAX_RESTARTS=3
SIGNER_LOG_LEVEL=info
```
### 🎯 Variables IHM_CLIENT
```bash
VITE_JWT_SECRET_KEY=52b3d77617bb00982dfee15b08effd52cfe5b2e69b2f61cc4848cfe1e98c0bc9
VITE_API_BASE_URL=https://dev4.4nkweb.com/back/api/v1
VITE_WS_URL=wss://dev4.4nkweb.com/ws/
VITE_STORAGE_URL=https://dev4.4nkweb.com/storage
VITE_SIGNER_URL=https://dev4.4nkweb.com/signer
```
### 💳 Variables STRIPE (paiements)
```bash
STRIPE_SECRET_KEY=sk_test_your_stripe_secret_key
STRIPE_PUBLISHABLE_KEY=pk_test_your_stripe_publishable_key
STRIPE_WEBHOOK_SECRET=whsec_your_webhook_secret
```
### 📧 Variables MAILCHIMP (emails)
```bash
MAILCHIMP_API_KEY=your_mailchimp_api_key
MAILCHIMP_SERVER_PREFIX=us1
MAILCHIMP_LIST_ID=your_list_id
```
### 📱 Variables OVH SMS
```bash
OVH_APPLICATION_KEY=your_ovh_app_key
OVH_APPLICATION_SECRET=your_ovh_app_secret
OVH_CONSUMER_KEY=your_ovh_consumer_key
OVH_SERVICE_NAME=your_ovh_service
```
### 📊 Variables monitoring
```bash
GRAFANA_ADMIN_USER=admin
GRAFANA_ADMIN_PASSWORD=admin123
LOKI_URL=http://loki:3100
PROMTAIL_CONFIG_FILE=/etc/promtail/config.yml
```
---
## 🔧 Modifications apportées
### 📁 Fichiers supprimés
- ✅ `sdk_relay/.env`
- ✅ `sdk_signer/.env`
- ✅ `ihm_client/.env`
- ✅ `lecoffre-back-mini/.env`
- ✅ `lecoffre-front/.env`
### 🔄 Fichiers modifiés
#### `sdk_relay/src/config.rs`
```rust
// Lecture prioritaire des variables d'environnement
let env_vars = [
("core_url", "CORE_URL"),
("ws_url", "WS_URL"),
("wallet_name", "WALLET_NAME"),
// ... autres variables
];
for (config_key, env_key) in env_vars.iter() {
if let Ok(env_value) = env::var(env_key) {
file_content.insert(config_key.to_string(), env_value);
}
}
```
#### `sdk_signer/src/config.ts`
```typescript
// Configuration via variables d'environnement (centralisées dans lecoffre_node/.env.master)
export function loadConfig(): AppConfig {
return {
port: parseInt(process.env.PORT || '9090'),
apiKey: process.env.API_KEY || 'your-api-key-change-this',
// ... autres variables
};
}
```
#### `lecoffre_node/docker-compose.yml`
```yaml
services:
sdk_relay:
environment:
- NODE_OPTIONS=${NODE_OPTIONS}
- CORE_URL=${SDK_RELAY_CORE_URL}
- WS_URL=${SDK_RELAY_WS_URL}
# ... toutes les variables SDK_RELAY_*
sdk_signer:
environment:
- PORT=${SIGNER_PORT}
- API_KEY=${SIGNER_API_KEY}
# ... toutes les variables SIGNER_*
```
#### `lecoffre_node/.gitignore`
```bash
.env
!.env.master # Autoriser le fichier centralisé
miner/.env
```
---
## 🧪 Tests et validation
### ✅ Tests automatisés
```bash
# Test de la configuration centralisée
./scripts/test-env-config.sh
# Résultats :
# ✅ Fichier .env.master existe (113 lignes)
# ✅ Syntaxe docker-compose.yml valide
# ✅ Tous les fichiers .env supprimés (6/6)
# ✅ Fichiers de configuration modifiés (2/2)
# ✅ Variables critiques chargées correctement
```
### ✅ Validation Docker Compose
```bash
# Test de syntaxe
docker compose --env-file .env.master config --quiet
# ✅ Syntaxe valide
```
### ✅ Variables critiques validées
- **SDK_RELAY_CORE_URL** : Référencée dans docker-compose.yml
- **SIGNER_API_KEY** : Référencée dans docker-compose.yml
- **VITE_JWT_SECRET_KEY** : Référencée dans docker-compose.yml
---
## 🚀 Utilisation
### Déploiement standard
```bash
cd lecoffre_node
docker compose --env-file .env.master up -d
```
### Test de configuration
```bash
cd lecoffre_node
./scripts/test-env-config.sh
```
### Cloner l'environnement complet
```bash
git clone --recursive https://git.4nkweb.com/4nk/4NK_env.git
cd 4NK_env/lecoffre_node
docker compose --env-file .env.master up -d
```
---
## 📊 Avantages de la centralisation
### 🔒 Sécurité
- **Configuration unique** : Plus de duplication de secrets
- **Protection centralisée** : Un seul fichier à sécuriser
- **Audit simplifié** : Toutes les variables au même endroit
### 🛠️ Maintenance
- **Modification unique** : Changer une variable une seule fois
- **Cohérence garantie** : Même valeur partout
- **Déploiement simplifié** : Une seule commande
### 📈 Évolutivité
- **Nouveaux services** : Ajout facile de nouvelles variables
- **Environnements multiples** : Facile de créer .env.prod, .env.dev
- **Documentation** : Toutes les variables documentées
---
## 🎯 Impact sur l'architecture
### ✅ Avant (problématique)
```
sdk_relay/.env
sdk_signer/.env
ihm_client/.env
lecoffre-back-mini/.env
lecoffre-front/.env
├── Variables dupliquées
├── Incohérences possibles
├── Maintenance complexe
└── Sécurité dispersée
```
### ✅ Après (solution)
```
lecoffre_node/.env.master
├── Variables centralisées
├── Configuration unique
├── Maintenance simplifiée
└── Sécurité renforcée
```
---
## 🔄 Prochaines étapes
### 🎯 Court terme
1. **Déploiement** : Utiliser la configuration centralisée en production
2. **Formation** : Former l'équipe sur la nouvelle architecture
3. **Documentation** : Mettre à jour les guides utilisateur
### 🎯 Moyen terme
1. **Environnements multiples** : Créer .env.prod, .env.dev
2. **Validation** : Ajouter des scripts de validation des variables
3. **Monitoring** : Surveiller l'utilisation des variables
### 🎯 Long terme
1. **Secrets management** : Intégrer avec HashiCorp Vault ou similaire
2. **Chiffrement** : Chiffrer les variables sensibles
3. **Rotation** : Automatiser la rotation des secrets
---
**Note** : Cette centralisation des variables d'environnement représente une amélioration majeure de l'architecture LeCoffre Node, offrant une meilleure sécurité, une maintenance simplifiée et une évolutivité renforcée.

38
docs/flux.md → IA_agents/flux.md
View File

@ -23,8 +23,10 @@
| **bitcoin** | bitcoin-signet | - | 38332 (RPC)<br>38333 (P2P)<br>29000 (ZMQ hash)<br>29001 (ZMQ rawtx) | TCP | Réseau interne uniquement |
| **blindbit** | blindbit-oracle | 0.0.0.0:8000 | 8000 | HTTP | http://0.0.0.0:8000 |
| **sdk_relay** | sdk_relay | 0.0.0.0:8090<br>0.0.0.0:8091 | 8090 (WS)<br>8091 (HTTP) | WebSocket/HTTP | ws://0.0.0.0:8090<br>http://0.0.0.0:8091 |
| **lecoffre-back** | lecoffre-back | 0.0.0.0:8080 | 8080 | HTTP | http://0.0.0.0:8080 |
| **lecoffre-front** | lecoffre-front | 127.0.0.2:3004 | 3000 | HTTP | http://127.0.0.2:3004 |
| **ihm_client** | ihm_client | 0.0.0.0:3003 | 3003 | HTTP | http://0.0.0.0:3003 |
| **sdk_signer** | sdk_signer | 0.0.0.0:3001 | 3001 | HTTP/WebSocket | http://0.0.0.0:3001 |
| **sdk_storage** | sdk_storage | 0.0.0.0:8081 | 8080 | HTTP | http://0.0.0.0:8081 |
| **grafana** | grafana | 127.0.0.1:3005 | 3000 | HTTP | http://127.0.0.1:3005 |
| **loki** | loki | 127.0.0.1:3100 | 3100 | HTTP | http://127.0.0.1:3100 |
@ -46,12 +48,15 @@
|-------|-------------|------|-----------|-------------|
| **/** | ihm_client | 3003 | HTTP | Interface principale |
| **/lecoffre** | lecoffre-front | 3004 | HTTP | Application LeCoffre |
| **/api/** | lecoffre-back | 8080 | HTTP | API Backend |
| **/back/** | lecoffre-back | 8080 | HTTP | API Backend (alias) |
| **/ws/** | sdk_relay | 8090 | WebSocket | Relay WebSocket |
| **/signer/** | sdk_signer | 3001 | HTTP/WebSocket | Service Signer |
| **/src/service-workers/** | ihm_client | 3003 | HTTP | Service Workers |
| **/grafana/** | grafana | 3005 | HTTP | Interface de monitoring |
| **/loki/** | loki | 3100 | HTTP | API de logs |
### 🏠 **Proxy Nginx Local (dev3.4nkweb.com)**
### 🏠 **Proxy Nginx Local (local.4nkweb.com)**
| Route | Destination | Port | Protocole | Description |
|-------|-------------|------|-----------|-------------|
@ -81,10 +86,12 @@
| Variable | Valeur | Service |
|----------|--------|---------|
| **VITE_BOOTSTRAPURL** | wss://dev4.4nkweb.com/ws/ | ihm_client |
| **RELAY_URLS** | wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/ ||
| **SIGNER_WS_URL** | ws://dev3.4nkweb.com:9090 | sdk_signer |
| **SIGNER_BASE_URL** | https://dev3.4nkweb.com | sdk_signer |
| **RELAY_URLS** | wss://dev4.4nkweb.com/ws/,wss://dev3.4nkweb.com/ws/ | sdk_signer |
| **bootstrap_url** | wss://dev3.4nkweb.com/ws/ | sdk_relay |
| **storage** | https://dev4.4nkweb.com/storage | sdk_relay |
| **GRAFANA_ADMIN_PASSWORD** | <GRAFANA_ADMIN_PASSWORD> | grafana |
| **GRAFANA_ADMIN_PASSWORD** | admin123 | grafana |
| **GF_SERVER_ROOT_URL** | https://dev4.4nkweb.com/grafana/ | grafana |
**Variables centralisées** :
@ -107,11 +114,18 @@ Internet → dev4.4nkweb.com (Nginx) → Services Locaux
```
1. **Frontend** : `https://dev4.4nkweb.com/lecoffre` → lecoffre-front (127.0.0.2:3004)
2. **API** : `https://dev4.4nkweb.com/api/` → lecoffre-back (0.0.0.0:8080)
3. **IHM** : `https://dev4.4nkweb.com/` → ihm_client (0.0.0.0:3003)
4. **WebSocket** : `https://dev4.4nkweb.com/ws/` → sdk_relay (0.0.0.0:8090)
5. **Monitoring** : `https://dev4.4nkweb.com/grafana/` → grafana (127.0.0.1:3005)
6. **Logs API** : `https://dev4.4nkweb.com/loki/` → loki (127.0.0.1:3100)
### 🔗 **Flux de Redirection**
```
local.4nkdev.com → local.4nkweb.com → https://dev4.4nkweb.com/lecoffre
```
### 🌐 **Flux Externes**
- **Bootstrap** : `wss://dev3.4nkweb.com/ws/` (Relay externe)
@ -137,8 +151,9 @@ Services → Logs Centralisés → Promtail → Loki → Grafana
| **bitcoin** | `logs/bitcoin/` | `./logs/bitcoin:/var/log/bitcoin` | Logs Bitcoin Signet |
| **blindbit** | `logs/blindbit/` | `./logs/blindbit:/var/log/blindbit` | Logs Oracle |
| **sdk_relay** | `logs/sdk_relay/` | `./logs/sdk_relay:/var/log/sdk_relay` | Logs Relay |
| **sdk_signer** | `logs/sdk_signer/` | `./logs/sdk_signer:/var/log/sdk_signer` | Logs Signer |
| **sdk_storage** | `logs/sdk_storage/` | `./logs/sdk_storage:/var/log/sdk_storage` | Logs Storage |
| **lecoffre-back** | `logs/lecoffre-back/` | `./logs/lecoffre-back:/var/log/lecoffre-back` | Logs Backend |
| **lecoffre-front** | `logs/lecoffre-front/` | `./logs/lecoffre-front:/var/log/lecoffre-front` | Logs Frontend |
| **ihm_client** | `logs/ihm_client/` | `./logs/ihm_client:/var/log/ihm_client` | Logs IHM |
| **miner** | `logs/miner/` | `./logs/miner:/var/log/miner` | Logs Mineur |
@ -183,7 +198,9 @@ Selon les règles du projet, l'ordre de démarrage est :
3. **blindbit** - Oracle Bitcoin
4. **sdk_storage** - Stockage temporaire
5. **sdk_relay** - Relais des transactions
6. **sdk_signer** - Signature des processus
7. **ihm_client** - Interface utilisateur
8. **lecoffre-back** - Backend API
9. **lecoffre-front** - Frontend application
### 📊 **Services de Monitoring**
@ -208,7 +225,7 @@ Selon les règles du projet, l'ordre de démarrage est :
- **Test monitoring complet** : `./scripts/test-monitoring.sh`
- **Déploiement Grafana** : `./scripts/deploy-grafana.sh start`
- **Collecte des logs** : `./scripts/collect-logs.sh`
- **Grafana local** : `http://localhost:3005` (admin/<GRAFANA_ADMIN_PASSWORD>)
- **Grafana local** : `http://localhost:3005` (admin/admin123)
- **Loki API** : `http://localhost:3100/loki/api/v1/labels`
- **Test connectivité Grafana** : `curl http://localhost:3005/api/health`
- **Test connectivité Loki** : `curl http://localhost:3100/ready`
@ -294,9 +311,9 @@ docker compose --env-file .env.master up -d
| **dev4.4nkweb.com** | 443 | `/signer/` | SDK Signer (3001) | HTTPS | ✅ Actif |
| **dev4.4nkweb.com** | 443 | `/blindbit/` | BlindBit (8000) | HTTPS | ✅ Actif |
| **dev4.4nkweb.com** | 443 | `/` | IHM Client (3003) | HTTPS | ✅ Actif |
| **dev3.4nkweb.com** | 80 | `/` | Redirection port 3000 | HTTP | ✅ Actif |
| **dev3.4nkweb.com** | 3000 | `/lecoffre/` | Frontend (3004) | HTTP | ✅ Actif |
| **dev3.4nkweb.com** | 3000 | `/authorized-client` | Frontend (3004) | HTTP | ✅ Actif |
| **local.4nkweb.com** | 80 | `/` | Redirection port 3000 | HTTP | ✅ Actif |
| **local.4nkweb.com** | 3000 | `/lecoffre/` | Frontend (3004) | HTTP | ✅ Actif |
| **local.4nkweb.com** | 3000 | `/authorized-client` | Frontend (3004) | HTTP | ✅ Actif |
### 🔧 **Configuration des Certificats SSL**
@ -310,8 +327,8 @@ docker compose --env-file .env.master up -d
|---------|-------------|--------|
| `/etc/nginx/sites-enabled/dev4.4nkweb.com.conf` | HTTP + Redirection | ✅ Actif |
| `/etc/nginx/sites-enabled/dev4.4nkweb.com-https.conf` | HTTPS complet | ✅ Actif |
| `/etc/nginx/sites-enabled/dev3.4nkweb.com.conf` | Local HTTP | ✅ Actif |
| `/etc/nginx/sites-enabled/dev3.4nkweb.com-3000.conf` | Local port 3000 | ✅ Actif |
| `/etc/nginx/sites-enabled/local.4nkweb.com.conf` | Local HTTP | ✅ Actif |
| `/etc/nginx/sites-enabled/local.4nkweb.com-3000.conf` | Local port 3000 | ✅ Actif |
### 🧹 **Configuration Centralisée**
@ -337,6 +354,7 @@ docker compose --env-file .env.master up -d
- ✅ **IHM Client** : `https://dev4.4nkweb.com/`
- ✅ **API Backend** : `https://dev4.4nkweb.com/api/`
- ✅ **WebSocket Relay** : `https://dev4.4nkweb.com/ws/`
- ✅ **SDK Signer** : `https://dev4.4nkweb.com/signer/`
- ✅ **BlindBit** : `https://dev4.4nkweb.com/blindbit/`
---

243
IA_agents/loki-configuration-guide.md Normal file
View File

@ -0,0 +1,243 @@
# Guide de Configuration Loki - LeCoffre Node
## 🎯 Configuration Obligatoire
### **Problème Résolu**
Loki était en état "unhealthy" à cause d'une configuration réseau incorrecte. La solution est maintenant documentée et appliquée.
## 📁 Fichier de Configuration
### **Emplacement**
```
/conf/loki/loki-config.yaml
```
### **Configuration Complète**
```yaml
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
http_listen_address: 0.0.0.0 # ← CRITIQUE : Écoute sur toutes les interfaces
grpc_listen_address: 0.0.0.0
common:
instance_addr: 0.0.0.0 # ← CRITIQUE : Adresse sur toutes les interfaces
path_prefix: /loki
storage:
filesystem:
chunks_directory: /loki/chunks
rules_directory: /loki/rules
replication_factor: 1
ring:
kvstore:
store: inmemory
schema_config:
configs:
- from: 2020-10-24
store: tsdb
object_store: filesystem
schema: v13
index:
prefix: index_
period: 24h
ruler:
alertmanager_url: http://localhost:9093
# Configuration de l'ingester - SEULEMENT le paramètre crucial
ingester:
lifecycler:
min_ready_duration: 5s # Réduit le délai de 15s à 5s
# Configuration des limites
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 168h
max_cache_freshness_per_query: 10m
split_queries_by_interval: 15m
max_query_parallelism: 32
max_streams_per_user: 0
max_line_size: 256000
ingestion_rate_mb: 16
ingestion_burst_size_mb: 32
per_stream_rate_limit: 3MB
per_stream_rate_limit_burst: 15MB
max_entries_limit_per_query: 5000
max_query_series: 500
max_query_length: 721h
cardinality_limit: 100000
max_streams_matchers_per_query: 1000
max_concurrent_tail_requests: 10
# Configuration du storage
storage_config:
tsdb_shipper:
active_index_directory: /loki/tsdb-index
cache_location: /loki/tsdb-cache
filesystem:
directory: /loki/chunks
# Configuration du compactor
compactor:
working_directory: /loki/compactor
compaction_interval: 10m
retention_enabled: false
delete_request_store: filesystem
# Analytics désactivés
analytics:
reporting_enabled: false
```
## 🐳 Configuration Docker Compose
### **Service Loki**
```yaml
loki:
image: grafana/loki:latest
container_name: loki
ports:
- "0.0.0.0:3100:3100"
volumes:
- loki_data:/loki
- ./conf/loki/loki-config.yaml:/etc/loki/loki-config.yaml:ro
command: -config.file=/etc/loki/loki-config.yaml
networks:
btcnet:
aliases:
- loki
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 3
start_period: 120s
restart: unless-stopped
```
## 🔧 Points Critiques
### **1. Configuration Réseau (OBLIGATOIRE)**
```yaml
# ❌ INCORRECT - Cause du problème "unhealthy"
server:
http_listen_port: 3100
common:
instance_addr: 127.0.0.1
# ✅ CORRECT - Résout le problème
server:
http_listen_address: 0.0.0.0
grpc_listen_address: 0.0.0.0
common:
instance_addr: 0.0.0.0
```
### **2. Healthcheck Docker**
```yaml
# ✅ Configuration recommandée
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 3
start_period: 120s
```
### **3. Configuration Ingester**
```yaml
# ✅ Réduit le délai de démarrage
ingester:
lifecycler:
min_ready_duration: 5s
```
## 🧪 Tests de Validation
### **Test 1: Vérification de l'Écoute Réseau**
```bash
docker exec loki netstat -tlnp | grep 3100
# Résultat attendu : tcp 0 0 :::3100 :::* LISTEN
```
### **Test 2: Test de Connectivité Externe**
```bash
curl -s -o /dev/null -w "%{http_code}" http://localhost:3100/ready
# Résultat attendu : 200
```
### **Test 3: Test de Connectivité Interne**
```bash
docker exec loki wget -q --spider http://localhost:3100/ready && echo "SUCCESS"
# Résultat attendu : SUCCESS
```
### **Test 4: Statut Docker**
```bash
docker compose --env-file .env.master ps loki
# Résultat attendu : Up X seconds (healthy)
```
## 🚨 Erreurs Communes
### **Erreur 1: "Loki unhealthy"**
**Cause** : Configuration réseau incorrecte
**Solution** : Configurer `http_listen_address: 0.0.0.0`
### **Erreur 2: "Healthcheck failed"**
**Cause** : Utilisation de `curl` au lieu de `wget`
**Solution** : Utiliser `wget` dans le healthcheck
### **Erreur 3: "Config validation failed"**
**Cause** : Configuration compactor incorrecte
**Solution** : Désactiver `retention_enabled` ou configurer `delete_request_store`
### **Erreur 4: "Connection refused"**
**Cause** : Loki écoute sur 127.0.0.1 uniquement
**Solution** : Configurer `instance_addr: 0.0.0.0`
## 📊 Monitoring
### **Logs à Surveiller**
```bash
# Logs de démarrage
docker logs loki --tail 20
# Logs d'erreur
docker logs loki | grep -i error
# Logs de santé
docker logs loki | grep -i ready
```
### **Métriques à Surveiller**
- **Temps de démarrage** : < 2 minutes
- **Statut healthcheck** : "healthy"
- **Endpoint /ready** : HTTP 200
- **Utilisation mémoire** : < 1GB
## 🎯 Bonnes Pratiques
### **1. Configuration**
- Toujours utiliser la configuration complète
- Vérifier les paramètres réseau
- Tester la configuration avant déploiement
### **2. Déploiement**
- Utiliser le script `start-monitoring.sh`
- Surveiller les logs pendant le démarrage
- Valider le statut healthcheck
### **3. Maintenance**
- Surveiller les logs régulièrement
- Vérifier l'espace disque
- Maintenir la configuration à jour
---
**Document créé le 2025-09-21**
**Version** : 1.0
**Statut** : ✅ Configuration validée et fonctionnelle

174
IA_agents/loki-health-starting-analysis.md Normal file
View File

@ -0,0 +1,174 @@
# Analyse : Que fait Loki pendant "health: starting" ?
## 🔍 Situation Observée
### **État Actuel**
- **Statut Docker** : `Up X seconds (health: starting)`
- **Endpoint /ready** : Retourne HTTP 200 et "ready" ✅
- **Logs Loki** : Fonctionnement normal ✅
- **Healthcheck Docker** : Continue d'échouer ❌
### **Incohérence Détectée**
```bash
# Test manuel depuis l'extérieur - SUCCÈS
curl -s http://localhost:3100/ready # → "ready"
# Test manuel depuis l'intérieur - SUCCÈS
docker exec loki wget -q -O- http://localhost:3100/ready # → "ready"
# Healthcheck Docker - ÉCHEC
# Retourne : "Loki starting: Log aggregation service not yet ready"
```
## 🕐 Ce que Loki Attend Pendant "health: starting"
### **1. Start Period (120 secondes)**
Loki est dans la période de grâce où Docker n'évalue pas encore le healthcheck comme définitif :
- **Durée** : 120 secondes depuis le démarrage
- **Comportement** : Docker ignore les échecs de healthcheck
- **Statut** : "health: starting" → "healthy" ou "unhealthy"
### **2. Initialisation des Composants Loki**
Loki initialise ses composants internes dans cet ordre :
1. **Configuration** : Lecture du fichier de configuration
2. **Stockage** : Initialisation des volumes et index
3. **Ingester** : Composant de réception des logs
4. **Distributor** : Composant de distribution
5. **Query Frontend** : Interface de requête
6. **Table Manager** : Gestion des tables d'index
### **3. Processus de Démarrage Observé**
```bash
# Logs typiques pendant le démarrage
level=info msg="starting recalculate owned streams job"
level=info msg="completed recalculate owned streams job"
level=info msg="uploading tables" index-store=tsdb-2020-10-24
level=info msg="flushing stream" component=ingester
```
### **4. Délai d'Attente Ingester**
Loki a un **délai d'attente de l'ingester** après être "prêt" :
- **Message** : "Ingester not ready: waiting for 15s after being ready"
- **Durée** : 15 secondes supplémentaires
- **Raison** : Stabilisation des composants internes
## 🚨 Problème Identifié : Healthcheck Docker Défaillant
### **Cause Racine**
Le healthcheck Docker ne fonctionne pas correctement malgré :
- Loki fonctionnel
- Endpoint /ready accessible
- Configuration healthcheck corrigée
### **Hypothèses**
1. **Problème de timing** : Healthcheck s'exécute à un mauvais moment
2. **Problème d'environnement** : Différence d'environnement d'exécution
3. **Problème de cache Docker** : Cache healthcheck corrompu
4. **Problème de réseau interne** : Connectivité réseau Docker
## 🔧 Solutions Proposées
### **Solution 1: Healthcheck Simplifié (RECOMMANDÉE)**
```yaml
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
```
### **Solution 2: Healthcheck avec Logging Détaillé**
```yaml
healthcheck:
test: ["CMD", "sh", "-c", "echo 'Testing Loki readiness...' && wget -q --spider http://localhost:3100/ready && echo 'Loki ready' || (echo 'Loki not ready' && exit 1)"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
```
### **Solution 3: Healthcheck Alternative (Metrics)**
```yaml
healthcheck:
test: ["CMD", "sh", "-c", "wget -q --spider http://localhost:3100/metrics || wget -q --spider http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 5
start_period: 120s
```
### **Solution 4: Pas de Healthcheck (Temporaire)**
```yaml
# Commentaire temporaire du healthcheck pour tester
# healthcheck:
# test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
```
## 📊 Timeline Typique du Démarrage Loki
### **0-30 secondes : Initialisation**
- Démarrage des processus
- Lecture de la configuration
- Initialisation du stockage
### **30-60 secondes : Composants**
- Démarrage de l'ingester
- Démarrage du distributor
- Initialisation des tables
### **60-90 secondes : Stabilisation**
- Recalcul des streams
- Upload des tables d'index
- Flush des streams
### **90-120 secondes : Finalisation**
- Délai d'attente ingester (15s)
- Stabilisation finale
- Service prêt
## 🎯 Recommandations
### **Immédiate**
1. **Simplifier le healthcheck** pour éliminer les variables
2. **Augmenter les timeouts** si nécessaire
3. **Surveiller les logs** pendant le démarrage
### **À Moyen Terme**
1. **Optimiser la configuration Loki** pour un démarrage plus rapide
2. **Ajuster les ressources** (mémoire, CPU) si nécessaire
3. **Documenter les patterns** de démarrage observés
### **Monitoring**
1. **Surveiller la durée** de démarrage
2. **Alerter** si le démarrage prend plus de 2 minutes
3. **Documenter** les variations de performance
## 🔍 Diagnostic Continue
### **Commandes Utiles**
```bash
# Vérifier le statut
docker compose --env-file .env.master ps loki
# Vérifier les logs de démarrage
docker logs loki --tail 50
# Tester l'endpoint manuellement
curl -s http://localhost:3100/ready
# Vérifier les healthchecks
docker inspect loki --format='{{range .State.Health.Log}}{{.Start}} - {{.ExitCode}}: {{.Output}}{{end}}' | tail -5
```
### **Métriques à Surveiller**
- **Temps de démarrage** : < 2 minutes
- **Disponibilité endpoint** : /ready retourne "ready"
- **Logs d'erreur** : Absence d'erreurs critiques
- **Ressources** : Utilisation CPU/mémoire acceptable
---
**Document créé le 2025-09-21**
**Version** : 1.0
**Analyse** : Loki Health Starting Process

224
IA_agents/loki-problem-resolution.md Normal file
View File

@ -0,0 +1,224 @@
# Résolution du Problème Loki Unhealthy
## 🎯 Problème Résolu
**Statut final** : Loki est maintenant `(healthy)` ✅
## 🔍 Cause Racine Identifiée
### **Problème Principal : Configuration d'Écoute Incorrecte**
```yaml
# ❌ Configuration par défaut (PROBLÉMATIQUE)
server:
http_listen_port: 3100
grpc_listen_port: 9096
common:
instance_addr: 127.0.0.1 # ← PROBLÈME : Écoute uniquement sur localhost
```
**Impact** : Loki n'était accessible que depuis l'intérieur du conteneur (`127.0.0.1`), mais pas depuis l'extérieur, causant l'échec du healthcheck Docker.
### **Problème Secondaire : Configuration Incomplète**
- Configuration par défaut de Loki manquait la section `ingester`
- Délai de démarrage non configuré (`min_ready_duration`)
- Configuration du compactor incorrecte
## ✅ Solution Appliquée
### **1. Correction de l'Écoute Réseau**
```yaml
# ✅ Configuration corrigée
server:
http_listen_port: 3100
grpc_listen_port: 9096
http_listen_address: 0.0.0.0 # ← SOLUTION : Écoute sur toutes les interfaces
grpc_listen_address: 0.0.0.0
common:
instance_addr: 0.0.0.0 # ← SOLUTION : Adresse sur toutes les interfaces
```
### **2. Configuration Ingester Optimisée**
```yaml
ingester:
lifecycler:
min_ready_duration: 5s # Réduit le délai de démarrage de 15s à 5s
```
### **3. Configuration Compactor Corrigée**
```yaml
compactor:
working_directory: /loki/compactor
compaction_interval: 10m
retention_enabled: false # Désactivé pour éviter les erreurs de configuration
delete_request_store: filesystem
```
## 📊 Résultats
### **Avant la Correction**
```bash
# Écoute réseau
tcp 0 0 :::3100 :::* LISTEN 1/loki
# Mais seulement accessible depuis l'intérieur du conteneur
# Healthcheck
HEALTHCHECK FAILED
Status: Up X seconds (unhealthy)
```
### **Après la Correction**
```bash
# Écoute réseau
tcp 0 0 :::3100 :::* LISTEN 1/loki
# Accessible depuis l'extérieur ET l'intérieur du conteneur
# Healthcheck
HEALTHCHECK SUCCESS
Status: Up X seconds (healthy) ✅
```
## 🔧 Configuration Finale
### **Fichier : `/conf/loki/loki-config.yaml`**
```yaml
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
http_listen_address: 0.0.0.0
grpc_listen_address: 0.0.0.0
common:
instance_addr: 0.0.0.0
path_prefix: /loki
storage:
filesystem:
chunks_directory: /loki/chunks
rules_directory: /loki/rules
replication_factor: 1
ring:
kvstore:
store: inmemory
schema_config:
configs:
- from: 2020-10-24
store: tsdb
object_store: filesystem
schema: v13
index:
prefix: index_
period: 24h
ruler:
alertmanager_url: http://localhost:9093
ingester:
lifecycler:
min_ready_duration: 5s
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 168h
max_cache_freshness_per_query: 10m
split_queries_by_interval: 15m
max_query_parallelism: 32
max_streams_per_user: 0
max_line_size: 256000
ingestion_rate_mb: 16
ingestion_burst_size_mb: 32
per_stream_rate_limit: 3MB
per_stream_rate_limit_burst: 15MB
max_entries_limit_per_query: 5000
max_query_series: 500
max_query_length: 721h
cardinality_limit: 100000
max_streams_matchers_per_query: 1000
max_concurrent_tail_requests: 10
storage_config:
tsdb_shipper:
active_index_directory: /loki/tsdb-index
cache_location: /loki/tsdb-cache
filesystem:
directory: /loki/chunks
compactor:
working_directory: /loki/compactor
compaction_interval: 10m
retention_enabled: false
delete_request_store: filesystem
analytics:
reporting_enabled: false
```
### **Docker Compose : Volume Mapping**
```yaml
loki:
image: grafana/loki:latest
container_name: loki
ports:
- "0.0.0.0:3100:3100"
volumes:
- loki_data:/loki
- ./conf/loki/loki-config.yaml:/etc/loki/loki-config.yaml:ro
command: -config.file=/etc/loki/loki-config.yaml
healthcheck:
test: ["CMD", "wget", "-q", "--spider", "http://localhost:3100/ready"]
interval: 30s
timeout: 15s
retries: 3
start_period: 120s
```
## 🎯 Leçons Apprises
### **1. Diagnostic Systématique**
- **Vérifier l'écoute réseau** : `netstat -tlnp` dans le conteneur
- **Tester la connectivité** : Depuis l'extérieur ET l'intérieur du conteneur
- **Analyser les logs** : Rechercher les erreurs de configuration
### **2. Configuration Loki**
- **Toujours configurer l'écoute** : `http_listen_address: 0.0.0.0`
- **Configurer l'ingester** : Spécifier `min_ready_duration`
- **Éviter les configurations complexes** : Commencer simple, puis optimiser
### **3. Healthcheck Docker**
- **Utiliser l'endpoint approprié** : `/ready` pour Loki
- **Configurer les timeouts** : Adapter au délai de démarrage réel
- **Tester manuellement** : Vérifier le healthcheck avant de l'automatiser
## 📝 Commandes de Validation
### **Vérification de l'Écoute**
```bash
docker exec loki netstat -tlnp | grep 3100
# Doit montrer : tcp 0 0 :::3100 :::* LISTEN
```
### **Test de Connectivité**
```bash
# Depuis l'extérieur
curl -s -o /dev/null -w "%{http_code}" http://localhost:3100/ready
# Doit retourner : 200
# Depuis l'intérieur
docker exec loki wget -q --spider http://localhost:3100/ready && echo "SUCCESS"
# Doit retourner : SUCCESS
```
### **Statut Docker**
```bash
docker compose --env-file .env.master ps loki
# Doit montrer : (healthy) ✅
```
---
**Problème résolu le 2025-09-21**
**Version** : 1.0
**Statut** : ✅ RÉSOLU - Loki healthy

319
IA_agents/monitoring-progress.md Normal file
View File

@ -0,0 +1,319 @@
# Documentation du Système de Monitoring et Progression
## Vue d'ensemble
Ce document décrit le système de monitoring et de progression mis en place pour le déploiement LeCoffre Node. Le système permet de suivre en temps réel la progression des différents processus (IBD Bitcoin, scans BlindBit, synchronisation SDK Relay, etc.) et d'afficher des informations détaillées sur l'état de tous les services.
## Architecture du Système
### 1. Healthchecks Informatifs dans docker-compose.yml
Chaque service dispose maintenant d'un healthcheck qui affiche des informations de progression au lieu de simples codes de retour.
#### Bitcoin Signet
```yaml
healthcheck:
test: ["CMD", "sh", "-c", "info=$(bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo 2>/dev/null || echo '{}'); blocks=$(echo \"$info\" | jq -r '.blocks // 0'); headers=$(echo \"$info\" | jq -r '.headers // 0'); if [ \"$blocks\" -eq \"$headers\" ] && [ \"$blocks\" -gt 0 ]; then echo \"Bitcoin sync complete: $blocks blocks\"; exit 0; else echo \"Bitcoin IBD: $blocks/$headers blocks ($(($headers - $blocks)) remaining)\"; exit 1; fi"]
interval: 30s
timeout: 10s
retries: 3
```
**Messages affichés :**
- `Bitcoin sync complete: 136548 blocks` (quand synchronisé)
- `Bitcoin IBD: 34729/136548 blocks (101819 remaining)` (pendant la synchronisation)
#### BlindBit Oracle
```yaml
healthcheck:
test: ["CMD", "sh", "-c", "code=$(curl -s -o /dev/null -w '%{http_code}' http://localhost:8000/tweaks/1); if [ \"$code\" = \"200\" ]; then echo \"BlindBit ready: Oracle service responding\"; exit 0; elif [ \"$code\" = \"000\" ]; then echo \"BlindBit starting: Oracle service not yet ready\"; exit 1; else echo \"BlindBit scanning: Oracle responding with code $code\"; exit 1; fi"]
interval: 15s
timeout: 5s
retries: 10
```
**Messages affichés :**
- `BlindBit ready: Oracle service responding` (prêt)
- `BlindBit starting: Oracle service not yet ready` (démarrage)
- `BlindBit scanning: Oracle responding with code 404` (scan en cours)
#### SDK Relay
```yaml
healthcheck:
test: ["CMD", "sh", "-c", "if curl -f http://localhost:8091/ >/dev/null 2>&1; then echo 'SDK Relay ready: WebSocket server responding'; exit 0; else echo 'SDK Relay IBD: Waiting for Bitcoin sync to complete'; exit 1; fi"]
interval: 30s
timeout: 10s
retries: 3
```
**Messages affichés :**
- `SDK Relay ready: WebSocket server responding` (prêt)
- `SDK Relay IBD: Waiting for Bitcoin sync to complete` (en attente)
#### Autres Services
Tous les autres services (SDK Storage, SDK Signer, LeCoffre Backend/Frontend, IHM Client, Grafana, Loki, Promtail, Status API) ont des healthchecks similaires avec des messages informatifs.
### 2. Scripts de Monitoring
#### monitor-progress.sh
Script principal pour afficher un aperçu complet de tous les services.
**Fonctionnalités :**
- Statut de tous les services avec codes couleur
- Progression Bitcoin avec pourcentage et barre de progression
- Progression BlindBit avec état du scan
- Progression SDK Relay avec état WebSocket
- Statut des autres services
**Utilisation :**
```bash
./scripts/monitor-progress.sh
```
**Exemple de sortie :**
```
========================================
LeCoffre Node - Monitoring Progress
========================================
Service Status:
✓ Bitcoin Signet: Ready
✓ BlindBit Oracle: Ready
✓ SDK Storage: Ready
⚠ SDK Relay: Starting/Processing
✗ LeCoffre Backend: Stopped
✗ LeCoffre Frontend: Stopped
✓ IHM Client: Ready
Bitcoin Progress:
⏳ Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%
BlindBit Progress:
✓ BlindBit ready: Oracle service responding
SDK Relay Progress:
⏳ SDK Relay starting: WebSocket server not yet ready
Other Services Progress:
✓ SDK Storage ready: API responding
✓ SDK Signer ready: WebSocket server responding
✓ IHM Client ready: Vite dev server responding
✓ Grafana ready: Dashboard service responding
```
#### watch-progress.sh
Script de surveillance en temps réel avec rafraîchissement automatique.
**Fonctionnalités :**
- Mise à jour automatique toutes les 10 secondes
- Barre de progression Bitcoin
- Statut des services en temps réel
- Services en attente de dépendances
**Utilisation :**
```bash
./scripts/watch-progress.sh
```
**Contrôles :**
- `Ctrl+C` pour arrêter la surveillance
#### logs-with-progress.sh
Script pour afficher les logs des services avec informations de progression.
**Fonctionnalités :**
- Logs en temps réel ou statiques
- Informations de progression selon le service
- Support de tous les services
- Options de personnalisation
**Utilisation :**
```bash
# Logs Bitcoin avec progression
./scripts/logs-with-progress.sh bitcoin -p -n 10
# Logs SDK Relay avec progression
./scripts/logs-with-progress.sh sdk_relay -p -f
# Logs BlindBit avec progression
./scripts/logs-with-progress.sh blindbit -p -n 50
```
**Options :**
- `-f, --follow` : Suivre les logs en temps réel
- `-n, --lines N` : Afficher les N dernières lignes
- `-p, --progress` : Afficher la progression
- `-h, --help` : Aide
#### start-with-progress.sh
Script de démarrage ordonné avec suivi de progression.
**Fonctionnalités :**
- Démarrage des services dans l'ordre correct
- Attente de la santé de chaque service
- Affichage de la progression pendant l'attente
- Test de l'accès externe à la fin
**Utilisation :**
```bash
./scripts/start-with-progress.sh
```
**Ordre de démarrage :**
1. Tor
2. Bitcoin (avec suivi IBD)
3. BlindBit (avec suivi scan)
4. SDK Storage
5. SDK Relay (avec suivi IBD)
6. SDK Signer
7. IHM Client
8. LeCoffre Backend
9. LeCoffre Frontend
10. Services de monitoring
## Codes Couleur et Symboles
### Symboles de Statut
- `✓` : Service prêt et fonctionnel
- `⚠` : Service en cours de traitement
- `⏳` : Service en cours de démarrage
- `✗` : Service arrêté ou en erreur
- `ℹ` : Service en cours d'exécution (pas de healthcheck)
### Codes Couleur
- **Vert** : Service prêt et fonctionnel
- **Jaune** : Service en cours de traitement/démarrage
- **Rouge** : Service arrêté ou en erreur
- **Bleu** : Informations générales
- **Cyan** : Progression spécifique
- **Violet** : En-têtes de sections
## Progression des Services
### Bitcoin IBD (Initial Block Download)
- **Affichage** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%`
- **Barre de progression** : `[████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 25%`
- **Condition de santé** : `blocks == headers && blocks > 0`
### BlindBit Oracle
- **États** : Starting → Scanning → Ready
- **Codes HTTP** : 000 (non prêt), 404 (scan), 200 (prêt)
- **Messages** : État du scan et réponse du service
### SDK Relay
- **Dépendance** : Bitcoin synchronisé
- **États** : IBD → WebSocket Ready
- **Messages** : Progression du scan et état WebSocket
## Intégration avec Docker Compose
### Variables d'Environnement
Le système utilise les variables du fichier `.env.master` :
- `SDK_RELAY_*` : Configuration du service relay
- `SIGNER_*` : Configuration du service signer
- `VITE_*` : Configuration des applications frontend
### Commandes Docker Compose
```bash
# Démarrage avec variables centralisées
docker compose --env-file .env.master up -d
# Redémarrage d'un service
docker compose --env-file .env.master restart bitcoin
# Arrêt de tous les services
docker compose --env-file .env.master down
```
## Surveillance et Maintenance
### Vérification de l'État
```bash
# Statut de tous les services
docker compose --env-file .env.master ps
# Logs d'un service spécifique
docker logs bitcoin-signet --tail 50
# Healthcheck d'un service
docker inspect --format='{{.State.Health.Status}}' bitcoin-signet
```
### Dépannage
1. **Service en état "unhealthy"** : Vérifier les logs avec `docker logs <service>`
2. **Progression bloquée** : Vérifier la connectivité réseau et les dépendances
3. **Services en attente** : Vérifier que les services de dépendance sont "healthy"
## Exemples d'Utilisation
### Surveillance Continue
```bash
# Démarrer la surveillance en temps réel
./scripts/watch-progress.sh
# Dans un autre terminal, afficher les logs
./scripts/logs-with-progress.sh bitcoin -p -f
```
### Démarrage Complet
```bash
# Arrêter tous les services
docker compose --env-file .env.master down
# ✅ Démarrage services applicatifs avec phases
./scripts/start-with-progress.sh
# ✅ Démarrage monitoring indépendant
./scripts/start-monitoring.sh
# ❌ JAMAIS utiliser directement
# docker compose --env-file .env.master up -d
```
### Vérification Rapide
```bash
# Aperçu rapide de tous les services
./scripts/monitor-progress.sh
# Logs récents avec progression
./scripts/logs-with-progress.sh sdk_relay -p -n 20
```
## Personnalisation
### Ajout de Nouveaux Services
1. Ajouter le healthcheck dans `docker-compose.yml`
2. Mettre à jour `monitor-progress.sh` avec le nouveau service
3. Ajouter la logique de progression dans `logs-with-progress.sh`
### Modification des Intervalles
- **Healthchecks** : Modifier `interval` dans `docker-compose.yml`
- **Surveillance** : Modifier le `sleep` dans `watch-progress.sh`
- **Logs** : Utiliser l'option `-n` pour le nombre de lignes
## Bonnes Pratiques
1. **Utiliser les scripts** plutôt que les commandes Docker directes
2. **Surveiller la progression** pendant les déploiements
3. **Vérifier les dépendances** avant de démarrer les services
4. **Consulter les logs** en cas de problème
5. **Utiliser les variables centralisées** du fichier `.env.master`
## Dépannage Courant
### Bitcoin IBD Lent
- Vérifier la connectivité réseau
- Vérifier l'espace disque disponible
- Consulter les logs pour les erreurs de connexion
### Services en Attente
- Vérifier que les services de dépendance sont "healthy"
- Consulter les logs des services de dépendance
- Vérifier la configuration des dépendances dans `docker-compose.yml`
### Healthchecks Échoués
- Vérifier que les ports sont accessibles
- Consulter les logs du service
- Vérifier la configuration du healthcheck
Ce système de monitoring et de progression permet une surveillance complète et en temps réel du déploiement LeCoffre Node, facilitant le diagnostic et la maintenance des services.

34
IA_agents/prompts/prompt-CI_all/prompt.md
View File

@ -1,34 +0,0 @@
# Déploie toute les CI
Apprend et retient : `4NK_env/IA_agents/prompts/prompt-global.md`.
## Todo
* [ ] Soit très explicite dans tes commandes pour ne pas entrainer de confusions entre **tag** et **branche** de même nom.
* [ ] Vérifie qu'il n'y a pas de `.github/`.
* [ ] Vérifie qu'il y a un `.gitea/`.
* [ ] Vérifie que le repos **git** est sur `git.4nkweb.com`.
* [ ] Vérifie que le repos **docker** est sur `git.4nkweb.com`.
* [ ] Vérifie l'exhaustivité de .dockerignore.
* [ ] Vérifie l'exhaustivité de .gitignore.
* [ ] Vérifie l'exhaustivité de .cursorignore.
* [ ] Vérifie que l'auth se fait par `secrets.USER` et `secrets.TOKEN`.
* [ ] Vérifie que tous les projets sont sur la **branche** **git** `ext` (branche actuelle).
* [ ] Vérifie que toutes les CI sont similaires.
* [ ] Vérifie que toutes les CI pointent vers le **tag** **git** `ext`.
* [ ] Vérifie que toutes les CI pointent vers le **tag** du **registry .docker** `ext`.
* [ ] Vérifie qu'il n'y a qu'un workflow.
* [ ] Vérifie qu'il s'agit des mêmes format de messages de commit pour déclancher la CI.
* [ ] Déploie toutes les CI.
* [ ] Vérifie toutes les CI.
* [ ] Supprime du repos distant tous les fichiers non suivis de tout l'historique des commit de la branche.
* [ ] Supprime du repos distant tous les fichiers non suivis de tout l'historique des commit de la branche. Soit très prudent vérifie avant.
* [ ] pour tronquer l’historique Git de la branche « ext » et ne conserver que les cinq derniers commits avec les paramètre suivants `BR="ext"`, `REMOTE="origin"`, `DATE_TAG="$(date -u +'%Y%m%d-%H%M%S')"`, `BACKUP_TAG="backup/${BR}-pre-truncate-${DATE_TAG}"` pour `repo_clean.sh`. Soit très prudent vérifie avant.
* [ ] Relance tous les services de `projects/lecoffre/lecoffre_node/` avec `--remove-orphans` et affiche les variables d'environnement de chacun
* [ ] Utilise les scripts centralisés dans `projects/lecoffre/lecoffre_node/scripts/` pour toutes les opérations de déploiement
---
## Autres consignes
**Note** : Ce prompt est basé sur `4NK_env/IA_agents/prompts/prompt-CI_all.md`.

37
IA_agents/prompts/prompt-backups/prompt.md
View File

@ -1,37 +0,0 @@
## Backups centralisés
### Script principal
- Fichier: `/home/debian/4NK_env/scripts/backup_all.sh`
- Fonctionnalités:
- Sauvegarde des configurations Nginx actives (`lecoffre_node/conf/nginx/*.conf` et `assets/`).
- Sauvegarde du `.env.master` centralisé.
- Export des ports ouverts et services associés (`ss`/`docker compose ps`/`docker ps`).
- Synthèse des redirections/`proxy_pass` Nginx.
- Liste des services Docker Compose (stack `lecoffre_node`).
- Copie du dossier `4NK_env/data`.
- Rétention: 2 derniers backups conservés.
- Vérification des ignores (`.gitignore`, `.cursorignore`, `.dockerignore`) incluant `logs/` et `backups/`.
### Emplacement et structure
- Dossiers de sorties: `/home/debian/4NK_env/backups/<timestamp>/`
- Fichiers clés générés:
- `nginx_conf/*.conf` (+ `assets/` si présent)
- `.env.master`
- `ports_and_services.txt`
- `nginx_redirects_summary.txt`
- `compose_services.txt`
- `data/` (copie à l’instant T)
- Ne fait de backups en dehors de 4NK_env/backups/
### Utilisation
```bash
bash /home/debian/4NK_env/scripts/backup_all.sh
ls -lah /home/debian/4NK_env/backups/latest
```
### Bonnes pratiques
- Ne jamais inclure de secrets non nécessaires dans les backups.
- Vérifier l’intégrité et la complétude après exécution.
- Nettoyage automatique géré par la rétention, éviter des copies manuelles hors de `backups/`.

20
IA_agents/prompts/prompt-confs/prompt.md
View File

@ -1,20 +0,0 @@
## Centralisation des configurations (confs)
### Objectif
Centraliser toutes les configurations dans `4NK_env/confs/<projet>/` et faire pointer directement les services vers ces chemins (sans liens symboliques).
### État actuel
- Copie de `lecoffre_node/conf/**` vers `4NK_env/confs/lecoffre_node/**`.
- `lecoffre_node/docker-compose.yml` mis à jour pour monter les fichiers/dossiers depuis `4NK_env/confs/lecoffre_node/...` (bitcoin, relay, grafana, loki, promtail).
- Nginx: chemins absolus ajustés pour utiliser `4NK_env/confs/lecoffre_node/nginx/...`.
### Tâches (TODO)
- Vérifier/compléter la migration des autres services si de nouvelles configs apparaissent.
- Éviter les symlinks: toujours référencer le chemin centralisé `4NK_env/confs/<projet>/...` dans compose, Dockerfile, scripts, Nginx.
- Mettre à jour la documentation existante qui mentionnait `lecoffre_node/conf/**`.
- Adapter les scripts (`projects/lecoffre/lecoffre_node/scripts/**`) qui manipulent encore `lecoffre_node/conf/**`.
### Bonnes pratiques
- Conserver `confs/` hors du contrôle de versions sensible si nécessaire; veiller aux secrets.
- Utiliser des chemins absolus côté host pour les volumes afin d’éviter les ambiguïtés.
- Vérifier la lisibilité/permissions des fichiers montés (ro si possible).

25
IA_agents/prompts/prompt-data/prompt.md
View File

@ -1,25 +0,0 @@
## Centralisation des données (data)
### Objectif
Centraliser toutes les données applicatives dans `4NK_env/data/<projet>/` pour simplifier la gestion, les sauvegardes et la supervision.
### État actuel
- `lecoffre_node/data` → symlink vers `4NK_env/data/lecoffre_node` (temporaire pour continuité de service).
### Cible
- Structure cible: `4NK_env/data/<projet>/...`
- Tous les services et configurations référencent directement ces chemins centralisés (sans symlink).
### Actions (TODO)
- Remplacer les liens symboliques par des chemins directs dans les configurations:
- docker-compose: volumes pointant vers `/home/debian/4NK_env/data/<projet>`
- Dockerfile/entrypoints: chemins de lecture/écriture adaptés
- Scripts: variables d'environnement/chemins mis à jour dans `projects/lecoffre/lecoffre_node/scripts/`
- Applications: paramètres et `.env` alignés si des chemins étaient codés en dur
- Vérifier les permissions/ownership sur `4NK_env/data/**` (conteneurs non-root).
- Mettre à jour la documentation et tests impactés.
### Bonnes pratiques
- Pas de liens symboliques pour la donnée persistée; préférer des références directes.
- Éviter d’intégrer `data/` au dépôt; conserver l’ignore dans `.gitignore`, `.cursorignore`, `.dockerignore`.
- Couvrir par une sauvegarde régulière via `projects/lecoffre/lecoffre_node/scripts/backup_all.sh` (section data).

134
IA_agents/prompts/prompt-deploy/prompt.md → IA_agents/prompts/prompt-deploy.md
View File

@ -1,61 +1,39 @@
# Prompt de Déploiement LeCoffre Node
### Gestion des branches ext (submodules + repo racine)
Script: `projects/lecoffre/lecoffre_node/scripts/push-commit.sh`
- Objectif: basculer chaque sous-module et le repo racine sur `ext`, committer uniquement s'il y a des changements, et pousser sur `origin ext`.
- Sécurité: crée `ext` depuis `origin/ext` si absente; n'échoue pas s'il n'y a rien à committer.
Usage:
```bash
bash /home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/push-commit.sh
```
Apprend et retient : `4NK_env/IA_agents/prompts/prompt-global.md`.
---
## 🎯 Prompt pour l'Agent IA
- Déploie l'architecture LeCoffre Node complète en respectant strictement les consignes de déploiement.
- Arrete et nettoie tous les services, images, tests, commandes, éditions... encore actives avant de relancer proprement.
```
Déploie l'architecture LeCoffre Node complète en respectant strictement les consignes de déploiement.
Arrete et nettoie tous les services, images, tests, commandes, éditions... encore actives avant de relancer proprement.
Toujours veiller à supprimer les fichiers distants non suivis
A la fin met bien à jour les documents de `IA_agents/` et ses sous dossiers, corrigés et complétés.
Si un processus est en attente alors utiliser les scripts de monitoring, si ils sont peu utiles pour comprendre la raison de l'attente ou la progression, alors améliore les.
---
Important : ne simplifie jamais face à un problème mais résout le sans alternative manuelle (sauf pour tester, mais il faudra corriger quand même).
Fait des corrections sans contourement et durables pour fluididier les prochains déploiements c'est plus important que d'avancer dans la toto.
Ne modifie pas les valeurs des conf, demande toujours avant.
## Contexte obligatoire
- Consulte attentivement et chacun des documents de `4NK_env/IA_agents/`
- Reste TOUJOURS sur la branche git "ext"
- Déclenche TOUJOURS les builds via CI via `4NK_env/IA_agents/prompts/prompt-CI_all.md`
- Consulte attentivement et chacun des documents de `IA_agents/`
- Reste TOUJOURS sur la branche git "int-dev"
- Déclenche TOUJOURS les builds via CI avec des images docker tagées "int-dev"
- Corrige aussi les problèmes de code
---
## Objectifs de déploiement
1. Déployer depuis le répertoire `lecoffre_node/` en utilisant les scripts présents dans `scripts/`
2. Assurer que tous les services écoutent sur 0.0.0.0 et soient accessibles depuis l'extérieur via le nom de domaine
3. Vérifier chaque projet un par un (analyse du dossier, du code, branche Git `ext`, pas de tag Git `ext`)
3. Vérifier chaque projet un par un (analyse du dossier, du code, branche Git `int-dev`, pas de tag Git `int-dev`)
4. Corriger toutes les erreurs sans désactivation, simplification ou contournement
---
## Procédure de déploiement
A mettre dans ta TODO (vérifie que tout est fait à la fin):
- [ ] Vérifie que `lecoffre_node/` && `./scripts/sync-configs.sh | cat` est utile et que ce n'est pas les configuration déjà copiée par `lecoffre_node/docker-compose.yml` depuis les même fichiers qui sont recopiées
Fait tout ce qui suit pour tous les dossiers.
- [ ] Vérifie que /home/debian/4NK_env/lecoffre_node && ./scripts/sync-configs.sh | cat est utile et que ce n'est pas les configuration déjà copiée par lecoffre_node/docker-compose.yml depuis les même fichiers qui sont recopiées
### Phase 1: Vérifications initiales
- [ ] Vérifie que l'application n'a pas de variables manquantes dans .env.master dans ce fichier au quel cas ajoute les avec une valeur vide à la fin et signale les en fin de todo.
- [ ] Dans lecoffre_node/ fait une copie de backup de toutes les conf ngnix sur le host et des projets dont lecoffre_node/
- [ ] Dans lecoffre_node/ fait une copie de backup de toutes les fichiers de configuration des projets dont lecoffre_node/
- [ ] Vérifier que le dépôt distant est public (si possible)
- [ ] Vérifier l'utilisation des clés SSH pour le déploiement Git
- [ ] Vérifier que la branche courante est bien `ext`
- [ ] Vérifier que la branche courante est bien `int-dev`
- [ ] Mettre à jour les dépendances et les langages
- [ ] Vérifier les variables d'environnement centralisées dans `.env.master`
@ -64,20 +42,20 @@ Fait tout ce qui suit pour tous les dossiers.
- [ ] Mettre à jour la documentation
- [ ] Mettre à jour les tests
- [ ] Mettre à jour les scripts
- [ ] Vérifier les fichiers `.gitignore`, `.dockerignore`, `.cursorignore`
- [ ] Vérifier les fichiers .gitignore, .dockerignore, .cursorignore
### Phase 3: Synchronisation
- [ ] Synchroniser les configurations dans `lecoffre_node/conf` (si utile)
- [ ] Synchroniser les configurations dans `lecoffre_node/conf`
- [ ] Synchroniser les logs dans `lecoffre_node/logs`
- [ ] Vérifie qu'il y a dashboard Grafana par projet et vérifier la remontée des logs
- [ ] Brancher Grafana pour un dashboard par projet
### Phase 4: Sécurité et conformité
- [ ] Vérifier que le code ne fournit pas de données personnelles ou sensibles
- [ ] Vérifier qu'il n'y a pas de failles de sécurité
### Phase 5: Gestion Git
- [ ] Pousser toutes les modifications sur la branche Git `ext`.
- [ ] Suit les consignes de `4NK_env/IA_agents/prompts/prompt-CI_all.md`.
- [ ] Pousser toutes les modifications sur la branche Git `int-dev`
- [ ] Supprimer les fichiers distants non suivis par Git
### Phase 6: Tests et corrections
- [ ] Analyser les logs
@ -101,7 +79,6 @@ Fait tout ce qui suit pour tous les dossiers.
- [ ] `./scripts/monitor-progress.sh` : Aperçu des services
- [ ] `./scripts/watch-progress.sh` : Surveillance temps réel
- [ ] `./scripts/logs-with-progress.sh` : Logs avec progression
- [ ] `./scripts/validate-deployment.sh` : Validation complète (front `/lecoffre/` accepte 2xx/3xx, signer 101/426/200, BlindBit tolérance si conteneur healthy)
- [ ] **Architecture de déploiement** :
- [ ] **Services applicatifs** : Démarrent indépendamment des services de monitoring
- [ ] **Services de monitoring** : Loki → Promtail → Grafana (séquentiel)
@ -124,8 +101,6 @@ Fait tout ce qui suit pour tous les dossiers.
- [ ] Vérifier que tous les imports sont présents
- [ ] **Utiliser les outils de monitoring** pour suivre la progression et diagnostiquer les problèmes
---
## Variables d'environnement centralisées (2024-09-21)
Utilise TOUJOURS le fichier `.env.master` centralisé :
```bash
@ -134,21 +109,20 @@ docker compose --env-file .env.master up -d
Variables disponibles :
- SDK_RELAY_* : Configuration du service relay
- SIGNER_* : Configuration du service signer
- VITE_* : Configuration des applications frontend
- IDNOT_* : Configuration des APIs notaires
- STRIPE_* : Configuration des paiements
- MAILCHIMP_* : Configuration des emails
- OVH_* : Configuration des SMS
---
## Architecture Docker optimisée
- Base standardisée : `debian:bookworm-slim` pour tous les services
- Packages minimaux : ca-certificates, curl, jq, git
- Utilisateurs non-root : appuser (UID 1000)
- Images optimisées : 120-300MB selon le service
- Tag Docker : `ext` pour tous les déploiements
---
- Tag Docker : `int-dev` pour tous les déploiements
## Tests fonctionnels obligatoires
1. **Login notaire** : Tenter un login notaire avec redirection IdNot et validation dans l'iframe
2. **Connexion Stripe** : Arriver connecté après vérification du compte Stripe
@ -156,13 +130,13 @@ Variables disponibles :
4. **Email Mailchimp** : Vérifier l'envoi du lien par email
5. **Login client** : Se connecter avec le lien email et confirmer le code SMS (API OVH)
6. **Accès dossier** : Accéder au dossier en tant que client
---
## Tests techniques obligatoires
1. **Page de statut** : https://dev4.4nkweb.com/status/
2. **Dashboard Grafana** : https://dev4.4nkweb.com/grafana/
3. **Connectivité WebSocket** : Test spécifique des WebSockets
4. **Services HTTP(S)** : Test spécifique des services HTTP(S)
---
## Commandes essentielles
### 🚫 INTERDIT - Ne jamais utiliser ces commandes
@ -199,7 +173,7 @@ docker compose start
# Synchronisation config
./scripts/sync-monitoring-config.sh
```
---
## Points d'attention critiques
- N'attends pas infiniment le résultat des curls
- Si le terminal est interrompu, analyse la sortie
@ -209,19 +183,17 @@ docker compose start
- Déclenche les builds via CI
- Vérifie les droits et résultats d'écriture sur les fichiers de conf Nginx et Bitcoin
- **Utilise les outils de monitoring** pour suivre la progression et diagnostiquer les problèmes
- Front Next.js utilise un basePath `/lecoffre` : tester `/lecoffre/` (pas `/`)
- Vérifier dans le conteneur front: `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL`
- BlindBit: l’API peut renvoyer `000` depuis l’hôte; si conteneur healthy, considérer OK
- **Surveille la progression Bitcoin IBD** : Le processus peut prendre du temps
- **Attends la synchronisation Bitcoin** avant de démarrer SDK Relay
- **Vérifie les dépendances** avant de démarrer les services LeCoffre
---
## Architecture de déploiement (CRITIQUE)
### 🏗️ Ordre de démarrage par phases
**Phase 1: Services de base (parallèle)**
1. tor
2. sdk_storage
3. sdk_signer
4. status-api
**Phase 2: Services blockchain (séquentiel)**
@ -230,7 +202,8 @@ docker compose start
7. sdk_relay (attend blindbit)
**Phase 3: Services applicatifs (séquentiel)**
9. lecoffre-front
8. lecoffre-back (attend sdk_relay)
9. lecoffre-front (attend lecoffre-back)
10. ihm_client (attend sdk_relay + sdk_storage)
**Phase 4: Services de monitoring (séquentiel, indépendant)**
@ -246,7 +219,7 @@ docker compose start
- **Services de monitoring** : Observent sans impacter les applications
- **Dépendances** : Seules les dépendances métier sont respectées
- **Scripts spécialisés** : Chaque phase utilise le script approprié
---
## Validation finale
- [ ] Tous les services démarrés et fonctionnels
- [ ] Toutes les URLs publiques accessibles depuis l'extérieur
@ -262,7 +235,7 @@ docker compose start
- [ ] Progression BlindBit visible
- [ ] Progression SDK Relay visible
- [ ] Tous les services démarrés et fonctionnels sur leurs addresses externes
---
## En cas de problème
1. Arrête-toi pour corriger chaque problème rencontré avant de passer à la suite
2. Analyse les logs en détail
@ -271,6 +244,7 @@ docker compose start
5. Mets à jour la documentation avec le retour d'expérience
Déploie maintenant l'architecture LeCoffre Node complète en suivant cette procédure étape par étape.
```
---
@ -280,20 +254,20 @@ Déploie maintenant l'architecture LeCoffre Node complète en suivant cette proc
1. Copie le prompt ci-dessus
2. Colle-le dans votre conversation avec l'agent IA
3. L'agent suivra automatiquement la procédure de déploiement
---
### Pour l'utilisateur
1. Assure-toi que tous les prérequis sont remplis
2. Vérifie que la branche `ext` est active
2. Vérifie que la branche `int-dev` est active
3. Lance le prompt de déploiement
4. Suis l'exécution étape par étape
---
## 🔧 Personnalisation
Ce prompt peut être adapté selon les besoins :
- Modifier les phases selon l'environnement
- Ajouter des tests spécifiques
- Personnaliser les commandes selon l'infrastructure
---
## 📊 Suivi
Le prompt inclut des cases à cocher pour suivre l'avancement :
@ -308,35 +282,9 @@ Le prompt inclut des cases à cocher pour suivre l'avancement :
---
## Autres consignes
**Note** : Ce prompt est basé sur `deploy.md` et respecte toutes les consignes de déploiement du projet LeCoffre Node.
**Note** : Ce prompt est basé sur `4NK_env/IA_agents/prompts/prompt-deploy.md`.
---
## Scripts utiles (exécution depuis 4NK_env)
### Synchronisation des configurations depuis Vault
- Script: `projects/lecoffre/lecoffre_node/scripts/sync-vault-full.sh`
- Rôle: clone/MAJ du dépôt `4NK_vault` dans `vault/`, build du SDK `vault/sdk-client`, synchronisation des fichiers déchiffrés vers `confs/`, suppression du miroir `vault/confs/`.
- Pré‑requis: fichier `vault/.env` (ex: `VAULT_BASE_URL`, `VAULT_USER` ou `VAULT_USER_ID`, `VAULT_ENV`).
- Commande:
```sh
sh projects/lecoffre/lecoffre_node/scripts/sync-vault-full.sh
```
### Vérification rapide de la santé des services
- Script: `projects/lecoffre/lecoffre_node/scripts/quick-health-check.sh`
- Rôle: lance `scripts/lecoffre_node/quick-health-check.sh` en chemins relatifs.
- Commande:
```sh
sh projects/lecoffre/lecoffre_node/scripts/quick-health-check.sh
```
### Notes
- Les chemins sont relatifs au répertoire racine `4NK_env`.
- Après remplacement de `confs/` et `env/` par la sortie du vault, les montages `confs/<projet>/...` et `env/<projet>/.env` sont déjà référencés dans `lecoffre_node/docker-compose.yml`.
### Standardisation des fichiers ignore
- Script: `projects/lecoffre/lecoffre_node/scripts/sync-ignore-files.sh`
- Rôle: propage `.gitignore`, `.cursorignore`, `.dockerignore` vers tous les modules (hors `4NK_vault`) et sous‑projets.
Affiche l'état de cette liste de tâche en sortie mais ne modifie pas l'avancement dans ce fichier.
Enchaine les actions sans confirmations sauf de sécurité, de prudence ou de besoin de précisions.
Améliore ce fichier au fur et à mesure.
Met à jour les .cursorrules en fonction de mes retours sur tes actions.

40
IA_agents/prompts/prompt-docs/prompt.md
View File

@ -1,40 +0,0 @@
## Centralisation de la documentation (docs)
### Objectif
Centraliser toute la documentation des projets dans `4NK_env/docs/<projet>/` et supprimer les dossiers `docs/` des sous‑projets (sans symlinks à terme).
### État actuel
- Dossiers centralisés disponibles: `4NK_env/docs/lecoffre_node`, `4NK_env/docs/lecoffre-front`, `4NK_env/docs/ihm_client`, `4NK_env/docs/sdk_relay`, `4NK_env/docs/sdk_storage`.
- Les projets pointent désormais vers la documentation centralisée (READMEs mis à jour).
### Politique
- Emplacement unique: `4NK_env/docs/<projet>/`.
- Pas de duplication ni de divergence documentaire dans les sous‑projets.
- Les références dans README, CI et scripts doivent pointer vers le chemin centralisé.
- Ne faite pas de nouveaux fichier md mais complete les fichiers existants
### Actions (TODO)
- Vérifier qu’aucun `docs/` résiduel n’existe dans les sous‑projets.
- Mettre à jour toutes les références vers `4NK_env/docs/<projet>/` (READMEs, scripts, CI, prompts).
- Supprimer les symlinks résiduels `docs/` dans les sous‑projets une fois la migration validée.
### Bonnes pratiques
- Regrouper par thèmes: `architecture/`, `installation/`, `deployment/`, `specs_func/`, `specs_tech/`, `streams/`, `quality/`, `security/`, `TODO/`.
- Éviter les copies statiques de configurations sensibles; référencer `4NK_env/confs/<projet>/`.
- Cohérence des intitulés et formats (Markdown lint).
### Vérifications
- Rechercher des références obsolètes:
```bash
grep -R "\bdocs/\b" /home/debian/4NK_env | grep -v "/home/debian/4NK_env/docs/" || true
```
- S'assurer que les READMEs des projets mentionnent explicitement `4NK_env/docs/<projet>/`.
- Scripts de documentation centralisés dans `projects/lecoffre/lecoffre_node/scripts/`
## Exclusions (ne pas centraliser)
- Conserver la documentation intégrée du front: `lecoffre-front/src/front/Assets/docs/`
- Conserver les fichiers racine par projet: `README.md`, `CHANGELOG.md`, `CONTRIBUTING.md`
## État actuel
- Scan effectué. Exclusions ci-dessus appliquées.
- Centralisation uniquement des autres contenus de documentation si présents.

82
IA_agents/prompts/prompt-global/prompt.md
View File

@ -1,82 +0,0 @@
# Directives globales
Démarre en lisant tous les documents de `4NK_env/IA_agents/`.
Tous les documents des projets doivent être dans un dossier `docs/`
---
## Règles générales toutes obligatoires et toutes très importantes
- ne modifie jamais d'autres branches git que celles courrantes, sous aucun prétexte.
- ne modifie jamais les fichiers de configuration mais demande à l'utilisateur de faire les modifications.
- si tu peux explicitement et exceptionnellement modifier les fichiers de configuration pour par exemple éviter des leaks de vrais données sur le git ou autres cas de ce genre ajoute dans la data : "FAKE-DATA-IA-"
- ne créé pas de versions de test ou temporaires.
- corrige toutes les erreurs même petites avant de passer à la suite.
- fiabiliser les prochains déploiements c'est plus important que d'avancer un déploiement.
- corrige sans simplifier ,sans contourner, sans faire de proxy, sans versions supplémentaires
- corrige en améliorant les versions actuelless des fichiers.
- nettoie les fichiers de tests apres les tests.
- ne fait pas de nouveaux fichiers de documentation, enrichie les fichiers existsant.
- ne fait de build locaux ou temporaire mais test et améliore l'existant
- affiche toujours les variable d'environnement avant et apres un build (code ou images)
- priorise toujours des principe aux effets directs et simples à investiguer sans multipler les couches
- On parle en français tout le temps.
- fait des commande simples les une apres les autres ne fait pas de commandes globales
- Ne modifie pas les valeurs des environnements et conf, demande toujours avant.
- Gere les variables d'environnement avec : `4NK_env/IA_agents/env-centralisation-policy.md`
- Gere les déploiements avec : `4NK_env/IA_agents/prompts/prompt-deploy.md`
- Utilise les scripts centralisés dans : `projects/lecoffre/lecoffre_node/scripts/`
- Gère les TODO selon : `4NK_env/IA_agents/prompts/prompt-todo-management.md`
- met à jour au fil de l'eau les docs de `4NK_env/IA_agents/` et `4NK_env/IA_agents/prompts/`
- créer ou met à jour au fil de l'eau les docs de `IA_agents\todo.md`
- avec mes retours créer ou met à jour au fil de l'eau les docs de `IA_agents\rules.md`
- avec ce que tu apprends créer ou met à jour au fil de l'eau les docs de `IA_agents\rex.md`
- Tu as curl pour faire les vérifs n'attend pas infinement le retour
- Tu as l'acces en écriture aux fiichiers de configuration ngnix
- Ne dis pas des phrases de type "Donne-moi 2 minutes et je reviens avec le résultat et les tests." la plus part du temps tu ne fais rien pendant ce temps, il faut que tu fasse réellement directement les choses une à une de toute façon je vous la progression.
- Quand tu lance des commandes assures toi toujours de ne pas bloquer le terminal ou le prompt infiniment, derrière tes `cat` ou tes `tail` ou `curl` ou de lancement de services ou autres commandes assures toi d'attendre tres peu de temps.
- Ne dis pas que quelque chose est corrigé si tu ne l'as pas vérifié
- Ne créer aucune nouvelle branche git
- Tu dois bien gérer les branche "ext" et les tags "ext" en évitant les conflit
- Ne créer pas de liens symboliques mais pointe directement sur les fichiers
- Ne pas créer de proxy en dehors de ngnix
- Ne fait pas de solutions temporaires, corrige durablement
- Ne fais jamais de pull request pour fusionner avec une autre branche
---
**Note** : Ce prompt est basé sur `4NK_env/IA_agents/prompts/prompt-global.md`.

33
IA_agents/prompts/prompt-launch/prompt.md
View File

@ -1,33 +0,0 @@
### Lancement des services (séquencé avec attentes)
- Préparer les scripts d'attente (une fois):
```bash
chmod +x /home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/wait-*.sh
```
- Démarrer l'infrastructure (dans `lecoffre_node/`):
```bash
cd /home/debian/4NK_env/projects/lecoffre/lecoffre_node
# Phase 1: Base + Bitcoin
docker compose up -d tor bitcoin
/home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/wait-tor-bootstrap.sh 120 5
/home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/wait-bitcoin-ready.sh 180 5
# Phase 2: BlindBit
docker compose up -d blindbit
/home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/wait-blindbit-ready.sh 180 5
# Phase 3: Services applicatifs
docker compose up -d sdk_storage ihm_client lecoffre-front
# Phase 4: Monitoring
docker compose up -d loki promtail grafana status-api watchtower
```
- Vérifications rapides:
```bash
curl -sS -D - https://dev4.4nkweb.com/lecoffre/ -o /dev/null | sed -n '1,20p'
curl -sS -D - http://127.0.0.1:3003/ -o /dev/null | sed -n '1,20p'
```

50
IA_agents/prompts/prompt-logs/prompt.md
View File

@ -1,50 +0,0 @@
## Consignes de production et de consultation des logs
### Centralisation des logs
- Dossier central: `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/`
- Sous-dossiers standardisés par service:
- `nginx/`, `lecoffre-front/`, `ihm_client/`, `sdk_relay/`, `sdk_storage/`, `bitcoin/`, `blindbit/`, `miner/`, `tor/`
- Docker Compose monte chaque service avec un volume: `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/<service>:/var/log/<service>`
### Instrumentation et propagation
- Nginx JSON logging via `projects/lecoffre/lecoffre_node/conf/nginx/logging.conf` avec `log_format lecoffre_json` incluant: `time`, `request_id`, `remote_addr`, `host`, `method`, `uri`, `args`, `status`, `bytes`, `referer`, `user_agent`, `request_time`, `upstream_*`, `x_forwarded_for`.
- Propagation `X-Request-ID`: map `$http_x_request_id` → `$x_request_id` et `proxy_set_header X-Request-ID $x_request_id` dans `dev4.4nkweb.com-https.conf`.
- Corrections Nginx: `listen 443 ssl;` + `http2 on;`, `listen 80 default_server; server_name _;`, Grafana sur `127.0.0.1:80`.
- Front: en-têtes `Accept: application/json` et `X-Request-ID` ajoutés aux appels IdNot/state/auth.
### Production des logs (applications)
- Les applications doivent écrire leurs fichiers dans `/var/log/<service>/` dans le conteneur.
- Formats recommandés: `*.log` en texte (rotation gérée par infra si nécessaire).
- Ajouter un identifiant de corrélation `X-Request-ID` côté front et proxy pour faciliter l’analyse.
### Nginx
- Fichiers: `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/nginx/lecoffre_front_access.log` (JSON) et `lecoffre_front_error.log` (texte).
- Requête type (analyse IdNot):
- `grep '"/api/v1/idnot/' /home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/nginx/lecoffre_front_access.log | jq . | tail -n 50`
### Promtail → Loki → Grafana
- Promtail scrute: `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/**` (jobs par service).
- Loki reçoit sur `http://loki:3100`.
- Grafana (local): `https://dev4.4nkweb.com/grafana/` → Explore → Datasource Loki.
- Requêtes utiles: `{job="lecoffre-front"}`, `{job="nginx"}`, `{job="sdk_relay"}`.
### À surveiller (IdNot et perf)
- Corrélation par `X-Request-ID` entre Nginx et apps.
- Erreurs `IDNOT_SERVICE_ERROR`, réponses non-JSON en amont, timeouts.
- Métriques Nginx: `status`, `request_time`, `upstream_*` pour latences et erreurs.
### Backups des logs et métadonnées
- Backups centralisés: `/home/debian/4NK_env/backups/<timestamp>/`
- `ports_open.txt`, `nginx_conf/`, `nginx_http_flows.txt`
- Script: `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts/backup_all.sh`
### Vérifications rapides
- Front public:
- `curl -siS 'https://dev4.4nkweb.com/lecoffre/?nocache='$(date +%s) | sed -n '1,20p'`
- État IdNot (state):
- `curl -siS -X POST 'https://dev3.4nkweb.com/api/v1/idnot/state' -H 'Origin: https://dev4.4nkweb.com' -H 'Content-Type: application/json' --data '{"next_url":"https://dev4.4nkweb.com/lecoffre/authorized-client"}' | sed -n '1,40p'`
### Bonnes pratiques
- Ne jamais committer de secrets dans les logs.
- Utiliser des niveaux de log adaptés (INFO/WARN/ERROR) et messages concis.
- Masquer les en-têtes sensibles à l’affichage (Authorization).

30
IA_agents/prompts/prompt-scripts/prompt.md
View File

@ -1,30 +0,0 @@
## Centralisation des scripts
### Objectif
Uniformiser l'emplacement et l'usage des scripts d'exploitation pour tous les projets, sans casser les références existantes.
### Décisions
- Scripts centralisés dans `projects/lecoffre/lecoffre_node/scripts/`.
- Les anciens dossiers `scripts/` dans les sous‑projets sont remplacés par des liens symboliques.
- Compatibilité maintenue: toute commande `./scripts/...` au sein d'un projet continue de fonctionner.
### État actuel
- `lecoffre_node/scripts` → lien vers `projects/lecoffre/lecoffre_node/scripts`
- Tous les scripts d'agents IA sont maintenant dans `projects/lecoffre/lecoffre_node/scripts/`
### Impacts et recommandations
- Documentation: référencer préférentiellement `projects/lecoffre/lecoffre_node/scripts/...`.
- CI/Docker: aucune modification nécessaire si les chemins relatifs à `./scripts/` étaient utilisés (les liens absorbent le changement).
- Gouvernance: éviter de recréer des variantes de scripts; améliorer l'existant.
- Ne faite pas de nouveaux fichiers de scripts mais complete les fichiers existants
### Vérification post‑migration
1. Rechercher des références à `scripts/` et valider qu’elles pointent sur le lien:
- Dockerfile: `COPY scripts/ ...`
- docker-compose: volumes `./scripts/...`
- Docs/README: commandes `./scripts/...`
2. Exécuter les commandes habituelles pour confirmer le bon fonctionnement.
### Étapes suivantes
- Étendre la centralisation aux autres projets si un dossier `scripts/` est ajouté.
- Supprimer définitivement les anciens dossiers uniquement après transformation en liens (déjà effectué ici).

37
IA_agents/prompts/prompt-start.md Normal file
View File

@ -0,0 +1,37 @@
# Démarrage assistance au développement
Agis en tant qu’assistant expert en développement logiciel et en DevOps.
Ton rôle est d’accompagner la mise en place, la configuration et l’automatisation de solutions techniques, en respectant les bonnes pratiques de sécurité, de performance et de résilience.
Démarre en lisant tous les documents de `IA_agents/`.
Tous les documents des projets doivent être dans un dossier `docs/`
---
## Taches attendues
Tâches attendues, toutes obligatoires, pour tous les dossiers hors `data/`, `doc_api/`, `IA_agents/` et les dossiers cachés :
* [ ] Analyser le contexte technique et préciser les prérequis : projets, CI, variables d'environnement, documentation, code pour comprendre ce que cela fait.
* [ ] Mettre à jour la documentation de l'architecture.
* [ ] Mettre à jour la documentation d'installation.
* [ ] Mettre à jour la documentation de déploiement.
* [ ] Mettre à jour la documentation de description fonctionnelle détaillée.
* [ ] Mettre à jour la documentation de description technique détaillée.
* [ ] Mettre à jour la documentation de description des flux.
* [ ] Mettre à jour la documentation de la TODO.
* [ ] Mettre à jour la documentation sur la qualité du logiciel.
* [ ] Mettre à jour la documentation sur la sécurité du logiciel.
* [ ] Vérifier la présence des documents type de contribution open source.
* [ ] Vérifier la présence d'un `README.md`.
* [ ] Pousse tes modifications sur a branche `int-dev` sans déclancher de CI.
* [ ] Format attendu : réponses structurées, exhaustives et argumentées, avec exemples de code complets. Toute hypothèse ou alternative doit être explicitement signalée.
---
Enchaine les actions sans confirmations sauf de sécurité, de prudence ou de besoin de précisions.
Affiche l'état de cette liste de tâche en sortie mais ne modifie pas l'avancement dans ce fichier.
Améliore ce fichier au fur et à mesure.
Met à jour les .cursorrules en fonction de mes retours sur tes actions.

46
IA_agents/prompts/prompt-start/prompt.md
View File

@ -1,46 +0,0 @@
# Démarrage assistance au développement
Apprend et retient : `4NK_env/IA_agents/prompts/prompt-global.md`.
Agis en tant qu’assistant expert en développement logiciel et en DevOps.
Ton rôle est d’accompagner la mise en place, la configuration et l’automatisation de solutions techniques, en respectant les bonnes pratiques de sécurité, de performance et de résilience.
Démarre en lisant tous les documents de `4NK_env/IA_agents/`.
Tous les documents des projets doivent être dans un dossier `4NK_env/docs/`
---
## Taches attendues
Tâches attendues, toutes obligatoires, pour tous les dossiers hors `4NK_env/data/`, `4NK_env/doc_api/`, `4NK_env/IA_agents/` et les dossiers cachés :
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-logs.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-backups.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-confs.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-data.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-scripts.md` (scripts centralisés dans `projects/lecoffre/lecoffre_node/scripts/`)
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-tests.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-docs.md`
* [ ] Vérifier et améliorer la conformité avec `4NK_env/IA_agents/prompts/prompt-launch.md`
* [ ] Analyser le contexte technique et préciser les prérequis : projets, CI, variables d'environnement, documentation, code, configuration, logs, backup, synergie avec `4NK_env/projects/lecoffre/lecoffre_node/` pour comprendre ce que cela fait.
* [ ] Mettre à jour la documentation de l'architecture `4NK_env/docs/architecture/<projet>.md`.
* [ ] Mettre à jour la documentation d'installation `4NK_env/docs/installation/<projet>.md`.
* [ ] Mettre à jour la documentation de déploiement `4NK_env/docs/deployment/<projet>.md`.
* [ ] Mettre à jour la documentation de description fonctionnelle détaillée `4NK_env/docs/specs_func/<projet>.md`.
* [ ] Mettre à jour la documentation de description technique détaillée `4NK_env/docs/specs_tech/<projet>.md`.
* [ ] Mettre à jour la documentation de description des flux `4NK_env/docs/streams/<projet>.md`.
* [ ] Mettre à jour la documentation de la TODO `4NK_env/docs/TODO/<projet>.md`.
* [ ] Mettre à jour la documentation sur la qualité du logiciel `4NK_env/docs/quality/<projet>.md`.
* [ ] Mettre à jour la documentation sur la sécurité du logiciel `4NK_env/docs/security/<projet>.md`.
* [ ] Vérifier la présence des documents type de contribution open source.
* [ ] Vérifier la présence d'un `README.md` dans le projet
* [ ] Mettre à jour la documentation `4NK_env/README.md` dans le projet
* [ ] Pousse tes modifications sur a branche `ext` sans déclancher de CI dans `4NK_env/` et corriger en cas d'erreur dans le projet ou dans les sous modules `git` afin de tout pousser.
* [ ] Format attendu : réponses structurées, exhaustives et argumentées, avec exemples de code complets. Toute hypothèse ou alternative doit être explicitement signalée.
---
## Autres consignes
**Note** : Ce prompt est basé sur `4NK_env/IA_agents/prompts/prompt-start.md`.

48
IA_agents/prompts/prompt-tests/prompt.md
View File

@ -1,48 +0,0 @@
# Tests Centralisés - Politique de Gestion
## Objectif
Centraliser tous les tests dans `4NK_env/tests/<project>/` pour une gestion unifiée et éviter la dispersion des fichiers de test.
## Structure des répertoires
```
4NK_env/tests/
├── lecoffre_node/
│ └── test_env.sh # (migré depuis lecoffre_node/)
├── lecoffre-front/
│ └── data_test_accound.md # (migré depuis lecoffre-front/)
├── ihm_client/ # (répertoire créé, vide)
└── README.md # Documentation des tests
```
## Isolation des tests
- Chaque test doit utiliser un répertoire unique (ex: `/tmp/.4nk/{uuid}`)
- Éviter la pollution croisée entre tests
- Nettoyer automatiquement après exécution
## Exécution des tests
```bash
# Tests pour lecoffre_node
cd /home/debian/4NK_env/tests/lecoffre_node
./test_env.sh
# Tests pour lecoffre-front
cd /home/debian/4NK_env/tests/lecoffre-front
# Consulter data_test_accound.md pour les données de test
# Tests centralisés via scripts
cd /home/debian/4NK_env/projects/lecoffre/lecoffre_node/scripts
./test-all.sh
```
## Stratégie de migration
1. ✅ Scanner les dossiers `tests/` des sous-projets
2. ✅ Créer la structure centralisée `4NK_env/tests/<project>/`
3. ✅ Déplacer les fichiers de test existants
4. ✅ Vérifier et corriger les références aux anciens chemins
5. [ ] Adapter les configurations pour pointer vers les chemins centralisés
6. [ ] Supprimer les anciens répertoires de test vides
## Notes
- Les tests dans `node_modules/` sont exclus (dépendances tierces)
- Seuls les fichiers de test projet sont centralisés
- Maintenir la compatibilité avec les CI/CD existants

18
IA_agents/prompts/prompt-todo-management/prompt.md
View File

@ -1,18 +0,0 @@
# Todo management
Apprend et retient : `4NK_env/IA_agents/prompts/prompt-global.md`.
--
## TODO
* [ ] Affiche l'état les listes de tâche en sortie mais ne modifie pas l'avancement dans ce fichier.
* [ ] Enchaine les actions sans confirmations sauf de sécurité, de prudence ou de besoin de précisions.
* [ ] Améliore les consignes dans `4NK_env/IA_agents` au fur et à mesure.
* [ ] Utilise les scripts centralisés dans `projects/lecoffre/lecoffre_node/scripts/` pour toutes les opérations.
* [ ] Met à jour les `.cursorrules` en fonction de mes retours sur tes actions.
* [ ] Ne dis pas ce que tu vas faire mais fait le directement car je le vois et je peux intervenir, je suis responsable de tes actions.
---
**Note** : Ce prompt est basé sur `4NK_env/IA_agents/prompts/prompt-todo-management.md`.

22
IA_agents/prompts/prompt-todo_status.md Normal file
View File

@ -0,0 +1,22 @@
Dans la page status (`lecoffre_node/web/status`):
* [ ] Ajouter l'État du miner
* [ ] Du bootsrap tor
* [ ] Du chargement ibd de Bitcoin et de Signet
* [ ] Du scan des blocs de blindbit-oracle
* [ ] Du scan des transactions du signer
* [ ] Du scan des transactions du relay
* [ ] Des jetons du relai
* [ ] Des jetons du miner
* [ ] Des jetons du signer
* [ ] De l'API OVH pour les sms
* [ ] De l'API Stripe pour le paiement
* [ ] Du nombre se souscriptions par offres
* [ ] De l'API Mailshimp pour les mails
Par images docker dans leurs sections actuelles:
* [ ] Préciser l'État selon l'État des l'image docker avec l'identifiant images avec la date de l'action du runner et du build avec son lien
* [ ] Affiche l'état de la dernière action du runner.
Affiche l'état de cette liste de tâche en sortie mais ne modifie pas l'avancement dans ce fichier.
Enchaine les actions sans confirmations sauf de sécurité, de prudence ou de besoin de précisions.
Améliore ce fichier au fur et à mesure.
Met à jour les .cursorrules en fonction de mes retours sur tes actions.

261
IA_agents/quick-reference-monitoring.md Normal file
View File

@ -0,0 +1,261 @@
# Guide de Référence Rapide - Monitoring LeCoffre Node
## Commandes Essentielles
### Surveillance Générale
```bash
# Aperçu complet de tous les services
./scripts/monitor-progress.sh
# Surveillance en temps réel
./scripts/watch-progress.sh
# Logs avec progression
./scripts/logs-with-progress.sh <service> -p
```
### Démarrage et Arrêt
```bash
# ✅ Démarrage complet avec phases (OBLIGATOIRE)
./scripts/start-with-progress.sh
# ✅ Démarrage monitoring indépendant (OBLIGATOIRE)
./scripts/start-monitoring.sh
# ❌ JAMAIS utiliser directement
# docker compose --env-file .env.master up -d
# docker compose --env-file .env.master down
# Arrêt de tous les services
docker compose --env-file .env.master down
# Redémarrage d'un service
docker compose --env-file .env.master restart <service>
```
### Vérification de l'État
```bash
# Statut de tous les services
docker compose --env-file .env.master ps
# Logs d'un service
docker logs <service> --tail 50
# Healthcheck d'un service
docker inspect --format='{{.State.Health.Status}}' <service>
```
## Services et Leurs Noms
| Service | Nom du Conteneur | Port | Description |
|---------|------------------|------|-------------|
| Tor | tor-proxy | 9050 | Proxy SOCKS |
| Bitcoin | bitcoin-signet | 8332 | Nœud Bitcoin Signet |
| BlindBit | blindbit-oracle | 8000 | Oracle BlindBit |
| SDK Storage | sdk_storage | 8081 | Stockage SDK |
| SDK Relay | sdk_relay | 8090-8091 | Relay WebSocket |
| SDK Signer | sdk_signer | 3001 | Service de signature |
| LeCoffre Backend | lecoffre-back | 8080 | API Backend |
| LeCoffre Frontend | lecoffre-front | 3000 | Interface utilisateur |
| IHM Client | ihm_client | 3003 | Client IHM |
| Grafana | grafana | 3005 | Dashboard |
| Loki | loki | 3100 | Agrégation de logs (config: 0.0.0.0) |
| Promtail | promtail | 9080 | Collection de logs |
| Status API | status-api | 3006 | API de statut |
## Codes de Statut
### Symboles
- `✓` : Service prêt et fonctionnel
- `⚠` : Service en cours de traitement
- `⏳` : Service en cours de démarrage
- `✗` : Service arrêté ou en erreur
- `ℹ` : Service en cours d'exécution
### États de Healthcheck
- `healthy` : Service prêt
- `unhealthy` : Service en cours de traitement
- `starting` : Service en cours de démarrage
- `no-healthcheck` : Pas de healthcheck défini
## Progression des Services
### Bitcoin IBD
- **Message** : `Bitcoin IBD: 34729/136548 blocks (101819 remaining) - 25%`
- **Condition de santé** : `blocks == headers && blocks > 0`
- **Temps estimé** : Variable selon la vitesse de téléchargement
### BlindBit Oracle
- **États** : Starting → Scanning → Ready
- **Codes HTTP** : 000 (non prêt), 404 (scan), 200 (prêt)
- **Message de santé** : `BlindBit ready: Oracle service responding`
### SDK Relay
- **Dépendance** : Bitcoin synchronisé
- **États** : IBD → WebSocket Ready
- **Message de santé** : `SDK Relay ready: WebSocket server responding`
## Architecture de Déploiement par Phases
### **Phase 1: Services de Base (Parallèle)**
1. **Tor** → 2. **SDK Storage** → 3. **SDK Signer** → 4. **Status API**
### **Phase 2: Services Blockchain (Séquentiel)**
5. **Bitcoin** → 6. **BlindBit** → 7. **SDK Relay**
### **Phase 3: Services Applicatifs (Séquentiel)**
8. **LeCoffre Backend** → 9. **LeCoffre Frontend** → 10. **IHM Client**
### **Phase 4: Services de Monitoring (Séquentiel, Indépendant)**
11. **Loki** → 12. **Promtail** → 13. **Grafana**
### **Phase 5: Services Utilitaires**
14. **Watchtower**
### **Scripts par Phase**
- **Phases 1, 2, 3, 5** : `./scripts/start-with-progress.sh`
- **Phase 4** : `./scripts/start-monitoring.sh`
## URLs de Test
### Services Locaux
- Bitcoin RPC : `http://localhost:8332`
- BlindBit : `http://localhost:8000`
- SDK Storage : `http://localhost:8081`
- SDK Relay : `http://localhost:8091`
- SDK Signer : `http://localhost:3001`
- IHM Client : `http://localhost:3003`
- Grafana : `http://localhost:3005`
- Loki : `http://localhost:3100`
- Status API : `http://localhost:3006`
### Services Externes
- Page de statut : `https://dev4.4nkweb.com/status/`
- API de statut : `https://dev4.4nkweb.com/status/api`
- Grafana : `https://dev4.4nkweb.com/grafana/`
- IHM Client : `https://dev4.4nkweb.com/`
- Application LeCoffre : `https://dev4.4nkweb.com/lecoffre/`
- WebSocket Relay : `https://dev4.4nkweb.com/ws/`
## Dépannage Rapide
### Service en État "unhealthy"
```bash
# Vérifier les logs
docker logs <service> --tail 50
# Vérifier le healthcheck
docker inspect --format='{{.State.Health.Status}}' <service>
```
### Progression Bitcoin Bloquée
```bash
# Vérifier la connectivité
docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo
# Vérifier les logs
docker logs bitcoin-signet --tail 20
```
### Services en Attente
```bash
# Vérifier les dépendances
docker compose --env-file .env.master ps
# Vérifier les logs des services de dépendance
docker logs <service-dependance> --tail 20
```
### Erreurs de Connexion
```bash
# Vérifier la connectivité réseau
docker network ls
docker network inspect lecoffre_node_btcnet
# Vérifier les ports
netstat -tlnp | grep <port>
```
## Variables d'Environnement Importantes
### Fichier .env.master
- `SDK_RELAY_*` : Configuration du service relay
- `SIGNER_*` : Configuration du service signer
- `VITE_*` : Configuration des applications frontend
- `IDNOT_*` : Configuration des APIs notaires
- `STRIPE_*` : Configuration des paiements
- `MAILCHIMP_*` : Configuration des emails
- `OVH_*` : Configuration des SMS
### Utilisation
```bash
# Toujours utiliser le fichier .env.master
docker compose --env-file .env.master up -d
```
## Scripts de Monitoring
### monitor-progress.sh
- Aperçu complet de tous les services
- Progression Bitcoin avec pourcentage
- Statut des services avec codes couleur
- Progression BlindBit et SDK Relay
### watch-progress.sh
- Surveillance en temps réel
- Mise à jour automatique toutes les 10 secondes
- Barre de progression Bitcoin
- Services en attente de dépendances
### logs-with-progress.sh
- Logs avec informations de progression
- Support de tous les services
- Options de personnalisation
- Suivi en temps réel
### start-with-progress.sh
- Démarrage ordonné des services
- Attente de la santé de chaque service
- Affichage de la progression
- Test de l'accès externe
## Bonnes Pratiques
1. **Utiliser les scripts** plutôt que les commandes Docker directes
2. **Surveiller la progression** pendant les déploiements
3. **Vérifier les dépendances** avant de démarrer les services
4. **Consulter les logs** en cas de problème
5. **Utiliser les variables centralisées** du fichier `.env.master`
6. **Tester l'accès externe** après le déploiement
7. **Vérifier la santé des services** régulièrement
## Exemples d'Utilisation
### Démarrage Complet
```bash
# Arrêter tous les services
docker compose --env-file .env.master down
# Démarrer avec suivi de progression
./scripts/start-with-progress.sh
```
### Surveillance Continue
```bash
# Démarrer la surveillance en temps réel
./scripts/watch-progress.sh
# Dans un autre terminal, afficher les logs
./scripts/logs-with-progress.sh bitcoin -p -f
```
### Vérification Rapide
```bash
# Aperçu rapide de tous les services
./scripts/monitor-progress.sh
# Logs récents avec progression
./scripts/logs-with-progress.sh sdk_relay -p -n 20
```
Ce guide de référence rapide permet aux agents IA d'utiliser efficacement le système de monitoring et de progression du déploiement LeCoffre Node.

304
IA_agents/scripts-advanced.md Normal file
View File

@ -0,0 +1,304 @@
# Scripts Avancés LeCoffre Node
## 🚀 Vue d'ensemble
LeCoffre Node dispose maintenant d'un ensemble complet de scripts pour la gestion, le monitoring et la maintenance de l'architecture complète.
## 📋 Scripts Principaux
### `start.sh` - Démarrage Séquentiel Intelligent
**Fonctionnalités** :
- Démarrage des services dans l'ordre logique optimal
- Affichage de la progression détaillée en temps réel
- Compatibilité complète avec Bitcoin Signet
- Gestion des timeouts adaptatifs
- Monitoring des healthchecks intégrés
**Utilisation** :
```bash
./scripts/start.sh
```
**Progression affichée** :
- Tor Bootstrap (0-100%)
- Bitcoin IBD (blocs synchronisés, pourcentage de vérification)
- BlindBit Oracle (scan des blocs, tweaks détectés)
- SDK Relay (synchronisation, connexions WebSocket)
- SDK Signer (état de connexion, clés disponibles)
- URLs publiques (accessibilité HTTPS/WebSocket)
### `validate-deployment.sh` - Validation Complète
**Fonctionnalités** :
- Vérification des volumes Docker (persistance des données)
- Validation des services et healthchecks
- Tests des URLs publiques et WebSockets
- Vérification des scripts et permissions
- Rapport détaillé avec compteurs
**Utilisation** :
```bash
./scripts/validate-deployment.sh
```
**Vérifications effectuées** :
- ✅ Volumes Docker (Bitcoin, BlindBit, SDK Storage, SDK Signer, Grafana, Loki)
- ✅ Services (Tor, Bitcoin, BlindBit, SDK Relay, SDK Signer, LeCoffre, IHM, Grafana)
- ✅ URLs publiques (Status, Grafana, Main Site, LeCoffre App)
- ✅ WebSockets (Bootstrap Relay, Signer Service)
- ✅ Scripts (disponibilité et permissions)
### `maintenance.sh` - Menu Interactif
**Fonctionnalités** :
- Menu interactif pour toutes les tâches de maintenance
- Validation complète du déploiement
- Sauvegarde et restauration des données
- Nettoyage des logs et images Docker
- Vérification de l'espace disque
- Redémarrage et mise à jour des services
**Utilisation** :
```bash
./scripts/maintenance.sh
```
**Options disponibles** :
1. Validation complète du déploiement
2. Sauvegarde des données
3. Nettoyage des logs anciens
4. Nettoyage des images Docker inutilisées
5. Vérification de l'espace disque
6. Redémarrage des services
7. Mise à jour des images
8. Collecte des logs
9. Vérification de la santé des services
## 🛡️ Protection des Données
### `backup-data.sh` - Sauvegarde Automatique
**Fonctionnalités** :
- Sauvegarde de tous les volumes Docker critiques
- Création d'archives compressées avec timestamps
- Gestion des permissions et erreurs
- Support des volumes Bitcoin, BlindBit, SDK Storage, SDK Signer
**Utilisation** :
```bash
./scripts/backup-data.sh
```
**Volumes sauvegardés** :
- `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_signer_data` : Données SDK Signer
- `4nk_node_sdk_storage_data` : Données SDK Storage
- `4nk_node_grafana_data` : Données Grafana
- `4nk_node_loki_data` : Données Loki
### `restore-data.sh` - Restauration
**Fonctionnalités** :
- Restauration depuis une sauvegarde spécifiée
- Arrêt sécurisé des services avant restauration
- Remplacement complet des données existantes
- Gestion des permissions et erreurs
**Utilisation** :
```bash
./scripts/restore-data.sh <backup_file.tar.gz>
```
### `update-images.sh` - Mise à Jour Sécurisée
**Fonctionnalités** :
- Sauvegarde automatique avant mise à jour
- Téléchargement des nouvelles images Docker
- Redémarrage des services avec les nouvelles images
- Protection complète des données
**Utilisation** :
```bash
./scripts/update-images.sh
```
## 📊 Monitoring et Logs
### `collect-logs.sh` - Collecte des Logs
**Fonctionnalités** :
- Collecte automatique ou par service spécifique
- Organisation par répertoires avec timestamps
- Support de tous les services LeCoffre Node
**Utilisation** :
```bash
# Tous les services
./scripts/collect-logs.sh
# Service spécifique
./scripts/collect-logs.sh bitcoin-signet
```
**Services supportés** :
- Tor Proxy, Bitcoin Signet, BlindBit Oracle
- SDK Relay, SDK Signer, SDK Storage
- LeCoffre Backend, LeCoffre Frontend, IHM Client
- Grafana, Loki, Promtail, Status API, Signet Miner
### `test-monitoring.sh` - Tests de Monitoring
**Fonctionnalités** :
- Vérification des services Grafana, Loki, Promtail
- Tests de connectivité et API
- Validation des dashboards
### `test-dashboards.sh` - Tests des Dashboards
**Fonctionnalités** :
- Vérification des dashboards Grafana
- Tests des sources de données
- Validation des métriques
## 🔧 Scripts de Configuration
### `sync-configs.sh` - Synchronisation
**Fonctionnalités** :
- Copie des configurations vers les conteneurs
- Mise à jour des paramètres
- Redémarrage des services
### `sync-monitoring-config.sh` - Configuration Monitoring
**Fonctionnalités** :
- Configuration Grafana
- Configuration Loki/Promtail
- Déploiement des dashboards
### `setup-logs.sh` - Configuration des Logs
**Fonctionnalités** :
- Création des répertoires de logs
- Configuration des permissions
- Setup des rotations
## 🛠️ Scripts de Maintenance
### `fix_relay_funds.sh` - Correction des Fonds
**Fonctionnalités** :
- Vérification des fonds du relay
- Correction des problèmes
- Tests de connectivité
### `optimize-relay-startup.sh` - Optimisation Relay
**Fonctionnalités** :
- Optimisation des paramètres
- Amélioration des performances
- Tests de stabilité
### `verify_mining_fix.sh` - Vérification Minage
**Fonctionnalités** :
- Tests du minage Signet
- Vérification des blocs
- Validation des transactions
## 🔒 Scripts de Sécurité
### `generate-ssl-certs.sh` - Certificats SSL
**Fonctionnalités** :
- Création des certificats
- Configuration HTTPS
- Sécurisation des communications
### `uninstall-host-nginx.sh` - Désinstallation Nginx
**Fonctionnalités** :
- Nettoyage de Nginx
- Suppression des configurations
- Libération des ports
## 📁 Structure des Volumes
Les données sont persistées dans les volumes Docker suivants :
| Volume | Service | Description |
|--------|---------|-------------|
| `4nk_node_bitcoin_data` | Bitcoin Signet | Blockchain, wallet, configuration |
| `4nk_node_blindbit_data` | BlindBit Oracle | Cache des scans, tweaks détectés |
| `4nk_node_sdk_data` | SDK Relay | Messages, transactions, cache |
| `4nk_node_sdk_signer_data` | SDK Signer | Clés privées, signatures, profils |
| `4nk_node_sdk_storage_data` | SDK Storage | Données temporaires, cache |
| `4nk_node_grafana_data` | Grafana | Dashboards, configurations, utilisateurs |
| `4nk_node_loki_data` | Loki | Logs centralisés, index |
## 🔄 Workflows Recommandés
### Déploiement Initial
```bash
# 1. Démarrage complet
./scripts/start.sh
# 2. Validation
./scripts/validate-deployment.sh
# 3. Tests de monitoring
./scripts/test-monitoring.sh
```
### Maintenance Régulière
```bash
# 1. Menu de maintenance
./scripts/maintenance.sh
# 2. Sauvegarde manuelle si nécessaire
./scripts/backup-data.sh
# 3. Collecte des logs
./scripts/collect-logs.sh
```
### Mise à Jour
```bash
# 1. Mise à jour sécurisée (sauvegarde automatique)
./scripts/update-images.sh
# 2. Validation post-mise à jour
./scripts/validate-deployment.sh
```
### Récupération d'Urgence
```bash
# 1. Arrêt des services
docker compose down
# 2. Restauration
./scripts/restore-data.sh <backup_file>
# 3. Redémarrage
./scripts/start.sh
```
## ⚠️ Notes Importantes
- **Persistance des données** : Tous les scripts préservent les données importantes
- **Sauvegardes automatiques** : Les mises à jour incluent une sauvegarde automatique
- **Bitcoin Signet** : Tous les scripts sont compatibles avec le réseau de test
- **Volumes Docker** : Garantissent la persistance des données entre redémarrages
- **Monitoring intégré** : Healthchecks et progression en temps réel
- **Sécurité** : Aucune clé privée ou secret n'est exposé dans les scripts
## 📝 Logs et Debugging
- **Logs des services** : `./logs/<service>/`
- **Collecte des logs** : `./scripts/collect-logs.sh`
- **Monitoring** : Grafana sur port 3005
- **Status API** : Port 3006
- **Validation** : `./scripts/validate-deployment.sh`

9
IA_agents/todo.md
View File

@ -1,5 +1,14 @@
# TODO - Améliorations et optimisations LeCoffre
### Validation des builds CI
- [ ] Vérifier le succès des builds CI pour tous les services
- [ ] Tester le déploiement des nouvelles images optimisées
- [ ] Valider le fonctionnement des services avec les nouvelles images
- [ ] Vérifier que les dashboards Grafana fonctionnent correctement
## 📋 Tâches à faire
### Monitoring et observabilité
- [ ] Mettre en place des alertes sur la taille des images Docker
- [ ] Créer des métriques de performance des builds CI

372
IA_agents/troubleshooting-monitoring.md Normal file
View File

@ -0,0 +1,372 @@
# Guide de Dépannage - Monitoring LeCoffre Node
## Problèmes Courants et Solutions
### 1. Services en État "unhealthy"
#### Symptômes
- Service affiché comme "unhealthy" dans `docker compose ps`
- Healthcheck échoue constamment
- Service ne répond pas aux requêtes
#### Diagnostic
```bash
# Vérifier le statut du healthcheck
docker inspect --format='{{.State.Health.Status}}' <service>
# Vérifier les logs du healthcheck
docker inspect --format='{{range .State.Health.Log}}{{.Output}}{{end}}' <service>
# Vérifier les logs du service
docker logs <service> --tail 50
```
#### Solutions
1. **Vérifier la connectivité réseau**
```bash
# Vérifier que le service écoute sur le bon port
docker exec <service> netstat -tlnp
# Vérifier la connectivité depuis l'extérieur
curl -f http://localhost:<port>/health
```
2. **Vérifier les dépendances**
```bash
# Vérifier que les services de dépendance sont "healthy"
docker compose --env-file .env.master ps
```
3. **Redémarrer le service**
```bash
docker compose --env-file .env.master restart <service>
```
### 2. Progression Bitcoin Bloquée
#### Symptômes
- Bitcoin IBD reste à un pourcentage fixe
- Pas de nouveaux blocs téléchargés
- Messages d'erreur dans les logs
#### Diagnostic
```bash
# Vérifier l'état de la blockchain
docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getblockchaininfo
# Vérifier les connexions
docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getpeerinfo
# Vérifier les logs
docker logs bitcoin-signet --tail 100 | grep -E "(ERROR|error|Error|WARN|warn|Warn)"
```
#### Solutions
1. **Vérifier la connectivité réseau**
```bash
# Vérifier que Tor fonctionne
docker logs tor-proxy --tail 20
# Vérifier la connectivité Bitcoin
docker exec bitcoin-signet bitcoin-cli -conf=/etc/bitcoin/bitcoin.conf getnetworkinfo
```
2. **Vérifier l'espace disque**
```bash
# Vérifier l'espace disponible
df -h
# Vérifier la taille du volume Bitcoin
docker volume inspect 4nk_node_bitcoin_data
```
3. **Redémarrer Bitcoin**
```bash
docker compose --env-file .env.master restart bitcoin
```
### 3. Services en Attente de Dépendances
#### Symptômes
- Services affichés comme "Stopped"
- Messages "dependency failed to start"
- Services ne démarrent pas
#### Diagnostic
```bash
# Vérifier les dépendances dans docker-compose.yml
grep -A 5 -B 5 "depends_on" docker-compose.yml
# Vérifier le statut des services de dépendance
docker compose --env-file .env.master ps
```
#### Solutions
1. **Démarrer les services dans l'ordre correct**
```bash
# Utiliser le script de démarrage ordonné
./scripts/start-with-progress.sh
```
2. **Vérifier les conditions de dépendance**
```bash
# Vérifier que les services de dépendance sont "healthy"
docker inspect --format='{{.State.Health.Status}}' <service-dependance>
```
3. **Modifier temporairement les dépendances**
```bash
# Changer condition: service_healthy en condition: service_started
# (Attention : à remettre en place après résolution)
```
### 4. Erreurs de Connexion WebSocket
#### Symptômes
- SDK Relay ne répond pas sur le port 8091
- Erreurs 502 Bad Gateway pour les WebSockets
- Messages "TLS support not compiled in"
#### Diagnostic
```bash
# Vérifier que le service écoute sur le bon port
docker exec sdk_relay netstat -tlnp
# Vérifier les logs du service
docker logs sdk_relay --tail 50
# Tester la connectivité locale
curl -f http://localhost:8091/
```
#### Solutions
1. **Vérifier la configuration Nginx**
```bash
# Vérifier la configuration WebSocket
sudo grep -A 10 -B 5 "ws/" /etc/nginx/sites-enabled/dev4.4nkweb.com-https.conf
# Tester la configuration Nginx
sudo nginx -t
```
2. **Vérifier les variables d'environnement**
```bash
# Vérifier la configuration du SDK Relay
docker exec sdk_relay env | grep SDK_RELAY
```
3. **Redémarrer le service**
```bash
docker compose --env-file .env.master restart sdk_relay
```
### 5. Problèmes de Permissions
#### Symptômes
- Erreurs "Permission denied"
- Services ne peuvent pas écrire dans les volumes
- Erreurs de montage de volumes
#### Diagnostic
```bash
# Vérifier les permissions des volumes
docker volume inspect <volume-name>
# Vérifier les permissions des dossiers locaux
ls -la logs/
ls -la conf/
```
#### Solutions
1. **Corriger les permissions des volumes**
```bash
# Corriger les permissions des logs
sudo chown -R 1000:1000 logs/
sudo chmod -R 755 logs/
```
2. **Vérifier la configuration des volumes**
```bash
# Vérifier la configuration dans docker-compose.yml
grep -A 5 -B 5 "volumes:" docker-compose.yml
```
3. **Redémarrer les services**
```bash
docker compose --env-file .env.master down
docker compose --env-file .env.master up -d
```
### 6. Problèmes de Configuration
#### Symptômes
- Services ne démarrent pas
- Erreurs de configuration dans les logs
- Variables d'environnement manquantes
#### Diagnostic
```bash
# Vérifier la configuration Docker Compose
docker compose --env-file .env.master config
# Vérifier les variables d'environnement
docker exec <service> env | grep <VARIABLE>
# Vérifier les fichiers de configuration
cat .env.master | grep <VARIABLE>
```
#### Solutions
1. **Vérifier le fichier .env.master**
```bash
# Vérifier que toutes les variables sont définies
docker compose --env-file .env.master config --services
```
2. **Corriger les variables manquantes**
```bash
# Ajouter les variables manquantes dans .env.master
echo "VARIABLE=valeur" >> .env.master
```
3. **Redémarrer les services**
```bash
docker compose --env-file .env.master down
docker compose --env-file .env.master up -d
```
## Outils de Diagnostic
### Scripts de Diagnostic
```bash
# Diagnostic complet
./scripts/monitor-progress.sh
# Logs avec progression
./scripts/logs-with-progress.sh <service> -p -n 100
# Surveillance en temps réel
./scripts/watch-progress.sh
```
### Commandes Docker Utiles
```bash
# Informations détaillées sur un service
docker inspect <service>
# Logs en temps réel
docker logs -f <service>
# Exécuter une commande dans un conteneur
docker exec -it <service> /bin/bash
# Vérifier l'utilisation des ressources
docker stats <service>
```
### Commandes Système
```bash
# Vérifier l'espace disque
df -h
# Vérifier la mémoire
free -h
# Vérifier les processus
ps aux | grep docker
# Vérifier les ports
netstat -tlnp | grep <port>
```
## Procédures de Récupération
### Récupération Complète
```bash
# Arrêter tous les services
docker compose --env-file .env.master down
# Nettoyer le système Docker
docker system prune -af --volumes
# Redémarrer avec le script de progression
./scripts/start-with-progress.sh
```
### Récupération d'un Service
```bash
# Arrêter le service
docker compose --env-file .env.master stop <service>
# Supprimer le conteneur
docker compose --env-file .env.master rm <service>
# Redémarrer le service
docker compose --env-file .env.master up -d <service>
```
### Récupération des Volumes
```bash
# Arrêter tous les services
docker compose --env-file .env.master down
# Supprimer les volumes
docker volume rm <volume-name>
# Redémarrer les services
docker compose --env-file .env.master up -d
```
## Logs et Monitoring
### Logs Importants
```bash
# Logs Bitcoin
docker logs bitcoin-signet --tail 100
# Logs SDK Relay
docker logs sdk_relay --tail 100
# Logs BlindBit
docker logs blindbit-oracle --tail 100
# Logs Nginx
sudo tail -f /var/log/nginx/error.log
```
### Monitoring des Ressources
```bash
# Utilisation des ressources
docker stats
# Espace disque
df -h
# Mémoire
free -h
# CPU
top
```
## Prévention des Problèmes
### Vérifications Régulières
1. **Vérifier l'espace disque** : `df -h`
2. **Vérifier la mémoire** : `free -h`
3. **Vérifier les logs** : `./scripts/monitor-progress.sh`
4. **Vérifier la connectivité** : Tester les URLs externes
### Maintenance Préventive
1. **Nettoyer les logs** : `docker system prune -f`
2. **Vérifier les mises à jour** : `docker images`
3. **Sauvegarder les configurations** : Copier `.env.master`
4. **Tester les sauvegardes** : Vérifier les volumes
### Surveillance Continue
1. **Utiliser les scripts de monitoring** : `./scripts/watch-progress.sh`
2. **Configurer des alertes** : Surveiller les logs d'erreur
3. **Vérifier les performances** : `docker stats`
4. **Tester la connectivité** : Vérifier les URLs externes
Ce guide de dépannage permet aux agents IA de diagnostiquer et résoudre rapidement les problèmes courants du système de monitoring LeCoffre Node.

19
LICENSE
View File

@ -1,19 +0,0 @@
MIT License
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

90
README.md
View File

@ -9,11 +9,13 @@ Environnement de développement centralisé pour tous les dépôts 4NK et le pro
4NK_env/ # Environnement de développement 4NK + Agents IA
├── lecoffre_node/ # Orchestrateur principal LeCoffre (Nginx intégré)
├── sdk_relay/ # Service de relais WebSocket 4NK
├── sdk_signer/ # Service de signature 4NK
├── sdk_storage/ # Service de stockage 4NK
├── sdk_client/ # Client SDK 4NK
├── sdk_common/ # Composants communs 4NK
├── sdk-signer-client/ # Client signeur 4NK
├── ihm_client/ # Interface utilisateur LeCoffre
├── lecoffre-back-mini/ # API Backend LeCoffre
├── lecoffre-front/ # Frontend Next.js LeCoffre
├── doc_api/ # Documentation API 4NK
├── IA_agents/ # 🧠 Agents IA - Contexte et outillage complet
@ -21,7 +23,7 @@ Environnement de développement centralisé pour tous les dépôts 4NK et le pro
│ ├── deploy.md # Procédures de déploiement
│ ├── flux.md # Architecture des flux
│ └── todo.md # Liste des tâches et améliorations
└── scripts/ # Scripts de gestion et déploiement (centralisés)
└── scripts/ # Scripts de gestion et déploiement
├── clone-all-repos.sh # Clonage de tous les dépôts 4NK
├── init-4nk-env-repo.sh # Initialisation du dépôt 4NK_env
├── check-repos-status.sh # Vérification du statut des dépôts
@ -31,7 +33,7 @@ Environnement de développement centralisé pour tous les dépôts 4NK et le pro
## 🚀 Déploiement
### 1. Clonage de tous les dépôts 4NK (branche ext)
### 1. Clonage de tous les dépôts 4NK (branche int-dev)
```bash
cd /home/debian/4NK_env
./scripts/clone-all-repos.sh
@ -63,7 +65,7 @@ cd lecoffre_node
| **WebSocket** | ws://localhost/ws/ | Communication temps réel |
| **Status Page** | http://localhost/status/ | Tableau de bord |
| **Grafana** | http://localhost/grafana/ | Monitoring |
| **Redirections IdNot** | `<IDNOT_BASE_URL>` | Redirections externes |
| **Redirections IdNot** | http://local.4nkweb.com:3000/ | Redirections externes |
| **HTTPS** | https://localhost/ | Accès sécurisé |
### Ports
@ -75,7 +77,7 @@ cd lecoffre_node
### Environnement de développement avec agents IA
- **Dépôts centralisés** : Tous les projets 4NK et LeCoffre dans un seul environnement
- **Branche unifiée** : `ext` pour tous les dépôts
- **Branche unifiée** : `int-dev` pour tous les dépôts
- **Scripts de gestion** : Automatisation complète du clonage et déploiement
- **Agents IA** : Contexte et outillage complet dans IA_agents/
- **Documentation centralisée** : Toute la documentation technique accessible
@ -94,52 +96,10 @@ cd lecoffre_node
## 📚 Documentation et Agents IA
### Agents IA - Contexte et outillage complet (IA_agents/)
- **AGENTS_SYNTHESIS.md** : **NOUVEAU** - Synthèse complète pour les agents IA
- **README.md** : Documentation principale et règles obligatoires
- **deployment-architecture.md** : Architecture de déploiement par phases
- **best-practices-deployment.md** : Bonnes pratiques et interdictions
- **todo.md** : Liste des tâches et améliorations à suivre
### Documentation Technique (docs/)
- **DEEP_ARCHITECTURE_ANALYSIS.md** : **NOUVEAU** - Analyse architecturale approfondie complète
- **TECHNICAL_REFERENCE.md** : **NOUVEAU** - Référence technique complète
- **DEPLOYMENT_GUIDE.md** : **NOUVEAU** - Guide de déploiement complet
- **DOCUMENTATION_SYNTHESIS.md** : **NOUVEAU** - Synthèse de la documentation
- **ARCHITECTURE_ANALYSIS.md** : Analyse architecturale complète 4NK + LeCoffre
- **context.md** : Contexte général des projets 4NK et LeCoffre
- **context.md** : Contexte général des projets 4NK et LeCoffre pour les agents IA
- **deploy.md** : Procédures de déploiement détaillées
- **flux.md** : Architecture des flux et services
## 🔐 Synchronisation des configurations (Vault)
Les configurations sont synchronisées depuis le dépôt sécurisé du Vault, puis répliquées pour les déploiements.
```bash
# Synchroniser les configurations
bash projects/lecoffre/lecoffre_node/scripts/sync-vault-full.sh
# Résultat attendu
# - Miroir local: vault/confs2/
# - Copie centralisée: confs/
# - Réplication projet: projects/lecoffre/lecoffre_node/confs/
```
Notes:
- Rebuild propre de `vault/sdk-client` avant la synchronisation.
- Fallback automatique sur `vault/confs2/` si le miroir `vault/confs/` est absent.
- Aucun secret n'est committé; toutes les valeurs sensibles restent externalisées.
## 🧹 Standardisation des fichiers ignore
Les fichiers `.gitignore`, `.cursorignore`, `.dockerignore` sont centralisés et propagés.
```bash
# Propager les fichiers ignore
bash projects/lecoffre/lecoffre_node/scripts/sync-ignore-files.sh
# Portée
# - 4NK_modules/* (exclu: 4NK_vault)
# - projects/*/*
```
- **todo.md** : Liste des tâches et améliorations à suivre
### Documentation spécifique
- **lecoffre_node/README-AUTONOMOUS.md** : Architecture autonome LeCoffre
@ -150,22 +110,12 @@ bash projects/lecoffre/lecoffre_node/scripts/sync-ignore-files.sh
### Gestion des dépôts
```bash
./scripts/check-repos-status.sh # Vérifier le statut de tous les dépôts
./scripts/clone-all-repos.sh # Cloner tous les dépôts 4NK (branche ext)
./scripts/clone-all-repos.sh # Cloner tous les dépôts 4NK (branche int-dev)
./scripts/init-4nk-env-repo.sh # Initialiser le dépôt 4NK_env
./scripts/push-to-remote.sh # Pousser vers git.4nkweb.com
./scripts/setup-complete-env.sh # Configuration complète de l'environnement
./scripts/push-commit.sh # Forcer travail sur ext (submodules + racine), commit/push si changements
```
### Centralisation des scripts
- Les scripts des sous‑projets sont centralisés dans `4NK_env/scripts/<projet>/`.
- Les répertoires `scripts/` à la racine des sous‑projets sont désormais des liens symboliques pointant vers ces emplacements centralisés.
- Exemples:
- `lecoffre_node/scripts` → `4NK_env/scripts/lecoffre_node`
Impact:
- Aucun changement pour les commandes existantes (`./scripts/...`) dans les projets: les liens symboliques assurent la compatibilité.
- Référence recommandée dans la documentation: `4NK_env/scripts/<projet>/...`.
## 🔐 Sécurité
- **Fichiers .env** protégés par `.gitignore`
@ -179,7 +129,7 @@ Impact:
- **Base Debian** `bookworm-slim`
- **Packages minimaux** pour la sécurité
- **Utilisateurs non-root** (`appuser`, `lecoffreuser`)
- **Tag unique** : `ext`
- **Tag unique** : `int-dev`
### Architecture
- **Conteneur master** : `lecoffre_node` avec Nginx intégré
@ -204,30 +154,20 @@ Impact:
## 🔄 CI/CD
### Environnement de développement avec agents IA
- **Branche unifiée** : `ext` pour tous les dépôts
- **Branche unifiée** : `int-dev` pour tous les dépôts
- **Dépôt central** : `4NK_env` sur git.4nkweb.com
- **Scripts automatisés** : Clonage et déploiement
- **Agents IA** : Contexte et outillage toujours à jour
### LeCoffre
- **Tag Docker** : `ext`
- **Déclenchement** : Push sur `ext`
- **Tag Docker** : `int-dev`
- **Déclenchement** : Push sur `int-dev`
- **Build** : Automatique via Gitea CI
## 📞 Support
Pour toute question ou problème :
1. Vérifier les logs : `docker logs <container>`
2. Consulter la documentation des agents IA : `4NK_env/IA_agents/`
2. Consulter la documentation des agents IA : `IA_agents/`
3. Vérifier le statut : `./scripts/check-repos-status.sh`
4. Utiliser l'outillage complet : Scripts et documentation centralisés
## 📋 Fichiers centralisés
Les fichiers suivants sont centralisés dans le dépôt principal `4NK_env` :
- `CODE_OF_CONDUCT.md` - Code de conduite
- `CODEOWNERS` - Propriétaires du code
- `CONTRIBUTING.md` - Guide de contribution
- `LICENSE` - Licence du projet
Voir : [`4NK_env/CODE_OF_CONDUCT.md`](../../CODE_OF_CONDUCT.md), [`4NK_env/CODEOWNERS`](../../CODEOWNERS), [`4NK_env/CONTRIBUTING.md`](../../CONTRIBUTING.md), [`4NK_env/LICENSE`](../../LICENSE)

1
doc_api/.ci-trigger Normal file
View File

@ -0,0 +1 @@
# CI Trigger Sun Sep 21 19:58:04 UTC 2025

4
docs/doc_api/.cursorrules → doc_api/.cursorrules
View File

@ -42,7 +42,7 @@
- Externaliser au maximum les variables d’environnement.
- Toujours utiliser une clé SSH pour cloner les dépôts.
- Monter en version les dépôts au début du travail.
- Pousser les tags docker `ext` via la CI sur `git.4nkweb.com`.
- Pousser les tags docker `int-dev` via la CI sur `git.4nkweb.com`.
- Corriger systématiquement les problèmes, sans contournement.
## Scripts (règles critiques)
@ -56,7 +56,7 @@
- Installer en arrière-plan dans les images Docker :
`curl, git, sed, awk, nc, wget, jq, telnet, tee, wscat, ping, npm (dernière version)`
- Appliquer à tous les Dockerfiles et `docker-compose.yml`.
- N'utilise pas les version test ou dev ou ext-dev mais toujours les version ext, relance leur compilation si nécessaire
- N'utilise pas les version test ou dev ou int-dev-dev mais toujours les version int-dev, relance leur compilation si nécessaire
## Fichiers de configuration (règles critiques)
- Vérifier l’écriture effective après chaque modification.

0
docs/doc_api/API Annuaire - Hiérarchies des entités dans le notariat - API Annuaire.pdf → doc_api/API Annuaire - Hiérarchies des entités dans le notariat - API Annuaire.pdf
View File

0
docs/doc_api/API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf → doc_api/API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf
View File

0
docs/doc_api/API Annuaire - Présentation et guide d'intégration.pdf → doc_api/API Annuaire - Présentation et guide d'intégration.pdf
View File

0
docs/doc_api/API Annuaire - V2 - Documentation Utilisateur.pdf → doc_api/API Annuaire - V2 - Documentation Utilisateur.pdf
View File

0
docs/doc_api/ID.NOT - Document d'intégration OpenIDConnect.pdf → doc_api/ID.NOT - Document d'intégration OpenIDConnect.pdf
View File

0
docs/doc_api/ID.NOT - Présentation et guide d'intégration.pdf → doc_api/ID.NOT - Présentation et guide d'intégration.pdf
View File

0
docs/doc_api/Portail des raccordements - Guide de démarrage.pdf → doc_api/Portail des raccordements - Guide de démarrage.pdf
View File

2404
docs/4NK_DAO_TECHNICAL_SPECIFICATION.md
View File

File diff suppressed because it is too large Load Diff

1515
docs/4NK_IDENTITY_AND_PROCESS_SPEC.md
View File

File diff suppressed because it is too large Load Diff

676
docs/4NK_IDENTITY_PROCESS_SUMMARY.md
View File

@ -1,676 +0,0 @@
# Résumé Exécutif : Système d'Identité et Processus 4NK
**Document complet:** [4NK_IDENTITY_AND_PROCESS_SPEC.md](./4NK_IDENTITY_AND_PROCESS_SPEC.md)
**Version:** 1.0
**Date:** 1 octobre 2025
---
## Vue d'ensemble en 5 minutes
### Qu'est-ce que 4NK ?
4NK est un **système décentralisé de gestion de processus collaboratifs** qui utilise Bitcoin comme couche de consensus et les **Silent Payments (BIP352)** comme infrastructure d'identité cryptographique.
### Concepts clés
```
┌─────────────────────────────────────────────────────────────┐
│ SYSTÈME 4NK │
├─────────────────────────────────────────────────────────────┤
│ │
│ IDENTITÉ PROCESSUS RÉSEAU │
│ ┌─────────┐ ┌──────────┐ ┌─────────┐ │
│ │ Device │───────────►│ State │◄─────────┤ Relay │ │
│ │ (SP) │ │ Machine │ │ (WS) │ │
│ └────┬────┘ └────┬─────┘ └─────────┘ │
│ │ │ │
│ ┌────▼────┐ ┌────▼─────┐ │
│ │ Member │ │ Roles │ │
│ │ (Pair) │ │ Rules │ │
│ └─────────┘ └──────────┘ │
│ │
│ BLOCKCHAIN BITCOIN │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ UTXO → OP_RETURN(state_id) → UTXO → OP_RETURN ... │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
---
## 1. Système d'identité
### 1.1 Architecture d'identité à 3 niveaux
| Niveau | Composant | Description | Exemple |
|--------|-----------|-------------|---------|
| 1 | **Device** | Appareil unique avec clés SP | Laptop, smartphone |
| 2 | **Member** | Groupe de devices pairés | Alice (laptop + mobile) |
| 3 | **Process ID** | Identifiant du pairing | OutPoint Bitcoin |
### 1.2 Silent Payments (BIP352)
**Pourquoi Silent Payments ?**
✅ **Adresses réutilisables** sans compromettre la vie privée
✅ **Dérivation cryptographique** de clés publiques
✅ **Interopérabilité** native avec Bitcoin
✅ **Multi-device** via pairing process
**Structure d'un Device:**
```rust
Device {
sp_wallet: SpWallet, // Portefeuille Bitcoin SP
pairing_process_commitment: OutPoint, // ID du processus de pairing
paired_member: Member, // Groupe d'adresses liées
}
```
### 1.3 Pairing multi-device
Le **pairing** permet d'associer plusieurs appareils à une seule identité logique.
**Flux simplifié:**
```
1. Device A crée un processus "pairing"
└─> State: { pairedAddresses: [addr_A] }
2. Device B scanne le QR code
3. Device B propose l'ajout
└─> State: { pairedAddresses: [addr_A, addr_B] }
4. Device A signe (approuve)
5. Commit on-chain
└─> Transaction Bitcoin avec OP_RETURN(state_id)
6. Les deux devices sont pairés
└─> Peuvent signer au nom du Member
```
**Sécurité:**
- **Ajout** : Signature des adresses existantes requise
- **Retrait** : Consensus de tous les devices
- **Oblitération** : Rôle "apophis" (destruction du processus)
---
## 2. Système de processus
### 2.1 Modèle de machine à états
Un **Process** est une succession d'états commitables sur Bitcoin.
```
Process = Vec<ProcessState>
├─ State 0: Empty (initial UTXO)
├─ State 1: Création (données + rôles)
├─ State 2: Update (modification)
├─ ...
└─ State n: Empty (prochain UTXO)
```
**Règle:** Le dernier état est toujours vide, représentant l'UTXO à dépenser.
### 2.2 Structure d'un ProcessState
```rust
ProcessState {
commited_in: OutPoint, // UTXO Bitcoin
pcd_commitment: PcdCommitments, // Merkle tree des données
state_id: [u8; 32], // Merkle root (identifiant)
keys: BTreeMap<String, [u8; 32]>, // Clés de déchiffrement
validation_tokens: Vec<Proof>, // Signatures
public_data: Pcd, // Données publiques
roles: Roles, // Rôles et permissions
}
```
**Caractéristiques:**
- **Immutable** : Une fois committé on-chain, l'état est figé
- **Vérifiable** : Merkle proofs pour chaque champ
- **Cryptographiquement prouvé** : Signatures Schnorr obligatoires
### 2.3 Commitments cryptographiques
```
┌────────────────────────────────┐
│ Données privées (chiffrées) │
│ ┌──────────┬─────────────┐ │
│ │ field1 │ "value1" │ │
│ │ field2 │ "value2" │ │
│ └──────────┴─────────────┘ │
└───────────────┬────────────────┘
│
▼ Hash taggé
┌────────────────────────────────┐
│ PcdCommitments │
│ ┌──────────┬─────────────┐ │
│ │ field1 │ hash1 │ │
│ │ field2 │ hash2 │ │
│ │ roles │ hash_roles │ │
│ └──────────┴─────────────┘ │
└───────────────┬────────────────┘
│
▼ Merkle Tree
┌────────────────────────────────┐
│ state_id (32 bytes) │
│ = Merkle Root │
└───────────────┬────────────────┘
│
▼ OP_RETURN
┌────────────────────────────────┐
│ Blockchain Bitcoin │
│ Transaction avec state_id │
└────────────────────────────────┘
```
**Avantages:**
- Seul le `state_id` est on-chain (32 bytes)
- Données privées restent off-chain (chiffrées)
- Vérification cryptographique possible (Merkle proofs)
---
## 3. Validation et consensus
### 3.1 Système de rôles
```rust
RoleDefinition {
members: Vec<OutPoint>, // Process IDs des membres
validation_rules: Vec<ValidationRule>, // Règles de modification
storages: Vec<String>, // Storages autorisés
}
```
**Exemple:**
```rust
Roles {
"owner": RoleDefinition {
members: [alice_pairing_id],
validation_rules: [
ValidationRule {
quorum: 1.0, // 100% des membres
fields: ["roles"], // Peut modifier les rôles
min_sig_member: 1.0, // Tous les devices
}
],
},
"validator": RoleDefinition {
members: [bob_id, carol_id],
validation_rules: [
ValidationRule {
quorum: 0.67, // 2/3 des membres
fields: ["contract", "amount"],
min_sig_member: 0.5, // 50% des devices
}
],
},
}
```
### 3.2 Processus de validation
```
┌──────────────────────┐
│ Proposition d'état │
└──────────┬───────────┘
│
▼
┌──────────────────────────┐
│ Pour chaque champ modifié│
└──────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ Trouver les rôles applicables│
└──────────┬──────────────────┘
│
▼
┌────────────────────────────────┐
│ Vérifier le quorum │
│ (proportion de membres) │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ Pour chaque membre validant: │
│ Vérifier min_sig_member │
│ (proportion de devices) │
└──────────┬─────────────────────┘
│
▼
┌────────────────────────────────┐
│ Vérifier les signatures Schnorr│
└──────────┬─────────────────────┘
│
▼
✅ VALIDE ou ❌ REJETÉ
```
### 3.3 Signatures cryptographiques
**Type:** Schnorr (BIP340) sur secp256k1
```rust
Proof {
signature: [u8; 64], // Signature Schnorr
public_key: PublicKey, // Clé publique (33 bytes)
message: [u8; 32], // state_id
}
```
**Messages signés:**
- **ValidationYes** : Approbation du state_id
- **ValidationNo** : Rejet du state_id
**Génération:**
```rust
let message_hash = state.get_message_hash(true)?; // true = yes
let proof = Proof::new(message_hash, spend_key);
state.validation_tokens.push(proof);
```
---
## 4. Communication réseau
### 4.1 Architecture réseau
```
┌──────────────┐ WebSocket ┌──────────────┐
│ Client A │◄──────────────────────────►│ sdk_relay │
│ (WASM) │ │ (Rust) │
└──────────────┘ └──────┬───────┘
│
┌──────────────┐ │
│ Client B │◄──────────────────────────────────┤
│ (WASM) │ │
└──────────────┘ │
▼
┌───────────────┐
│ Bitcoin Node │
│ (RPC + ZMQ) │
└───────────────┘
```
### 4.2 Types de messages (AnkFlag)
| Flag | Direction | Description |
|------|-----------|-------------|
| **Handshake** | Relay → Client | Synchronisation initiale (peers, processes) |
| **NewTx** | Relay → Clients | Transaction Bitcoin détectée |
| **Commit** | Client ↔ Relay | Demande/validation de commit on-chain |
| **Cipher** | Client ↔ Clients | Données chiffrées (via relay) |
| **Faucet** | Client → Relay | Demande de fonds (testnet) |
| **Sync** | Client ↔ Relay | Synchronisation d'état |
### 4.3 Flux de commit
```
Client A Relay Client B
│ │ │
│ 1. CommitMessage │ │
│ (validation_tokens=[]) │
├─────────────────────►│ │
│ │ 2. Broadcast │
│ ├───────────────────►│
│ │ │
│ │ 3. Signature │
│ │◄───────────────────┤
│ │ │
│ 4. CommitMessage │ │
│ (validation_tokens= │ │
│ [proof_A, proof_B]) │
├─────────────────────►│ │
│ │ 5. Validation │
│ │ is_valid() │
│ │ │
│ │ 6. Tx Bitcoin │
│ │ (broadcast) │
│ │ │
│ 7. Confirmation │ 7. Confirmation │
│◄─────────────────────┼───────────────────►│
```
---
## 5. Stockage et persistance
### 5.1 Niveaux de stockage
| Couche | Type | Données | Chiffrement |
|--------|------|---------|-------------|
| **Blockchain** | Public | state_id (32 bytes) | ❌ Non |
| **sdk_storage** | Semi-privé | Données volumineuses | ✅ AES-256-GCM |
| **Local** | Privé | Wallet, clés | ✅ Device-local |
### 5.2 Format PCD (Private Collaborative Data)
```
┌─────────────────────────┐
│ Version: 0x01 │
├─────────────────────────┤
│ DataType: │
│ 0 = FileBlob │
│ 1 = JSON │
├─────────────────────────┤
│ Data (compressed zstd) │
└─────────────────────────┘
```
**Utilisation:**
```rust
// Insertion
let mut pcd = Pcd::new(BTreeMap::new());
pcd.insert_serializable("profile", &json!({"name": "Alice"}))?;
// Récupération
let profile: Value = pcd.get_as_json("profile")?;
```
### 5.3 Chiffrement
**Algorithme:** AES-256-GCM (AEAD)
```rust
// Génération clé
let key = Aes256Gcm::generate_key(&mut rng);
// Chiffrement
let cipher = Aes256Gcm::new(&key);
let nonce = Aes256Gcm::generate_nonce(&mut rng);
let ciphertext = cipher.encrypt(&nonce, plaintext)?;
// Stockage clé dans ProcessState
state.keys.insert("field_name", key.as_slice().try_into()?);
```
---
## 6. Sécurité
### 6.1 Garanties cryptographiques
| Menace | Protection | Mécanisme |
|--------|------------|-----------|
| **Usurpation d'identité** | ✅ | Signatures Schnorr obligatoires |
| **Modification non autorisée** | ✅ | Validation multi-signatures + quorum |
| **Replay attacks** | ✅ | state_id unique (inclut outpoint) |
| **Man-in-the-middle** | ✅ | Messages signés cryptographiquement |
| **Observation réseau** | ✅ | Chiffrement AES-256-GCM |
| **Perte d'un device** | ✅ | Multi-device pairing |
### 6.2 Modèle de confiance
**Ce qui est vérifié cryptographiquement:**
- ✅ Identité des signataires (Silent Payment addresses)
- ✅ Intégrité des données (Merkle commitments)
- ✅ Ordre des états (chaîne UTXO Bitcoin)
- ✅ Consensus (validation multi-signatures)
**Ce qui nécessite de la confiance:**
- ⚠️ sdk_relay (peut censurer, pas falsifier)
- ⚠️ sdk_storage (peut refuser de servir, pas modifier)
- ⚠️ Blindbit (optimisation, pas sécurité critique)
**Aucune confiance requise:**
- ✅ Bitcoin Core node (vérification SPV possible)
- ✅ Autres participants (signatures vérifiables)
### 6.3 Bonnes pratiques
#### Configuration des rôles:
```rust
// ✅ BON: Quorum élevé pour actions critiques
ValidationRule::new(0.67, vec!["roles"], 1.0) // 2/3 consensus
// ❌ MAUVAIS: Quorum trop faible
ValidationRule::new(0.1, vec!["roles"], 0.1) // 10% seulement
```
#### Pairing:
```rust
// ✅ BON: Au moins 2 devices
Member::new(vec![device1_addr, device2_addr])
// ⚠️ RISQUÉ: Un seul device (perte = perte d'accès)
Member::new(vec![device1_addr])
```
#### Chiffrement:
```rust
// ✅ BON: Données sensibles dans PCD privé
let private_data = json!({ "ssn": "123-45-6789" });
// ❌ MAUVAIS: Données sensibles en public
let public_data = json!({ "ssn": "123-45-6789" }); // Visible par tous!
```
---
## 7. Cas d'usage
### 7.1 Gestion de contrats
**Scénario:** Contrat de prestation entre une entreprise (3 signataires) et un client.
**Rôles:**
- **Owner** : Entreprise (quorum 67%)
- **Validator** : Service juridique (quorum 100%)
- **Client** : Lecture + signature (quorum 100%)
**Flux:**
1. Owner crée le processus avec le contrat
2. Validator valide le contrat
3. Client signe le contrat
4. Commit on-chain (preuve horodatée immuable)
### 7.2 Signature électronique
**Scénario:** Signature de documents par plusieurs parties.
**Avantages 4NK:**
- ✅ Horodatage Bitcoin (immuable)
- ✅ Multi-signatures cryptographiques
- ✅ Traçabilité complète (audit trail)
- ✅ Documents chiffrés (confidentialité)
### 7.3 Identité décentralisée
**Scénario:** Gestion d'identité multi-device avec révocation.
**Fonctionnalités:**
- Pairing/unpairing de devices
- Attestations cryptographiques (signatures)
- Révocation d'attestations (oblitération)
- Portabilité (export/import du wallet)
### 7.4 Workflow d'approbation
**Scénario:** Processus d'approbation de dépenses dans une entreprise.
**Rôles:**
- **Demandeur** : Crée la demande
- **Manager** : Valide < 1000€
- **Directeur** : Valide ≥ 1000€
- **Comptable** : Enregistre le paiement
**Règles:**
```rust
ValidationRule::new(
1.0, // 100% consensus
vec!["amount", "beneficiary"], // Champs concernés
0.5 // 50% des devices du membre
)
```
---
## 8. Architecture technique
### 8.1 Stack technologique
| Composant | Technologie | Rôle |
|-----------|-------------|------|
| **sdk_common** | Rust (WASM-ready) | Types partagés, logique métier |
| **sdk_client** | Rust → WASM | Bibliothèque cliente pour navigateurs |
| **sdk_relay** | Rust + Tokio + Tungstenite | Relais WebSocket |
| **sdk_storage** | Rust + Actix-web | Stockage clé-valeur HTTP |
| **ihm_client** | TypeScript + Web Components | Interface utilisateur |
| **Bitcoin Core** | C++ | Node Bitcoin (RPC + ZMQ) |
| **Blindbit** | Rust | Filtres BIP158 (optimisation scanning) |
### 8.2 Dépendances clés
```toml
[dependencies]
sp_client = "0.2" # Silent Payments
bitcoin = "0.30" # Bitcoin primitives
secp256k1 = "0.27" # Cryptographie EC
tokio-tungstenite = "0.20" # WebSocket async
serde = "1.0" # Sérialisation
zstd = "0.12" # Compression
aes-gcm = "0.10" # Chiffrement
rs-merkle = "1.4" # Merkle trees
```
### 8.3 Flux de compilation
```
┌──────────────┐
│ Rust Code │
│ (sdk_client) │
└──────┬───────┘
│
▼ wasm-pack build --target web
┌──────────────────────┐
│ WebAssembly Module │
│ + JS Bindings │
└──────┬───────────────┘
│
▼ npm install
┌──────────────────────┐
│ ihm_client │
│ (TypeScript) │
└──────────────────────┘
```
---
## 9. Métriques de performance
### 9.1 Taille des données
| Élément | Taille | Localisation |
|---------|--------|--------------|
| **state_id** | 32 bytes | On-chain (OP_RETURN) |
| **Signature Schnorr** | 64 bytes | Off-chain (validation_tokens) |
| **ProcessState sérialisé** | ~500 bytes - 50 KB | Off-chain (sdk_storage) |
| **Transaction Bitcoin** | ~250 bytes | On-chain |
### 9.2 Coûts Bitcoin
| Opération | Coût (testnet) | Coût (mainnet) |
|-----------|----------------|----------------|
| **Création Process** | ~2500 sats | Variable (frais réseau) |
| **Update Process** | ~2500 sats | Variable (frais réseau) |
| **Oblitération** | ~2500 sats | Variable (frais réseau) |
**Note:** Frais mainnet dépendent du feerate (sat/vB).
### 9.3 Latence réseau
| Opération | Latence typique |
|-----------|-----------------|
| **Connexion WebSocket** | < 100 ms |
| **Handshake** | < 500 ms |
| **Commit proposal** | < 200 ms |
| **Accumulation signatures** | 1-5 secondes |
| **Broadcast Bitcoin** | < 1 seconde |
| **Confirmation on-chain** | 10 minutes (1 bloc) |
---
## 10. Roadmap et évolutions futures
### 10.1 Court terme (Q4 2025)
- ✅ Optimisation scanning Silent Payments (Blindbit v2)
- ✅ Multi-relays (connexions simultanées)
- ✅ Rate limiting sur sdk_relay
- ✅ Hardware wallet support (Ledger, Trezor)
### 10.2 Moyen terme (2026)
- 🔄 Gossip protocol P2P (résilience réseau)
- 🔄 Recovery social (M-of-N recovery)
- 🔄 Taproot multi-signatures (MuSig2)
- 🔄 Lightning Network integration
### 10.3 Long terme (2027+)
- 🚀 Zero-knowledge proofs (privacy)
- 🚀 Cross-chain bridges (Liquid, other L2)
- 🚀 Decentralized PKI (web of trust)
- 🚀 Smart contracts (Simplicity, Bitcoin L2)
---
## Conclusion
Le système 4NK offre une infrastructure décentralisée complète pour:
✅ **Identité souveraine** : Contrôle total des clés, multi-device
✅ **Collaboration sécurisée** : Processus à états avec validation distribuée
✅ **Auditabilité** : Traçabilité Bitcoin immuable
✅ **Confidentialité** : Chiffrement bout-en-bout
✅ **Résilience** : Pas de point de défaillance unique
**Points forts:**
- Architecture élégante (identité = cryptographie Bitcoin)
- Pas de serveur central de confiance
- Interopérabilité Bitcoin native
- Flexibilité des rôles et permissions
**Défis restants:**
- Performance du scanning SP (amélioration continue)
- UX du pairing (simplification nécessaire)
- Adoption (éducation des utilisateurs)
- Coûts mainnet (optimisation des frais)
---
**Document complet:** [4NK_IDENTITY_AND_PROCESS_SPEC.md](./4NK_IDENTITY_AND_PROCESS_SPEC.md)
**Code source:** [GitHub 4NK](https://git.4nkweb.com/4nk/)
**Contact:** dev@4nkweb.com

317
docs/ARCHITECTURE_ANALYSIS.md
View File

@ -1,317 +0,0 @@
# Analyse Architecturale Complète - 4NK Environment
**Date** : 2025-01-27
**Version** : 1.0
**Contexte** : Analyse complète de l'architecture 4NK et du projet LeCoffre
## 📋 Vue d'ensemble
Cette analyse présente l'architecture complète de l'environnement 4NK, incluant tous les modules 4NK, le projet LeCoffre, et le système de gestion des configurations via 4NK_vault.
## 🏗️ Architecture Générale
### Environnement de Développement Centralisé
```
4NK_env/ # Environnement centralisé
├── 4NK_modules/ # Modules 4NK (SDK, services)
├── projects/lecoffre/ # Projet LeCoffre (notaires)
├── IA_agents/ # Agents IA et documentation
├── docs/ # Documentation centralisée
├── scripts/ # Scripts de gestion centralisés
└── confs/ # Configurations déployées (4NK_vault)
```
## 🔧 Modules 4NK - Analyse Complète
### 1. **sdk_relay** - Service de Relais WebSocket
**Rôle** : Relais central pour les communications WebSocket et la synchronisation mesh
- **Port** : 8090 (WebSocket), 8091 (HTTP health)
- **Fonctionnalités** :
- Serveur WebSocket configurable
- Synchronisation mesh entre relais
- Gestion des processus et membres
- Interface avec Bitcoin Core (RPC + ZMQ)
- Intégration Blindbit pour Silent Payments
- **Dépendances** : Bitcoin Core, Blindbit Oracle
- **Architecture** : Rust avec gestion d'état locale
### 2. **sdk_storage** - Service de Stockage Temporaire
**Rôle** : Stockage temporaire sécurisé avec TTL
- **Port** : 8081
- **API** :
- `POST /store` : Stockage avec clé/valeur/TTL
- `GET /retrieve/:key` : Récupération des données
- **Fonctionnalités** :
- Stockage temporaire avec expiration
- Clés hexadécimales 64 caractères
- Valeurs hexadécimales
- TTL optionnel (permanent si non spécifié)
### 3. **sdk_signer** - Service de Signature
**Rôle** : Service de signature TypeScript pour l'écosystème 4NK
- **Fonctionnalités** :
- Gestion des processus et signatures
- Communication sécurisée
- Compatibilité WASM (stub temporaire)
- Interface avec le réseau de relais
- **Architecture** : TypeScript avec support WASM
- **État** : Compatible avec stub sdk_client
### 4. **sdk_client** - Client SDK
**Rôle** : Client SDK pour l'interaction avec l'écosystème 4NK
- **Fonctionnalités** :
- Interface avec les services 4NK
- Gestion des connexions WebSocket
- Support des processus et transactions
- **Architecture** : Rust avec interface WebAssembly
### 5. **sdk_common** - Composants Communs
**Rôle** : Bibliothèque commune partagée entre tous les modules
- **Fonctionnalités** :
- Types et structures communes
- Utilitaires partagés
- Protocoles de communication
- **Usage** : Importé par tous les autres modules
### 6. **sdk-signer-client** - Client Signeur
**Rôle** : Client pour l'interaction avec le service de signature
- **Fonctionnalités** :
- Interface avec sdk_signer
- Gestion des signatures
- Communication sécurisée
### 7. **ihm_client** - Interface Homme-Machine
**Rôle** : Interface utilisateur pour la gestion des clés et processus
- **Port** : 3003
- **Fonctionnalités** :
- Interface de gestion des clés Bitcoin
- Gestion des processus
- Interface utilisateur web
- **Dépendances** : sdk_relay, sdk_storage
### 8. **4NK_vault** - Système de Gestion des Configurations
**Rôle** : API sécurisée pour la gestion centralisée des configurations
- **Port** : 6666 (HTTPS)
- **Fonctionnalités** :
- Authentification par clés utilisateur
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Rotation automatique des clés
- Résolution des variables d'environnement
- Isolation par environnement (dev, prod)
- **Sécurité** :
- HTTPS obligatoire
- Authentification par ID utilisateur
- Clés individuelles par utilisateur/environnement
- Rotation automatique (toutes les heures)
- **Déploiement** : Synchronise les configurations vers `confs/` dans le docker de contrôle
### 9. **4NK_certificator** - Service d'Ancrage Cryptographique
**Rôle** : Ancrage périodique sur Bitcoin mainnet des empreintes des échanges
- **Fonctionnalités** :
- Surveillance des messages du relay 4NK
- Détection des paiements Bitcoin
- Enregistrement périodique sur blockchain
- Métriques de volume de données
- **Architecture** : Rust avec base de données SQLite
- **État** : MVP complet implémenté
### 10. **4NK_miner** - Service de Minage
**Rôle** : Service de minage Bitcoin (développement/test)
- **Fonctionnalités** :
- Minage sur réseau Signet
- Génération de blocs de test
- Interface avec le réseau Bitcoin
### 11. **4NK_web_status** - Service de Statut
**Rôle** : Service de monitoring et statut des services
- **Fonctionnalités** :
- Monitoring des services
- Interface de statut
- Métriques de santé
### 12. **blindbit-oracle** - Oracle Bitcoin
**Rôle** : Service pour les paiements silencieux (Silent Payments)
- **Port** : 8000
- **Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Interface HTTP REST
- **Dépendances** : Bitcoin Core
### 13. **rust-silentpayments** - Implémentation Silent Payments
**Rôle** : Implémentation Rust des Silent Payments
- **Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Utilitaires cryptographiques
## 🏢 Projet LeCoffre - Architecture Notariale
### Contexte Métier
Le projet LeCoffre est une plateforme de gestion de documents sécurisée pour les notaires, utilisant l'infrastructure 4NK pour la sécurité et l'intégrité des documents.
### Composants du Projet LeCoffre
#### 1. **lecoffre_node** - Orchestrateur Principal
**Rôle** : Docker de contrôle et déploiement pour LeCoffre
- **Architecture** : Docker Compose avec Nginx intégré
- **Services déployés** :
- lecoffre-front (interface utilisateur)
- ihm_client (gestion des clés)
- sdk_relay (relais WebSocket)
- sdk_storage (stockage temporaire)
- bitcoin-signet (nœud Bitcoin)
- blindbit-oracle (oracle Bitcoin)
- tor-proxy (proxy anonyme)
- Services de monitoring (Grafana, Loki, Promtail)
- **Configuration** : Centralisée dans `confs/` (synchronisée depuis 4NK_vault)
- **Déploiement** : Scripts automatisés avec phases de démarrage
#### 2. **lecoffre-front** - Interface Utilisateur
**Rôle** : Frontend Next.js pour l'application LeCoffre
- **Technologie** : Next.js avec React
- **Fonctionnalités** :
- Interface utilisateur pour les notaires
- Gestion des documents
- Intégration avec l'écosystème 4NK
- **Déploiement** : Conteneur Docker sur port 3004
#### 3. **lecoffre-back-mini** - Backend Centralisé
**Rôle** : Backend centralisé pour les besoins spécifiques des notaires
- **Fonctionnalités** :
- APIs avec Stripe (paiements)
- Intégration Mailchimp (email marketing)
- Intégration OVH (SMS)
- Intégration IdNot (HMR dev3 ↔ dev4 via OAuth2)
- **Déploiement** : Sur dev3.4nkweb.com
- **Architecture** : Service centralisé indépendant
## 🌐 Architecture de Déploiement
### Environnements
- **dev4.4nkweb.com** : Machine principale (LeCoffre)
- **dev3.4nkweb.com** : Nœud de bootstrap (signer centralisé, mini back)
### URLs et Services
- **LeCoffre Front** : https://dev4.4nkweb.com/lecoffre
- **4NK iframe** : https://dev4.4nkweb.com
- **Signer centralisé** : dev3.4nkweb.com (module 4NK pour notaires)
- **Mini back** : dev3.4nkweb.com (APIs Stripe, Mailchimp, OVH, IdNot)
### Architecture de Déploiement par Phases
#### Phase 1: Services de Base (Parallèle)
- tor, sdk_storage, status-api
#### Phase 2: Services Blockchain (Séquentiel)
- bitcoin → blindbit → sdk_relay
#### Phase 3: Services Applicatifs (Séquentiel)
- lecoffre-front, ihm_client
#### Phase 4: Services de Monitoring (Indépendant)
- loki → promtail → grafana
#### Phase 5: Services Utilitaires
- watchtower
## 🔐 Sécurité et Configuration
### 4NK_vault - Gestion Centralisée des Configurations
- **Rôle** : API sécurisée pour la gestion des configurations
- **Sécurité** : Chiffrement quantique résistant, authentification par clés
- **Déploiement** : Synchronise vers `confs/` dans le docker de contrôle
- **Isolation** : Variables d'environnement protégées, fichiers .env inaccessibles
### Protection des Secrets
- **Fichiers .env** : Inaccessibles pour des raisons de sécurité
- **Variables** : Séparées des secrets, remplacées dans storage/
- **Configurations** : Copie déployée dans confs/ pour visualisation
## 🤖 Agents IA - Organisation
### Structure IA_agents/
- **README.md** : Documentation principale et règles obligatoires
- **deployment-architecture.md** : Architecture de déploiement par phases
- **best-practices-deployment.md** : Bonnes pratiques et interdictions
- **prompts/** : Prompts spécialisés pour différents aspects
- **todo.md** : Liste des améliorations et optimisations
### Règles Critiques pour les Agents IA
1. **Interdictions absolues** : Pas de `docker compose up -d` direct
2. **Scripts obligatoires** : Utilisation des scripts spécialisés
3. **Phases respectées** : Ordre de démarrage par phases
4. **Monitoring indépendant** : Services de monitoring séparés
5. **Surveillance continue** : Suivi de progression obligatoire
## 📊 Monitoring et Observabilité
### Stack de Monitoring
- **Grafana** : Dashboards et visualisation
- **Loki** : Collecte et stockage des logs
- **Promtail** : Agent de collecte des logs
- **Watchtower** : Mise à jour automatique des images
### Dashboards Disponibles
- Vue d'ensemble LeCoffre
- Bitcoin & Miner
- Services Applications
- SDK Services
- Frontend Services
## 🔄 CI/CD et Déploiement
### Branches et Tags
- **Branche unifiée** : `ext` pour tous les dépôts
- **Tag Docker** : `ext` pour toutes les images
- **Déclenchement** : Push sur `ext` → Build automatique
### Scripts de Déploiement
- **start.sh** : Démarrage complet avec phases
- **validate-deployment.sh** : Validation du déploiement
- **maintenance.sh** : Menu de maintenance interactif
- **backup-data.sh** : Sauvegarde des données
- **update-images.sh** : Mise à jour sécurisée
## 📚 Documentation Centralisée
### Structure docs/
- **Architecture** : Spécifications techniques
- **Déploiement** : Guides de déploiement
- **Services** : Documentation par service
- **Scripts** : Documentation des scripts
### Mise à Jour Continue
- **IA_agents/** : Documentation pour les agents IA
- **docs/** : Documentation technique centralisée
- **Alignement** : Synchronisation entre code et documentation
## 🎯 Points Clés de l'Architecture
### 1. **Séparation des Responsabilités**
- Services applicatifs indépendants du monitoring
- Monitoring observant sans impacter
- Dépendances uniquement métier
### 2. **Sécurité Multi-Niveaux**
- 4NK_vault pour la gestion centralisée des configurations
- Chiffrement quantique résistant
- Isolation des secrets et variables
### 3. **Déploiement Optimisé**
- Phases de démarrage respectées
- Scripts spécialisés obligatoires
- Surveillance continue et diagnostic facilité
### 4. **Maintenance Facilitée**
- Redémarrage sélectif possible
- Scripts de maintenance interactifs
- Documentation centralisée et à jour
---
**Document créé le 2025-01-27**
**Version** : 1.0
**Usage** : Documentation architecturale complète pour les agents IA et l'équipe de développement

1140
docs/CERTIFICATOR_SPECIFICATION.md
View File

File diff suppressed because it is too large Load Diff

424
docs/DEEP_ARCHITECTURE_ANALYSIS.md
View File

@ -1,424 +0,0 @@
# Analyse Architecturale Approfondie - 4NK Environment
**Date** : 2025-01-27
**Version** : 2.0
**Contexte** : Analyse approfondie de l'architecture 4NK et du projet LeCoffre
## 📋 Vue d'ensemble Détaillée
Cette analyse approfondie présente l'architecture complète de l'environnement 4NK, incluant tous les modules, leurs dépendances, configurations, et le système de déploiement par phases.
## 🏗️ Architecture Générale Détaillée
### Structure des Submodules
```
4NK_env/ # Environnement centralisé
├── 4NK_modules/ # 13 modules 4NK (SDK, services)
│ ├── sdk_relay/ # Relais WebSocket central (Rust)
│ ├── sdk_storage/ # Stockage temporaire (Rust)
│ ├── sdk_signer/ # Service de signature (TypeScript)
│ ├── sdk_client/ # Client SDK (Rust/WASM)
│ ├── sdk_common/ # Composants communs (Rust)
│ ├── sdk-signer-client/ # Client signeur (TypeScript)
│ ├── ihm_client/ # Interface utilisateur (Vite/React)
│ ├── 4NK_vault/ # API sécurisée configurations (Python)
│ ├── 4NK_certificator/ # Ancrage cryptographique (Rust)
│ ├── 4NK_miner/ # Service de minage (Rust)
│ ├── 4NK_web_status/ # Service de statut (Python)
│ ├── blindbit-oracle/ # Oracle Bitcoin (Rust)
│ ├── rust-silentpayments/ # Silent Payments (Rust)
│ └── doc_api/ # Documentation API
├── projects/lecoffre/ # Projet LeCoffre (notaires)
│ ├── lecoffre_node/ # Docker de contrôle
│ ├── lecoffre-front/ # Frontend Next.js
│ └── lecoffre-back-mini/ # Backend centralisé
├── IA_agents/ # Agents IA et documentation
├── docs/ # Documentation centralisée
├── scripts/ # Scripts de gestion centralisés
└── confs/ # Configurations déployées (4NK_vault)
```
## 🔧 Modules 4NK - Analyse Approfondie
### 1. **sdk_relay** - Service de Relais WebSocket Central
**Rôle** : Relais central pour les communications WebSocket et la synchronisation mesh
- **Technologie** : Rust (tokio, async-trait, futures-util)
- **Ports** : 8090 (WebSocket), 8091 (HTTP health)
- **Dépendances** :
- `sdk_common` (git: https://git.4nkweb.com/4nk/sdk_common.git)
- `bitcoincore-rpc` (0.18) - Interface Bitcoin Core
- `tokio-tungstenite` (0.21.0) - WebSocket
- `zeromq` (0.4.1) - ZMQ Bitcoin Core
- **Fonctionnalités** :
- Serveur WebSocket configurable
- Synchronisation mesh entre relais
- Gestion des processus et membres
- Interface avec Bitcoin Core (RPC + ZMQ)
- Intégration Blindbit pour Silent Payments
- Cache de déduplication
- Gestion d'état locale dans `~/<data_dir>`
- **Architecture** : Rust avec gestion d'état locale
- **Configuration** : Fichier de configuration via `--config`
- **Healthcheck** : `/health` sur port 8091
### 2. **sdk_storage** - Service de Stockage Temporaire Sécurisé
**Rôle** : Stockage temporaire avec TTL et chiffrement
- **Technologie** : Rust (tide, async-std)
- **Port** : 8081 (mappé depuis 8080)
- **API** :
- `POST /store` : Stockage avec clé/valeur/TTL
- `GET /retrieve/:key` : Récupération des données
- **Fonctionnalités** :
- Stockage temporaire avec expiration
- Clés hexadécimales 64 caractères
- Valeurs hexadécimales
- TTL optionnel (permanent si non spécifié)
- Chiffrement des données
- **Architecture** : Rust avec async-std
- **Healthcheck** : `/health` sur port 8080
### 3. **sdk_signer** - Service de Signature TypeScript
**Rôle** : Service de signature pour l'écosystème 4NK
- **Technologie** : TypeScript avec support WASM
- **Fonctionnalités** :
- Gestion des processus et signatures
- Communication sécurisée
- Compatibilité WASM (stub temporaire)
- Interface avec le réseau de relais
- Validation des permissions
- **Architecture** : TypeScript avec support WASM
- **État** : Compatible avec stub sdk_client
- **Dépendances** : Node.js 18+, npm/yarn
### 4. **sdk_client** - Client SDK Rust/WASM
**Rôle** : Client SDK pour l'interaction avec l'écosystème 4NK
- **Technologie** : Rust avec interface WebAssembly
- **Fonctionnalités** :
- Interface avec les services 4NK
- Gestion des connexions WebSocket
- Support des processus et transactions
- Compilation WASM pour le web
- **Architecture** : Rust avec interface WASM
- **Usage** : Importé par sdk_signer et autres clients
### 5. **sdk_common** - Bibliothèque Commune
**Rôle** : Composants communs partagés entre tous les modules
- **Technologie** : Rust
- **Fonctionnalités** :
- Types et structures communes
- Utilitaires partagés
- Protocoles de communication
- Support Blindbit (feature: "blindbit-backend")
- Support parallèle (feature: "parallel")
- **Usage** : Importé par tous les autres modules
- **Features** : parallel, blindbit-backend
### 6. **sdk-signer-client** - Client Signeur
**Rôle** : Client pour l'interaction avec le service de signature
- **Technologie** : TypeScript
- **Fonctionnalités** :
- Interface avec sdk_signer
- Gestion des signatures
- Communication sécurisée
- **Architecture** : TypeScript client
### 7. **ihm_client** - Interface Homme-Machine
**Rôle** : Interface utilisateur pour la gestion des clés et processus
- **Technologie** : Vite + React
- **Port** : 3003
- **Fonctionnalités** :
- Interface de gestion des clés Bitcoin
- Gestion des processus
- Interface utilisateur web
- Variables d'environnement Vite
- **Dépendances** : sdk_relay, sdk_storage
- **Variables** : VITE_JWT_SECRET_KEY, VITE_API_BASE_URL, VITE_WS_URL, VITE_STORAGE_URL, VITE_SIGNER_URL, VITE_BOOTSTRAPURL
### 8. **4NK_vault** - Système de Gestion des Configurations
**Rôle** : API sécurisée pour la gestion centralisée des configurations
- **Technologie** : Python Flask
- **Port** : 6666 (HTTPS)
- **Sécurité** :
- Authentification par clés utilisateur
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Rotation automatique des clés (toutes les heures)
- Isolation par environnement (dev, prod)
- **Fonctionnalités** :
- Résolution des variables d'environnement
- Synchronisation vers `confs/` dans le docker de contrôle
- Protection des secrets
- Clés individuelles par utilisateur/environnement
- **Endpoints** :
- `GET /health` - Contrôle de santé
- `GET /info` - Informations API
- `GET /routes` - Routes disponibles
- `GET /<env>/<file>` - Fichier chiffré
- **Déploiement** : Synchronise les configurations vers `confs/`
### 9. **4NK_certificator** - Service d'Ancrage Cryptographique
**Rôle** : Ancrage périodique sur Bitcoin mainnet des empreintes des échanges
- **Technologie** : Rust
- **Fonctionnalités** :
- Surveillance des messages du relay 4NK
- Détection des paiements Bitcoin
- Enregistrement périodique sur blockchain
- Métriques de volume de données
- Base de données SQLite
- **Architecture** : Rust avec base de données SQLite
- **État** : MVP complet implémenté
- **Composants** :
- RelayMonitor (surveillance WebSocket)
- PaymentWatcher (surveillance Bitcoin)
- Base de données SQLite
### 10. **4NK_miner** - Service de Minage
**Rôle** : Service de minage Bitcoin (développement/test)
- **Technologie** : Rust
- **Fonctionnalités** :
- Minage sur réseau Signet
- Génération de blocs de test
- Interface avec le réseau Bitcoin
- **Usage** : Développement et tests uniquement
### 11. **4NK_web_status** - Service de Statut
**Rôle** : Service de monitoring et statut des services
- **Technologie** : Python Flask
- **Port** : 3006
- **Fonctionnalités** :
- Monitoring des services
- Interface de statut
- Métriques de santé
- API REST pour le statut
- **Dépendances** : Docker socket, logs directory
### 12. **blindbit-oracle** - Oracle Bitcoin Silent Payments
**Rôle** : Service pour les paiements silencieux (Silent Payments)
- **Technologie** : Rust
- **Port** : 8000
- **Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Interface HTTP REST
- Scan filtré BIP158
- **Dépendances** : Bitcoin Core
- **Configuration** : blindbit.toml
### 13. **rust-silentpayments** - Implémentation Silent Payments
**Rôle** : Implémentation Rust des Silent Payments
- **Technologie** : Rust
- **Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Utilitaires cryptographiques
- **Usage** : Bibliothèque pour blindbit-oracle
## 🏢 Projet LeCoffre - Architecture Notariale Détaillée
### Contexte Métier
Le projet LeCoffre est une plateforme de gestion de documents sécurisée pour les notaires, utilisant l'infrastructure 4NK pour la sécurité et l'intégrité des documents.
### Composants du Projet LeCoffre
#### 1. **lecoffre_node** - Orchestrateur Principal
**Rôle** : Docker de contrôle et déploiement pour LeCoffre
- **Architecture** : Docker Compose avec Nginx intégré
- **Services déployés** :
- **tor** (btcpayserver/tor:0.4.8.10) - Proxy anonyme
- **bitcoin** (build: ./bitcoin) - Nœud Bitcoin Signet
- **blindbit** (git.4nkweb.com/4nk/blindbit-oracle:fixed-source) - Oracle Bitcoin
- **sdk_relay** (git.4nkweb.com/4nk/sdk_relay:ext) - Relais WebSocket
- **sdk_storage** (git.4nkweb.com/4nk/sdk_storage:ext) - Stockage temporaire
- **lecoffre-front** (git.4nkweb.com/4nk/lecoffre-front:ext) - Frontend Next.js
- **ihm_client** (git.4nkweb.com/4nk/ihm_client:ext) - Interface utilisateur
- **grafana** (grafana/grafana:latest) - Monitoring
- **loki** (grafana/loki:latest) - Collecte de logs
- **promtail** (grafana/promtail:latest) - Agent de collecte
- **status-api** (build: 4NK_web_status) - API de statut
- **watchtower** (containrrr/watchtower) - Mise à jour automatique
- **signet_miner** (build: 4NK_miner) - Minage (profile: miner)
- **Configuration** : Centralisée dans `confs/` (synchronisée depuis 4NK_vault)
- **Déploiement** : Scripts automatisés avec phases de démarrage
- **Réseau** : btcnet (172.20.0.0/16)
- **Volumes** : Persistance des données (bitcoin_data, blindbit_data, sdk_data, etc.)
#### 2. **lecoffre-front** - Interface Utilisateur
**Rôle** : Frontend Next.js pour l'application LeCoffre
- **Technologie** : Next.js avec React
- **Port** : 3004 (mappé depuis 8080)
- **Fonctionnalités** :
- Interface utilisateur pour les notaires
- Gestion des documents
- Intégration avec l'écosystème 4NK
- Variables d'environnement Next.js
- **Variables** : NEXT_PUBLIC_API_URL, NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_4NK_IFRAME_URL, NEXT_PUBLIC_IDNOT_BASE_URL
- **Déploiement** : Conteneur Docker sur port 3004
- **User** : lecoffreuser (non-root)
#### 3. **lecoffre-back-mini** - Backend Centralisé
**Rôle** : Backend centralisé pour les besoins spécifiques des notaires
- **Déploiement** : Sur dev3.4nkweb.com
- **Fonctionnalités** :
- APIs avec Stripe (paiements)
- Intégration Mailchimp (email marketing)
- Intégration OVH (SMS)
- Intégration IdNot (HMR dev3 ↔ dev4 via OAuth2)
- **Architecture** : Service centralisé indépendant
- **APIs** :
- `/api/v1/health` - Santé du service
- `/api/v1/status` - Statut du service
- `/api/v1/idnot/state` - État IdNot
## 🌐 Architecture de Déploiement Détaillée
### Environnements et URLs
- **dev4.4nkweb.com** : Machine principale (LeCoffre)
- **dev3.4nkweb.com** : Nœud de bootstrap (signer centralisé, mini back)
### URLs et Services
- **LeCoffre Front** : https://dev4.4nkweb.com/lecoffre
- **4NK iframe** : https://dev4.4nkweb.com
- **Signer centralisé** : dev3.4nkweb.com (module 4NK pour notaires)
- **Mini back** : dev3.4nkweb.com (APIs Stripe, Mailchimp, OVH, IdNot)
### Architecture de Déploiement par Phases
#### Phase 1: Services de Base (Parallèle)
- **tor** : Proxy anonyme (btcpayserver/tor:0.4.8.10)
- **sdk_storage** : Stockage temporaire (git.4nkweb.com/4nk/sdk_storage:ext)
- **status-api** : API de statut (build: 4NK_web_status)
#### Phase 2: Services Blockchain (Séquentiel)
- **bitcoin** → **blindbit** → **sdk_relay**
- Chaîne de dépendances blockchain respectée
#### Phase 3: Services Applicatifs (Séquentiel)
- **lecoffre-front** : Frontend Next.js
- **ihm_client** : Interface utilisateur
- Dépendances : sdk_relay + sdk_storage
#### Phase 4: Services de Monitoring (Indépendant)
- **loki** → **promtail** → **grafana**
- Chaîne de dépendances monitoring
#### Phase 5: Services Utilitaires
- **watchtower** : Mise à jour automatique (interval: 30s)
## 🔐 Sécurité et Configuration Détaillée
### 4NK_vault - Gestion Centralisée des Configurations
- **Rôle** : API sécurisée pour la gestion des configurations
- **Sécurité** :
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Authentification par clés utilisateur
- Rotation automatique des clés (toutes les heures)
- Isolation par environnement (dev, prod)
- **Déploiement** : Synchronise vers `confs/` dans le docker de contrôle
- **Protection des secrets** : Fichiers .env inaccessibles, variables séparées
### Variables d'Environnement par Service
- **bitcoin** : BITCOIN_RPC_USER, BITCOIN_RPC_PASSWORD, BITCOIN_RPC_PORT
- **blindbit** : BLINDBIT_API_PORT, BITCOIN_RPC_URL
- **sdk_relay** : RELAY_PORT, RELAY_HTTP_PORT, STORAGE_URL
- **sdk_storage** : STORAGE_PORT, STORAGE_DATA_DIR
- **lecoffre-front** : NEXT_PUBLIC_API_URL, NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_IDNOT_BASE_URL
- **ihm_client** : VITE_API_URL, VITE_4NK_URL, VITE_RELAY_URL
- **grafana** : GF_SECURITY_ADMIN_PASSWORD, GF_DATABASE_TYPE
- **loki** : LOKI_CONFIG_FILE, LOKI_DATA_DIR
- **promtail** : PROMTAIL_CONFIG_FILE, LOKI_URL
- **status-api** : STATUS_API_PORT, STATUS_API_HOST
## 📊 Monitoring et Observabilité Détaillée
### Stack de Monitoring
- **Grafana** (grafana/grafana:latest) : Dashboards et visualisation
- **Loki** (grafana/loki:latest) : Collecte et stockage des logs
- **Promtail** (grafana/promtail:latest) : Agent de collecte des logs
- **Watchtower** (containrrr/watchtower) : Mise à jour automatique
### Configuration Loki (CRITIQUE)
- **OBLIGATOIRE** : `http_listen_address: 0.0.0.0` (pas 127.0.0.1)
- **OBLIGATOIRE** : `instance_addr: 0.0.0.0` (pas 127.0.0.1)
- **Fichier** : `/conf/loki/loki-config.yaml`
- **Healthcheck** : `wget` (pas `curl`)
### Dashboards Disponibles
- Vue d'ensemble LeCoffre
- Bitcoin & Miner
- Services Applications
- SDK Services
- Frontend Services
### Logs Centralisés
- **Répertoire** : `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/`
- **Services** : tor, bitcoin, blindbit, sdk_relay, sdk_storage, lecoffre-front, ihm_client, grafana, loki, promtail, status-api
- **Collecte** : Promtail → Loki → Grafana
## 🔄 CI/CD et Déploiement Détaillé
### Branches et Tags
- **Branche unifiée** : `ext` pour tous les dépôts 4NK
- **Branches spéciales** : `main` pour 4NK_certificator, 4NK_miner, 4NK_web_status
- **Tag Docker** : `ext` pour toutes les images
- **Déclenchement** : Push sur `ext` → Build automatique
### Scripts de Déploiement Détaillés
- **start.sh** : Démarrage complet avec phases et progression
- **validate-deployment.sh** : Validation complète du déploiement
- **maintenance.sh** : Menu de maintenance interactif
- **backup-data.sh** : Sauvegarde des données
- **update-images.sh** : Mise à jour sécurisée
- **collect-logs.sh** : Collecte des logs
- **deploy-grafana.sh** : Déploiement du monitoring
- **sync-configs.sh** : Synchronisation des configurations
### Healthchecks Détaillés
- **tor** : tor-progress.sh (bootstrap %)
- **bitcoin** : bitcoin-progress.sh (IBD, blocks, headers)
- **blindbit** : blindbit-progress.sh (API, scan)
- **sdk_relay** : sdk-relay-progress.sh (WebSocket, health)
- **sdk_storage** : curl /health
- **lecoffre-front** : ps aux | grep next-server
- **ihm_client** : curl localhost:3003
- **grafana** : curl /api/health
- **loki** : wget /ready
- **promtail** : fichier positions.yaml
- **status-api** : curl /api
## 🎯 Points Clés de l'Architecture Approfondie
### 1. **Séparation des Responsabilités**
- Services applicatifs indépendants du monitoring
- Monitoring observant sans impacter
- Dépendances uniquement métier
### 2. **Sécurité Multi-Niveaux**
- 4NK_vault pour la gestion centralisée des configurations
- Chiffrement quantique résistant
- Isolation des secrets et variables
- Utilisateurs non-root dans les conteneurs
### 3. **Déploiement Optimisé**
- Phases de démarrage respectées
- Scripts spécialisés obligatoires
- Surveillance continue et diagnostic facilité
- Healthchecks informatifs
### 4. **Maintenance Facilitée**
- Redémarrage sélectif possible
- Scripts de maintenance interactifs
- Documentation centralisée et à jour
- Logs centralisés et structurés
### 5. **Architecture Modulaire**
- 13 modules 4NK avec rôles spécialisés
- Projet LeCoffre : Interface notariale
- 4NK_vault : Gestion centralisée des configurations
- Scripts centralisés et réutilisables
---
**Document créé le 2025-01-27**
**Version** : 2.0
**Usage** : Analyse architecturale approfondie pour les agents IA et l'équipe de développement

332
docs/DEPLOYMENT_GUIDE.md
View File

@ -1,332 +0,0 @@
# Guide de Déploiement Complet - 4NK Environment
**Date** : 2025-01-27
**Version** : 2.0
**Contexte** : Guide de déploiement complet pour les agents IA et l'équipe de développement
## 📋 Vue d'ensemble du Déploiement
Ce guide présente le processus de déploiement complet de l'environnement 4NK, incluant tous les modules, le projet LeCoffre, et le système de monitoring.
## 🚀 Prérequis et Préparation
### Environnement Système
- **OS** : Linux (Ubuntu 20.04+, Debian 11+, CentOS 8+)
- **Docker** : 20.10+ avec Docker Compose 2.0+
- **RAM** : Minimum 8 GB, 16 GB recommandé
- **Stockage** : Minimum 100 GB pour la blockchain et les données
- **Réseau** : Connexion stable à Internet
### Accès et Authentification
- **SSH** : Clés SSH configurées pour git.4nkweb.com
- **Docker Registry** : Accès à git.4nkweb.com/4nk/
- **Certificats** : Certificats SSL pour HTTPS (auto-signés en dev)
### Variables d'Environnement
- **Fichier principal** : `.env.master` dans la racine du projet
- **Synchronisation** : 4NK_vault synchronise vers `confs/`
- **Protection** : Fichiers .env inaccessibles pour des raisons de sécurité
## 🏗️ Architecture de Déploiement par Phases
### Principe Fondamental
Les services sont organisés en **5 phases** pour optimiser le démarrage et éviter les dépendances inutiles :
1. **Services applicatifs** : Fonctionnent indépendamment du monitoring
2. **Services de monitoring** : Observent sans impacter les applications
3. **Dépendances** : Seules les dépendances métier sont respectées
### Phase 1: Services de Base (Parallèle)
Ces services peuvent démarrer en parallèle car ils sont indépendants :
| Service | Port | Dépendance | Script | Description |
|---------|------|------------|--------|-------------|
| **tor** | 9050 | Aucune | `start.sh` | Proxy anonyme |
| **sdk_storage** | 8081 | Aucune | `start.sh` | Stockage temporaire |
| **status-api** | 3006 | Aucune | `start.sh` | API de statut |
### Phase 2: Services Blockchain (Séquentiel)
Ces services suivent la chaîne blockchain :
| Service | Port | Dépendance | Script | Description |
|---------|------|------------|--------|-------------|
| **bitcoin** | 8332 | tor (healthy) | `start.sh` | Nœud Bitcoin Signet |
| **blindbit** | 8000 | bitcoin (healthy) | `start.sh` | Oracle Bitcoin |
| **sdk_relay** | 8090-8091 | blindbit (healthy) | `start.sh` | Relais WebSocket |
### Phase 3: Services Applicatifs (Séquentiel)
Ces services suivent la chaîne applicative :
| Service | Port | Dépendance | Script | Description |
|---------|------|------------|--------|-------------|
| **lecoffre-front** | 3004 | sdk_relay + sdk_storage | `start.sh` | Frontend Next.js |
| **ihm_client** | 3003 | sdk_relay + sdk_storage | `start.sh` | Interface utilisateur |
### Phase 4: Services de Monitoring (Séquentiel, Indépendant)
Ces services sont indépendants des applications :
| Service | Port | Dépendance | Script | Description |
|---------|------|------------|--------|-------------|
| **loki** | 3100 | Aucune | `start-monitoring.sh` | Collecte de logs |
| **promtail** | 9080 | loki (healthy) | `start-monitoring.sh` | Agent de collecte |
| **grafana** | 3005 | loki + promtail (healthy) | `start-monitoring.sh` | Dashboards |
### Phase 5: Services Utilitaires
Services de maintenance et surveillance :
| Service | Port | Dépendance | Script | Description |
|---------|------|------------|--------|-------------|
| **watchtower** | 8080 | Aucune | `start.sh` | Mise à jour automatique |
## 🔧 Scripts de Déploiement
### Scripts OBLIGATOIRES
#### `./scripts/start.sh`
**Usage** : Démarrage complet avec phases
**Fonction** : Démarre les services applicatifs dans l'ordre correct
**Phases** : 1, 2, 3, 5
**Fonctionnalités** :
- Démarrage séquentiel avec progression
- Vérification des variables d'environnement
- Healthchecks informatifs
- Tests d'URLs complets
- Surveillance continue
#### `./scripts/start-monitoring.sh`
**Usage** : Démarrage monitoring indépendant
**Fonction** : Démarre les services de monitoring dans l'ordre correct
**Phases** : 4 uniquement
**Fonctionnalités** :
- Démarrage indépendant du monitoring
- Configuration Loki critique
- Dashboards Grafana
#### `./scripts/validate-deployment.sh`
**Usage** : Validation complète du déploiement
**Fonction** : Vérifie tous les services, volumes, et configurations
**Fonctionnalités** :
- Validation des services
- Validation des volumes
- Validation des URLs publiques
- Validation des WebSockets
- Validation des scripts
- Validation des variables d'environnement
### Scripts INTERDITS
```bash
# ❌ JAMAIS utiliser ces commandes
docker compose --env-file .env.master up -d
docker compose up -d
docker compose start
```
## 📊 Flux de Déploiement Complet
### Étape 1: Préparation
1. **Vérifier l'environnement** : Docker, RAM, stockage
2. **Synchroniser les configurations** : 4NK_vault → confs/
3. **Vérifier les variables d'environnement** : .env.master
4. **Préparer les volumes** : Données persistantes
### Étape 2: Déploiement Services Applicatifs
```bash
# Démarrage complet avec phases
./scripts/start.sh
```
**Progression attendue** :
1. **Phase 1** : tor, sdk_storage, status-api (parallèle)
2. **Phase 2** : bitcoin → blindbit → sdk_relay (séquentiel)
3. **Phase 3** : lecoffre-front, ihm_client (séquentiel)
4. **Phase 5** : watchtower (utilitaire)
### Étape 3: Déploiement Monitoring
```bash
# Démarrage monitoring indépendant
./scripts/start-monitoring.sh
```
**Progression attendue** :
1. **loki** : Collecte de logs
2. **promtail** : Agent de collecte
3. **grafana** : Dashboards
### Étape 4: Validation
```bash
# Validation complète
./scripts/validate-deployment.sh
```
**Tests effectués** :
- Services Docker
- Volumes persistants
- URLs publiques
- WebSockets
- Variables d'environnement
## 🔍 Configuration Critique
### Configuration Loki (CRITIQUE)
- **OBLIGATOIRE** : `http_listen_address: 0.0.0.0` (pas 127.0.0.1)
- **OBLIGATOIRE** : `instance_addr: 0.0.0.0` (pas 127.0.0.1)
- **Fichier** : `/conf/loki/loki-config.yaml`
- **Healthcheck** : `wget` (pas `curl`)
### Variables d'Environnement par Service
- **bitcoin** : BITCOIN_RPC_USER, BITCOIN_RPC_PASSWORD, BITCOIN_RPC_PORT
- **blindbit** : BLINDBIT_API_PORT, BITCOIN_RPC_URL
- **sdk_relay** : RELAY_PORT, RELAY_HTTP_PORT, STORAGE_URL
- **sdk_storage** : STORAGE_PORT, STORAGE_DATA_DIR
- **lecoffre-front** : NEXT_PUBLIC_API_URL, NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_IDNOT_BASE_URL
- **ihm_client** : VITE_API_URL, VITE_4NK_URL, VITE_RELAY_URL
- **grafana** : GF_SECURITY_ADMIN_PASSWORD, GF_DATABASE_TYPE
- **loki** : LOKI_CONFIG_FILE, LOKI_DATA_DIR
- **promtail** : PROMTAIL_CONFIG_FILE, LOKI_URL
- **status-api** : STATUS_API_PORT, STATUS_API_HOST
## 📊 Monitoring et Observabilité
### Stack de Monitoring
- **Grafana** : Dashboards et visualisation
- **Loki** : Collecte et stockage des logs
- **Promtail** : Agent de collecte des logs
- **Watchtower** : Mise à jour automatique
### Dashboards Disponibles
- Vue d'ensemble LeCoffre
- Bitcoin & Miner
- Services Applications
- SDK Services
- Frontend Services
### Logs Centralisés
- **Répertoire** : `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/`
- **Services** : tor, bitcoin, blindbit, sdk_relay, sdk_storage, lecoffre-front, ihm_client, grafana, loki, promtail, status-api
- **Collecte** : Promtail → Loki → Grafana
## 🚨 Dépannage et Maintenance
### Problèmes Courants
#### Services non accessibles
```bash
# Vérifier le statut
docker compose --env-file .env.master -f docker-compose.yml ps
# Vérifier les logs
docker compose --env-file .env.master -f docker-compose.yml logs -f <service>
```
#### Erreurs de configuration
```bash
# Synchroniser les configurations
./scripts/sync-configs.sh
# Vérifier les variables d'environnement
./scripts/validate-deployment.sh
```
#### Problèmes de monitoring
```bash
# Redémarrer le monitoring
./scripts/start-monitoring.sh
# Vérifier la configuration Loki
cat confs/loki/loki-config.yaml
```
### Scripts de Maintenance
- **backup-data.sh** : Sauvegarde des données
- **restore-data.sh** : Restauration des données
- **update-images.sh** : Mise à jour des images
- **collect-logs.sh** : Collecte des logs
- **maintenance.sh** : Menu de maintenance interactif
## 🎯 Bonnes Pratiques
### Règles d'Or pour les Agents IA
#### Règle 1: Toujours utiliser les scripts spécialisés
```bash
# ✅ CORRECT
./scripts/start.sh
./scripts/start-monitoring.sh
# ❌ INCORRECT
docker compose up -d
```
#### Règle 2: Respecter l'ordre par phases
```bash
# ✅ CORRECT : Phases séparées
Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5
# ❌ INCORRECT : Tout en parallèle
tous_les_services_en_même_temps
```
#### Règle 3: Monitoring indépendant
```bash
# ✅ CORRECT : Monitoring séparé
./scripts/start.sh # Applications
./scripts/start-monitoring.sh # Monitoring
# ❌ INCORRECT : Monitoring dépendant
applications_dépendent_de_monitoring
```
#### Règle 4: Surveillance continue
```bash
# ✅ CORRECT : Suivi de progression
./scripts/validate-deployment.sh
./scripts/monitor-progress.sh
# ❌ INCORRECT : Démarrage sans suivi
docker_compose_up_et_oublier
```
#### Règle 5: Diagnostic facilité
```bash
# ✅ CORRECT : Logs avec progression
./scripts/collect-logs.sh
./scripts/validate-deployment.sh
# ❌ INCORRECT : Logs bruts
docker logs <service>
```
## 📝 Validation et Tests
### Tests de Déploiement
1. **Services applicatifs** : URLs publiques accessibles
2. **Services de monitoring** : Dashboards Grafana alimentés
3. **Dépendances** : Chaîne de démarrage respectée
4. **Performance** : Temps de démarrage optimisé
### Tests de Maintenance
1. **Redémarrage monitoring** : Applications non impactées
2. **Redémarrage applications** : Monitoring non impacté
3. **Pannes sélectives** : Récupération isolée
4. **Surveillance** : Détection et diagnostic facilités
## 🔄 Mise à Jour et Maintenance
### Mise à Jour Automatique
- **Watchtower** : Mise à jour automatique toutes les 30 secondes
- **Images** : Tag `ext` pour toutes les images
- **Configuration** : Synchronisation automatique via 4NK_vault
### Maintenance Préventive
- **Sauvegarde** : `./scripts/backup-data.sh`
- **Logs** : `./scripts/collect-logs.sh`
- **Validation** : `./scripts/validate-deployment.sh`
- **Mise à jour** : `./scripts/update-images.sh`
---
**Document créé le 2025-01-27**
**Version** : 2.0
**Usage** : Guide de déploiement complet pour les agents IA et l'équipe de développement

219
docs/DOCUMENTATION_SYNTHESIS.md
View File

@ -1,219 +0,0 @@
# Synthèse de la Documentation - 4NK Environment
**Date** : 2025-01-27
**Version** : 2.0
**Contexte** : Synthèse de toute la documentation mise à jour
## 📋 Vue d'ensemble de la Documentation
Cette synthèse présente l'organisation complète de la documentation mise à jour pour l'environnement 4NK, incluant tous les documents créés et mis à jour.
## 📚 Structure de la Documentation
### Documentation Principale (docs/)
1. **DEEP_ARCHITECTURE_ANALYSIS.md** - Analyse architecturale approfondie complète
2. **TECHNICAL_REFERENCE.md** - Référence technique complète
3. **DEPLOYMENT_GUIDE.md** - Guide de déploiement complet
4. **ARCHITECTURE_ANALYSIS.md** - Analyse architecturale complète 4NK + LeCoffre
5. **context.md** - Contexte général des projets 4NK et LeCoffre
6. **flux.md** - Architecture des flux et services
### Documentation des Agents IA (IA_agents/)
1. **AGENTS_SYNTHESIS.md** - Synthèse complète pour les agents IA
2. **README.md** - Documentation principale et règles obligatoires
3. **deployment-architecture.md** - Architecture de déploiement par phases
4. **best-practices-deployment.md** - Bonnes pratiques et interdictions
5. **todo.md** - Liste des tâches et améliorations à suivre
### Documentation du Projet (README.md)
- **README.md** - Documentation principale mise à jour
- **Documentation centralisée** - Tous les documents référencés
- **Liens cohérents** - Navigation facilitée
## 🔧 Modules 4NK - Documentation Complète
### 13 Modules Documentés
1. **sdk_relay** - Service de Relais WebSocket Central
2. **sdk_storage** - Service de Stockage Temporaire Sécurisé
3. **sdk_signer** - Service de Signature TypeScript
4. **sdk_client** - Client SDK Rust/WASM
5. **sdk_common** - Bibliothèque Commune
6. **sdk-signer-client** - Client Signeur
7. **ihm_client** - Interface Homme-Machine
8. **4NK_vault** - Système de Gestion des Configurations
9. **4NK_certificator** - Service d'Ancrage Cryptographique
10. **4NK_miner** - Service de Minage
11. **4NK_web_status** - Service de Statut
12. **blindbit-oracle** - Oracle Bitcoin Silent Payments
13. **rust-silentpayments** - Implémentation Silent Payments
### Documentation Technique par Module
- **Technologie** : Rust, TypeScript, Python
- **Ports** : Tous les ports documentés
- **Dépendances** : Dépendances Rust, Node.js, Python
- **Fonctionnalités** : Toutes les fonctionnalités détaillées
- **Configuration** : Variables d'environnement et fichiers de config
- **Healthchecks** : Tous les healthchecks documentés
## 🏢 Projet LeCoffre - Documentation Complète
### 3 Composants Documentés
1. **lecoffre_node** - Orchestrateur Principal
2. **lecoffre-front** - Interface Utilisateur
3. **lecoffre-back-mini** - Backend Centralisé
### Documentation par Composant
- **Architecture** : Docker Compose avec Nginx intégré
- **Services** : Tous les services déployés
- **Configuration** : Centralisée dans `confs/`
- **Déploiement** : Scripts automatisés avec phases
- **Variables** : Toutes les variables d'environnement
- **URLs** : Toutes les URLs et services
## 🌐 Architecture de Déploiement - Documentation Complète
### 5 Phases Documentées
1. **Phase 1** : Services de Base (Parallèle)
2. **Phase 2** : Services Blockchain (Séquentiel)
3. **Phase 3** : Services Applicatifs (Séquentiel)
4. **Phase 4** : Services de Monitoring (Indépendant)
5. **Phase 5** : Services Utilitaires
### Scripts Documentés
- **Scripts OBLIGATOIRES** : start.sh, start-monitoring.sh, validate-deployment.sh
- **Scripts INTERDITS** : docker compose up -d (toute variante)
- **Fonctionnalités** : Toutes les fonctionnalités des scripts
- **Utilisation** : Guide d'utilisation complet
## 🔐 Sécurité et Configuration - Documentation Complète
### 4NK_vault Documenté
- **Rôle** : API sécurisée pour la gestion des configurations
- **Sécurité** : Chiffrement quantique résistant, authentification
- **Déploiement** : Synchronisation vers `confs/`
- **Protection** : Fichiers .env inaccessibles, variables séparées
### Variables d'Environnement Documentées
- **Par service** : Toutes les variables par service
- **Critiques** : Variables critiques identifiées
- **Validation** : Scripts de validation des variables
- **Synchronisation** : Processus de synchronisation
## 📊 Monitoring et Observabilité - Documentation Complète
### Stack de Monitoring Documenté
- **Grafana** : Dashboards et visualisation
- **Loki** : Collecte et stockage des logs
- **Promtail** : Agent de collecte des logs
- **Watchtower** : Mise à jour automatique
### Configuration Critique Documentée
- **Loki** : Configuration critique documentée
- **Dashboards** : Tous les dashboards documentés
- **Logs** : Centralisation et collecte documentées
## 🔄 CI/CD et Déploiement - Documentation Complète
### Branches et Tags Documentés
- **Branche unifiée** : `ext` pour tous les dépôts 4NK
- **Branches spéciales** : `main` pour certains modules
- **Tag Docker** : `ext` pour toutes les images
- **Déclenchement** : Processus de déclenchement documenté
### Scripts de Déploiement Documentés
- **Démarrage** : Scripts de démarrage complets
- **Validation** : Scripts de validation complets
- **Maintenance** : Scripts de maintenance complets
- **Healthchecks** : Tous les healthchecks documentés
## 🎯 Points Clés de la Documentation
### 1. **Cohérence Complète**
- Tous les modules documentés
- Toutes les configurations documentées
- Tous les scripts documentés
- Toutes les variables documentées
### 2. **Navigation Facilitée**
- Liens cohérents entre documents
- Structure hiérarchique claire
- Références croisées complètes
- Index et tables des matières
### 3. **Utilisation Optimisée**
- Guides de déploiement complets
- Références techniques détaillées
- Bonnes pratiques documentées
- Dépannage et maintenance
### 4. **Mise à Jour Continue**
- Documentation centralisée
- Synchronisation avec le code
- Validation de cohérence
- Amélioration continue
## 📝 Validation de la Documentation
### Documents Créés
- **DEEP_ARCHITECTURE_ANALYSIS.md** : Analyse architecturale approfondie
- **TECHNICAL_REFERENCE.md** : Référence technique complète
- **DEPLOYMENT_GUIDE.md** : Guide de déploiement complet
- **DOCUMENTATION_SYNTHESIS.md** : Synthèse de la documentation
### Documents Mis à Jour
- **README.md** : Documentation principale
- **IA_agents/README.md** : Documentation des agents IA
- **IA_agents/AGENTS_SYNTHESIS.md** : Synthèse pour les agents IA
### Cohérence Vérifiée
- **Liens** : Tous les liens fonctionnels
- **Références** : Toutes les références cohérentes
- **Structure** : Structure hiérarchique respectée
- **Contenu** : Contenu complet et détaillé
## 🚀 Utilisation de la Documentation
### Pour les Agents IA
1. **Commencer par** : `IA_agents/AGENTS_SYNTHESIS.md`
2. **Analyser** : `docs/DEEP_ARCHITECTURE_ANALYSIS.md`
3. **Référencer** : `docs/TECHNICAL_REFERENCE.md`
4. **Déployer** : `docs/DEPLOYMENT_GUIDE.md`
### Pour les Développeurs
1. **Commencer par** : `README.md`
2. **Analyser** : `docs/ARCHITECTURE_ANALYSIS.md`
3. **Référencer** : `docs/TECHNICAL_REFERENCE.md`
4. **Déployer** : `docs/DEPLOYMENT_GUIDE.md`
### Pour l'Équipe
1. **Commencer par** : `docs/DOCUMENTATION_SYNTHESIS.md`
2. **Analyser** : `docs/DEEP_ARCHITECTURE_ANALYSIS.md`
3. **Référencer** : `docs/TECHNICAL_REFERENCE.md`
4. **Déployer** : `docs/DEPLOYMENT_GUIDE.md`
## 📊 Métriques de la Documentation
### Documents Créés
- **4 nouveaux documents** de documentation technique
- **3 documents mis à jour** avec analyse approfondie
- **1 synthèse complète** de la documentation
### Couverture
- **13 modules 4NK** entièrement documentés
- **3 composants LeCoffre** entièrement documentés
- **5 phases de déploiement** entièrement documentées
- **Tous les scripts** entièrement documentés
### Qualité
- **Cohérence** : Tous les liens et références cohérents
- **Complétude** : Tous les aspects couverts
- **Utilisabilité** : Navigation et utilisation optimisées
- **Maintenabilité** : Structure évolutive et maintenable
---
**Document créé le 2025-01-27**
**Version** : 2.0
**Usage** : Synthèse complète de la documentation mise à jour

135
docs/README-URL-TESTS.md
View File

@ -1,135 +0,0 @@
# Tests de Santé des URLs - LeCoffre Node
## 🎯 Objectif
Ce répertoire contient les scripts de vérification de santé des URLs pour LeCoffre Node, intégrés dans les processus de backup et de production.
## 📁 Fichiers Créés
### Scripts Principaux
- **`url-health-check.sh`** : Script principal de test d'URLs (toutes les URLs internes et externes)
- **`production-health-check.sh`** : Script de vérification complète pour la production (avec rapport Markdown)
- **`backup-data.sh`** : Script de backup modifié (intègre les tests d'URLs avant/après)
### Documentation
- **`URL-HEALTH-CHECKING.md`** : Documentation complète des tests d'URLs
- **`README-URL-TESTS.md`** : Ce fichier (synthèse)
## 🚀 Utilisation Rapide
### Test des URLs
```bash
cd /home/debian/4NK_env/scripts/lecoffre_node
./url-health-check.sh
```
### Rapport de Production
```bash
cd /home/debian/4NK_env/scripts/lecoffre_node
./production-health-check.sh
```
### Backup avec Tests
```bash
cd /home/debian/4NK_env/scripts/lecoffre_node
./backup-data.sh
```
## 📊 URLs Testées
### ✅ URLs Interne (Services Docker)
- BlindBit Oracle API (`http://localhost:8000/tweaks/1`)
- SDK Storage Health (`http://localhost:8081/health`)
- SDK Relay WebSocket (`http://localhost:8091/`)
- SDK Relay HTTP (`http://localhost:8090/`)
- LeCoffre Frontend (`http://localhost:3004/`)
- IHM Client (`http://localhost:3003/`)
- Grafana (`http://localhost:3005/`)
- Loki (`http://localhost:3100/ready`)
- Status API (`http://localhost:3006/api`)
### ✅ URLs Externes (Domaine Public)
- Site Principal (`<PUBLIC_BASE_URL>/`)
- Page de Statut (`<PUBLIC_BASE_URL>/status/`)
- Dashboard Grafana (`<PUBLIC_BASE_URL>/grafana/`)
- Application LeCoffre (`<PUBLIC_BASE_URL>/lecoffre/`)
- Login LeCoffre (`<PUBLIC_BASE_URL>/lecoffre/login`)
- Callback Auth (`<PUBLIC_BASE_URL>/lecoffre/authorized-client`)
### ✅ APIs Externes (Backend Services)
- API Backend Health (`<BACKEND_BASE_URL>/api/v1/health`)
- API Backend Status (`<BACKEND_BASE_URL>/api/v1/status`)
- IdNot State Endpoint (`<BACKEND_BASE_URL>/api/v1/idnot/state`)
### ✅ WebSockets Externes
- Bootstrap Relay (`wss://<WS_BOOTSTRAP_HOST>/ws/`)
### ✅ Services Externes (Dépendances)
- Mempool Signet (`<MEMPOOL_URL>`)
- Service IdNot (`https://qual-connexion.idnot.fr/`)
- IdNot Authorization (`https://qual-connexion.idnot.fr/IdPOAuth2/authorize/idnot_idp_v1`)
## 📈 Intégration dans les Processus
### Backup
- **Avant** : Test de l'état des URLs
- **Après** : Vérification de la cohérence
- **Logs** : Sauvegardés avec le backup
### Production
- **État complet** : Services, disque, mémoire, volumes
- **Rapport Markdown** : Généré automatiquement
- **Recommandations** : Actions suggérées
## 🔍 Codes de Retour
- **0** : Toutes les URLs sont accessibles
- **1** : Certaines URLs ne sont pas accessibles (majorité fonctionne)
- **2** : Trop d'URLs ne sont pas accessibles
## 📝 Fichiers Générés
### Backup
```
./backups/
├── lecoffre_backup_YYYYMMDD_HHMMSS.tar.gz
├── url-health-check-pre-backup-YYYYMMDD_HHMMSS.log
└── url-health-check-post-backup-YYYYMMDD_HHMMSS.log
```
### Production
```
./reports/
├── production-health-report-YYYYMMDD_HHMMSS.md
└── url-tests-production-YYYYMMDD_HHMMSS.log
```
## 🚨 Dépannage
### URLs Internes Non Accessibles
- Vérifier les services Docker : `docker ps`
- Consulter les logs : `docker logs <service_name>`
- Vérifier les ports et la configuration réseau
### URLs Externes Non Accessibles
- Vérifier la configuration nginx
- Vérifier les certificats SSL
- Vérifier la connectivité réseau externe
### APIs Non Accessibles
- Vérifier la configuration CORS
- Vérifier la connectivité vers `<BACKEND_BASE_URL>`
- Consulter les logs du backend
## 📚 Documentation Complète
Pour plus de détails, consultez :
- **`docs/scripts/URL-HEALTH-CHECKING.md`** : Documentation complète
- **`scripts/url-health-check.sh`** : Code source du script principal
- **`scripts/production-health-check.sh`** : Code source du script de production
---
**Créé le 2025-09-25**
**Version** : 1.0
**Usage** : Tests de santé LeCoffre Node

408
docs/TECHNICAL_REFERENCE.md
View File

@ -1,408 +0,0 @@
# Référence Technique Complète - 4NK Environment
**Date** : 2025-01-27
**Version** : 2.0
**Contexte** : Référence technique complète pour les développeurs et agents IA
## 📋 Vue d'ensemble Technique
Cette référence technique présente tous les détails techniques de l'environnement 4NK, incluant les configurations, dépendances, ports, et interfaces.
## 🔧 Modules 4NK - Référence Technique Complète
### 1. **sdk_relay** - Service de Relais WebSocket Central
**Technologie** : Rust (tokio, async-trait, futures-util)
**Ports** : 8090 (WebSocket), 8091 (HTTP health)
**Dépendances Rust** :
```toml
anyhow = "1.0"
async-trait = "0.1"
bitcoincore-rpc = { version = "0.18" }
env_logger = "0.9"
futures-util = { version = "0.3.28", default-features = false, features = ["sink", "std"] }
hex = "0.4.3"
log = "0.4.20"
sdk_common = { git = "https://git.4nkweb.com/4nk/sdk_common.git", rev = "e205229e", features = ["parallel", "blindbit-backend"] }
serde = { version = "1.0.193", features = ["derive"]}
serde_json = "1.0"
serde_with = "3.6.0"
tokio = { version = "1.0.0", features = ["io-util", "rt-multi-thread", "macros", "sync"] }
tokio-stream = "0.1"
tokio-tungstenite = "0.21.0"
zeromq = "0.4.1"
```
**Fonctionnalités** :
- Serveur WebSocket configurable
- Synchronisation mesh entre relais
- Gestion des processus et membres
- Interface avec Bitcoin Core (RPC + ZMQ)
- Intégration Blindbit pour Silent Payments
- Cache de déduplication
- Gestion d'état locale dans `~/<data_dir>`
**Configuration** : Fichier de configuration via `--config`
**Healthcheck** : `/health` sur port 8091
**Variables d'environnement** : RELAY_PORT, RELAY_HTTP_PORT, STORAGE_URL
### 2. **sdk_storage** - Service de Stockage Temporaire Sécurisé
**Technologie** : Rust (tide, async-std)
**Port** : 8081 (mappé depuis 8080)
**Dépendances Rust** :
```toml
tide = "0.16"
async-std = { version = "1", features = ["attributes"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
hex = "0.4"
env_logger = "0.10"
```
**API** :
- `POST /store` : Stockage avec clé/valeur/TTL
- `GET /retrieve/:key` : Récupération des données
**Fonctionnalités** :
- Stockage temporaire avec expiration
- Clés hexadécimales 64 caractères
- Valeurs hexadécimales
- TTL optionnel (permanent si non spécifié)
- Chiffrement des données
**Healthcheck** : `/health` sur port 8080
**Variables d'environnement** : STORAGE_PORT, STORAGE_DATA_DIR
### 3. **sdk_signer** - Service de Signature TypeScript
**Technologie** : TypeScript avec support WASM
**Fonctionnalités** :
- Gestion des processus et signatures
- Communication sécurisée
- Compatibilité WASM (stub temporaire)
- Interface avec le réseau de relais
- Validation des permissions
**Dépendances** : Node.js 18+, npm/yarn
**Architecture** : TypeScript avec support WASM
**État** : Compatible avec stub sdk_client
### 4. **sdk_client** - Client SDK Rust/WASM
**Technologie** : Rust avec interface WebAssembly
**Fonctionnalités** :
- Interface avec les services 4NK
- Gestion des connexions WebSocket
- Support des processus et transactions
- Compilation WASM pour le web
**Architecture** : Rust avec interface WASM
**Usage** : Importé par sdk_signer et autres clients
### 5. **sdk_common** - Bibliothèque Commune
**Technologie** : Rust
**Fonctionnalités** :
- Types et structures communes
- Utilitaires partagés
- Protocoles de communication
- Support Blindbit (feature: "blindbit-backend")
- Support parallèle (feature: "parallel")
**Usage** : Importé par tous les autres modules
**Features** : parallel, blindbit-backend
### 6. **sdk-signer-client** - Client Signeur
**Technologie** : TypeScript
**Fonctionnalités** :
- Interface avec sdk_signer
- Gestion des signatures
- Communication sécurisée
**Architecture** : TypeScript client
### 7. **ihm_client** - Interface Homme-Machine
**Technologie** : Vite + React
**Port** : 3003
**Fonctionnalités** :
- Interface de gestion des clés Bitcoin
- Gestion des processus
- Interface utilisateur web
- Variables d'environnement Vite
**Dépendances** : sdk_relay, sdk_storage
**Variables d'environnement** :
- VITE_JWT_SECRET_KEY
- VITE_API_BASE_URL
- VITE_WS_URL
- VITE_STORAGE_URL
- VITE_SIGNER_URL
- VITE_BOOTSTRAPURL
### 8. **4NK_vault** - Système de Gestion des Configurations
**Technologie** : Python Flask
**Port** : 6666 (HTTPS)
**Sécurité** :
- Authentification par clés utilisateur
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Rotation automatique des clés (toutes les heures)
- Isolation par environnement (dev, prod)
**Fonctionnalités** :
- Résolution des variables d'environnement
- Synchronisation vers `confs/` dans le docker de contrôle
- Protection des secrets
- Clés individuelles par utilisateur/environnement
**Endpoints** :
- `GET /health` - Contrôle de santé
- `GET /info` - Informations API
- `GET /routes` - Routes disponibles
- `GET /<env>/<file>` - Fichier chiffré
**Déploiement** : Synchronise les configurations vers `confs/`
### 9. **4NK_certificator** - Service d'Ancrage Cryptographique
**Technologie** : Rust
**Fonctionnalités** :
- Surveillance des messages du relay 4NK
- Détection des paiements Bitcoin
- Enregistrement périodique sur blockchain
- Métriques de volume de données
- Base de données SQLite
**Architecture** : Rust avec base de données SQLite
**État** : MVP complet implémenté
**Composants** :
- RelayMonitor (surveillance WebSocket)
- PaymentWatcher (surveillance Bitcoin)
- Base de données SQLite
### 10. **4NK_miner** - Service de Minage
**Technologie** : Rust
**Fonctionnalités** :
- Minage sur réseau Signet
- Génération de blocs de test
- Interface avec le réseau Bitcoin
**Usage** : Développement et tests uniquement
### 11. **4NK_web_status** - Service de Statut
**Technologie** : Python Flask
**Port** : 3006
**Fonctionnalités** :
- Monitoring des services
- Interface de statut
- Métriques de santé
- API REST pour le statut
**Dépendances** : Docker socket, logs directory
**Variables d'environnement** : STATUS_API_PORT, STATUS_API_HOST
### 12. **blindbit-oracle** - Oracle Bitcoin Silent Payments
**Technologie** : Rust
**Port** : 8000
**Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Interface HTTP REST
- Scan filtré BIP158
**Dépendances** : Bitcoin Core
**Configuration** : blindbit.toml
**Variables d'environnement** : BLINDBIT_API_PORT, BITCOIN_RPC_URL
### 13. **rust-silentpayments** - Implémentation Silent Payments
**Technologie** : Rust
**Fonctionnalités** :
- Génération d'adresses Silent Payments
- Validation des transactions
- Utilitaires cryptographiques
**Usage** : Bibliothèque pour blindbit-oracle
## 🏢 Projet LeCoffre - Référence Technique Complète
### 1. **lecoffre_node** - Orchestrateur Principal
**Architecture** : Docker Compose avec Nginx intégré
**Services déployés** :
- **tor** (btcpayserver/tor:0.4.8.10) - Proxy anonyme
- **bitcoin** (build: ./bitcoin) - Nœud Bitcoin Signet
- **blindbit** (git.4nkweb.com/4nk/blindbit-oracle:fixed-source) - Oracle Bitcoin
- **sdk_relay** (git.4nkweb.com/4nk/sdk_relay:ext) - Relais WebSocket
- **sdk_storage** (git.4nkweb.com/4nk/sdk_storage:ext) - Stockage temporaire
- **lecoffre-front** (git.4nkweb.com/4nk/lecoffre-front:ext) - Frontend Next.js
- **ihm_client** (git.4nkweb.com/4nk/ihm_client:ext) - Interface utilisateur
- **grafana** (grafana/grafana:latest) - Monitoring
- **loki** (grafana/loki:latest) - Collecte de logs
- **promtail** (grafana/promtail:latest) - Agent de collecte
- **status-api** (build: 4NK_web_status) - API de statut
- **watchtower** (containrrr/watchtower) - Mise à jour automatique
- **signet_miner** (build: 4NK_miner) - Minage (profile: miner)
**Configuration** : Centralisée dans `confs/` (synchronisée depuis 4NK_vault)
**Déploiement** : Scripts automatisés avec phases de démarrage
**Réseau** : btcnet (172.20.0.0/16)
**Volumes** : Persistance des données (bitcoin_data, blindbit_data, sdk_data, etc.)
### 2. **lecoffre-front** - Interface Utilisateur
**Technologie** : Next.js avec React
**Port** : 3004 (mappé depuis 8080)
**Fonctionnalités** :
- Interface utilisateur pour les notaires
- Gestion des documents
- Intégration avec l'écosystème 4NK
- Variables d'environnement Next.js
**Variables d'environnement** :
- NEXT_PUBLIC_API_URL
- NEXT_PUBLIC_4NK_URL
- NEXT_PUBLIC_4NK_IFRAME_URL
- NEXT_PUBLIC_IDNOT_BASE_URL
**Déploiement** : Conteneur Docker sur port 3004
**User** : lecoffreuser (non-root)
### 3. **lecoffre-back-mini** - Backend Centralisé
**Déploiement** : Sur dev3.4nkweb.com
**Fonctionnalités** :
- APIs avec Stripe (paiements)
- Intégration Mailchimp (email marketing)
- Intégration OVH (SMS)
- Intégration IdNot (HMR dev3 ↔ dev4 via OAuth2)
**Architecture** : Service centralisé indépendant
**APIs** :
- `/api/v1/health` - Santé du service
- `/api/v1/status` - Statut du service
- `/api/v1/idnot/state` - État IdNot
## 🌐 Architecture de Déploiement - Référence Technique
### Environnements et URLs
- **dev4.4nkweb.com** : Machine principale (LeCoffre)
- **dev3.4nkweb.com** : Nœud de bootstrap (signer centralisé, mini back)
### URLs et Services
- **LeCoffre Front** : https://dev4.4nkweb.com/lecoffre
- **4NK iframe** : https://dev4.4nkweb.com
- **Signer centralisé** : dev3.4nkweb.com (module 4NK pour notaires)
- **Mini back** : dev3.4nkweb.com (APIs Stripe, Mailchimp, OVH, IdNot)
### Architecture de Déploiement par Phases
#### Phase 1: Services de Base (Parallèle)
- **tor** : Proxy anonyme (btcpayserver/tor:0.4.8.10)
- **sdk_storage** : Stockage temporaire (git.4nkweb.com/4nk/sdk_storage:ext)
- **status-api** : API de statut (build: 4NK_web_status)
#### Phase 2: Services Blockchain (Séquentiel)
- **bitcoin** → **blindbit** → **sdk_relay**
- Chaîne de dépendances blockchain respectée
#### Phase 3: Services Applicatifs (Séquentiel)
- **lecoffre-front** : Frontend Next.js
- **ihm_client** : Interface utilisateur
- Dépendances : sdk_relay + sdk_storage
#### Phase 4: Services de Monitoring (Indépendant)
- **loki** → **promtail** → **grafana**
- Chaîne de dépendances monitoring
#### Phase 5: Services Utilitaires
- **watchtower** : Mise à jour automatique (interval: 30s)
## 🔐 Sécurité et Configuration - Référence Technique
### 4NK_vault - Gestion Centralisée des Configurations
- **Rôle** : API sécurisée pour la gestion des configurations
- **Sécurité** :
- Chiffrement quantique résistant (ChaCha20-Poly1305)
- Authentification par clés utilisateur
- Rotation automatique des clés (toutes les heures)
- Isolation par environnement (dev, prod)
- **Déploiement** : Synchronise vers `confs/` dans le docker de contrôle
- **Protection des secrets** : Fichiers .env inaccessibles, variables séparées
### Variables d'Environnement par Service
- **bitcoin** : BITCOIN_RPC_USER, BITCOIN_RPC_PASSWORD, BITCOIN_RPC_PORT
- **blindbit** : BLINDBIT_API_PORT, BITCOIN_RPC_URL
- **sdk_relay** : RELAY_PORT, RELAY_HTTP_PORT, STORAGE_URL
- **sdk_storage** : STORAGE_PORT, STORAGE_DATA_DIR
- **lecoffre-front** : NEXT_PUBLIC_API_URL, NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_IDNOT_BASE_URL
- **ihm_client** : VITE_API_URL, VITE_4NK_URL, VITE_RELAY_URL
- **grafana** : GF_SECURITY_ADMIN_PASSWORD, GF_DATABASE_TYPE
- **loki** : LOKI_CONFIG_FILE, LOKI_DATA_DIR
- **promtail** : PROMTAIL_CONFIG_FILE, LOKI_URL
- **status-api** : STATUS_API_PORT, STATUS_API_HOST
## 📊 Monitoring et Observabilité - Référence Technique
### Stack de Monitoring
- **Grafana** (grafana/grafana:latest) : Dashboards et visualisation
- **Loki** (grafana/loki:latest) : Collecte et stockage des logs
- **Promtail** (grafana/promtail:latest) : Agent de collecte des logs
- **Watchtower** (containrrr/watchtower) : Mise à jour automatique
### Configuration Loki (CRITIQUE)
- **OBLIGATOIRE** : `http_listen_address: 0.0.0.0` (pas 127.0.0.1)
- **OBLIGATOIRE** : `instance_addr: 0.0.0.0` (pas 127.0.0.1)
- **Fichier** : `/conf/loki/loki-config.yaml`
- **Healthcheck** : `wget` (pas `curl`)
### Dashboards Disponibles
- Vue d'ensemble LeCoffre
- Bitcoin & Miner
- Services Applications
- SDK Services
- Frontend Services
### Logs Centralisés
- **Répertoire** : `/home/debian/4NK_env/projects/lecoffre/lecoffre_node/logs/`
- **Services** : tor, bitcoin, blindbit, sdk_relay, sdk_storage, lecoffre-front, ihm_client, grafana, loki, promtail, status-api
- **Collecte** : Promtail → Loki → Grafana
## 🔄 CI/CD et Déploiement - Référence Technique
### Branches et Tags
- **Branche unifiée** : `ext` pour tous les dépôts 4NK
- **Branches spéciales** : `main` pour 4NK_certificator, 4NK_miner, 4NK_web_status
- **Tag Docker** : `ext` pour toutes les images
- **Déclenchement** : Push sur `ext` → Build automatique
### Scripts de Déploiement Détaillés
- **start.sh** : Démarrage complet avec phases et progression
- **validate-deployment.sh** : Validation complète du déploiement
- **maintenance.sh** : Menu de maintenance interactif
- **backup-data.sh** : Sauvegarde des données
- **update-images.sh** : Mise à jour sécurisée
- **collect-logs.sh** : Collecte des logs
- **deploy-grafana.sh** : Déploiement du monitoring
- **sync-configs.sh** : Synchronisation des configurations
### Healthchecks Détaillés
- **tor** : tor-progress.sh (bootstrap %)
- **bitcoin** : bitcoin-progress.sh (IBD, blocks, headers)
- **blindbit** : blindbit-progress.sh (API, scan)
- **sdk_relay** : sdk-relay-progress.sh (WebSocket, health)
- **sdk_storage** : curl /health
- **lecoffre-front** : ps aux | grep next-server
- **ihm_client** : curl localhost:3003
- **grafana** : curl /api/health
- **loki** : wget /ready
- **promtail** : fichier positions.yaml
- **status-api** : curl /api
## 🎯 Points Clés de l'Architecture Technique
### 1. **Séparation des Responsabilités**
- Services applicatifs indépendants du monitoring
- Monitoring observant sans impacter
- Dépendances uniquement métier
### 2. **Sécurité Multi-Niveaux**
- 4NK_vault pour la gestion centralisée des configurations
- Chiffrement quantique résistant
- Isolation des secrets et variables
- Utilisateurs non-root dans les conteneurs
### 3. **Déploiement Optimisé**
- Phases de démarrage respectées
- Scripts spécialisés obligatoires
- Surveillance continue et diagnostic facilité
- Healthchecks informatifs
### 4. **Maintenance Facilitée**
- Redémarrage sélectif possible
- Scripts de maintenance interactifs
- Documentation centralisée et à jour
- Logs centralisés et structurés
### 5. **Architecture Modulaire**
- 13 modules 4NK avec rôles spécialisés
- Projet LeCoffre : Interface notariale
- 4NK_vault : Gestion centralisée des configurations
- Scripts centralisés et réutilisables
---
**Document créé le 2025-01-27**
**Version** : 2.0
**Usage** : Référence technique complète pour les développeurs et agents IA

196
docs/VARIABLES-ENVIRONNEMENT-NOUVELLE-STRUCTURE.md
View File

@ -1,196 +0,0 @@
# Nouvelle Structure des Variables d'Environnement
## Vue d'ensemble
La structure des variables d'environnement a été réorganisée pour séparer les variables par projet. Cette nouvelle architecture améliore la maintenabilité et la sécurité en isolant les configurations de chaque service.
## Structure Actuelle
```
4NK_env/
├── env/
│ ├── lecoffre_node/
│ │ └── .env
│ ├── sdk_relay/
│ │ └── .env
│ ├── sdk_storage/
│ │ └── .env
│ ├── ihm_client/
│ │ └── .env
│ ├── lecoffre-front/
│ │ └── .env
│ ├── blindbit-oracle/
│ │ └── .env
│ ├── monitoring/
│ │ └── .env
│ └── sdk_signer/
│ └── .env
└── .env.master (conservé pour compatibilité)
```
## Projets et Variables
### 1. lecoffre_node
**Fichier**: `env/lecoffre_node/.env`
**Variables principales**:
- Configuration des domaines (DOMAIN, BOOTSTRAP_DOMAIN, etc.)
- Configuration Git (GITEA_BASE_URL, GIT_TOKEN, etc.)
- Configuration IDNOT (IDNOT_API_KEY, IDNOT_CLIENT_ID, etc.)
- Configuration serveur (APP_HOST, API_BASE_URL, etc.)
### 2. sdk_relay
**Fichier**: `env/sdk_relay/.env`
**Variables principales**:
- SDK_RELAY_* (SDK_RELAY_CORE_URL, SDK_RELAY_WS_URL, etc.)
- Variables legacy (core_url, ws_url, etc.)
- Configuration des ports (RELAY_PORT, RELAY_HTTP_PORT)
### 3. sdk_storage
**Fichier**: `env/sdk_storage/.env`
**Variables principales**:
- STORAGE_URL, STORAGE_PORT, STORAGE_DATA_DIR
### 4. ihm_client
**Fichier**: `env/ihm_client/.env`
**Variables principales**:
- VITE_* (VITE_API_BASE_URL, VITE_WS_URL, etc.)
- VITE_JWT_SECRET_KEY (variable sensible)
### 5. lecoffre-front
**Fichier**: `env/lecoffre-front/.env`
**Variables principales**:
- NEXT_PUBLIC_* (NEXT_PUBLIC_4NK_URL, NEXT_PUBLIC_IDNOT_BASE_URL, etc.)
- NEXT_PUBLIC_IDNOT_CLIENT_ID (variable sensible)
### 6. blindbit-oracle
**Fichier**: `env/blindbit-oracle/.env`
**Variables principales**:
- BLINDBIT_API_PORT, BITCOIN_RPC_URL
### 7. monitoring
**Fichier**: `env/monitoring/.env`
**Variables principales**:
- Configuration Grafana (GRAFANA_ADMIN_USER, GRAFANA_ADMIN_PASSWORD, etc.)
- Configuration Loki (LOKI_URL, LOKI_CONFIG_FILE, etc.)
- Configuration Status API (STATUS_API_PORT, STATUS_API_HOST)
- Variables Bitcoin pour monitoring
### 8. sdk_signer
**Fichier**: `env/sdk_signer/.env`
**Variables principales**:
- SIGNER_* (SIGNER_PORT, SIGNER_DATABASE_PATH, etc.)
- SIGNER_API_KEY (variable sensible)
## Migration depuis .env.master
### Avant (Structure Monolithique)
```yaml
# docker-compose.yml
services:
sdk_relay:
env_file:
- /home/debian/4NK_env/.env.master
```
### Après (Structure Séparée)
```yaml
# docker-compose.yml
services:
sdk_relay:
env_file:
- /home/debian/4NK_env/env/sdk_relay/.env
```
## Avantages de la Nouvelle Structure
1. **Séparation des responsabilités**: Chaque projet a ses propres variables
2. **Sécurité améliorée**: Isolation des variables sensibles par service
3. **Maintenance facilitée**: Modification des variables sans impact sur les autres services
4. **Déploiement modulaire**: Possibilité de déployer des services indépendamment
5. **Debugging simplifié**: Variables spécifiques à un service dans un seul fichier
## Scripts de Gestion
### Ajout de Variables Manquantes
```bash
./scripts/add-missing-env-vars-new.sh
```
### Test de Configuration
```bash
./scripts/test-env-config.sh
```
### Démarrage des Services
```bash
./scripts/lecoffre_node/start.sh
```
## Variables Sensibles
Les variables marquées comme sensibles sont identifiées par la section :
```bash
# ================== /!\ sensible =========================
```
Ces variables contiennent :
- Clés API (IDNOT_API_KEY, SIGNER_API_KEY)
- Secrets JWT (VITE_JWT_SECRET_KEY)
- Identifiants clients (IDNOT_CLIENT_ID, NEXT_PUBLIC_IDNOT_CLIENT_ID)
- Mots de passe (IDNOT_CLIENT_SECRET, GRAFANA_ADMIN_PASSWORD)
## Compatibilité
Le fichier `.env.master` est conservé pour la compatibilité avec les anciens scripts, mais il est recommandé d'utiliser la nouvelle structure pour tous les nouveaux développements.
## Migration des Scripts Existants
Les scripts ont été mis à jour pour utiliser la nouvelle structure :
- `docker-compose.yml`: Pointe vers les nouveaux fichiers .env
- `scripts/lecoffre_node/start.sh`: Vérifie les fichiers par projet
- `scripts/test-env-config.sh`: Teste la nouvelle structure
## Recommandations
1. **Ne jamais modifier les valeurs des variables** sans validation préalable
2. **Utiliser les scripts de gestion** pour ajouter/modifier des variables
3. **Tester la configuration** après chaque modification
4. **Maintenir la cohérence** entre les fichiers .env et la documentation
5. **Sauvegarder** avant toute modification importante
## Troubleshooting
### Problème : Service ne trouve pas ses variables
**Solution**: Vérifier que le fichier .env correspondant existe dans `env/<service>/.env`
### Problème : Variables manquantes
**Solution**: Utiliser le script `add-missing-env-vars-new.sh`
### Problème : Conflit de variables
**Solution**: Vérifier que les variables sont dans le bon fichier projet
## Maintenance
### Ajout d'un Nouveau Service
1. Créer le dossier `env/<nouveau_service>/`
2. Créer le fichier `.env` avec les variables nécessaires
3. Mettre à jour `docker-compose.yml`
4. Mettre à jour les scripts de test
5. Documenter les variables dans ce fichier
### Suppression d'un Service
1. Sauvegarder le fichier .env
2. Supprimer le dossier `env/<service>/`
3. Mettre à jour `docker-compose.yml`
4. Mettre à jour les scripts de test
5. Mettre à jour la documentation

104
docs/idnot-front-agnostic.md
View File

@ -1,104 +0,0 @@
IdNot front-agnostic flow (durable setup)
Overview
- Goal: Backend is agnostic of the frontend, supports any domain and localhost. IdNot keeps the fixed redirect_uri, Nginx forwards to backend, backend returns to the real frontend with an authToken in the fragment.
Data flow
1) Frontend (Next.js) requests state
- POST https://dev3.4nkweb.com/api/v1/idnot/state
- Body: { next_url: <absolute URL to /authorized-client of the current front> }
- Returns: { state }
2) Frontend builds authorize URL and redirects
- authorize = ${NEXT_PUBLIC_IDNOT_BASE_URL}${NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT}
- query: client_id, redirect_uri = NEXT_PUBLIC_IDNOT_REDIRECT_URI_FIXED, scope=openid,profile, response_type=code, state
3) IdNot redirects to the fixed redirect
- https://lecoffreio.4nkweb.com/authorized-client?code=...&state=...
4) Nginx (dev4) 301 → dev3 backend callback
- https://dev3.4nkweb.com/idnot/callback?code=...&state=...
5) Backend callback
- Verifies state (HMAC, TTL, nonce, host allowlist)
- Exchanges code with IdNot
- Creates session/authToken
- 302 → next_url#authToken=...
Frontend requirements
- Expose runtime variables in Next.js (NEXT_PUBLIC_*):
- NEXT_PUBLIC_IDNOT_BASE_URL=https://qual-connexion.idnot.fr
- NEXT_PUBLIC_IDNOT_AUTHORIZE_ENDPOINT=/IdPOAuth2/authorize/ (or provider-specific)
- NEXT_PUBLIC_IDNOT_CLIENT_ID=<from IdNot>
- NEXT_PUBLIC_IDNOT_REDIRECT_URI_FIXED=https://lecoffreio.4nkweb.com/authorized-client
- NEXT_PUBLIC_FRONT_APP_HOST=https://dev4.4nkweb.com/lecoffre
- NEXT_PUBLIC_BACK_BASE=https://dev3.4nkweb.com
- Login button flow (simplified):
1) POST ${NEXT_PUBLIC_BACK_BASE}/api/v1/idnot/state { next_url: window.location.origin + '/authorized-client' }
2) On {state}, redirect to authorize with &state=
- Callback page
- Read authToken from window.location.hash
- Store token then clear hash
Backend requirements (summary)
- Env:
- BACK_HMAC_SECRET=<random-long-hex>
- STATE_TTL_SECONDS=180
- ALLOW_LOCALHOST_REDIRECTS=true
- ALLOWED_REDIRECT_HOST_PATTERNS=^dev4\.4nkweb\.com$,^localhost$,^127\.0\.0\.1$
- Endpoints:
- POST /api/v1/idnot/state → returns signed state with {next_url, nonce, ts}
- GET /idnot/callback → verifies state, exchanges code, then 302 to next_url#authToken=...
Curl note (important)
- When testing with curl, ensure a valid JSON body is actually sent. Some shells/options can result in an empty or malformed body, causing HTTP 500.
- Use Content-Type: application/json and --data-binary, for example:
curl -i -m 8 -X POST "https://dev3.4nkweb.com/api/v1/idnot/state" \
-H "Origin: https://lecoffreio.4nkweb.com" \
-H "Content-Type: application/json" \
--data-binary '{"next_url":"https://lecoffreio.4nkweb.com/authorized-client"}'
Nginx notes
- On dev4 (front): host lecoffreio.4nkweb.com must return 301 to dev3 callback, preserving full query string.
- On dev3 (back): proxy /idnot/callback and /api/ to the backend server.
Docker Compose (durable)
- Build lecoffre-front locally to ensure latest code and env are used:
lecoffre-front:
build:
context: ../lecoffre-front
dockerfile: Dockerfile
env_file:
- .env.master
- Keep .env.master at lecoffre_node/.env.master and include the NEXT_PUBLIC_* variables above. See .env.master.example.
Testing checklist
- On login:
- Network shows POST /api/v1/idnot/state before redirect
- IdNot authorize URL contains &state=
- dev3 /idnot/callback returns 302 to next_url#authToken=...
- Front stores token and proceeds
Security considerations
- HMAC-signed state with TTL and nonce (anti-replay)
- Strict host allowlist for next_url and localhost allowed only if ALLOW_LOCALHOST_REDIRECTS=true
- Prefer fragment (#authToken) to avoid logging tokens in proxies
Operations
- To rebuild and restart only the frontend after changes:
docker compose build lecoffre-front
docker compose up -d --no-deps --force-recreate lecoffre-front

39
docs/ihm_client/ANALYSE.md
View File

@ -1,39 +0,0 @@
## 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
View File

@ -1,21 +0,0 @@
# 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
View File

@ -1,40 +0,0 @@
# 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
View File

@ -1,23 +0,0 @@
# 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
View File

@ -1,10 +0,0 @@
# 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
View File

@ -1,17 +0,0 @@
# 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
View File

@ -1,35 +0,0 @@
# 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
View File

@ -1,6 +0,0 @@
# 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
View File

@ -1,6 +0,0 @@
# 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
View File

@ -1,22 +0,0 @@
# 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
View File

@ -1,6 +0,0 @@
# 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
View File

@ -1,124 +0,0 @@
# 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
View File

@ -1,31 +0,0 @@
### 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

Some files were not shown because too many files have changed in this diff Show More