feat : Utilisation web disponible et simplification du deployement des scripts (WIP)

This commit is contained in:
2026-03-17 11:40:35 +01:00
parent 0d4ffd9391
commit a1fb6f5504
14 changed files with 1287 additions and 257 deletions

566
RebuildBdd/README.md Normal file
View File

@@ -0,0 +1,566 @@
# RebuildBdd
Orchestration de reconstruction de bases PostgreSQL à partir de dumps distants, avec préparation automatique des machines cibles, exécution non interactive et intégration web.
---
## Objectif
Ce projet permet de :
- préparer automatiquement une machine cible neuve ou partiellement configurée ;
- déployer et mettre à jour les scripts sur la cible ;
- préparer PostgreSQL localement sur la cible ;
- récupérer le dernier dump disponible depuis un serveur de backup ;
- restaurer une base PostgreSQL de manière non interactive ;
- exposer un flux exploitable depuis une interface web via des retours JSON.
---
## Fonctionnement global
Le flux standard est le suivant :
1. **Création ou mise à jour de la configuration dune cible**
2. **Bootstrap initial de la cible**
3. **Précheck de préparation**
4. **Rebuild de la base**
En pratique :
- `create-target-config.sh` crée un fichier de configuration cible ;
- `bootstrap-target-host.sh` prépare la machine cible ;
- `Checkup/check-target-readiness.sh` valide lenvironnement ;
- `rebuild-bdd-core.sh` exécute la restauration ;
- `run-rebuild-bdd.sh` orchestre lensemble.
---
## Architecture
### Configuration
Le projet utilise deux niveaux de configuration :
#### 1. Configuration globale
Fichier :
```bash
config/global.env
````
Contient les paramètres stables, par exemple :
* dépôt Git des scripts ;
* serveur de backup ;
* clé SSH de lecture backup ;
* valeurs par défaut PostgreSQL ;
* options globales de bootstrap.
#### 2. Configuration par cible
Fichiers :
```bash
config/targets/<nom_cible>.env
```
Chaque fichier cible contient :
* accès SSH bootstrap ;
* répertoires locaux de la cible ;
* paramètres PostgreSQL ;
* sous-répertoire backup associé ;
* options spécifiques à la cible.
---
## Arborescence recommandée
```bash
RebuildBdd/
├── bootstrap-target-host.sh
├── create-target-config.sh
├── run-rebuild-bdd.sh
├── rebuild-bdd-core.sh
├── config/
│ ├── global.env
│ └── targets/
│ ├── test.env
│ └── prod.env
└── Checkup/
├── check-postgresql.sh
└── check-target-readiness.sh
```
---
## Scripts
### `create-target-config.sh`
Crée ou met à jour un fichier cible dans :
```bash
config/targets/<cible>.env
```
Usage :
```bash
./create-target-config.sh \
--target test \
--host 192.168.1.50 \
--port 22 \
--bootstrap-user backup_liot \
--bootstrap-key /home/user/.ssh/id_ed25519_target_test \
--runtime-user backup_liot \
--repo-dir /home/backup_liot/RebuildBdd \
--env-name RECETTE \
--pguser backup_liot \
--pgpassword secret \
--dbs "sirh inventory ferme" \
--backup-subdir bdd-recette
```
---
### `bootstrap-target-host.sh`
Prépare une machine cible neuve ou quasi neuve :
* connexion SSH bootstrap ;
* installation des paquets minimum ;
* création des dossiers ;
* génération du `.env` cible ;
* copie de la clé SSH backup ;
* préparation de `known_hosts` ;
* installation éventuelle dun `sudoers.d` minimal ;
* synchronisation du dépôt ;
* exécution de `check-postgresql.sh`.
Usage :
```bash
./bootstrap-target-host.sh --target test
```
Mode JSON :
```bash
./bootstrap-target-host.sh --target test --json-only
```
---
### `Checkup/check-postgresql.sh`
Prépare PostgreSQL localement sur la cible :
* installation si absent ;
* démarrage du service ;
* test de disponibilité ;
* création du rôle PostgreSQL cible si nécessaire.
Ce script est prévu pour fonctionner en non interactif avec `sudo -n`.
---
### `Checkup/check-target-readiness.sh`
Valide la préparation complète de la cible :
* lecture du `.env` cible ;
* vérification des chemins ;
* permissions locales ;
* permissions SSH ;
* `known_hosts` ;
* accès SSH au serveur de backup ;
* exécution de `check-postgresql.sh`.
Mode JSON disponible pour usage web.
---
### `rebuild-bdd-core.sh`
Script métier de reconstruction :
* validation des paramètres ;
* connexion au serveur de backup ;
* récupération du dernier dump ;
* récupération éventuelle du fichier des rôles ;
* suppression/recréation de la base si autorisé ;
* restauration des rôles ;
* restauration du dump PostgreSQL ;
* retour JSON final.
---
### `run-rebuild-bdd.sh`
Script orchestrateur principal.
Il peut :
* lancer le bootstrap si activé pour la cible ;
* synchroniser le dépôt distant ;
* lancer le précheck ;
* exécuter le rebuild.
Usage :
```bash
./run-rebuild-bdd.sh \
--target test \
--db sirh \
--overwrite yes \
--restore-roles yes \
--request-id web_001 \
--non-interactive
```
---
## Prérequis
### Machine de lancement
Doit disposer de :
* `bash`
* `ssh`
* `scp`
* `git`
* `python3`
### Machine cible
Le bootstrap suppose :
* accès SSH fonctionnel ;
* utilisateur bootstrap existant ;
* soit `root`, soit `sudo -n` déjà disponible pour le bootstrap initial.
### Serveur de backup
Doit :
* être joignable en SSH depuis la cible ;
* accepter la clé de lecture backup ;
* contenir les dumps dans larborescence attendue.
---
## Structure des backups attendue
Exemple :
```bash
/home/malio-b/backups/
├── bdd-recette/
│ ├── sirh/
│ │ ├── sirh_2026-03-16_19-00-01.dump
│ ├── inventory/
│ ├── ferme/
│ └── user/
│ ├── user_2026-03-16_19-00-01.sql
```
Le script recherche :
* le dernier dump dans :
```bash
<BACKUP_REMOTE_DIR>/<db>/<db>_*.dump
```
* le dernier fichier rôles dans :
```bash
<BACKUP_REMOTE_DIR>/<REMOTE_ROLES_DIR_NAME>/user_*.sql
```
---
## Configuration
### 1. Créer la configuration globale
Copier :
```bash
config/global.env.example
```
vers :
```bash
config/global.env
```
Renseigner ensuite :
* dépôt Git ;
* serveur de backup ;
* clé SSH backup ;
* defaults globaux.
---
### 2. Créer une cible
Deux possibilités.
#### A. À la main
Créer un fichier :
```bash
config/targets/test.env
```
à partir de :
```bash
config/targets/test.env.example
```
#### B. Via script
Utiliser :
```bash
./create-target-config.sh ...
```
---
## Exécution locale
### Bootstrap seul
```bash
./bootstrap-target-host.sh --target test
```
### Rebuild complet
```bash
./run-rebuild-bdd.sh \
--target test \
--db sirh \
--overwrite yes \
--restore-roles yes \
--non-interactive
```
---
## Intégration web
Linterface web ne doit envoyer que les paramètres métier de lexécution :
```json
{
"target": "test",
"db": "sirh",
"overwrite": "yes",
"restore_roles": "yes",
"request_id": "web_20260317_001"
}
```
Le backend transforme cela en commande :
```bash
./run-rebuild-bdd.sh \
--target test \
--db sirh \
--overwrite yes \
--restore-roles yes \
--request-id web_20260317_001 \
--non-interactive
```
### Important
Le web ne doit pas transmettre directement :
* les clés SSH ;
* les mots de passe PostgreSQL ;
* les paramètres bas niveau de la cible ;
* les chemins système sensibles.
Ces informations doivent être stockées dans la configuration serveur.
---
## Ajouter une nouvelle machine depuis le web
Le flux recommandé est :
1. créer ou mettre à jour `config/targets/<cible>.env`
2. lancer `bootstrap-target-host.sh --target <cible>`
3. lancer ensuite `run-rebuild-bdd.sh --target <cible> ...`
Le bouton web **“Ajouter une machine”** doit donc :
* créer la configuration cible ;
* déclencher le bootstrap ;
* vérifier le retour ;
* rendre ensuite la cible disponible pour les rebuilds.
---
## Sorties JSON
### Succès
Exemple :
```json
{
"status": "success",
"message": "restauration terminée avec succès",
"request_id": "web_001",
"environment": "RECETTE",
"database": "sirh",
"dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
"log_file": "/home/backup_liot/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}
```
### Erreur
Exemple :
```json
{
"status": "error",
"message": "la base existe déjà et overwrite n'est pas autorisé",
"request_id": "web_001",
"environment": "RECETTE",
"database": "sirh",
"dump_file": "/home/backup/backups/bdd-recette/sirh/sirh_2026-03-16_19-00-01.dump",
"log_file": "/home/backup_liot/logs/rebuild_bdd/restore_recette_web_001_2026-03-17_09-10-00.log"
}
```
---
## Sécurité
### Recommandations minimales
* utiliser des clés SSH dédiées ;
* limiter la clé backup à la lecture seule ;
* restreindre les permissions des fichiers de config ;
* exécuter les scripts avec un utilisateur dédié ;
* ne pas exposer les secrets dans linterface web ;
* valider strictement toutes les entrées côté backend.
### `sudoers`
Le bootstrap peut installer un `sudoers.d` minimal pour lutilisateur runtime :
```sudoers
<user> ALL=(root) NOPASSWD: /usr/bin/apt, /usr/bin/apt-get, /usr/bin/systemctl
<user> ALL=(postgres) NOPASSWD: /usr/bin/psql
```
Adapter si dautres commandes doivent être autorisées.
---
## Logs
Les logs de rebuild sont stockés dans :
```bash
TARGET_BACKUP_LOG_DIR
```
Exemple :
```bash
/home/backup_liot/logs/rebuild_bdd/
```
Le chemin du log est renvoyé dans le JSON final.
---
## Limites connues
* le bootstrap initial nécessite un accès SSH bootstrap valide ;
* le bootstrap ne remplace pas une mauvaise architecture réseau ;
* les secrets doivent être gérés proprement par la couche web/backend ;
* des verrous dexécution peuvent être ajoutés si plusieurs rebuilds concurrents sont prévus.
---
## Recommandations de validation
Avant mise en production, tester au minimum :
1. bootstrap dune machine neuve ;
2. rebuild complet dune base ;
3. refus si la base existe et `overwrite=no` ;
4. relance complète une seconde fois sur la même cible ;
5. accès backup invalide ;
6. PostgreSQL absent au départ ;
7. `sudo -n` indisponible.
---
## Commandes utiles
### Créer une cible
```bash
./create-target-config.sh \
--target test \
--host 192.168.1.50 \
--port 22 \
--bootstrap-user backup_liot \
--bootstrap-key /home/matteo/.ssh/id_ed25519_target_test \
--runtime-user backup_liot \
--repo-dir /home/backup_liot/RebuildBdd \
--env-name RECETTE \
--pguser backup_liot \
--pgpassword secret \
--dbs "sirh inventory ferme" \
--backup-subdir bdd-recette
```
### Bootstrap
```bash
./bootstrap-target-host.sh --target test
```
### Rebuild
```bash
./run-rebuild-bdd.sh \
--target test \
--db sirh \
--overwrite yes \
--restore-roles yes \
--non-interactive
```
---
## État du projet
Le projet permet désormais une utilisation :
* locale ;
* automatisée ;
* intégrée au web ;
avec préparation des cibles, exécution non interactive et retour JSON.
```