Kan du ändra en containers publicerade port utan att bygga om dess databas?
Ja, du kan ändra en containers publicerade port utan att bygga om databasen när databasen finns kvar på samma verifierade permanenta lagring.
På en hem-NAS eller Docker-värd tillhör den synliga porten normalt den utbytbara applikationscontainern, medan poster, konton och inställningar lagras i en namngiven volym, en bind-montering eller en separat databastjänst. Den säkra ändringen är därför att bevara distributionsdefinitionen och de permanenta sökvägarna, endast ändra publiceringsregeln på värdsidan, återskapa den berörda applikationstjänsten och sedan kontrollera alla proxyer, bokmärken, callback-URL:er, brandväggsregler och hälsokontroller som fortfarande hänvisar till den gamla porten.
Skilj den publicerade värdporten från containerns lyssningsport
Skriv ned den aktuella mappningen som två separata slutpunkter innan du ändrar den. I 8080:80 ansluter klienter till port 8080 på Docker-värden, medan applikationen fortfarande lyssnar på port 80 inuti containern. Om du ändrar den vänstra sidan ändras varken applikationsprocessen eller dess databasanslutning automatiskt.
Ett felsökningsfall i Docker-communityt betonar att värdmappningen och den interna lyssningsporten är separata, och att en ny publicerad port inte kan fungera när inget lyssnar internt på målporten.
Kontrollera den körande containerns publicerade portar och lyssnande sockets, och testa sedan den interna slutpunkten från containern eller dess nätverk. Låt den interna porten vara oförändrad om inte själva applikationen måste flyttas. Det här första testet förhindrar att en enkel ändring av värdporten leder till en onödig omkonfiguration av applikationen.
Skydda den aktuella databassökvägen innan du återskapar tjänsten
Dokumentera Compose-filen, bildtaggen eller digesten, miljöfilerna, namngivna volymer, bind-monteringarna, nätverksnamnen, hemligheterna och databasvärdnamnet. Målet är att bevisa vilket objekt som äger den permanenta datan innan Docker ersätter applikationscontainern.
Att ändra portpubliceringen kräver en ny containerkonfiguration, men inte en ny bild eller en ny databas. Ett praktiskt Docker-svar skiljer mellan återskapande av containern och att bygga om applikationsbilden när portinställningarna ändras.
Ta en aktuell, applikationskonsistent säkerhetskopia eller ögonblicksbild av databasen när tjänsten är viktig, och kontrollera sedan att databassökvägen inte finns i containerns skrivbara lager. Avbryt om monteringslistan är oklar, volymnamnet har ändrats eller den aktuella appen verkar använda en oväntad tom databas.
Ändra endast mappningen på värdsidan och återskapa applikationstjänsten
Redigera applikationstjänsten från en mappning som 8080:80 till 8081:80. Låt bilden, den interna porten, volymerna, databas-URL:en, tjänstenamnet, nätverken och användarmappningen vara oförändrade om det inte finns ett annat verifierat krav.
Compose-portsyntax tolkas från värd till container, så när du ändrar värdsidan fortsätter processen att lyssna på sin befintliga interna port. Ett exempel från Docker-forumet förklarar varför den vänstra sidan är värdporten och den högra sidan fortfarande måste motsvara applikationens lyssningsport.
Återskapa endast applikationstjänsten med den uppdaterade definitionen. Använd inte ett stackkommando som tar bort volymer, initiera inte databasen igen och lägg inte till --build om inte själva bilden har ändrats. Efter återskapandet kontrollerar du de faktiska monteringspunkterna och portmappningen innan du låter migreringar eller bakgrundsjobb köras.
Uppdatera alla klientvägar som är beroende av den gamla porten
Ett webbläsarbokmärke är bara en av användarna av den publicerade porten. Omvända proxyer, vidarebefordringar i routern, lokala brandväggar, övervakningsprober, mobilappar, webhook-destinationer, OAuth-callbacks, CORS-tillåtelselistor och genererade offentliga URL:er kan fortfarande peka på den tidigare slutpunkten.
Vissa egenhostade applikationer gör loopback-anrop eller skapar callback-URL:er utifrån sin konfigurerade offentliga adress. En diskussion om en WordPress-container visar hur en ändrad extern mappning kan påverka portmedvetet loopback-beteende även när databasen fortfarande är frisk.
Sök efter den gamla porten i Compose-projektet, proxykonfigurationen, miljöfilerna och applikationsinställningarna. Uppdatera endast de lager som faktiskt använder värdslutpunkten. Interna containrar bör normalt fortsätta använda tjänstenamnet och den interna porten i stället för den nya publicerade värdporten.
Låt databasen vara kvar på sin privata containersökväg
Ändra eller publicera inte databasporten bara för att webbapplikationens värdport har ändrats. En databas som endast används av containrar i samma stack kan fortsätta nås via sitt tjänstenamn och sin interna port utan någon publicering på värden.
Om du blandar ihop appens offentliga slutpunkt med databasanslutningen kan det skapa ett andra avbrott: applikationen kan riktas mot NAS-adressen och en värdport trots att databasen är avsedd att ligga kvar på ett privat Docker-nätverk. Den ändringen tillför brandväggs-, NAT- och autentiseringsvariabler utan att hjälpa webbläsaren att nå webbtjänsten.
Från den återskapade applikationscontainern slår du upp databastjänstens namn, öppnar dess interna TCP-port, autentiserar och kör en ofarlig läsning. Om den sökvägen är oförändrad ska du låta den förbli oförändrad. Om databastestet misslyckas återställer du den ursprungliga applikationsdefinitionen innan du felsöker det separata nätverks- eller behörighetsproblemet.
Verifiera den nya porten utan att röra permanent data
Testa den nya värdporten direkt och testa sedan det vanliga värdnamnet eller den omvända proxyvägen. Bekräfta inloggning, läsning av poster, en ångringsbar skrivning, uppladdningar, schemalagda jobb, integrationer och en kontrollerad omstart av containern.
ZimaSpace-guiden om att matcha hälsokontroller med verkliga appvägar är nästa kontroll när den nya webbläsarens slutpunkt fungerar men Docker fortfarande rapporterar tjänsten som ohälsosam.
Ändringen är klar först när den nya publicerade porten överlever återskapande och omstart, proxyn och klienterna inte längre använder den gamla slutpunkten, applikationen återansluter till samma permanenta databas och databassäkerhetskopian fortfarande är tillgänglig. Rulla tillbaka portmappningen om appen startar med ett nytt tomt tillstånd eller försöker utföra en oväntad migrering.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
