BLOG | NGINX

Tutoriel : Proxy .NET Core et Kestrel avec NGINX et NGINX Plus

NGINX-Partie-de-F5-horiz-black-type-RGB
Nick Shadrin Miniature
Nick Shadrin
Publié le 14 février 2017

Il y a environ deux ans, Microsoft® a annoncé .NET Core , un framework qui vous permet de développer et d'exécuter des applications .NET de manière native sur les systèmes Linux et Mac. ASP.NET Core inclut Kestrel , une bibliothèque de serveur Web interne.

Comme indiqué dans la documentation de Kestrel sur le site Web de Microsoft et dans le référentiel GitHub , vous exécutez généralement Kestrel derrière un serveur Web de production tel que IIS ou NGINX. Dans ce didacticiel, nous allons décrire comment implémenter Kestrel derrière NGINX et NGINX Plus.

Dans ce tutoriel, vous apprendrez à :

Une fois l’installation et la configuration terminées :

  • .NET Core et Kestrel :

    • Exécuter le code de l’application dynamique
    • Écoutez sur une adresse IP locale et répondez aux requêtes HTTP
  • NGINX ou NGINX Plus, agissant comme un proxy inverse :

    • Accepte le trafic HTTP/2 sur IPv6 et IPv4
    • Fournit un déchargement SSL pour l'application .NET
    • Fournit un service de fichiers statiques
    • Fournit des journaux d'accès
    • Ajoute la mise en cache
  • NGINX Plus :

    • Fournit une surveillance et des mesures d'activité en direct
    • Assure le fonctionnement de l'application au moyen de contrôles de santé actifs

L’architecture de déploiement des applications .NET Core est similaire à l’architecture de déploiement des applications Node.js ou Go. NGINX fournit aux applications .NET des fonctionnalités de gestion du trafic qui simplifient le déploiement de production et l'évolutivité des applications. Vous pouvez exécuter plusieurs applications .NET sur la même machine ou sur des machines différentes, et NGINX ou NGINX Plus effectue l'équilibrage de charge et le routage intelligent du trafic entre elles.

Instructions

Les instructions suivantes expliquent comment créer rapidement une application « Hello World » à l’aide de .NET Core, l’exécuter sur Linux et la déployer derrière un proxy inverse NGINX ou NGINX Plus avec des fonctionnalités avancées de gestion du trafic.

  1. Installer .NET Core, NGINX et NGINX Plus
  2. Exécutez l'application « Hello World »
  3. Exécutez le serveur HTTP Kestrel
  4. Configurer NGINX ou NGINX Plus pour inverser le proxy de l'application .NET
  5. Configurer la surveillance des activités en direct et les contrôles de santé actifs de NGINX Plus

