ASP.NET sous Linux : quels outils ? Comment faire ?

Version imprimable

22/11/2019, 10h59
StringBuilder

ASP.NET sous Linux : quels outils ? Comment faire ?

Bonjour,

J'ai quelques notions sous Linux, même si c'est un système que je n'ai jamais vraiment utilisé pour autre-chose que bidouiller.

Avec .NET Core porté sous Linux, et la possibilité sur les Freebox d'héberger des VMs sous Linux, j'ai envie de jouer un peu avec.

ASP.NET semble être supporté depuis quelques temps dans la version .NET Core 3.0 ARM64 donc de ce côté là ça devrait aller.

Seulement voilà, j'ai plusieurs questions… en rapport direct avec .NET et d'autres moins.

Pour héberger mon application ASP.NET quels outils dois-je utiliser ?
Jusqu'à présent j'ai toujours joué avec Apache2, mais j'ai cru comprendre que ce n'était pas forcément le choix de prédilection.

Dans les doc de Microsoft, ils parlent plutôt de Docker et NGNIX. J'ai déjà mis en place NGNIX pour faire un reverse proxy, mais je ne vois pas trop comment paramétrer .NET dedans…

Est-ce "la" bonne solution ? Même si au final je vais me contenter de bidouiller, je souhaite mettre en place un environnement logiciel le plus proche possible de ce qu'on pourrait trouver sur un véritable serveur de production.

Enfin, j'utilise Visual Studio sous Windows : quel moyen simple ai-je pour déployer mes devs sur la VM ? Existe-t-il des solutions permettant de débugger à distance comme avec IIS ?
27/11/2019, 06h19
DotNetMatt

Citation:

Envoyé par StringBuilder

Pour héberger mon application ASP.NET quels outils dois-je utiliser ?
Jusqu'à présent j'ai toujours joué avec Apache2, mais j'ai cru comprendre que ce n'était pas forcément le choix de prédilection.

Rien ne t'empeche d'utiliser Apache. C'est un peu comme le debat Java vs C#. Apache et NGNIX ont des differences fondamentales. Par exemple Apache est plutot lent pour servir du contenu statique, alors que NGNIX est tres rapide. Apache est livre par defaut avec tout un tas d'options et de plugins, alors que NGNIX vient avec le strict minimum. En terme d'architecture, Apache va creer un thread par requete HTTP, alors que NGNIX va faire transiter plusieurs requetes HTTP dans un meme thread... Bref la-dessus le mieux c'est de te forger ta propre opinion avec par exemple "Apache vs NGNIX" sur Google, et aussi en fonction du type de site Web que tu veux heberger.

Citation:

Envoyé par StringBuilder

Dans les doc de Microsoft, ils parlent plutôt de Docker et NGNIX. J'ai déjà mis en place NGNIX pour faire un reverse proxy, mais je ne vois pas trop comment paramétrer .NET dedans…

Docker c'est un systeme de conteneur. Avant Docker, la seule option etait d'avoir 1 VM = 1 OS + 1 serveur Web + l'appli. C'etait plutot lourd et n'optimisait pas les ressources du data center. Avec un systeme de conteneur comme Docker, tu as 1 VM = 1 OS = x conteneurs. Chaque conteneur contient un serveur Web + l'appli. Ca simplifie les deploiements et la maintenance vu qu'il n'y a plus besoin de maintenir et configurer autant d'OS. Les conteneurs sont bien plus legers donc pour scaler tu seras beaucoup plus reactif (quelques seconds pour lancer un nouveau conteneur vs quelques minutes pour lancer une VM). Il y a pas mal d'autres avantages a utiliser Docker, mais par exemple si ton archi cible c'est 1 load balancer avec 2 serveurs Web derriere, alors il est inutile de partir sur Docker... 3 VMs feront l'affaire tout simplement. Un exemple d'architecture typique pour Docker : des micro-services.

Je ne sais pas si tu as deja vu ces tutos mais ils sont tres complets :
- Pour .NET Core 3.0 sur NGNIX
- Pour .NET Core 3.0 sur Apache

Pour une demo tu n'as pas besoin de te farcir toutes les configs de securite, par contre si tu pars en Production avec, il est conseille de suivre tout le tuto, a minima.

Si tu veux utiliser Docker, c'est un poil plus complique a configurer. Je t'invite a lire la doc ici, si ce n'est deja fait.

Citation:

Envoyé par StringBuilder

Est-ce "la" bonne solution ? Même si au final je vais me contenter de bidouiller, je souhaite mettre en place un environnement logiciel le plus proche possible de ce qu'on pourrait trouver sur un véritable serveur de production.

Comme d'habitude, la meilleure solution va dependre de tes problematiques :) Comme tu en es a la phase de test, je pense qu'une VM + NGNIX est un bon point de depart pour acquerir les concepts initiaux. Ensuite quand tu te sens a l'aise, tu peux rajouter Docker, mais il n'y a rien d'obligatoire.

Citation:

Envoyé par StringBuilder

Enfin, j'utilise Visual Studio sous Windows : quel moyen simple ai-je pour déployer mes devs sur la VM ? Existe-t-il des solutions permettant de débugger à distance comme avec IIS ?

