Le Cloud est un perpétuel recommencement

Le Cloud, c’est une infrastructure et des services en perpétuelle évolution. Dans Azure, historiquement dans les machines virtuelles, on avait la Série A. Avec le temps Microsoft a étoffé son service IaaS en proposant de nouvelles configurations. Avec l’arrivée de la série D, on avait 60% de performances en plus. A cette époque, l’étude comparative de Cloud Spector démontrait l’intérêt de réaliser des migrations technique (qui en plus apportaient un gain financier). Avec DV2, la promesse de Microsoft est de 35% de performance en plus pour un prix inférieur de 5%. Cloud Spector a mis à jour son étude, comparant la série DV1 avec la nouvelle offre DV2.

Bref, ce que nous avons mis en production devra nécessairement être réévalué. Certes, on bénéficie de la baisse continue des prix. A chaque fois qu’un des grands acteurs du Cloud baisse les prix, les autres s’alignent ou surenchérissent. C’est en réévaluant nos besoins par rapport aux nouvelles capacités de la plateforme qu’on peut réaliser les meilleures optimisations techniques et financières. Avec la Série Av2, l’histoire recommence.

Prochainement, c’est notre approche de la haute disponibilité que nous allons devoir remettre en cause. Historiquement, le seul moyen que nous avions de garantir la disponibilité d’une machine virtuelle (et donc un SLA de la part de Microsoft) passait par les Availability Set qui permettait de répartir deux ou plusieurs instances de notre machine virtuelle dans des domaines de panne et des domaines de maintenance distincts. Grand merci à l’article de Samir Farhat sur le sujet. Avec cette nouvelle fonctionnalité, la haute disponibilité dans Azure deviendra beaucoup plus abordable. Certes, je ne pense pas que cela concerne tous les workloads et qu’il faudra par exemple continuer à utiliser des Availability Sets pour un cluster SQL en Always-On. Comme l’indique Samir Farhat, beaucoup de clients ont refusé de migrer certains workloads à cause des contraintes financières de la haute disponibilité dans Azure.

Plus généralement, dans le Cloud, la notion d’état stable n’est qu’une notion temporaire entre deux cycles d’optimisations techniques & financières.

clip_image001

Notre problème, ce sera de savoir comment évaluer les opportunités techniques et financières qui se présentent à nous. Si on regarde une plateforme comme Microsoft Azure, en 2015, c’est plus de 500 nouveaux services ou évolutions de services mis à disposition des clients. Evaluer toutes les possibilités d’évolution qui se présentent à nous n’a pas de sens :

  • Une évaluation individuelle pour chaque application ne fera que complexifier chaque application
  • Une évaluation individuelle augmentera le nombre de service distincts à gérer et ne va pas aller dans le sens de la gouvernance

Nous n’allons donc pas évaluer toutes les possibilités mais retenir un ensemble de fonctionnalités qui peuvent être généralisées pour un ensemble de workloads. Plus nos workloads pourront partager de services et fonctionnalités en commun, il deviendra simple de profiter des effets d’échelle aussi bien du point de vue de la performance que des prix. Conclusion, le Cloud, ce n’est pas qu’une transformation technique, c’est aussi une transformation de la manière dont nous allons organiser ceux-ci ainsi que l’organisation pour les gérer. C’est une nouvelle approche de l’infogérance qui se dessine.

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (3/3)

Maintenant, les détails qui comptent. On a noté que notre certificat a une durée de vie de trois mois. Mais comment alors sera-t-il renouvelé ? Réponse, grâce à un WebJob. Le problème, c’est qu’au terme de la mise en œuvre, ce WebJob est arrêté, donc aucune possibilité que le renouvellement automatique fonctionne.

clip_image001

 

Une fois démarré, ce sera beaucoup mieux.

clip_image002

 

Par ce que le diable se cache toujours dans les détails, essayons de lire les logs associés à la Web Extension Lets’ Encrypt. Il doit manquer quelque chose :

clip_image003

 

Ce qui manque, c’est un repository pour déverser les logs. Ce que nous dit le message, c’est que la configuration de la Web Application ne fournit pas les informations nécessaires pour la Web Extension. Ça tombe bien, j’avais justement prévu un compte de stockage pour cela :

Get-AzureRmStorageAccount -ResourceGroupName DemoLetsencrypt -StorageAccountName DemoLetsencryptlogs

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName DemoLetsEncrypt -StorageAccountName DemoLetsEncryptLogs

clip_image004

 

Ce qui nous reste à faire, c’est de formater convenablement les informations dans cela dans une Application Settings nommé :

AzureWebJobsDashboard avec le contenu suivant :

DefaultEndpointsProtocol=https;AccountName=DemoLetsencryptlogs;AccountKey=<Contenu de ma clé primaire>;

clip_image005

 

Au passage on découvre que les paramètres que nous avons renseignés lors de la configuration de la Web Extension. Ne reste plus qu’à les sauvegarder et redémarrer le Web Job. Si la chaine de connexion est correctement formatée, alors, on devrait trouver la journalisation de l’extension dans le Storage Account que nous avons provisionné lors de la mise en place des prérequis.

clip_image006

 

Si on regarde dans la WebJob elle-même, on peut consulter ses logs directement à ce niveau.

clip_image007

 

Au passage, les logs vont vous apprendre un dernier truc. Pensez à activer l’option « Always-On » sinon en cas de crash du compute qui porte notre Web App, notre WebJob ne redémarre pas automatiquement. Donc pensez à activer cette option.

clip_image008

 

Voilà ce qui clos notre mise en œuvre de Let’s Encrypt dans le Paas Azure.

­

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (2/3)

Après la mise en place des prérequis, passons à la configuration de Let’s Encrypt. Techniquement c’est une extension de la Web Application. C’est un plug-in que l’on va venir positionner.

clip_image001

 

Une fois l’extension ajoutée, on la retrouve dans la liste.

clip_image002

 

En cliquant sur la Web Extension, on peut avoir quelques informations et surtout l’accès au bouton « Browse ».

clip_image003

 

On obtient ainsi l’accès à la page de configuration de la Web Extension. C’est maintenant que cela commence à devenir intéressant.

clip_image004

 

Pour le premier paramètre, c’est simple, c’est notre tenant Azure Active Directory. La Web Extension va avoir besoin d’importer le certificat nouvellement généré dans la configuration de la Web Application. Le problème, c’est qu’une Web Extension n’a pas d’identité au sens propre. On va donc avoir besoin de lui en créer une. On y viendra. Pour l’instant, on a juste besoin du Tenant Azure Active Directory.

clip_image005

 

Pour le SubscriptionID, on va le retrouver simplement avec la commande Get-AzureRmContext :

clip_image006

 

C’est maintenant que cela se complique. Première chose dont on va avoir besoin, c’est le nom sous lequel la Web Application va se présenter à l’authentification devant le tenant Azure Active Directory. Avec un peu de PowerShell, on va extraire l’information :

$WebApp = Get-AzureRmWebApp -ResourceGroupName DemoLetsEncrypt

$WebApp

clip_image007

 

Ce qui va nous intéresser plus précisément c’est le hostname sous lequel le site web va être référencé comme application dans Azure Active Directory.

$WebApp.Hostnames

$Uri = $WebApp.HostNames | Select -Last 1

$Uri

clip_image008

 

$Uri = « https://$($uri)« 

$AppName = « DemoLetsEncrypt »

$Password = ‘{P@ssw0rd123}’

$NewApp = New-AzureRmADApplication -DisplayName $AppName -HomePage $uri -IdentifierUris $uri -Password $password

$NewApp

clip_image009

 

