Introduction aux Resources Providers de Windows Azure Pack

Depuis le début de cette longue séance de torture, on parle de cloud, donc de mise à disposition de ressources mutualisées accessibles en libre-service. Pourtant à part le portail, on ne voit pas grand-chose comme ressources mises à disposition. C’est normal, on n’a pas encore abordé le sujet des « Resources Providers ». Windows Azure Pack est modulaire et extensible. Toute la richesse du produit se situe dans les « Ressources providers » mis à disposition par Microsoft et ses partenaires, voire ceux que l’on voudrait développer soit même. Pour cette séance de torture, on va se focaliser sur un ensemble dit « Core », essentiel au bon fonctionnement de Windows Azure Pack, bref plein de choses dites « sous la moquette ». Commençons par voir ceux que nous avons à disposition avec un peu de Powershell. Avant d’en introduire de nouveaux, on va commencer par traiter ceux qu’on a sous la main avec la commande Get-MgmtSvcResourceProvider. Pour cela, quelques prérequis sont nécessaires.

Pour commencer on va utiliser le module Windows Azure Pack Administration (MgmtSvcAdmin) et non plus le module Windows Azure Pack Configuration (MgmtSvcConfig). Après, c’est un peu comme une recette de cuisine mais en Powershell car faut pas compter sur une quelconque interface graphique. Un soupçon de credential stocké dans un objet de type System.Security.SecureString puis un peu de get-MgmtsvcNamespace pour construire les URL de connexion pour le Web Service AdminAPI et le site web d’authentification des administrateurs, le tout exécuté dans la marmite du serveur « Privilégié ». Avec tout-ça, j’ai pu négocier un token JSON que je vais pouvoir aller présenter auprès du Web Service AdminAPI. Normalement, jusque-là, c’est des révisions, à la limite ça pique un peu. Pour commencer, j’ai volontairement limité le contenu retourné par la commande Get-MgmtSvcResourceProvider, histoire de poser un peu le tableau.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator », $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = « https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)« 

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = « https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)« 

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$AllRPs | Select Name, DisplayName | Format-Table -AutoSize

clip_image001

Donc, il y a seulement trois « Ressources Providers » sur ma plateforme. C’est normal. Pour faire simple, disons que ces trois-là forment un noyau autour duquel viendront se greffer les suivants. Un « Resource Provider », c’est un peu plus que de simples extensions pour les portails des locataires et administrateurs. Les Virtual Machines, les Web Sites, bases SQL sont aussi des « Resources Providers ». Ils viennent se greffer dans Windows Azure Pack pour apporter de nouvelles fonctionnalités. Certaines seront visibles dans les différents portails, d’autres non (cas de nos trois premiers). Pourtant tous vont devoir communiquer avec Windows Azure Pack pour :

  • Permettre aux administrateurs de gérer les ressources mises à disposition des locataires
  • Permettre à nos locataires de souscrire a des ressources et de suivre leur usage
  • Permettre à nos locataires de suivre les usages de ses ressources
  • Gérer la consommation des ressources par rapport aux quotas
  • Mettre à disposition les données de supervision aussi bien à l’exploitant qu’au locataire

Prenons un exemple concret avec le « Resource Provider » SQLSERVER que nous introduirons prochainement. Pour communiquer avec Windows Azure Pack, il va s’exposer sous un certain nombre d’URL nommées « Endpoint » :

  • Administrator Endpoint : C’est lui qui va recevoir les requêtes émises depuis l’API de gestion de Windows Azure Pack (AdminAPI). Lorsqu’un administrateur configure un plan (abonnement) pour proposer du SQL Server en PaaS à la souscription, derrière, le « Resource Provider » nommé SQLSERVER recevoir la demande sur ce « Endpoint ». Pour faire simple, c’est ce que l’administrateur de Windows Azure Pack voit dans le portail lorsqu’il configure les ressources de type SQL Server ».
  • Tenant Endpoint : C’est lui qui va traiter les requêtes en provenance du Tenant API (via le Tenant Public API) . Lorsqu’un utilisateur va vouloir souscrire à un plan contenant des ressources de type SQLSERVER, c’est lui qui va être à la manœuvre. Le Tenant Portal va demander via le Tenant Public API de souscrire à un abonnement via le Tenant API. Ce dernier va alors relayer la demande au « Resource Provider » SQL Server.
  • Notification Endpoint : C’est auprès de lui qu’on vient gérer la souscription (état, statuts des ressources) à une ressource donnée ainsi qu’assurer le suivi de sa consommation (quotas).
  • Usage Endpoint : Enfin, s’il y a suivi des usages, il y aura nécessairement exposition des données de facturation. A ce niveau, on parle de « metrics », pas encore de facturation. Pour parler de facturation, encore faut-il avoir positionné un prix sur la ressource mise à disposition.

