Implémentation de la sauvegarde

Les bases de données sur l’architecture de Picasoft ne sont pas redondés. Pour pallier ce problème, un conteneur sauvegarde périodiquement le contenu des bases de données.

La mise en place d’un système de sauvegarde pouvant gérer plusieurs bases de données (PostgreSQL, MySQL et MongoDB) s’est fait dans un objectif de simplification de l’infrastructure et de scalabilité.

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’hui un problème, il ne semble pas nécessaire de fournir un environnement d’exécution isolé (comprendre un conteneur Docker) pour chaque script de sauvegarde.
• Gestion centralisée : Une image unique à chaque machine permettrait de simplifier l’accès au système de sauvegarde (un seul point d’accès), ainsi que sa maintenance (ex: mise à jour des scripts de sauvegarde).

Trois questions se posent alors :

• Comment transmettre plusieurs paramètres (décrivant plusieurs bases de données) à l’image Docker ?
  • Jusqu’alors, les paramètres étaient transmis par variable d’environnement, mais pour une unique base de donnée
  • 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’adapter les scripts ?
• 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’utiliser des listes dans des variables d’environnements, qui seront interprétée par un script Shell.

Comme vu dans l’historique, ce système de backup a connu plusieurs évolutions : * D’abord des scripts ad-hoc pour MySQL et PostgreSQL, capables de gérer une seule base de données * Ensuite une configuration via des variables d’environnement, lues dans des tableaux Bash, qui appellent les scripts ad-hoc * Enfin, une configuration via un fichier JSON, lu en Python, qui créé les variables d’environnement, lues dans des tableaux Bash […]

Ce qui donne un côté un peu bigarré à l’ensemble. Pour résumer :

• L’image Docker de sauvegarde unifiée dispose donc 3 scripts situés dans le dossier /scripts :
  • mongodb-run.sh, qui réalise le backup d’une seule base de données MongoDB à partir de l’environnement
  • mysql-run.sh, pareil pour MySQL/MariaDB
  • postgres-run.sh, pareil pour PostgreSQL.
• run.sh prend des listes de de bases de données, nom de base, utilisateurs, mots de passe… et itère sur ces listes pour créer les variables d’environnement nécessaires à l’appel des scripts ci-dessus. Pour être plus précis sur le fonctionnement du script run.sh, celui-ci transforme les listes passés en tant que variables d’environnement en tableaux Bash, plus facile à manipuler. Cela est rendu possible grâce à la fonction read à laquelle on précise le séparateur via la variable IFS (dans notre cas IFS=,)
• backup_env_var.py va créer les listes à partir d’un fichier de configuration JSON.

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 <service>-backup.sh est rajouté à la crontab du conteneur avec une fréquence d’exécution égale à celle définie dans la configuration.

Le lancement du script effectue enfin un dump de la base de données dans l’archive /backup/<nomservice>/<DATE>.tar.gz.

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.