Partager via

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

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

Cet article explique comment installer Nginx et le configurer en tant que serveur proxy inverse.

Prerequisites

Pour suivre les exercices de cette partie, vous devez disposer d’une application web ASP.NET Core créée et déployée dans le dossier /var .

Objectif de cette partie

Dans la partie précédente, vous avez créé une application web ASP.NET Core à l’aide de l’outil CLI .NET et l’application est déployée dans le dossier /var . L’application a également été configurée pour écouter sur le port 5000 pour les requêtes HTTP, et la redirection HTTPS a été supprimée.

À ce stade, les clients doivent fournir le numéro de port lorsque vous vous connectez à l’application (par exemple). http://localhost:5000 Toutefois, ce n’est pas le comportement souhaité.

Nos objectifs dans cette partie sont les suivants :

  • Les clients doivent pouvoir naviguer sans avoir à fournir un numéro de port. Par exemple, les clients doivent se connecter à l’aide http://localhostde .
  • L’application web doit démarrer automatiquement s’il s’arrête pour une raison quelconque ou après le redémarrage de l’ordinateur.

Dans la section suivante, vous allez utiliser Nginx comme serveur proxy pour router les requêtes HTTP effectuées vers le port 80 vers notre application .NET à la place. Vous allez également configurer votre application pour démarrer automatiquement.

Présentation de Nginx

Nginx est un serveur web populaire, léger et rapide. Il peut s’exécuter sur Linux et Windows, et il peut être configuré en tant que serveur proxy inverse.

Qu’est-ce qu’un démon ?

Nginx s’exécute en tant que démon. Un démon est un terme alternatif pour un service qui s’exécute en arrière-plan. Tout comme les services qui s’exécutent sur Windows, les démons peuvent être configurés pour démarrer automatiquement au démarrage. Vous allez configurer votre application ASP.NET Core pour qu’elle s’exécute en tant que démon.

Installer Nginx à l’aide d’APT

L’installation de Nginx est simple. Exécutez la sudo apt install nginx commande pour installer le programme sur la machine virtuelle Ubuntu.

Capture d’écran de la commande sudo.

Une fois l’installation terminée, exécutez whereis nginx pour découvrir où le programme est installé. Vous pouvez voir où se trouvent les fichiers de configuration Nginx en inspectant la sortie. La capture d’écran suivante montre que les fichiers de configuration se trouvent dans le dossier /etc/nginx .

Capture d’écran de la commande whereis.

Note

Si vous exécutez une distribution autre que Ubuntu ou Debian, vous trouverez la commande d’installation du gestionnaire de package équivalente ou des instructions dans la documentation officielle de l’installation de Nginx.

Gérer les services à l’aide de systemctl

Si vous ne voyez pas que Nginx est en cours d’exécution, vous pouvez le démarrer explicitement en exécutant sudo systemctl start nginx. Bien que cet exercice illustre les systemctl commandes pour Nginx, ces commandes sont utilisées pour configurer l’application web pour démarrer automatiquement en tant que démon.

Une fois l’installation terminée, Nginx est déjà configuré pour démarrer automatiquement. Nginx s’exécute en tant que démon. Vous pouvez vérifier l’état du démon à l’aide de systemctl.

La systemctl commande est utilisée pour gérer les « services » pour des tâches telles que l’affichage de l’état du service, ou le démarrage et l’arrêt. Certains paramètres disponibles sont démarrer, arrêter, redémarrer, activer, désactiver et état. Pour vérifier l’état de Nginx, exécutez systemctl status nginx.

Capture d’écran de la commande systemctl.

Cette commande génère des informations utiles. Comme le montre cette capture d’écran, Nginx est en active (running) état et l’ID de processus de l’instance Nginx est 8539. Notez également les instructions et vendor preset: enabled les enabled instructions. Enabled signifie que ce démon démarre lorsque l’ordinateur est redémarré, et vendor preset: enabled signifie que Nginx est activé par défaut lorsqu’il est installé. Par conséquent, Nginx démarre automatiquement lorsque le serveur est démarré.

Tester l’installation de Nginx

Par défaut, Nginx écoute sur le port 80. Comme il est en cours d’exécution, vous devez être en mesure d’accéder à la page principale de Nginx lorsque vous parcourez localhost. Permet curl de tester Nginx en exécutant curl localhost. Le texte en surbrillance jaune dans la capture d’écran suivante montre la page web Nginx par défaut. Par conséquent, Nginx est en cours d’exécution :

Capture d’écran de la commande curl.

options de commande systemctl

Les services ou démons peuvent être gérés à l’aide de la systemctl commande. Le démarrage, l’arrêt ou l’application de modifications nécessitent un accès superutilisateur. Par conséquent, vous devez ajouter le sudo préfixe à ces commandes.