Il ne nous reste plus qu’à créer un nouveau Service Principal (un peu compte un compte de service du vieux temps du On-Premises) :

New-AzureRmADServicePrincipal -ApplicationId $Newapp.ApplicationId

clip_image010

 

Puis de lui affecter des permissions sur notre application nouvellement créée :

New-AzureRmRoleAssignment -RoleDefinitionName « Contributor » -ServicePrincipalName $NewApp.ApplicationId

clip_image011

 

Dernière chose dont nous allons avoir besoin, c’est l’ApplicationID associé à notre nouvelle application :

$NewApp.ApplicationId

clip_image012

 

Pour finaliser la configuration, nous avons juste besoin d’une permission pour l’application sur la Web Application

clip_image013

 

Si vous creusez un peu vous découvrirez les permissions minimales nécessaires pour cela. Prochaine étape, configurer les permissions sur le groupe de ressources ou plus précisément sur la Web Application.

clip_image014

 

Reste plus qu’à cliquer sur le bouton « Next ». Si les permissions sont les bonnes alors cela devrait fonctionner. L’extension est bien configurée mais pour l’instant le certificat n’est pas encore généré.

clip_image015

 

Pour générer notre certificat, il manque quelques informations. Cliquons donc sur le bouton « Next ». La première, ce sera de sélectionner le hostname pour lequel nous allons générer le certificat. Au moment de la rédaction de cet article, Let’s Encrypt ne propose pas encore la prise en charge des certificats Wildcard (bientôt).

clip_image016

 

Pour délivrer un certificat, nous avons besoin de fournir une adresse de messagerie et cliquer sur le bouton « Request and Install certificate ».

 

Remarque : Let’sEncrypt impose une limite, celle de ne de délivrer que cinq certificats par semaine pour un même domaine DNS. Il faudra utiliser le staging slots pour contourner cette limitation.

 

C’est l’heure du tour de magie. Si tout se déroule sans accros (un bon plan), alors nous devrions avoir le résultat ci-dessous :

clip_image017

 

Remarque : Faites attention à la date d’expiration du certificat. Oui, les certificats délivrés par l’autorité Let’s Encrypt ont une durée de vie de trois mois. Nous allons y revenir.

 

Nous pouvons revenir sur l’interface du portail Azure et constater la présence du certificat dans la Web Application

clip_image018

 

Ne nous reste plus qu’à mettre en place le binding

clip_image019

 

Le binding est maintenant en place

clip_image020

 

Et effectivement, le site web répond bien en HTTPS sur le Custom Domain configuré.

clip_image021

 

Au passage, le truc est propre puisque voilà le résultat au test SSL de Qualyst :

clip_image022

 

Maintenant, plus d’excuse pour les développeurs à continuer d’utiliser des certificats auto-signés. Il ne nous reste plus qu’à gérer les points de détails.

 

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

Mise en oeuvre de Let’sEncrypt dans le PaaS Azure (1/3)

Le cloud, c’est un jeu de lego. Pour produire un service, on va combiner différents services. Ce qui est intéressant, c’est qu’il n’y a pas une seule combinaison mais bien plusieurs. Plus les Plateformes développent leurs services, plus on dispose de nouvelles combinaisons.

Dans ce jeu de Lego, on retrouve souvent des certificats. Lors du déploiement de solutions dans Azure, on va utiliser des solutions comme Azure Key Vault pour y stocker nos certificats. C’est un sujet que j’ai déjà évoqué dans plusieurs billets sur Azure Key Vault. Dans Azure, on peut aussi demander de générer nos propres certificats avec le App Service Certificate. Ce service permet de générer automatiquement (ainsi que renouveler) nos certificats. Au moment d’écrire ce billet, le service App Service Certificate ne propose que GoDaddy comme fournisseur. C’est une démarche intéressante mais pour nos développeurs, c’est une solution payante. En toute logique, nos développeurs vont se tourner vers des certificats auto-signés (beurk). Pourtant, en creusant un peu dans les tréfonds des Web Application, on peut trouver des solutions bien plus élégantes. Le projet Let’s Encrypt et celle-ci et est disponible sous forme de Web App Extension dans les App Services. C’est un peu moins intégré que le App Service Certificate mais ce n’est pas impossible à mettre en œuvre. C’est le sujet de ce billet : Comment utiliser la solution Let’s Encrypt avec Paas App Service. Ce billet sera organisé en plusieurs parties :

Dans mon introduction, j’ai parlé de Web Application. Donc logiquement on connait déjà les prérequis ou presque :

  • Un groupe de ressources histoire de regrouper nos ressources.
  • Un Service Plan qui va porter notre Web App (subtilité, il nous faudra un Service Plan nous autorisant d’utiliser le SSL et les Custom Domains)

 

Commençons par créer notre groupe de ressources avec simple ligne PowerShell :

New-AzureRmResourceGroup -Name « DemoLetsEncrypt » -Location « West Europe »

clip_image001

 

Ci-dessous la configuration retenue pour la Web Application.

clip_image002

 

Dans ma configuration, je n’ai pas retenu d’implémenter App Insight. A l’heure où j’écris ce billet, App Service est encore en Preview et pas disponible dans toutes les régions Azure. La subtilité, c’est le choix de l’App Service Plan. J’ai retenu le plan B1 qui est le premier à proposer le support des Custom Domains ainsi que celui des certificats.

clip_image003

 

Avec un peu de PowerShell, on peut retrouver les ressources provisionnées :

Get-AzureRmResourceGroup -Name DemoLetsEncrypt | Find-AzureRmResource

clip_image004

 

Avant de poursuivre, on va mettre en place les prérequis pour le Custom Domain. Dans ma zone DNS « Simplebydesign.fr », j’ai créé un enregistrement CNAME pour le nom « DemoLetsEncrypt » qui pointe sur le nom DNS Azure de mon site « demoletsencrypt.azurewebsites.net ». Pour instant le site ne répond qu’au seul hostname « demoletsencrypt.azureWebsite.Net ». On va juste lui en adjoindre un nouveau :

clip_image005

 

Si on n’a pas été patient dans la propagation de la zone DNS, cela va échouer. A noter que dans Azure, on peut contourner ce genre de problème et obtenir un service plus intégré en utilisant le service DNS d’Azure. Techniquement, un sous-domaine DNS de la zone « simplebydesign.fr » serait délégué au service Azure DNS qui se chargera de la gestion de cette zone. Avec cette approche, nous pourrons créer l’enregistrement DNS depuis Azure et nous assurer de sa propagation dans les secondes qui suivent mais revenons à notre billet. Lorsqu’on est patient, cela fonctionne.

clip_image006

 

Quelques secondes plus tard, notre site web répondra à son nom Azure mais aussi à son nouveau Custom Domain

clip_image007

 

Dernière étape dans nos prérequis, la mise en place d’un Storage Account. Nous allons en avoir besoin avec Lets’Encrypt pour permettre à la Web Extension d’y déverser ses logs :

New-AzureRmStorageAccount -ResourceGroupName « DemoLetsEncrypt » -AccountName « demoletsencryptlogs » -Location « West Europe » -SkuName « Standard_LRS » -Kind « Storage »

clip_image008

 

Remarque : Pour faire simple, j’ai utilisé un Storage Account standard, je n’ai pas cherché à optimiser avec du stockage chaud/froid. Ce n’est pas le but de ce billet.

 

Voilà pour les prérequis à la mise en œuvre de la Web Extension de Lets Encrypt. Prochaine étape, son installation et sa configuration.

 

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

Azure Site Recovery avec Hyper-V 3/3