Installer .NET Core, NGINX et NGINX Plus

  1. Installez .NET Core en suivant les instructions sur le site Web de Microsoft.

    Dans notre exemple, nous utilisons Ubuntu 16.04. Les commandes suivantes étaient correctes au moment de la rédaction, mais sont susceptibles d'être modifiées car Kestrel est toujours en cours de développement. Consultez la documentation .NET Core si nécessaire.

    $ sudo apt-get install apt-transport-https $ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list' $ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 $ sudo apt-get update $ sudo apt-get install dotnet-dev-1.0.0-preview2-003131
    
  2. Installer NGINX :

    $ sudo apt-get install nginx
  3. Installez NGINX Plus si vous souhaitez une surveillance des activités en direct, des contrôles de santé actifs ou les deux. Consultez les instructions dans le Guide d'administration de NGINX Plus .

    1. Modifiez le fichier ./project.json pour ajouter Kestrel comme dépendance au projet.

      { "version": "1.0.0-*", "buildOptions": { "debugType": "portable", "emitEntryPoint": true }, "dépendances": {}, "frameworks": { "netcoreapp1.0": { "dépendances": { "Microsoft.NETCore.App": { "type": "plateforme", "version": "1.0.1" } , "Microsoft.AspNetCore.Server.Kestrel": "1.0.0" }, "importations": "dnxcore50" } } }
      
    2. Copiez ce code pour une application simple dans un nouveau fichier appelé Program.cs . Il renvoie la date et l'heure actuelles, en exécutant Kestrel sur le port 5000 sur localhost.

      en utilisant System;en utilisant Microsoft.AspNetCore.Builder;
      en utilisant Microsoft.AspNetCore.Hosting;
      en utilisant Microsoft.AspNetCore.Http;
      
      namespace ConsoleApplication
      {
      public class Program
      {
      public static void Main(string[] args)
      {
      var host = new WebHostBuilder()
      .UseKestrel()
      .Configure(app =>
      {
      app.Run(async (context) => wait context.Response.WriteAsync("Date actuelle : " + DateTime.Now + "n"));
      })
      .Build();
      
      host.Run();
      }
      }
      }
      
    3. Exécutez la commande dotnet run pour démarrer le serveur .NET Core :

      $ dotnet run L'application de projet (.NETCoreApp,Version=v1.0) sera compilée car les entrées ont été modifiées Compilation de l'application pour .NETCoreApp,Version=v1.0 Compilation réussie.
          0 Avertissement(s) 0 Erreur(s) Temps écoulé 00:00:01.9047678 Bonjour le monde !
      Environnement d'hébergement : Chemin racine du contenu de production : /app/bin/Debug/netcoreapp1.0 Écoute en cours sur : http://localhost:5000 Application démarrée. Appuyez sur Ctrl+C pour arrêter.
      
    4. Exécutez la commande curl pour tester la connectivité et HTTP :

      $ curl -v localhost:5000 * URL reconstruite vers : localhost:5000/ * Essai ::1... * Connecté au port 5000 (#0) de localhost (::1) > GET / HTTP/1.1 > Hôte : localhost:5000 > Agent utilisateur : curl/7.47.0 > Accepter : */* > < HTTP/1.1 200 OK < Date : mar. 14 févr. 2017 19:50:59 GMT < Transfer-Encoding: chunked < Serveur: Faucon crécerelle < Date actuelle : 14/02/17 12:50:59 PM * Connexion #0 à l'hôte localhost laissée intacte
      
    1. Installer un certificat SSL. Il existe plusieurs façons d'en obtenir un :

      • Achetez-le auprès d'une autorité de certification (CA) réputée
      • Demandez à votre groupe informatique d'entreprise ou à votre CA de le générer
      • Exportez-le à partir d’un serveur IIS existant
      • Utilisez une autorité de certification gratuite comme Let's Encrypt
      • Générer directement un certificat auto-signé

      Afin de lancer rapidement un exemple d’application .NET Core avec SSL, nous générons un certificat auto-signé et une clé associée avec cette commande openssl . Nous installons le certificat et la clé à l'emplacement standard pour NGINX, /etc/nginx , mais vous pouvez choisir un emplacement différent.

      $ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem Génération d'une clé privée RSA 4096 bits .........++ ............................++ écriture d'une nouvelle clé privée dans '/etc/nginx/cert.key' -----
      
    2. Configurez le proxy inverse dans le fichier de configuration NGINX et NGINX Plus par défaut pour les serveurs virtuels HTTP.

      Le fichier de configuration principal de NGINX et NGINX Plus est /etc/nginx/nginx.conf . Cependant, plusieurs distributions NGINX (ainsi que NGINX Plus) suivent la convention selon laquelle vous ne placez pas beaucoup de configuration réelle dans le fichier principal, mais créez plutôt des fichiers plus petits et spécifiques aux fonctions dans un sous-répertoire de /etc/nginx :

      • Pour les builds NGINX Open Source fournies par nginx.org et pour NGINX Plus, le répertoire est /etc/nginx/conf.d et le fichier par défaut pour les serveurs virtuels HTTP est default.conf .
      • Pour les builds NGINX Open Source distribuées avec Ubuntu, le répertoire est /etc/nginx/sites-enabled et le fichier par défaut pour les serveurs virtuels HTTP est default .

      Le contenu des fichiers spécifiques aux fonctions dans ces répertoires est ensuite lu dans le fichier principal ( nginx.conf ) avec une directive include , par exemple :

      inclure /etc/nginx/conf.d/*.conf;inclure /etc/nginx/sites-enabled/*;
      

      Si vous n'êtes pas sûr du fichier de configuration par défaut pour les serveurs virtuels HTTP sur votre système, recherchez la directive include appropriée dans /etc/nginx/nginx.conf .

      Pour configurer NGINX ou NGINX Plus comme proxy inverse, ajoutez les trois blocs de configuration suivants au fichier de configuration par défaut des serveurs virtuels HTTP :

      • Le premier bloc serveur accepte les requêtes HTTP sur le port 80 et les redirige vers le serveur virtuel pour les requêtes HTTPS.

      • Le deuxième bloc de serveur accepte les requêtes HTTPS sur le port 443 et les transmet à un groupe d'un ou plusieurs serveurs en amont (backend), appelés ici dotnet . (Si à l'étape 1 vous avez installé votre certificat SSL auto-signé dans un répertoire autre que /etc/nginx , remplacez le chemin correct dans les directives ssl_certificate et ssl_certificate_key .)

      • Le bloc en amont définit le groupe dotnet de serveurs back-end.

        Dans Exécuter le serveur HTTP Kestrel , nous avons configuré Kestrel sur localhost:5000 , ce qui signifie qu'il écoute le trafic IPv4 et IPv6 sur ce port. (La configuration de Kestrel pour un seul protocole peut entraîner une instabilité et potentiellement502 erreurs.) De même, NGINX et NGINX Plus résolvent localhost à la fois sur son adresse IPv4 et son adresse IPv6 (127.0.0.1 et ::1). Par souci de simplicité, nous identifions ici le serveur en amont comme127.0.0.1 au lieu de localhost , il écoute donc uniquement le trafic IPv4. Vous pouvez utiliser localhost si vous êtes à l'aise avec une configuration plus avancée qui inclut IPv6.

      serveur { écouter 80 default_server;
      écouter [::]:80 default_server;
      retourner 301 https://$host$request_uri;
      }
      
      serveur {
      écouter 443 ssl http2 default_server;
      écouter [::]:443 ssl http2 default_server;
      
      certificat_ssl /etc/nginx/cert.pem;
      clé_certificat_ssl /etc/nginx/cert.key;
      
      emplacement / {
      proxy_pass http://dotnet;
      proxy_set_header Hôte $host;
      }
      }
      
      en amont dotnet {
      zone dotnet 64k;
      serveur 127.0.0.1:5000;
      }
      
    3. Exécutez cette commande curl pour tester la connectivité à l’application .NET Core via HTTPS. (Vous pouvez également pointer votre navigateur vers votre serveur Linux à la place.)

      $ curl -kv https://localhost * URL reconstruite vers : https://localhost/ * Essai ::1... * Connecté au port 443 (#0) de localhost (::1) ...[ SAUTÉ ]... < HTTP/1.1 200 OK < Serveur : nginx/1.10.0 (Ubuntu) < Date : mar. 14 févr. 2017 20:22:07 GMT < Transfer-Encoding: chunked < Connexion: keep-alive < Date actuelle: 14/02/17 13:22:07
      

      Note: Si tu vois 502 Mauvais Porte erreurs, cela signifie que NGINX ou NGINX Plus ne peut pas se connecter à votre application .NET. Assurez-vous qu'il est en cours d'exécution et qu'il fournit des réponses sur le port 5000.

      Si vous avez installé le package nghttp2 , vous pouvez également exécuter la commande nghttp suivante pour tester la connectivité via HTTP/2. Recherchez la ligne surlignée en orange dans l’exemple suivant, près du début de la sortie assez longue.

      $ nghttp -v https://localhost [ 0.000] Connecté Le protocole négocié : h2 [ 0.009] envoyer la trame SETTINGS (niv=2) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535] [ 0.009] envoyer la trame PRIORITY (dep_stream_id=0, weight=201, exclusive=0)
      
    • Le code de réponse est 200D'ACCORD
    • Le serveur d'applications est Kestrel et non un autre logiciel
    • Le corps de la réponse comprend les mots « Date du jour »
    • L'application répond dans un délai d'attente d'une seconde
  4. Exécutez l'application « Hello World »

    Installez et initialisez une application « Hello World » dans le répertoire parent de votre choix :

    $ cd répertoire-parent-pour-les-applications $ mkdir app $ cd app $ dotnet restore
    

    Pour vérifier que l'application fonctionne, exécutez la commande dotnet run .

    Exécutez le serveur HTTP Kestrel

    À ce stade, .NET Core s’exécute sur Linux et diffuse des données dynamiques à l’aide de Kestrel comme serveur HTTP.

    Configurer NGINX ou NGINX Plus pour inverser le proxy de l'application .NET

    Avec NGINX ou NGINX Plus comme proxy inverse pour l'application .NET, vous pouvez facilement configurer la sécurité avec SSL/TLS, la prise en charge HTTP/2 et de nombreuses autres fonctionnalités pour une distribution rapide des applications sur la même machine sur laquelle l'application .NET Core est exécutée. Les instructions suivantes supposent que NGINX et NGINX Plus sont déjà installés sur votre système ; si ce n'est pas le cas, consultez Installer .NET Core, NGINX et NGINX Plus .

    Configurer la surveillance des activités en direct et les contrôles de santé actifs de NGINX Plus

    À ce stade, nous avons terminé la configuration de base de NGINX ou NGINX Plus avec .NET Core. NGINX ou NGINX Plus fournit la gestion HTTP, les contrôles de santé passifs, la sécurité avec SSL/TLS et la connectivité HTTP/2 pour notre application .NET Core.

    Si vous avez installé NGINX Plus, vous pouvez configurer deux fonctionnalités supplémentaires : la surveillance de l'activité en direct et les contrôles de santé actifs.

    Configurer la surveillance des activités en direct

    [Éditeur – Cette section a été mise à jour pour faire référence à l’ API NGINX Plus , qui remplace et désapprouve le module d’état étendu distinct initialement décrit ici.]

    Ajoutez le bloc de serveur suivant au fichier de configuration NGINX par défaut pour les serveurs virtuels HTTP. Nous vous recommandons fortement de restreindre l'accès aux statistiques et aux mesures. Ici, nous autorisons l'accès uniquement aux utilisateurs sur localhost et un réseau local.

    Pour plus d'informations sur la surveillance des activités en direct, consultez Surveillance des activités en direct de NGINX Plus en 3 étapes simples sur notre blog et le Guide d'administration de NGINX Plus .

    server { listen 8080;
    allow 127.0.0.1; # Autoriser l'accès de l'hôte local aux statistiques
    allow 10.3.3.0/24; # Autoriser le réseau local à accéder aux statistiques
    deny all; # Empêcher l'accès depuis n'importe où ailleurs
    
    root /usr/share/nginx/html;
    
    location / {
    return 302 /dashboard.html;
    }
    
    location /api {
    api write=on;
    }
    
    location = /dashboard.html {
    root /usr/share/nginx/html;
    }
    
    # Rediriger les requêtes faites vers l'ancien tableau de bord
    location = /status.html {
    return 301 /dashboard.html;
    }
    }
    

    Configurer les contrôles de santé actifs

    Les contrôles de santé actifs garantissent que NGINX Plus envoie du trafic uniquement aux applications qui fonctionnent correctement. Vous définissez les requêtes HTTP que NGINX Plus envoie périodiquement à l'application, ainsi que le type de réponse que l'application doit renvoyer pour être considérée comme saine.

    Ici, nous exigeons que la réponse de l’application réponde aux conditions suivantes :

    Dans le fichier de configuration par défaut des serveurs virtuels HTTP, ajoutez le bloc d'emplacement suivant au bloc du serveur principal (le bloc pour le trafic HTTPS défini à l'étape 2 de la section Configurer NGINX ou NGINX Plus pour inverser le proxy de l'application .NET ) :

    emplacement @healthcheck { proxy_pass http://dotnet;
    proxy_set_header Hôte localhost;
    health_check match=currentdate;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
    }
    

    Ajoutez également le bloc de correspondance suivant au même niveau dans la hiérarchie que les blocs serveur et en amont :

    correspond à la date actuelle { statut 200 ;
    header Server = Kestrel ;
    body ~ "Date actuelle " ;
    }
    

    Vous pouvez vérifier que votre application back-end est saine dans l'onglet Upstreams du tableau de bord de surveillance des activités en direct intégré (pointez votre navigateur sur //http:// nginx-plus-server-address :8080/ ) :

    Le tableau de bord de surveillance des activités en direct de NGINX Plus indique l'état de santé des applications .NET backend que NGINX utilise comme proxy

    Pour plus d'options de configuration NGINX, consultez la documentation Microsoft .

    Conclusion

    Pour les déploiements prêts pour la production des applications que vous développez avec ASP.NET, NGINX et NGINX Plus fournissent les fonctionnalités de gestion du trafic dont vous avez besoin dans un proxy inverse. NGINX et NGINX Plus offrent sécurité, évolutivité, authentification, limitation du trafic et routage intelligent de vos requêtes HTTP vers les applications .NET Core.

    Pour essayer NGINX Plus par vous-même, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .


« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."