Redémarrer les démons

Vous devrez peut-être redémarrer les démons de temps à autre. Pour redémarrer un démon, exécutez sudo systemctl restart <daemon_name>. Pour redémarrer Nginx, exécutez sudo systemctl restart nginx. Veillez à vérifier l’état de Nginx avant et après avoir exécuté cette commande pour surveiller les modifications apportées à l’ID de processus.

Arrêter les démons

Pour arrêter un démon, exécutez sudo systemctl stop <daemon_name>. Pour arrêter Nginx, exécutez sudo systemctl stop nginx, puis vérifiez l’état de Nginx en réexécutant systemctl status nginx . Cette fois, le service est affiché comme inactif (mort) mais toujours activé. Cela signifie que même si le service n’est pas en cours d’exécution, il démarre automatiquement une fois le serveur redémarré.

Capture d’écran de la commande Stop.

Note

La systemctl status commande affiche également plusieurs lignes d’entrées de journal précédentes pour le démon.

Après avoir arrêté Nginx, réexécutez curl localhost .

Note

La connexion est refusée, car rien n’écoute le trafic entrant sur le port 80.

Capture d’écran de BuggyAmb localhost.

Désactiver les démons

La désactivation d’un démon est différente de l’arrêt d’un démon. Un démon désactivé peut être en cours d’exécution, mais il ne démarre pas automatiquement une fois le serveur redémarré. Pour désactiver le démon Nginx, exécutez sudo systemctl disable nginx, puis vérifiez l’état de Nginx.

Capture d’écran de la commande disable.

Cette capture d’écran montre que Nginx n’est pas en cours d’exécution et qu’il est désactivé. Cela signifie que Nginx ne démarre pas automatiquement après un redémarrage.

Démons de démarrage

Pour démarrer un démon, exécutez sudo systemctl start <daemon_name>. Pour démarrer Nginx, exécutez sudo systemctl start nginxà nouveau l’état du service, puis vérifiez à nouveau l’état du service.

Capture d’écran de la commande démarrer.

Cette capture d’écran montre que Nginx est démarré mais est toujours désactivé. Bien que le service s’exécute, Nginx ne démarre pas automatiquement après un redémarrage, car il s’agit d’un service désactivé.

Activer les démons

L’activation d’un service signifie qu’il démarre automatiquement après un redémarrage. Pour activer Nginx, exécutez sudo systemctl enable nginx, puis vérifiez à nouveau l’état de Nginx.

Capture d’écran de la commande Enable.

Cette capture d’écran montre que Nginx est en cours d’exécution et qu’il sera démarré une fois le serveur redémarré.

Configurer Nginx en tant que proxy inverse pour acheminer les requêtes vers votre application ASP.NET Core

Maintenant que vous avez appris à démarrer, arrêter et redémarrer le service Nginx, vous allez ensuite configurer Nginx en tant que proxy inverse pour acheminer les demandes effectuées sur le port 80 vers votre application ASP.NET Core qui écoute sur le port 5000.

Voici la configuration requise. Certaines des parties clés sont mises en surbrillance.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Cette configuration indique les éléments suivants :

  • Nginx écoute sur le port 80 pour toutes les demandes (directive : listen 80).
  • Nginx acheminera les requêtes vers http://localhost:5000 (directive : proxy_pass http://localhost:5000)

Note

Ligne server_name _ dans le code. Il s’agit d’une directive catch-all. Si vous souhaitez en savoir plus sur server_name, reportez-vous à la documentation officielle.

Les modifications de configuration apparaissent simples. Nous allons utiliser ce code pour remplacer la server section directive dans le fichier de configuration. Mais où est le fichier de configuration ?

Rechercher le fichier de configuration Nginx correct

Le fichier de configuration Nginx principal est /etc/nginx/nginx.conf. Pour inspecter la configuration, utilisez la cat /etc/nginx/nginx.conf commande et recherchez la directive serveur.

Capture d’écran de la commande cat.

Faites défiler la configuration pour localiser la directive du serveur. Vous devriez vous attendre à ne pas le trouver. Nous pouvons placer les modifications de configuration souhaitées quelque part dans le fichier de configuration. Toutefois, dans l’idéal, vous ne souhaitez pas remplacer le fichier de configuration d’origine. Cela permet d’empêcher l’introduction d’erreurs de configuration susceptibles d’empêcher le démarrage correct du serveur. La server section ne se trouve pas dans le fichier de configuration principal. Si vous continuez à faire défiler le fichier de configuration, vous découvrirez qu’il existe certaines include directives.

Capture d’écran de la commande Include.

