Partie 2.1 - Créer et configurer des applications ASP.NET Core dans Linux

S’applique à : .NET 8 et versions ultérieures

Cet article explique comment créer et configurer des applications ASP.NET Core dans Linux.

Prerequisites

Pour suivre les exercices de cette partie, vous devez avoir installé un Kit de développement logiciel (SDK) .NET. Pour installer le Kit de développement logiciel (SDK), reportez-vous aux instructions d’installation de la partie 1, si nécessaire.

Objectif de cette partie

Découvrez comment créer une application web ASP.NET Core à l’aide de l’interface de ligne de commande .NET (CLI) dans Linux et comment publier l’application dans le répertoire /var . À mesure que vous découvrez ces concepts, vous allez effectuer certaines tâches de base telles que l’utilisation de fichiers et de dossiers et l’exécution de commandes en tant qu’utilisateur privilégié. Vous allez également apprendre à modifier des fichiers à l’aide de l’éditeur de texte vi dans Linux.

CLI .NET

Selon cette documentation de l’interface CLI .NET, l’interface CLI .NET est une chaîne d’outils multiplateforme pour le développement, la génération, l’exécution et la publication d’applications .NET. L’interface CLI .NET est installée avec le Kit de développement logiciel (SDK) .NET.

Ces formations utilisent fréquemment la dotnet commande. Cette commande est puissante et a deux fonctions principales :

• Il fournit des commandes pour travailler sur des projets .NET. Par exemple, dotnet build génère un projet. Chaque commande définit ses propres options et arguments. Toutes les commandes prennent en charge l’option --help d’impression de brèves explications sur l’utilisation de la commande.
• Elle exécute des applications .NET.

Vous utiliserez la dotnet new commande pour créer votre premier projet ASP.NET Core dans Linux. Cette commande obtient le type du projet en tant qu’argument. Les types de projet sont expliqués dans ce document. Vous pouvez également afficher une liste de types en cours d’exécution dotnet new sans paramètre. Les types de projets liés au web sont mis en surbrillance en jaune dans la capture d’écran suivante.

Créer une application web ASP.NET Core à l’aide du Kit de développement logiciel (SDK)

Vous allez utiliser l’interface CLI .NET pour créer votre première application web à l’aide de la commande suivante :

dotnet new <template_type> -n <project_name> -o <output_directory>

Ces règles s’appliquent lorsque vous utilisez dotnet new:

• La commande crée les fichiers projet dans le répertoire de sortie. Si vous omettez le -o <output_directory> segment, le projet sera créé dans le répertoire actif. Vous pouvez toujours utiliser le -o commutateur.
• Si le dossier n’existe pas, la commande la crée.
• Si vous omettez le -n <project_name> segment, le nom du projet sera identique au nom du répertoire.

Vous êtes invité à trouver des noms créatifs pour le répertoire et le projet lui-même. Toutefois, gardez à l’esprit que Linux respecte la casse. Pour cet exercice, utilisez le nom de projet le plus conservateur AspNetCoreDemo et créez-le dans le firstwebapp répertoire.

Pour créer le projet, exécutez la commande suivante :

dotnet new webapp -n AspNetCoreDemo -o firstwebapp 

Examinez la sortie pour afficher les noms de répertoire et de projet. La capture d’écran suivante répertorie également le contenu du répertoire de sortie. Vous devez être familiarisé avec la structure de répertoires si vous avez créé une application web ASP.NET Core sur Windows avant.

Vous avez créé votre première application. La tâche suivante sera de l’exécuter. Remplacez le répertoire par le dossier du projet, puis exécutez dotnet run.

Note

Les éléments suivants de cette capture d’écran :

• Votre application web écoute le port 5001 pour les requêtes HTTPS et écoute sur le port 5000 pour les requêtes HTTP.
• La racine du contenu se trouve sous le répertoire de base.

Nous vous recommandons de ne pas exécuter l’application sous votre répertoire de base. Vous allez le publier dans un autre répertoire ultérieurement, mais vous devez le tester avant de le publier. Vous pouvez appuyer sur Ctrl+C pour arrêter l’application. Mais pour l’instant, continuez à l’exécuter et ouvrez une nouvelle session de terminal à l’aide de votre méthode préférée pour vous connecter à votre machine virtuelle Linux. Pour cet exemple, vous allez réutiliser PowerShell.

