Freigeben über


Teil 2.2 – Installieren von Nginx und Konfigurieren als Reverseproxyserver

Gilt für: .NET Core 2.1, .NET Core 3.1, .NET 5

In diesem Artikel wird erläutert, wie Nginx installiert und als Reverseproxyserver konfiguriert wird.

Voraussetzungen

Um den Übungen in diesem Teil zu folgen, müssen Sie eine ASP.NET Core-Webanwendung erstellt und im Ordner "/var " bereitgestellt haben.

Ziel dieses Teils

Im vorherigen Teil haben Sie mithilfe des .NET CLI-Tools eine ASP.NET Core-Webanwendung erstellt, und die Anwendung wird im Ordner "/var " bereitgestellt. Die Anwendung wurde auch für die Überwachung von Port 5000 für HTTP-Anforderungen konfiguriert, und die HTTPS-Umleitung wurde entfernt.

An diesem Punkt sollten die Clients die Portnummer angeben, wenn Sie eine Verbindung mit der Anwendung herstellen (z. B http://localhost:5000. ). Dies ist jedoch nicht das gewünschte Verhalten.

Unsere Ziele in diesem Teil sind wie folgt:

  • Clients sollten in der Lage sein, zu navigieren, ohne eine Portnummer angeben zu müssen. Clients sollten z. B. eine Verbindung mithilfe von http://localhost.
  • Die Webanwendung sollte automatisch gestartet werden, wenn sie aus irgendeinem Grund oder nach dem Neustart des Computers beendet wird.

Im nächsten Abschnitt verwenden Sie Nginx als Proxyserver, um die HTTP-Anforderungen, die stattdessen an Port 80 an unsere .NET-Anwendung gesendet werden, weiterzuleiten. Außerdem konfigurieren Sie Ihre Anwendung so, dass sie automatisch gestartet wird.

Was ist nginx?

Nginx ist ein beliebter, einfacher und schneller Webserver. Sie kann sowohl unter Linux als auch unter Windows ausgeführt werden und kann als Reverseproxyserver konfiguriert werden.

Was ist ein Daemon?

Nginx wird als Daemon ausgeführt. Ein Daemon ist ein alternativer Begriff für einen Dienst, der im Hintergrund ausgeführt wird. Genau wie die Dienste, die unter Windows ausgeführt werden, können Daemons für den automatischen Start während des Starts konfiguriert werden. Sie konfigurieren Ihre ASP.NET Core-Anwendung so, dass sie als Daemon ausgeführt wird.

Installieren von Nginx mithilfe von APT

Die Installation von Nginx ist einfach. Führen Sie den sudo apt install nginx Befehl aus, um das Programm auf dem virtuellen Ubuntu-Computer zu installieren.

Screenshot des Befehls

Führen Sie nach Abschluss der Installation die Installation whereis nginx aus, um zu ermitteln, wo das Programm installiert ist. Sie können sehen, wo sich die Nginx-Konfigurationsdateien befinden, indem Sie die Ausgabe prüfen. Der folgende Screenshot zeigt, dass sich die Konfigurationsdateien im Ordner "/etc/nginx " befinden.

Screenshot des Befehls

Notiz

Wenn Sie eine andere Verteilung als Ubuntu oder Debian ausführen, finden Sie den entsprechenden Paket-Manager-Installationsbefehl oder Anweisungen aus der offiziellen Nginx-Installationsdokumentation.

Verwalten von Diensten mithilfe von systemctl

Wenn nicht angezeigt wird, dass Nginx ausgeführt wird, können Sie sie explizit starten, indem Sie sie ausführen sudo systemctl start nginx. Obwohl in dieser Übung die systemctl Befehle für Nginx veranschaulicht werden, werden diese Befehle verwendet, um die Webanwendung so zu konfigurieren, dass sie automatisch als Daemon gestartet wird.

Nach Abschluss der Installation ist Nginx bereits für den automatischen Start konfiguriert. Nginx wird als Daemon ausgeführt. Sie können den Status des Daemons mithilfe von systemctl überprüfen.

Der systemctl Befehl wird zum Verwalten von "Diensten" für aufgaben verwendet, z. B. das Anzeigen des Status des Diensts oder das Starten und Beenden des Diensts. Einige verfügbare Parameter sind Start, Stopp, Neustart, Aktivieren, Deaktivieren und Status. Führen Sie zum Überprüfen des Status von Nginx aus systemctl status nginx.

Screenshot des Befehls

Dieser Befehl generiert einige nützliche Informationen. Wie dieser Screenshot zeigt, befindet sich Nginx im active (running) Status, und die Prozess-ID der Nginx-Instanz ist 8539. Beachten Sie auch die enabled und vendor preset: enabled Anweisungen. Enabled bedeutet, dass dieser Daemon gestartet wird, wenn der Computer neu gestartet wird, und vendor preset: enabled bedeutet, dass Nginx standardmäßig aktiviert ist, wenn er installiert wird. Daher wird Nginx automatisch gestartet, wenn der Server gestartet wird.

Testen der Nginx-Installation

Standardmäßig lauscht Nginx auf Port 80. Da sie ausgeführt wird, sollten Sie beim Durchsuchen von localhost auf die Hauptseite von Nginx zugreifen können. Wird curl verwendet, um Nginx durch Ausführen curl localhostzu testen. Der gelb hervorgehobene Text im folgenden Screenshot zeigt die Nginx-Standardwebseite. Daher wird Nginx ausgeführt:

Screenshot des Curl-Befehls.

Systemctl-Befehlsoptionen

Dienste oder Daemons können mithilfe des systemctl Befehls verwaltet werden. Das Starten, Beenden oder Vornehmen von Änderungen erfordert superuser-Zugriff. Daher müssen Sie das sudo Präfix diesen Befehlen hinzufügen.

Daemons neu starten

Möglicherweise müssen Sie die Daemons von Zeit zu Zeit neu starten. Führen Sie zum Neustarten eines Daemons aus sudo systemctl restart <daemon_name>. Um Nginx neu zu starten, führen Sie den Befehl sudo systemctl restart nginxaus. Stellen Sie sicher, dass Sie den Status von Nginx vor und nach dem Ausführen dieses Befehls überprüfen, um Änderungen an der Prozess-ID zu überwachen.

Beenden von Daemons

Führen Sie zum Beenden eines Daemons die Ausführung aus sudo systemctl stop <daemon_name>. Führen Sie zum Beenden von Nginx den sudo systemctl stop nginxStatus von Nginx aus, indem Sie es erneut ausführen systemctl status nginx . Diesmal wird der Dienst als inaktiv (inaktiv) angezeigt, aber trotzdem aktiviert. Dies bedeutet, dass der Dienst zwar nicht ausgeführt wird, aber automatisch gestartet wird, nachdem der Server neu gestartet wurde.

Screenshot des Befehls

Notiz

Der systemctl status Befehl zeigt auch mehrere Zeilen früherer Protokolleinträge für den Daemon an.

Nachdem Sie Nginx beendet haben, führen Sie den Vorgang erneut aus curl localhost .

Notiz

Die Verbindung wird verweigert, da an Port 80 nichts auf eingehenden Datenverkehr lauscht.

Screenshot vonBugAmb localhost.

Deaktivieren von Daemons

Das Deaktivieren eines Daemons unterscheidet sich vom Beenden eines Daemons. Ein deaktivierter Daemon kann ausgeführt werden, aber er wird nach dem Neustart des Servers nicht automatisch gestartet. Um den Nginx-Daemon zu deaktivieren, führen Sie sudo systemctl disable nginxden Status von Nginx aus, und überprüfen Sie dann den Status von Nginx.

Screenshot des Befehls

Dieser Screenshot zeigt, dass Nginx nicht ausgeführt wird und deaktiviert ist. Dies bedeutet, dass Nginx nach einem Neustart nicht automatisch gestartet wird.

Starten von Daemons

Führen Sie zum Starten eines Daemons aus sudo systemctl start <daemon_name>. Führen Sie zum Starten von Nginx den sudo systemctl start nginxStatus des Diensts aus, und überprüfen Sie dann erneut den Status des Diensts.

Screenshot des Startbefehls.

Dieser Screenshot zeigt, dass Nginx gestartet, aber noch deaktiviert ist. Obwohl der Dienst ausgeführt wird, wird Nginx nach einem Neustart nicht automatisch gestartet, da es sich um einen deaktivierten Dienst handelt.

Aktivieren von Daemons

Das Aktivieren eines Diensts bedeutet, dass er nach einem Neustart automatisch gestartet wird. Führen Sie sudo systemctl enable nginxzum Aktivieren von Nginx den Status von Nginx erneut aus, und überprüfen Sie dann erneut den Status von Nginx.

Screenshot des Befehls

Dieser Screenshot zeigt, dass Nginx ausgeführt wird und nach dem Neustart des Servers gestartet wird.

Konfigurieren von Nginx als Reverseproxy zum Weiterleiten der Anforderungen an Ihre ASP.NET Core-Anwendung

Nachdem Sie nun erfahren haben, wie Sie den Nginx-Dienst starten, beenden und neu starten, konfigurieren Sie Nginx als Reverseproxy, um die Anforderungen, die an Port 80 vorgenommen werden, an Ihre ASP.NET Core-Anwendung weiterzuleiten, die auf Port 5000 lauscht.

Dies ist die erforderliche Konfiguration. Einige der wichtigsten Teile sind hervorgehoben.

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;
    }
  }
}

