Migration serveur OpenShip v0.4.7 : checklist 2026

Symptôme : les conteneurs cibles fonctionnent, mais la base de données, les tâches en arrière-plan ou le retour vers l’ancien serveur ne sont pas encore prouvés. Solution la plus rapide : ne basculez pas le domaine ; validez séparément les images, les conteneurs, les volumes, les secrets, les certificats, les tâches et la restauration de l’ancien nœud.

Cette méthode s’applique à la migration serveur OpenShip v0.4.7 d’une application Docker existante vers un nouveau serveur ou un nouveau nœud de production. OpenShip v0.4.7 a apporté, d’après le changelog officiel consulté le 3 août 2026, des améliorations de fiabilité sur la chaîne de migration Docker ; cela ne transforme toutefois pas une migration terminée en validation de production. La décision de couper l’ancien serveur doit reposer sur des preuves vérifiables dans votre environnement, pas sur l’état « terminé » affiché par l’outil.

Cette page est destinée aux développeurs qui doivent s’assurer que les services repris peuvent être reconstruits, aux équipes d’exploitation qui veulent limiter le risque lié aux données et aux certificats, ainsi qu’aux responsables techniques qui doivent définir une condition claire avant de payer ou de conserver un second nœud en parallèle.

Dernière mise à jour : 3 août 2026. Vérification effectuée à partir du changelog officiel, du dépôt de code, de la documentation de migration et de la documentation Docker disponibles à cette date. Une nouvelle vérification est nécessaire si OpenShip publie une version de migration différente, modifie la logique de prise en charge des conteneurs ou change le transfert des volumes et des certificats.

La fin de la migration ne vaut pas encore validation

Une migration Docker échoue rarement de manière spectaculaire. Le cas le plus dangereux est plus discret : la page d’accueil répond, mais les données sont anciennes ; le conteneur principal est actif, mais le travailleur n’est pas lancé ; le certificat fonctionne, mais le renouvellement échouera ; ou le tableau de bord indique un ancien conteneur arrêté alors qu’un autre processus reçoit toujours le trafic.

La documentation officielle présente OpenShip comme une couche capable de construire les images, de connecter un serveur par SSH, de gérer les domaines et de conserver une version précédente pour un retour arrière. Ce sont des capacités annoncées par le produit, non une preuve que votre projet a correctement transféré ses volumes, ses secrets et ses dépendances. (openship.io)

Avant toute bascule, vous devez donc conserver quatre éléments :

• l’inventaire des services source et cible ;
• les identifiants exacts des images et des configurations ;
• la preuve de restauration des données ;
• la procédure écrite permettant de remettre l’ancien serveur en service.

Les coûts cachés se situent généralement ailleurs que dans le transfert lui-même :

• dépendances oubliées : un worker, un service Redis, un stockage d’objets ou une tâche planifiée peut ne pas apparaître dans le parcours utilisateur principal ;
• état différent : le conteneur peut repartir avec une configuration valide mais un volume vide, un mauvais chemin ou un propriétaire de fichiers incorrect ;
• permissions excessives : une clé SSH ou une clé d’API copiée sans filtrage peut donner au nouveau nœud un accès plus large que nécessaire ;
• double exécution : deux consommateurs de file ou deux tâches planifiées peuvent traiter le même événement ;
• retour arrière incomplet : le domaine peut revenir vers l’ancien serveur alors que les dernières écritures ont déjà été faites sur le nouveau.

Docker précise qu’un volume persiste indépendamment de la suppression d’un conteneur, mais cette persistance ne signifie pas que le volume a été copié sur votre nouveau serveur. La différence entre « volume existant » et « volume restauré avec les bonnes données » doit rester au centre de votre contrôle. (docs.docker.com)

Les preuves à réunir avant la bascule

Commencez par créer un dossier de preuve horodaté, conservé hors des deux serveurs. Il peut contenir les sorties de commandes, les captures du tableau de bord, les identifiants d’images, les contrôles de somme, les journaux de restauration et le plan de retour arrière.

1. Définir précisément le périmètre

Relevez la version réellement exécutée, et pas seulement la version sélectionnée dans l’interface. Notez :

• le serveur source et le serveur cible ;
• le projet OpenShip concerné ;
• chaque service attendu ;
• chaque image utilisée ;
• chaque port, réseau et point de montage ;
• chaque base de données, file de messages et stockage externe ;
• chaque tâche planifiée ou consommateur permanent.

Comparez ensuite la définition Compose, les fichiers d’environnement et la liste issue du moteur Docker. Cette comparaison est indispensable pour détecter un service déclaré mais jamais lancé, ou un conteneur lancé manuellement qui ne figure plus dans le dépôt.

