Teil 2.7 – Konfigurieren einer zweiten Website mithilfe des Hostnamens in Nginx

  • Artikel
  • 5 Minuten Lesedauer

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

In diesem Artikel wird erläutert, wie Sie eine zweite Website in Nginx mithilfe des Hostnamens konfigurieren und die Konfiguration testen.

Voraussetzungen

Für diesen Teil sollten Die folgenden Elemente eingerichtet sein:

  • Nginx wird automatisch ausgeführt und lauscht auf Anforderungen, die an Port 80 gesendet werden.
  • Nginx als Reverseproxy konfiguriert und routing all the incoming HTTP requests to the first ASP.NET Core application that's listening on port 5000 (you can use any ASP.NET Core application as a back-end application that's running on this port.)
  • Diese erste ASP.NET Core Anwendung, die so konfiguriert ist, dass sie immer ausgeführt wird (wenn der Prozess beendet oder der Server neu gestartet wird, sollte die ASP.NET Core Anwendung automatisch gestartet werden.)
  • Die lokale Linux-Firewall ist aktiviert und konfiguriert, um SSH- und HTTP-eingehenden Datenverkehr zuzulassen.
  • Ein zweites ASP.NET Core Anwendung, die für das Überwachen von Port 5001 konfiguriert ist (diese Anwendung sollte auch so konfiguriert sein, dass sie immer ausgeführt wird, und das Beispiel "QaAmb" ASP.NET Core Anwendung sollte als zweite Anwendung im Setup konfiguriert werden.)

Ziel dieses Teils

Derzeit ist eine Website in Nginx konfiguriert. Jede Anforderung, die am Port 80 nach Nginx eingeht, wird an diesen Standort weitergeleitet. Der Hostname spielt bei diesem Setup keine Rolle. Verwenden Sie entweder die IP-Adresse oder einen beliebigen Hostnamen, der in die IP-Adresse aufgelöst wird. Alle Anforderungen werden an die Standardwebsite weitergeleitet. Diese Standardwebsite fungiert als Reverseproxy und leitet Anforderungen an die erste ASP.NET Core Anwendung weiter, die port 5000 überwacht.

In diesem Teil des Lernprogramms erstellen Sie eine zweite Website in Nginx. Diese Website fungiert auch als Reverseproxy, und jede Anforderung mit einem bestimmten Hostnamen wird an die zweite ASP.NET Core Anwendung weitergeleitet, die an Port 5001 lauscht.

Sie konfigurieren die Website auch so, dass ein bestimmter Hostname überwacht wird. Am Ende gibt es zwei Websites, auf die zugegriffen werden kann und die die folgenden Hostnamen aufweisen:

  • First website: http://myfirstwebsite will be directing traffic to the first ASP.NET Core demo application.
  • Zweite Website: http://buggyamb leitet Datenverkehr an die zweite ASP.NET Core Beispielanwendung weiter.

Fügen Sie myfirstwebsite buggyamb der Hosts-Datei sowohl Die Client-Windows als auch Linux-Computer hinzu. Auf diese Weise können Sie diese URLs verwenden, um die neue Konfiguration zu testen.

Diese Hostnamen dienen nur zur Demonstration. Sie können auch andere Hostnamen verwenden, die Sie bevorzugen, solange Sie in den Übungen in diesem Teil konsistent die gleichen Hostnamen verwenden.

Konfigurieren eines zweiten Webs mithilfe eines Hostnamens in Nginx

Wenn Sie sich erinnern, ist eines der Verzeichnisse, in denen Nginx die Websitekonfigurationen lädt, /etc/nginx/sites-enabled/. Derzeit gibt es eine Standardkonfigurationsdatei. Die Datei ähnelt dem folgenden Screenshot.

Screenshot des Cat-Befehls.

Hinweis

Beachten Sie die hervorgehobenen Teile, da Sie diese ändern müssen:

  • server_name: Sie können hier den gewünschten Hostnamen festlegen. Derzeit ist dies auf den Wert _ konfiguriert. Dies bedeutet einen beliebigen Hostnamen.
  • proxy_pass: Dies ist tatsächlich ASP.NET Core Anwendung, die auf einer bestimmten URL ausgeführt und überwacht wird. Anforderungen werden an diese URL weitergeleitet.

Konfigurieren Sie die erste Website zum Überwachen des http://myfirstwebsite Hostheaders. Ändern Sie dazu die server_name Konfigurationsdatei "/etc/nginx/sites-enabled/default", wie im folgenden Screenshot dargestellt. Zur Erinnerung müssen Sie den Befehl verwenden, sudo vi /etc/nginx/sites-enabled/default um diese Datei zu bearbeiten.

Screenshot des Standardbefehls "Katze".

Erstellen Sie eine zweite Nginx-Konfigurationsdatei für die zweite Website. Verwenden Sie diese Datei als Vorlage, um eine Kopie dieser Datei im selben Konfigurationsverzeichnis zu erstellen. Benennen Sie die Datei buggyamb.config.

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Bearbeiten Sie die Konfigurationsdatei, indem Sie den sudo vi /etc/nginx/sites-enabled/buggyamb.config Befehl ausführen. Hier ist die endgültige Version der Datei /etc/nginx/sites-enabled/buggyamb.config.

