Partager via

Partie 2.6 - Exécuter deux applications ASP.NET Core en même temps

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

Cet article explique comment exécuter deux applications ASP.NET Core côte à côte, écouter sur différents ports et traiter les requêtes entrantes.

Prerequisites

Pour effectuer cette partie du didacticiel, vous devez avoir configuré les éléments suivants :

  • Les kits SDK .NET Core 3.1 et .NET 5.0 sont installés.
  • Nginx s’exécute automatiquement et écoute des requêtes envoyées sur le port 80.
  • Nginx configuré en tant que proxy inverse et routage de toutes les requêtes vers l’application ASP.NET Core (à l’écoute sur le port 5000.)
  • Une application ASP.NET Core en cours d’exécution et configurée pour démarrer automatiquement une fois le serveur redémarré ou après l’arrêt du processus.
  • Pare-feu local Linux activé et configuré pour autoriser le trafic SSH et HTTP.
  • Exemple d’application buggy ASP.NET Core téléchargée et extraite dans le répertoire /var/buggyamb_v1.1 .

La première application de démonstration ASP.NET Core utilisée dans cette série est une application ASP.NET Core 5.0. La deuxième application est une application ASP.NET Core 3.1. Si vous n’avez pas installé les kits SDK .NET Core 3.1 et .NET 5.0, installez-en un avant de continuer.

Note

Vous pouvez vérifier la version installée des runtimes et des kits SDK en exécutant la dotnet --info commande. L’installation de .NET Core a été abordée dans les parties précédentes de cette série.

Objectif de cette partie

À la fin de cette partie, vous disposez de deux applications ASP.NET Core qui s’exécutent côte à côte, d’écoute sur différents ports et de traitement des requêtes entrantes.

La plupart des actions que vous effectuerez dans cette partie seront similaires : créez un fichier de service pour la deuxième application ASP.NET Core afin qu’elle puisse démarrer chaque fois que le serveur est redémarré ou que le processus est arrêté.

Exécuter la deuxième application

Exécutez une deuxième application en tant que service similaire à la première application en cours d’exécution. Avant de créer le fichier de service, assurez-vous qu’il s’exécute correctement.

Rappelez-vous que, dans les chapitres précédents, vous avez été invité à copier l’application de débogage de test dans le répertoire /var/buggyamb_v1.1/ , puis à exécuter l’application à l’aide de la dotnet /var/buggyamb_v1.1/BuggyAmb.dll commande. Vous pouvez recevoir le message d’erreur suivant :

System.IO.IOException : Échec de la liaison à l’adresse http://127.0.0.1:5000: adresse déjà utilisée.

Capture d’écran du message d’erreur d’E/S.

Selon ce message, un autre processus utilise déjà le port 5000. C’est évident. Mais comment apprendre quel processus utilise le port ? En exécutant la sudo netstat -tulpn | grep 5000 commande. Dans la capture d’écran suivante, le PID est 12536 et le nom du processus est dotnet. Vous verrez probablement que votre ID de processus sera différent :

Capture d’écran de la commande sudo netstat.

L’étape suivante consiste à comprendre quelle application ASP.NET Core est hébergée par le processus dotnet qui écoute sur le port 5000. Vous pouvez exécuter la cat /proc/12536/cmdline commande pour obtenir un résultat semblable à la capture d’écran suivante.

Capture d’écran de la commande cat.

Il s’agit de la première application ASP.NET Core configurée dans cette série. Il écoute sur le port 5000. Par conséquent, notre nouvelle application buggy core ASP.NET Core ne peut pas écouter sur le même port.

Note

Vous avez appris quelque chose de nouveau ici. Il existe un répertoire nommé /proc. Si vous répertoriez le contenu de ce répertoire, vous verrez des répertoires nommés pour chaque PID en cours d’exécution. Chaque sous-dossier a plusieurs fichiers que vous pouvez utiliser pour obtenir des propriétés de chaque processus, telles que la ligne de commande et les informations de mémoire ou d’UC. Pour l’instant, ne vous concentrez pas sur cela, car nous allons le discuter lorsque nous aborderons les outils et les processus.

La solution au problème de conflit de port n’est pas d’arrêter l’exécution de la première application. Étant donné que l’objectif est d’exécuter les deux applications en même temps, la solution consiste en fait à exécuter la deuxième application ASP.NET Core sur un autre port.

