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)
This commit is contained in:
@@ -0,0 +1,133 @@
|
||||
# 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 :
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
git --version
|
||||
docker --version
|
||||
docker compose version
|
||||
```
|
||||
|
||||
### 1.2 Cloner le dépôt
|
||||
|
||||
```bash
|
||||
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 :
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
```
|
||||
|
||||
Puis éditer `.env` et renseigner au minimum :
|
||||
|
||||
- `JWT_SECRET_KEY` : **obligatoire**. Générer une valeur aléatoire longue, ex. :
|
||||
```bash
|
||||
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
|
||||
|
||||
```bash
|
||||
./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 :
|
||||
|
||||
```bash
|
||||
./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`) :
|
||||
|
||||
```bash
|
||||
./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 :
|
||||
```bash
|
||||
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** :
|
||||
```bash
|
||||
docker compose logs -f backend
|
||||
docker compose logs -f frontend
|
||||
```
|
||||
- **Redémarrer sans rebuild** :
|
||||
```bash
|
||||
docker compose restart
|
||||
```
|
||||
Reference in New Issue
Block a user