Migrer un conteneur Docker d’un serveur à un autre sans tout casser

Tu bosses sur un projet qui tourne bien, tu as ton conteneur Docker avec tout dedans : appli, config, logs, base de données… Et puis un jour, il faut le migrer : changement d’hébergeur, de machine, besoin de scaler, ou tout simplement nettoyage de printemps.

Et là, tu te poses LA question qu’on s’est tous posée au moins une fois :

Comment je déplace mon conteneur proprement, sans tout péter, sans me taper une réinstall complète à la main ?

Bonne nouvelle : Docker, c’est fait pour être portable. Mais il y a quelques pièges à éviter, surtout si tu utilises des volumes, des réseaux personnalisés ou une base intégrée.

Voici plusieurs méthodes, selon ton niveau de parano, ton besoin de reproductibilité et le temps que tu veux y passer.

📦 1. Méthode simple : exporter / importer le conteneur

C’est un peu la version “brute” du transfert. Tu veux tout prendre tel quel et le remettre ailleurs.

Sur le serveur source :

docker export mon_conteneur > mon_conteneur.tar

Puis transfère ce fichier vers le nouveau serveur (via scp, rsync, sftp…).

Sur le serveur cible :

cat mon_conteneur.tar | docker import - mon_image_migrée
docker run -d --name mon_conteneur_migré mon_image_migrée

✅ Avantage : rapide, pas besoin du Dockerfile
❌ Inconvénient : tu perds tout l’historique des couches Docker, les volumes ne sont pas inclus

🧱 2. Méthode propre : sauvegarder l’image + les volumes

Si tu veux conserver les volumes de données, il faut les gérer à part.

a. Sauvegarde de l’image

docker commit mon_conteneur mon_image_migrée
docker save mon_image_migrée > mon_image_migrée.tar

b. Sauvegarde du volume (par exemple /var/lib/docker/volumes/monvolume/_data)

tar czvf data.tar.gz -C /var/lib/docker/volumes/monvolume/_data .

Ou utilise docker run pour extraire proprement :

docker run --rm -v monvolume:/volume -v $(pwd):/backup alpine \
  tar czf /backup/data.tar.gz -C /volume .

Transfère l’image et l’archive sur le nouveau serveur.

c. Sur le serveur de destination

docker load < mon_image_migrée.tar

# Recréer le volume
docker volume create monvolume

# Restaurer les données
docker run --rm -v monvolume:/volume -v $(pwd):/backup alpine \
  tar xzf /backup/data.tar.gz -C /volume

Puis relance ton conteneur avec les bons mounts.

⚙️ 3. Méthode “infra propre” : avec docker-compose

Si ton projet tourne avec docker-compose, alors tu as déjà une description déclarative de ton infra. C’est de loin la méthode la plus propre pour migrer.

Étapes :

1. Copie le répertoire du projet (avec docker-compose.yml, .env, etc.) vers le nouveau serveur.
2. Sauvegarde les volumes si besoin, comme vu plus haut.
3. Rebuild sur le serveur cible :

docker-compose pull
docker-compose up -d

Ou, si tu n’as pas d’image à puller :

docker-compose build
docker-compose up -d

Tu restaures les volumes, tu lances, et voilà.

💡 Astuce : tu peux aussi utiliser rsync ou scp -r pour tout copier d’un coup. Par exemple :

rsync -avz -e ssh ./ monuser@nouveau-serveur:/home/monuser/mon-projet

🛡️ 4. Attention aux pièges courants

• Ports déjà utilisés : le conteneur peut ne pas démarrer si le port (ex. 80, 443) est occupé sur la nouvelle machine.
• Variables d’environnement manquantes : si tu n’as pas migré .env ou les secrets, certains services peuvent planter.
• Compatibilité Docker/Compose : si les versions sont très différentes, certaines options peuvent ne plus marcher.
• Volumes nommés vs paths absolus : attention à ce que tu as utilisé dans le docker run ou le docker-compose.yml.

🚀 Méthode bonus : avec docker context et docker cp

Si tu veux éviter les transferts manuels, tu peux créer un contexte Docker distant :

docker context create monserveur --docker "host=ssh://user@ip"
docker context use monserveur

Tu peux ensuite envoyer une image, copier des fichiers, lancer un conteneur… comme si tu étais en local.

Exemple :

docker build -t mon_image .
docker image save mon_image | ssh user@ip docker image load

C’est un peu plus avancé, mais redoutablement efficace pour gérer plusieurs machines.