Note : En réalité, il y en a un cinquième mais il ne nous intéresse pas pour le moment.

On parle de Web Services, allons voir un peu à quoi cela ressemble. J’ai conservé ma variable $AllRPs, j’ai juste besoin de détailler un peu le contenu des attributs AdminEndpoint et TenantEndpoint. Au passage, j’ai piqué l’astuce ci-dessous chez pour récupérer et formater les URL.

$AllRPs | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}} | Format-Table -AutoSize

clip_image002

Je me suis volontairement limité aux URL correspondant au AdminEndpoint et TenantEndpoint car c’est le sujet qui nous occupe pour cette séance de torture. Pour vous donner une idée voilà à quoi ressemble une installation de Windows Azure pack en mode (Next-Next-Next tout sur la même machine à la barbare). Ça promet quelques « nervous breakdown » à base de certificats et Web Services. Une séance de torture des plus habituelles nous attend donc.

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}},@{e={$_.HealthCheckEndpoint.ForwardingAddress}},@{e={$_.NotificationEndpoint.ForwardingAddress}}

clip_image003

Donc chaque « Resource provider » qui sera ajouté par la suite sur la plateforme viendra annoncer ses différentes URL.

Un « Resource Provider » comme celui de SQL Server que nous traiterons prochainement va donc venir se greffer sur nos premiers « Resources Providers ». Ces premiers « Resources Providers » sont un peu un bus de communication pour gérer les usages, la souscription, la supervision et le Marketplace proposé à nos locataires. A ce stade, de la séance de torture, on peut déjà en déduire que :

  • Toute installation d’un nouveau « Resource Provider » implique qu’on viendra corriger les URL par défaut
  • Chaque « Resource Provider » étant représenté par un site web avec un certificat auto-signé associé, on sait ce qu’il adviendra.
  • Tous les « Resources providers » s’installent uniquement sur le serveur « Privilégié »

Les trois « Resources Providers » que nous avons sur notre plateforme sont essentiel au bon fonctionnement de Windows Azure Pack. Sans eux, les futurs « Resources Providers » que nous installerons ne fonctionneront pas. Pour faire simple, Ces « Resources Providers » serviront à :

  • Monitoring : Les administrateurs auront une vue consolidée du monitoring de toutes les ressources mises à disposition
  • Monitoring : Les locataires auront une vue consolidée du monitoring de toutes les ressources auxquelles il a souscrit
  • Usage Service : Les administrateurs pourront gérer les quotas associés à chaque « Resource Provider » et avoir une idée du capacité planning de la plateforme
  • Usage Service : les locataires pourront suivre la consommation des ressources qui ont été mises à sa disposition
  • Marketplace : Les locataires auront accès à un Marketplace

On va donc commencer par passer un peu de temps en leur compagnie et s’assurer qu’ils puissent fonctionner avec des nom DNS et de véritables certificats. De ce côté-là, Windows Azure pack, c’est un peu un service de torture à la demande :). Ce qui est bien, c’est que c’est très bien documenté chez Microsoft : Update FQDNs for Resource Providers. Je vais donc reprendre la méthodologie et expliquer un peu en détail.

Pour simplifier le billet, j’ai développé le script RPUPDATE.PS1 disponible ici. C’est le même principe que le script développé par Microsoft. Le truc, c’est que chaque « Resource Provider » va utiliser la même URL de base (logique car hébergé sur notre serveur « privilégié ») mais avec des ports différents. Jusque-là, c’est simple.

Resource Provider

Port par défaut

Monitoring

30020

Marketplace