Les directives Include facilitent la gestion de la configuration en le fractionnant en blocs à inclure dans le fichier de configuration principal. Le fichier de configuration principal peut être simple et certains composants de configuration spécifiques peuvent être déplacés vers d’autres fichiers. Les lignes mises en surbrillance de cette capture d’écran indiquent les éléments suivants :

  • Nginx charge la configuration à partir de chaque fichier .conf situé dans le répertoire /etc/nginx/conf.d .
  • Nginx charge les configurations de chaque fichier situé dans le répertoire /etc/nginx/sites.

Si vous inspectez ces répertoires, vous ne trouverez aucun fichier de configuration dans /etc/nginx/conf.d. Toutefois, un fichier est activé dans /etc/nginx/sites.

Capture d’écran de la commande conf.

Le fichier de configuration par défaut ressemble à un candidat principal pour héberger la configuration que nous recherchons. Si vous inspectez le fichier /etc/nginx/sites-enabled/default à l’aide cat /etc/nginx/sites-enabled/defaultde , vous verrez que la directive de serveur par défaut est placée dans le code suivant.

Capture d’écran des informations par défaut.

Par conséquent, le fichier /etc/nginx/sites-enabled/default doit être modifié pour modifier la configuration.

Modifier le fichier de configuration à l’aide de vi

Vous avez appris à modifier des fichiers lorsque vous avez modifié le fichier Startup.cs pour supprimer la redirection HTTPS du pipeline ASP.NET. À présent, vous allez utiliser vi à nouveau pour modifier le fichier de configuration nginx.

Conseil

Sauvegardez toujours les fichiers que vous modifiez. Si un problème se produit après modification, vous pouvez utiliser cette copie pour restaurer le fichier à son état précédent. Dans ce cas, exécutez cp /etc/nginx/sites-enabled/default ~/nginx-default-backup pour copier le fichier de configuration dans votre répertoire de base. Le nom du fichier de sauvegarde sera nginx-default-backup. Notez que la sauvegarde n’a pas été effectuée dans le même répertoire que le fichier d’origine. Cela est dû au fait que Nginx charge tous les fichiers de configuration à partir de ce répertoire et que vous ne souhaitez pas interrompre la configuration en chargeant deux versions différentes de la directive serveur.

Exécutez sudo vi /etc/nginx/sites-enabled/default pour modifier le fichier de configuration et remplacer la directive du serveur, comme illustré dans la capture d’écran suivante.

Capture d’écran de la commande vi.

Voici quelques conseils et astuces pour modifier des fichiers à l’aide de vi :

  • Vous pouvez faire défiler vers le haut et le bas à l’aide des touches de direction.
  • Pour entrer en mode édition, appuyez sur la touche Insertion ou I . Pendant que vous êtes en mode édition, il y aura un message --INSERT-- dans le coin inférieur gauche.
  • En mode édition, vous pouvez utiliser le clavier pour supprimer des caractères un par un.
  • En mode édition, les opérations de copie et de collage fonctionnent avec la plupart des terminaux. Vous pouvez donc copier le contenu de cet article et le coller dans vi.
  • Pour quitter le mode édition, appuyez sur Échap.
  • Vous pouvez supprimer des lignes plus facilement en mode normal. En mode normal, accédez au début d’une ligne que vous souhaitez supprimer, puis entrez dd. La dd commande supprime toute la ligne. Vous pouvez également taper 5dd pour supprimer cinq lignes à la fois. Toutefois, cette option doit être utilisée avec précaution pour éviter de supprimer du contenu supplémentaire.
  • Comment supprimer des lignes dans Vim / Vi est un bon article Pour savoir comment supprimer plusieurs lignes dans vi.
  • Pour quitter vi et enregistrer les modifications, entrez :wq !, puis appuyez sur Entrée. Ici, le signe deux-points (:) signifie que vous exécutez une commande, w signifie écrire les modifications, q signifie quitter et ! remplacer les modifications.
  • Pour quitter sans enregistrer les modifications, entrez :q !, puis appuyez sur Entrée.

Les modifications sont désormais enregistrées et vous devez redémarrer le service Nginx pour que ces modifications prennent effet. Avant de redémarrer le service, vous pouvez exécuter la sudo nginx -t commande pour tester le fichier de configuration. Lorsque cette commande s’exécute, Nginx vérifie la syntaxe du fichier de configuration, puis tente d’ouvrir les fichiers référencés dans le fichier de configuration.

Capture d’écran de la commande t.

Comme vous pouvez le voir ici, le fichier de configuration modifié semble correct.

Nous devons redémarrer Nginx afin que les modifications prennent effet :

sudo systemctl restart nginx

Après le redémarrage, vous vous attendez à voir une réponse de l’application ASP.NET Core lorsque vous effectuez une requête à http://localhost , car Nginx doit fonctionner comme proxy inverse pour les demandes effectuées au port 80.