Screenshot des Befehls "sudo".

Das resultierende Setup sollte zwei Konfigurationsdateien im Nginx-Standortkonfigurationsverzeichnis aufweisen: buggyamb.config und Standard. Sie müssen Nginx festlegen, um die Konfigurationsänderungen neu zu laden. Sie sollten jedoch zuerst die neue Konfiguration testen, um sicherzustellen, dass beim Vornehmen von Änderungen keine Fehler eingeführt wurden. Führen Sie den sudo nginx -t Befehl aus, und stellen Sie sicher, dass die Konfiguration korrekt ist. Führen Sie dann die Ausführung sudo nginx -s reload aus, um die Konfiguration neu zu laden und die neuen Änderungen einzugeben.

Screenshot des Befehls "sudo nginx".

Testen der neuen Konfiguration

Legen Sie die myfirstwebsite buggyamb Und-Hostnamen fest, um sie in die richtigen IP-Adressen aufzulösen. Wenn Sie über den Linux-Computer auf die Websites zugreifen, sollten diese Hostnamen in 127.0.0.1 und für die externen Clients aufgelöst werden, z. B. der Client Windows Computer. Die Hostnamen sollten in die öffentliche IP-Adresse Ihres virtuellen Linux-Computers aufgelöst werden. Sie können diese IP-Adresse aus dem Azure-Portal abrufen.

Hinweis

Die Hosts-Zuordnungen werden in der Datei "/etc/hosts" unter Linux und in der Datei "C:\WINDOWS\System32\drivers\etc\hosts" in Windows gespeichert.

Dies ist der Inhalt der Linux-Hosts-Datei.

Screenshot des Cathost-Befehls.

Sie können die Befehle und befehle curl myfirstwebsite curl buggyamb ausführen, um Anforderungen an jede der beiden Websites zu senden.

Hier sehen Sie die curl myfirstwebsite Ausgabe. Die Antwort scheint den HTML-Inhalt auf der Startseite der Demo ASP.NET Kernanwendung korrekt anzuzeigen, die ursprünglich bereitgestellt wurde und an Port 5000 lauscht.

Screenshot des ersten Curl-Webbefehls.

Und hier ist die curl buggyamb Ausgabe. Dadurch wird der HTML-Inhalt von der Startseite der Aufzählungsbeispielanwendung angezeigt, die auf Port 5001 ausgeführt wird.

Screenshot des Curl-Befehls "curl gifamb".

Sie sollten in der Lage sein, die gleichen URLs über den Clientcomputer mithilfe eines Browsers zu durchsuchen. Dies sollte auch funktionieren, wenn Sie die Hostdatei ordnungsgemäß konfigurieren. Dies wird angezeigt, wenn Sie von einem Browser aus navigieren, der http://buggaymb auf einem Windows Computer ausgeführt wird.

Screenshot der Willkommensseite.

Bis zu diesem Zeitpunkt haben Sie das folgende Setup:

  • Nginx hostet zwei Websites:

    • Die erste Website lauscht mithilfe des Hostheaders auf Anforderungen myfirstwebsite und leitet die Anforderungen an unsere Demo-ASP.NET Core-Anwendung weiter. Diese Anwendung überwacht Port 5000.
    • Die zweite Website lauscht mithilfe des Hostheaderwerts von auf eingehenden HTTP-Datenverkehr buggyamb und leitet die Anforderungen an die zweite ASP.NET Core Beispielanwendung weiter. Diese Anwendung überwacht Port 5001.

  • Beide ASP.NET Core Anwendungen werden als Dienste ausgeführt, die automatisch neu gestartet werden, wenn der Server neu gestartet wird, oder die Anwendungen reagieren nicht mehr.

  • Die lokale Linux-Firewall ist aktiviert und konfiguriert, um SSH- und HTTP-Datenverkehr zuzulassen.

Tipps zur Problembehandlung

Möglicherweise erhalten Sie http 502 – Fehler "Ungültiges Gateway", wenn Sie eine Website durchsuchen. "HTTP 502 – Ungültiges Gateway" bedeutet, dass Nginx nicht mit der Back-End-ASP.NET Core-Anwendung kommunizieren konnte. Dies tritt auf, wenn die Back-End-Anwendung nicht ausgeführt wird.

In diesem Fall:

  • Stellen Sie sicher, dass beide ASP.NET Core Anwendungen auf unterschiedlichen Ports lauschen. Einer sollte auf Port 5000 lauschen, während der andere port 5001 abhören sollte.
  • Stellen Sie sicher, dass beide ASP.NET Core Anwendungen so konfiguriert sind, dass sie automatisch gestartet werden.
  • Überprüfen Sie den Status der ASP.NET Core Anwendungsdienste, die die systemctl status Befehle verwenden. Wenn einer nicht ausgeführt wird, beheben Sie die Problembehandlung, indem Sie die Systemprotokolle durch Ausführen des journalctl Befehls untersuchen. Dient syslogIdentifier zum Filtern der Protokolle.
  • Stellt sicher, dass sowohl .NET Core 3.1 als auch .NET 5.0 installiert sind. Eine Website verwendet .NET Core 3.1, die andere .NET 5.0.

Nächste Schritte

Teil 3.1 – Vorbereiten der Problembehandlung