Diese Konfiguration gibt Folgendes an:

  • Nginx überwacht Port 80 für alle Anforderungen (Direktive: listen 80).
  • Nginx leitet die Anforderungen an http://localhost:5000 (Direktive: proxy_pass http://localhost:5000)

Notiz

Die server_name _ Zeile im Code. Dies wird als Catch-All-Direktive verwendet. Weitere Informationen zu server_name finden Sie in der offiziellen Dokumentation.

Die Konfigurationsänderungen sind einfach. Wir verwenden diesen Code, um den server Direktivenabschnitt in der Konfigurationsdatei zu ersetzen. Aber wo befindet sich die Konfigurationsdatei?

Suchen der richtigen Nginx-Konfigurationsdatei

Die primäre Nginx-Konfigurationsdatei ist /etc/nginx/nginx.conf. Verwenden Sie den cat /etc/nginx/nginx.conf Befehl, und suchen Sie nach der Serverdirektive, um die Konfiguration zu überprüfen.

Screenshot des Cat-Befehls.

Scrollen Sie durch die Konfiguration, um die Serverdirektive zu finden. Sie sollten davon ausgehen, dass sie nicht gefunden werden. Wir können die gewünschten Konfigurationsänderungen an einer beliebigen Stelle in der Konfigurationsdatei platzieren. Im Idealfall möchten Sie die ursprüngliche Konfigurationsdatei jedoch nicht ersetzen. Dadurch wird verhindert, dass Konfigurationsfehler auftreten, die verhindern können, dass der Server ordnungsgemäß gestartet wird. Der server Abschnitt befindet sich nicht in der Hauptkonfigurationsdatei. Wenn Sie den Bildlauf durch die Konfigurationsdatei beibehalten, werden Sie feststellen, dass es einige include Direktiven gibt.

