Architecture Windows Azure Pack WebSites – Etape n°2 : Mise en place du rôle Front-End

Le rôle Font-end, est positionné en frontal de l’architecture Web Sites. Sa fonction , sera de router les requêtes des clients vers la bonne instance de Web Worker rôle en s’assurant que celle-ci soit effectivement fonctionnelle. Le rôle assure aussi fonction de Load-Balancer. Notre instance du rôle Font-end seront mise en place dans une zone réseau dédiée, ayant accès à Internet, directement exposés ou via des solutions de type reverse-proxy / équilibrage de charge.

clip_image001

 

L’astuce, c’est l’enregistrement CNAME que nous avons créé dans la zone DNS websites.Windowsazurepack.fr. Pour rappel, quel que soit le nom pour lequel la résolution DNS est demandée, la réponse sera toujours la même : Webfrontend.Windowsazurepack.Fr.

Resolve-DNSName -Name toto.websites.windowsazurepack.fr -DnsOnly

clip_image002

 

Pour cela, il utilisera le module Application Request Routing (ARR) bien connu de IIS. Le rôle agit donc aussi comme un répartiteur de charge. Avant, cela, on va avoir besoin d’un certificat un peu particulier pour le domaine DNS par défaut configuré de notre infrastructure Web Sites : Websites.WindowsAzurePack.Fr. C’est un certificat wildcard qui devra être délivré par une autorité de certification reconnue par nos futurs locataires qui devra en plus être exportable. Nous devrons le mettre en œuvre sur toutes les instances de notre rôle Frond-end ainsi que de le fournir à Windows Azure Pack.

Une fois le certificat installé sur notre serveur, on doit le retrouver dans le magasin personnel de notre serveur avec un peu de PowerShell :

Get-ChildItem Cert:\Localmachine\My | Where {$_.friendlyName -eq « Certificate for Default Domain »} | Format-List

clip_image003

 

Si c’est pas déjà fait, on l’exporte (avec sa clé privée), vous reprendrez-bien un peu de Powershell?

$Password = ConvertTo-SecureString « ******** » -Force -AsPlaintext

Get-ChildItem Cert:\Localmachine\My | Where {$_.friendlyName -eq « Certificate for Default Domain »} | Export-PFXCertificate -FilePath C:\Temp\DefaultDomain.PFX -Password $Password

clip_image004

 

Le certificat en place, nous pouvons commencer la mise en œuvre de notre première instance du rôle Frond-End. Pourquoi commencer par lui? Car si on commence par, le rôle Web-Worker, il ne démarrera que lorsqu’au moins une instance du rôle Front-end aura démarré. Donc, un Frond-End, c’est :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Compte « WAP\FT-WAB-WEB01 » membre du groupe local administrators
  • Le certificat *.sites.windowsazurepack.fr
  • Quelques règles de pare-feu entrantes :
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole HTTP
    • Protocole HTTPS
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole « Certificate Sync Service » (TCP 1233)

 

Note : Selon les informations issues de l’article Capacity Planning for Windows Azure Pack: Web Sites, il faut considérer que chaque cœur consommé par une instance du rôle Font-end est capable traiter 100 requêtes par seconde. Il est donc intéressant d’avoir plusieurs instances de ce rôle avec de l’équilibrage de charge en amont.

Il est possible de réaliser l’opération directement depuis le portail d’administration de Windows Azure Pack, mais je préfère réutiliser la console Windows Azure Pack Web sites. L’avantage, c’est qu’on a directement les logs sous la main pour traiter les éventuels problèmes. En plus, on a plein de commandes Powershell à tester.

clip_image005

 

La liste des produits à installer sera fournie par le contrôleur de l’infrastructure Web Sites. Dans la liste des composants, que du classique avec des choses attendues tel que URL Rewrite et Application Request Routing. Pourtant l’un d’entre eux a attiré mon attention : CertSynchronizationService.

clip_image006

 

C’est un composant magique car, il va nous permettre de prendre en charge l’utilisation de certificats SSL en frontal, le support des SNI et plus généralement le support des certificats que nos locataires vont associer à leurs sites web. Ça promet du lourd à la mise en œuvre. Une fois le processus mené à son terme, le serveur aura automatiquement redémarré et la console Windows Azure Web Sites devrait ressembler à l’illustration ci-dessous :

clip_image007

 

On peut vérifier que notre rôle est bien opérationnel. Subtilité, en Powershell avec la commande Get-WebSitesServer que nous utiliserons depuis notre instance du rôle contrôleur. Une seule subtilité : il se nomme « LoadBalancer » et non « Publisher » : Get-WebSitesServer | Where {$_.Role -Eq « LoadBalancer »}|Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image008

 

Pour être plus précis, il faut parcourir les logs de l’architecture Web Sites avec la commande Get-WebSitesEvent, et plus particulièrement les évènements compris entre 7775 et 7778 inclus.

Get-WebSitesEvent -ComputerName Webfrontend.Windowsazurepack.lan | Where {($_.MessageID -ge 7775) -And ($_.MessageID -le 7778)}

clip_image009

 

Là, je suis assuré que mon instance du rôle Font-End a effectivement démarrée. Notre infrastructure commence à prendre forme. Prochaine étape, le rôle Web-Worker. On va enfin parler de sites Web.

La séance de torture vous plait? Bien. On passe au plat de résistance.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.