Tester le site web à partir d’un autre terminal

Dans votre nouvelle session de terminal, vérifiez que votre application écoute sur les ports 5000 et 5001. Linux a la même netstat commande que Windows. Exécutez-le netstat avec le -tlp commutateur. Vous pouvez vous familiariser avec les netstat commutateurs de cet article, ou vous pouvez consulter le fichier d’aide en exécutant man netstat ou info netstat.

Voici la sortie de la netstat -tlp commande à partir de la deuxième session de terminal. Il montre que le processus AspNetCoreDemo s’exécute à l’aide de PID 781 et écoute sur les ports 5000 et 5001 pour IPv4 et IPv6.

Vous pouvez utiliser curl et wget pour tester votre site web. Les deux commandes effectuent un appel HTTP côté cible, mais elles se comportent différemment :

• Curl est simplement un outil de navigateur en ligne de commande. Il effectue une requête HTTP à la cible donnée et affiche uniquement la sortie simple de la réponse HTTP. Par exemple, il affiche le balisage source HTML pour une application web.
• Wget est un téléchargeur HTTP. Il effectue une requête HTTP et télécharge la ressource donnée. Par exemple, wget http://server/file.zip télécharge file.zip depuis http://server et l’enregistre dans le répertoire actif.

La wget commande nous présente également des détails supplémentaires, tels que la redirection et les messages d’erreur que vous pouvez recevoir. Par conséquent, vous pouvez l’utiliser comme version primitive d’un outil de trace HTTP chaque fois que vous en avez besoin.

Pour plus d’informations sur la différence entre curl et wget, accédez à la page web StackExchange.

Dans cette série d’entraînement, vous avez précédemment utilisé wget pour télécharger le fichier du gestionnaire de package .deb à partir de serveurs Microsoft avant d’installer .NET.

Si vous exécutez curl http://localhost, rien ne se produit. Cela signifie probablement qu’il n’y a pas de réponse HTTP. Vous pouvez ensuite exécuter wget http://localhost pour vérifier si d’autres informations sont affichées lorsque vous essayez d’accéder au site.

Voici ce qui se produit maintenant :

• Vous effectuez une requête HTTP à http://localhost:5000, et vous vous connectez correctement. Cela signifie que l’application accepte les connexions sur le port 5000.
• Vous recevez une réponse de redirection temporaire HTTP 307 de l’application qui pointe vers un emplacement HTTPS sécurisé : https://localhost:5001.
• Wget est suffisamment intelligent pour suivre cette redirection et effectuer une nouvelle demande à https://localhost:5001.
• Vous vous connectez à nouveau. Toutefois, wget ne fait pas confiance au certificat SSL. Par conséquent, la connexion échoue.

La wget commande vous recommande de contourner ce problème à l’aide du --no-check-certificate commutateur pour vous connecter de manière non sécurisée. Toutefois, cette approche implique des paramètres de certificat SSL qui sont hors portée pour cette formation. Au lieu de cela, vous pouvez configurer votre application ASP.NET Core afin qu’elle ne redirige pas les requêtes HTTP vers HTTPS. Si vous connaissez ASP.NET développement d’applications core (ou simplement la configuration), modifiez le fichier Startup.cs pour supprimer la configuration de redirection.

Modifier des fichiers à l’aide de vi

Vous pouvez utiliser l’éditeur de texte vi pour les distributions Linux pour modifier tous les types de fichiers texte brut. Vous l’utiliserez dans cette formation pour reconfigurer votre application.

Vous devez fermer votre application avant de pouvoir la modifier. Fermez d’abord la session de terminal ouverte. Appuyez ensuite sur Ctrl+C pour arrêter l’application.

Pour modifier Startup.cs fichier, exécutez la commande suivante :

vi ~/firstwebapp/Startup.cs

Note

Cette commande démarre l’éditeur vi, puis charge le fichier. Le raccourci ~ (tilde) fait référence à votre répertoire de base où vous avez créé votre projet. Autrement dit, la commande pointe vers /home/<YourName>/firstwebapp/Startup.cs.

