Infra/Mise-a-jour-Applications.md

Mise à jour des applications

Chaque application est packagée sous forme d'image Docker publiée sur le registre Gitea (git.goutailler-olivier.com) par la CI lors d'une release. La mise à jour en production consiste à récupérer la nouvelle image et à recréer le conteneur.

---

Principe général

cd <dossier-du-service>/
docker compose pull          # télécharge la nouvelle image
docker compose up -d         # recrée le conteneur si l'image a changé

docker compose up -d détecte automatiquement que l'image locale est différente de celle utilisée par le conteneur en cours et le recrée. Le temps d'indisponibilité est limité à la durée du redémarrage du conteneur (quelques secondes).

---

Exemple : mettre à jour Bonsai Webapp

Une nouvelle release a été publiée sur Gitea et l'image bonsai-webapp:latest a été mise à jour par la CI.

cd bonsai-webapp/
docker compose pull
docker compose up -d

Vérifier que le conteneur tourne bien avec la nouvelle image :

docker inspect bonsai-webapp --format '{{.Image}}'
# ou
docker compose ps

---

Mettre à jour une version précise (tag de release)

Par défaut les docker-compose.yml pointent sur :latest. Pour épingler une version spécifique, éditer le fichier et remplacer le tag :

image: git.goutailler-olivier.com/bonsai/bonsai-webapp:v1.2.3

Puis appliquer :

docker compose pull
docker compose up -d

---

Revenir à une version précédente (rollback)

Un workflow Gitea Actions dédié permet de déclencher un rollback sans toucher au serveur manuellement.

Rollback Bonsai Webapp

1. Aller dans Gitea → Bonsai-webapp → Actions → Rollback → Run workflow
2. Saisir la version cible (ex. v1.2.3)
3. Lancer — Watchtower redéploie automatiquement

Rollback Bonsai API (avec ou sans restauration BDD)

1. Aller dans Gitea → Bonsai-api → Actions → Rollback → Run workflow
2. Saisir la version cible (ex. v1.2.3)
3. Choisir restore_db :
   • no (défaut) — rollback du code uniquement (migrations Flyway compatibles)
   • yes — rollback du code et restauration de la base de données depuis le backup créé avant ce déploiement

Attention : restore_db=yes écrase toutes les données créées depuis le déploiement à annuler. À réserver aux cas où la migration de schéma est incompatible avec l'ancienne version.

Ce que fait le workflow en coulisse

1. Retague l'image image:vX.Y.Z en image:latest dans le registry Gitea
2. (Si restore_db=yes) Se connecte en SSH au serveur, arrête l'API, restaure le dump PostgreSQL
3. Déclenche Watchtower → redéploie le conteneur avec la version rétrogradée

---

Backups de la base de données

Un backup compressé (pg_dump | gzip) est créé automatiquement avant chaque déploiement de Bonsai API.

• Emplacement sur le serveur : /opt/backups/bonsai-api/
• Format du nom : bonsai_v1.2.3_20260531_143000.sql.gz
• Rétention : les 10 derniers backups sont conservés, les plus anciens sont supprimés automatiquement

Pour lister les backups disponibles sur le serveur :

ls -lh /opt/backups/bonsai-api/

Pour restaurer manuellement un backup :

VERSION="v1.2.3"
BACKUP_FILE=$(ls -t /opt/backups/bonsai-api/bonsai_${VERSION}_*.sql.gz | head -1)

docker stop bonsai-api
docker exec bonsai-api-db psql -U bonsai postgres \
  -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='bonsai' AND pid != pg_backend_pid();"
docker exec bonsai-api-db dropdb -U bonsai bonsai
docker exec bonsai-api-db createdb -U bonsai bonsai
gunzip -c "$BACKUP_FILE" | docker exec -i bonsai-api-db psql -U bonsai bonsai
docker start bonsai-api

---

Mettre à jour tous les services d'un coup

for dir in traefik keycloak gitea bonsai-api bonsai-webapp nextcloud trilium; do
  echo "=== $dir ==="
  (cd "$dir" && docker compose pull && docker compose up -d)
done

---

Vérifications après mise à jour

# État de tous les conteneurs
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"

# Logs du service mis à jour
docker logs bonsai-webapp --tail 50 -f

# Supprimer les anciennes images devenues inutiles
docker image prune -f