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

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

In diesem Artikel wird erläutert, wie zwei ASP.NET Core-Anwendungen nebeneinander ausgeführt werden, unterschiedliche Ports überwachen und eingehende Anforderungen verarbeiten.

Voraussetzungen

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

• Sowohl .NET Core 3.1 als auch .NET 5.0-SDKs sind installiert.
• Nginx wird automatisch ausgeführt und überwacht Anforderungen, die an Port 80 gesendet werden.
• Nginx ist als Reverseproxy konfiguriert und routingt alle Anforderungen an die ASP.NET Core-Anwendung (Überwachen von Port 5000.)
• Eine ASP.NET Core-Anwendung, die ausgeführt und so konfiguriert ist, dass sie automatisch gestartet wird, nachdem der Server neu gestartet wurde oder nachdem der Prozess beendet wurde.
• Lokale Linux-Firewall, die aktiviert und konfiguriert ist, um SSH- und HTTP-Datenverkehr zuzulassen.
• Beispiel-Bug-ASP.NET Core-Anwendung, die in das Verzeichnis "/var/buggyamb_v1.1 " heruntergeladen und 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, bevor Sie fortfahren.

Notiz

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 parallel ausgeführt werden, und überwachen verschiedene Ports und verarbeiten eingehende Anforderungen.

Die meisten Aktionen, die Sie in diesem Teil ausführen, 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.

Erinnern Sie sich daran, dass Sie in früheren Kapiteln angewiesen wurden, die Testdebugginganwendung in das Verzeichnis "/var/buggyamb_v1.1/ " zu kopieren und dann die Anwendung mit dem dotnet /var/buggyamb_v1.1/BuggyAmb.dll Befehl auszuführen. Sie erhalten ggf. eine Fehlermeldung der folgenden Art:

System.IO.IOException: Fehler beim Binden an die Adresse http://127.0.0.1:5000: Adresse, die bereits verwendet wird.

Pro dieser Nachricht verwendet ein anderer Prozess bereits Port 5000. Dies ist offensichtlich. Aber wie erfahren Sie, welcher Prozess den Port verwendet? Führen Sie den sudo netstat -tulpn | grep 5000 Befehl aus. Im folgenden Screenshot ist 12536 dotnetdie PID und der Prozessname . Wahrscheinlich sehen Sie, dass Ihre Prozess-ID anders ist:

Der nächste Schritt besteht darin, zu verstehen, welche ASP.NET Core-Anwendung vom Dotnet-Prozess 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. Es lauscht auf Port 5000. Daher kann unsere neue ASP.NET Core Kinderwagen-Anwendung nicht auf denselben Port hören.

Notiz

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 zu diesem Zeitpunkt ausgeführt wird. Jeder Unterordner verfügt über mehrere Dateien, die Sie verwenden können, um Eigenschaften jedes Prozesses abzurufen, z. B. die Befehlszeile und Arbeitsspeicher oder CPU-Informationen. Konzentrieren Sie sich jetzt nicht auf dies, da wir es besprechen werden, wenn wir Tools und Prozesse behandeln.

Die Lösung für das Portkonfliktproblem besteht nicht darin, die Ausführung der ersten Anwendung zu beenden. Da beide Anwendungen gleichzeitig ausgeführt werden sollen, 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 eines anderen Ports

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 die Überwachung einer Umgebungsvariable fest. Verwenden oder DOTNET_URLS ASPNETCORE_URLS Umgebungsvariablennamen, um dies zu erreichen.

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

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 auf einen alternativen Port lauscht.

Erstellen einer Diensteinheitsdatei für die zweite Anwendung

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

Notiz

Die Environment=ASPNETCORE_URLS=http://localhost:5001 Zeile deklariert eine Umgebungsvariable, die benannt ASPNETCORE_URLS ist, und teilt der Anwendung mit, dass sie auf Port 5001 lauschen soll:

[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 ist cartamb.service und wird im Verzeichnis /etc/systemd/system/ erstellt. Verwenden Sie genau 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 Und einfügen Sie diese Konfiguration, und speichern Sie sie. Beachten Sie erneut, wie Sie die ASPNETCORE_URLS Umgebungsvariable festlegen:

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

Sie befinden sich an dem Punkt, an dem Sie jetzt überprüfen können, ob die Bugamb-Anwendung wie erwartet funktioniert. Führen Sie den curl localhost:5001 Befehl aus, um die Willkommensseite vonBugAmb HTML in der Konsole anzuzeigen, wie im folgenden Screenshot gezeigt.

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

Bisher ist das Ziel erreicht, die zweite ASP.NET Core-Anwendung parallel zur ersten Demoanwendung auszuführen. Im nächsten Kapitel konfigurieren wir weiterhin Nginx, wie es in diesem Teil beschrieben wird.

Nächste Schritte

Teil 2.7 – Konfigurieren einer zweiten Website mit Hostnamen in Nginx