Partager via

Partie 2.7 - Configurer un deuxième site web à l’aide du nom d’hôte dans Nginx

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

Cet article explique comment configurer un deuxième site web dans Nginx à l’aide du nom d’hôte et comment tester la configuration.

Prerequisites

Pour cette partie, vous devez configurer les éléments suivants :

  • Nginx s’exécute automatiquement et écoute des requêtes envoyées sur le port 80.
  • Nginx configuré comme proxy inverse et acheminant toutes les requêtes HTTP entrantes vers la première application ASP.NET Core qui écoute sur le port 5000 (vous pouvez utiliser n’importe quelle application ASP.NET Core en tant qu’application principale qui s’exécute sur ce port.)
  • Cette première application ASP.NET Core configurée pour toujours s’exécuter (si le processus s’arrête ou si le serveur est redémarré, l’application ASP.NET Core doit démarrer automatiquement.)
  • Le pare-feu local Linux activé et configuré pour autoriser le trafic entrant SSH et HTTP.
  • Une deuxième application ASP.NET Core configurée pour écouter le port 5001 (cette application doit également être configurée pour toujours s’exécuter, et l’exemple BuggyAmb ASP.NET’application Core doit être configuré comme deuxième application dans l’installation.)

Objectif de cette partie

Actuellement, il existe un site configuré dans Nginx. Toute demande qui arrive sur le port 80 vers Nginx est acheminée vers ce site. Le nom d’hôte n’a pas d’importance dans cette configuration. Utilisez l’adresse IP ou tout nom d’hôte qui se résout à l’adresse IP. Toutes les demandes sont acheminées vers le site web par défaut. Ce site web par défaut agit en tant que proxy inverse et achemine les requêtes vers la première application ASP.NET Core qui écoute sur le port 5000.

Dans cette partie du tutoriel, vous allez créer un deuxième site web dans Nginx. Ce site web agit également en tant que proxy inverse, et toute demande qui a un nom d’hôte spécifique sera acheminée vers la deuxième application ASP.NET Core qui écoute sur le port 5001.

Vous allez également configurer le site web pour écouter un nom d’hôte spécifique. À la fin, il y aura deux sites accessibles et qui ont ces noms d’hôte :

  • Premier site web : http://myfirstwebsite dirigera le trafic vers la première application de démonstration ASP.NET Core.
  • Deuxième site web : http://buggyamb dirigera le trafic vers le deuxième exemple d’application buggy core ASP.NET Core.

Ajoutez et buggyamb accédez myfirstwebsite au fichier hosts de vos ordinateurs Windows et Linux clients. De cette façon, vous pouvez utiliser ces URL pour tester la nouvelle configuration.

Ces noms d’hôtes sont uniquement à des fins de démonstration. N’hésitez pas à utiliser tous les autres noms d’hôtes que vous préférez, tant que vous utilisez constamment les mêmes noms d’hôtes dans les exercices de cette partie.

Configurer un deuxième web à l’aide d’un nom d’hôte dans Nginx

Si vous vous souvenez, l’un des répertoires dans lesquels Nginx charge les configurations de site est /etc/nginx/sites-enabled/. Actuellement, il existe un fichier de configuration par défaut. Le fichier ressemble à la capture d’écran suivante.

Capture d’écran de la commande cat.

Note

Notez les parties en surbrillance, car vous devrez les modifier :

  • server_name: vous pouvez définir le nom d’hôte souhaité ici. Actuellement, il est configuré avec la valeur _. Cela signifie n’importe quel nom d’hôte.
  • proxy_pass: Il s’agit d’une application ASP.NET Core en cours d’exécution et d’écoute sur une URL donnée. Les demandes sont acheminées vers cette URL.

Configurez le premier site web pour écouter l’en-tête http://myfirstwebsitede l’hôte. Pour ce faire, modifiez le server_name fichier de configuration /etc/nginx/sites-enabled/default , comme illustré dans la capture d’écran suivante. En guise de rappel, vous devez utiliser la sudo vi /etc/nginx/sites-enabled/default commande pour modifier ce fichier.

Capture d’écran de la commande par défaut cat.

Créez un deuxième fichier de configuration Nginx pour le deuxième site web. Utilisez ce fichier comme modèle pour créer une copie de ce fichier dans le même répertoire de configuration. Nommez le fichier buggyamb.config.

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Modifiez le fichier de configuration en exécutant la sudo vi /etc/nginx/sites-enabled/buggyamb.config commande. Voici la version finale du fichier /etc/nginx/sites-enabled/buggyamb.config .

