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

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

In diesem Artikel wird erläutert, wie Sie die ASP.NET Core-Anwendung konfigurieren, um sicherzustellen, dass die Anwendung nach dem Neustart des Servers automatisch gestartet wird.

Voraussetzungen

Um die Übungen in diesem Teil zu befolgen, müssen Sie eine ASP.NET Core-Webanwendung installiert und in Linux bereitgestellt haben.

Außerdem müssen Sie den Nginx-Webserver als Reverseproxy konfigurieren, um die Anforderungen an die Back-End-ASP.NET Core-Anwendung von Port 80 weiterzuleiten.

Ziel dieses Teils

In den vorherigen Teilen dieser Reihe wurde gezeigt, wie Nginx als Reverseproxy konfiguriert und wie ein HTTP 502-Proxyfehler behoben wird. Die Ursache des HTTP 502-Antwortcodes besteht darin, dass das Back-End-ASP.NET Core-Anwendung nicht ausgeführt wurde, als Nginx versucht hat, Datenverkehr an sie weiterzuleiten.

Das Problem wurde vorübergehend behoben, indem Sie Ihre ASP.NET Core-Anwendung manuell ausführen. Aber was geschieht, wenn die Anwendung abstürzt? Oder der Server muss neu gestartet werden? Manuelles Neustarten der ASP.NET Core-Anwendung jedes Mal, wenn keine praktische Lösung ist. Daher konfigurieren Sie in diesem Abschnitt Linux so, dass Ihre Anwendung nach dem Absturz gestartet wird.

Bisher haben Sie Nginx und ASP.NET Core für die Zusammenarbeit konfiguriert. Nginx überwacht Port 80 und leitet Anforderungen an die ASP.NET Core-Anwendung weiter, die auf Port 5000 lauscht. Obwohl Nginx automatisch gestartet wird, muss die ASP.NET Core-Anwendung bei jedem Neustart des Servers manuell gestartet werden. Andernfalls wird die ASP.NET Core-Anwendung ordnungsgemäß beendet oder abstürzt.

Wenn Sie den ASP.NET Core ausführen, indem Sie IIS als Proxy verwenden, verarbeitet das IIS ASP.NET Core Module (ANCM) die Prozessverwaltung, und der ASP.NET Core-Prozess wird automatisch gestartet. Eine weitere Option besteht darin, die ASP.NET Core als Dienst in Windows auszuführen, damit das Feature für den automatischen Start so konfiguriert werden kann, dass der Computer gestartet wird.

Erstellen einer Dienstdatei für Ihre ASP.NET Core-Anwendung

Denken Sie daran, dass der systemctl Befehl zum Verwalten der "Dienste" oder "Daemons" verwendet wird. Ein Daemon ist ein ähnliches Konzept wie ein Windows-Dienst. Ein solcher Dienst kann automatisch neu gestartet werden, wenn das System gestartet wird.

Was ist eine Dienstdatei?

Unter Linux gibt es auch Komponentenkonfigurationsdateien mit einer Erweiterung ".service", die verwendet wird, um das Verhalten von Daemons zu steuern, wenn der Prozess beendet wird. Diese werden auch als Dienstdateien, Einheitendateien und Diensteinheitsdateien bezeichnet.

Diese Dienstdateien befinden sich in einem der folgenden Verzeichnisse:

• /usr/lib/systemd/: Speichert Dienstdateien für heruntergeladene Anwendungen
• /etc/systemd/system/: Speichert Dienstdateien, die von Systemadministratoren erstellt werden

Überprüfen Sie die Nginx-Dienstdatei. Sie wird über einen Paket-Manager installiert. Die Konfigurationsdatei sollte sich im Ordner "/usr/lib/systemd/system/" befinden. Wenn Sie den systemctl status nginx Befehl ausführen, wird auch der Speicherort der Dienstdatei angezeigt.

So sieht die Nginx-Dienstdatei aus.

Beispieldienstdatei für ASP.NET Core-Anwendungen

Das folgende Beispiel für Komponentendateiinhalte stammt aus Host ASP.NET Core unter Linux mit Nginx:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Hier sind einige wichtige Aspekte dieses Inhalts:

• WorkingDirectory ist das Verzeichnis, in dem Sie Ihre Anwendung veröffentlichen.
• ExecStart ist der tatsächliche Befehl, der die Anwendung startet.
• Restart=always ist selbsterklärend. Dieser Vorgang wird immer gestartet, wenn er aus irgendeinem Grund beendet wird, unabhängig davon, ob manuell oder aufgrund eines Absturzes.
• RestartSec=10 ist auch selbsterklärend. Nachdem der Vorgang beendet wurde, wird er nach ablaufen 10 Sekunden gestartet.
• SyslogIdentifier ist wichtig. Dies bedeutet "Systemprotokollbezeichner". Informationen zum Daemon werden unter diesem Namen in den Systemprotokollen protokolliert. Sie können diesen Bezeichner auch verwenden, um die PID Ihres Prozesses zu finden.
• User ist der Benutzer, der den Dienst verwaltet. Es sollte im System vorhanden sein und über den entsprechenden Besitz der Anwendungsdateien verfügen.
• Sie können eine beliebige Anzahl von Umgebungsvariablen in der Dienstdatei festlegen.

Notiz

Der www-data Benutzer ist ein spezieller Benutzer im System. Sie können dieses Konto verwenden. Sie erstellen einen neuen Benutzer zum Üben von Benutzerberechtigungen in Linux. Es ist jedoch in Ordnung, zu verwenden www-data , wenn Sie keinen anderen Linux-Benutzer erstellen möchten.