Screenshot des Befehls

Mithilfe von Direktiven können Sie die Konfiguration einfacher verwalten, indem Sie sie in Blöcke aufteilen, die in die Hauptkonfigurationsdatei eingeschlossen werden sollen. Die Hauptkonfigurationsdatei kann einfach gehalten werden, und einige bestimmte Konfigurationsteile können in andere Dateien verschoben werden. Die hervorgehobenen Zeilen in diesem Screenshot geben Folgendes an:

  • Nginx lädt die Konfiguration aus jeder CONF-Datei , die sich im Verzeichnis "/etc/nginx/conf.d " befindet.
  • Nginx lädt die Konfigurationen aus jeder Datei, die sich im Verzeichnis "/etc/nginx/sites-enabled " befindet.

Wenn Sie diese Verzeichnisse überprüfen, finden Sie keine Konfigurationsdateien in /etc/nginx/conf.d. Es gibt jedoch eine Datei in /etc/nginx/sites-enabled.

Screenshot des Befehls

Die Standardkonfigurationsdatei sieht wie ein Prime Candidate aus, um die gewünschte Konfiguration zu hosten. Wenn Sie die Datei "/etc/nginx/sites-enabled/default " verwenden cat /etc/nginx/sites-enabled/default, sehen Sie, dass die Standardserverdirektive im folgenden Code enthalten ist.

