Déploiement de la CNP sur `cnp-control` (VM Oracle)¶

Ce guide documente le déploiement de la plateforme CNP (backend FastAPI + Postgres + frontend) sur la VM Oracle Cloud cnp-control, et la procédure de redéploiement pour l'équipe (4K-61).

Règle critique¶

Ne jamais éteindre, redémarrer ou supprimer la VM cnp-control. Elle tourne en free tier OCI (Ampere A1, ARM64) et est très difficile à reprovisionner si elle est perdue. Toute opération sur l'instance (stop/terminate/reboot) doit être validée explicitement au préalable.

État actuel¶

VM : Oracle Cloud, Ubuntu 22.04 ARM64 (aarch64), 4 Go RAM, 45 Go disque
Code : cloné dans ~/cloud-native-plat4k (branche main) via une deploy key SSH dédiée (~/.ssh/id_ed25519_github)
Stack : docker compose — db, backend, frontend, pgadmin, vault (profile production)
Exposition : HTTPS public via Cloudflare Tunnel (cloudflared.service) — https://cnp.cloud-native-plat4k.me
Firewall : UFW actif, seul le port 22 (SSH) est ouvert en entrée
Secrets : gérés par HashiCorp Vault — bootstrappé au premier démarrage, policy cnp-backend créée, token applicatif en place (root token non utilisé par le backend)
.env : permissions 600, non versionné — contient uniquement les variables nécessaires au démarrage de l'infra (voir section Gestion des secrets)

Accès à la plateforme¶

URL publique : https://cnp.cloud-native-plat4k.me
Via tunnel SSH (développement/debug) :
```
ssh -i ~/.ssh/oci_a1 -L 8080:localhost:80 -L 8000:localhost:8000 ubuntu@<IP_VM>
```
Frontend : http://localhost:8080 / API : http://localhost:8000/api/v1

Prérequis sur la VM (déjà fait, pour référence)¶

Docker Engine + plugin Compose installés via le repo officiel Docker (docker-ce, docker-compose-plugin)
Utilisateur ubuntu ajouté au groupe docker
Clé SSH dédiée ~/.ssh/id_ed25519_github ajoutée comme clé d'authentification sur le compte GitHub
cloudflared installé et configuré en service systemd (/etc/systemd/system/cloudflared.service)
UFW activé (ufw allow 22/tcp, ufw default deny incoming)

Procédure de redéploiement (nouvelle version)¶

Se connecter à la VM :
```
ssh -i ~/.ssh/oci_a1 ubuntu@<IP_VM>
```

Récupérer la dernière version du code :

cd ~/cloud-native-plat4k
git fetch origin && git checkout main && git pull

Vérifier si .env.example a évolué (nouvelles variables à ajouter manuellement dans .env si besoin) :
```
git diff HEAD@{1} HEAD -- .env.example
```
Rebuild et redémarrage des conteneurs :
```
docker compose up -d --build
```
Les migrations Alembic sont appliquées automatiquement au démarrage du backend (entrypoint).

Vérifier l'état :

docker compose ps
curl -s http://localhost:8000/api/v1/health/
curl -s https://cnp.cloud-native-plat4k.me/api/v1/health/

En cas de problème, consulter les logs :

docker compose logs backend --tail 100
docker compose logs vault --tail 50

Procédure post-reboot¶

ATTENTION : Après tout redémarrage de la VM (même involontaire), Vault repart en état Sealed et le backend refuse de démarrer. Il faut impérativement unsealer Vault avant de relancer les services.

cd ~/cloud-native-plat4k

# 1. Unsealer Vault (3 clés sur 5, à effectuer depuis votre gestionnaire de mots de passe d'équipe)
docker compose exec -e VAULT_ADDR=http://127.0.0.1:8200 vault vault operator unseal <clé_1>
docker compose exec -e VAULT_ADDR=http://127.0.0.1:8200 vault vault operator unseal <clé_2>
docker compose exec -e VAULT_ADDR=http://127.0.0.1:8200 vault vault operator unseal <clé_3>

# 2. Vérifier que Vault est bien unsealed (Sealed: false)
docker compose exec -e VAULT_ADDR=http://127.0.0.1:8200 vault vault status

# 3. Relancer le reste de la stack
docker compose up -d

Note : Vault démarre automatiquement au boot via le profile production (docker compose le gère), mais démarre toujours sealed. Les étapes 1-2 ci-dessus sont donc nécessaires à chaque reboot.

Gestion des secrets¶

Vault est le point de vérité pour tous les secrets de la plateforme. Le .env sur la VM ne contient que les variables strictement nécessaires à l'infrastructure Docker :

Variables à conserver dans .env :

# Nécessaires au conteneur db (Postgres)
POSTGRES_USER=cnpuser
POSTGRES_PASSWORD=cnppass
POSTGRES_DB=cnp

# Connexion à Vault (backend) — token applicatif avec policy cnp-backend (pas le root token)
VAULT_ADDR=http://vault:8200
VAULT_TOKEN=hvs.xxxxxxxxxxxx

# Orchestration docker-compose
COMPOSE_FILE=docker-compose.yml:docker-compose.override.yml:docker-compose.tunnel.yml

Tout le reste (SECRET_KEY, ENCRYPTION_KEY, GITLAB_*, PROMETHEUS_URL, etc.) est lu depuis Vault au démarrage du backend — ne pas les remettre dans .env.

Pour la gestion des secrets Vault (rotation, policy, unseal keys), voir vault-runbook.md.

Cloudflare Tunnel¶

Le tunnel est géré par cloudflared.service (systemd). Il démarre automatiquement au boot et survit aux déconnexions SSH.

# Vérifier l'état du tunnel
sudo systemctl status cloudflared

# Logs du tunnel
sudo journalctl -u cloudflared --no-pager -n 50

L'URL https://cnp.cloud-native-plat4k.me est un tunnel nommé (stable) — elle ne change pas au redémarrage.

Déploiement de la CNP sur cnp-control (VM Oracle)¶