Dernière étape de notre découverte d’Azure Site Recovery avec Hyper-V. A ce stade, nous avons une synchronisation de notre machine virtuelle. Plus précisément, c’est Hyper-V réplica qui se charge de maintenir une copie cohérente de notre machine virtuelle. Notre dernière étape, c’est de configurer la politique de Failover.

clip_image001

On peut disposer d’autant de Recovery Plan qu’on veut mais une machine virtuelle ne peut être liée qu’à un seul Recovery Plan. Dans mon cas, il ne concerne qu’une seule machine virtuelle.

clip_image002

Notre premier Recovery Plan est créé. Dans l’illustration ci-dessous, on constate qu’il n’a jamais été testé. C’est la faiblesse de tous nos plans de DRP. Ce qui est bien avec Azure Site Recovery, c’est qu’on peut le tester à blanc.

clip_image003

Dans le portail, lorsqu’on se positionne sur un Recovery Plan, on peut utiliser l’option « Test Failover ». L’objectif est de valider qu’Azure Site Recovery sera bien en mesure de reconstruire une machine virtuelle consistante sur un réseau Azure isolé. Nous pouvons donc le tester tant qu’on veut.

clip_image004

Attention tout de même, tous les scénarios d’implémentation ne proposent pas le même niveau de fonctionnalité. La page Technet Failover in Site Recovery documente clairement quels scénarios autorisent quels types de failover. Dans mon contexte (Hyper-V), le test Failover est bien possible. Pour le réaliser, il n’a besoin que d’une seule information : un VNET sur lequel associer la future interface réseau. Bien entendu, celui que j’ai sélectionné ne dispose ni d’Azure Gateway ou Peering. Il est donc totalement isolé.

clip_image005

Après, c’est un job en cours d’exécution. On n’a qu’à le suivre.

clip_image006

On note la notion de groupe, lorsqu’on a plusieurs VM dans une politique de failover, on peut décider l’ordre de remise en ligne. Logiquement dans ce groupe, mon contrôleur de domaine est le premier. Si j’avais d’autres machines virtuelles, je pourrais séquencer le redémarrage.

clip_image007

Avec un peu de patience, on arrive au résultat suivant :

clip_image008

Ce qu’il est intéressant de noter, c’est qu’entre l’initialisation de l’action et le démarrage de la machine virtuelle, il ne s’est écoulé trois minutes. Le temps de bascule a donc été très court. On considère que le test est concluant quand la machine virtuelle a bien réussi à démarrer. Nous avons été capable d’utiliser le dernier état consistant stocké dans Azure Site Recovery. On va clore le test.

clip_image009

 

Et indique quelques informations sur notre test avant de demander de faire le ménage.

clip_image010

Du point de vue du job, l’opération est totalement terminée.

clip_image011

Voilà pour le test. Mais tester à blanc, ça ne vaut pas grand-chose. Ce dont on a besoin c’est de valider qu’on est bien capable de reprendre le service dans Azure et de revenir On-Premises sans encombre. Pour cela, nous allons organiser un test de failover planifié. Cela signifie que sur notre hôte Hyper-V la machine virtuelle sera inactive. On va donc procéder cette fois à un « Planned Failover ».

clip_image012

Par rapport au Test Failover, cela se présente exactement de la même manière. La seule différence, c’est qu’on n’a pas à indiquer le VNET à utiliser, c’est une information qui a déjà été communiquée lors de la mise en place de la politique de réplication.

clip_image013

Par contre dans le Job, on voit bien une différence. Il commence par arrêter notre machine virtuelle et réaliser une dernière synchronisation delta vers Azure.

clip_image014

Entre l’initialisation de la bascule et la mise en ligne de la machine virtuelle, il ne s’est écoulé que cinq minutes. Pour un service de reprise sur incident As a service, c’est plutôt pas mal.

clip_image015

Logiquement, je devrais avoir une machine virtuelle dans la souscription. C’est effectivement le cas, elle a été provisionnée dans le groupe de ressources du même nom que la machine virtuelle basculée. C’est un des aspects qu’on ne maîtrise pas (au moment de la rédaction de ce billet).

clip_image016

Au passage sur mon hôte Hyper-V, ma machine virtuelle est bien arrêtée. Ce qui est intéressant, c’est que le groupe de ressource ne contient que les ressources machines virtuelles et interface réseau. C’est logique, le VHD a été restaurés dans le Storage Account asrstoragerestore01, celui que j’ai indiqué lors de la configuration d’Azure Site Recovery.

clip_image017

Note à ce niveau, ma machine virtuelle n’a qu’un seul disque OS, pas de disque de données. On-Premises, ce n’est pas un problème. Par contre dans Azure, ce n’est pas une bonne pratique. Avant de répliquer des machines virtuelles vers Azure, Quelques bonnes pratiques à respecter

  • Laisser le disque D:\ libre, on va en avoir besoin dans Azure
  • Utiliser obligatoirement des volumes de données VHD distincts pour héberger les données de vos applications

Techniquement, ma machine virtuelle est opérationnelle dans Azure. Mon planned Failover s’est déroulé sans problème, on va rebasculer On-Premises mais avant cela un bonus. Si on creuse un peu dans les menus, on va trouver une option qui va nous intéresser au plus haut point :

clip_image018

L’idée c’est qu’une fois la machine virtuelle répliquée vers Azure, on finalise complètement sa migration. La machine virtuelle n’est plus gérée par Azure Site Recovery. On peut donc utiliser Azure Site Recovery comme outil de migration. Ce sera le sujet d’un autre billet. Pour l’instant, nous allons valider la bascule avec un Commit. Cela signifie que l’on perd le contenu de nos Recovery Points. C’est logique. Par contre, cela signifie aussi qu’il faudra reconstruire le Recovery Point et repartir sur une réplication initiale. Donc à moins d’avoir de la bande passante à revendre, on ne va pas s’amuser à basculer les machines virtuelles entre On-Premises et Azure tous les matins.

clip_image019

Ici encore, l’opération de Commit est un job que l’on peut suivre.

clip_image020

A ce stade, on va repartir On-Premises en déclenchant de nouveau un « Planned Failover ». On notera que le Commit est maintenant grisé.

clip_image021

Le processus de failback ressemble beaucoup au process de failover à une exception.

clip_image022

 

On a le choix du scénario pour réaliser la bascule :

  • Minimiser le downtime
  • Réaliser un download full

Ce qui est intéressant c’est la case à cocher qui permet de recréer les machines virtuelles. On l’utilisera si on a perdu notre serveur Hyper-V. Juste un détail, dans ce sens de réplication, c’est du trafic descendant d’Azure, donc facturé. Le choix du full download n’est donc pas sans conséquences. Ça veut dire aussi qu’on peut utiliser ASR pour migrer d’un Datacenter à un autre, … Après, on connait, c’est un job comme un autre :

clip_image023

On-Premises, on peut suivre le processus dans notre console Hyper-V :

clip_image024

C’est presque fini.

clip_image025

Y a plus qu’à valider la migration. Cette opération de validation est nécessaire pour indiquer à l’agent Azure Site Recovery qu’il peut inverser le sens de réplication pour maintenant resynchroniser vers Azure.

clip_image026

 

En regardant plus précisément les détails du job de failback, on constate que le temps total d’opération a été de 48 minutes.

clip_image027

Cependant, le downtime du service est lui de 20 minutes. Dans la console Azure Site Recovery, on peut constater que le status du replicated Item est revenu à « On-premises ».

clip_image028

 

Sur notre serveur Hyper-V, on peut constater que le processus de synchronisation est de nouveau reparti vers Azure.

clip_image029

 

A noter qu’on recommence le processus de réplication depuis le début. C’est donc une réplication complète qui débute.

Voilà pour cette découverte d’Azure Site Recovery.

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

