Publikacja aplikacji Docker

W ćwiczeniu z plikiem Dockerfile utworzyłeś obraz i uruchomiłeś aplikację za pomocą docker run. Jeśli wykonałeś opcjonalne ćwiczenie z Compose, możesz użyć Compose zamiast tego. Tutaj należy sprawić, aby ta sama aplikacja odpowiadała przez nazwę DNS i dostępnego serwera proxy. Możesz użyć własnej aplikacji lub testowej aplikacji z ćwiczenia z pliku Dockerfile.

Najpierw wykonaj bezpośredni test, a następnie komunikację HTTP przez serwer proxy. Ścieżka podstawowa jest ukończona, gdy nazwa zwraca oczekiwany odpowiedź aplikacji, a Ty potrafisz wyjaśnić poszczególne elementy. Obsługa HTTPS oraz instalacja dedykowanego serwera proxy to opcje dodatkowe wymagające określonych warunków wstępnych.

Gdy aplikacja Flask działa na serwerze pod danym portem, serwer proxy odwrotny może przyjmować żądania w imieniu aplikacji i przekazywać je do właściwego kontenera. Dzięki temu użytkownik może użyć nazwy domenowej zamiast adresu IP i numeru portu. Potrzebujesz nazwy DNS, serwera proxy, który masz uprawnienia konfigurować, oraz certyfikatu, jeśli usługa ma korzystać z HTTPS.

DNS odpowiada adresem, ale nie przesyła strony internetowej. Na rysunku serwer proxy kończy połączenie HTTPS i dalej korzysta z HTTP w ograniczonej sieci wewnętrznej. Przeglądarka otrzymuje odpowiedź przez serwer proxy.

Przed rozpoczęciem

Wymagany jest działający kontener z ćwiczenia dotyczącego pliku Dockerfile (lub ćwiczenia Compose) oraz następujące informacje ze środowiska testowego:

• Adres IP maszyny wirtualnej aplikacji: adres maszyny wirtualnej uruchamiającej aplikację; tutaj używany jest port 5000.
• ADRESA PROKSY: adres, pod którym klient ma nawiązać połączenie z proksem, przy czym protokół HTTP działa na porcie 80.
• NAZWA APLIKACJI: nazwa DNS wskazująca na proksy. Aplikacja i proksi mogą być hostowane na różnych maszynach wirtualnych.

Potrzebujesz dostępu do utworzenia elementu Host proxyski w menedżerze Nginx Proxy Managera oraz uprawnień do łączenia się od proksi do aplikacji. Miejsca zastępcze powyżej muszą zostać zastąpione Twoimi wartościami. Jeśli dostępność DNS lub dostępu do proksi nie jest możliwa, wykonaj lokalny test i wyjaśnij diagram. Nie da to jednak ukończonego testu publikacji.

1. Sprawdź aplikację lokalnie

Pracuj w katalogu projektu na VM z aplikacją. Poniższe polecenia używają nazwy kontenera min-app z ćwiczenia dotyczącego pliku Dockerfile. Dzięki mapowaniu portów z tego ćwiczenia ten test powinien wyświetlić stronę główną:

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Możesz użyć /status jako stałego punktu kontrolnego. Jeśli ta trasa nie istnieje wcześniej, dodaj ją po innych pełnych funkcjach tras i przed if __name__ == "__main__": w pliku app.py:

@app.route("/status")
def status():
    return {"status": "ok"}

Zbuduj, uruchom i przetestuj ponownie:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Jeśli używasz Compose, zastąp trzy pierwsze polecenia poleceniem docker compose up -d --build.

Oczekuj odpowiedzi HTTP 200 z kodem JSON zawierającym "status": "ok". Jeśli aplikacja ma już endpoint /status, użyj tam udokumentowanej odpowiedzi zamiast tworzyć nową trasę o tej samej nazwie. To sprawdza tylko tę trasę, a nie wszystkie funkcje aplikacji.