Capture d’écran de la commande sudo.

La configuration résultante doit avoir deux fichiers de configuration dans le répertoire de configuration du site Nginx : buggyamb.config et par défaut. Vous devez définir Nginx pour recharger les modifications de configuration. Toutefois, vous devez d’abord tester la nouvelle configuration pour vous assurer qu’aucune erreur n’a été introduite lorsque vous avez apporté des modifications. Exécutez la sudo nginx -t commande et vérifiez que la configuration est correcte. Ensuite, exécutez sudo nginx -s reload pour recharger la configuration et lire les nouvelles modifications.

Capture d’écran de la commande sudo nginx.

Tester la nouvelle configuration

Définissez les myfirstwebsite noms d’hôte et buggyamb les noms d’hôte à résoudre en adresses IP correctes. Lorsque vous accédez aux sites à partir de l’ordinateur Linux, ces noms d’hôte doivent être résolus sur 127.0.0.1 et pour les clients externes, tels que l’ordinateur Windows client. Les noms d’hôte doivent être résolus sur l’adresse IP publique de votre machine virtuelle Linux. Vous pouvez récupérer cette adresse IP à partir du Portail Azure.

Note

Les mappages hosts sont stockés dans le fichier /etc/hosts dans Linux et dans le fichier C :\WINDOWS\System32\drivers\etc\hosts dans Windows.

Il s’agit du contenu du fichier hosts Linux.

Capture d’écran de la commande hôte cat.

Vous pouvez exécuter les curl myfirstwebsite commandes et curl buggyamb les exécuter pour effectuer des requêtes sur chacun des deux sites.

Voici la curl myfirstwebsite sortie. La réponse semble afficher correctement le contenu HTML de la page d’accueil de la démonstration ASP.NET application principale qui a été initialement déployée et écoute sur le port 5000.

Capture d’écran de la première commande web curl.

Et voici la curl buggyamb sortie. Cela affiche le contenu HTML de la page d’accueil de l’exemple d’application BuggyAmb qui s’exécute sur le port 5001.

Capture d’écran de la commande curl buggyamb.

Vous devez pouvoir parcourir les mêmes URL à partir de l’ordinateur client à l’aide d’un navigateur. Cela doit également fonctionner si vous configurez correctement le fichier hosts. Il s’agit de ce qui s’affiche lorsque vous accédez à http://buggaymb partir d’un navigateur qui s’exécute sur un ordinateur Windows.

Capture d’écran de la page d’accueil.

Jusqu’à ce stade, vous disposez de la configuration suivante :

  • Nginx hébergeant deux sites web :

    • Le premier site web écoute les requêtes à l’aide de l’en-tête de l’hôte myfirstwebsite et route les requêtes vers notre application de démonstration ASP.NET Core. Cette application écoute le port 5000.
    • Le deuxième site web écoute le trafic HTTP entrant à l’aide de la valeur d’en-tête de buggyambl’hôte, et route les requêtes vers la deuxième application ASP.NET Exemple de bogue Core. Cette application écoute le port 5001.

  • Les deux applications ASP.NET Core s’exécutent en tant que services qui redémarrent automatiquement lorsque le serveur est redémarré, ou les applications cessent de répondre.

  • Le pare-feu local Linux est activé et configuré pour autoriser les trafics SSH et HTTP.

Conseils de dépannage

Vous pouvez recevoir une erreur HTTP 502 - Passerelle incorrecte lorsque vous parcourez un site. « HTTP 502 - Passerelle incorrecte » signifie que Nginx n’a pas pu communiquer avec l’application principale ASP.NET Core. Cela se produit si l’application principale n’est pas en cours d’exécution.

Dans ce cas :

  • Assurez-vous que les deux applications ASP.NET Core écoutent sur différents ports. L’un doit écouter sur le port 5000, tandis que l’autre doit écouter sur le port 5001.
  • Assurez-vous que les deux applications ASP.NET Core sont configurées pour démarrer automatiquement.
  • Vérifiez l’état des services d’application core ASP.NET qui utilisent les systemctl status commandes. Si l’un n’est pas en cours d’exécution, résolvez-le en examinant les journaux système en exécutant la journalctl commande. Permet syslogIdentifier de filtrer les journaux.
  • Vérifiez que .NET Core 3.1 et .NET 5.0 sont installés. Un site utilise .NET Core 3.1, l’autre utilise .NET 5.0.

Prochaines étapes

Partie 3.1 - Préparer la résolution des problèmes