Environnements

KOHAMI cible trois environnements distincts, tous hébergés sur le même serveur dédié Scaleway à Paris (INV-T02). Chaque environnement a sa pile complète : API, runtime vocal, LiveKit, Inngest et sa propre base PostgreSQL.

Vue d'ensemble

Le domaine définitif (kohami.app) n'est pas encore enregistré ; en attendant, les environnements sont servis sur le wildcard public sslip.io, qui résout directement vers l'IP du serveur et permet des certificats Let's Encrypt valides.

La documentation (ce site) est servie par le même serveur : https://docs-dev.195-154-239-8.sslip.io.

Le TLS public est terminé par Caddy (ports 80/443, certificats Let's Encrypt automatiques). Seul l'environnement dev porte aujourd'hui l'application déployée ; les hostnames staging et prod sont déjà câblés dans le reverse-proxy et s'activeront à leur mise en service, sans changement d'URL côté clients.

Comportements spécifiques

dev

• Swagger UI accessible sur /docs (non protégé)
• Workloads applicatifs déployés sur k3s, redéployés automatiquement à chaque push develop
• Comptes de démonstration et fixtures de développement
• Logs verbeux

staging

• Endpoints de développement désactivés
• Données de recette JUWA (volume réduit)
• Configuration identique à prod, à destination de la validation contractuelle

prod

• Aucun endpoint de développement exposé, Swagger désactivé
• Données seniors réelles
• Sauvegarde continue PostgreSQL (WAL-G vers Object Storage, armée à la mise en service)

Gestion des secrets

Aucun secret n'est versionné dans le repo, et la CI n'en détient aucun pour l'infrastructure. La source canonique est le vault Ansible (infra/ansible/vault/secrets.yaml, chiffré avec ansible-vault, jamais commité en clair) :

1. Ansible déchiffre le vault au moment du provisioning et rend les fichiers d'environnement de chaque pile sur le serveur (permissions restrictives).
2. Pour l'environnement k3s, c'est aussi Ansible qui pose les secrets Kubernetes (clés LiveKit, environnement de l'API et du voice-agent, accès registre). Les manifests applicatifs appliqués par la CI ne contiennent aucune valeur sensible : un déploiement ne peut pas écraser une credential.
3. En développement local, un .env gitignoré par application fait foi.

Un garde-fou refuse d'appliquer les playbooks sur le serveur réel si le vault n'est pas déchiffré : impossible d'installer par accident les valeurs d'exemple du repo.

Détecter l'environnement runtime

Côté back-end, la variable KOHAMI_ENV est garantie présente. Côté clients, l'environnement se déduit de l'URL de base configurée au build (l'app mobile embarque EXPO_PUBLIC_API_URL, le dashboard VITE_API_URL).

Promotion entre environnements

Le pipeline courant :

1. Branche feat/... ou fix/..., ciblant develop (squash merge).
2. Avant tout merge, preuve sur pile locale complète : boot réel, tests, sonde de bout en bout.
3. Le push sur develop déclenche le workflow deploy-box : build des images (API et voice-agent), push au registre Scaleway, application des manifests k3s sur le serveur, migrations, puis smoke public. Le smoke exige un /v1/health à 200, la garde d'authentification, et l'enregistrement effectif du worker vocal auprès de LiveKit (un déploiement qui rendrait Helena muette échoue au lieu de passer au vert).
4. main reste le miroir de la production : release PR depuis develop avec tag, déploiement prod manuel (à l'activation de l'environnement).

Aller plus loin

• Operations Deploy, procédures de déploiement détaillées
• Authentification, récupération des credentials par environnement