Architecture Windows Azure Pack WebSites – Etape n°1 : Mise en place des rôles Controller, Management, File Server

La mise en bouche vous a plu? Tant mieux. Maintenant on entre dans la salle de torture. Ça va devenir fun ou pas, c’est selon votre sensibilité. Les rôles contrôleur, Management et File Server constituent le socle d’une infrastructure Web Sites. C’est donc logique de commencer par eux.

Commençons avec le contrôleur. Nous allons l’installer sur un serveur dédié. On va passer beaucoup de temps avec puisque c’est lui qui va provisionner l’intégralité de l’infrastructure Web Sites. Pour sa mise en œuvre, la liste des prérequis est la suivante :

  • 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é
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole WebDeploy (TCP 8172)
    • Protocole Web Farm Service (TCP 8675)

Note : Une infrastructure Web Sites ne peut avoir que deux contrôleurs, un primaire et l’autre secondaire.

Pour installer notre rôle contrôleur, nous allons utiliser le Web Platform Installer que nous connaissons déjà. Dans sa version actuelle, c’est un package nommé Windows Azure Pack Web Sites V2 update 6.

clip_image001

 

C’est une installation dès plus simple (package Windows Installer). On n’a plus rien à faire avec le Web Platform Installer.

clip_image002

 

Maintenant, c’est le package Windows Installer qui prend la main. Le processus d’installation propose deux scénarios de déploiement :

  • Déploiement du rôle contrôleur en utilisant les packages disponibles sur Internet
  • Déploiement du rôle contrôleur en utilisant un repository de packages préalablement téléchargés

Le second scénario de déploiement est adapté aux environnement ou l’accès Internet est limité, comme on peut le faire avec le Web Platform Installer. Ce scénario permet aussi de conserver la maitrise de l’architecture. L’installation de tous les rôles sera réalisée en utilisant le repository. Quand on sait que l’architecture Web Sites de Windows Azure Pack repose sur un grand nombre de composants, il est intéressant de bien maitriser le cycle de mise à jour de chacun d’entre eux. Il faut comprendre que l’architecture Web Sites dispose de son propre mécanisme de mise à niveau pour s’assurer que chaque rôle est bien installé avec la dernière version chaque composant disponible. Pour la majorité des rôles, plusieurs instances d’un même rôle peuvent exister dans une architecture. Pendant que certaines sont actives, les autres peuvent être en maintenance, mise à niveau voire même s’auto-réparer.

Dans le contexte de ce billet, nous allons faire simple et réaliser l’installation du rôle contrôleur en téléchargeant les sources directement depuis Internet.

clip_image003

 

Je fais l’impasse sur l’accord de licence et on se retrouve avec la liste des composants de l’architecture qui seront téléchargés. La liste est longue, très longue, il y en a presque pour un giga-octets, donc patience.

clip_image004

 

Au fur et à mesure de la progression de l’installation, nous avons le répertoire « c:\HostingOfflineFeed\Installers » qui se remplit avec les binaires nécessaires. Il y a plein de choses que nous connaissons car en provenance de IIS mais aussi des composants non Microsoft (PHP, …).

clip_image005

 

Après avoir créé le repository local, le Setup va mettre en œuvre notre nouvelle architecture.

clip_image006

 

L’architecture Web Sites est totalement indépendante de Windows Azure Pack. Avant de pouvoir référencer le « Resource Provider », il reste beaucoup de travail. Le rôle Controller est au cœur de l’architecture Web Sites. Il a pour rôle de :

  • Gérer l’architecture Web Sites
  • Provisionner les autres rôles de l’architecture
  • Orchestrer la mise à niveau des différents rôles
  • Gérer les Web Sites mis à disposition des locataires

 

Dans notre situation, nous allons installer notre contrôleur primaire. Il sera tout à fait possible de lui adjoindre un contrôleur secondaire plus tard. A l’instant T, un seul contrôleur « primaire » assure la gestion de l’infrastructure Web Sites.

clip_image007

 

Pour mettre en place notre rôle Contrôleur, c’est aussi mettre en place le rôle File Server. Il est possible de référencer un serveur /cluster de fichiers préalablement configuré ou de laisser notre contrôleur configurer un serveur prévu pour ce rôle. La seule limite est qu’il n’est pas possible d’utiliser un Scale-Out File server (Le rôle File Server Resource Manager qui sera installé n’est pas compatible avec les clusters Scale-out File server).

Pour faire simple, nous allons laisser le programme d’installation nous configurer notre serveur de fichiers. Réutiliser un serveur de fichiers existant implique qu’on mette en place la structure de répertoire, les partages et permissions NTFS par nous-même tel que documenté par l’article Technet « Pre-configure a Windows File Server Cluster or NAS device for Windows Azure Pack: Web Sites« .