Preuve à conserver : export de la configuration, inventaire des conteneurs, liste des volumes et copie des paramètres de déploiement.

Critère de passage : aucun service utilisé par un parcours métier ou une tâche automatique ne doit rester sans propriétaire.

Action en cas d’échec : interrompez la migration et complétez la définition avant de recopier les données. Ne tentez pas de « corriger après la bascule » un service dont vous ne connaissez pas encore le rôle.

2. Vérifier les images et les conteneurs réels

Pour chaque service, contrôlez l’image exacte, son identifiant, le statut du conteneur, le réseau, le port publié et le point de montage. Le contrôle doit être effectué sur le serveur cible, directement auprès du moteur Docker, et non uniquement dans un cache d’interface.

Une redéploiement contrôlé est ensuite nécessaire. Arrêtez et recréez un service non critique, puis vérifiez qu’il revient avec la même configuration. Pour un service construit depuis le dépôt, confirmez qu’il peut être reconstruit. Pour un service basé sur une image distante, confirmez que l’image peut être récupérée avec les identifiants présents sur le nouveau nœud.

Le cas des « anciens conteneurs arrêtés » mérite une vérification distincte. Un service peut sembler normal parce que le proxy inverse redirige encore vers l’ancien serveur, parce qu’un second conteneur écoute sur un autre réseau ou parce qu’un processus hors Docker répond sur le port attendu. Comparez donc l’adresse de destination du proxy, l’adresse IP publique, le port réellement ouvert et les journaux d’accès.

Le passage est validé seulement lorsque vous pouvez répondre à cette question : quel processus reçoit exactement une requête lorsque vous appelez le domaine de test ?

3. Tester les volumes et la base de données

Le transfert des données est le point où une migration Docker peut devenir irréversible. Un conteneur peut être parfaitement sain tout en utilisant un volume neuf. Pour éviter ce piège, comparez la liste des volumes source et cible, leur emplacement, leur propriétaire, leur taille indicative et leur association avec les services.

Ne réduisez pas le test à un comptage de fichiers. Pour une base de données, sélectionnez des objets représentatifs : un compte, une commande, un projet, un fichier audio ou vidéo, une miniature, un résultat de traitement ou une entrée de file. Les exemples doivent correspondre à votre activité ; une application de design ou de production audiovisuelle nécessite notamment de vérifier les fichiers lourds, les chemins de rendu et les métadonnées, pas seulement la page de connexion.

Effectuez ensuite quatre actions dans cet ordre :

1. démarrez la base avec la copie restaurée ;
2. lisez un échantillon métier ;
3. écrivez une donnée explicitement marquée comme test ;
4. redémarrez le conteneur et relisez cette donnée.

Pour une sauvegarde, le statut « réussie » n’est pas suffisant. Vous devez restaurer une copie dans un environnement isolé, vérifier que le service démarre et confirmer que l’application peut interroger les données restaurées. Les pratiques Docker recommandent précisément d’automatiser la sauvegarde, la migration et le test de restauration plutôt que de considérer la présence d’une archive comme une garantie. (docs.docker.com)

Si la base a continué à accepter des écritures sur l’ancien serveur pendant la copie, arrêtez-vous avant la bascule : vous devez établir la frontière exacte entre les données source et cible. Sans cette frontière, un retour arrière peut supprimer ou écraser les dernières écritures.

Les secrets, les accès et les domaines à contrôler

4. Reprendre les variables et les permissions sans élargir les accès

Comparez les variables d’environnement attendues avec celles réellement injectées dans le conteneur. Contrôlez en particulier :

• les chaînes de connexion à la base ;
• les clés de signature de session ;
• les identifiants du stockage objet ;
• les clés d’API externes ;
• les informations du registre d’images ;
• les paramètres de messagerie ;
• les secrets utilisés par les tâches en arrière-plan.

Ne copiez pas aveuglément un fichier d’environnement complet. Un nouveau serveur peut nécessiter une adresse différente, tandis qu’un jeton de test ou une ancienne clé ne devrait pas entrer en production. Utilisez un compte de déploiement limité, un accès SSH limité à la tâche requise et des clés séparées pour le registre, la base et les services externes.

OpenShip documente une gestion des secrets par environnement ainsi qu’un modèle d’API soumis à authentification ; ces éléments doivent être vérifiés dans votre configuration effective, notamment lorsque le nouveau nœud doit récupérer des images ou appeler une API externe. (openship.io)

Preuve à conserver : liste des variables par nom, sans valeur secrète, matrice des permissions, journal d’une connexion réussie et résultat d’un test d’accès refusé.

Critère de passage : le nouveau nœud peut effectuer ses opérations nécessaires, mais un compte de déploiement ne peut pas administrer des ressources sans rapport avec la migration.

