Partie 2.3 : Configurer l’application ASP.NET Core pour démarrer automatiquement

S’applique à : .NET Core 2.1, .NET Core 3.1, .NET 5

Cet article explique comment configurer l’application ASP.NET Core pour vous assurer que l’application démarre automatiquement après le redémarrage du serveur.

Prerequisites

Pour suivre les exercices de cette partie, vous devez disposer d’une application web ASP.NET Core installée et déployée dans Linux.

Vous devez également configurer le serveur web Nginx en tant que proxy inverse pour router les requêtes vers l’application back-end ASP.NET Core à partir du port 80.

Objectif de cette partie

Les parties précédentes de cette série ont montré comment configurer Nginx en tant que proxy inverse et comment résoudre une erreur de proxy HTTP 502. La cause du code de réponse HTTP 502 est que l’application principale ASP.NET Core n’était pas en cours d’exécution lorsque Nginx a essayé de transférer le trafic vers celui-ci.

Le problème a été résolu temporairement en exécutant manuellement votre application ASP.NET Core. Mais que se passe-t-il si l’application se bloque ? Ou le serveur doit être redémarré ? Le redémarrage manuel de l’application ASP.NET Core à chaque fois n’est pas une solution pratique. Par conséquent, dans cette section, vous allez configurer Linux pour démarrer votre application après qu’elle se bloque.

Jusqu’à présent, vous avez configuré Nginx et ASP.NET Core pour travailler ensemble. Nginx écoute sur le port 80 et route les requêtes vers l’application ASP.NET Core qui écoute sur le port 5000. Bien que Nginx démarre automatiquement, l’application ASP.NET Core doit être démarrée manuellement chaque fois que le serveur est redémarré. Sinon, l’application ASP.NET Core sort normalement ou se bloque.

Si vous exécutez le ASP.NET Core en ayant IIS en tant que proxy, IIS ASP.NET Core Module (ANCM) gère la gestion des processus, et le processus ASP.NET Core démarre automatiquement. Une autre option consiste à exécuter le ASP.NET Core en tant que service dans Windows afin que la fonctionnalité de démarrage automatique puisse être configurée dès que l’ordinateur démarre.

Créer un fichier de service pour votre application ASP.NET Core

Rappelez-vous que la systemctl commande est utilisée pour gérer les « services » ou « démons ». Un démon est un concept similaire à celui d’un service Windows. Un tel service peut être redémarré automatiquement au démarrage du système.

Qu’est-ce qu’un fichier de service ?

Dans Linux, il existe également des fichiers de configuration d’unité qui ont une extension .service » utilisée pour contrôler le comportement des démons lorsque le processus se ferme. Elles sont également appelées fichiers de service, fichiers unitaires et fichiers d’unité de service.

Ces fichiers de service se trouvent dans l’un des répertoires suivants :

• /usr/lib/systemd/ : stocke les fichiers de service pour les applications téléchargées
• /etc/systemd/system/ : stocke les fichiers de service créés par les administrateurs système

Inspectez le fichier de service Nginx. Il est installé via un gestionnaire de package. Son fichier de configuration doit se trouver dans le dossier /usr/lib/systemd/system/ . L’exécution de la systemctl status nginx commande affiche également l’emplacement du fichier de service.

C’est à quoi ressemble le fichier de service Nginx.

Exemple de fichier de service pour les applications ASP.NET Core

L’exemple de contenu de fichier d’unité suivant est extrait de Host ASP.NET Core sur Linux avec 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

Voici quelques aspects clés de ce contenu :

• WorkingDirectory est le répertoire dans lequel vous publiez votre application.
• ExecStart est la commande réelle qui démarre l’application.
• Restart=always est explicite. Ce processus est toujours démarré s’il s’arrête pour une raison quelconque, que ce soit manuellement ou en raison d’un incident.
• RestartSec=10 est également explicite. Une fois le processus arrêté, il est démarré après 10 secondes.
• SyslogIdentifier est important. Cela signifie « identificateur du journal système ». Les informations sur le démon sont consignées sous ce nom dans les journaux système. Vous pouvez également utiliser cet identificateur pour rechercher le PID de votre processus.
• User est l’utilisateur qui gère le service. Il doit exister dans le système et posséder la propriété appropriée des fichiers d’application.
• Vous pouvez définir n’importe quel nombre de variables d’environnement dans le fichier de service.

Note

