Dlaczego alias sieci Compose przestaje działać po odtworzeniu stosu pod nową nazwą projektu?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Alias Compose może przestać działać po ponownym utworzeniu, gdy usługa dołączy do innej sieci przypisanej do projektu albo alias nie będzie już do niej przypisany.

Aliasy Dockera są przypisane do sieci, a nie globalne. Ponowne wdrożenie stosu z innego katalogu, z użyciem jawnej nazwy projektu, nazwy stosu w Portainerze lub innego projektu Compose może utworzyć nową sieć domyślną, podczas gdy inna aplikacja pozostanie w starej. Usługa może działać poprawnie i być dostępna przez opublikowany port, a mimo to jej wewnętrzny alias nie działać, ponieważ wywołujący i docelowy kontener nie współdzielą już tej samej sieci albo odwrotny serwer proxy wybrał inne przypisanie do sieci.

Porównaj stare i nowe nazwy projektów Compose

Zapisz poprzednią i bieżącą nazwę projektu, katalog roboczy, nazwę stosu, nazwy sieci oraz etykiety kontenerów. Porównaj usługę wywołującą i docelową po ponownym utworzeniu.

Docker Compose używa nazwy projektu do grupowania zasobów i nadawania im nazw. Dokumentacja dotycząca priorytetów nazwy projektu wyjaśnia, dlaczego zmiana katalogu lub nazwy wdrożenia może utworzyć nową sieć zamiast ponownie użyć starej sieci projektu.

Jeśli wywołujący pozostaje podłączony do oldproject_default, a usługa docelowa dołącza do newproject_default, wcześniejszy alias nie ma wspólnego zakresu DNS.

Zweryfikuj alias w dokładnie tej samej współdzielonej sieci

Sprawdź oba kontenery i wyświetl wszystkie podłączone sieci, punkty końcowe, adresy IPv4 lub IPv6 oraz aliasy. Przetestuj DNS z wnętrza kontenera wywołującego.

Specyfikacja Compose definiuje aliasy jako nazwy przypisane do sieci, więc alias zadeklarowany w jednej sieci nie istnieje automatycznie w ramach innego przypisania.

Przenieś deklarację aliasu do sieci faktycznie współdzielonej przez usługi. Nie polegaj na container_name jako zamienniku przemyślanego wykrywania usług.

Sprawdź nazwy sieci zewnętrznych i podstawianie wartości podczas wdrażania

Porównaj logiczny klucz sieci Compose z jej jawną zewnętrzną wartością name. Sprawdź podstawianie zmiennych środowiskowych oraz zmienne stosu używane podczas wdrażania.

Dokumentacja Portainera opisuje, że stosy mogą korzystać z istniejących sieci Docker, które należy wybierać spójnie, gdy niezależnie wdrażane stosy muszą wzajemnie się rozpoznawać.

Sieć zewnętrzna zapobiega zmianom prefiksu projektu tylko wtedy, gdy każdy stos wskazuje tę samą rzeczywistą nazwę sieci. Literówka może utworzyć inną sieć lub wybrać niewłaściwą, nie zmieniając opublikowanego portu usługi.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Upewnij się, że wywołujący korzysta z DNS Dockera, a nie z buforowanego adresu

Wykonaj świeże wyszukiwanie z kontenera wywołującego, sprawdź jego konfigurację rozpoznawania nazw i w razie potrzeby zrestartuj tylko proces buforujący DNS. Porównaj rozwiązywanie nazwy z bezpośrednim wyszukiwaniem nazwy usługi.

Model przestrzeni nazw sieciowych w systemie Linux izoluje zasoby sieciowe, dlatego poprawne działanie DNS na hoście nie dowodzi, że kontener wywołujący współdzieli sieć Dockera z kontenerem docelowym.

Nie dodawaj bieżącego adresu IP kontenera docelowego do /etc/hosts. Ponownie utworzone kontenery mogą otrzymać inny adres, pozostawiając kolejną nieaktualną zależność.

Sprawdź, z której sieci korzysta odwrotny serwer proxy

Sprawdź przypisania proxy i aplikacji do sieci, etykiety dostawców oraz sieć wybraną do routingu do backendu. Przetestuj alias z kontenera proxy.

Dostawca Dockera w Traefiku umożliwia wskazanie sieci Docker używanej do połączeń z backendami.

Jeśli proxy jest podłączone do kilku sieci, automatyczny wybór może się zmienić po ponownym utworzeniu. Ustaw jawnie właściwą współdzieloną sieć i zachowaj jej rzeczywistą nazwę.

Usuń nieaktualne punkty końcowe bez usuwania niewłaściwej sieci

Wyświetl kontenery podłączone do starej i nowej sieci. Zidentyfikuj osierocone punkty końcowe, zatrzymane kontenery oraz aktywne usługi, które nadal korzystają ze starej sieci projektu.

Przewodnik Red Hat dotyczący sieci kontenerów opisuje podłączanie kontenerów do sieci zdefiniowanych przez użytkownika jako część stanu środowiska uruchomieniowego kontenerów, a nie zawartości plików aplikacji.

Usuń starą sieć dopiero po potwierdzeniu, że żaden aktywny stos z niej nie korzysta. Jednoczesne usunięcie obu sieci i ponowne utworzenie wszystkiego niszczy dowody wskazujące, które przypisanie było nieprawidłowe.

Utwórz ponownie jedną usługę i zweryfikuj DNS z każdego wywołującego kontenera

Ustandaryzuj nazwę projektu lub sieć zewnętrzną, utwórz ponownie tylko usługę, której dotyczy problem, a następnie przetestuj nazwę usługi i alias z każdego zależnego kontenera.

Artykuł ZimaSpace dotyczący zależności środowiska uruchomieniowego kontenera przedstawia powiązaną zasadę: test łączności na hoście nie weryfikuje przestrzeni nazw kontenera ani ścieżki wykrywania usług.

Problem jest rozwiązany, gdy alias wskazuje bieżący punkt końcowy z każdego zamierzonego kontenera wywołującego po ponownym utworzeniu stosu i ponownym uruchomieniu systemu, bez używania adresów IP wpisanych na stałe.

Często zadawane pytania

Czy aliasy sieci Docker są globalne?

Nie. Alias istnieje tylko w sieci, w której został skonfigurowany, i jest dostępny wyłącznie dla kontenerów współdzielących tę sieć.

Czy zmiana nazwy katalogu Compose może zepsuć DNS?

Tak. Nazwa katalogu może wpływać na domyślną nazwę projektu, a ta na generowane nazwy sieci, chyba że nazwa projektu lub sieci zewnętrznej zostanie ustalona jawnie.