613 lines
12 KiB
Markdown
613 lines
12 KiB
Markdown
# 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 d’une 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 l’environnement ;
|
||
- `rebuild-bdd-core.sh` exécute la restauration ;
|
||
- `run-rebuild-bdd.sh` orchestre l’ensemble.
|
||
|
||
---
|
||
|
||
<details>
|
||
<summary style="list-style: none; cursor: pointer;">
|
||
<strong>EggMaster</strong>
|
||
</summary>
|
||
|
||
<details>
|
||
<summary style="list-style: none; cursor: pointer;">Question 4</summary>
|
||
|
||
Quel utilitaire standard permet de decoder la chaine reconstituee ?
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary style="list-style: none; cursor: pointer;">Indice commande 4</summary>
|
||
|
||
```text
|
||
base64
|
||
```
|
||
|
||
</details>
|
||
|
||
<details>
|
||
<summary style="list-style: none; cursor: pointer;">Fragment 4</summary>
|
||
|
||
```text
|
||
4gcmVjb21wZW5zZSBodHRwczovL3d3dy55b3V0
|
||
```
|
||
|
||
</details>
|
||
|
||
</details>
|
||
|
||
## 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 <TARGET_HOST> \
|
||
--port 22 \
|
||
--bootstrap-user <BOOTSTRAP_USER> \
|
||
--bootstrap-key /home/user/.ssh/id_ed25519_target_test \
|
||
--runtime-user <RUNTIME_USER> \
|
||
--repo-dir /home/<RUNTIME_USER>/RebuildBdd \
|
||
--env-name RECETTE \
|
||
--pguser <PGUSER> \
|
||
--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 d’un `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`
|
||
* `jq` si vous consommez les JSON côté tooling
|
||
|
||
### Machine cible
|
||
|
||
Le bootstrap suppose :
|
||
|
||
* accès SSH fonctionnel ;
|
||
* utilisateur bootstrap existant ;
|
||
* soit `root`, soit `sudo -n` déjà disponible pour le bootstrap initial ;
|
||
* `known_hosts` correctement provisionné si le mode strict SSH est activé vers le serveur de backup.
|
||
|
||
### Serveur de backup
|
||
|
||
Doit :
|
||
|
||
* être joignable en SSH depuis la cible ;
|
||
* accepter la clé de lecture backup ;
|
||
* contenir les dumps dans l’arborescence attendue.
|
||
|
||
## Sécurité / déploiement
|
||
|
||
### Clés hôtes SSH
|
||
|
||
Si `GLOBAL_BACKUP_KNOWN_HOSTS_STRICT=yes`, l’empreinte du serveur de backup doit déjà être présente dans le `known_hosts` de la cible. Le bootstrap et les checks ne font plus d’ajout aveugle en mode strict.
|
||
|
||
### Répertoires de clone
|
||
|
||
Les scripts refusent maintenant les chemins de clone manifestement dangereux comme `/`, `/root`, `/home` ou `/home/<user>` pour éviter un `rm -rf` destructeur dû à une mauvaise configuration.
|
||
|
||
### Ubuntu Server
|
||
|
||
Le flux de bootstrap est pensé pour des cibles Ubuntu Server avec `apt`, `systemctl` et `sudo -n`.
|
||
|
||
---
|
||
|
||
## 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/.env.exemple
|
||
```
|
||
|
||
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.exemple
|
||
```
|
||
|
||
#### 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
|
||
|
||
L’interface web ne doit envoyer que les paramètres métier de l’exé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/<RUNTIME_USER>/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/<RUNTIME_USER>/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 l’interface web ;
|
||
* valider strictement toutes les entrées côté backend.
|
||
|
||
### `sudoers`
|
||
|
||
Le bootstrap peut installer un `sudoers.d` minimal pour l’utilisateur 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 d’autres commandes doivent être autorisées.
|
||
|
||
---
|
||
|
||
## Logs
|
||
|
||
Les logs de rebuild sont stockés dans :
|
||
|
||
```bash
|
||
TARGET_BACKUP_LOG_DIR
|
||
```
|
||
|
||
Exemple :
|
||
|
||
```bash
|
||
/home/<RUNTIME_USER>/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 d’exécution peuvent être ajoutés si plusieurs rebuilds concurrents sont prévus.
|
||
|
||
---
|
||
|
||
## Recommandations de validation
|
||
|
||
Avant mise en production, tester au minimum :
|
||
|
||
1. bootstrap d’une machine neuve ;
|
||
2. rebuild complet d’une 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 <TARGET_HOST> \
|
||
--port 22 \
|
||
--bootstrap-user <BOOTSTRAP_USER> \
|
||
--bootstrap-key /home/<LOCAL_USER>/.ssh/id_ed25519_target_test \
|
||
--runtime-user <RUNTIME_USER> \
|
||
--repo-dir /home/<RUNTIME_USER>/RebuildBdd \
|
||
--env-name RECETTE \
|
||
--pguser <PGUSER> \
|
||
--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.
|