Azure Site Recovery avec Hyper-V 2/3

La mise en place étant maintenant terminée, passons à la mise en place de la politique de réplication. Celle-ci va concerner un site Hyper-V donc tous les serveurs Hyper-V qui y sont associés. Conclusion, si on veut plusieurs politiques, il faudra plusieurs groupes et donc répartir nos Hyper-V au sein de ces groupes.

clip_image001

La destination, c’est Azure (en même temps, on s’en serait douté). Plus précisément, la destination sera une souscription Azure (qui peut être différente de celle d’Azure Site Recovery), pour un mode de déploiement donné et un Storage Account. Voilà un premier point d’attention. Considérons les limites d’un Storage Account Standard avec ses 20000 IOPS de 8K et le fait que nos machines virtuelles seront composées d’au moins deux disques VHD. Sachant qu’un VHD ne peut pas consommer plus de 500 IOPS, combien de machines virtuelles puis-je placer dans un même Storage Account? La limite sera de vingt. Donc si on a plus de vingt disques VHD, il faudra plusieurs Storage Accounts et donc plusieurs politiques de réplication. Cette règle est importante car nos IOPS sont capés dans Azure. A noter qu’il n’y a pas de contrainte pour le Virtual Network. Il est possible d’appliquer une configuration générique pour toutes les machines virtuelles à répliquer ou de l’individualiser par machine virtuelle. Depuis peu, cette individualisation nous permet par exemple d’exclure des volumes des machines virtuelles à protéger.

clip_image002

Au passage, puisque la fonctionnalité Azure Storage Encryption est passée GA il y a quelques jours autant la configurer maintenant. Activée avant la réplication, tous les données stockées seront automatiquement chiffrées. Autant en profiter, c’est gratuit.

clip_image003

Passons aux machines virtuelles. L’assistant nous liste toutes les machines virtuelles hébergées sur les hôtes Hyper-V composant notre site Hyper-V. Y a qu’à faire son marché et sélectionner la ou les machines virtuelles qui nous intéressent.

clip_image004

 

A noter que si nous déplaçons une machine virtuelle sur l’hôte Hyper-V (ou cluster), il faudra un peu de temps avant de la voir apparaitre dans cette liste. Pour chaque machine virtuelle, on doit préciser le système d’exploitation et identifier le disque OS. Le système d’exploitation est nécessaire car dans Azure, le coût d’une machine virtuelle n’est pas le même entre Linux et Windows.

clip_image005

A ce stade, on peut constater un point important à prendre en considération. Ma machine virtuelle est composée d’un unique disque OS, sans aucun disque de données. Avec Azure, c’est Mal. Mal car sur ce disque OS, nous bénéficions d’un coup de boost avec un cache en lecture/écriture. Le problème, c’est que ce cache utilise la mémoire de l’hôte Hyper-V dans Azure. En cas de crash de ce dernier, on risque que les données de notre disque OS ne soient plus cohérentes. Derrière, le risque, c’est que notre machine virtuelle ne démarre plus. My two cents, corrigez ces points avant d’entamer la réplication, on évite des manipulations compliquées dans Azure. Ceci dit, notre politique de réplication est terminée.

clip_image006

 

Dans ma configuration, la réplication commence immédiatement en cliquant sur le bouton « Enable replication ».

clip_image007

 

C’est aussi maintenant qu’on commence à découvrir les contraintes d’Azure Site Recovery. Histoire de vous éviter des déconvenues, en voilà une liste (non exhaustive) :

  • Pas de prise en charge des disques SCSI et donc du contrôleur qui va avec dans nos machines virtuelles
  • Pas de prise en charge des disques VHDX partagés (pas cool, super comme fonctionnalité)
  • Pas de prise en charge des disques connectés à un contrôleur Fiber Channel virtuel
  • Pas de volume VHD de plus de 1To : Can’t recover VMs in Azure with volumes greater than 1TB? Use Storage Spaces!
  • Les volumes VHDX dynamiques seront convertis en VHD de taille fixe
  • Pas plus de 16 volumes VHD par machine virtuelle
  • Une seule adresse IP par interface réseau (donc bye bye les clusters)
  • Pour Linux, la configuration en DHCP doit être réalisée manuellement avant la mise en protection
  • Le Storage Spaces est bien utilisable mais attention, les VSS-Based Snapshots ne sont pas supportés à ce jour pour Hyper-V
  • L’utilisation de Storage Spaces n’est pas possible dans les scénarios VMWARE & serveurs physique

Pour chaque mise en place de la production d’une machine virtuelle, nous allons avoir des Jobs. Ce qui est intéressant, c’est de suivre l’activation de la protection et la finalisation de la protection (donc fin du processus de réplication initial). Dans mon cas, à peu près 40 minutes pour réaliser l’opération. D’un point de vue réseau, c’est à peu près 10Go uploadés à un rythme de 32Mb/Seconde. Normalement, ma connexion Fibre devrait me permettre d’aller plus vite. Le problème, c’est Azure. Je ne peux pas aller plus vite que lui, surtout si je n’utilise pas de connexion VPN site à site / ExpressRoute permettant de garantir la bande passante et la latence

clip_image008

 

Dans la console Azure Site Recovery, chaque machine virtuelle protégées et un Replicated Item dont on peut suivre l’état de synchronisation.

clip_image009

 

Après, il est aussi possible de suivre l’avancement des opérations en PowerShell comme illustré ci-dessous pour la réplication initiale :

clip_image010

Par contre, attention les commandes PowerShell ne sont pas disponibles pour tous les scénarios. Par exemple, au moment de l’écriture de ce billet, il n’est pas encore possible de les utiliser pour les scénarios VMWARE et serveurs physiques. Pendant la réplication, j’ai observé ce qui se passe sur mon hôte Hyper-V. Premier constat, c’est Hyper-V Replica qui est à la manœuvre. On ne constate dans l’illustration ci-dessous :

clip_image011

 

Par expérience, je sais que cela consomme des IOPS et du CPU (compression). Donc si je parallélise trop de machines virtuelles en même temps, je vais juste assassiner mon stockage. Donc avant de vous lancer dans la protection de l’intégralité des machines virtuelles hébergées sur votre hôte Hyper-V, je vous conseille de revoir vos inputs du capacity planning. La réplication initiale des machines virtuelles consomme bien plus d’IOPS que les réplications delta opérées après. Du point de vue réseau, une rapide analyse dans le moniteur de ressources de mon Hyper-V ont mis en évidence les flux réseau. Je sais que c’est de l’Hyper-V réplica, donc du HTTPS sur le port 443. Une rapide recherche avec mon vieil ami NETSTAT -ano | FindStr « :443 » m’identifie bien des flux TCP en cours pour le processus identifié avec l’ID 5184.

clip_image012

 

Avec un « Get-Process », on retrouve le processus en question. On constate qu’il consomme aussi beaucoup de CPU.

clip_image013

 

Au terme du processus de réplication initiale, la consommation CPU / IOPS va se réduire car on passe en mode de réplication Delta. Le truc ici, c’est de toujours être capable de répliquer nos snapshots vers Azure plus vite que nous ne les accumulons. Sinon, ça ne va pas le faire. Dans mon cas à moi, la protection de ma petite machine virtuelle a nécessité près de quarante minutes.

clip_image014

 

Note machine virtuelle est maintenant protégée. Prochaine étape, on va faire fumer la connexion Internet pour basculer la machine virtuelle vers Azure pour ensuite la ramener sur son Hyper-V.

­

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

Azure Site Recovery avec Hyper-V 1/3