clip_image008

 

Ces premiers choix fait, on peut passer à la configuration du rôle contrôleur.

clip_image009

 

Première étape, c’est de désigner une base de données pour le rôle Web Sites Cloud ainsi que pour la mesure des usages. Pour des raisons de sécurité, il est recommandé de dédier une instance SQL distincte pour ces bases de données. Pour une plateforme de développement, il est tout à fait possible de localiser ces bases de données avec celles de Windows Azure Pack, c’est ce que j’ai fait. D’un point de vue réseau, cela se limite au port TCP 1433 (ou celui utilisé pour installer l’instance SQL Server).

clip_image010

 

Note : Attention à bien vérifier que le programme d’installation a bien créé les deux bases de données lors de l’installation. Lors de la mise en œuvre sur ma maquette, je suis tombé sur un cas ou la base de données de mesure des usage était annoncée comme créée alors que cela ne l’était pas, ce qui a bloqué la suite du processus de déploiement de certains rôles.

Une fois les bases de données crées, on peut passer à la phase de configuration des paramètres systèmes.

clip_image011

 

Dans Microsoft Azure, lorsqu’on demande la création d’un Web Sites, celui-ci est référencé dans la zone DNS « AzureWebsites.Net » gérée par Microsoft. Il est possible de configurer un domaine personnalisé, si on est capable de prouver que nous en sommes bien les propriétaires (capable de créer des enregistrements DNS bien spécifiques). Avec l’architecture Web Sites, c’est presque le même principe, sauf que nous avons le choix du domaine public. J’ai créé un sous-domaine « websites.windowsazurepack.fr » qui contient les enregistrements DNS attendus.

clip_image012

 

L’astuce, c’est que l’on va exploiter un enregistrement DNS dit « Wildcard » pour traiter toutes les demandes de résolution DNS pour ce sous-domaine et rediriger le trafic vers les instances du rôle Font-End pour routage vers l’instance Web Worker appropriée. Si on essaie de résoudre n’importe quel nom DNS dans cette zone, on voit bien que la réponse est toujours la même : le rôle Front-End.

Resolve-DNSname -Name toto.websites.windowsazurepack.fr

clip_image013

 

Tous les produits Microsoft proposent une option pour se mettre à niveau via Windows Update. Avec l’architecture Web Sites, c’est un peu plus compliqué. Sur chaque serveur de l’infrastructure, un service « Web Sites update service » est chargé de maintenir le rôle à niveau. Le rôle contrôleur met à disposition un fichier XML à l’Url suivante : http://{controller}/HostingOfflineFeed/Feeds/latest/originalfeeds/WebSites<Version>.XML. Celui-ci référence pour chaque package la version associée. Chaque instance est donc à même de détecter lui-même que un ou plusieurs packages doivent être mis à niveau.

clip_image014

 

L’architecture Web Sites de Windows Azure Pack nous propose de configurer nos rôles pour se mettre à niveau automatiquement. Cela inclus aussi bien les packages de mise à niveau ou les nouvelles fonctionnalités de l’architecture Web Sites. Si on dispose de plusieurs instances pour chaque rôle, cela ne pose pas de problème particulier. Le contrôleur réalisera les mises à niveau progressivement, sans perturber le service. Par contre, sur une plateforme de POC / Développement, il peut être opportun de ne pas activer la mise à niveau automatique pour gérer la maintenance de l’infrastructure Web Sites mais aussi pour garantir la stabilité de la plateforme en terme de version de composants mis à disposition pour les sites web.

clip_image015

 

On rentre dans une section intéressante. L’architecture Web Sites de Windows Azure Pack exploite plusieurs contextes de sécurité. Pour chacun d’entre eux, on peut configurer un compte local ou un compte de domaine. C’est ce qui fait que les serveurs de notre architecture Web Sites peuvent tout aussi bien être installés en Workgroup ou domaine. Personnellement, j’ai fait le choix de raccorder mon infrastructure Web Sites au domaine, on utilisera donc des comptes de services.

clip_image016

 

On commence avec le compte de service qui sera utilisé pour réaliser le provisioning du reste de l’infrastructure Web Sites de Windows Azure Pack. Cela concerne une liste de rôles bien définie :

  • Front-end
  • Publisher
  • Management
  • File Servers

 

Il est possible d’utiliser un compte local pour tous ces rôles mais c’est quand même plus simple d’utiliser un compte de domaine. J’ai donc créé le compte « WAP\FT-WAP-WEB01 » qui sera positionné comme membre du groupe local administrators pour les rôles cités ci-dessus. Dans la console Windows Azure Pack Web Sites, nous n’avons qu’à référencer le compte de service à utiliser ainsi que son mot de passe.

