Sauvegarde et restauration d'images Docker avec exemples pratiques

Introduction

La sauvegarde et la restauration d'images Docker sont une compétence opérationnelle essentielle pour les développeurs, les consultants DevOps et les équipes de startups techniques. Un processus de sauvegarde fiable vous protège contre la suppression accidentelle d'images, les pannes de registre, les échecs de build et les besoins de retour en arrière de version. Cet article fournit des conseils pratiques, axés sur les commandes, pour vous aider à passer d'un problème observé à un résultat vérifié.

Nous couvrirons le cycle de vie complet : inventorier votre environnement, créer des sauvegardes d'images, les restaurer correctement, valider les images restaurées et récupérer après des échecs courants. Chaque section inclut des commandes concrètes, les sorties attendues et les étapes de vérification. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, éviter les fuites de secrets, vérifier les résultats et documenter les chemins de récupération avant d'en avoir besoin.

Inventaire des versions et de l'environnement

Avant de commencer à sauvegarder des images, vous devez savoir exactement avec quoi vous travaillez. Exécutez ces commandes en lecture seule pour capturer l'état actuel de votre environnement Docker.

# Version Docker et informations système
docker version
docker system info

# Liste de toutes les images avec ID d'image, référentiel, tag et taille
docker image list --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}\t{{.Size}}"

# Liste de tous les conteneurs (y compris arrêtés) pour identifier quelles images peuvent être utilisées
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"

# Afficher l'utilisation du disque par les objets Docker
docker system df

Si vos images sont stockées dans un registre privé, vérifiez l'accès au registre et listez les tags distants. Par exemple, si vous utilisez Docker Hub ou un registre auto-hébergé, vérifiez que l'authentification est configurée et que vous pouvez tirer des images.

# Vérifier la configuration Docker pour les identifiants de registre (ne pas imprimer les secrets)
docker info | grep -A2 "Registry"

# Pour un registre privé spécifique, se connecter et tirer une image de test
docker login registry.example.com
docker pull registry.example.com/myapp:1.0.0

Prérequis :

• Docker Engine 20.10 ou ultérieur (vérifiez avec docker version).
• Espace disque suffisant : au moins la taille totale de toutes les images que vous prévoyez de sauvegarder, plus une marge.
• Accès à un emplacement sécurisé pour les fichiers de sauvegarde (autre serveur, stockage objet ou disque externe).
• Pour les sauvegardes de registre, les identifiants du registre et les permissions pour tirer des images.

Observation avant modification : Enregistrez les ID d'image exacts (docker images -q) et les horodatages. Cela vous aide à distinguer les différentes versions de build même si les tags sont réutilisés.

Création de sauvegardes d'images

Il existe deux méthodes principales pour sauvegarder des images Docker : enregistrer des fichiers image localement et utiliser un registre comme sauvegarde. Chacune a ses cas d'utilisation et ses limites.

Méthode 1 : Utiliser docker save pour créer des archives tar

docker save exporte une image ou un ensemble d'images vers une archive tar. C'est utile pour déplacer des images entre hôtes, pour des sauvegardes hors ligne ou pour une reprise après sinistre simple.

Sauvegarde d'une seule image :

docker save -o myapp_backup_1.0.0.tar myapp:1.0.0

Plusieurs images dans une seule archive :

docker save -o app_stack_backup.tar myapp:1.0.0 nginx:1.25 postgres:16-alpine

Sauvegarde compressée pour économiser de l'espace :

docker save myapp:1.0.0 | gzip > myapp_backup_1.0.0.tar.gz

Sortie attendue : docker save n'imprime rien en cas de succès. Le fichier est créé dans le répertoire courant. Vérifiez avec ls -lh myapp_backup_1.0.0.tar et contrôlez sa taille.

Vérification après sauvegarde :

# Charger l'image dans un démon Docker temporaire ou un environnement de test et comparer les ID d'image.
# Sur une autre machine, ou après avoir supprimé l'original :
docker load -i myapp_backup_1.0.0.tar
docker images myapp:1.0.0

Comparez l'IMAGE ID avant et après. Il doit correspondre exactement.

Quand utiliser docker save :

• Environnements hors ligne ou isolés.
• Archivage de versions spécifiques pour la conformité.
• Transfert d'images vers un hôte sans accès au registre.