Screenshot der Standardinformationen.

Daher muss die Datei "/etc/nginx/sites-enabled/default " bearbeitet werden, um die Konfiguration zu ändern.

Bearbeiten der Konfigurationsdatei mithilfe von vi

Sie haben erfahren, wie Sie Dateien bearbeiten, wenn Sie die Startup.cs Datei bearbeitet haben, um die HTTPS-Umleitung aus der ASP.NET Pipeline zu entfernen. Jetzt verwenden Sie vi erneut, um die nginx-Konfigurationsdatei zu ändern.

Tipp

Sichern Sie immer die Dateien, die Sie ändern. Wenn nach der Bearbeitung ein Fehler auftritt, können Sie diese Kopie verwenden, um die Datei in den vorherigen Zustand wiederherzustellen. Führen Sie in diesem Fall aus cp /etc/nginx/sites-enabled/default ~/nginx-default-backup , um die Konfigurationsdatei in Ihr Startverzeichnis zu kopieren. Der Name der Sicherungsdatei lautet nginx-default-backup. Beachten Sie, dass die Sicherung nicht im selben Verzeichnis wie die Originaldatei erstellt wurde. Dies liegt daran, dass Nginx alle Konfigurationsdateien aus diesem Verzeichnis lädt und Sie die Konfiguration nicht unterbrechen möchten, indem Sie zwei verschiedene Versionen der Serverdirektive laden.

Führen Sie die Ausführung sudo vi /etc/nginx/sites-enabled/default aus, um die Konfigurationsdatei zu bearbeiten und die Serverdirektive zu ersetzen, wie im folgenden Screenshot gezeigt.

Screenshot des Befehls vi.

Hier sind einige Tipps und Tricks zum Bearbeiten von Dateien mithilfe von vi:

  • Sie können mit den Pfeiltasten nach oben und unten scrollen.
  • Um in den Bearbeitungsmodus zu gelangen, drücken Sie die EINFG - oder I-TASTE . Während Sie sich im Bearbeitungsmodus befinden, wird in der unteren linken Ecke eine Meldung "--INSERT" - angezeigt.
  • Im Bearbeitungsmodus können Sie die Tastatur verwenden, um Zeichen einzeln zu löschen.
  • Im Bearbeitungsmodus funktionieren Kopier- und Einfügevorgänge zusammen mit den meisten Terminals. Sie können also den Inhalt aus diesem Artikel kopieren und in vi einfügen.
  • Um den Bearbeitungsmodus zu beenden, drücken Sie ESC.
  • Sie können Linien im normalen Modus einfacher löschen. Wechseln Sie im normalen Modus zum Anfang einer Zeile, die Sie löschen möchten, und geben Sie "dd" ein. Der dd Befehl löscht die gesamte Zeile. Sie können auch 5dd eingeben, um fünf Zeilen gleichzeitig zu löschen. Diese Option sollte jedoch mit Vorsicht verwendet werden, um das Löschen zusätzlicher Inhalte zu vermeiden.
  • Wie man Zeilen in Vim / Vi Artikel löscht, ist ein guter Artikel , um zu erfahren, wie sie mehrere Zeilen in vi löschen.
  • Um vi zu beenden und die Änderungen zu speichern, geben Sie :wq! ein, und drücken Sie dann die EINGABETASTE. Hier bedeutet der Doppelpunkt (:), dass Sie einen Befehl ausführen, bedeutet, w dass sie die Änderungen schreiben, beenden q und ! bedeutet, die Änderungen außer Kraft zu setzen.
  • Um zu beenden, ohne die Änderungen zu speichern, geben Sie :q! ein, und drücken Sie dann die EINGABETASTE.