L’utilisateur www-data est un utilisateur spécial dans le système. Vous pouvez utiliser ce compte. Vous allez créer un utilisateur pour la pratique des autorisations utilisateur dans Linux. Toutefois, il est recommandé d’utiliser www-data si vous ne souhaitez pas créer un autre utilisateur Linux.

Créer un fichier de service pour l’application ASP.NET Core

Vous allez utiliser vi pour créer et modifier le fichier de service. Votre fichier de service entre dans le dossier /etc/systemd/system/ . N’oubliez pas que, dans cette série, vous avez publié votre première application dans le dossier /var/firstwebapp/ . Par conséquent, WorkingDirectory doit pointer vers ce dossier.

Voici le fichier de configuration final :

[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

Exécutez sudo vi /etc/systemd/system/myfirstwebapp.service , collez la configuration finale et enregistrez le fichier.

Cette opération termine la configuration requise pour l’application web ASP.NET Core à exécuter en tant que démon.

Étant donné que l’application web est maintenant configurée en tant que service, vous pouvez vérifier son état en exécutant systemctl status myfirstwebapp.service. Comme vous pouvez le voir dans la capture d’écran suivante, l’application est désactivée (ne démarre pas automatiquement après un redémarrage du système), et elle n’est pas en cours d’exécution.

Pour démarrer le service, exécutez la sudo systemctl start myfirstwebapp.service commande, puis vérifiez à nouveau l’état. Cette fois, vous devez voir le service en cours d’exécution et un ID de processus doit être répertorié en regard de celui-ci. La sortie de commande affiche également les dernières lignes des journaux système pour le service nouvellement créé, et indique que le service écoute http://localhost:5000.

Si l’application web s’arrête de façon inattendue, elle démarre automatiquement après 10 secondes.

Il existe une dernière étape : le service est en cours d’exécution, mais n’est pas activé. « Activé » signifie qu’il démarre automatiquement une fois le serveur démarré. Il s’agit de la configuration finale souhaitée. Exécutez la commande suivante pour vous assurer que le service est activé :

sudo systemctl enable myfirstwebapp.service

Il s’agit d’un jalon pour votre application ASP.NET Core, car vous l’avez configurée pour démarrer automatiquement après un redémarrage du serveur ou une terminaison de processus.

Testez si ASP.NET’application Core redémarre automatiquement

Avant de passer à la partie suivante, assurez-vous que tout fonctionne comme prévu. La configuration actuelle est la suivante :

• Nginx s’exécute automatiquement et écoute les demandes envoyées sur le port 80.
• Nginx est configuré en tant que proxy inverse et il achemine les requêtes vers l’application ASP.NET Core. L’application écoute sur le port 5000.
• L’application ASP.NET Core est configurée pour démarrer automatiquement après le redémarrage du serveur ou si le processus s’arrête ou se bloque.

Par conséquent, chaque fois que le service ASP.NET Core s’arrête, il doit redémarrer en 10 secondes. Pour tester ce comportement, vous forcez le processus à arrêter. Vous pouvez vous attendre à ce qu’elle démarre à nouveau en 10 secondes.

Note

ID de processus actuel de l’application ASP.NET Core. L’ID de processus de la tentative indiquée ici était 5084 avant la mort du processus. Pour rechercher l’ID de processus de votre application ASP.net Core, exécutez la systemctl status myfirstwebapp.service commande.

Pour forcer l’arrêt du processus, exécutez la commande suivante :

sudo kill -9 <PID>

Note

9 voici le type de signal. Selon la commande de man signal, 9 est SIGKILL (signal de destruction). Vous pouvez ouvrir les pages d’aide à l’aide de la man commande « kill and signal » pour en savoir plus sur cette rubrique.

Exécutez la systemctl status myfirstwebapp.service commande immédiatement après la kill commande, attendez environ 10 secondes, puis réexécutez la même commande.

Dans cette capture d’écran, vous pouvez voir les informations suivantes :

• Avant d’être tué, le processus ASP.NET Core avait un ID de processus de 5084.
• L’état du service indique que le processus qui utilise PID 5084 a été tué et qu’il est à nouveau activé, car le redémarrage automatique est configuré.
• Quelques secondes plus tard, un nouveau processus (PID 5181) a été démarré.

Si vous essayez d’accéder au site à l’aide curl localhostde , vous devez voir que l’application ASP.NET Core répond toujours.

Prochaines étapes

Partie 2.3.1 - [Facultatif] Configurez l’application ASP.NET Core dans Linux pour démarrer automatiquement sous un autre utilisateur.