Limites :

• docker save inclut toutes les couches, donc les archives peuvent être volumineuses.
• Il ne préserve pas les métadonnées d'image comme les sorties de docker inspect, seulement le système de fichiers et la configuration de l'image.
• Les images non taggées peuvent être perdues si elles ne sont pas référencées par tag ou ID.

Méthode 2 : Utiliser un registre comme sauvegarde

Les registres sont le moyen standard de stocker et de distribuer des images Docker. Vous pouvez utiliser Docker Hub, un registre cloud (AWS ECR, Google Artifact Registry, Azure Container Registry) ou un registre auto-hébergé (comme Harbor, GitLab Container Registry ou registry:2).

Pousser votre image vers un registre :

# Tagger l'image pour le registre
docker tag myapp:1.0.0 registry.example.com/myapp:1.0.0

# La pousser
docker push registry.example.com/myapp:1.0.0

Automatiser les sauvegardes avec une politique de rétention : La plupart des registres permettent de définir des règles de rétention pour conserver un certain nombre de versions d'image. Par exemple, garder les 10 versions les plus récentes de myapp et supprimer les plus anciennes. Cela empêche une croissance illimitée du stockage tout en préservant l'historique récent.

Stratégies de sauvegarde de registre :

• Sauvegarde au niveau du registre : Si vous hébergez votre propre registre, sauvegardez le répertoire de données du registre ou le backend de stockage (par exemple, un bucket S3). Consultez la documentation de votre registre pour les procédures de sauvegarde.
• Script côté client : Périodiquement, tirez toutes les images importantes et poussez-les vers un registre de sauvegarde.

Exemple de script pour sauvegarder des images spécifiques vers un registre de sauvegarde :

#!/bin/bash
set -euo pipefail

BACKUP_REGISTRY="backup.example.com"
IMAGES=("myapp:1.0.0" "nginx:1.25" "postgres:16-alpine")

for img in "${IMAGES[@]}"; do
  echo "Sauvegarde de $img"
  docker pull "$img"
  backup_tag="$BACKUP_REGISTRY/$img"
  docker tag "$img" "$backup_tag"
  docker push "$backup_tag"
  echo "Terminé pour $img"
done

Quand utiliser un registre :

• Sauvegardes régulières et historique des versions.
• Déploiements en production où les équipes doivent tirer la même image.
• Intégration avec les pipelines CI/CD.

Limites :

• Nécessite un accès réseau et la disponibilité du registre.
• Des coûts de stockage peuvent s'appliquer.
• Les politiques de rétention du registre peuvent supprimer des images plus anciennes involontairement si elles ne sont pas configurées avec soin.

Restauration d'images Docker

La restauration est le processus inverse. Vous devez vous assurer que l'image restaurée est identique à l'originale et que vous pouvez exécuter des conteneurs à partir de celle-ci.

Restauration à partir d'une archive tar (docker load)

# Charger depuis une archive tar non compressée
docker load -i myapp_backup_1.0.0.tar

# Si compressée, décompresser d'abord
gunzip -c myapp_backup_1.0.0.tar.gz | docker load

Sortie attendue : Docker imprime les images et tags chargés :

Loaded image: myapp:1.0.0
Loaded image: nginx:1.25
Loaded image: postgres:16-alpine

Vérification après chargement :

• Vérifiez que l'ID de l'image correspond à celui que vous aviez avant la sauvegarde.
• Exécutez un conteneur de test : docker run --rm myapp:1.0.0 <some command>.
• Si l'image est utilisée dans un fichier compose, exécutez docker compose up dans un environnement de test pour vérifier que l'application démarre.

Restauration à partir d'un registre

Tirez simplement l'image :

docker pull registry.example.com/myapp:1.0.0

Si le registre est inaccessible ou si l'image a été supprimée accidentellement, vous devrez peut-être récupérer à partir d'une archive côté client ou du registre de sauvegarde. Assurez-vous que votre registre de sauvegarde contient l'image et tirez à partir de là.

Restauration des volumes de données en parallèle des images

Les images seules ne contiennent souvent pas les données applicatives. Les volumes de données ou les montages de liaison doivent être restaurés séparément. C'est essentiel pour les applications avec état comme les bases de données.

Vérifier quels volumes une image utilise :

