lecoffre_node/IA_agents/deploy.md

agent_deploy.md

Informations critiques à respecter totalement et impérativemment.

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 local.4nkdev.com qui sera redirigé vers @https://dev4.4nkweb.com/lecoffre avec l'ouverture de l'iframe @https://dev4.4nkweb.com/ (ihm_client).

Analyse le contenu de lecoffre_node/IA_agents/flux.md pour comprendre les flux. Met à jour ce flux si tu détecte des incohérences ou pose des questions pour confirmer.

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.

Dans tous les projets :

• Une branche Git dédiée ext existe.
• Aucun tag Git nommé ext n’existe.
• Des images Docker avec le tag ext existent.
• Les images Docker ne sont build que via CI qui est la seule à pousser sur le registry ou pour test localement.
• Aucun Dockerfile ne doit utiliser de clés ssh car aucun repos n'est privé, utiliser HTTPS.
• Les services doivent écouter sur 0.0.0.0 (et non sur 127.0.0.1).
• Corrige aussi les erreurs non critiques.

Dépendances :

• image: btcpayserver/tor:0.4.8.10 (pour synchro Bitcoin)
• image: git.4nkweb.com/4nk/bitcoin:latest (pour mainchain et signet custom)
• image: git.4nkweb.com/4nk/blindbit-oracle:dev (pour scan des blocs et détection des secrets dans les transaction silent payment)
• image: containrrr/watchtower (pour la surveillance et mise à jour automatique des images)

Projets locaux avec Dockerfile à déployer par lecoffre_node/ (d'autres projets externes sont ne dépendance dans le lecoffre_node/docker-compose.yml):

• sdk_relay/ (relai des transations et messages et oracle)
• sdk_signer/ (signature des processus métier et des identités/profils)
• sdk_storage/ (stockage temporaire)
• ihm_client/ (iframe dans les frontend des projets pour interactions avec les clés privés Bitcoin Silent Payment)
• lecoffre-back-mini/ (backend pour les API tierces du projet lecoffre)
• lecoffre-front/ (frontend du projet lecoffre)

Projets locaux sans Dockerfile à vérifier lecoffre_node/:

• sdk_common/ (coeur de la gestion des clés)
• sdk_client/ (coeur de l'intégration du système de process)
• sdk-signer-client/ (coeur de l'intégration du système de process pour l'intégration)

---

Procédure générale

Vérifications initiales

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 ext.
4. Mettre à jour les dépendances.
5. Vérifier les variables d’environnement.

Mise à jour et construction

6. Construire 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

11. Synchroniser les configurations dans lecoffre_node/conf.
12. Synchroniser les logs dans lecoffre_node/logs (brancher grafana pour un dashboard par projet)

Sécurité et conformité

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

14. Pousser toutes les modifications sur la branche Git ext.
15. Supprimer les fichiers distants non suivis par Git.

Analyse et correction

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

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 ext.
28. Supprimer à nouveau les fichiers distants non suivis.
29. Répéter analyse des logs, corrections, tests jusqu'à un déploiement parfait.

---

Spécificités Dockerfile

Pour tous les projets contenant un Dockerfile, avant de pousser sur la branche ext :

• Mettre à jour le Dockerfile pour maîtriser les prérequis :
  • inclure sudo apt update && sudo apt upgrade,
  • installer build-essential, autoconf, automake, libtool, pkg-config, cmake, ninja-build, clang, lldb, lld, make, tree, ncdu, mc, exuberant-ctags, cscope, vim, emacs, jq, curl, sed, gawk, inetutils-tools, iputils-*, net-tools, iproute2
  • installer python3 (dernière version) et mettre à jour
  • installer go (dernière version) et mettre à jour
  • installer rust (dernière version) et mettre à jour
  • installer npm (dernière version), instaler wscat (dernière version) et mettre à jour
• Construire l’image pour test.
• Vérifier .dockerignore.
• Vérifier à l'absence de dépendances croisées ou dupliquée entre les projets, sinon mutualiser via d'autres projets/docker

Après le push sur la branche Git ext :

• Pousser l’image sur le tag Docker ext via la CI.

---