Kun je de gepubliceerde poort van een container wijzigen zonder de database opnieuw op te bouwen?
Ja, je kunt de gepubliceerde poort van een container wijzigen zonder de database opnieuw op te bouwen, zolang de database op dezelfde geverifieerde permanente opslag blijft staan.
Op een thuis-NAS of Docker-host hoort de zichtbare poort normaal gesproken bij de vervangbare applicatiecontainer, terwijl records, accounts en instellingen in een benoemd volume, een bind-mount of een afzonderlijke databaseservice staan. De veilige wijziging is daarom om de implementatiedefinitie en permanente paden te behouden, alleen de publicatieregel aan de hostzijde aan te passen, de betreffende applicatieservice opnieuw aan te maken en vervolgens elke proxy, bladwijzer, callback, firewallregel en gezondheidscontrole te controleren die nog naar de oude poort verwijst.
Scheid de gepubliceerde hostpoort van de containerlistener
Noteer de huidige koppeling als twee verschillende eindpunten voordat je de wijziging uitvoert. In 8080:80 maken clients verbinding met poort 8080 op de Docker-host, terwijl de applicatie binnen de container nog steeds naar poort 80 luistert. Als je de linkerkant wijzigt, veranderen het applicatieproces of de databaseverbinding niet automatisch.
Een troubleshooting-case uit de Docker-community benadrukt dat de hostkoppeling en de interne listener los van elkaar staan en dat een nieuwe gepubliceerde poort niet kan werken wanneer er intern niets luistert op de bestemmingspoort.
Controleer de gepubliceerde poorten en luisterende sockets van de actieve container en test vervolgens het interne eindpunt vanuit de container of het bijbehorende netwerk. Laat de interne poort ongewijzigd, tenzij de applicatie zelf moet verhuizen. Met deze eerste test voorkom je dat een eenvoudige wijziging van de hostpoort uitmondt in een onnodige herconfiguratie van de applicatie.
Bescherm het huidige databasepad voordat je de service opnieuw aanmaakt
Leg het Compose-bestand, de imagetag of -digest, omgevingsbestanden, benoemde volumes, bind-mounts, netwerknamen, secrets en databasenaam vast. Het doel is om vast te stellen welk object de permanente status beheert voordat Docker de applicatiecontainer vervangt.
Voor het wijzigen van de poortpublicatie is een nieuwe containerconfiguratie nodig, maar geen nieuwe imagebuild of database. Een praktisch Docker-antwoord maakt onderscheid tussen het opnieuw aanmaken van de container en het opnieuw opbouwen van de applicatie-image wanneer poortinstellingen veranderen.
Maak een actuele, consistente back-up of snapshot van de database als de service belangrijk is en controleer vervolgens of het databasepad niet in de schrijfbare laag van de container staat. Stop als de mountlijst onduidelijk is, de volumenaam is gewijzigd of de huidige applicatie een onverwachte lege database lijkt te gebruiken.
Wijzig alleen de koppeling aan de hostzijde en maak de applicatieservice opnieuw aan
Wijzig de applicatieservice bijvoorbeeld van 8080:80 naar 8081:80. Laat de image, interne poort, volumes, database-URL, servicenaam, netwerken en gebruikerskoppeling ongewijzigd, tenzij er een andere geverifieerde vereiste bestaat.
De syntaxis voor Compose-poorten wordt van host naar container geïnterpreteerd. Als je de hostzijde wijzigt, blijft het proces dus naar de bestaande interne poort luisteren. Een voorbeeld op het Docker-forum legt uit waarom de linkerkant de hostpoort is en de rechterkant nog steeds moet overeenkomen met de listener van de applicatie.
Maak alleen de applicatieservice opnieuw aan met de bijgewerkte definitie. Gebruik geen stackopdracht die volumes verwijdert, initialiseer de database niet opnieuw en voeg geen --build toe, tenzij de image zelf is gewijzigd. Controleer na het opnieuw aanmaken de effectieve mounts en poortkoppeling voordat je migraties of achtergrondtaken laat uitvoeren.
Werk elk clientpad bij dat afhankelijk is van de oude poort
Een bladwijzer in de browser is slechts één gebruiker van de gepubliceerde poort. Reverse proxies, routerdoorsturingen, lokale firewalls, monitoringprobes, mobiele apps, webhookdoelen, OAuth-callbacks, CORS-allowlists en gegenereerde openbare URL's kunnen nog steeds naar het vorige eindpunt verwijzen.
Sommige zelfgehoste applicaties maken loopbackverzoeken of stellen callback-URL's samen op basis van hun geconfigureerde openbare adres. Een discussie over een WordPress-container laat zien hoe een gewijzigde externe koppeling poortafhankelijk loopbackgedrag kan blootleggen, zelfs wanneer de database gezond blijft.
Zoek in het Compose-project, de proxyconfiguratie, omgevingsbestanden en applicatie-instellingen naar de oude poort. Werk alleen de lagen bij die het hosteindpunt daadwerkelijk gebruiken. Interne containers moeten normaal gesproken de servicenaam en interne poort blijven gebruiken in plaats van de nieuw gepubliceerde hostpoort.
Houd de database op het private containerpad
Wijzig of publiceer de databasepoort niet alleen omdat de hostpoort van de webapplicatie is gewijzigd. Een database die uitsluitend door containers in dezelfde stack wordt gebruikt, kan bereikbaar blijven via de servicenaam en interne poort zonder enige publicatie naar de host.
Als je het openbare eindpunt van de applicatie verwart met de databaseverbinding, kan dat een tweede storing veroorzaken: de applicatie wordt mogelijk ingesteld op het NAS-adres en een hostpoort, terwijl de database juist op een privénetwerk van Docker hoort te blijven. Die wijziging voegt firewall-, NAT- en authenticatievariabelen toe zonder dat de browser daardoor beter toegang krijgt tot de webservice.
Los vanuit de opnieuw aangemaakte applicatiecontainer de naam van de databaseservice op, open de interne TCP-poort, authenticeer en voer een onschadelijke leesbewerking uit. Als dat pad ongewijzigd is, laat het dan ongewijzigd. Als de databasetest mislukt, herstel dan eerst de oorspronkelijke applicatiedefinitie voordat je het afzonderlijke netwerk- of credentialprobleem onderzoekt.
Controleer de nieuwe poort zonder permanente gegevens aan te raken
Test de nieuwe hostpoort rechtstreeks en test daarna de normale hostnaam of reverse-proxyroute. Controleer het inloggen, het lezen van records, één terug te draaien schrijfbewerking, uploads, geplande taken, integraties en een gecontroleerde herstart van de container.
De ZimaSpace-handleiding voor het afstemmen van gezondheidscontroles op echte applicatiepaden is de volgende controle wanneer het nieuwe browserendpoint werkt, maar Docker de service nog steeds als ongezond rapporteert.
De wijziging is pas voltooid wanneer de nieuwe gepubliceerde poort een nieuwe aanmaak en een herstart overleeft, de proxy en clients het oude eindpunt niet meer gebruiken, de applicatie opnieuw verbinding maakt met dezelfde permanente database en de databaseback-up beschikbaar blijft. Zet de poortkoppeling terug als de applicatie met een nieuwe lege status start of een onverwachte migratie probeert uit te voeren.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Kan Plex een GPU delen met een andere Docker-container?
Plex en een andere container kunnen vaak dezelfde GPU gebruiken, maar je moet de driverondersteuning, apparaattoewijzing, belasting van de video-engine, het geheugengebruik en het...
Hoe je kunt bepalen of een Plex-fout door de client of de server wordt veroorzaakt
Reproduceer hetzelfde item op een andere client, vergelijk het sessiepad en verzamel pas serverbewijs nadat de scope heeft uitgewezen waar de fout daadwerkelijk zit.
Plex-cache en tijdelijke opslag voor transcodering configureren
Bescherm de permanente Plex-status door tijdelijke transcodebestanden op geschikte lokale opslag te plaatsen en controleer vervolgens het opruimen, de beschikbare ruimte en het gedrag...
