Files
SchotzIAD/DEPLOY.md
T
MadJax d857ccb879 Déploiement par Git + Docker : script deploy.sh et guide DEPLOY.md
- deploy.sh : met à jour depuis Gitea (branche master) et ne reconstruit
  les conteneurs (docker compose up -d --build) que si une nouvelle
  version existe ; option --force ; vérifie git/docker/compose/.env ;
  pull --ff-only ; compatible Compose v2 et v1
- DEPLOY.md : guide de premier déploiement (prérequis, git clone, .env
  depuis .env.example), mises à jour, persistance SQLite, dépannage
- design.md : note renvoyant vers DEPLOY.md et la procédure Git + Docker
  (abandon de la copie d'archive)
2026-10-12 12:54:43 +02:00

3.7 KiB

Déploiement de SchotzIAD KM Tracker

Déploiement via Git (Gitea) + Docker Compose. Le serveur récupère les sources depuis Gitea et reconstruit les conteneurs — plus besoin de copier une archive.

  • Dépôt Gitea : http://192.168.1.55:3000/MadJax/SchotzIAD
  • Branche déployée : master
  • Frontend exposé sur le port hôte 2202 (derrière le reverse-proxy Caddy externe).

1. Premier déploiement (une seule fois sur le serveur)

1.1 Installer les prérequis

Le serveur a besoin de git et de Docker (avec le plugin Compose v2).

Sur Debian/Ubuntu :

sudo apt update
sudo apt install -y git
# Docker + plugin compose : voir https://docs.docker.com/engine/install/
# (paquets docker-ce, docker-ce-cli, containerd.io, docker-compose-plugin)

Vérification :

git --version
docker --version
docker compose version

1.2 Cloner le dépôt

git clone http://192.168.1.55:3000/MadJax/SchotzIAD SchotzIAD
cd SchotzIAD

Au premier git clone/push, Gitea demande identifiant + token. Avec le credential helper store déjà en place, ils ne sont demandés qu'une fois.

1.3 Créer le fichier .env

Le .env n'est jamais versionné (il contient les secrets). On le crée à partir du modèle fourni :

cp .env.example .env

Puis éditer .env et renseigner au minimum :

  • JWT_SECRET_KEY : obligatoire. Générer une valeur aléatoire longue, ex. :
    openssl rand -base64 48
    
    (sans cette clé, le backend refuse de démarrer.)
  • AUTH_FRONTEND_BASE_URL : l'URL publique du site (ex. https://schotz.exemple.fr), utilisée dans les liens de réinitialisation de mot de passe.
  • ORS_API_KEY : clé OpenRouteService (sinon distances à vol d'oiseau).
  • SMTP_* : facultatif. Si SMTP_HOST est vide, le lien de réinitialisation est seulement journalisé côté serveur.

1.4 Premier démarrage

./deploy.sh --force

(--force car il n'y a pas de « version précédente » à comparer la première fois.)


2. Mettre à jour le site (à chaque nouvelle version)

Depuis le dossier du dépôt sur le serveur :

./deploy.sh

Le script :

  1. vérifie les prérequis (git, docker, docker compose, présence du .env) ;
  2. récupère les références distantes (git fetch) ;
  3. ne reconstruit que si une nouvelle version existe sur master :
    • si le serveur est déjà à jour, il s'arrête sans rien reconstruire ;
    • sinon il fait git pull --ff-only puis docker compose up -d --build ;
  4. affiche l'état des conteneurs.

Pour forcer une reconstruction sans nouveau commit (par exemple après avoir modifié .env) :

./deploy.sh --force

3. Données et persistance

  • La base SQLite est persistée via un bind mount dans ./data/trajets.db (créé au premier démarrage). Elle survit aux redéploiements et n'est pas versionnée.
  • Sauvegarde : il suffit de copier ./data/trajets.db (idéalement conteneurs arrêtés, ou via une copie à chaud suivie d'un VACUUM INTO).

4. Dépannage

  • .env absent : copier .env.example vers .env et le renseigner (étape 1.3).
  • git pull --ff-only a échoué : l'historique local du serveur a divergé (commits locaux non souhaités). Revenir à l'état distant :
    git fetch origin
    git reset --hard origin/master   # ⚠ écrase les modifs locales non commitées
    
  • JWT_SECRET_KEY requis au démarrage du backend : la clé est absente du .env (voir étape 1.3).
  • Voir les logs :
    docker compose logs -f backend
    docker compose logs -f frontend
    
  • Redémarrer sans rebuild :
    docker compose restart