Die Änderungen werden jetzt gespeichert, und Sie müssen den Nginx-Dienst neu starten, damit diese Änderungen wirksam werden. Bevor Sie den Dienst neu starten, können Sie den sudo nginx -t Befehl ausführen, um die Konfigurationsdatei zu testen. Wenn dieser Befehl ausgeführt wird, überprüft Nginx die Konfigurationsdateisyntax und versucht dann, die Dateien zu öffnen, auf die in der Konfigurationsdatei verwiesen wird.

Screenshot des Befehls

Wie Sie hier sehen können, scheint die geänderte Konfigurationsdatei korrekt zu sein.

Wir müssen Nginx neu starten, damit die Änderungen wirksam werden:

sudo systemctl restart nginx

Nach dem Neustart erwarten Sie, dass eine Antwort der ASP.NET Core-Anwendung angezeigt wird, wenn Sie eine Anforderung an http://localhost senden, da Nginx als Reverseproxy für die Anforderungen funktionieren sollte, die an Port 80 vorgenommen werden.

Starten Sie den Nginx-Dienst neu, damit die Änderungen wirksam werden, und stellen Sie dann eine Anforderung an localhost durch Ausführen.curl localhost Dieser Befehl schlägt jedoch fehl. Der nächste Schritt besteht darin, auszuführen wget localhost, und dann nach einigen Hinweisen zur Quelle des Problems zu suchen.

Screenshot des wget-Befehls.

Problembehandlung des Nginx-Proxyproblems

Im vorherigen Screenshot sehen Sie diese Informationen:

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.

Die ersten und zweiten Zeilen geben an, dass Sie localhost auflösen und eine Verbindung mit dem 127.0.0.1:80 Socket herstellen können. Daher sollte Nginx ausgeführt werden. Um dies zu überprüfen, können Sie den systemctl status nginx Befehl ausführen.

Die dritte Zeile gibt die Quelle des Problems an. Sie erhalten eine Fehlermeldung "HTTP 502 Ungültiges Gateway" . HTTP 502 Ungültiges Gateway bezieht sich auf Proxys. Dies bedeutet, dass der Reverseproxy keine Verbindung mit der Back-End-Anwendung herstellen konnte. In diesem Fall ist es Ihre ASP.NET Core-Webanwendung, die ausgeführt und auf Port 5000 für die Anforderungen lauscht. Wir sollten überprüfen, ob auch die Webanwendung ausgeführt wird.

Führen Sie zum Starten der Problembehandlung denselben netstat Befehl wie zuvor aus. Verwenden Sie dieses Mal den Grep, um den Port 5000 Ihrer Anwendung zu filtern. Führen Sie dann netstat -tlp | grep 5000 aus.

Screenshot des Netstat-Befehls.

Diese Beispielausgabe gibt an, dass keine Überwachung auf Port 5000 erfolgt. Daher ist dies die Ursache der HTTP 502-Antwort , die von Nginx stammt, da ein Prozess, der auf Port 5000 lauscht, nicht gefunden werden kann.