clip_image017

 

Vous avez certainement remarqué que le rôle Web Worker n’était pas dans la liste précédente. C’est logique, il dispose de son propre compte de service, que ce soit pour le Web Worker dedicated ou Shared. J’ai donc créé le compte « WAP\FT-WAP-WEB02 » qui sera positionné comme membre du groupe local administrators sur les futurs serveurs qui hébergeront les instances du rôle Web Worker.

clip_image018

 

Passons au rôle File Server de l’architecture. Il nécessite deux comptes de services car on distingue :

  • Le contexte utilisé pour gérer l’infrastructure Web Sites
  • Le contexte utilisé par les Web Worker Role pour venir récupérer le contenu du site web

 

Pour le premier contexte, j’ai donc créé le compte de service « WAP\FT-WAP-FSO » qui est positionné comme membre du groupe local « Administrators » de toutes les instances du rôle File Server.

clip_image019

 

Pour le second contexte, ce sera le compte « WAP\FT-WAP-FSU ». Pour ceux qui ont suivi les recommandations « Pre-configure a Windows File Server Cluster or NAS device for Windows Azure Pack: Web Sites » pour configurer les permissions de partage et NTFS, c’est un compte qui ne peut que lire le contenu des partages sur les instances du rôle File Server.

clip_image020

 

Il ne nous manque plus qu’une identité. C’est celle sous laquelle sera réalisé le référencement de l’infrastructure Web Sites dans Windows Azure Pack via ses API Rest.

clip_image021

 

Pour continuer, un serveur devra avoir été mis en place pour le rôle File Server avec les prérequis suivants :

  • 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é
  • Le compte « WAP\FT-WAP-FSO » positionné comme membre du groupe local administrators
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)

 

Le rôle File Server, permet de stocker le contenu des sites web de nos locataires. Dans le contexte d’un POC simple, j’avais retenu une configuration simplifiée. C’est donc le processus d’installation qui va configurer les permissions.

clip_image022

 

Dernière étape, désigner notre Management Server pour que celui-ci puisse être l’interface avec Windows Azure Pack. Ici encore, c’est un serveur dédié avec les prérequis suivants :

  • 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é
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole Web Deploy (TCP 8172)
    • Protocole HTTP
    • Protocole HTTPS

clip_image023

 

C’est maintenant que la magie commence, lorsqu’on appuie sur le bouton Start.

clip_image024

 

En démarrant, notre contrôleur dispose de toutes les informations pour mettre en place sa propre configuration ainsi que déployer et configurer les rôles File-Server et Management. En consultant sa base de données, il va découvrir que la configuration de ces deux rôles n’a pas encore été réalisée. Il va donc procéder à leur installation. Pour le rôle Management, la liste des composants à installer est relativement courte :

clip_image025

 

Pour le rôle File Server, la liste est nettement plus courte. Si on exclus HostingFile (le file File-Server), l’autre ne nous sont pas inconnus puisque c’est tout simplement le rôle Windows File Server et le sous-rôle File Server Resource Manager.

clip_image026

 

Note : Depuis l’update 6 de la version 2.0, l’architecture Web Sites n’utilise plus de partage pour stocker les certificats des utilisateurs. C’est le service « Certificate Sync Service » présent sur les instances du rôle Font-end qui se charge de stocker ces certificats et de les mettre en œuvre.

Note : Le Scale-Out File Server est incompatible avec le rôle File Server Resource Manager. De ce fait, il n’est pas possible d’utiliser un Scale-out File Server pour héberger notre rôle File Server. Nous devons nous contenter d’un cluster de fichiers à l’ancienne.

Une fois le processus d’installation terminé, on peut constater la configuration suivante dans la console Windows Azure Pack Web Sites.

clip_image027

 

Ce qu’il faut retenir, c’est que notre contrôleur est chargé de réaliser les déploiements mais aussi de fournir les moyens pour que chaque rôle puisse réalise sa mise à niveau / réparation.

Je pouvais pas finir ce billet sans un peu de PowerShell. L’architecture Web Sites dispose de son propre module PowerShell que l’on peut utiliser sur le rôle contrôleur.

Import-Module WebSitesDev

(get-Command -Module WebSitesDev).Count

clip_image028

 

A quand même! 195 commandes, c’est tout un univers. Pour l’instant, une seule nous intéresse :

Get-WebSitesServer | Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image029

 

Donc à ce stade, nos trois rôles sont opérationnels. Nous avons le socle de notre infrastructure Web Sites. prochaine étape, le rôle Front-End.

 

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.