Waarom wordt een Compose-netwerkalias niet meer opgelost nadat de stack onder een nieuwe projectnaam opnieuw is aangemaakt?

Een Compose-alias kan na het opnieuw aanmaken niet meer worden opgelost wanneer de service verbinding maakt met een netwerk met een andere projectscope, of wanneer de alias daar niet langer aan gekoppeld is.

Docker-aliases zijn gebonden aan een netwerk en geen globale namen. Wanneer je een stack vanuit een nieuwe map opnieuw aanmaakt, een expliciete projectnaam gebruikt, de naam van een Portainer-stack wijzigt of een ander Compose-project gebruikt, kan er een nieuw standaardnetwerk ontstaan terwijl een andere app nog op het oude netwerk zit. De service kan gezond zijn en via de gepubliceerde poort bereikbaar blijven, terwijl de interne alias niet werkt omdat de aanroeper en het doel geen netwerk meer delen of omdat een reverse proxy een andere netwerkverbinding heeft geselecteerd.

Vergelijk de oude en nieuwe Compose-projectnamen

Noteer de vorige en huidige projectnaam, werkmap, stacknaam, netwerknamen en containerlabels. Vergelijk de aanroepende en doelservice na het opnieuw aanmaken.

Docker Compose gebruikt de projectnaam om resources te groeperen en een naam te geven. De prioriteitsregels voor projectnamen leggen uit waarom het wijzigen van de map of implementatienaam een nieuw netwerk kan maken in plaats van het oude projectnetwerk opnieuw te gebruiken.

Als de aanroeper verbonden blijft met oldproject_default terwijl het doel verbinding maakt met newproject_default, heeft de voormalige alias geen gedeelde DNS-scope.

Controleer de alias op het exacte gedeelde netwerk

Inspecteer beide containers en vermeld elk verbonden netwerk, endpoint, IPv4- of IPv6-adres en alias. Test DNS vanuit de aanroepende container.

De Compose-specificatie definieert aliases als netwerkgebonden namen. Een alias die onder één netwerk is gedeclareerd, bestaat daarom niet automatisch op een andere verbinding.

Verplaats de aliasdeclaratie naar het netwerk dat de services daadwerkelijk delen. Gebruik container_name niet als vervanging voor weloverwogen servicedetectie.

Controleer externe netwerknamen en implementatiesubstitutie

Vergelijk de logische Compose-netwerksleutel met de expliciete externe name. Controleer omgevingssubstitutie en stackinterfacevariabelen die tijdens de implementatie worden gebruikt.

Portainer documenteert dat stacks gebruik kunnen maken van bestaande Docker-netwerken. Deze moeten consistent worden geselecteerd wanneer onafhankelijk geïmplementeerde stacks elkaar moeten kunnen vinden.

Een extern netwerk voorkomt wijzigingen in projectprefixen alleen wanneer elke stack naar dezelfde daadwerkelijke netwerknaam verwijst. Een typefout kan een ander netwerk aanmaken of selecteren zonder de gepubliceerde poort van de service te wijzigen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Bevestig dat de aanroeper Docker-DNS gebruikt in plaats van een gecachet adres

Voer een nieuwe lookup uit vanuit de aanroeper, inspecteer de resolverconfiguratie en start indien nodig alleen het proces opnieuw dat DNS-caching gebruikt. Vergelijk naamresolutie met een directe lookup van de servicenaam.

Het Linux-model van netwerknaamruimten isoleert netwerkresources. Daarom bewijst succesvolle DNS op de host niet dat de aanroepende container hetzelfde Docker-netwerk deelt als het doel.

Voeg het huidige container-IP-adres van het doel niet toe aan /etc/hosts. Opnieuw aangemaakte containers kunnen een ander adres krijgen, waardoor er nog een verouderde afhankelijkheid achterblijft.

Controleer welk netwerk de reverse proxy gebruikt

Inspecteer de netwerkverbindingen van de proxy en applicatie, providertags en het netwerk dat voor backendroutering is geselecteerd. Test de alias vanuit de proxycontainer.

De Docker-provider van Traefik ondersteunt het specificeren van het Docker-netwerk dat voor backendverbindingen wordt gebruikt.

Als de proxy met meerdere netwerken is verbonden, kan de automatische selectie na het opnieuw aanmaken anders uitvallen. Stel het bedoelde gedeelde netwerk expliciet in en houd de daadwerkelijke naam stabiel.

Verwijder verouderde endpoints zonder het verkeerde netwerk te verwijderen

Bekijk welke containers met de oude en nieuwe netwerken zijn verbonden. Identificeer verweesde endpoints, gestopte containers en actieve services die nog afhankelijk zijn van het oude projectnetwerk.

De containernetwerkgids van Red Hat beschrijft netwerkverbindingen met door gebruikers gedefinieerde containernetwerken als onderdeel van de runtime-status van de container, en niet van de inhoud van applicatiebestanden.

Verwijder een oud netwerk pas nadat je hebt vastgesteld dat geen enkele actieve stack het gebruikt. Door beide netwerken te verwijderen en alles tegelijk opnieuw aan te maken, vernietig je het bewijs dat laat zien welke verbinding verkeerd was.

Maak één service opnieuw aan en controleer DNS vanuit elke aanroeper

Standaardiseer de projectnaam of het externe netwerk, maak alleen de betrokken service opnieuw aan en test de servicenaam en alias vanuit elke afhankelijke container.

Het ZimaSpace-artikel over runtimeafhankelijkheden van containers geeft de aanvullende regel: een connectiviteitstest op hostniveau valideert niet de naamruimte en het pad voor servicedetectie van een container.

Het probleem is opgelost wanneer de alias na het opnieuw aanmaken van de stack en na een herstart vanuit elke bedoelde aanroeper naar het huidige endpoint verwijst, zonder hardgecodeerde IP-adressen.

Veelgestelde vragen

Zijn Docker-netwerkaliassen globaal?

Nee. Een alias bestaat alleen op het netwerk waarop deze is geconfigureerd en is alleen bruikbaar voor containers die dat netwerk delen.

Kan het wijzigen van de naam van de Compose-map DNS verbreken?

Ja. De map kan van invloed zijn op de standaardprojectnaam, die op zijn beurt de gegenereerde netwerknamen beïnvloedt, tenzij de projectnaam of externe netwerknaam is vastgelegd.

Moet ik container_name gebruiken om DNS stabiel te houden?

Meestal niet. Stabiele servicenamen en expliciete gedeelde netwerken behouden de schaalmogelijkheden van Compose en voorkomen conflicten met globale namen.