Redémarrez le service Nginx pour que les modifications prennent effet, puis effectuez une demande à localhost en exécutant curl localhost. Toutefois, cette commande échoue. L’étape suivante consiste à exécuter wget localhost, puis à rechercher des indications sur la source du problème.

Capture d’écran de la commande wget.

Résoudre le problème de proxy Nginx

Dans la capture d’écran précédente, vous voyez ces informations :

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

Les premières et deuxième lignes indiquent que vous êtes en mesure de résoudre localhost et de se connecter sur le 127.0.0.1:80 socket. Par conséquent, Nginx doit être en cours d’exécution. Pour vérifier cela, vous pouvez exécuter la systemctl status nginx commande.

La troisième ligne indique la source du problème. Vous recevez un message d’erreur http 502 de passerelle incorrecte. La passerelle http 502 incorrecte est liée aux proxys. Cela signifie que le proxy inverse n’a pas pu se connecter à l’application principale. Dans ce cas, il s’agit de votre application web ASP.NET Core qui doit être en cours d’exécution et à l’écoute sur le port 5000 pour les requêtes. Nous devons vérifier si l’application web est également en cours d’exécution.

Pour démarrer la résolution des problèmes, exécutez la même netstat commande que précédemment. Cette fois, utilisez le grep pour filtrer le port 5000 de votre application. Exécutez ensuite netstat -tlp | grep 5000.

Capture d’écran de la commande netstat.

Cet exemple de sortie indique que rien n’écoute sur le port 5000. Par conséquent, il s’agit de la cause de la réponse HTTP 502 provenant de Nginx, car elle ne trouve pas de processus qui écoute sur le port 5000.

La solution consiste à démarrer votre application ASP.NET Core. Toutefois, avant d’aller plus loin, vous pouvez examiner une autre approche pour résoudre ce problème. Tous les problèmes ne sont pas aussi faciles à résoudre qu’en examinant simplement quelques lignes de contenu de journal et en recherchant la cause racine. Parfois, vous devez approfondir vos connaissances sur d’autres journaux d’activité système et d’application.

Étant donné que vous travaillez en étroite collaboration avec Nginx lorsque vous configurez des applications ASP.NET Core dans Linux, nous vous suggérons d’apprendre quel type de journaux Nginx et le système d’exploitation fournit pour la résolution des problèmes.

Vérifier les journaux Nginx

Si vous réexécutez cat /etc/nginx/nginx.conf , puis recherchez le logging settings, vous devez remarquer ce qui suit.

Capture d’écran des informations de journal.

Cela montre que Nginx a deux types de journaux : les journaux d’activité d’accès et les journaux d’erreur. Ceux-ci sont stockés dans le répertoire /var/log/nginx/ .

Les journaux d’accès sont similaires aux fichiers journaux IIS. Une inspection rapide du contenu révèle qu’ils ressemblent à la capture d’écran suivante.

Capture d’écran de la commande Access.

Les journaux d’accès n’affichent pas de nouvelles informations autres que l’état de réponse HTTP 502 que vous connaissiez déjà. Vous pouvez également inspecter les journaux d’erreurs en exécutant cat /var/log/nginx/error.log. Ceux-ci révèlent beaucoup plus sur la cause du problème.

Capture d’écran des informations d’erreur.

Les indications sont claires : Nginx peut obtenir la requête du client, mais elle ne peut pas se connecter au upstream serveur et http://127.0.0.1:5000 à l’application ASP.NET Core qui doit avoir été en cours d’exécution et à l’écoute sur ce port.

Solution de contournement

Pour contourner ce problème, démarrez votre application ASP.NET Core manuellement. Connectez-vous au serveur à l’aide d’une deuxième session de terminal, puis exécutez l’application ASP.NET Core comme précédemment.

Capture d’écran des informations aspnet.

Pendant que votre application ASP.NET Core est en cours d’exécution, basculez vers l’autre session de terminal et exécutez la même curl localhost commande. À présent, vous pouvez accéder à votre application ASP.NET Core qui s’exécute derrière Nginx. La capture d’écran suivante montre que vous avez effectué une demande à localhost, que la requête a été gérée par Nginx et routée vers l’application principale, et que vous avez reçu une réponse de votre application ASP.NET Core.

Capture d’écran de la commande curllocalhost.

Vous avez maintenant configuré Nginx pour qu’il se comporte en tant que proxy inverse pour votre application ASP.NET Core qui s’exécute sous Linux.

Toutefois, si l’application ASP.NET Core ne démarre pas après un redémarrage, quel sera le résultat ? Que se passe-t-il si l’application web se bloque et ne démarre pas tant que vous n’avez pas remarqué qu’elle n’est pas en cours d’exécution ? Devez-vous démarrer votre application ASP.NET Core après chaque redémarrage de l’arrêt du processus ?

Prochaines étapes

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

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.