2. Udostępnij aplikację dla agenta proxy

Dalsza instrukcja używa adresu sieciowego maszyny wirtualnej z aplikacją (app-VM). Jeśli port jest powiązany tylko z adresem 127.0.0.1, uruchom ponownie kontener, używając faktycznego adresu VM w mapowaniu portów. Ogranicz dostęp do sieci wyłącznie do niezbędnych źródeł; samo powiązanie adresów nie ogranicza klientów, którzy mogą się połączyć.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Jeśli używasz Compose, zamień wiersz z portem pod app w pliku compose.yaml na "APP-VM-IP:5000:5000" i uruchom polecenie docker compose up -d.

Uruchom testy na maszynie wirtualnej aplikacji oraz ze środowiska sieciowego serwera odwrotnego (proxy) lub z klienta testowego o tym samym poziomie dostępu. Faktyczne połączenie serwera odwrotnego jest również kontrolowane za pomocą nazwy opisanej w następnej sekcji. Po zmianie wiązania przetestuj adres maszynowy wirtualny, a nie 127.0.0.1. Nie otwieraj tego portu dla całego internetu. [[Segmentacja poziom 1 – VLAN i segmentacja sieci|Segmentacja]] zapewnia wsparcie dla reguł dostępowych.

Od domeny po kontenera

Kiedy użytkownik otwiera nazwę taką jak https://app.example.test, dzieje się kilka rzeczy. To jest przykładowa nazwa; zastąp ją nazwą faktycznie skonfigurowaną w Twoim środowisku testowym:

sequenceDiagram
    participant B as Przeglądarka
    participant D as DNS
    participant P as Menedżer proxy Ngix
    participant F as Kontener Flaska

    B->>D: Znajdź adres IP dla domeny
    D-->>B: Adres IP proxy
    B->>P: Żądanie do domeny
    P->>P: Znajdź odpowiedni host proxy
    P->>F: Przekierowanie na wewnętrzny port 5000
    F-->>P: Zwróć stronę HTML
    P-->>B: Zwróć odpowiedź

Dlatego warto testować po jednym warstwie naraz, zamiast debugować jednocześnie DNS, proxy i Flask.

Menedżer proxy Nginx

Nginx Proxy Manager to interfejs webowe dla Nginxa. Tutaj używasz dostępnej instalacji i tworzysz jeden hosta proxy. Nie musisz instalować nowego proxy dla każdej aplikacji.

Utwórz hosta proxy:

1. Wpisz APP-NAVN, nazwę faktycznie skonfigurowaną dla usługi.
2. Wybierz http jako schemat połączenia od Nginx Proxy Manager do kontenera.
3. Wpisz APP-VM-IP jako przesyłany hostname. 127.0.0.1 wewnątrz kontenera proxy oznacza sam kontener proxy.
4. Wpisz opublikowany port kontenera, na przykład 5000.
5. Zapisz i otwórz http://APP-NAVN/status z klienta.

Nazwa powinna rozwiązywać się do PROXY-IP. Możesz sprawdzić rozwiązanie za pomocą nslookup APP-NAVN na kliencie. Test HTTP powinien dać ten sam kod odpowiedzi statusu jak test bezpośredni. Wyświetlenie strony domyślnej proxy nie oznacza, że żądanie dotarło do aplikacji.

Ponowne wybranie: HTTPS

Gdy HTTP działa i masz ważny certyfikat dla nazwy, otwórz kartę SSL, wybierz certyfikat i przetestuj https://NAZWA-APLIKACJI/status. Wewnętrzna nazwa przykładowa, taka jak app.example.test, nie może otrzymać publicznego certyfikatu od Let’s Encrypt; w takim przypadku potrzebujesz certyfikatu od wewnętrznej organizacji wydającej, której klienci ufają. Samo zapytanie DNS nie konfiguruje HTTPS. Ścieżka bazowa HTTP to ćwiczenie lokalne; podczas przetwarzania logowania lub innych danych wartych ochrony wymagane jest HTTPS.

