Czy można zmienić opublikowany port kontenera bez przebudowywania jego bazy danych?

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.

Can You Change a Container’s Published Port Without Rebuilding Its Database? - Zima Store Online

Tak, możesz zmienić opublikowany port kontenera bez przebudowywania jego bazy danych, jeśli baza danych pozostaje na tej samej zweryfikowanej pamięci trwałej.

Na domowym serwerze NAS lub hoście Dockera widoczny port zwykle należy do jednorazowego kontenera aplikacji, podczas gdy rekordy, konta i ustawienia znajdują się w nazwanym woluminie, podpięciu bind mount lub oddzielnej usłudze bazy danych. Bezpieczna zmiana polega więc na zachowaniu definicji wdrożenia i ścieżek trwałych danych, zmianie wyłącznie reguły publikowania po stronie hosta, ponownym utworzeniu usługi aplikacji, której dotyczy zmiana, a następnie sprawdzeniu każdego serwera proxy, zakładki, wywołania zwrotnego, reguły zapory i testu kondycji, które nadal odwołują się do starego portu.

Oddziel opublikowany port hosta od portu nasłuchiwania kontenera

Przed zmianą zapisz bieżące mapowanie jako dwa różne punkty końcowe. W zapisie 8080:80 klienci łączą się z portem 8080 na hoście Dockera, podczas gdy aplikacja nadal nasłuchuje na porcie 80 wewnątrz kontenera. Zmiana lewej strony nie zmienia automatycznie procesu aplikacji ani połączenia z bazą danych.

Przypadek dotyczący rozwiązywania problemów w społeczności Dockera podkreśla, że mapowanie hosta i wewnętrzny port nasłuchiwania są od siebie niezależne oraz że nowy opublikowany port nie zadziała, gdy wewnątrz nic nie nasłuchuje na docelowym porcie.

Sprawdź opublikowane porty działającego kontenera i gniazda nasłuchujące, a następnie przetestuj wewnętrzny punkt końcowy z wnętrza kontenera lub jego sieci. Pozostaw wewnętrzny port bez zmian, chyba że sama aplikacja musi zostać przeniesiona. Ten pierwszy test zapobiega przekształceniu prostej zmiany portu hosta w niepotrzebną rekonfigurację aplikacji.

Chroń bieżącą ścieżkę bazy danych przed ponownym utworzeniem usługi

Zapisz plik Compose, tag lub skrót obrazu, pliki środowiskowe, nazwane woluminy, podpięcia bind mount, nazwy sieci, sekrety i nazwę hosta bazy danych. Celem jest potwierdzenie, który obiekt przechowuje trwały stan, zanim Docker zastąpi kontener aplikacji.

Zmiana publikowania portu wymaga nowej konfiguracji kontenera, ale nie wymaga budowania nowego obrazu ani tworzenia nowej bazy danych. Praktyczna odpowiedź dotycząca Dockera rozróżnia ponowne utworzenie kontenera od przebudowania obrazu aplikacji po zmianie ustawień portu.

Jeśli usługa ma istotne znaczenie, wykonaj aktualną kopię zapasową lub migawkę bazy danych spójną z aplikacją, a następnie sprawdź, czy ścieżka bazy danych nie znajduje się w zapisywalnej warstwie kontenera. Zatrzymaj się, jeśli lista podpięć jest niejednoznaczna, nazwa woluminu uległa zmianie lub bieżąca aplikacja wygląda na korzystającą z nieoczekiwanej pustej bazy danych.

Zmień tylko mapowanie po stronie hosta i utwórz ponownie usługę aplikacji

Edytuj usługę aplikacji, zmieniając mapowanie z 8080:80 na 8081:80. Pozostaw obraz, port wewnętrzny, woluminy, adres URL bazy danych, nazwę usługi, sieci i mapowanie użytkownika bez zmian, chyba że istnieje inne zweryfikowane wymaganie.

Składnia portów Compose jest interpretowana od hosta do kontenera, więc zmiana strony hosta pozostawia proces nasłuchujący na dotychczasowym porcie wewnętrznym. Przykład z forum Dockera wyjaśnia, dlaczego lewa strona oznacza port hosta, a prawa nadal musi odpowiadać portowi nasłuchiwania aplikacji.