Action en cas d’échec : révoquez les jetons trop larges, recréez des identifiants ciblés et recommencez le test avant toute exposition publique.

5. Tester le domaine, HTTPS et les connexions persistantes

Avant de modifier le DNS, utilisez un sous-domaine temporaire, une résolution locale ou une entrée contrôlée dans le fichier hosts. Vérifiez successivement :

• la réponse HTTP ;
• la redirection vers HTTPS ;
• le certificat présenté ;
• le nom d’hôte couvert par le certificat ;
• les en-têtes transmis par le proxy ;
• les chemins d’API ;
• les connexions WebSocket ;
• les téléchargements et téléversements de fichiers ;
• les contrôles de santé.

La documentation officielle indique qu’OpenShip prend en charge les domaines personnalisés, le certificat automatique et les connexions WebSocket ; votre validation doit toutefois confirmer que le proxy, le DNS et les en-têtes de votre serveur permettent réellement ces fonctions. (openship.io)

La documentation d’installation officielle expose notamment les ports HTTP et HTTPS ainsi qu’un port d’interface pour le service ; utilisez ces informations comme point de comparaison, pas comme autorisation d’ouvrir indistinctement tous les ports vers Internet. (openship.io)

Pour le certificat, contrôlez le nom, la chaîne, la date d’expiration et les conditions de renouvellement. Les certificats de l’autorité de certification ne se renouvellent pas parce qu’un certificat initial a été émis : le domaine doit toujours pointer correctement, le service de validation doit rester accessible et le proxy doit transmettre les requêtes attendues. Consultez la documentation officielle du protocole ACME pour confirmer le mécanisme utilisé.

Documentez ensuite la fenêtre DNS : heure prévue, durée de maintien de l’ancien serveur, personne autorisée à modifier la zone et méthode de vérification depuis plusieurs réseaux. Ne promettez pas une durée de propagation universelle ; elle dépend de la configuration DNS, des caches intermédiaires et des résolveurs utilisés par vos clients.

La bascule et le retour arrière doivent être testés ensemble

6. Coordonner les tâches, les files et les écritures

Avant de couper le trafic, mettez en pause les tâches planifiées qui écrivent dans la base, les consommateurs de files et les traitements de fichiers. Pour une application audio ou vidéo, cela inclut les rendus, les transcodages, les extractions de miniatures et les nettoyages automatiques. Pour une application de design, incluez les exports, les conversions et les notifications asynchrones.

Ne démarrez pas les mêmes tâches sur les deux serveurs sans mécanisme d’exclusion explicite. Deux consommateurs peuvent produire des doublons ; deux tâches de nettoyage peuvent supprimer un fichier encore utilisé ; deux processus de synchronisation peuvent écraser des versions différentes.

La séquence recommandée est la suivante :

1. annoncer une fenêtre de changement et geler les déploiements ;
2. arrêter ou suspendre les producteurs d’événements ;
3. laisser les consommateurs vider leur file, ou conserver un point de reprise documenté ;
4. effectuer la dernière sauvegarde ;
5. vérifier la restauration cible ;
6. basculer le domaine ;
7. relancer les tâches sur le nouveau serveur uniquement ;
8. tester un parcours utilisateur et un traitement asynchrone ;
9. surveiller les erreurs et les files ;
10. conserver l’ancien serveur sans nouvelle écriture.

7. Définir la condition de fermeture de l’ancien serveur

Vous ne pouvez fermer l’ancien nœud que si les quatre conditions suivantes sont simultanément réunies :

• le nouveau serveur reçoit effectivement le trafic attendu ;
• les données écrites après la bascule sont localisées et sauvegardées ;
• les tâches et les files fonctionnent sans double consommation ;
• le retour vers l’ancien serveur a été préparé et, idéalement, exécuté dans un test contrôlé.

Le retour arrière doit préciser ce qui se passe pour les écritures réalisées sur le nouveau serveur. Revenir au DNS précédent ne suffit pas si la base source n’a pas reçu ces données. Vous devez soit disposer d’une réplication ou d’une procédure de réconciliation, soit accepter une fenêtre de gel et définir explicitement la perte maximale tolérée.

Le fait qu’OpenShip conserve une version précédente prête à être restaurée concerne principalement la version déployée et le routage ; cela ne remplace pas une stratégie de restauration de base, de volumes et de secrets. (openship.io)

Checklist finale de décision

Cochez chaque ligne uniquement lorsque la preuve est archivée :