docker inspect myapp:1.0.0 | jq '.[0].Config.Volumes'

Si l'image déclare des volumes, ces chemins sont censés être sauvegardés séparément. Utilisez docker run --volumes-from ou restaurez une sauvegarde de volume (par exemple, à partir d'un tar du contenu du volume).

Vérification et diagnostics

Après la restauration, vous devez vérifier que l'image fonctionne correctement. Ne supposez pas qu'un docker load réussi signifie que l'application est fonctionnelle.

Vérification étape par étape

1. Inspecter les métadonnées de l'image :

   docker inspect myapp:1.0.0

Comparez les champs clés : Id, RepoTags, Config.Env, Config.ExposedPorts.

1. Exécuter un conteneur simple à partir de l'image :

   docker run --rm myapp:1.0.0 --version

Si cela échoue en raison de dépendances manquantes, l'image peut être incomplète.

Si l'image a un healthcheck, exécutez docker run avec --health-cmd ou utilisez le fichier compose d'origine pour démarrer le service et observez que le STATUS de docker ps devient sain.

1. Vérifier la santé de l'application :

Capturez l'ID d'image original avant la sauvegarde (docker images -q myapp:1.0.0). Après restauration, confirmez qu'il correspond. Si vous poussez/tirez via un registre, l'ID de l'image doit rester le même.

1. Comparer les ID d'image :

Diagnostics pour les problèmes courants :

• docker: Error response from daemon: No such image: signifie que l'image n'a pas été chargée ou tirée. Vérifiez le chemin de votre archive ou l'URL du registre.
• docker load réussit mais le conteneur ne démarre pas : inspectez les journaux du conteneur avec docker logs <container>.
• Volumes manquants : assurez-vous que les volumes de données sont restaurés et montés correctement avant de démarrer le conteneur.

Modes de défaillance et récupération

Les opérations de sauvegarde et de restauration peuvent échouer de plusieurs manières. Comprendre les modes de défaillance vous permet de planifier la récupération.

Défaillance : Corruption d'archive

• Cause : docker save ou docker load interrompu, erreurs de disque ou transfert de fichier incomplet.
• Détection : docker load -i archive.tar échoue avec des erreurs comme unexpected EOF ou archive/tar: invalid tar header.
• Récupération : Re-téléchargez l'archive depuis sa source (si disponible) ou recréez-la à partir de l'image originale. Validez les archives avec tar -tf archive.tar > /dev/null pour vérifier l'intégrité.

Défaillance : Registre indisponible

• Cause : Panne du registre, problèmes réseau ou authentification mal configurée.
• Impact : Impossible de pousser ou de tirer des images, perturbant les déploiements et les sauvegardes.
• Récupération : Maintenez un registre secondaire ou des archives locales. Utilisez régulièrement docker save pour les images critiques. En cas d'urgence, récupérez les images à partir d'autres nœuds qui pourraient les avoir en cache.

Défaillance : Discordance d'ID d'image après restauration

• Symptôme : Vous avez restauré une image mais son ID diffère de l'original. Cela peut arriver si vous avez reconstruit l'image au lieu de restaurer une sauvegarde.
• Impact : L'image restaurée peut ne pas être la version exacte dont vous avez besoin, entraînant des changements de comportement.
• Récupération : Utilisez toujours docker save/docker load ou un pull de registre pour préserver les ID d'image. Ne vous fiez jamais uniquement aux tags, car les tags peuvent être déplacés vers différentes images.

Défaillance : Perte de volume de données

• Symptôme : Les conteneurs démarrent mais les données sont manquantes ou corrompues.
• Cause : Les volumes n'ont pas été sauvegardés ou ont été restaurés au mauvais emplacement.
• Récupération : Mettez en place une stratégie de sauvegarde des volumes. Pour les volumes nommés, utilisez docker run --rm -v volume_name:/data -v $(pwd):/backup alpine tar czf /backup/volume.tar.gz -C /data .. Pour les montages de liaison, sauvegardez directement le répertoire hôte.

Défaillance : Secrets divulgués dans les sauvegardes

