7472d72dc8
Le compose de prod et le .env ne sont pas versionnes (propres a l'hote) mais leur modele l'est desormais : docker-compose.prod.yml.example (entierement pilote par le .env, identique sur tout hote) et .env.prod.example (prod : APP_ENV=prod, HTTPS, mots de passe forts a renseigner). Permet un bootstrap par 'git pull + cp' sur le serveur, sans copier-coller fragile, et rend le deploiement reproductible. deployment.md mis a jour.
115 lines
4.5 KiB
Markdown
115 lines
4.5 KiB
Markdown
# Deploiement continu (CD) — Wakdo
|
|
|
|
Ce document decrit le deploiement automatique vers la production et la mise en place
|
|
a faire une seule fois cote serveur. Il complete `scripts/deploy.sh` et
|
|
`.forgejo/workflows/deploy.yml`.
|
|
|
|
## Topologie
|
|
|
|
| Hote | Role |
|
|
|---|---|
|
|
| **Thanos** (`git.acadenice.com`) | Forge : depot Git + Forgejo Actions |
|
|
| **Stark** | Environnement de dev ; heberge le runner Forgejo |
|
|
| **Vision** | Production : la stack Wakdo y tourne, cible du deploiement |
|
|
|
|
Le runner (sur Stark) n'a pas acces au socket Docker, par choix de securite : un job
|
|
CI ne peut pas piloter Docker sur son hote. Le deploiement vers Vision se fait donc
|
|
par SSH — ce qui correspond au schema normal d'un deploiement vers un hote distant.
|
|
|
|
## Flux
|
|
|
|
```
|
|
merge dev -> main (release, deja passee par la CI sur la PR)
|
|
│
|
|
▼
|
|
Forgejo Actions: workflow Deploy (.forgejo/workflows/deploy.yml)
|
|
│ ssh deploy@vision (sans commande : forced command cote Vision)
|
|
▼
|
|
Vision: scripts/deploy.sh (git ff-only -> VERSION + deploy.log -> compose build/up)
|
|
│
|
|
▼
|
|
GET /api/health renvoie le nouveau SHA ← preuve du deploiement
|
|
```
|
|
|
|
## Ce qui est automatise (dans le depot)
|
|
|
|
- `.forgejo/workflows/deploy.yml` : sur push `main`, ouvre la session SSH vers Vision.
|
|
- `scripts/deploy.sh` : recupere `main` (fast-forward), ecrit le marqueur de version
|
|
(`src/VERSION`) et une ligne dans `deploy.log`, reconstruit et recree la stack.
|
|
Mode non-interactif via `DEPLOY_YES=1`.
|
|
- `GET /api/health` expose `version` (SHA) et `deployed_at` (date), lus depuis
|
|
`src/VERSION`.
|
|
|
|
## Mise en place cote Vision (une fois)
|
|
|
|
Prerequis : Docker + docker compose, le depot clone (ex. `/srv/wakdo`).
|
|
|
|
Le compose et le `.env` de prod ne sont pas versionnes (propres a l'hote) ; ils se
|
|
derivent des modeles fournis dans le depot :
|
|
```bash
|
|
cp docker-compose.prod.yml.example docker-compose.prod.yml
|
|
cp .env.prod.example .env # puis renseigner domaines + mots de passe + reseau Traefik
|
|
docker compose -f docker-compose.prod.yml up -d --build
|
|
```
|
|
Le compose est entierement pilote par le `.env` : le meme fichier marche sur tout hote.
|
|
|
|
1. Creer un utilisateur dedie au deploiement, membre du groupe `docker` :
|
|
```bash
|
|
sudo useradd -m -G docker deploy
|
|
```
|
|
2. Lui donner le depot (ou ajuster les droits du clone existant) :
|
|
```bash
|
|
sudo chown -R deploy:deploy /srv/wakdo
|
|
```
|
|
3. Autoriser la cle CI avec une **forced command** : la cle ne peut lancer que le
|
|
deploiement, aucune autre commande. Dans `~deploy/.ssh/authorized_keys` :
|
|
```
|
|
command="cd /srv/wakdo && DEPLOY_YES=1 scripts/deploy.sh main",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...CLE_PUBLIQUE... deploy@wakdo-ci
|
|
```
|
|
`deploy.sh` ne lit pas `$SSH_ORIGINAL_COMMAND` : meme si un appel SSH tentait de
|
|
passer une autre commande, elle serait ignoree.
|
|
|
|
## Generer la cle et la connaitre cote forge
|
|
|
|
Sur un poste de confiance :
|
|
```bash
|
|
ssh-keygen -t ed25519 -f wakdo-deploy -C "deploy@wakdo-ci" -N ""
|
|
# wakdo-deploy -> cle PRIVEE (secret de la forge, ci-dessous)
|
|
# wakdo-deploy.pub -> cle PUBLIQUE (authorized_keys de Vision, etape 3)
|
|
|
|
ssh-keyscan -t ed25519 <hote-vision> # -> contenu du secret DEPLOY_KNOWN_HOSTS
|
|
```
|
|
|
|
## Secrets et variables a creer sur la forge
|
|
|
|
Depot -> Settings -> Actions -> Secrets / Variables :
|
|
|
|
| Type | Nom | Valeur |
|
|
|---|---|---|
|
|
| Secret | `DEPLOY_SSH_KEY` | contenu de la cle privee `wakdo-deploy` |
|
|
| Secret | `DEPLOY_KNOWN_HOSTS` | sortie de `ssh-keyscan` (cle d'hote de Vision) |
|
|
| Secret | `DEPLOY_HOST` | nom/IP de Vision |
|
|
| Variable | `DEPLOY_USER` | `deploy` |
|
|
|
|
## Verification
|
|
|
|
1. Faire une release (`dev -> main`).
|
|
2. Suivre le workflow **Deploy** dans l'interface de la forge (il se declenche au push
|
|
sur `main`).
|
|
3. Interroger la sonde et lire la version deployee :
|
|
```bash
|
|
curl -s https://<fqdn-admin-prod>/api/health
|
|
# { ... "version": "<sha>", "deployed_at": "<date>" }
|
|
```
|
|
Le `version` correspond au HEAD de `main` apres la release — preuve que Vision a ete
|
|
mise a jour sans intervention manuelle.
|
|
|
|
## Notes de securite
|
|
|
|
- Cle SSH dediee au seul deploiement, **forced command** + options `no-*` qui retirent
|
|
shell, tunnels et forwarding.
|
|
- Cle d'hote **epinglee** (`DEPLOY_KNOWN_HOSTS`, `StrictHostKeyChecking=yes`) : pas de
|
|
confiance a la premiere connexion.
|
|
- Secrets stockes cote forge, hors du depot. `.env` et `docker-compose.prod.yml`
|
|
restent gitignores.
|
|
- Le runner n'a pas le socket Docker : un job ne peut pas agir sur Docker localement.
|