Warum wird ein Compose-Netzwerkalias nach der Neuerstellung des Stacks unter einem neuen Projektnamen nicht mehr aufgelöst?
Ein Compose-Alias kann nach einer Neuerstellung nicht mehr aufgelöst werden, wenn der Dienst einem anderen projektspezifischen Netzwerk beitritt oder der Alias dort nicht mehr zugewiesen ist.
Docker-Aliase sind netzwerkbezogene Namen und keine globalen Namen. Wenn ein Stack in einem neuen Verzeichnis, unter einem expliziten Projektnamen, einem Portainer-Stack-Namen oder in einem anderen Compose-Projekt neu erstellt wird, kann ein neues Standardnetzwerk entstehen, während eine andere Anwendung im alten Netzwerk verbleibt. Der Dienst kann gesund und über den veröffentlichten Port erreichbar sein, während sein interner Alias fehlschlägt, weil der aufrufende und der Zielcontainer nicht mehr dasselbe Netzwerk gemeinsam nutzen oder weil ein Reverse-Proxy eine andere Netzwerkschnittstelle ausgewählt hat.
Alte und neue Compose-Projektnamen vergleichen
Notieren Sie den vorherigen und den aktuellen Projektnamen, das Arbeitsverzeichnis, den Stack-Namen, die Netzwerknamen und die Container-Labels. Vergleichen Sie den aufrufenden und den Ziel-Dienst nach der Neuerstellung.
Docker Compose verwendet den Projektnamen, um Ressourcen zu gruppieren und zu benennen. Die Priorität des Projektnamens erklärt, warum eine Änderung des Verzeichnisses oder Bereitstellungsnamens ein neues Netzwerk erzeugen kann, anstatt das bisherige Projektnetzwerk wiederzuverwenden.
Wenn der aufrufende Container weiterhin mit oldproject_default verbunden ist, während der Zielcontainer newproject_default beitritt, besitzt der frühere Alias keinen gemeinsamen DNS-Geltungsbereich.
Alias im exakt gemeinsam genutzten Netzwerk überprüfen
Untersuchen Sie beide Container und listen Sie jedes verbundene Netzwerk, jeden Endpunkt, jede IPv4- oder IPv6-Adresse sowie jeden Alias auf. Testen Sie die DNS-Auflösung innerhalb des aufrufenden Containers.
Die Compose-Spezifikation definiert Aliase als netzwerkbezogene Namen. Ein unter einem Netzwerk deklarierter Alias existiert daher nicht automatisch an einer anderen Netzwerkschnittstelle.
Verschieben Sie die Alias-Deklaration in das Netzwerk, das von den Diensten tatsächlich gemeinsam genutzt wird. Verlassen Sie sich nicht auf container_name als Ersatz für eine bewusst konfigurierte Diensterkennung.
Externe Netzwerknamen und Bereitstellungsvariablen prüfen
Vergleichen Sie den logischen Compose-Netzwerkschlüssel mit dessen explizitem externem name. Prüfen Sie die Variablenersetzung und die beim Bereitstellen verwendeten Variablen der Stack-Oberfläche.
Portainer dokumentiert, dass Stacks vorhandene Docker-Netzwerke verwenden können. Diese müssen konsistent ausgewählt werden, wenn unabhängig bereitgestellte Stacks einander auflösen sollen.
Ein externes Netzwerk verhindert Änderungen durch Projektpräfixe nur dann, wenn jeder Stack auf denselben tatsächlichen Netzwerknamen verweist. Ein Tippfehler kann ein anderes Netzwerk erstellen oder auswählen, ohne den veröffentlichten Port des Dienstes zu verändern.
Sicherstellen, dass der Aufrufer Docker-DNS statt einer zwischengespeicherten Adresse verwendet
Führen Sie vom aufrufenden Container aus eine neue DNS-Abfrage durch, prüfen Sie dessen Resolver-Konfiguration und starten Sie bei Bedarf nur den Prozess neu, der DNS-Einträge zwischenspeichert. Vergleichen Sie die Namensauflösung mit einer direkten Suche nach dem Dienstnamen.
Das Linux-Modell der Netzwerk-Namespaces isoliert Netzwerkressourcen. Deshalb beweist eine erfolgreiche DNS-Auflösung auf dem Host nicht, dass der aufrufende Container dasselbe Docker-Netzwerk wie der Zielcontainer nutzt.
Tragen Sie die aktuelle Container-IP des Zielcontainers nicht in /etc/hosts ein. Neu erstellte Container können eine andere Adresse erhalten und dadurch eine weitere veraltete Abhängigkeit hinterlassen.
Prüfen, welches Netzwerk der Reverse-Proxy verwendet
Untersuchen Sie die Netzwerkanbindungen des Proxys und der Anwendung, die Provider-Labels und das für das Backend-Routing ausgewählte Netzwerk. Testen Sie den Alias aus dem Proxy-Container.
Der Docker-Provider von Traefik unterstützt die Angabe des für Backend-Verbindungen verwendeten Docker-Netzwerks.
Wenn der Proxy mit mehreren Netzwerken verbunden ist, kann die automatische Auswahl nach einer Neuerstellung anders ausfallen. Legen Sie das vorgesehene gemeinsame Netzwerk ausdrücklich fest und behalten Sie dessen tatsächlichen Namen stabil.
Veraltete Endpunkte entfernen, ohne das falsche Netzwerk zu löschen
Listen Sie die verbundenen Container in den alten und neuen Netzwerken auf. Identifizieren Sie verwaiste Endpunkte, gestoppte Container und aktive Dienste, die weiterhin vom alten Projektnetzwerk abhängen.
Der Container-Networking-Leitfaden von Red Hat beschreibt die Verbindung mit benutzerdefinierten Containernetzwerken als Bestandteil des Zustands der Container-Laufzeit und nicht des Inhalts der Anwendungsdateien.
Entfernen Sie ein altes Netzwerk erst, nachdem Sie nachgewiesen haben, dass kein aktiver Stack es verwendet. Wenn Sie beide Netzwerke löschen und alles gleichzeitig neu erstellen, geht der Beleg dafür verloren, welche Verbindung fehlerhaft war.
Einen Dienst neu erstellen und DNS von jedem Aufrufer aus prüfen
Vereinheitlichen Sie den Projektnamen oder das externe Netzwerk, erstellen Sie nur den betroffenen Dienst neu und testen Sie den Dienstnamen sowie den Alias von jedem abhängigen Container aus.
Der ZimaSpace-Artikel zu Laufzeitabhängigkeiten von Containern liefert die ergänzende Regel: Ein Verbindungstest auf Host-Ebene validiert nicht den Namespace und den Pfad zur Diensterkennung eines Containers.
Das Problem ist behoben, wenn der Alias nach der Neuerstellung und einem Neustart des Stacks von jedem vorgesehenen Aufrufer aus auf den aktuellen Endpunkt aufgelöst wird, ohne fest codierte IP-Adressen.
Häufig gestellte Fragen
Sind Docker-Netzwerkaliase global?
Nein. Ein Alias existiert nur in dem Netzwerk, in dem er konfiguriert ist, und ist nur für Container nützlich, die dieses Netzwerk gemeinsam nutzen.
Kann eine Änderung des Compose-Verzeichnisnamens DNS beeinträchtigen?
Ja. Das Verzeichnis kann den standardmäßigen Projektnamen beeinflussen, der wiederum die generierten Netzwerknamen bestimmt, sofern der Projektname oder der Name des externen Netzwerks nicht festgelegt ist.
Sollte ich container_name verwenden, um DNS stabil zu halten?
In der Regel nein. Stabile Dienstnamen und ausdrücklich konfigurierte gemeinsame Netzwerke ermöglichen die Skalierung mit Compose und vermeiden Konflikte globaler Namen.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Leitfaden zur Speicherkapazität, Aufbewahrung und Bereinigung von Live-TV-Aufnahmen
Messen Sie echte Aufzeichnungen, halten Sie Headroom frei, kombinieren Sie Alters- und Kapazitätslimits und weisen Sie nach, dass das älteste geeignete Programm entfernt wird,...
Workflow zur Wiederherstellung von Metadaten für Heimmedien nach der Wiederherstellung einer Datenbank
Schützen Sie den wiederhergestellten Zustand, überprüfen Sie die Medienidentität und die Pfade und reparieren Sie anschließend fehlende Grafiken oder Übereinstimmungen in einer Pilotbibliothek, bevor...
Jellyfin-Client-Kompatibilitätscheckliste für Audio, Video und Untertitel
Testen Sie repräsentative Dateien mit jeweils nur einer veränderten Variable und protokollieren Sie für jeden Client Direct Play, Remux, Audiokonvertierung, Videotranskodierung oder einen Fehler.