Azure Site Recovery est un composant intéressant de la plateforme Azure. Je le classe dans la catégorie des composants qui apportent un bénéfice immédiat à notre Datacenter. Pour les autres composants / scénarios d’usage, il faut un peu plus de travail pour pouvoir en bénéficier. Pour certains, l’adoption passera même par une phase de transformation, ce qui nécessite du temps. Azure Azure Site Recovery (ASR pour les intimes), on répond à une problématique immédiate, à savoir comment j’organise mon Plan de Reprise d’Activité.

Le sujet du PRA est vaste. Si on se limite aux problématique techniques, cela consiste à mettre à disposition des ressources (locaux, serveurs, réseau) qui ne seront utilisées qu’en cas de défaillance, autant dire le moins souvent possible. Différentes technologies liées à la virtualisation et au stockage forment la réponse technique. Le problème, c’est le coût de ce ticket d’entrée. Si on raisonne « On-Premises », cela implique de doubler ses infrastructures à commencer par son hébergement. Ce sont donc des mètres carrés à louer à prix d’or à un hébergeur.

ASR permet d’utiliser la plateforme Azure pour réaliser ce PRA avec pour avantage de ne provisionner la machine virtuelle que lorsque l’on déclenchera les opérations de reprise d’activité. D’un point de vue financier, c’est intéressant car on ne paie pas pour le compute des machines virtuelles répliquées car à ce stade, elle n’existent pas. Au moment de l’écriture de ce billet, il existe plusieurs scénarios pour ASR :

  • Répliquer des machines physiques Windows/Linux vers Azure
  • Répliquer des machines physiques Windows/Linux vers un site de repli
  • Répliquer des machines virtuelles VMWARE vers Azure
  • Répliquer des machines virtuelles VMWARE vers un site de repli VMWARE
  • Répliquer des machines virtuelles Hyper-V vers Azure
  • Répliquer des machines virtuelles Hyper-V vers un site repli Hyper-V
  • Répliquer des machines virtuelles Hyper-V gérées par SCVMM vers Azure
  • Répliquer des machines virtuelles Hyper-V gérées par SCVMM vers un site de repli avec SCVMM et Hyper-V
  • Répliquer des machines virtuelles Hyper-V & le stockage SAN vers un site de repli avec SCVMM et Hyper-V

Pour ce billet, on va se contenter du plus simple, à savoir répliquer une machine virtuelle Hyper-V. Derrière c’est la technologie Hyper-V Replica qui est à l’œuvre. L’objectif est d’avoir des snapshots consistants réalisés par l’hôte Hyper-V et une ou plusieurs versions consistantes de nos machines virtuelles prête à démarrer dans Azure en cas de défaillance de la machine virtuelle Hyper-V ou pire de l’hôte Hyper-V voilà pour l’introduction. Avant de rentrer dans la mise en œuvre, on va commander par les prérequis :

  • Une souscription Azure (en même temps, c’est logique)
  • Un groupe de ressources pour regrouper nos ressources
  • Un storage Account que nous allons dédier à Azure Site Recovery
  • Un Virtual Network & Subnets pour préparer l’hébergement de nos futures machines virtuelles
  • Un compte de stockage pour héberger nos futures machines virtuelles.

A noter que l’approche avec VMWARE ou les serveurs physique est quelque peu différente puisque cela ne repose pas sur Hyper-V-Replica mais sur la technologie InMage de la société Scout qui a été rachetée par Microsoft : InMage is now part of Microsoft

Ce premier billet de la série va se focaliser sur la mise en place des prérequis. Suivront deux autres billets :

Le service de DRP devant assurer un service de bout en bout, il est logique de regrouper tous ces éléments au sein d’un groupe de ressources. En plus, toutes ces ressources ont une caractéristique, elles ne sont pas liées à un projet en particulier mais mises à disposition pour un scénario donné. En regroupant ces ressources on a donc un coût pour toutes ces ressources que l’on va pouvoir ventiler en fonction des usages. Ce sera de la refacturation d’un service IT. J’ai donc créé un groupe de ressources auquel j’ai associé un Tag.

clip_image001

Lors de la création des services, le choix de la région Azure n’est pas anodin. Les futures machines virtuelles seront nécessairement dans la même région que l’instance du service ASR. J’ai donc retenu de créer mon Recovery Vault Service dans la région West Europe. Au passage, même si Azure Backup est maintenant intégré à Azure Site Recovery (depuis mai/juin 2016), je recommande de ne pas mutualiser les deux usages au sein d’une même instance du service. Les deux usages vont consommer du stockage, certainement beaucoup plus pour le backup que pour le DRP. En plus, une instance du service ne permet de sauvegarder que 50 machines virtuelles (avec l’agent Windows Server backup) ou 200 machines virtuelles IaaS Azure. Sachant qu’au sein d’une souscription on est limité qu’à 25 Recovery vault, on devrait pouvoir y arriver.

clip_image002

Mon instance du service Azure Site Recovery est rapidement provisionnée. Il reste encore un peu de configuration avant que le service soit totalement opérationnel.

clip_image003

Le service Azure Site Recovery est utilisable pour deux usages

  • Le DRP
  • La sauvegarde

Dans le cas présent, c’est le premier qui nous intéresse, nous allons donc suivre l’assistant « Site Recovery ».

clip_image004

Première question, le scénario. Dans notre cas, nous désirons :

  • Répliquer nos machines virtuelles vers Azure
  • Depuis un ou plusieurs hôtes Hyper-V (Windows Server 2012 R2 minimum)
  • Sans avoir besoin d’un SCVMM

clip_image005

Du point de vue Azure Site Recovery, nous allons déclarer nos serveurs Hyper-V (en installant un agent dessus), ces hôtes Hyper-V seront regroupés dans un Hyper-V Site que nous allons créer maintenant. La notion de site est importante car pour la mise en place de la protection des machines virtuelles, la politique s’appliquera à un site Hyper-V.

clip_image006

Notre site Hyper-V sera nommé « On-Premises ».

clip_image007

Nous retrouverons la notion de site Hyper-V ultérieurement lorsqu’on abordera la notion de politique de réplication. La même politique sera appliquée à tous les serveurs Hyper-V du site. Prochaine étape, associer notre serveur Hyper-V à ce site « On-Premises » :

clip_image008

L’association de notre serveur au site sera faite avec le fichier de « Vault Registration » mis à disposition en même temps que le binaire de l’installation de l’agent. Chaque serveur Hyper-V qui sera associé au site devra être enregistré individuellement avec son fichier de configuration propre.

clip_image009

Nous pouvons maintenant passer à l’installation de l’agent sur le serveur Hyper-V. Un point important, c’est que cet agent ne s’installe que sur socle Windows Server 2012 R2. Au moment de l’écriture de ce billet, l’agent n’était pas encore compatible avec Windows Server 2016. L’agent téléchargé est le Azure Site Recovery Provider. Il s’installe sur un serveur Windows Server 2012 R2 avec le rôle Hyper-V. Trois points intéressants à noter :

  • Possible de déployer cet agent sur une installation Core de Windows Server 2012 R2 (Top).
  • Pas de redémarrage nécessaire (donc mise en production en pleine journée)
  • Pas d’autre prérequis nécessaire

C’est un composant Microsoft, donc avec une stratégie de mise à jour Microsoft Update. Microsoft actualise le binaire régulièrement pour corriger des problèmes pour intégrer de nouvelles fonctionnalités. On va donc conserver la fonctionnalité activée.

clip_image010

C’est un processus d’installation comme un autre, avec un chemin d’installation proposé par défaut.

clip_image011

C’est maintenant que cela devient intéressant. C’est maintenant qu’on va enregistrer notre hôte Hyper-V auprès de notre Azure Site Recovery Vault.

clip_image012