Erstellen einer Dienstdatei für die ASP.NET Core-Anwendung

Sie verwenden vi die Dienstdatei zum Erstellen und Bearbeiten der Dienstdatei. Ihre Dienstdatei wird in den Ordner "/etc/systemd/system/" verschoben. Denken Sie daran, dass Sie in dieser Reihe Ihre erste Anwendung im Ordner "/var/firstwebapp/" veröffentlicht haben. Daher sollte WorkingDirectory auf diesen Ordner verweisen.

Hier ist die endgültige Konfigurationsdatei:

[Unit]
Description=My very first ASP.NET Core applications running on Ubuntu

[Service]
WorkingDirectory=/var/firstwebapp/
ExecStart=/usr/bin/dotnet /var/firstwebapp/AspNetCoreDemo.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=myfirstapp-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Führen Sie sudo vi /etc/systemd/system/myfirstwebapp.service aus, fügen Sie die endgültige Konfiguration ein, und speichern Sie die Datei.

Dadurch wird die erforderliche Konfiguration für die ASP.NET Core-Webanwendung abgeschlossen, die als Daemon ausgeführt werden soll.

Da die Webanwendung jetzt als Dienst konfiguriert ist, können Sie den Status überprüfen, indem Sie diese ausführen systemctl status myfirstwebapp.service. Wie Sie im folgenden Screenshot sehen können, ist die Anwendung deaktiviert (wird nach einem Systemneustart nicht automatisch gestartet), und sie wird derzeit nicht ausgeführt.

Um den Dienst zu starten, führen Sie den sudo systemctl start myfirstwebapp.service Befehl aus, und überprüfen Sie dann den Status erneut. Dieses Mal sollte der Dienst ausgeführt werden, und daneben sollte eine Prozess-ID aufgeführt werden. Die Befehlsausgabe zeigt außerdem die letzten Zeilen aus Systemprotokollen für den neu erstellten Dienst an und zeigt an, dass der Dienst überwacht http://localhost:5000wird.

Sollte die Webanwendung unerwartet beendet werden, wird sie nach 10 Sekunden automatisch erneut gestartet.

Es gibt einen letzten Schritt: Der Dienst wird ausgeführt, aber nicht aktiviert. "Aktiviert" bedeutet, dass sie automatisch gestartet wird, nachdem der Server gestartet wurde. Dies ist die gewünschte endgültige Konfiguration. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass der Dienst aktiviert ist:

sudo systemctl enable myfirstwebapp.service

Dies ist ein Meilenstein für Ihre ASP.NET Core-Anwendung, da Sie sie so konfiguriert haben, dass sie nach einem Serverneustart oder einer Prozessbeendigung automatisch gestartet wird.

Testen, ob ASP.NET Core-Anwendung automatisch neu gestartet wird

Bevor Sie zum nächsten Teil wechseln, stellen Sie sicher, dass alles wie erwartet funktioniert. Die aktuelle Konfiguration lautet wie folgt:

• Nginx wird automatisch ausgeführt und überwacht Anforderungen, die an Port 80 gesendet wurden.
• Nginx ist als Reverseproxy konfiguriert und leitet Anforderungen an die ASP.NET Core-Anwendung weiter. Die Anwendung überwacht Port 5000.
• Die ASP.NET Core-Anwendung ist so konfiguriert, dass sie nach dem Neustart des Servers automatisch gestartet wird oder wenn der Prozess beendet oder abstürzt.

Daher sollte der ASP.NET Core-Dienst in 10 Sekunden neu gestartet werden. Um dieses Verhalten zu testen, erzwingen Sie, dass der Prozess beendet wird. Sie können davon ausgehen, dass sie in 10 Sekunden erneut gestartet wird.

Notiz

Die aktuelle Prozess-ID der ASP.NET Core-Anwendung. Die Prozess-ID für den hier gezeigten Versuch war 5084 , bevor der Prozess beendet wurde. Um die Prozess-ID für Ihre ASP.net Core-Anwendung zu finden, führen Sie den systemctl status myfirstwebapp.service Befehl aus.

Führen Sie den folgenden Befehl aus, um zu erzwingen, dass der Prozess beendet wird:

sudo kill -9 <PID>

Notiz

9 hier ist der Signaltyp. man Laut Signalbefehl 9 ist SIGKILL (Kill Signal). Sie können die Hilfeseiten öffnen, indem Sie den man Befehl für "Kill and signal" verwenden, um mehr über dieses Thema zu erfahren.

Führen Sie den systemctl status myfirstwebapp.service Befehl unmittelbar nach dem kill Befehl aus, warten Sie etwa 10 Sekunden, und führen Sie dann denselben Befehl erneut aus.

In diesem Screenshot können Sie die folgenden Informationen sehen:

• Bevor es getötet wurde, hatte der ASP.NET Core-Prozess eine Prozess-ID von 5084.
• Der Dienststatus weist darauf hin, dass der Prozess, der PID 5084 verwendet, getötet wurde und erneut aktiviert wird, da der automatische Neustart konfiguriert ist.
• Ein paar Sekunden später wurde ein neuer Prozess (PID 5181) gestartet.

Wenn Sie versuchen, mithilfe der Verwendung auf die Website curl localhostzuzugreifen, sollten Sie sehen, dass die ASP.NET Core-Anwendung weiterhin reagiert.

Nächste Schritte

Teil 2.3.1 - [Optional] Konfigurieren Sie die ASP.NET Core-Anwendung in Linux so, dass sie automatisch unter einem anderen Benutzer gestartet wird.