Kestrel pour la production d'applications principales asp.net est-il prêt?
J'ai une API utilisée par mon angular développée dans asp.net core 2.0. Elle a été déployée dans IIS et configurée pour utiliser kestrel.
J'ai lu que Kestrel n'est pas sûr lors de l'exposition publique de l'application et plus encore. Est-ce vrai? La crécerelle n'est-elle pas encore prête pour une utilisation en production? ou kestrel est à des fins différentes, comme peu de blogs le disent pour les applications internes.
Oui, Kestrel est prêt pour la production, mais si votre application est disponible sur les réseaux publics Microsoft recommande que vous l'utilisiez avec un proxy inverse.
Vous pouvez en savoir plus sur les options pour hébergement d'applications ASP.NET Core 2.1 dans la documentation MSDN, y compris sous Windows avec IIS , sous Linux avec Nginx et sous Linux avec Apache entre autres.
Il existe plusieurs raisons d'utiliser un proxy inverse, notamment:
- Exécution de plusieurs applications sur la même IP et le même port
- Limiter votre surface exposée
- Couches supplémentaires de configuration et de défense
- Équilibrage de charge et configuration SSL simplifiés (ceux-ci peuvent être terminés par le proxy inverse par exemple)
- Meilleure prise en charge des fichiers statiques, de la compression, etc.
Selon vos besoins, différents aspects de ce qui précède peuvent être plus ou moins importants pour vous.
Par exemple, Kestrel est un serveur Web très léger qui se spécialise dans l'exécution des applications ASP.NET Core, mais pour ce faire, il n'a pas beaucoup de fonctionnalités telles que IIS ou Apache, qui par exemple, le traitement de fichiers statiques tels que des images, CSS ou JS n'a pas besoin d'être géré par le moteur ASP.NET Core - en utilisant IIS vous pouvez compresser automatiquement ces fichiers et ajouter des en-têtes de mise en cache pour accélérer les chargements de page ultérieurs. De même, les redirections et le routage peuvent être gérés par IIS avant que la demande n'atteigne le processeur.
Du point de vue de la sécurité, vous pouvez à nouveau profiter de fonctionnalités telles que le filtrage des demandes (c'est-à-dire les verbes utilisés, les chemins, etc.), le filtrage IP, l'authentification, etc. avant que la demande n'atteigne Kestrel et ne pas avoir à gérer ces aspects dans votre code.
À noter, pour ASP.NET Core 1.x , la documentation est encore plus spécifique:
Si vous exposez votre application à Internet, vous devez utiliser IIS, Nginx ou Apache comme serveur proxy inverse. Un serveur proxy inverse reçoit les requêtes HTTP d'Internet et les transmet à Kestrel après un traitement préliminaire.