Część 2.2 — Instalowanie serwera Nginx i konfigurowanie go jako odwrotnego serwera proxy

Dotyczy: .NET Core 2.1, .NET Core 3.1, .NET 5

W tym artykule przedstawiono sposób instalowania serwera Nginx i konfigurowania go jako odwrotnego serwera proxy.

Wymagania wstępne

Aby wykonać ćwiczenia opisane w tej części, musisz mieć jedną aplikację internetową ASP.NET Core utworzoną i wdrożona w folderze /var .

Cel tej części

W poprzedniej części utworzono aplikację internetową platformy ASP.NET Core przy użyciu narzędzia interfejsu wiersza polecenia platformy .NET, a aplikacja jest wdrażana w folderze /var . Aplikacja została również skonfigurowana do nasłuchiwania na porcie 5000 dla żądań HTTP, a przekierowanie HTTPS zostało usunięte.

W tym momencie klienci powinni podać numer portu podczas nawiązywania połączenia z aplikacją (na przykład http://localhost:5000). Nie jest to jednak pożądane zachowanie.

Nasze cele w tej części są następujące:

• Klienci powinni mieć możliwość nawigowania bez konieczności podawania numeru portu. Na przykład klienci powinni łączyć się przy użyciu polecenia http://localhost.
• Aplikacja internetowa powinna zostać uruchomiona automatycznie, jeśli zostanie zatrzymana z jakiegoś powodu lub po ponownym uruchomieniu komputera.

W następnej sekcji użyjesz serwera Nginx jako serwera proxy, aby kierować żądania HTTP wysyłane do portu 80 do naszej aplikacji .NET. Skonfigurujesz również aplikację do automatycznego uruchamiania.

Co to jest serwer Nginx?

Nginx to popularny, lekki i szybki serwer internetowy. Można go uruchomić zarówno w systemach Linux, jak i Windows, i można go skonfigurować jako zwrotny serwer proxy.

Co to jest demon?

Nginx działa jako demon. Demon to alternatywny termin dla usługi działającej w tle. Podobnie jak w przypadku usług uruchamianych w systemie Windows demony można skonfigurować do automatycznego uruchamiania podczas uruchamiania. Skonfigurujesz aplikację ASP.NET Core do uruchamiania jako demona.

Instalowanie serwera Nginx przy użyciu narzędzia APT

Instalowanie serwera Nginx jest proste. Uruchom polecenie , sudo apt install nginx aby zainstalować program na maszynie wirtualnej z systemem Ubuntu.

Po zakończeniu instalacji uruchom polecenie whereis nginx , aby dowiedzieć się, gdzie jest zainstalowany program. Możesz zobaczyć, gdzie znajdują się pliki konfiguracji Nginx, sprawdzając dane wyjściowe. Poniższy zrzut ekranu pokazuje, że pliki konfiguracji znajdują się w folderze /etc/nginx .

Uwaga 16.

Jeśli uruchamiasz dystrybucję inną niż Ubuntu lub Debian, możesz znaleźć równoważne polecenie instalacji menedżera pakietów lub instrukcje z oficjalnej dokumentacji instalacji serwera Nginx.

Zarządzanie usługami przy użyciu biblioteki systemctl

Jeśli nie widzisz, że serwer Nginx jest uruchomiony, możesz go uruchomić jawnie, uruchamiając polecenie sudo systemctl start nginx. Mimo że to ćwiczenie demonstruje systemctl polecenia dla serwera Nginx, te polecenia służą do konfigurowania aplikacji internetowej do automatycznego uruchamiania jako demona.

Po zakończeniu instalacji serwer Nginx jest już skonfigurowany do automatycznego uruchamiania. Nginx działa jako demon. Stan demona można sprawdzić przy użyciu elementu systemctl.

Polecenie systemctl służy do zarządzania "usługami" dla takich zadań, jak wyświetlanie stanu usługi lub uruchamianie i zatrzymywanie. Niektóre dostępne parametry to uruchamianie, zatrzymywanie, ponowne uruchamianie, włączanie, wyłączanie i stan. Aby sprawdzić stan serwera Nginx, uruchom polecenie systemctl status nginx.

To polecenie generuje kilka przydatnych informacji. Jak pokazano na tym zrzucie ekranu, serwer Nginx jest w active (running) stanie, a identyfikator procesu wystąpienia serwera Nginx to 8539. Zwróć również uwagę na instrukcje enabled i vendor preset: enabled . Enabled oznacza, że ten demon zostanie uruchomiony po ponownym uruchomieniu maszyny i vendor preset: enabled oznacza, że serwer Nginx jest domyślnie włączony po zainstalowaniu. W związku z tym serwer Nginx zostanie uruchomiony automatycznie po uruchomieniu serwera.

Testowanie instalacji serwera Nginx

Domyślnie serwer Nginx nasłuchuje na porcie 80. Ponieważ jest uruchomiona, podczas przeglądania hosta lokalnego powinno być możliwe uzyskanie dostępu do strony głównej serwera Nginx. Użyj curl polecenia , aby przetestować serwer Nginx, uruchamiając polecenie curl localhost. Żółty wyróżniony tekst na poniższym zrzucie ekranu przedstawia domyślną stronę internetową serwera Nginx. W związku z tym serwer Nginx jest uruchomiony:

opcje poleceń systemctl

Usługi lub demony mogą być zarządzane za pomocą systemctl polecenia . Uruchamianie, zatrzymywanie lub wprowadzanie zmian wymaga dostępu administratora. W związku z tym należy dodać sudo prefiks do tych poleceń.

Ponowne uruchamianie demonów

Może być konieczne ponowne uruchomienie demonów od czasu do czasu. Aby ponownie uruchomić demona, uruchom polecenie sudo systemctl restart <daemon_name>. Aby ponownie uruchomić serwer Nginx, uruchom polecenie sudo systemctl restart nginx. Upewnij się, że przed uruchomieniem tego polecenia sprawdź stan serwera Nginx i po nim, aby monitorować zmiany identyfikatora procesu.

Zatrzymaj demony

Aby zatrzymać demona, uruchom polecenie sudo systemctl stop <daemon_name>. Aby zatrzymać serwer Nginx, uruchom polecenie sudo systemctl stop nginx, a następnie sprawdź stan serwera Nginx, uruchamiając systemctl status nginx ponownie. Tym razem usługa jest wyświetlana jako nieaktywna (martwa), ale nadal włączona. Oznacza to, że mimo że usługa nie jest uruchomiona, zostanie uruchomiona automatycznie po ponownym uruchomieniu serwera.

Uwaga 16.

Polecenie systemctl status wyświetla również kilka wierszy poprzednich wpisów dziennika demona.

Po zatrzymaniu serwera Nginx ponownie uruchom polecenie curl localhost .

Uwaga 16.

Połączenie nie jest odrzucane, ponieważ nic nie nasłuchuje ruchu przychodzącego na porcie 80.

Wyłączanie demonów

Wyłączenie demona różni się od zatrzymywania demona. Wyłączony demon może być uruchomiony, ale nie zostanie uruchomiony automatycznie po ponownym uruchomieniu serwera. Aby wyłączyć demonA Nginx, uruchom polecenie sudo systemctl disable nginx, a następnie sprawdź stan serwera Nginx.

Ten zrzut ekranu pokazuje, że serwer Nginx nie jest uruchomiony i jest wyłączony. Oznacza to, że serwer Nginx nie zostanie uruchomiony automatycznie po ponownym uruchomieniu.

Uruchom demony

Aby uruchomić demona, uruchom polecenie sudo systemctl start <daemon_name>. Aby uruchomić serwer Nginx, uruchom polecenie sudo systemctl start nginx, a następnie ponownie sprawdź stan usługi.

Ten zrzut ekranu pokazuje, że serwer Nginx został uruchomiony, ale nadal jest wyłączony. Mimo że usługa jest uruchomiona, serwer Nginx nie zostanie uruchomiony automatycznie po ponownym uruchomieniu, ponieważ jest to usługa wyłączona.

Włączanie demonów

Włączenie usługi oznacza, że zostanie uruchomiona automatycznie po ponownym uruchomieniu. Aby włączyć serwer Nginx, uruchom polecenie sudo systemctl enable nginx, a następnie ponownie sprawdź stan serwera Nginx.

Ten zrzut ekranu pokazuje, że serwer Nginx jest uruchomiony i zostanie uruchomiony po ponownym uruchomieniu serwera.

Konfigurowanie serwera Nginx jako zwrotnego serwera proxy w celu kierowania żądań do aplikacji ASP.NET Core

Teraz, gdy wiesz już, jak uruchomić, zatrzymać i ponownie uruchomić usługę Nginx, następnie skonfigurujesz serwer Nginx jako zwrotny serwer proxy w celu kierowania żądań wysyłanych na porcie 80 do aplikacji ASP.NET Core nasłuchującej na porcie 5000.

Oto wymagana konfiguracja. Niektóre kluczowe części są wyróżnione.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Ta konfiguracja wskazuje następujące elementy:

• Serwer Nginx nasłuchuje na porcie 80 dla wszystkich żądań (dyrektywa: listen 80).
• Serwer Nginx będzie kierować żądania do http://localhost:5000 (dyrektywa: proxy_pass http://localhost:5000)

Uwaga 16.

Wiersz server_name _ w kodzie. Jest ona używana jako dyrektywa catch-all. Jeśli chcesz dowiedzieć się więcej na temat server_name, zapoznaj się z oficjalną dokumentacją.

Zmiany konfiguracji są proste. Użyjemy tego kodu, aby zastąpić sekcję server dyrektywy w pliku konfiguracji. Ale gdzie jest plik konfiguracji?

Znajdź prawidłowy plik konfiguracji serwera Nginx

Podstawowym plikiem konfiguracji serwera Nginx jest /etc/nginx/nginx.conf. Aby sprawdzić konfigurację, użyj cat /etc/nginx/nginx.conf polecenia i wyszukaj dyrektywę serwera.

Przewiń konfigurację, aby zlokalizować dyrektywę serwera. Należy się spodziewać, że go nie znajdziesz. W pliku konfiguracji można umieścić żądane zmiany konfiguracji. Jednak w idealnym przypadku nie chcesz zastępować oryginalnego pliku konfiguracji. Zapobiega to wprowadzeniu błędów konfiguracji, które mogą uniemożliwić prawidłowe uruchamianie serwera. Sekcja server nie znajduje się w głównym pliku konfiguracji. Jeśli będziesz przewijać plik konfiguracji, okaże się, że istnieją pewne include dyrektywy.

Dyrektywy dołączania ułatwiają zarządzanie konfiguracją przez podzielenie jej na fragmenty, które mają zostać uwzględnione w głównym pliku konfiguracji. Główny plik konfiguracji może być prosty, a niektóre określone części konfiguracji można przenieść do innych plików. Wyróżnione wiersze na tym zrzucie ekranu wskazują następujące elementy:

• Serwer Nginx załaduje konfigurację z każdego pliku conf znajdującego się w katalogu /etc/nginx/conf.d .
• Serwer Nginx załaduje konfiguracje z każdego pliku znajdującego się w katalogu /etc/nginx/sites-enabled .

Jeśli sprawdzisz te katalogi, nie znajdziesz żadnych plików konfiguracji w folderze /etc/nginx/conf.d. Istnieje jednak jeden plik w pliku /etc/nginx/sites-enabled.

Domyślny plik konfiguracji wygląda jak główny kandydat do hostowania konfiguracji, którą szukamy. Jeśli sprawdzisz plik /etc/nginx/sites-enabled/default przy użyciu polecenia cat /etc/nginx/sites-enabled/default, zobaczysz, że domyślna dyrektywa serwera zostanie umieszczona w następującym kodzie.

W związku z tym plik /etc/nginx/sites-enabled/default musi być edytowany, aby zmienić konfigurację.

Edytowanie pliku konfiguracji przy użyciu narzędzia vi

Wiesz już, jak edytować pliki podczas edytowania pliku Startup.cs w celu usunięcia przekierowania HTTPS z potoku ASP.NET. Teraz ponownie użyjesz narzędzia vi, aby zmienić plik konfiguracji serwera nginx.

Napiwek

Zawsze należy utworzyć kopię zapasową zmienianych plików. Jeśli coś pójdzie nie tak po edycji, możesz użyć tej kopii, aby przywrócić plik do poprzedniego stanu. W takim przypadku uruchom polecenie cp /etc/nginx/sites-enabled/default ~/nginx-default-backup , aby skopiować plik konfiguracji do katalogu macierzystego. Nazwa pliku kopii zapasowej to nginx-default-backup. Zwróć uwagę, że kopia zapasowa nie została wykonana w tym samym katalogu co oryginalny plik. Dzieje się tak, ponieważ serwer Nginx ładuje wszystkie pliki konfiguracji z tego katalogu i nie chcesz przerywać konfiguracji, ładując dwie różne wersje dyrektywy serwera.

Uruchom polecenie sudo vi /etc/nginx/sites-enabled/default , aby edytować plik konfiguracji i zastąpić dyrektywę serwera, jak pokazano na poniższym zrzucie ekranu.

Poniżej przedstawiono kilka wskazówek i wskazówek dotyczących edytowania plików przy użyciu programu vi:

• Możesz przewijać w górę i w dół za pomocą strzałek.
• Aby wprowadzić tryb edycji, naciśnij Insert lub I . W trybie edycji w lewym dolnym rogu pojawi się komunikat --INSERT- .
• W trybie edycji można użyć klawiatury, aby usunąć znaki pojedynczo.
• W trybie edycji operacje kopiowania i wklejania współpracują z większością terminali. Dlatego możesz skopiować zawartość z tego artykułu i wkleić ją do elementu vi.
• Aby zakończyć tryb edycji, naciśnij Esc.
• Wiersze można łatwiej usuwać w trybie normalnym. W trybie normalnym przejdź do początku wiersza, który chcesz usunąć, i wprowadź dd. Polecenie dd usuwa cały wiersz. Możesz również wpisać 5dd , aby usunąć pięć wierszy jednocześnie. Jednak ta opcja powinna być używana z ostrożnością, aby uniknąć usuwania dodatkowej zawartości.
• Jak usunąć linie w vim / Vi artykuł jest dobry, aby dowiedzieć się, jak usunąć wiele wierszy w vi.
• Aby zakończyć działanie vi i zapisać zmiany, wprowadź ciąg :wq!, a następnie naciśnij Enter. W tym miejscu dwukropek (:) oznacza, że uruchamiasz polecenie, oznacza to zapisanie zmian, w q oznacza zamknięcie i ! oznacza zastąpienie zmian.
• Aby zakończyć bez zapisywania zmian, wprowadź ciąg :q!, a następnie naciśnij Enter.

Zmiany są teraz zapisywane i musisz ponownie uruchomić usługę Nginx, aby te zmiany zaczęły obowiązywać. Przed ponownym uruchomieniem usługi możesz uruchomić sudo nginx -t polecenie , aby przetestować plik konfiguracji. Po uruchomieniu tego polecenia serwer Nginx sprawdza składnię pliku konfiguracji, a następnie próbuje otworzyć pliki, do których odwołuje się plik konfiguracji.

Jak widać tutaj, plik konfiguracji, który został zmieniony, wydaje się być poprawny.

Musimy ponownie uruchomić serwer Nginx, aby zmiany zaczęły obowiązywać:

sudo systemctl restart nginx

Po ponownym uruchomieniu spodziewasz się, że otrzymasz odpowiedź z aplikacji ASP.NET Core po wysłaniu żądania do http://localhost , ponieważ serwer Nginx powinien działać jako zwrotny serwer proxy dla żądań wysyłanych do portu 80.

Uruchom ponownie usługę Nginx, aby zmiany zaczęły obowiązywać, a następnie wysłać żądanie do hosta lokalnego, uruchamiając polecenie curl localhost. Jednak to polecenie zakończy się niepowodzeniem. Następnym krokiem jest uruchomienie wget localhostpolecenia , a następnie wyszukanie wskazówek dotyczących źródła problemu.

Rozwiązywanie problemu z serwerem proxy Nginx

Na poprzednim zrzucie ekranu są widoczne następujące informacje:

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

Pierwsze i drugie wiersze wskazują, że możesz rozpoznać hosta lokalnego i nawiązać połączenie z gniazdem 127.0.0.1:80 . W związku z tym serwer Nginx powinien być uruchomiony. Aby to sprawdzić, możesz uruchomić systemctl status nginx polecenie .

Trzeci wiersz wskazuje źródło problemu. Zostanie wyświetlony komunikat o błędzie HTTP 502 Bad Gateway . Zła brama HTTP 502 jest powiązana z serwerami proxy. Oznacza to, że zwrotny serwer proxy nie może nawiązać połączenia z aplikacją zaplecza. W takim przypadku jest to aplikacja internetowa ASP.NET Core, która powinna być uruchomiona i nasłuchuje na porcie 5000 dla żądań. Powinniśmy sprawdzić, czy aplikacja internetowa jest również uruchomiona.

Aby rozpocząć rozwiązywanie problemów, uruchom to samo netstat polecenie co poprzednio. Tym razem użyj grep, aby filtrować port 5000 aplikacji. Następnie uruchom polecenie netstat -tlp | grep 5000.

Te przykładowe dane wyjściowe wskazują, że nic nie nasłuchuje na porcie 5000. W związku z tym jest to przyczyna odpowiedzi HTTP 502 pochodzącej z serwera Nginx, ponieważ nie może znaleźć procesu nasłuchiwania na porcie 5000.

Rozwiązaniem jest uruchomienie aplikacji ASP.NET Core. Jednak przed kontynuowaniem możesz przejrzeć inne podejście do rozwiązywania tego problemu. Nie każdy problem jest tak prosty, aby rozwiązać ten problem, ponieważ wystarczy spojrzeć na kilka wierszy zawartości dziennika i znaleźć główną przyczynę. Czasami należy szczegółowo poznać inne dzienniki systemu i aplikacji.

Ponieważ ściśle współpracujesz z serwerem Nginx podczas konfigurowania aplikacji ASP.NET Core w systemie Linux, zalecamy zapoznanie się z tego rodzaju dziennikami Nginx i systemem operacyjnym na potrzeby rozwiązywania problemów.

Sprawdzanie dzienników serwera Nginx

Jeśli uruchomisz cat /etc/nginx/nginx.conf ponownie polecenie , a następnie poszukaj elementu logging settings, zwróć uwagę na następujące kwestie.

Pokazuje to, że serwer Nginx ma dwa rodzaje dzienników: dzienniki dostępu i dzienniki błędów. Są one przechowywane w katalogu /var/log/nginx/ .

Dzienniki dostępu są podobne do plików dziennika usług IIS. Szybka inspekcja zawartości pokazuje, że przypominają one poniższy zrzut ekranu.

Dzienniki dostępu nie pokazują nowych informacji innych niż stan odpowiedzi HTTP 502, który już znasz. Możesz również sprawdzić dzienniki błędów, uruchamiając polecenie cat /var/log/nginx/error.log. Ujawniają one o wiele więcej o przyczynie problemu.

Wskazania są jasne: serwer Nginx może pobrać żądanie od klienta, ale nie może nawiązać upstream połączenia z serwerem w http://127.0.0.1:5000 lokalizacji i z aplikacją ASP.NET Core, która powinna być uruchomiona i nasłuchuje na tym porcie.

Rozwiązanie

Aby obejść ten problem, uruchom ręcznie aplikację ASP.NET Core. Nawiąż połączenie z serwerem przy użyciu drugiej sesji terminalu, a następnie uruchom aplikację ASP.NET Core tak jak poprzednio.

Gdy aplikacja ASP.NET Core jest uruchomiona, przełącz się na inną sesję terminalu i uruchom to samo curl localhost polecenie. Teraz możesz uzyskać dostęp do aplikacji ASP.NET Core działającej za serwerem Nginx. Poniższy zrzut ekranu pokazuje, że zostało wykonane żądanie do hosta lokalnego, żądanie zostało obsłużone przez serwer Nginx i skierowane do aplikacji zaplecza i odebrano odpowiedź z aplikacji ASP.NET Core.

Teraz skonfigurowano serwer Nginx do zachowania się jako zwrotny serwer proxy dla aplikacji ASP.NET Core działającej w systemie Linux.

Jeśli jednak aplikacja ASP.NET Core nie zostanie uruchomiona po ponownym uruchomieniu, jaki będzie wynik? Co się stanie, jeśli aplikacja internetowa ulegnie awarii i nie rozpocznie się, dopóki nie zauważysz, że nie jest uruchomiona? Czy należy uruchomić aplikację ASP.NET Core po każdym ponownym uruchomieniu procesu zakończenia?

Następne kroki

Część 2.3 — konfigurowanie aplikacji ASP.NET Core do automatycznego uruchamiania

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.