Configurer la deuxième application ASP.NET Core pour écouter sur un autre port

Il existe différentes façons d’atteindre cet objectif :

  • Permet UseUrls() de définir le port dans Program.cs : cela signifie que le port est codé en dur dans l’application. Bien que nous puissions lire le port à partir d’un fichier de configuration, vous ne souhaitez pas modifier l’application et compiler à nouveau. Par conséquent, cette formation ne se concentre pas sur cette solution.
  • Arguments de ligne de commande : utilisez le --urls paramètre lorsque vous exécutez votre application.
  • Variables d’environnement : définissez l’URL permettant d’écouter pour utiliser une variable d’environnement. Utilisez ou utilisez DOTNET_URLS des ASPNETCORE_URLS noms de variables d’environnement pour y parvenir.

Les variables d’environnement et l’approche de l’argument de ligne de commande sont des options à prendre en compte. Essayez de tester l’option --urls , comme illustré dans la capture d’écran suivante.

Capture d’écran de la commande url dotnet.

N’oubliez pas que l’objectif est d’exécuter l’application en tant que service. Cela nécessite que vous disposiez d’un fichier de service dans lequel vous pouvez définir des variables d’environnement. Vous pouvez définir la commande exécutable comme indiqué précédemment, ou définir des variables d’environnement. Les exemples suivants utilisent des variables d’environnement pour configurer l’application pour écouter sur un autre port.

Créer un fichier d’unité de service pour la deuxième application

Vous allez utiliser la définition de service suivante dans votre fichier d’unité de service. N’oubliez pas que la deuxième application s’exécute dans le répertoire /var/buggyamb_v1.1 .

Note

La Environment=ASPNETCORE_URLS=http://localhost:5001 ligne déclare une variable d’environnement nommée ASPNETCORE_URLS et indique à notre application d’écouter sur le port 5001 :

[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

Le nom du fichier de service sera buggyamb.service et sera créé dans le répertoire /etc/systemd/system/ . Comme vous l’avez fait précédemment, utilisez l’éditeur vi et exécutez la sudo vi /etc/systemd/system/buggyamb.service commande pour créer le fichier de définition de service. Copiez et collez cette configuration, puis enregistrez-la. Là encore, notez comment vous définissez la variable d’environnement ASPNETCORE_URLS :

Capture d’écran de la commande sudo vi.

Vous avez maintenant configuré l’application web buggy ASP.NET Core pour qu’elle s’exécute en tant que démon. Est-ce suffisant pour atteindre l’objectif que nous avons déclaré au début de la formation ? Activez et démarrez le service en exécutant les commandes et sudo systemctl start buggyamb.service les sudo systemctl enable buggyamb.service commandes. Vérifiez ensuite l’état du service en exécutant systemctl status buggyamb.service, comme illustré dans la capture d’écran suivante.

Capture d’écran de la commande d’état systemctl.

Vous êtes à l’endroit où vous pouvez maintenant vérifier si l’application BuggyAmb fonctionne comme prévu. Exécutez la curl localhost:5001 commande pour afficher la page d’accueil du code HTML BuggyAmb dans la console, comme illustré dans la capture d’écran suivante.

Capture d’écran de la commande curl localhost.

L’application ne peut pas encore être testée à partir du client, car elle écoute sur le port 5001. Ce port n’est pas autorisé dans les paramètres de pare-feu. Étant donné que Nginx n’expose pas le port à Internet, vous pouvez configurer Nginx pour écouter sur le port 80 et router le trafic vers BuggyAmb lorsque les requêtes HTTP entrantes sont effectuées à l’aide d’un certain nom d’hôte. Par exemple, vous pouvez utiliser les noms d’hôte : http://buggyamb ou http://buggyweb. Vous pouvez également utiliser tout autre nom d’hôte souhaité.

Pour l’instant, l’objectif est d’avoir la deuxième application ASP.NET Core s’exécutant côte à côte avec la première application de démonstration. Dans le chapitre suivant, nous allons continuer à configurer Nginx comme nous le décrivons dans cette partie.

Prochaines étapes

Partie 2.7 - Configurer un deuxième site web avec le nom d’hôte dans Nginx