Le processus d’inscription a besoin de trois informations :

  • La souscription Azure concernée
  • Le nom du Recovery Vault
  • Le site auquel notre serveur Hyper-V sera associé dans le Recovery Vault

Toutes ces informations sont contenues dans le fichier Vault Registration Key. A noter que ces informations seront enregistrées dans le registre du système d’exploitation. Si le serveur Hyper-V doit être associé à un autre Recovery Vault, il faudra supprimer ces informations du registre.

clip_image013

Un point intéressant. Le processus de réplication (reposant sur Hyper-V Replica dans notre scénario) va communiquer sur le port TCP 443 avec possibilité d’utiliser un Proxy avec authentification. Autre point, la communication est initiée par le serveur Hyper-V pas par Azure.

clip_image014

L’installation est maintenant terminée. Il faudra patienter quelques minutes pour que le serveur apparaisse dans le portail Azure.

clip_image015

De retour dans le portail Azure, on constate que notre serveur Hyper-V est maintenant associée au site.

clip_image016

Passons à l’étape suivante avec la configuration du Target. Lors de la bascule d’une machine virtuelle vers Azure, il faut pouvoir provisionner une machine virtuelle, cela implique :

  • Une souscription (qui peut être différente de celle hébergeant notre instance Azure Site Recovery)
  • Un mode de déploiement (aujourd’hui, on ne pense plus qu’en ARM)
  • Un Storage Account pour héberger les VHD (qui n’existent pas encore)
  • Un Virtual Network sur lequel on viendra connecter les interfaces des machines virtuelles

Tous les prérequis existant avant d’en arriver là, ça va tout de suite plus vite.

clip_image017

Le compte de stockage sera utilisé pour stocker les versions consistantes des machines virtuelles répliquées. Le Virtual Network sera lui utilisé pour reconnecter les machines virtuelles lors de la bascule. Un point à noter, si on a plusieurs Virtual Network, il faudra donc autant d’instances du service ASR.

Avec Hyper-V, la fréquence de réplication peut être configurée selon trois possibilités:

  • 30 secondes
  • 5 minutes
  • 15 Minutes

Dans le cas d’un contrôleur de domaine, on devrait pouvoir se contenter de 15 minutes. Le paramètre suivant détermine le nombre de recovery points consistants que l’on va conserver pour la reprise d’activité. Il est possible d’en conserver jusqu’à 24. Une configuration à 0 indique qu’on ne conserve que le dernier point de recovery dans Azure. Attention, ce paramètre va directement influer sur le stockage et donc sur la facture.

La notion de App-Consistent snapshot fait référence aux snapshots Hyper-V. Il existe deux type de snapshots. Le snapshot standard se contente de faire un cliché instantané de la machine virtuelle puis fonctionne en mode incrémentiel. Le second type (App-Consistent) travaille au niveau applicatif (Volume Shadow Copy). A ce niveau, on s’assure que l’application est dans un état compatible avec l’opération de snapshot. D’un point de vue RDP, c’est intéressant car on s’assure de pouvoir travailler à un niveau plus fin. Techniquement, il est possible de configurer jusqu’à douze App-Consistent snapshot par heure. Le hic, c’est que ce type de snapshot est consommateur en espace disque sur l’hôte Hyper-V et aussi en CPU. Vouloir plusieurs App-Consistent snapshot par heure est techniquement possible après, ce qui va nous limiter, c’est la capacité à les uploader vers Azure, et avoir terminé l’opération avant que les prochains snapshots ne se déclenchent. Pour rappel, c’est un nombre de Snapshots par heure que l’on configure. Pour cette raison, on recommande de toujours configurer le App-Consistent snapshot avec une valeur inférieure au nombre de recovery points.

Le dernier paramètre permet de spécifier le nombre de snapshots de la machine virtuelle qui seront réalisés sur l’hôte Hyper-V. Il est possible de réaliser jusqu’à 12 snapshots par heure.

clip_image018

Notre mise en place des prérequis est maintenant terminée.

clip_image019

Terminée oui, enfin presque. Avant de poursuivre, un passage par la case Capacity Planning s’impose.

clip_image020

On peut utiliser l’outil dans une version Quick ou Detailled. On a quelques inputs à fournir et l’outil nous indique en sortie quelques éléments intéressants. Le premier d’entre eux est la bande passante nécessaire pour répliquer les machines virtuelles. A noter que l’outil distingue la bande passante nécessaire pour la réplication initiale des réplications delta suivantes. Pour ce calcul, l’outil prend en compte une contrainte : la fenêtre de temps allouée pour réaliser la réplication initiale. Certes, on peut augmenter la taille de la fenêtre pour réduire la bande passante nécessaire mais il faudra bien faire passer la réplication initiale. Au moment de l’écriture de ce billet, il n’est pas encore possible d’utiliser le service Import/Export d’Azure pour envoyer des disques dur avec le contenu de notre première réplication initiale. Cependant, ce type de fonctionnalité est dans les cartons : Support for offline replication data transfer from on premise to Azure.

clip_image021

Maintenant qu’on est informé des conséquences réseau, il faut aussi se soucier des conséquences sur notre hôte de virtualisation. Réaliser des snapshots, c’est bien mais encore faut-il avoir la place de les stocker et avoir les IOPS pour les générer. Pour la réplication delta, le point d’attention sera de valider qu’on sera bien capable de répliquer ce contenu via la connectivité Internet. Au début avec quelques machines virtuelles, ça passe. Avec le temps, on ne ajoute de plus en plus jusqu’à ne plus être en mesure de répliquer tout le contenu dans un seul cycle de réplication.

Voilà pour les prérequis. Prochaine étape, on configurera la réplication.

­

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

Microsoft Experiences 2016 : Azure Stack de l’Azure dans votre Datacenter

Ca approche doucement, on peaufine nos derniers slides, affine nos démos, bref les Microsoft Experiences 2016, c’est bientôt.

Session

 

En ce qui me concerne, nous animerons avec Bruno Saille une session autour d’un produit qui nous tiens à cœur, à savoir Microsoft Azure Stack. Pour information, la session est planifiée pour la journée technique (donc le mercredi 5 octobre 2016). La session est planifiée pour le créneau horaire 18h15-19h00 en salle 252B. Nous serons donc disponible immédiatement après pour répondre à vos questions autour d’un verre.

Si Microsoft Azure Stack vous intéresse, l’évènement Microsoft Ignite devrait vous intéresser puisqu’il y a pas moins de onze sessions consacrées au sujet.

 

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

Découverte d’Azure VNet Peering

La période la plus difficile pour un addict du cloud, c’est les vacances, loin de ses régions Azure, … La qualité du réseau Corse n’incitant pas à la pratique assidue d’azure, il y a des sujets qui passent à la trappe. Le Vnet Peering est l’un d’entre eux. Le service est apparu pendant le mois de Juillet 2016 pour être visible dans le portail depuis le mois d’Aout 2016 : Public preview: VNet Peering for Azure Virtual Network

Avant, lorsqu’on voulait reproduire l’isolation réseau entre un environnement de production et les autres, le seul moyen à notre disposition était de segmenter avec plusieurs VNet et de connecter ceux-ci avec une Gateway comme illustré ci-dessous :

clip_image001

 

Cette approche répond parfaitement à notre problématique d’isolation. Par contre, elle présente plusieurs inconvénients :

  • Le coût : La mise en place de deux Gateway fonctionnant 744 heures par mois. Ce n’est pas négligeable.
  • La performance : Passer par deux Gateway, implique un tunnel IPSEC. Un fort trafic réseau entre les deux VNET impliquera de bien dimensionner les dites gateways car c’est le VCPU qui va travailler.
  • La logique : Pourquoi faudrait-il ressortir sur Internet pour connecter deux réseaux alors qu’ils sont dans la même région, donc dans le même datacenter

 

