Méthode : Utiliser les snapshots Docker Compose pour des tests d’intégration fiables

Pourquoi les snapshots sont utiles

Lorsqu’on exécute des tests d’intégration, la cohérence des données est cruciale. Recréer une base de données à chaque run peut être long et introduire des variations. Les snapshots permettent de sauvegarder l’état complet d’un conteneur (fichiers, configuration, données) et de le restaurer instantanément, garantissant ainsi la même condition initiale pour chaque scénario de test.

Préparer l’environnement Docker Compose

1. Définir les services – Incluez la base de données et, si besoin, les services dépendants.
2. Configurer les volumes nommés – Ils facilitent la manipulation des snapshots.
3. Activer les healthchecks – Le pipeline attend que le service soit prêt avant de prendre le snapshot.

Exemple minimal de docker-compose.yml :

version: "3.9"
services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test
      POSTGRES_DB: testdb
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "test"]
      interval: 5s
      retries: 5
volumes:
  db-data:
    name: db-data

Créer et restaurer un snapshot

Docker ne propose pas de commande native « snapshot », mais on peut exploiter les volumes.

Créer le snapshot

# Démarrer les services
docker compose up -d
# Attendre que le healthcheck réussisse
while ! docker compose exec db pg_isready -U test; do sleep 1; done
# Exporter le volume vers une archive
docker run --rm -v db-data:/data -v $(pwd):/backup alpine \
  sh -c "cd /data && tar czf /backup/db-snapshot.tar.gz ."

Restaurer le snapshot

# Supprimer le volume existant
docker volume rm db-data
# Recréer le volume à partir de l'archive
docker volume create db-data
docker run --rm -v db-data:/data -v $(pwd):/backup alpine \
  sh -c "cd /data && tar xzf /backup/db-snapshot.tar.gz"
# Relancer les services
docker compose up -d

Le conteneur db démarre immédiatement avec les mêmes données que lors de la création du snapshot.

Intégrer les snapshots dans un pipeline CI

Dans un fichier .gitlab-ci.yml (ou équivalent), on peut ajouter deux jobs :

stages:
  - prepare
  - test

create_snapshot:
  stage: prepare
  script:
    - docker compose up -d
    - ./wait-for-db.sh   # script qui attend le healthcheck
    - docker run --rm -v db-data:/data -v $CI_PROJECT_DIR:/backup alpine \
        sh -c "cd /data && tar czf /backup/db-snapshot.tar.gz ."
  artifacts:
    paths:
      - db-snapshot.tar.gz
    expire_in: 1 hour

integration_tests:
  stage: test
  dependencies:
    - create_snapshot
  script:
    - docker volume rm db-data || true
    - docker volume create db-data
    - docker run --rm -v db-data:/data -v $CI_PROJECT_DIR:/backup alpine \
        sh -c "cd /data && tar xzf /backup/db-snapshot.tar.gz"
    - docker compose up -d
    - ./run-tests.sh

Le job create_snapshot génère l’archive qui devient un artefact. Le job suivant réimporte le snapshot avant d’exécuter les tests.

Bonnes pratiques et limites

• Versionner les snapshots : conservez plusieurs archives (par ex. snapshot-v1.tar.gz) pour pouvoir revenir à différents points de référence.
• Nettoyer les volumes : supprimez les volumes temporaires à la fin du pipeline afin d’éviter l’accumulation d’espace disque.
• Ne pas inclure de secrets : les snapshots contiennent les données de la base, assurez‑vous qu’aucune information sensible n’est committée dans le dépôt.
• Limite de taille : les snapshots volumineux ralentissent le transfert des artefacts. Utilisez des bases de données de taille réduite spécialement préparées pour les tests.
• Compatibilité des images : certaines images (par ex. MySQL avec InnoDB) requièrent des étapes de « flush‑tables‑with‑read‑lock » avant la sauvegarde. Adaptez la procédure en fonction du SGBD.

En suivant cette méthode, vous obtenez des environnements d’intégration identiques à chaque exécution, ce qui facilite le diagnostic des échecs et renforce la fiabilité de votre suite de tests.