Files
Malio-ops/RebuildBdd/README.md

567 lines
10 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.
```