338 lines
14 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.
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.
---
## 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`
- 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`)
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.
### 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`
- [ ] Mettre à jour les dépendances et les langages
- [ ] Vérifier les variables d'environnement centralisées dans `.env.master`
### Phase 2: Construction et optimisation
- [ ] si il y a eu des changements, Supprimer les caches et optimiser le build de chaque projet
- [ ] Mettre à jour la documentation
- [ ] Mettre à jour les tests
- [ ] Mettre à jour les scripts
- [ ] Vérifier les fichiers `.gitignore`, `.dockerignore`, `.cursorignore`
### Phase 3: Synchronisation
- [ ] Synchroniser les configurations dans `lecoffre_node/conf` (si utile)
- [ ] 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
### 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`.
### Phase 6: Tests et corrections
- [ ] Analyser les logs
- [ ] Corriger toutes les erreurs (sans désactivation, simplification, contournement)
- [ ] Tester
- [ ] Analyser à nouveau les logs
- [ ] Vérifier que les logs ne contiennent pas de données sensibles
- [ ] Corriger à nouveau si nécessaire (jusqu'à l'absence totale d'erreurs)
### Phase 7: Déploiement des services
- [ ] **IMPORTANT** : Utiliser UNIQUEMENT les scripts spécialisés, JAMAIS docker compose directement
- [ ] **Ordre de déploiement OBLIGATOIRE** :
- [ ] **Phase 1** : Services de base (parallèle) avec `./scripts/start-with-progress.sh`
- [ ] **Phase 2** : Services blockchain (séquentiel) avec `./scripts/start-with-progress.sh`
- [ ] **Phase 3** : Services applicatifs (séquentiel) avec `./scripts/start-with-progress.sh`
- [ ] **Phase 4** : Services de monitoring (indépendant) avec `./scripts/start-monitoring.sh`
- [ ] **Phase 5** : Services utilitaires avec `./scripts/start-with-progress.sh`
- [ ] **Scripts OBLIGATOIRES à utiliser** :
- [ ] `./scripts/start-with-progress.sh` : Démarrage complet avec phases
- [ ] `./scripts/start-monitoring.sh` : Démarrage monitoring indépendant
- [ ] `./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)
- [ ] **Dépendances** : Seules les dépendances métier sont respectées
- [ ] **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
- [ ] Corriger toutes les erreurs rencontrées
- [ ] Tester la connectivité externe
### Phase 8: Monitoring et validation
- [ ] S'assurer que Grafana est à jour
- [ ] Synchroniser la configuration Nginx et relancer le serveur
- [ ] Vérifier que Loki, Promtail et Grafana sont OK avec des dashboards alimentés
- [ ] Vérifier qu'il n'y a aucun conflit de ports
- [ ] Tester toutes les URLs publiques depuis l'extérieur
- [ ] Tester spécifiquement les WebSockets et services HTTP(S)
- [ ] 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
docker compose --env-file .env.master up -d
```
Variables disponibles :
- SDK_RELAY_* : Configuration du service relay
- 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
---
## 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
3. **Création dossier** : Créer un dossier en tant que notaire et ajouter un client
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
```bash
# ❌ JAMAIS utiliser directement
docker compose --env-file .env.master up -d
docker compose up -d
docker compose start
```
### ✅ OBLIGATOIRE - Utiliser uniquement ces scripts
```bash
# Démarrage complet avec phases (OBLIGATOIRE)
./scripts/start-with-progress.sh
# Démarrage monitoring indépendant (OBLIGATOIRE)
./scripts/start-monitoring.sh
# 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
# Test de configuration
./scripts/test-env-config.sh
# Test monitoring
./scripts/test-monitoring.sh
# 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
- Teste TOUTES les URLs publiques depuis l'extérieur avant de dire qu'elles sont OK
- Vérifie spécifiquement les WebSockets et services HTTP(S)
- Vérifie que tous les imports sont présents
- 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: lAPI peut renvoyer `000` depuis lhô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
4. status-api
**Phase 2: Services blockchain (séquentiel)**
5. bitcoin (attend tor)
6. blindbit (attend bitcoin)
7. sdk_relay (attend blindbit)
**Phase 3: Services applicatifs (séquentiel)**
9. lecoffre-front
10. ihm_client (attend sdk_relay + sdk_storage)
**Phase 4: Services de monitoring (séquentiel, indépendant)**
11. loki (base de données logs)
12. promtail (collecte logs → dépend de loki)
13. grafana (visualisation → dépend de loki + promtail)
**Phase 5: Services utilitaires**
14. watchtower
### 🔧 Principe architectural
- **Services applicatifs** : Fonctionnent indépendamment du monitoring
- **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
- [ ] Tests fonctionnels validés
- [ ] Tests techniques validés
- [ ] Monitoring opérationnel
- [ ] Aucune erreur dans les logs
- [ ] Configuration centralisée opérationnelle
- [ ] **Système de monitoring et progression opérationnel** :
- [ ] Healthchecks informatifs fonctionnels
- [ ] Scripts de monitoring opérationnels
- [ ] Progression Bitcoin IBD visible
- [ ] 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
3. Corrige sans désactivation, simplification ou contournement
4. Documente toute nouvelle connaissance technique ou fonctionnelle acquise
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.
---
## 📋 Instructions d'utilisation
### Pour l'agent IA
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
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 :
- [ ] Phase 1: Vérifications initiales
- [ ] Phase 2: Construction et optimisation
- [ ] Phase 3: Synchronisation
- [ ] Phase 4: Sécurité et conformité
- [ ] Phase 5: Gestion Git
- [ ] Phase 6: Tests et corrections
- [ ] Phase 7: Déploiement des services
- [ ] Phase 8: Monitoring et validation
---
## Autres consignes
**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`.