Appuyez sur la touche I (Insérer) pour activer le mode d’édition. Vous devez maintenant voir -- INSERT -- en bas de la ligne de commande. Utilisez les touches de direction pour naviguer dans le fichier. Commentez à la fois les app.UseHsTs()lignes ; et app.UseHttpsRedirection(); en les ajoutant // au début de celles-ci, comme illustré dans la capture d’écran suivante.

Appuyez sur échap pour quitter le mode édition, entrez :wq !, puis appuyez sur Entrée. Notez que le caractère deux-points (:) signifie que vous entrez une commande, w signifie écrire, q quitter et ! forcer l’écriture.

Une fois que vous appuyez sur Entrée, les modifications doivent être enregistrées. Vous pouvez vérifier les modifications en exécutant cat ~/firstwebapp/Startup.cs. Cette commande affiche le contenu du fichier Startup.cs .

Redémarrez votre application. Pour ce faire, remplacez le répertoire actif par le répertoire, puis réexécutez-le ~/firstwebappdotnet run . Ensuite, ouvrez une autre session de terminal sur votre serveur, puis réexécutez la curl http://localhost:5000 commande. Cette fois, la commande doit retourner le contenu HTML de la page d’accueil.

Vous avez maintenant exécuté votre première application web core ASP.NET sur Linux.

Déployer l’application dans le répertoire /var

L’objectif principal de cet exercice est d’héberger votre application web derrière un proxy inverse afin que les clients qui connectent les clients puissent accéder à l’application à partir d’un autre ordinateur en utilisant uniquement le nom d’hôte sans le numéro de port. C’est ce que vous prévoyez de faire dans des scénarios réels. Vous allez travailler avec Nginx plus tard pour effectuer cette tâche. Mais avant cela, publiez votre application dans le répertoire /var . Cela est dû au fait que nous vous recommandons de ne pas exécuter l’application dans le répertoire de base d’un utilisateur.

N’oubliez pas que le répertoire /var est utilisé pour stocker du contenu et des fichiers journaux par différentes applications telles qu’Apache et Nginx. Vous allez suivre cette pratique ici en publiant l’application web nouvellement créée sur /var.

Accédez au dossier du projet, puis exécutez-le dotnet publish pour créer un dossier de publication. Copiez ce dossier dans le répertoire /var .

La capture d’écran montre que la dotnet publish commande a créé des fichiers de publication dans le dossier ~/firstwebapp/bin/Debug/net5.0/publish/ . Ensuite, la commande suivante a été utilisée pour copier tous les fichiers dans le dossier /var/firstwebapp/ :

sudo cp -a ~/firstwebapp/bin/Debug/net5.0/publish/ /var/firstwebapp/

Note

Notez l’utilisation de sudo la commande de copie. Vous l’utilisez, car les utilisateurs standard n’ont pas l’autorisation d’écriture dans le répertoire /var . Par conséquent, vous devez exécuter la commande en tant que superutilisateur.

Pour exécuter votre application à partir d’un dossier publié, exécutez la commande suivante :

dotnet /var/firstwebapp/AspNetCoreDemo.dll

Si vous le souhaitez, vous pouvez exécuter ces tests à l’aide des mêmes curl commandes.wget Cela est dû au fait que l’application écoute toujours le port 5000 pour les requêtes HTTP.

Durée de vie du processus et étapes suivantes

Si l’application nécessite une durée de fonctionnement constante, l’exécution d’applications .NET au sein d’une session utilisateur interactive n’est pas une bonne pratique pour les raisons suivantes :

• Si les utilisateurs devaient mettre fin à leurs sessions, par exemple en fermant PuTTY ou le client SSH PowerShell ou en quittant la session, l’application s’arrêterait.
• Si le processus est arrêté pour une raison quelconque (par exemple, le processus se bloque en raison d’une exception non gérée), il ne démarre pas automatiquement et doit être redémarré manuellement.
• Si le serveur est redémarré, l’application ne démarre pas automatiquement.

Prochaines étapes

Partie 2.2 - Installer Nginx et le configurer en tant que serveur proxy inverse

Assurez-vous que l’application web démarre automatiquement. Installez et configurez Nginx en tant que proxy inverse pour acheminer les requêtes HTTP effectuées vers le port 80 vers l’application dotnet à la place (afin que les clients puissent se connecter sans avoir à fournir le numéro de port).

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.