Si seulement c’était la fin de cette série d’article, … Tant qu’on a pas de locataire qui puisse souscrire à notre plan et consommer nos services, c’est comme si on avait rien fait. Voyons donc les possibilités offertes à nos locataires. Déjà, ils faut qu’ils souscrivent à notre nouveau plan / abonnement. Dans le portail des locataires, le nœud « My Account » va permettre à notre locataire de demander à s’abonner à un nouveau plan avec le lien « Add Plan ».

Note : Si on avait associé le Resource Provider de l’architecture Web Sites à un plan / abonnement déjà souscrit par notre locataire, aurait déjà la possibilité de consommer nos nouveaux services immédiatement.
Dans la liste des plans / Abonnement, y a plus qu’à souscrire et patienter quelques secondes.

Si le certificat auto-signe associé au site web de management du rôle Management de l’architecture Web Sites a bien été remplacé par un certificat reconnu par notre infrastructure Windows Azure Pack, alors on devrait obtenir le résultat ci-dessous après quelques secondes. Le certificat-auto-signé mis en place dans l’infrastructure Web Sites n’est pas reconnu par notre infrastructure Windows Azure Pack.

Le premier choix offert à notre locataire, c’est de créer un simple site web vide. Le seul paramètre attendu, c’est un nom unique dans la zone DNS .websites.Windowsazurepack.Fr. Jusque-là, cela ressemble beaucoup à Azure Web Sites.

Quelques secondes plus tard, on peut tenter de se connecter et effectivement, le site web est opérationnel, manque plus que du contenu.

Notre locataire peut aussi demander la création d’un site web Custom. C’est-à-dire que notre site Web va être capable de consommer une ressource de type base de données. Le Site Web disposera donc d’une « connection string » contenant toutes les informations pour accéder à la base de données (SQL /MySQL). Dans l’illustration ci-dessous, notre locataire a retenu d’utiliser la base de données qu’il avait précédemment provisionnée via le Resource Provider Resource Provider SQL Server.

Et enfin, la partie PaaS, à savoir la Web App Gallery. Vu tout ce qui avait été téléchargé lors de l’installation de l’architecture Web Sites, il fallait bien que cela serve. La Web App Gallery propose pas mal de choix.

Selon le template qu’on va sélectionner, le locataire devra fournir plus ou moins d’informations.

Le portail dédié au locataire permet bien entendu de gérer les Web Sites mis en place. Prenons le cas du dernier créé.
L’onglet « Dashboard » nous fait rentrer dans le détail. La première chose dont le locataire a besoin, c’est de récupérer le Publish Profile. Sur le même principe que le service PaaS Web Sites de Microsoft Azure, c’est un fichier contenant les credentials pour accéder à notre Web sites. A noter que si on utilise l’option « Setup Deployment Credentials », il va de soi qu’il faudra actualiser la configuration de son outil de publication. Selon les caractéristiques de l’abonnement souscrit par le locataire, le site web consomme plus ou moins des différentes ressources mesurées. C’est à ce niveau qu’on peut gérer la notion de « Custom Domain », pour faire comme le grand frère Microsoft Azure, à savoir référencer un nom de domaine public.

Dans l’onglet « Monitor », l’infrastructure Web Sites collecte les compteurs de performance et les mets à disposition de Windows Azure Pack.

Note : Je fais l’impasse sur la notion de Web Jobs. L’idée générale est de permettre d’exécuter des exécutables ou des scripts directement depuis le site web. C’est une fonctionnalité apportée par la version 2.0 Update Rollup 6 de l’architecture Web Sites.
Dans l’onglet « configure », on a beaucoup de choses à dire. Si on héberge des applications Web, on a donc des Framework disponibles (ASP, PHP, …). A nous de choisir notre version. Si l’architecture Web Sites le supporte, le locataire peut activer l’authentification intégrée Windows au niveau de son site web IIS (implique des Web-Worker rôle raccordés à un domaine). Après, la liste des options disponibles est longue comme le bras :
- Activation de la prise en charge des Custom Application Pool Identity
- Choix de l’architecture de la plateforme (X86/X64)
- Configuration du certificat utilisé pour le SSL (SNI)
- Configuration du nom de domaine custom associé au site web
- Prise en charge de la journalisation IIS
- Journalisation des accès avec le module Failed Request Tracing
- Configuration des documents par défaut
- Gestion des virtual directories.
Note : Certaines fonctionnalités ne sont pas disponible car pas autorisée dans le niveau de service ou tout simplement pas autorisées au niveau de l’abonnement souscrit par le locataire.
Dans l’onglet « Scale » on retrouve la notion de niveaux de services que nous avons configurés dans le billet Architecture Windows Azure Pack Web Sites – Etape n°6 : Mise à disposition des Web Sites aux locataires. Si on ne précise rien, notre site web est créé avec le niveau de service le plus bas. Comme avec son grand frère Microsoft Azure, on peut changer le niveau de service à la volée ainsi que le nombre d’instances. La multiplication des instances permet de gérer la montée en charge de notre site web mais aussi faire face à l’indisponibilité d’une instance. D’un point de vue technique, l’architecture Web Sites déploie le même package Web Deploy sur plusieurs instances du rôle Web-Worker et configure le module Application Request Routing présent sur le rôle Front-End de l’architecture pour router le trafic vers les instances.

Note : contrairement à Microsoft Azure, il n’y a pas encore de fonctionnalité auto-scale dans l’architecture Web Sites.
Overdose d’interface graphique? Il vous faut un fix? Pas de problème, on va repasser Dev-Ops et redescendre sous la moquette. Allons voir ce qu’on peut faire notre locataire en Powershell. Il a déjà tout ce qu’il faut puisque c’est le module Azure que nous allons utiliser. Plus précisément, les commandes contenant la chaine de caractères ‘*WaPackWebSite*’.
Import-Module Azure
Get-Command ‘*WaPackWebsite*’
Notre locataire disposant déjà d’un abonnement opérationnel, une simple exécution de la commande Get-WaPackWebSite permet de connaitre la liste des Web sites qu’il a provisionné ainsi que leur état.

Maintenant, un peu plus tricky avec la création d’un Web Sites. Tout ce dont on a besoin, c’est le Datacenter de destination. Comme pour son grand frère, on peut choisir le Datacenter de déploiement. Dans Windows Azure Pack aussi. C’est juste que ma plateforme n’est pas assez grande pour jouer à cela. Une simple exécution de la commande Get-WapackWebSiteLocation qui me retourne le nom du Datacenter par défaut. Après, c’est juste un petit New-WapackWebSite pour créer un nouveau site web.

Je vous laisse explorer le reste. Ça a pris pas mal de temps mais on a vu les grandes fonctionnalités de l’architecture Web Sites. Pourtant, il reste plein de choses à voir (support des Custom Domain, Prise en charge SSL avec SNI, support d’IPv6
, …). Pourtant, il reste un gout d’inachevé. Vous trouvez aussi que la séance de torture manque cruellement de Windows Azure Pack qui brule et de PowerShell qui pique? Pas de problème, y a un billet Bonus Track rien que pour vous, garanti sans interface graphique qui arrive bientôt.
Alors reviendrez-vous dans la salle de torture?
BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)