• [ ] La version OpenShip v0.4.7 réellement utilisée a été relevée.
• [ ] Le périmètre des services a été comparé au dépôt et aux conteneurs actifs.
• [ ] Chaque image cible possède un identifiant vérifiable.
• [ ] Un service construit a été reconstruit avec succès.
• [ ] Un service basé sur une image a été récupéré avec les permissions prévues.
• [ ] Aucun conteneur doublon ni mauvais mappage de port n’est présent.
• [ ] Les volumes source et cible ont été comparés.
• [ ] La base a passé un test de lecture, d’écriture et de redémarrage.
• [ ] Une sauvegarde a été restaurée dans un environnement isolé.
• [ ] Les clés et variables correspondent au nouvel environnement.
• [ ] Les ports d’administration ne sont pas exposés par erreur.
• [ ] Le domaine de test répond en HTTP, HTTPS et WebSocket.
• [ ] Le certificat et son renouvellement ont été vérifiés.
• [ ] Les tâches planifiées et consommateurs sont contrôlés sur un seul nœud.
• [ ] Le DNS, la fenêtre de bascule et la durée de maintien de l’ancien serveur sont documentés.
• [ ] Le retour arrière ne dépend pas d’une donnée dont la frontière est inconnue.

Si une seule ligne critique reste vide, la décision rationnelle est de maintenir l’ancien serveur et de corriger la preuve manquante. Une migration techniquement terminée mais non vérifiable reste une migration incomplète.

Ce que votre choix de serveur change réellement

Si vous effectuez cette migration sur une machine que vous devez immédiatement libérer, vous perdez la possibilité de comparer les deux environnements en parallèle. Cette contrainte augmente le risque : un certificat mal renouvelé, un worker oublié ou un volume incomplet peut vous obliger à restaurer dans l’urgence, sans référence active.

Pour une équipe qui doit conserver un ancien nœud, exécuter une restauration isolée ou tester une bascule avant la date de renouvellement de son infrastructure, la location temporaire d’un serveur indépendant peut être plus confortable qu’un remplacement direct. Vous gardez alors l’ancien environnement comme point de comparaison, vous réalisez la validation OpenShip v0.4.7 hors production, puis vous ne supprimez la source qu’après avoir prouvé les données, les tâches et le retour arrière. Vous pouvez consulter le centre d’aide de kvmboot pour vérifier les modalités d’exploitation, puis examiner un nœud disponible pour un environnement de migration si vous avez besoin d’un espace séparé.

Cette approche n’est pas la meilleure pour une charge lourde et stable qui doit rester en service pendant des mois, ni pour une application dépendante d’un périphérique physique local. Elle devient pertinente lorsque le besoin est temporaire : double exploitation, test de restauration, validation d’un nouveau serveur ou migration d’une application AI SaaS sans sacrifier immédiatement l’ancien chemin de retour.

Questions fréquentes

Les réponses ci-dessous reprennent les points qui provoquent le plus souvent une fausse validation lors d’un changement de serveur.

Une migration Docker avec OpenShip peut-elle supprimer les données de production ?

Oui, si les volumes persistants, les chemins de montage ou la base de données ne sont pas copiés et restaurés correctement. Contrôlez la liste des volumes avant le départ, effectuez une restauration isolée, puis testez une écriture, une lecture et un redémarrage sur le nouveau serveur. Une sauvegarde marquée comme réussie ne suffit pas à prouver que les données sont récupérables.

Pourquoi les anciens conteneurs semblent-ils arrêtés alors que le service répond encore ?

Le trafic peut encore passer par un proxy, un autre nœud ou un conteneur recréé sous un nom différent. Ne vous fiez donc pas uniquement à l’état affiché dans le tableau de bord. Comparez l’adresse IP, le port publié, le proxy inverse, les journaux et le processus réellement à l’écoute avant de supprimer l’ancien environnement.

Comment basculer le domaine et le certificat pendant un changement de serveur ?

Préparez d’abord le nouveau serveur avec un domaine de test ou une résolution locale, puis vérifiez HTTP, HTTPS, les en-têtes du proxy et les connexions WebSocket. Après validation, modifiez le DNS pendant une fenêtre documentée, conservez l’ancien nœud actif et contrôlez l’émission ou le renouvellement du certificat avant de fermer la source.

Comment vérifier une base de données et ses volumes après la migration ?

Comparez le schéma, le nombre d’objets et quelques enregistrements métier sélectionnés avant et après la copie. Testez ensuite une écriture, une lecture, un redémarrage du conteneur et une nouvelle lecture. Pour la sauvegarde, restaurez une copie dans un environnement isolé et vérifiez que l’application peut réellement l’utiliser.

Peut-on revenir à l’ancien serveur après un échec de migration OpenShip ?

Oui, seulement si l’ancien nœud reste intact, si la frontière des écritures est connue et si les tâches planifiées ne s’exécutent pas simultanément sur les deux serveurs. Avant la bascule, documentez le DNS, les secrets, les volumes et la commande de remise en service. Après la bascule, ne détruisez pas la source avant un test de retour arrière.