Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente | |||
technique:old:adminsys:backup:db:scripts [2022/09/24 10:41] – supprimée - modification externe (Unknown date) 127.0.0.1 | technique:old:adminsys:backup:db:scripts [2022/09/24 10:41] (Version actuelle) – ↷ Page déplacée de technique:adminsys:backup:db:scripts à technique:old:adminsys:backup:db:scripts rdelaage | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | {{indexmenu_n> | ||
+ | |||
+ | # Implémentation de la sauvegarde | ||
+ | Les bases de données sur l' | ||
+ | |||
+ | < | ||
+ | Par convention, les sauvegardes sont stockés dans `/ | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | Le conteneur de sauvegarde est le même sur toutes les machines, et s' | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | |||
+ | ## Historique | ||
+ | |||
+ | La mise en place d’un système de sauvegarde pouvant gérer plusieurs bases de données (PostgreSQL, | ||
+ | |||
+ | Nous disposions avant le changement de 2 images Docker (une pour MySQL, une pour PostgreSQL). Chacune des images Docker contenait un script (nommé `run.sh`), qui effectuait la sauvegarde d’une seule base de donnée, dont les paramètres étaient précisés au lancement du conteneur par variables d’environnement. Pour chaque base de donnée, il était donc nécessaire de lancer une image Docker différente. | ||
+ | |||
+ | À terme, une telle solution semble peu adaptée, ainsi une image de sauvegarde unique semble être une meilleure solution pour plusieurs raisons : | ||
+ | * **Meilleur dimensionnement** : Bien que la consommation de ressource (CPU, RAM) ne soit pas aujourd' | ||
+ | * **Gestion centralisée** : Une image unique à chaque machine permettrait de simplifier l' | ||
+ | |||
+ | Trois questions se posent alors : | ||
+ | |||
+ | - Comment transmettre plusieurs paramètres (décrivant plusieurs bases de données) à l' | ||
+ | * Jusqu' | ||
+ | * Les variable Bash de type tableau ne sont pas gérés par Docker. | ||
+ | - Comment utiliser les scripts issus des images Docker existantes ? | ||
+ | * Peut-ont les utiliser tel quel, et faire en sorte de les importer des images existantes (du moins de leur source) | ||
+ | * Ou est-il nécessaire d' | ||
+ | - Comment monter un nombre variable de volumes, représentant les différents dossiers de sauvegardes sur la machine hôte ? | ||
+ | |||
+ | La solution retenue a été d' | ||
+ | |||
+ | ## Création des backups | ||
+ | |||
+ | Comme vu dans l' | ||
+ | * D' | ||
+ | * Ensuite une configuration via des variables d' | ||
+ | * Enfin, une configuration via un fichier JSON, lu en Python, qui créé les variables d' | ||
+ | |||
+ | Ce qui donne un côté un peu bigarré à l' | ||
+ | |||
+ | * L' | ||
+ | * `mongodb-run.sh`, | ||
+ | * `mysql-run.sh`, | ||
+ | * `postgres-run.sh`, | ||
+ | * `run.sh` prend des listes de de bases de données, nom de base, utilisateurs, | ||
+ | * `backup_env_var.py` va créer les listes à partir d'un fichier de configuration JSON. | ||
+ | |||
+ | ## Périodicité | ||
+ | |||
+ | Les scripts *ad-hoc* (comme `mysql-run.sh`) ne créent en fait pas directement de backups. | ||
+ | Ils créent un **script de backup** et un **script de restauration** pour chaque base de données. | ||
+ | |||
+ | < | ||
+ | |||
+ | Le fichier `< | ||
+ | |||
+ | Le lancement du script effectue enfin un dump de la base de données dans l' | ||
+ | |||
+ | Un paramètre de configuration permet de déclencher immédiatement un backup au démarrage du conteneur, sans attendre que `cron` ne s'en occupe. | ||