Serwer proxy musi mieć dostęp do porta na serwerze. Jeśli kontener działa na innym VM, sieć i firewall muszą umożliwiać ruch między maszynami wirtualnymi. Nie musisz wystawiać portu Flask bezpośrednio wobec całego internetu, gdy Nginx Proxy Manager jest punktem wejścia; ogranicz dostęp za pomocą firewalu zgodnie ze konfiguracją szkoły.

Ponowne wybory: Własny proxy

Instaluj własnego proxy tylko wtedy, gdy faktycznie go potrzebujesz i masz własne środowisko testowe. Skorzystaj z instrukcji instalacji Nginx Proxy Managera. Następnie wróć do tworzenia hosta proxy powyżej. Jest to osobna konfiguracja, a nie wymaganie wstępne do korzystania z istniejącego proxy.

Rozwiązywanie problemów

docker ps
docker logs -f min-app
ss -tulpn

Jeśli używasz Compose, dwie pierwsze komendy to docker compose ps i docker compose logs -f. Wykonuj te polecenia jedno po drugim na maszynie wirtualnej aplikacji (app-VM). Zakończ działanie logs -f za pomocą klawiszy Ctrl+C. Polecenie ps wyświetla status kontenerów, dziennik zdarzeń pokazuje komunikaty aplikacji, a ss może pomóc w badaniu portów nasłuchujących. Użyj wyniku konkretnego testu HTTP do zweryfikowania dostępu.

Przeprowadź testy w tej kolejności:

1. Na maszynie wirtualnej aplikacji po zmianie bindingu: curl --fail --show-error http://IP-MASZYNY-WIRTUALNEJ-APLIKACJI:5000/status.
2. Ze środowiska sieciowego serwera pośredniczącego (proxy): ten sam adres, port i ścieżka. Dowolny klient może mieć inne zasady dostępu.
3. Z klienta przez nazwę domeny: nslookup NAZWY_APLIKACJI, następnie http://NAZWY_APLIKACJI/status. Przetestuj HTTPS osobno, jeśli jest skonfigurowany.

Jeśli punkt 1 zakończy się błędem, zbadaj aplikację, status kontenera, adres i przypisanie portu. Jeśli punkt 1 działa, ale punkt 2 kończy się błędem, sprawdź połączenie oraz zasady dostępu ze strony serwera pośredniczącego. Jeśli punkt 2 działa, a punkt 3 kończy się błędem, zbadaj DNS, nagłówek Host proxy oraz wybrany protokół. Kod HTTP 404 oznacza, że serwer HTTP odpowiedział, ale ścieżka może być nieprawidłowa; kod 502 od serwera pośredniczącego wskazuje na problem z połączeniem lub odpowiedzią aplikacji. Zapisz, co test zawęża, zanim cokolwiek zmienisz.

Następny krok

Wyświetl odpowiedź dotyczącą stanu za pomocą nazwy i wyjaśnij różnicę między zapytaniem DNS a przekazywaniem dalej w pośredniku (proxy). Wskaż również klienta, pośrednik (proxy) oraz aplikację na rysunku lub własnym szkicu. Możesz to wyjaśnić ustnie lub pisemnie. Podaj adres testowy, oczekiwany/faktyczną odpowiedź oraz czy próbowałeś HTTP lub HTTPS. W przypadku odchylenia użyj powyżej przedstawionej kolejności testów przed przejściem do dalszych działań.

Gdy ścieżka podstawowa działa, możesz korzystać z tego zestawienia dalej w projekcie. Docker - Publikowanie kontenera przy użyciu workflow to kolejne szkolenie dotyczące automatyzacji budowania i publikowania obrazu.

Źródła: Docker: portbinding, Nginx Proxy Manager and Flask: ruter og svar.