Ca fait un moment que je n'ai pas bloggé, pour cause de plein de taff (et aussi de flemme, et un peu de WoW en début d'année), et pour cette fois, je voulais montrer un truc marrant en ASP.Net dont j'ai eu besoin chez un client.
Le contexte est simple: on a une appli ASP.Net, développée en MVC 2 qui a un soucis qui ne se produit que lorsqu'elle est déployée en mode WebFarm (plusieurs serveurs Web, répartisseur de charge sans affinité de session). Le détail du problème nous importe peu (il s'agissait d'un soucis au niveau de l'invalidation d'un cache partagé), ce qui nous intéresse, c'est la mise en place de l'environement de debugging.
Les 2 solutions qui viennent le plus vite a l'esprit sont:
- La mise en place de machines virtuelles, du remote debugging et l'installation d'un repartisseur de charge type IIS ARR. Cette solution est assez lourde en terme d'install / config (les joies du parametrage du Remote Debugger...)
- La creation de 2 sites locaux qui ecoutent sur un port différent et configuration d'un IIS ARR pour distribuer la charge sur ces 2 sites. Cela nécessite de connaitre un minimum ARR, et attacher le debugger aux différents sites manuellement après chaque build, c'est pas super fun
La 3e solution que je vous propose aujourd'hui est celle qui est la plus agréable pour le développeur : Utiliser l'environement de simulation de Windows Azure (qui repose sur IIS Web Core), et paramétrer un WebRole contenant votre appli Web en mode multi-instance:
- Dans notre solution, on commence par ajouter un projet Azure.
- Quand on nous demande les roles à ajouter, on dit “rien”,
- puis dans le SolutionExplorer, sur le dossier “Roles” du projet Windows Azure, on fait Clic droit => Add => Web Role Project in solution
- On selectionne notre projet Web, et on fait Ok
Ensuite on configure le Role comme ceci (clic droit => Properties sur le role qui est apparu dans le projet Windows Azure):
Selectionnez le projet Windows Azure comme projet de demarrage, et vous voila avec 4 instances d’applications ASP.Net sous IIS Web Core avec un NLB logiciel devant !
Attention tout de même, l’algorithme de distribution des requêtes semble un peu spécial (basé sur le temps plutôt que sur un nombre de requêtes traitées par serveur) et fonctionne mieux avec 2 instances.
A savoir également, par défaut le NLB écoute sur le premier port libre à partir de 80. Si Vous voulez qu’il écoute sur le 80 plutôt que le 81 (comportement par défaut si vous avez installé IIS), coupez l’environement de simulation Azure, stoppez le service IIS, et relancez le debug.
Enjoy!