C’est pour répondre à ce type de problématique que Microsoft a introduit la notion de Peering. D’un point de vue conception, c’est tout de suite plus simple

clip_image002

 

Le Peering se configure dans le portail Azure depuis le 1er Aout 2016 comme illustré ci-dessous :

clip_image003

 

J’ai attendu que la fonctionnalité soit nativement disponible dans le portail, c’est plus simple. Un Peering est un objet dans Azure, il a donc un nom. Premier point intéressant, la fonctionnalité de Peering s’applique aussi bien aux VNets dits classiques (ASM) que ARM.

clip_image004

 

Un Peering peut être mis en place entre :

  • Deux VNets au sein de la même souscription
  • Deux VNets au sein de souscriptions différentes

 

La seule limite actuelle est que les deux VNets dépendent de la même région Azure. Ça tombe bien, c’est le cas de mes deux VNETs. L’option Virtual Network Access est intéressante. Elle permet de considérer l’autre VNet comme une extension du notre, donc inclus dans le Tag Virtual Network. Autant dire que pour un scénario de segmentation Production-Préproduction, on va éviter. Les trois dernières options permettent de maîtriser le routage :

  • Allow forwarded Traffic : Permet de maîtriser le flux réseau en provenance du partenaire (mais ne dépendant pas de son Vnet)
  • Allow Gateway transit : Permet à notre partenaire d’utiliser notre passerelle pour le routage du flux réseau externe
  • Use Remote gateways : Utilisé par notre partenaire pour qu’il puisse utiliser notre passerelle pour le routage de ses flux réseaux externes

 

Logiquement, pour que cela fonctionne, il faut créer un autre objet VNet Peering pour l’autre VNet, ce que j’ai fait.

clip_image005

 

Si on a pas l’overlapping d’adressage, alors le VNet Peering devrait apparaître ainsi dans les deux Vnets, avec la mention « Connected ».

clip_image006

 

Pour vérifier que cela fonctionne, on va tenter de communiquer depuis une machine virtuelle dont la carte réseau est connectée au réseau de pré-production pour joindre une machine virtuelle dont l’interface est liée au réseau de production. Voilà la configuration d’une machine virtuelle de pré-production. Elle dispose d’une Gateway sur son réseau, que du classique.

clip_image007

 

Et côté production :

clip_image008

 

Pour valider le bon fonctionnement, on va pinger depuis la machine virtuelle de pré-production vers la production.

clip_image009

 

Effectivement, cela fonctionne. On voit que c’est du VNet Peering car le TTL ne décroit pas. C’est logique car on ne passe pas par un routeur, c’est ce que nous confirme le Tracert.

Alors Vnet ou Gateway?

Pour certains scénarios (segmentation d’environnements), le VNet Peering est intéressant. Maintenant, reste à voir comment le service sera facturé lors de son passage en GA. Du point de vue Azure, on consommera nécessairement des ressources. On n’a plus les adresses IP publiques associées à nos Gateway ni le coût de compute de celles-ci mais il y aura forcément un coût. Sur le papier, le VNet Peering à tout pour plaire et supporte déjà beaucoup de fonctionnalités que nous utilisons souvent :

  • Network Security group
  • Network Virtual Appliances
  • User-Defined Routes
  • Internal Load-Balancers

 

Personnellement, je suis fan.

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

Découverte Azure AD B2C

Ça faisait quelques temps que qu’Azure B2C trainait en Preview, le service est maintenant officiellement disponible, donc officiellement utilisable en production, avec un cadeau, la facturation ne commencera qu’en 2017 :). Le pricing est basé sur deux critères :

  • Le nombre d’utilisateurs
  • Le nombre d’authentification

C’est une facturation par palier. Dès lors qu’on est en dessous des 50000 utilisateurs et 50000 authentifications, autant dire que le service est gratuit. Attention quand je dis gratuit car les services dépendants tel qu’Azure Multi-Factor Authentication eux ne le seront pas. L’aspect le plus ennuyeux étant clos, passons maintenant aux réjouissances. Pour rappel, Microsoft avait mis en Preview deux services :

  • Azure B2C (l’objet de ce billet)
  • Azure B2B (qui lui est encore en Preview)

 

Présentation du service

Pour faire simple Azure B2C va nous proposer un système de gestion des utilisateurs externes / consommateurs, pour une application Web (mais pas que) avec toute les fonctionnalités que cela implique (inscription, gestion de profil, réinitialisation de mot de passe, …), bref tout un ensemble de services qui vont faciliter la vie de nos développeurs. A l’opposé Azure B2B est destiné aux mêmes applications mais pour le contexte Business to Business. Voilà pour le positionnement d’Azure B2C. Intégrer l’authentification à une Web App, ce n’est pas nouveau (Expanding App Service Authentication/Authorization), on sait déjà le faire. Par contre, cela nous impose de développer tout ce qui va autour :

  • Le formulaire d’inscription
  • Le formulaire d’authentification
  • Le formulaire pour permettre aux utilisateurs de mettre à jour leur profil
  • Le formulaire pour réinitialiser le mot de passe
  • L’intégration avec nos applications

Bref, être responsable de tout cela et surtout coupable (le leaking de mots de passe est à la mode en ce moment et il n’épargne personne), c’est pas forcément ce qu’on recherche. Au final, ce serait bien si on avait un service capable de prendre en compte tous ces points en proposant en plus de prendre en charge des fournisseurs d’authentifications tiers (Facebook, Linkedin, Google+ Live ID, …), des trucs modernes donc. Tout ce que je viens d’énumérer sont des fonctionnalités D’Azure AD B2C.

Prérequis

Pour les besoins de la démonstration, j’ai retenu la Web Application. J’ai mis en place une Web App et le App Service qui lui est associé, le tout dans un groupe de ressources comme illustré ci-dessous :

clip_image001

Note : La feature Application Insight s’est glissé dans la configuration. Le problème, c’est qu’actuellement en Preview, elle n’est pas encore disponible dans la région West Europe.

Ma Web Application est tout ce qu’il y a de plus classique. La commande PowerShell : Get-AzureWebsite -Name b2Cwebapplication | select name, sku,state, enabled, EnabledHostNames, HostNameSslStates va nous fournir l’information essentielle :

clip_image002

L’information essentielle, c’est l’url de cette WebApp : https://b2cwebapplication.azurewebsites.net/. C’est à cette URL que le service Azure AD BC2 va rediriger les requêtes après inscription, authentification ou mise à jour de profil.

Mise en place

Pour l’instant, la création et la gestion des instances du service Windows Azure Active Directory dépendent encore de l’ancien portail. C’est donc dans celui-ci que nous allons créer une nouvelle instance du service Azure AD. Ce qui a changé par rapport à la Preview, c’est qu’on est plus obligé de créer un nouveau tenant Windows Azure Active Directory. On peut aussi conserver son tenant existant. Tout de suite, on y voit un intérêt immédiat de réutiliser des comptes existants.

clip_image003

Pour cette démonstration, j’ai retenu la création d’une nouvelle instance Azure Active Directory dont je suis moi-même devenu administrateur. J’ai aussi créé un premier utilisateur tout ce qu’il y a de plus classique.

clip_image004

Dans l’onglet Configure, on va découvrir un lien nommé « Manage B2C Settings ».

clip_image005

