Migrer ses applications Docker de serveur

Ce guide s'appuie sur la documentation de Docker sur les volumes et sur celle de Docker Compose, relues le 15 octobre 2026. Les commandes supposent une application lancée avec docker compose, dans un dossier ~/monapp.

1. Faire l'inventaire sur l'ancien serveur

1. Listez les projets Compose, arrêtés compris : docker compose ls --all
2. Dans le dossier de chaque projet, listez ses conteneurs : docker compose ps
3. Pour chaque conteneur, affichez ses montages réels : docker inspect --format '{{json .Mounts}}' nom-du-conteneur. Le format json d'un champ est décrit dans la documentation de docker inspect.
4. Notez pour chaque montage son type (volume ou bind), son nom s'il s'agit d'un volume, sa Source, le chemin sur le serveur, et sa Destination, le chemin dans le conteneur.
5. Ouvrez le fichier compose et notez les ports publiés, les réseaux déclarés external et les images utilisées.

L'inventaire par docker inspect est le seul complet. Un volume anonyme, créé par une image sans nom dans le fichier compose, porte un nom fait de chiffres et de lettres, sans le préfixe du projet. Un dossier monté peut se trouver hors du dossier du projet, par exemple sous /srv. Les deux s'oublient facilement.

Vérifiez aussi que chaque image porte une étiquette de version précise, par exemple postgres:16 plutôt que postgres:latest. Le nouveau serveur doit lancer la même version que l'ancien, sans quoi une base copiée telle quelle peut refuser de démarrer.

2. Arrêter et archiver

Prévenez vos utilisateurs : l'application est indisponible de l'arrêt jusqu'à la bascule. Les fichiers d'une base appartiennent souvent à un autre utilisateur que le vôtre, d'où sudo : il lit tous les fichiers, et l'option p de tar garde leurs droits, --numeric-owner leurs propriétaires.

1. Dans le dossier du projet, arrêtez l'application sans supprimer les conteneurs : docker compose stop
2. Créez un dossier pour les archives : mkdir ~/migration
3. Archivez le dossier du projet, dossiers montés à l'intérieur compris : sudo tar czpf ~/migration/projet.tar.gz --numeric-owner -C ~ monapp
4. Archivez chaque volume, nommé ou anonyme, à partir de la Source relevée : sudo tar czpf ~/migration/donnees.tar.gz --numeric-owner -C /var/lib/docker/volumes/monapp_donnees/_data .
5. Archivez de la même façon chaque dossier monté hors du projet, en remplaçant le chemin après -C par sa Source.
6. Rendez les archives lisibles par votre compte, pour pouvoir les copier : sudo chown -R "$USER": ~/migration

Notez, pour chaque archive, la Destination du montage qu'elle contient : c'est elle qui permet de retrouver le bon volume sur le nouveau serveur.

Pour une base de données, un export par l'outil de la base ajoute une sécurité : un fichier SQL se relit avec n'importe quelle version récente du moteur. Les commandes pour PostgreSQL, MySQL et MariaDB sont dans Sauvegarde Docker : conteneurs et volumes.

3. Copier les archives sur le nouveau serveur

1. Si l'ancien serveur peut se connecter au nouveau par clé SSH, envoyez le dossier directement : rsync -avz ~/migration admin@nouveau-serveur:~/
2. Sinon, passez par votre ordinateur : rapatriez le dossier avec rsync ou scp, puis renvoyez-le vers le nouveau serveur.

Les archives contiennent le fichier .env, qui porte le plus souvent des mots de passe. Ne les faites jamais transiter par un service de partage ou un dépôt Git, et supprimez-les une fois la migration vérifiée.

4. Restaurer sur le nouveau serveur

1. Créez d'abord chaque réseau déclaré external dans le fichier compose, sans quoi l'étape suivante échoue : docker network create proxy, ou installez le reverse proxy qui le crée.
2. Restaurez le dossier du projet, sous le même nom : sudo tar xzpf ~/migration/projet.tar.gz --numeric-owner -C ~, puis vérifiez que ~/monapp/.env est bien là. L'option --numeric-owner a rendu au dossier le numéro d'utilisateur de l'ancien serveur : si ls -ln ~/monapp montre un autre propriétaire que le vôtre, reprenez la main sur le dossier et sur les fichiers posés à sa racine (fichier compose, .env), sans toucher aux dossiers de données montés à l'intérieur : sudo chown "$USER": ~/monapp, puis sudo find ~/monapp -maxdepth 1 -type f -exec chown "$USER": {} +. Protégez enfin le fichier avec chmod 600 ~/monapp/.env.
3. Dans le dossier du projet, créez conteneurs et volumes sans démarrer les services : docker compose up --no-start
4. Relevez les nouveaux montages avec docker inspect --format '{{json .Mounts}}' nom-du-conteneur. Un volume anonyme a changé de nom : retrouvez-le par sa Destination.
5. Décompressez chaque archive dans la Source de son volume : sudo tar xzpf ~/migration/donnees.tar.gz --numeric-owner -C /var/lib/docker/volumes/monapp_donnees/_data
6. Pour un dossier monté hors du projet, recréez son chemin avec sudo mkdir -p, puis décompressez son archive de la même façon.
7. Démarrez l'application : docker compose up -d
8. Contrôlez les journaux au démarrage : docker compose logs -f, puis Ctrl+C pour en sortir.

Si un volume avait déjà été initialisé par un premier démarrage, videz-le avant de restaurer : mélanger deux bases dans un même dossier donne un résultat imprévisible.

5. Tester, puis basculer

1. Testez l'application avant de toucher au DNS, par exemple en associant le domaine à l'adresse du nouveau serveur dans le fichier hosts de votre ordinateur.
2. Ouvrez sur le nouveau serveur les ports dont l'application a besoin, en plus de ceux du reverse proxy.
3. Remplacez l'adresse IP des enregistrements DNS du domaine par celle du nouveau serveur : voir Pointer un nom de domaine vers son VPS. Un TTL baissé la veille raccourcit l'attente.
4. Gardez l'ancien serveur quelques jours, éteint ou arrêté, comme copie de secours.

La migration VPS offerte chez Hubspace

Pour un VPS Hubspace, la migration VPS est offerte sur toutes les tailles. Vous nous donnez un accès SSH à votre serveur actuel, quel que soit son hébergeur. Nous relevons vos applications, leurs volumes, leurs bases et leurs ports, puis nous convenons avec vous de la taille du VPS et de la date de bascule.

Nous copions ensuite les fichiers compose, les fichiers d'environnement, les volumes et les bases. Pour une base, la copie finale se fait pendant une courte pause des conteneurs, à l'heure convenue. Nous relançons les conteneurs, vous testez, puis vos domaines pointent vers le nouveau VPS. L'ancien serveur reste en place le temps de la propagation.

Ce qui tourne hors de Docker est à réinstaller, l'ouverture d'autres ports que 22, 80 et 443 se fait depuis l'onglet « Firewalls » de votre espace client, et l'administration des applications après la bascule reste à votre charge : voir Ouvrir un port sur son VPS.

Questions fréquentes