Kun je de naam van een Docker-service wijzigen zonder de netwerkidentiteit ervan te verbreken?

Ja, maar behoud de oude DNS-naam als tijdelijke netwerkalias en werk elke client bij voordat je deze verwijdert.

Dit wordt een echte compatibiliteitskwestie wanneer een Compose-service wordt hernoemd terwijl sibling-containers, healthchecks, reverse proxies en opgeslagen verbindingsreeksen nog steeds de oude servicenaam gebruiken. Begin met een wegwerptraject of -account, houd de vorige werkende toestand beschikbaar en beoordeel het ontwerp aan de hand van de oorspronkelijke workload in plaats van een eenmalige verbindingstest.

Bepaal wanneer migratie van Docker-servicenamen kan werken

De ondersteunde variant is een gefaseerde hernoeming met zowel oude als nieuwe aliassen. De concurrerende variant is een onmiddellijke hernoeming waarbij de enige vindbare naam wordt verwijderd. Leg versies, identiteiten, adressen, mountpaden, machtigingen en de huidige waarneembare toestand vast voordat je een van beide varianten wijzigt.

De relevante Compose-servicedetectie bepaalt de eerste compatibiliteitsgrens. Gebruik deze om de claim af te bakenen en verifieer vervolgens hetzelfde gedrag op deze exacte homeserver, in plaats van een gedocumenteerde functie te beschouwen als bewijs dat het volledige ontwerp werkt.

Leg de beslisregel vast voordat je test: succes moet opleveren dat beide aliassen naar de opnieuw aangemaakte container verwijzen en dat alle clients opnieuw verbinding maken via de naam, niet via een oud IP-adres; tot mislukking behoren onder andere dat de oude naam NXDOMAIN retourneert, een client het voormalige IP-adres vastlegt of healthchecks nog steeds de verwijderde naam aanroepen. Zo voorkom je dat een gedeeltelijke verbinding of een schone beëindiging van een opdracht ten onrechte als end-to-endcompatibiliteit wordt geïnterpreteerd.

Voer de kleinste test uit die de ontwerpen van elkaar onderscheidt

Gebruik één gecontroleerde onderscheidende test: verbind een wegwerpclient met hetzelfde netwerk, resolveer beide namen, maak de service opnieuw aan en herhaal de verbindings- en healthchecktests. Houd de client, workload, bestandsset, het account en de timing constant, zodat het gewijzigde onderdeel de enige plausibele verklaring is.

Gebruik Compose-servicedefinities om de tweede observatie te kiezen die voor dit traject van belang is. Leg beide kanten van de transactie vast: resolver of route, onderhandeld protocol, procesidentiteit, afsluitstatus, latentie, overgedragen bytes en elk herstelmoment.

Herhaal de test na de in de titel genoemde levenscyclusgebeurtenis: opnieuw aanmaken, opnieuw verbinden, opnieuw mounten, herstarten, failover of een clientwijziging. Een ontwerp dat alleen werkt zolang oude sockets, caches of referenties nog actief zijn, is niet geslaagd.

docker compose config
docker network inspect app_default
getent hosts old-name new-name

Interpreteer de signalen voor geslaagd, mislukt en uitzonderlijk

GESLAAGD: beide aliassen verwijzen naar de opnieuw aangemaakte container en alle clients maken opnieuw verbinding via de naam, niet via een oud IP-adres. Sla de exacte versies en topologie op die deze toestand hebben opgeleverd, want de conclusie geldt voor die omstandigheden en niet voor elke implementatie van het protocol.

MISLUKT: de oude naam retourneert NXDOMAIN, een client legt het voormalige IP-adres vast of healthchecks roepen nog steeds de verwijderde naam aan. Controleer gedeelde afhankelijkheden zoals DNS, MTU, identiteit, firewallstatus, opslaglatentie en gecachte sessies voordat je een van beide primaire varianten verantwoordelijk houdt.

UITZONDERING: herstel de oude servicesleutel of alias, inventariseer de resterende gebruikers en probeer het opnieuw nadat hun configuratie is gemigreerd. Breid machtigingen niet uit, verwijder geen brongegevens, verzwak de transportbeveiliging niet en vervang werkende opslag niet voordat een herhaalbare observatie heeft vastgesteld welke grens is overschreden.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valideer de beslissing onder de echte workload

Pas alleen de actie toe die bij de waargenomen variant hoort en voer vervolgens de oorspronkelijke workload opnieuw uit. Behoud het ontwerp alleen wanneer beide aliassen naar de opnieuw aangemaakte container verwijzen en alle clients opnieuw verbinding maken via de naam, niet via een oud IP-adres, gedurende twee relevante levenscycli en onder de verwachte gelijktijdige belasting.

Gebruik de specifieke proxynetwerken om de meest nabije afhankelijke workflow te verifiëren. De toegangs-, timing- en herstelwerking ervan moet ongewijzigd blijven terwijl het nieuwe ontwerp actief is.

Stop en keer terug naar de opgeslagen toestand als de oude naam NXDOMAIN retourneert, een client het voormalige IP-adres vastlegt of healthchecks nog steeds de verwijderde naam aanroepen. Escaleer met tijdstempels, exacte versies, bewijs van routes of mounts en de kleinst mogelijke reproductie, in plaats van nog een workaround toe te voegen.

Controleer het resultaat met de lokale DNS-overschrijvingen, zodat het risico niet alleen naar een andere netwerk-, identiteits-, back-up- of opslaglaag wordt verplaatst.

Voor migratie van Docker-servicenamen is het gekwalificeerde antwoord dus het oordeel aan het begin, niet een onvoorwaardelijk ja. De waarneembare geslaagde toestand is de acceptatiegrens; de mislukte toestand is de terugrolgrens.

Veelgestelde vragen

Behoudt container_name de oude DNS-naam van de service?

Niet betrouwbaar op zichzelf. Test de netwerkaliassen die gekoppelde clients daadwerkelijk resolven.

Blijven geopende databaseverbindingen bestaan na de hernoeming?

Bestaande sockets kunnen nog korte tijd blijven werken, maar bij opnieuw verbinden moet een geldige naam worden geresolved; test dit nadat de service opnieuw is aangemaakt.

Wanneer kan de oude alias worden verwijderd?

Pas nadat logs en configuratiezoekopdrachten aantonen dat geen enkele client deze nog opvraagt gedurende ten minste één normale herstartcyclus.