Pouvez-vous modifier le port publié d’un conteneur sans reconstruire sa base de données ?
Oui, vous pouvez modifier le port publié d’un conteneur sans recréer sa base de données, à condition que celle-ci reste sur le même stockage persistant vérifié.
Sur un NAS domestique ou un hôte Docker, le port visible appartient généralement au conteneur d’application remplaçable, tandis que les enregistrements, les comptes et les paramètres résident dans un volume nommé, un montage lié ou un service de base de données distinct. La modification sûre consiste donc à conserver la définition du déploiement et les chemins persistants, à modifier uniquement la règle de publication côté hôte, à recréer le service d’application concerné, puis à vérifier chaque proxy, favori, rappel, règle de pare-feu et contrôle d’intégrité qui fait encore référence à l’ancien port.
Séparez le port hôte publié de l’écouteur du conteneur
Notez les deux points de terminaison actuels séparément avant toute modification. Dans 8080:80, les clients se connectent au port 8080 de l’hôte Docker, tandis que l’application continue d’écouter sur le port 80 à l’intérieur du conteneur. Modifier la partie gauche ne change pas automatiquement le processus de l’application ni sa connexion à la base de données.
Un cas de dépannage présenté dans la communauté Docker souligne que le mappage côté hôte et l’écouteur interne sont distincts, et qu’un nouveau port publié ne peut pas fonctionner si rien n’écoute en interne sur le port de destination.
Inspectez les ports publiés du conteneur en cours d’exécution ainsi que les sockets d’écoute, puis testez le point de terminaison interne depuis le conteneur ou son réseau. Laissez le port interne inchangé, sauf si l’application elle-même doit être déplacée. Ce premier test évite qu’une simple modification du port hôte n’entraîne une reconfiguration inutile de l’application.
Protégez le chemin actuel de la base de données avant de recréer le service
Notez le fichier Compose, la balise ou l’empreinte de l’image, les fichiers d’environnement, les volumes nommés, les montages liés, les noms de réseau, les secrets et le nom d’hôte de la base de données. L’objectif est de déterminer précisément quel objet contient l’état persistant avant que Docker ne remplace le conteneur d’application.
Modifier la publication des ports nécessite une nouvelle configuration du conteneur, mais pas la création d’une nouvelle image ni d’une nouvelle base de données. Une réponse pratique sur Docker distingue la recréation du conteneur de la reconstruction de l’image d’application lorsque les paramètres de port changent.
Effectuez une sauvegarde ou un instantané cohérent avec l’application de la base de données si le service est important, puis vérifiez que le chemin de la base de données ne se trouve pas dans la couche inscriptible du conteneur. Arrêtez-vous si la liste des montages est ambiguë, si le nom du volume a changé ou si l’application actuelle semble utiliser une base de données vide inattendue.
Modifiez uniquement le mappage côté hôte et recréez le service d’application
Modifiez le service d’application pour passer d’un mappage tel que 8080:80 à 8081:80. Conservez l’image, le port interne, les volumes, l’URL de la base de données, le nom du service, les réseaux et le mappage utilisateur, sauf si une autre exigence vérifiée l’impose.
La syntaxe des ports de Compose est interprétée de l’hôte vers le conteneur : modifier le côté hôte laisse donc le processus à l’écoute sur son port interne existant. Un exemple du forum Docker explique pourquoi la partie gauche correspond au port hôte et pourquoi la partie droite doit toujours correspondre à l’écouteur de l’application.
Recréez uniquement le service d’application avec la définition mise à jour. N’utilisez pas de commande de pile qui supprime les volumes, ne réinitialisez pas la base de données et n’ajoutez pas --build, sauf si l’image elle-même a changé. Après la recréation, inspectez les montages effectifs et le mappage des ports avant d’autoriser l’exécution des migrations ou des tâches en arrière-plan.
Mettez à jour chaque chemin client qui dépend de l’ancien port
Un favori de navigateur n’est qu’un des éléments qui utilisent le port publié. Les reverse proxies, les redirections du routeur, les pare-feu locaux, les sondes de supervision, les applications mobiles, les destinations de webhooks, les rappels OAuth, les listes d’autorisation CORS et les URL publiques générées peuvent encore pointer vers l’ancien point de terminaison.
Certaines applications auto-hébergées effectuent des requêtes en boucle locale ou construisent les URL de rappel à partir de leur adresse publique configurée. Une discussion consacrée à un conteneur WordPress montre comment une modification du mappage externe peut révéler un comportement de boucle locale dépendant du port, même lorsque la base de données reste saine.
Recherchez l’ancien port dans le projet Compose, la configuration du proxy, les fichiers d’environnement et les paramètres de l’application. Mettez à jour uniquement les couches qui utilisent réellement le point de terminaison hôte. Les conteneurs internes devraient normalement continuer à utiliser le nom du service et le port interne, plutôt que le nouveau port hôte publié.
Conservez la base de données sur son chemin privé dans le conteneur
Ne modifiez pas et ne publiez pas le port de la base de données simplement parce que le port hôte de l’application web a changé. Une base de données utilisée uniquement par les conteneurs de la même pile peut rester accessible via son nom de service et son port interne, sans aucune publication côté hôte.
Confondre le point de terminaison public de l’application avec la connexion à la base de données peut provoquer une seconde panne : l’application peut être configurée avec l’adresse du NAS et un port hôte alors que la base de données est censée rester sur un réseau Docker privé. Cette modification ajoute des variables liées au pare-feu, au NAT et à l’authentification sans aider le navigateur à atteindre le service web.
Depuis le conteneur d’application recréé, résolvez le nom du service de base de données, ouvrez son port TCP interne, authentifiez-vous et exécutez une lecture sans effet de bord. Si ce chemin n’a pas changé, laissez-le tel quel. Si le test de la base de données échoue, restaurez la définition d’origine de l’application avant de résoudre séparément le problème de réseau ou d’identifiants.
Vérifiez le nouveau port sans toucher aux données persistantes
Testez directement le nouveau port hôte, puis testez le nom d’hôte habituel ou la route du reverse proxy. Vérifiez la connexion, la lecture des enregistrements, une écriture réversible, les téléversements, les tâches planifiées, les intégrations et un redémarrage contrôlé du conteneur.
Le guide de ZimaSpace consacré à l’adaptation des contrôles d’intégrité aux chemins réels de l’application constitue l’étape suivante lorsque le nouveau point de terminaison fonctionne dans le navigateur, mais que Docker signale encore le service comme défaillant.
La modification est terminée uniquement lorsque le nouveau port publié survit à la recréation et au redémarrage, que le proxy et les clients n’utilisent plus l’ancien point de terminaison, que l’application se reconnecte à la même base de données persistante et que la sauvegarde de la base de données reste disponible. Restaurez le mappage de port si l’application démarre sur un nouvel état vide ou tente une migration inattendue.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
