Précédemment, vous avez pu découvrir comment l’infrastructure Docker était utilisée chez Touch & Sell par l’équipe R&D. Une partie n’a pas encore été abordée sur le sujet Docker : les sauvegardes de l’application grâce à la technologie Dirvish.
La sauvegarde et l’expiration des anciens backups sont lancées par des commandes fournies avec Dirvish :
Un petit glossaire de Dirvish pour aider à la compréhension de la technologie :
Ensuite, chaque vault est un dossier contenant la configuration de la sauvegarde dans un sous repertoire Dirvish :
Il ne reste plus qu’à configurer un vault Dirvish :
LES BASES DE DONNEES : UNE CONVENTION
Pour les données nécessitant un export spécifique telles que les bases de données, nous avons choisi d’utiliser une convention d’appel pour l’image. C’est à dire que chaque image doit fournir deux scripts data-backup et data-restore travaillant avec un fichier tar.
Pour résumer, un système de sauvegarde n’est jamais complet sans un test régulier de restauration. C’est pourquoi, nous les testons régulièrement, principalement avant chaque mise en production. Recetter à système et données équivalents nous à permis d’éliminer complétement les problèmes de mise en production.
Qu’est-ce que Dirvish ?
Chez Touch & Sell, les sauvegardes sont exécutées grâce à l’outil open-source : Dirvish. Cette technologie se base sur des outils classiques : ssh, pour accéder à distance à la machine et rsync pour la synchronisation des fichiers.Pourquoi ce choix ?
Dirvish possède deux avantages majeurs :- Grâce à la configuration par fichier, nous pouvons stocker nos données sur la plateforme Git (et par récursion dans les sauvegardes) et historiser toutes nos actions.
- Des sauvegardes en même temps complètes et incrémentales. Un fichier présent dans plusieurs sauvegardes n’est stocké qu’une seule fois, ce qui évite de perdre de l’espace de stockage. Dans notre cas de figure, cette fonctionnalité est indispensable car nous sauvegardons plus de 650Go de données chaque heure, ce qui génère 130 sauvegardes complètes qui ne prennent au final que 850Go !
Comment mettre en place ce process ?
Dirvish est lancé dans Docker en profitant pleinement de la notion de conteneur jetable. La notion de conteneur jetable signifie que chaque heure un conteneur est crée et sauvegarde les données dans un volume (une zone de stockage munie d’un système de fichiers, placé sur une partition d’un disque dur), pour par la suite être supprimé. Voici le Dockerfile (la représentation d’une image et de sa construction à partir d’une autre image) utilisé pour créer l’image dirvish :
La sauvegarde et l’expiration des anciens backups sont lancées par des commandes fournies avec Dirvish :
Un petit glossaire de Dirvish pour aider à la compréhension de la technologie :
- Un vault est un répertoire où sont stockés la configuration et les données d’un process de sauvegarde.
- Un bank est un répertoire où sont stockés et recherchés des vault. Le bank est lui même sauvegardé dans Git pour compléter l’architecture as Code git.
Ensuite, chaque vault est un dossier contenant la configuration de la sauvegarde dans un sous repertoire Dirvish :
Comment sauvegarder les données ?
LES VOLUMES DOCKER L’avantage majeur de l’infrastructure as code est que nous n’avons plus besoin de sauvegarder la machine mais uniquement les données. Grâce à Docker, toutes les données sont stockées dans un seul et même endroit : les volumes. Cependant tous les volumes ne sont pas sauvegardés, seulement les volumes de production qui sont regroupés au sein du répertoire sauvegardé par un montage bind. Exemple de fichier fstab :
Il ne reste plus qu’à configurer un vault Dirvish :
LES BASES DE DONNEES : UNE CONVENTION
Pour les données nécessitant un export spécifique telles que les bases de données, nous avons choisi d’utiliser une convention d’appel pour l’image. C’est à dire que chaque image doit fournir deux scripts data-backup et data-restore travaillant avec un fichier tar.
Pour résumer, un système de sauvegarde n’est jamais complet sans un test régulier de restauration. C’est pourquoi, nous les testons régulièrement, principalement avant chaque mise en production. Recetter à système et données équivalents nous à permis d’éliminer complétement les problèmes de mise en production.
