Jak skonfigurować dedykowaną sieć Docker dla backendów reverse proxy

Podłącz odwrotny serwer proxy i każdy backend HTTP do jednej współdzielonej sieci zdefiniowanej przez użytkownika; bazy danych pozostaw w prywatnych sieciach aplikacji.

Publikowanie każdego portu backendu na hoście NAS jest zbędne, gdy proxy może rozwiązywać nazwy usług Compose w zdefiniowanej przez użytkownika sieci typu bridge. Wzorzec dwóch sieci zapewnia proxy kontrolowaną ścieżkę do backendów internetowych, podczas gdy bazy danych pozostają dostępne wyłącznie dla swoich aplikacji. Zdefiniuj własność sieci, unikaj niejednoznacznych aliasów, określ, które usługi wymagają dostępu wychodzącego, i sprawdź, czy porty hosta pozostają zamknięte.

Utwórz macierz zamierzonej dostępności

Wymień każde połączenie: klient z proxy, proxy z backendem, backend z bazą danych, backend z zewnętrznymi interfejsami API oraz administrator z punktami końcowymi konserwacji. Zaznacz protokół, port, nazwę DNS i to, czy ścieżka przebiega przez hosta.

Zwykle tylko odwrotny serwer proxy powinien publikować porty 80 i 443. Backendy udostępniają swój port aplikacji w sieci Docker bez mapowania ports na hoście. Bazy danych dołączaj wyłącznie do prywatnej sieci aplikacji, chyba że wymagany jest jawny dostęp administracyjny.

Wybierz stabilne, unikalne nazwy usług lub aliasy sieciowe. DNS Dockera rozwiązuje usługi we współdzielonych sieciach zdefiniowanych przez użytkownika, ale ogólne aliasy, takie jak web, mogą kolidować, gdy wiele projektów Compose dołącza do tej samej sieci proxy.

Utwórz współdzieloną sieć proxy i prywatną sieć aplikacji

Utwórz sieć proxy raz, oznacz ją jako zewnętrzną w każdym projekcie aplikacji i dołącz do niej proxy oraz zamierzony backend. Dzięki temu tożsamość sieci pozostanie stabilna po odtworzeniu pojedynczego projektu Compose.

Zdefiniuj osobną domyślną lub nazwaną prywatną sieć dla każdej aplikacji i dołącz do niej backend oraz bazę danych. Backend staje się kontrolowanym mostem między ruchem proxy a prywatnym stanem; proxy nie powinno dołączać do sieci bazy danych.

Dokumentacja definicji sieci Compose opisuje zewnętrzne sieci i dołączanie usług w Compose. Traktuj zewnętrzną sieć jako zasób, którego cykl życia jest zarządzany poza stosem aplikacji: wdrożenie musi sprawdzić, czy sieć istnieje, zamiast zakładać, że Compose ją utworzy lub usunie.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Usuń niepotrzebne porty hosta i sprawdź ruch wychodzący

Po uruchomieniu trasy proxy usuń publikowanie portów backendu na hoście. Deklaracja expose może dokumentować port kontenera, ale nie jest zaporą sieciową; o tym, które kontenery mogą się łączyć, decyduje członkostwo w sieci.

Używaj internal: true tylko w sieciach, których członkowie rzeczywiście nie potrzebują zewnętrznej trasy. Backendy wywołujące dostawców tożsamości, webhooki, usługi pakietów lub zdalne interfejsy API mogą nie działać w sieci dostępnej wyłącznie wewnętrznie. Gdy wymaga tego projekt aplikacji, użyj drugiej sieci obsługującej ruch wychodzący.

Chroń gniazdo Dockera używane do automatycznego wykrywania proxy. Montowanie tylko do odczytu ogranicza przypadkowe zapisy, ale nie sprawia, że gniazdo jest nieszkodliwe; węższy zakres kontroli zapewnia ograniczony proxy gniazda lub konfiguracja statyczna.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zweryfikuj DNS usług, ekspozycję portów i izolację

Z kontenera proxy rozwiąż nazwę usługi backendu i wywołaj jego punkt końcowy stanu na porcie kontenera. Z niepowiązanego kontenera potwierdź, że nazwa lub połączenie są niedostępne, chyba że ten kontener został celowo dołączony do sieci proxy.

Przeskanuj hosta NAS z innego urządzenia w sieci LAN i potwierdź, że otwarte są tylko porty proxy. Następnie przetestuj TLS, przekazywane nagłówki, przełączanie protokołu WebSocket, duże przesyłane pliki i przekierowania aplikacji za pośrednictwem publicznej nazwy hosta. Mapa usług serwera domowego powinna rejestrować sieć proxy jako część mapy usług serwera domowego.

Wycofaj zmianę, przywracając poprzednie mapowanie portu wyłącznie na potrzeby diagnostyki, a nie jako stałą ukrytą zależność. Zatrzymaj się, jeśli proxy wymaga bezpośredniego dostępu do bazy danych, aliasy kierują do niewłaściwego projektu lub usunięcie portu hosta przerywa nieudokumentowaną integrację.

FAQ 

Czy zewnętrzna sieć Docker jest automatycznie bezpieczniejsza?

Nie. Określenie „zewnętrzna” opisuje własność cyklu życia, a nie bezpieczeństwo. Każdy dołączony kontener może zasadniczo komunikować się zgodnie z działaniem sterownika sieci i zapory hosta.

Czy usługi backendowe nadal powinny deklarować expose?

Jest to opcjonalne dla łączności w sieci zdefiniowanej przez użytkownika, ale może dokumentować zamierzony port kontenera. Nie publikuje portu na hoście.

Czy sieć proxy można oznaczyć jako wewnętrzną?

Tylko jeśli proxy i projekt routingu nadal mają wymagane ścieżki przychodzące i wychodzące. Sieć wewnętrzna blokuje zwykłą zewnętrzną łączność dołączonych kontenerów i może zakłócać przepływy certyfikatów lub tożsamości.

Dlaczego używać nazw usług zamiast adresów IP kontenerów?

Adresy kontenerów mogą się zmienić po ich odtworzeniu. Mechanizm wykrywania usług Dockera zapewnia stabilną nazwę w obrębie współdzielonej sieci, dzięki czemu konfiguracja proxy jest trwalsza.

przywróć zapisany stan bazowy, zastosuj zatwierdzoną konfigurację jeden raz, powtórz pierwotne obciążenie podobne do produkcyjnego, zweryfikuj obiecany sygnał powodzenia, a następnie wykonaj udokumentowane wycofanie. Nie zamykaj zmiany, dopóki dzienniki, czasy, uprawnienia, pojemność i odzyskane dane wyjściowe nie będą zgodne z kryteriami akceptacji.