Die Lösung besteht darin, Ihre ASP.NET Core-Anwendung zu starten. Bevor Sie fortfahren, können Sie jedoch einen anderen Ansatz zur Problembehandlung für dieses Problem überprüfen. Nicht jedes Problem ist so einfach zu beheben, wie einfach ein paar Zeilen Protokollinhalt zu betrachten und die Ursache zu finden. Manchmal müssen Sie tief in andere System- und Anwendungsprotokolle eintauchen.

Da Sie eng mit Nginx zusammenarbeiten, wenn Sie ASP.NET Core-Anwendungen in Linux einrichten, empfehlen wir Ihnen, zu erfahren, welche Art von Protokollen Nginx und das Betriebssystem zur Problembehandlung bereitstellt.

Überprüfen der Nginx-Protokolle

Wenn Sie erneut ausgeführt werden cat /etc/nginx/nginx.conf und dann nach dem logging settingsGesuchten suchen, sollten Sie Folgendes beachten.

Screenshot der Protokollinformationen.

Dies zeigt, dass Nginx zwei Arten von Protokollen hat: Access-Protokolle und Fehlerprotokolle. Diese werden im Verzeichnis /var/log/nginx/ gespeichert.

Zugriffsprotokolle ähneln IIS-Protokolldateien. Eine schnelle Überprüfung des Inhalts zeigt, dass sie dem folgenden Screenshot ähneln.

Screenshot des Zugriffsbefehls.

Access-Protokolle zeigen keine anderen Informationen als den HTTP 502-Antwortstatus an, den Sie bereits wussten. Sie können die Fehlerprotokolle auch überprüfen, indem Sie diese ausführen cat /var/log/nginx/error.log. Diese zeigen viel mehr über die Ursache des Problems.

Screenshot der Fehlerinformationen.

Die Hinweise sind klar: Nginx kann die Anforderung vom Client abrufen, kann aber keine Verbindung mit dem upstream Server herstellen http://127.0.0.1:5000 und mit der ASP.NET Core-Anwendung, die ausgeführt und auf diesen Port überwacht werden sollte.

Problemumgehung

Um dieses Problem zu umgehen, starten Sie Ihre ASP.NET Core-Anwendung manuell. Stellen Sie mithilfe einer zweiten Terminalsitzung eine Verbindung mit dem Server her, und führen Sie dann die ASP.NET Core-Anwendung wie zuvor aus.

Screenshot der Aspnet-Informationen.

Während Ihre ASP.NET Core-Anwendung ausgeführt wird, wechseln Sie zur anderen Terminalsitzung, und führen Sie denselben curl localhost Befehl aus. Jetzt können Sie auf Ihre ASP.NET Core-Anwendung zugreifen, die hinter Nginx ausgeführt wird. Der folgende Screenshot zeigt, dass Sie eine Anforderung an localhost gestellt haben, die Anforderung von Nginx verarbeitet und an die Back-End-Anwendung weitergeleitet wurde und Sie eine Antwort von Ihrer ASP.NET Core-Anwendung erhalten haben.

Screenshot des Curllocalhost-Befehls.

Sie haben jetzt Nginx so konfiguriert, dass sie sich als Reverseproxy für Ihre ASP.NET Core-Anwendung verhält, die unter Linux ausgeführt wird.

Wenn die ASP.NET Core-Anwendung jedoch nach einem Neustart nicht gestartet wird, was ist das Ergebnis? Was geschieht, wenn die Webanwendung abstürzt und erst gestartet wird, wenn Sie feststellen, dass sie nicht ausgeführt wird? Sollten Sie Ihre ASP.NET Core-Anwendung nach jedem Neustart des Prozessendes starten?

Nächste Schritte

Teil 2.3 – Konfigurieren der ASP.NET Core-Anwendung für den automatischen Start

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.