Teil 2.6: Ausführen von zwei ASP.NET Core Anwendungen gleichzeitig

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

In diesem Artikel wird erläutert, wie Sie zwei ASP.NET Core Anwendungen nebeneinander ausführen, verschiedene Ports überwachen und eingehende Anforderungen verarbeiten.

Voraussetzungen

Um diesen Teil des Lernprogramms abzuschließen, sollten Sie die folgenden Elemente eingerichtet haben:

• Installierte .NET Core 3.1- und .NET 5.0-SDKs.
• Nginx wird automatisch ausgeführt und lauscht auf Anforderungen, die an Port 80 gesendet werden.
• Nginx, das als Reverseproxy konfiguriert ist und alle Anforderungen an die ASP.NET Core-Anwendung weiterleitet (Überwachung auf Port 5000).
• Eine ASP.NET Core Anwendung, die ausgeführt und so konfiguriert wird, dass sie automatisch gestartet wird, nachdem der Server neu gestartet wurde oder nachdem der Prozess beendet wurde.
• Lokale Linux-Firewall, die aktiviert und so konfiguriert ist, dass SSH- und HTTP-Datenverkehr zulässig ist.
• Beispiel für ASP.NET Core Anwendung, die heruntergeladen und in das Verzeichnis /var/buggyamb_v1.1 extrahiert wird.

Die erste ASP.NET Core Demoanwendung, die in dieser Reihe verwendet wurde, ist eine ASP.NET Core 5.0-Anwendung. Die zweite Anwendung ist eine ASP.NET Core 3.1-Anwendung. Wenn Sie nicht sowohl .NET Core 3.1 als auch .NET 5.0 SDKs installiert haben, installieren Sie das fehlende SDKs, bevor Sie fortfahren.

Hinweis

Sie können die installierte Version von Laufzeiten und SDKs überprüfen, indem Sie den dotnet --info Befehl ausführen. Die .NET Core-Installation wurde in früheren Teilen dieser Reihe erläutert.

Ziel dieses Teils

Am Ende dieses Teils verfügen Sie über zwei ASP.NET Core Anwendungen, die nebeneinander ausgeführt werden, verschiedene Ports überwachen und eingehende Anforderungen verarbeiten.

Die meisten Aktionen, die Sie in diesem Teil ausführen werden, sind ähnlich: Erstellen Sie eine Dienstdatei für die zweite ASP.NET Core-Anwendung, damit sie gestartet werden kann, wenn der Server neu gestartet wird oder der Prozess beendet wird.

Zweite Anwendung ausführen

Führen Sie eine zweite Anwendung als Dienst aus, die der ersten ausgeführten Anwendung ähnelt. Bevor Sie die Dienstdatei erstellen, stellen Sie sicher, dass sie ordnungsgemäß ausgeführt wird.

Denken Sie daran, dass Sie in früheren Kapiteln angewiesen wurden, die Testdebugginganwendung in das Verzeichnis /var/buggyamb_v1.1/ zu kopieren und die Anwendung dann mithilfe des dotnet /var/buggyamb_v1.1/BuggyAmb.dll Befehls auszuführen. You may receive the following error message:

System.IO.IOException: Bindung an Adresse http://127.0.0.1:5000 nicht erfolgreich: Adresse wird bereits verwendet.

Gemäß dieser Nachricht verwendet ein anderer Prozess bereits Port 5000. Dies ist offensichtlich. Aber wie können Sie erfahren, welcher Prozess den Port verwendet? Führen Sie den sudo netstat -tulpn | grep 5000 Befehl aus. Im folgenden Screenshot ist die PID und der 12536 Prozessname dotnet . Sie werden wahrscheinlich sehen, dass Ihre Prozess-ID unterschiedlich ist:

Der nächste Schritt besteht darin, zu verstehen, welche ASP.NET Core Anwendung vom Dotnetprozess gehostet wird, der auf Port 5000 lauscht. Sie können den cat /proc/12536/cmdline Befehl ausführen, um ein Ergebnis zu erhalten, das dem folgenden Screenshot ähnelt.

Dies ist die erste ASP.NET Core Anwendung, die in dieser Reihe konfiguriert wurde. Sie lauscht an Port 5000. Daher kann unsere neue ASP.NET Core-Anwendung nicht auf demselben Port lauschen.

Hinweis

Sie haben hier etwas Neues gelernt. Es gibt ein Verzeichnis mit dem Namen /proc. Wenn Sie den Inhalt dieses Verzeichnisses auflisten, werden Verzeichnisse angezeigt, die für jede PID benannt sind, die in diesem Moment ausgeführt wird. Jeder Unterordner verfügt über mehrere Dateien, mit denen Sie Eigenschaften jedes Prozesses abrufen können, z. B. die Befehlszeile und Arbeitsspeicher- oder CPU-Informationen. Konzentrieren Sie sich vorerst nicht darauf, da wir dies beim Behandeln von Tools und Prozessen besprechen werden.

Die Lösung für das Portkonfliktproblem besteht nicht darin, die Ausführung der ersten Anwendung zu beenden. Da das Ziel darin besteht, beide Anwendungen gleichzeitig auszuführen, besteht die Lösung darin, die zweite ASP.NET Core Anwendung auf einem anderen Port auszuführen.