Utwórz ponownie tylko usługę aplikacji, korzystając ze zaktualizowanej definicji. Nie używaj polecenia stosu, które usuwa woluminy, nie inicjalizuj ponownie bazy danych i nie dodawaj --build, chyba że zmienił się sam obraz. Po ponownym utworzeniu sprawdź rzeczywiste podpięcia i mapowanie portów, zanim zezwolisz na uruchomienie migracji lub zadań w tle.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Zaktualizuj każdą ścieżkę klienta zależną od starego portu

Zakładka w przeglądarce jest tylko jednym z odbiorców opublikowanego portu. Serwery proxy, przekierowania routera, lokalne zapory, sondy monitorujące, aplikacje mobilne, adresy docelowe webhooków, wywołania zwrotne OAuth, listy dozwolonych CORS i generowane publiczne adresy URL mogą nadal wskazywać poprzedni punkt końcowy.

Niektóre aplikacje hostowane samodzielnie wykonują żądania do interfejsu loopback lub tworzą adresy URL wywołań zwrotnych na podstawie skonfigurowanego adresu publicznego. Dyskusja dotycząca kontenera WordPress pokazuje, jak zmienione mapowanie zewnętrzne może ujawnić zachowanie loopback zależne od portu, nawet gdy baza danych pozostaje sprawna.

Wyszukaj stary port w projekcie Compose, konfiguracji proxy, plikach środowiskowych i ustawieniach aplikacji. Aktualizuj tylko te warstwy, które faktycznie korzystają z punktu końcowego hosta. Kontenery wewnętrzne powinny zwykle nadal używać nazwy usługi i portu wewnętrznego zamiast nowo opublikowanego portu hosta.

Pozostaw bazę danych na jej prywatnej ścieżce kontenera

Nie zmieniaj ani nie publikuj portu bazy danych tylko dlatego, że zmienił się port hosta aplikacji internetowej. Baza danych używana wyłącznie przez kontenery w tym samym stosie może nadal być dostępna za pomocą nazwy usługi i portu wewnętrznego, bez publikowania jakiegokolwiek portu na hoście.

Pomylenie publicznego punktu końcowego aplikacji z połączeniem z bazą danych może spowodować kolejną awarię: aplikacja może zostać skierowana na adres NAS i port hosta, mimo że baza danych powinna pozostać w prywatnej sieci Dockera. Taka zmiana dodaje zmienne związane z zaporą, NAT-em i uwierzytelnianiem, nie ułatwiając przeglądarce dostępu do usługi internetowej.

Z poziomu ponownie utworzonego kontenera aplikacji rozwiąż nazwę usługi bazy danych, otwórz jej wewnętrzny port TCP, uwierzytelnij się i wykonaj nieszkodliwy odczyt. Jeśli ta ścieżka się nie zmieniła, pozostaw ją bez zmian. Jeśli test bazy danych zakończy się niepowodzeniem, przywróć pierwotną definicję aplikacji przed rozpoczęciem diagnozowania oddzielnego problemu z siecią lub danymi uwierzytelniającymi.

Zweryfikuj nowy port bez ingerowania w dane trwałe

Najpierw przetestuj bezpośrednio nowy port hosta, a następnie użyj zwykłej nazwy hosta lub trasy odwrotnego proxy. Potwierdź logowanie, odczyt rekordów, jeden odwracalny zapis, przesyłanie plików, zaplanowane zadania, integracje i kontrolowany restart kontenera.

Przewodnik ZimaSpace dotyczący dopasowywania testów kondycji do rzeczywistych ścieżek aplikacji jest kolejnym krokiem, gdy nowy punkt końcowy działa w przeglądarce, ale Docker nadal zgłasza usługę jako niesprawną.

Zmiana jest zakończona dopiero wtedy, gdy nowy opublikowany port przetrwa ponowne utworzenie kontenera i restart, proxy oraz klienci przestaną używać starego punktu końcowego, aplikacja ponownie połączy się z tą samą trwałą bazą danych, a kopia zapasowa bazy danych pozostanie dostępna. Przywróć mapowanie portu, jeśli aplikacja uruchomi się z nowym pustym stanem lub rozpocznie nieoczekiwaną migrację.