Maintenant on découvre que cela ne se passe plus dans l’ancien portail mais bien dans le nouveau portail, ce qui est une excellente nouvelle. Déclarer une application dans Azure AD, c’est quelque chose que nous avons déjà vu dans le billet Découverte d’Azure Disk Encryption (Preview). Par contre, c’est maintenant dans le nouveau portail que cela se passe. Mon application étant de type Web, il est logique que la case soit cochée. J’ai aussi référencer l’URL de mon application.

clip_image006

De cette interface, nous conservons deux choses :

  • L’Application ID
  • La clé de l’application

Ces informations seront essentielles pour configurer notre application. Azure B2C est un service d’authentification configurable à plusieurs niveaux :

  • La politique d’enregistrement (Sign-up policy)
  • La politique d’authentification (Sign-In policy)
  • La politique de gestion du profil (Profile Policy)
  • La politique de réinitialisation de mot de passe (Password Reset Policy)
Sign-up policy

C’est la politique d’enregistrement. On y référence les éléments suivants. Le ou les fournisseurs d’authentification que nous allons proposer à l’enregistrement (uniquement le mail pour commencer). Les deux autres sont visibles car au moment de la rédaction de ce billet, j’avais commencé la configuration d’autres fournisseurs.

clip_image007

Notre choix, c’est un enregistrement par mail pour commencer. Prochaine étape, la sélection des attributs que nous allons exiger de l’utilisateur pendant son enregistrement. On notera que ce sont des attributs Built-In. Cela signifie que l’on peut aussi demander d’autres informations.

clip_image008

Au terme de l’enregistrement, un jeton d’accès sera généré à destination de l’application. Il contiendra les informations suivantes :

clip_image009

La subtilité, c’est l’attribut « User Is new » qui permettra de traiter différemment la création d’un profil de la mise à jour d’un profil pour notre application. On pourrait exiger l’utilisation de Multi-Factor Authentication ou personnaliser la page d’enregistrement mais pas besoin de compliquer les choses pour une découverte.

Sign-In Policy

La politique d’authentification va reprendre les mêmes éléments que pour la politique d’enregistrement. On peut choisir :

  • Le ou les fournisseurs d’authentification à prendre en compte pour le formulaire d’authentification
  • Les attributs à intégrer au Claims qui sera généré et mis à disposition de notre application
  • La durée de vie de notre token et la configuration du SSO entre plusieurs applications
  • Le fait d’exiger l’authentification Multi-Factor pour notre application
  • La personnalisation de l’interface graphique mise à disposition des utilisateurs

 

Profile Policy

C’est le même principe que pour les politiques précédentes mais pour gérer l’interface de configuration du profil qui sera mise à disposition des utilisateurs. Au terme de la mise à jour, un jeton d’accès sera mis à disposition de l’application.

Password Reset Policy

L’interface de réinitialisation de mot de passe est valable uniquement pour le fournisseur d’identité Local Account. Pour les autres, c’est sous la responsabilité des fournisseurs respectifs (LinkedIn, Facebook, Google, …).

clip_image010

Attention, la politique de mot de passe applicable ainsi que la capacité de réinitialiser eux même leur mot de passe est lié au tenant Windows Azure AD B2C.

clip_image011

Après, encore faut-il que les utilisateurs aient renseigné une adresse de messagerie alternative :

clip_image012

 

C’est fini pour la partie mise en place. On va s’attaquer maintenant à Visual Studio.

Intégration Web Application

C’est maintenant que commence la phase développement. Là j’ai eu un peu d’aide ici : Azure AD B2C: Sign-Up & Sign-In in a ASP.NET Web App. Au début, j’ai commencé avec cet exemple disponible sur GitHub . Problème, n’étant plus dans la branche développement depuis bien longtemps (environ 15 ans), ça a été compliqué, je suis un peu rouillé en C#. J’ai donc pris un raccourci avec un package complètement opérationnel, lui aussi disponible sur GitHub. La toute la configuration tiens en quelques ligne du fichier « Web.Config » de notre Web Application. La cela me parle beaucoup plus. Nous devons référencer les points suivants :

  • Tenant : le nom de la souscription Windows Azure active Directory
  • ClientID : l’identifiant unique de notre application
  • RedirectUri : L’URL de redirection de notre application.
  • SignUpPolicyId : Le nom de la politique de Sign-up à utiliser avec notre application
  • SignInPolicyId : Le nom de la politique de Sign-in à utiliser avec notre application
  • UserProfilePolicyId : Le nom de la politique de profil à utiliser avec notre application

 

clip_image013

Y a plus qu’à sauver et builder. C’est maintenant qu’on va savoir si cela fonctionne. Mon instance App Service est déjà opérationnelle dans Azure, prête à accueillir mon package Web Deploy.

clip_image014

Mon instance se nomme b2Cwebapplication, c’est celle que j’avais créé en prérequis.

clip_image015

Visual Studio s’occupe de tout. Avec mes credentials il organise la publication de mon package Web Deploy.

clip_image016

On va direct en prod, pas de staging slot.

clip_image017

 

Expérience de l’enregistrement d’un nouvel utilisateur

Une fois l’application publiée, on peut aller faire un tour à l’URL https://b2cwebapplication.azurewebsites.net/. La première chose qui saute aux yeux, c’est que d’un point de vue design, ça ne casse pas trois pattes à un canard. En même temps, ce n’est pas le but et vous n’êtes pas arrivé jusqu’à ce paragraphe pour cela. Ce qui nous intéresse, c’est la barre en haut.

clip_image018

Si on clique sur « Sign up », alors la politique d’inscription que nous avons configurée devrait apparaître. Il nous faut prouver notre identité. Après avoir renseigné notre adresse email, on clique sur le bouton « Send verification code ». Le code nous est communiqué par mail. Nous n’avons qu’à le renseigner et cliquer sur le bouton « Verify ».

clip_image019

Tant que j’ai pas cliqué sur le bouton « Verify », pas possible d’aller plus loin. Ce n’est qu’une fois mon identité vérifiée qu’on va pouvoir finaliser la création du nouvel utilisateur dans le tenant Windows Azure Active Directory :

SignupPolicyExperience1

Dans l’application, il est maintenant bien référencé que je suis authentifié et reconnu :

clip_image021

 

Si on regarde sous la moquette (dans le tenant Azure AD B2C), on constate bien un nouvel utilisateur.

Get-MsolUser | Where {$_.DisplayName -eq « Simple by design but Business compliant »} | Format-List -Property Displayname, Userprincipalname, PostalCode, UserType, WhenCreated

clip_image022

On peut tester le formulaire d’authentification (Sign-in policy). Avec un seul fournisseur (Azure Active Directory), l’interface est des plus austères.

clip_image023

L’utilisateur peut mettre à jour les attributs dans son profil. Dans ma politique, j’avais indiqué que l’utilisateur pouvait modifier :

  • Son Code postal
  • Son Display Name
  • Son Pays

clip_image024

Si on va regarder ce qu’on a en PowerShell avec le module Azure AD.

$Cred = Get-Credential

Connect-msolservice -credential $cred

get-msoluser | where {$_.UserPrincipalname -eq « b2ccustomer@b2csimplebydesign.onmicrosoft.com »} | format-

list -Property Userprincipalname, Displayname, PostalCode, country

clip_image025

Ça correspond à ce que l’utilisateur a renseigné dans son profil. Pour finir, le lien Claims permet de consulter le Claims constitué et mis à disposition de notre application.

clip_image026

 

C’est une découverte rapide. Il y a encore beaucoup à dire sur le sujet Azure B2C. Quand je vais avoir un peu de temps, on s’attardera sur des sujets tel que :

  • L’utilisation d’autres fournisseurs d’authentification (Google, Facebook, LinkedIn)
  • L’utilisation d’attributs personnalisés dans le profil des utilisateurs

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