Konfigurieren der zweiten ASP.NET Core Anwendung zum Überwachen auf einem anderen Port

Es gibt verschiedene Möglichkeiten, dieses Ziel zu erreichen:

• Wird UseUrls() verwendet, um den Port in "Program.cs" festzulegen: Dies bedeutet, dass der Port in der Anwendung hartcodiert ist. Obwohl wir den Port aus einer Konfigurationsdatei lesen können, möchten Sie die Anwendung nicht ändern und erneut kompilieren. Daher konzentriert sich diese Schulung nicht auf diese Lösung.
• Befehlszeilenargumente: Verwenden Sie den --urls Parameter, wenn Sie die Anwendung ausführen.
• Umgebungsvariablen: Legen Sie die URL für das Überwachen der Verwendung einer Umgebungsvariablen fest. Verwenden Sie DOTNET_URLS dazu Variablennamen oder ASPNETCORE_URLS Umgebungsvariablennamen.

Sowohl Umgebungsvariablen als auch der Befehlszeilenargumentansatz sind optionen, die Sie berücksichtigen sollten. Versuchen Sie, die Option zu --urls testen, wie im folgenden Screenshot dargestellt.

Denken Sie daran, dass das Ziel darin besteht, die Anwendung als Dienst auszuführen. Dies erfordert, dass Sie über eine Dienstdatei verfügen, in der Sie Umgebungsvariablen festlegen können. Sie können den ausführbaren Befehl wie zuvor gezeigt festlegen oder Umgebungsvariablen festlegen. In den folgenden Beispielen werden Umgebungsvariablen verwendet, um die Anwendung so zu konfigurieren, dass sie einen alternativen Port überwacht.

Erstellen einer Diensteinheitsdatei für die zweite Anwendung

Sie verwenden die folgende Dienstdefinition in der Diensteinheitsdatei. Denken Sie daran, dass die zweite Anwendung im Verzeichnis /var/buggyamb_v1.1 ausgeführt wird.

Hinweis

Die Environment=ASPNETCORE_URLS=http://localhost:5001 Zeile deklariert eine Umgebungsvariable, die benannt ASPNETCORE_URLS ist, und weist unsere Anwendung an, Port 5001 zu überwachen:

[Unit]
Description=BuggyAmb is a really buggy application
 
[Service]
WorkingDirectory=/var/buggyamb_v1.1/
ExecStart=/usr/bin/dotnet /var/buggyamb_v1.1/BuggyAmb.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=buggyamb-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://localhost:5001
 
[Install]
WantedBy=multi-user.target

Der Name der Dienstdatei lautet "csvamb.service" und wird im Verzeichnis /etc/systemd/system/erstellt. Verwenden Sie wie zuvor den Vi-Editor, und führen Sie den sudo vi /etc/systemd/system/buggyamb.service Befehl aus, um die Dienstdefinitionsdatei zu erstellen. Kopieren Sie diese Konfiguration, fügen Sie sie ein, und speichern Sie sie. Beachten Sie erneut, wie Sie die ASPNETCORE_URLS Umgebungsvariable festlegen:

Jetzt haben Sie die Webanwendung ASP.NET Core so konfiguriert, dass sie als Daemon ausgeführt wird. Reicht dies aus, um das Ziel zu erreichen, das wir zu Beginn der Schulung angegeben haben? Aktivieren und starten Sie den Dienst, indem Sie die Befehle und die sudo systemctl enable buggyamb.service sudo systemctl start buggyamb.service Befehle ausführen. Überprüfen Sie dann den Dienststatus, indem Sie den Dienst systemctl status buggyamb.service ausführen, wie im folgenden Screenshot dargestellt.

Sie sind jetzt an der Stelle, an der Sie überprüfen können, ob die "MarbleAmb"-Anwendung wie erwartet funktioniert. Führen Sie den curl localhost:5001 Befehl aus, um die Willkommensseite von "GifAmb HTML" in der Konsole anzuzeigen, wie im folgenden Screenshot dargestellt.

Die Anwendung kann noch nicht vom Client getestet werden, da sie an Port 5001 lauscht. Dieser Port ist in den Firewalleinstellungen nicht zulässig. Da Nginx den Port nicht für das Internet verfügbar macht, können Sie Nginx so konfigurieren, dass port 80 überwacht wird, und den Datenverkehr an Aufzählungszeichen weiterleiten, wenn die eingehenden HTTP-Anforderungen mithilfe eines bestimmten Hostnamens erfolgen. Sie können z. B. die Hostnamen verwenden: http://buggyamb oder http://buggyweb . Sie können auch einen beliebigen anderen Hostnamen verwenden.

Derzeit ist das Ziel erreicht, dass die zweite ASP.NET Core-Anwendung parallel zur ersten Demoanwendung ausgeführt wird. Im nächsten Kapitel konfigurieren wir Nginx weiterhin, wie wir es in diesem Teil beschreiben.

Nächste Schritte

Teil 2.7 – Konfigurieren einer zweiten Website mit Hostname in Nginx