CAPBE-AGRO — Kit d'interaction et d'évolution

📄 Source : CAPBE-AGRO/README.md 🕒 Généré le 06/08/2026 09:56
Sommaire

Ce répertoire est le kit autonome de l'application capbe-agro (ex-agroworoba), migrée dans l'architecture CAPBE (Incus) via playbook/12-migrate-projects.sh. Il centralise les fichiers qui ont permis cette migration, adaptés pour interagir avec l'application au quotidien et faire évoluer le projet (avec IA ou sans).

Tous les scripts s'exécutent sur le serveur de production (root + Incus). Ils sont idempotents et lecture seule par défaut — toute action d'écriture exige un drapeau explicite ou un script deploy/.

🗺️ Carte d'identité (état réel constaté)

Composant Accès
Frontend Flutter conteneur capbe-agro (nginx :80, /var/www/html) https://agro.app.ci.capbe.ovh
API FastAPI conteneur capbe-pgis/srv/agro/api port 8001 (service agro-api)
Base API agro_api sur capbe-pgis (rôle app) réseau privé 10.10.10.0/24 uniquement
Tenant Odoo base agro sur capbe-pgis (rôle odoo), servie par capbe-odoo https://agro.ci.capbe.ovh
Routage/TLS conteneur capbe-caddy On-Demand TLS (wildcards DNS)
Source dev CAPBE-AGRO/src/ (intégré au kit) backend + frontend + docs + .env
Héritage conteneur agroworobadécommissionné (supprimé, voir POST-DEPLOY.md §6) aucun résidu (cron / sauvegarde / conteneur)

🔀 Flux applicatif

https://agro.app.ci.capbe.ovh  (Caddy → TLS)
   ├── /            → capbe-agro:80        (front Flutter statique)
   └── /api/*       → capbe-pgis:8001      (API agro, même-origine)
                        └─ base agro_api (PostgreSQL 18 sur pgis)
https://agro.ci.capbe.ovh   → capbe-odoo:8069 → base agro (tenant Odoo 19)

L'API agro sert ses routes sous /api/v1/* (pas de rewrite Caddy, contrairement à meca).

⚡ Commandes rapides (dans ce répertoire, en root)

sudo ./ops/status.sh            # état complet : conteneurs, service, bases, endpoints
sudo ./ops/smoke-agro.sh        # validation dédiée (front + API + tenant Odoo)
sudo ./ops/monitor-agro.sh      # surveillance endpoints + sauvegardes (cron */5 + alerte mail)
sudo ./ops/logs.sh api          # journaux du service agro-api (api|front|odoo|all)
sudo ./ops/api.sh health        # appel API en lecture seule (--list pour les endpoints)
sudo ./ops/db.sh --tables       # tables de agro_api (--sql api|odoo "SELECT ...")
sudo ./ops/backup-agro.sh       # sauvegarde ciblée projet (/var/backups/capbe-agro)
# 💾 Automatisée : cron root « 45 2 * * * » (02h45, décalé de 10-backup.sh à 02h00)
#    → log : /var/log/capbe-agro-backup.log (garde flock anti-concurrence)
sudo ./ops/check-nightly.sh     # vérifie en 1 commande le run de nuit (--alert = mail si échec)
# ⏰ Automatisé : cron root « 35 7 * * * » (07h35) → log /var/log/capbe-check-nightly.log
sudo ./deploy/deploy-api.sh --pull   # code API → ./api-work/ (pour modification)
sudo ./deploy/deploy-api.sh --push   # code → pgis + restart agro-api
sudo ./deploy/deploy-front.sh        # publie le build Flutter (chemin par défaut défini dans lib/)
sudo ./deploy/migrate-agro.sh        # relance la migration agroworoba→agro (idempotent)

📂 Structure

CAPBE-AGRO/
├── lib/common-agro.sh   → bibliothèque : constantes projet + helpers (adaptée de lib/common.sh)
├── ops/                 → exploitation : status · smoke-agro · logs · api · db · backup-agro
├── deploy/              → évolutions : migrate-agro · deploy-api · deploy-front · caddy-agro.conf
├── docs/                → MIGRATION.md (récit technique) · EVOLUTIONS.md (guide des évolutions)
└── api-work/            → copie locale du code API (pull par deploy-api.sh, .env JAMAIS copié)

🔐 Sécurité

  • Aucun secret en clair : les scripts masquent les valeurs sensibles (redact) et ne poussent jamais le .env (il reste sur pgis, chmod 600).
  • Lecture seule par défaut : db.sh bloque tout non-SELECT sans --write ; deploy-api.sh ne pousse que sur --push explicite.
  • Les mots de passe ne transitent jamais en argument de commande.
  • Ce kit suit les conventions du playbook (set -euo pipefail, log/warn/err).

📚 Docs

  • docs/MIGRATION.md — comment agroworoba est devenu capbe-agro : architecture cible, étapes, pièges rencontrés en réel.
  • docs/EVOLUTIONS.md — guide pour faire évoluer le projet (API, front, Odoo), avec ou sans IA.