Pour le deploiement, tu peux utiliser les outils de publication directement integres a VS. Par contre pour de la prod il vaut mieux passer par un outil de gestion de code source + CI/CD comme Azure DevOps par exemple (ou Jenkins, ou autre…).

Pour le debug a distance, c'est possible via SSH et une build en mode debug, avec un peu de config.

Pour ces 2 points, je te conseille de suivre ce tuto : Debugging ASP Core on Linux with Visual Studio 2017 (ca marche pareil pour VS 2019 ; VS Code est legerement plus complique, mais similaire).

J'espere que ca t'eclaire un peu plus !
27/11/2019, 09h15
StringBuilder

Merci beaucoup pour ta réponse.

J'ai en effet suivi avec plus ou moins de succès le tuto de Microsoft pour installer ASP.NET Core avec NGINX.

En revanche, il y a quelque chose qui me surprend/choque : en fait, mon appli ASP.NET contient elle-même son propre serveur d'application ??? Et y'a pas moyen de s'en passer ?

Car dans tous les cas, qu'on utilise Apache ou NGINX, on s'en sert uniquement de reverse proxy, et éventuellement pour délivrer les contenus statiques pour ne pas surcharger inutilement la partie .NET

Avec Mono, on avait un bête plugin pour Apache, on collait le site ASP.NET (ou la DLL) dans un dossier et basta, ça marchait tout seul, et Apache faisait ce pour quoi il est fait : serveur web, hôte de l'application. Idem avec le Framework .NET classique sous IIS : tout tournait sans IIS, il ne se contenait pas de rediriger les demandes HTTP à une autre application.

Au départ, je pensais que cette nouvelle architecture était là pour simplifier le développeur et debug (même si je n'en suis pas du tout convaincu), mais visiblement, on se coltine cette couche supplémentaire jusqu'en production. Ce choix me surprend énormément : le moindre hello world (une page ne contenant aucun code, juste une balise <p>) bouffe plus de 70 Mo sur le serveur quand elle est appelée ! Et je sais pas si le processeur de la Freebox est une merde ou si c'est .NET Core qui est très peu/mal optimisé pour Arm64, mais c'est d'une lenteur abominable…

J'ai l'impression d'avoir en face de mois un OC4J... J'avoue que je ne comprends pas ce choix technique.
Et accessoirement, j'ai vraiment du mal avec la mise en place ensuite de l'application .NET Core, pour la faire démarrer autrement qu'en ligne de commande : les scripts à taper et fichiers de conf à modifier n'en finissement pas…

Bon, je vais essayer de me rencourager un peu (faute de réponse et de résultats, j'avais laissé tombé hier :D) pour creuser encore un peu...
30/11/2019, 00h55
DotNetMatt

Citation:

Envoyé par StringBuilder

En revanche, il y a quelque chose qui me surprend/choque : en fait, mon appli ASP.NET contient elle-même son propre serveur d'application ??? Et y'a pas moyen de s'en passer ?

Exactement, il s'agit de Kestrel qui est directement integer a .NET Core (il est configurable dans le Program.cs). Il est integre systematiquement car il est multi-platformes, et donc permet l'hebergement multi-plateformes. A noter cependant il ne dispose pas de toutes les fonctionnalites fournies par un "vrai" serveur Web comme IIS, Apache, NGINX... Pour des web apps avec tres peu de traffic et exposees en local, ca peut largement faire l'affaire (donc pas besoin d'un reverse proxy devant). Par contre pour une appli exposee sur le Web et/ou avec fort traffic, il est tres recommande d'avoir un reverse proxy devant. J'avais vu le terme de Edge Server pour qualifier Kestrel, je pense que ca resume bien la chose.

A noter egalement, Kestrel est tres mauvais pour servir du contenu statique.

Citation:

Envoyé par StringBuilder

Et je sais pas si le processeur de la Freebox est une merde ou si c'est .NET Core qui est très peu/mal optimisé pour Arm64, mais c'est d'une lenteur abominable…

La lenteur peut venir de l'affichage console qui est active par defaut. Est-ce que tu as essaye de le desactiver ? Pour reference : Don't let ASP.NET Core Console Logging Slow your App down
A noter aussi, il y a des restrictions pour Arm64. Pas sur que ca soit le probleme dans ton cas, mais c'est toujours bon a savoir :)

Citation:

Envoyé par StringBuilder

Et accessoirement, j'ai vraiment du mal avec la mise en place ensuite de l'application .NET Core, pour la faire démarrer autrement qu'en ligne de commande : les scripts à taper et fichiers de conf à modifier n'en finissement pas…

Je pense que cela est plutot lie a l'environnement Linux/Unix qu'a .NET Core lui-meme. En principe ton Reverse Proxy doit etre un service, donc il se lance tout seul comme un grand. Pour demarrer automatiquement la Web App, il faut passer par systemd (voir ici) (supervisord est recommande sous Ubuntu 14). Il est possible d'automatiser le deploiement des configs via les outils de CI/CD, tant que la config est dans un repository (ce qui est grandement conseille).

Citation:

Envoyé par StringBuilder

Bon, je vais essayer de me rencourager un peu (faute de réponse et de résultats, j'avais laissé tombé hier :D) pour creuser encore un peu...

C'est deroutant au debut car il faut changer ~15 ans d'habitudes. Et maitriser Linux/Unix n'est pas toujours evident :roll: