Varför slutar ett Compose-nätverksalias att fungera efter att stacken har återskapats under ett nytt projektnamn?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does a Compose Network Alias Stop Resolving After the Stack Is Recreated Under a New Project Name?

Ett Compose-alias kan sluta lösas efter återskapande när tjänsten ansluter till ett annat projektspecifikt nätverk eller när aliaset inte längre är kopplat dit.

Docker-alias är nätverksspecifika, inte globala namn. Om en stack återskapas i en ny katalog, med ett uttryckligt projektnamn, ett Portainer-stacknamn eller ett annat Compose-projekt kan ett nytt standardnätverk skapas medan en annan app fortfarande finns på det gamla. Tjänsten kan vara frisk och nåbar via en publicerad port, men dess interna alias fungerar ändå inte eftersom anroparen och målet inte längre delar samma nätverk eller eftersom en reverse proxy valde en annan nätverksanslutning.

Jämför de gamla och nya Compose-projektnamnen

Anteckna föregående och aktuellt projektnamn, arbetskatalog, stacknamn, nätverksnamn och containeretiketter. Jämför anropar- och måltjänsten efter återskapandet.

Docker Compose använder projektnamnet för att gruppera och namnge resurser. Dess prioritering av projektnamn förklarar varför en ändring av katalogen eller distributionsnamnet kan skapa ett nytt nätverk i stället för att återanvända det gamla projektnätverket.

Om anroparen fortfarande är ansluten till oldproject_default medan målet ansluter till newproject_default, har det tidigare aliaset inget gemensamt DNS-omfång.

Verifiera aliaset på det exakta gemensamma nätverket

Inspektera båda containrarna och lista alla anslutna nätverk, slutpunkter, IPv4- eller IPv6-adresser och alias. Testa DNS inifrån anroparcontainern.

Compose-specifikationen definierar alias som nätverksspecifika namn, så ett alias som deklareras under ett nätverk finns inte automatiskt på en annan anslutning.

Flytta aliasdeklarationen till det nätverk som tjänsterna faktiskt delar. Förlita dig inte på container_name som ersättning för en genomtänkt tjänsteidentifiering.

Kontrollera externa nätverksnamn och substitutionsvärden vid distribution

Jämför den logiska Compose-nätverksnyckeln med dess uttryckliga externa name. Kontrollera miljösubstitution och stackgränssnittsvariabler som används vid distributionen.

Portainer beskriver att stackar kan använda befintliga Docker-nätverk, som måste väljas konsekvent när separat distribuerade stackar behöver hitta varandra.

Ett externt nätverk förhindrar ändringar av projektprefixet endast när varje stack hänvisar till samma faktiska nätverksnamn. Ett stavfel kan skapa eller välja ett annat nätverk utan att tjänstens publicerade port ändras.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Bekräfta att anroparen använder Docker DNS i stället för en cachad adress

Gör en ny uppslagning från anroparen, inspektera dess resolverkonfiguration och starta vid behov om endast den process som cachar DNS. Jämför namnupplösningen med en direkt uppslagning av tjänstenamnet.

Linux modell för nätverksnamnrymder isolerar nätverksresurser, vilket är anledningen till att fungerande DNS på värddatorn inte bevisar att anroparcontainern delar Dockers nätverk med målet.

Lägg inte till målets aktuella container-IP i /etc/hosts. Återskapade containrar kan få en annan adress, vilket lämnar kvar ännu ett föråldrat beroende.

Kontrollera vilket nätverk reverse proxyn använder

Inspektera proxyns och applikationens nätverksanslutningar, leverantörsetiketter och nätverket som valts för backend-routning. Testa aliaset från proxycontainern.

Traefiks Docker-provider stöder att man anger Docker-nätverket som används för backendanslutningar.

Om proxyn är ansluten till flera nätverk kan det automatiska valet ändras efter återskapandet. Ange det avsedda gemensamma nätverket uttryckligen och håll dess faktiska namn stabilt.

Ta bort inaktuella slutpunkter utan att radera fel nätverk

Lista anslutna containrar på de gamla och nya nätverken. Identifiera överblivna slutpunkter, stoppade containrar och aktiva tjänster som fortfarande är beroende av det gamla projektnätverket.

RHEL:s guide om containernätverk beskriver användardefinierad nätverksanslutning för containrar som en del av körtidsmiljön för containrar, inte av applikationens filinnehåll.

Ta bort ett gammalt nätverk först efter att du har bevisat att ingen aktiv stack använder det. Om du raderar båda nätverken och återskapar allt på en gång förstörs bevisen som visar vilken anslutning som var fel.

Återskapa en tjänst och verifiera DNS från varje anropare

Standardisera projektnamnet eller det externa nätverket, återskapa endast den berörda tjänsten och testa tjänstenamnet och aliaset från varje beroende container.

ZimaSpace-artikeln om beroenden i containerns körmiljö beskriver den närliggande regeln: ett anslutningstest på värddatornivå validerar inte containerns namnrymd och väg för tjänsteidentifiering.

Problemet är löst när aliaset pekar på den aktuella slutpunkten från varje avsedd anropare efter att stacken har återskapats och systemet har startats om, utan hårdkodade IP-adresser.

Vanliga frågor

Är Docker-nätverksalias globala?

Nej. Ett alias finns endast på det nätverk där det har konfigurerats och är användbart endast för containrar som delar det nätverket.

Kan ett byte av Compose-mappens namn bryta DNS?

Ja. Mappnamnet kan påverka standardprojektnamnet, vilket i sin tur påverkar genererade nätverksnamn om projekt- eller externa nätverksnamn inte är fastställda.