Partie III – Dirvish pour les sauvegardes de l’application Touch & Sell – Tutoriel

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.

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 :

  1. Grâce à la configuration par fichier, nous pouvons stocker nos données sur la plateforme Git (et par récursivité dans les sauvegardes) et historiser toutes nos actions.
  2. 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 :

FROM debian:jessie
MAINTAINER dev@touch-sell.com
RUN ln -sf /usr/share/zoneinfo/Europe/Paris /etc/localtime

# Installation de dirvish
RUN apt-get update
RUN apt-get install -y dirvish

# Configuration de dirvish
ADD master.conf /etc/dirvish/

# La clé ssh de backup lui permettant d’accéder aux différents serveurs
ADD id_rsa /root/.ssh/id_rsa
ADD known_hosts /root/.ssh/
RUN chmod g-rw /root/.ssh/*
RUN chmod o-rw /root/.ssh/*
VOLUME [“/opt/bank”, “/var/log/”]

 

La sauvegarde et l’expiration des anciens backups sont lancées par des commandes fournies avec Dirvish :

# Lance le backup de tout les vaults référencés dans master.conf (champs Runall:)
docker run -v /mnt/backup/:/opt/bank –rm tal/dirvish dirvish-runall
# Expire tout les backups dont la date (champs Expire: dans le fichier summary) est passée
docker run -v /mnt/backup/:/opt/bank –rm tal/dirvish dirvish-expire

 

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.

Dans .gitignore on exclue les sauvegardes jusqu’à l’an 3 000 et le fichier décrivant la liste des sauvegardes d’un vault :

# .gitignore
2*
default.hist

 

Ensuite, chaque vault est un dossier contenant la configuration de la sauvegarde dans un sous repertoire Dirvish :

/mnt/backup/vault1/dirvish/default.conf

 

 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 :

/var/lib/docker/volumes/tasbo_prod_files/_data/ /opt/dirvish/tasbo_prod_files none bind 0 0

 

Il ne reste plus qu’à configurer un vault Dirvish :

client: PRODSERVER
tree: /opt/dirvish
index: gzip

 

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. 

docker exec gitlab_app_1 data-backup > backup.tar

docker exec -i gitlab_app_1 data-restore < backup.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 a permis d’éliminer complétement les problèmes de mise en production.

New Call-to-action

//

 


Partagez cet article

Orientation non prise en charge

Pour une meilleure expérience,
veuillez tourner votre appareil en mode portrait.