- 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)
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. :(sans cette clé, le backend refuse de démarrer.)openssl rand -base64 48AUTH_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. SiSMTP_HOSTest 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 :
- vérifie les prérequis (git, docker, docker compose, présence du
.env) ; - récupère les références distantes (
git fetch) ; - 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-onlypuisdocker compose up -d --build;
- 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'unVACUUM INTO).
4. Dépannage
.env absent: copier.env.examplevers.envet 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éesJWT_SECRET_KEY requisau 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