• Risque : Les images peuvent contenir des secrets intégrés lors du build. Sauvegarder et stocker ces images expose les secrets.
• Atténuation : N'intégrez jamais de secrets dans les images. Utilisez des variables d'environnement ou la gestion des secrets à l'exécution. Analysez les images avec des outils comme Docker Scout ou Trivy avant la sauvegarde pour détecter les secrets exposés. Si des secrets ont été intégrés, envisagez de reconstruire sans eux avant la sauvegarde.

Pièges courants et comment les éviter

1. Utiliser docker export au lieu de docker save. docker export exporte le système de fichiers d'un conteneur, pas une image. Il perd l'historique, les métadonnées et les couches. Évitez-le pour les sauvegardes d'images.

• Pourquoi cela arrive : Mal comprendre la différence entre conteneurs et images.
• Évitement : Utilisez toujours docker save pour les images.

1. Sauvegarder des images sans vérifier l'intégrité. Une sauvegarde est inutile si vous ne testez jamais sa restauration.

• Pourquoi cela arrive : Pression du temps ou supposer que le processus fonctionne.
• Évitement : Planifiez des tests de restauration périodiques. Par exemple, restaurez une image de sauvegarde sur un hôte de test mensuellement et exécutez un test de fumée.

1. Ignorer la taille des images et la croissance du stockage. Avec le temps, les archives peuvent consommer un espace disque énorme si elles ne sont pas gérées.

• Pourquoi cela arrive : Pas de politique de rétention ou de nettoyage.
• Évitement : Utilisez les politiques de rétention du registre et supprimez les anciennes archives locales qui ne sont plus nécessaires. Surveillez l'utilisation du disque avec docker system df.

1. Ne pas sauvegarder les données des volumes. L'image seule peut ne pas suffire pour la récupération de l'application.

• Pourquoi cela arrive : Se concentrer uniquement sur les images et oublier les données avec état.
• Évitement : Identifiez les volumes utilisés par vos conteneurs (docker inspect -f '{{ .Mounts }}' <container>) et mettez en place un calendrier de sauvegarde des volumes.

1. Supposer que le tag latest est spécifique. Le tag latest est ambigu et peut pointer vers différentes images au fil du temps.

• Pourquoi cela arrive : Dépendance excessive à latest en production.
• Évitement : Utilisez des tags de version explicites (par exemple, myapp:1.0.0) et évitez latest en production.

1. Ne pas sécuriser les fichiers de sauvegarde. Les fichiers d'archive peuvent contenir du code ou des configurations applicatives sensibles.

• Pourquoi cela arrive : Sauvegardes stockées dans des emplacements non protégés.
• Évitement : Chiffrez les archives (par exemple, gpg -c myapp_backup.tar) et stockez-les dans un stockage à accès contrôlé. Pour les sauvegardes de registre, utilisez des registres privés avec des politiques IAM strictes.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour mettre en œuvre un processus robuste de sauvegarde et de restauration d'images.

Responsabilité et revue : Chaque tâche a un seul responsable imputable. Le Responsable DevOps revoit la stratégie de sauvegarde mensuellement et après tout changement majeur d'infrastructure.

Conclusion

La sauvegarde et la restauration d'images Docker ne se résument pas à exécuter docker save et docker load. C'est un processus continu qui nécessite un inventaire, des sauvegardes régulières, un stockage sécurisé et des restaurations testées. En suivant les exemples pratiques et la liste de contrôle de cet article, vous pouvez construire une stratégie de sauvegarde fiable qui protège vos applications et vos données.

Commencez petit : choisissez une image critique, créez une sauvegarde avec docker save, stockez-la en sécurité, puis entraînez-vous à la restaurer sur un hôte de test. Au fur et à mesure que vous gagnez en confiance, étendez pour inclure toutes les images de production et leurs volumes associés. N'oubliez pas qu'une sauvegarde n'est aussi bonne que votre capacité à la restaurer.

Prochaines étapes :

1. Exécutez les commandes d'inventaire de cet article et documentez vos images.
2. Choisissez une méthode de sauvegarde (docker save ou registre) et mettez-la en œuvre pour votre image la plus importante.
3. Planifiez un test de restauration régulier et attribuez un responsable.
4. Revoyez votre plan de reprise après sinistre et assurez-vous que les sauvegardes d'images sont intégrées.

En faisant de la sauvegarde et de la restauration d'images une routine de vos opérations, vous réduisez les risques et accélérez la récupération lorsque des problèmes surviennent.