30018

UsageService

30022

 

Là où cela se complique, c’est que chaque « Resource Provider » n’a pas une URL à exposer mais jusqu’à cinq. Pour nos trois premiers « Resource Providers », ils ne permettent pas de consommer de ressources, donc logiquement, pas besoin de monitoring à remonter aux utilisateurs, encore moins de suivi des usages. Notre tableau s’en trouve donc un peu simplifié. Ce ne sont donc que des simples extension des portails de Windows Azure Pack.

Resource Provider

Type de EndPoint

URL

Monitoring AdminEndpoint

https://wappriv//30020/

  TenantEndpoint

https://wappriv//30020/

MarketPlace AdminEndpoint

https://wappriv//30018/

  TenantEndpoint https://wappriv//30018/subscriptions
UsageService AdminEndpoint

https://wappriv//30022/

  TenantEndpoint

https://wappriv//30022/

 

Donc pour nos trois « Resource Provider », nous devons :

  1. Charger la configuration du « Resource Provider » avec la commande Get-MgmtSvcResourceProvider
  2. Mettre à jour les URL des Endpoints avec un nouveau FQDN commun dans l’objet Powershell retourné par la commande précédente
  3. Sauvegarder la configuration du « Resource provider » avec la commande Set-MgmtSvcResourceProvider
  4. Remplacer le certificat auto-signé

Commençons avec le « Resource Provider » du Monitoring. J’ai choisi de mutualiser tous les « Resources Providers » sur une même URL de base : https://adminapi.Windowsazurepack.fr. Cela implique déjà que le site web utilise MgmtSvc-Monitoring bien le bon certificat. Sinon, c’est un coup à se taper des « Nervous breakdowns comme ils disent ».

clip_image004

Ceci-fait, on peut utiliser mon script RPUPDATE.PS1. Il va générer un jeu d’URL pour chaque Endpoint du « Resource Provider » demandé en utilisant comme base le FQDN passé en paramètre, dans notre cas, « https://adminapi.windowsazurepack.Fr« .

RPUPDATE.PS1 -ResourceProviderName monitoring -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image005

Une fois exécuté, la configuration du « Resource provider » a été mise à jour avec la commande Set-MgmtSvcResourceProvider. Dans l’illustration ci-dessus, on constate que seuls les Endpoints AdminEndpoint et TenantEndpoint sont configurés. C’est normal, ils ne gèrent pas de ressources mises à disposition des utilisateurs finaux.

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web MgmtSvc-monitoring.

Continuons avec celui du Marketplace. Ce qui est rigolo avec celui-là, c’est que le site web associé ne se nomme pas MgmtSvc-Marketplace comme on pourrait s’y attendre mais MgmtSvc-WebAppGallery. Pourquoi? Ben j’en sais rien. Ici encore, on associe notre certificat pour notre url https://adminapi.windowsazurepack.fr.

clip_image006

On réutilise notre script, en indiquant qu’on veut mettre à jour le « Marketplace » cette fois.

RPUPDATE.PS1 -ResourceProviderName marketplace -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image007

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web Mgmtsvc-WebAppGallery.

Et finissons par le site web MgmtSvc-UsageService.

clip_image008

Plus besoin de présenter le script.

RPUPDATE.PS1 -ResourceProviderName usageservice -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image009

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web MgmtsvcUsageService.

 

Pour être sûr, on reprend notre démarche du début pour constater que les Url ont bien été reconfigurées.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator », $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = « https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)« 

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = « https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)« 

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}}

clip_image010

A ce stade, on permet déjà à Windows Azure Pack de fonctionner à minima. Des Web Services situés sur le serveur « public » (Tenant Portal, tenant Public API) sont capables de communiquer avec des Web Services présents sur le serveur « privilégié » (Tenant API, Admin API, Resources Providers) sans avoir de problème de nom d’hôte ou de certificats. Sans eux, la souscription aux différentes ressources ne fonctionnera pas. C’est essentiel dans le prochain billet, on va commencer à rentrer dans le dur du sujet avec la mise en place du « Resource Provider » SQLServer. Vu que c’est la nouvelle année, je suis sympa, la prochaine séance de torture attendra.

 

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.