Tutoriel : Débordement Web vers Windows Azure

Benjamin Guinebertière (Microsoft)

L'équipe de Windows Azure, la plateforme Cloud de Microsoft, a préparé beaucoup de contenu intéressant, en exclusivité pour les lecteurs de Developpez.com. Chaque semaine, on va partager ce contenu avec vous. Regardez les vidéos, rejoignez des Web Events, étudiez les tutoriels. À la fin de chaque semaine, il y aura des questions, et chaque personne qui répondra correctement à 80 % de ces questions recevra un t-shirt sympa. Le 23 décembre, un tirage au sort sera effectué entre tous les gagnants, et le vainqueur recevra un Nokia Lumia - un cadeau sympa de Noël ! Tous ceux qui auront au moins une fois trouvé 80 % de bonnes réponses à une série de questions - et donc, gagné un t-shirt - seront sélectionnés pour participer à ce tirage. En d'autres mots, un seul challenge réussi suffira pour participer au tirage.

Ce tutoriel montre comment on peut utiliser l'élasticité du cloud pour permettre à l'informatique interne d'une entreprise de déborder sur le nuage pendant les périodes de plus forte charge. Pour illustrer cela, on s'appuie sur l'exemple de la saisie des feuilles de temps dans laquelle les employés de l'entreprise affectent leur temps à des projets, pour le suivi budgétaire de ces derniers.

L'équipe Windows Azure de Developpez.com tient à remercier « L'équipe Azure de Microsoft » pour la mise à disposition de ce tutoriel aux membres de Developpez.com.

Vous pouvez essayer gratuitement Windows Azure pendant une période d'un mois et obtenir une réduction de 150 euros.

Pour réagir au contenu de ce tutoriel, un espace de dialogue vous est proposé sur le forum :
Commentez .

- Titre : Tutoriel : Débordement Web vers Windows Azure

- Auteur : Benjamin Guinebertière (Microsoft)

- Parution : 10 novembre 2013

- Mise à jour : 11 novembre 2013

- Licence : Copyright ® 2013 Microsoft. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- Introduction

- Scénario

- Conception de la solution

- Principales évolutions utiles depuis janvier 2010

- Environnement de simulation et de test de la solution

- Ce que nous allons tester

- Mise en œuvre

- Environnement de simulation

- Gestion de l'identité, publication sur Azure Web Sites

- Configuration de la mise à l'échelle automatique

- Combien ça coûte ?

- Évolution des tarifs depuis janvier 2010, pour la solution originale

- Coûts de ce qui est présenté dans cet article

- Conclusion

- Téléchargements

- Annexes

- Téléchargement et installation du module PowerShell pour gérer Windows Azure

- Comment joindre manuellement le serveur membre au domaine

Introduction

Cet article s'inspire d'un article publié en janvier 2010 que l'on propose ici. Le scénario est le même, mais la façon d'aborder le sujet diffère. L'article original s'adressait à des architectes et entrait peu dans le détail. On propose ici plutôt de n'aborder qu'une partie des sujets, mais de les voir concrètement, ce qui intéressera plus les développeurs. Cet article peut être lu sans lire l'article original. Par exemple, sur le coût de la solution, on indique comment ont évolué les prix et combien la solution pourrait coûter aujourd'hui sans reprendre le détail du calcul original. Également, dans le chapitre « Mise en œuvre », on montre des éléments assez indépendants. La cohérence est apportée par l'article original, mais n'est pas indispensable.

Scénario

Cet article montre comment on peut utiliser l'élasticité du cloud pour permettre à l'informatique interne d'une entreprise de déborder sur le nuage pendant les périodes de plus forte charge. Pour illustrer cela, on s'appuie sur l'exemple de la saisie des feuilles de temps dans laquelle les employés de l'entreprise affectent leur temps à des projets, pour le suivi budgétaire de ces derniers. Contoso demande aux employés européens qui travaillent sur ses projets de saisir de façon hebdomadaire le temps qu'ils ont passé sur chaque projet, de façon à pouvoir suivre budgétairement ces projets.

Les saisies peuvent avoir lieu par anticipation, mais la plupart de ces saisies ont lieu le vendredi après-midi (plus de 80 % de la population concernée). Il y a à peu près 20 000 personnes concernées par cette saisie dans l'entreprise. Cela donne donc une population de 16 000 personnes pour la saisie le vendredi après-midi.

Le vendredi après-midi, l'application de saisie des temps rencontre des dégradations des performances aboutissant à des abandons de saisie, et une baisse de productivité des employés. Les prestataires externes peuvent saisir leurs temps directement dans l'application quand ils sont dans les murs de l'entreprise, mais ils ne peuvent pas le faire depuis Internet, l'application de saisie des temps n'étant pas exposée à l'extérieur.

L'affectation des temps aux différents projets est gérée au niveau de l'ERP de CONTOSO. Ce dernier expose des services Web SOAP (il est à noter que l'ERP peut exposer ces services Web directement, ou via une couche d'intégration telle que BizTalk) qui permettent de

- récupérer pour un utilisateur la liste des codes et libellés de projets sur lesquels il peut saisir pour la période ;

- récupérer la liste des temps déjà saisis sur une période ;

- soumettre une saisie de temps.

L'application de saisie des temps est une application Web écrite en ASP.NET, qui fait appel à ces Services Web et utilise l'authentification intégrée Windows (les utilisateurs arrivent avec leur compte défini dans un domaine Active Directory de l'entreprise).

Conception de la solution

Principales évolutions utiles depuis janvier 2010

La solution proposée pour l'hébergement du site Web dans le nuage s'appuie sur les Web Roles (PaaS).

Depuis, pour héberger un site Web, il est également possible de choisir Web Sites ou des machines virtuelles.

Si le code est compliqué à migrer, ou que la solution tourne sur Linux par exemple, il est préférable de s'appuyer sur les machines virtuelles Windows Azure (IaaS). On peut tout à fait automatiser la création de ces VM (comme on le verra ici lors de la création de l'environnement de simulation de ce qui se passe à demeure). On peut même avoir de l'autoscaling sur ces VM comme expliqué dans le billet de Scott Guthrie ; pour les VM, le principe est de les mettre dans le même availability set et l'autoscaling les allumera ou éteindra en fonction des critères voulus (CPU typiquement).

Les Sites Web (« Web Sites ») permettent d'héberger du code .NET, PHP, Python ou Node.js facilement avec une montée en charge assez forte (jusqu'à 10 VM de 4 cœurs chacune). Contrairement aux web roles, on ne peut pas modifier les machines virtuelles instanciées, on ne peut pas s'y connecter en bureau à distance, on ne peut pas inclure ces VM dans un réseau virtuel Windows Azure, on en peut pas avoir des fermes Web de plus de 10 machines. Cela dit, dans le cas de la saisie des feuilles de temps, rien de tout cela n'est nécessaire. Aussi, on propose ici de s'appuyer sur Web Sites plutôt que des Web Roles.

Pour l'authentification, on dispose, en plus de ce qui était disponible en 2010, de Windows Azure Active Directory qui permet également d'authentifier les utilisateurs de l'entreprise depuis le cloud. Le fait d'utiliser Windows Azure Active Directory en tant que réplication d'Active Directory à demeure (via un outil appelé DirSync) est un choix qui relève en général plus des architectes en infrastructure que des développeurs et l'on propose dans cette version du papier de rester dans les principes énoncés dans la version originale avec Active Directory Federation Services qui conserve un rôle important dans la mise en œuvre de Windows Azure Active Directory dans une architecture hybride :

Pour la liaison entre le site web de saisie dans le nuage et l'ERP, c'est-à-dire l'envoi depuis Windows Azure des feuilles de temps saisies au système d'information interne de l'entreprise, on s'était appuyé sur Windows Azure Service Bus. Windows Azure Service Bus existe en version synchrone (« relay ») et asynchrone (« Queues », « Topics »). La version asynchrone est apparue après et présente ici deux avantages par rapport à la version synchrone :

- elle peut absorber les pics de charge en stockant les messages non encore consommés ;

- elle est plus simple à mettre en œuvre.

On choisit donc de remplacer Windows Azure Service Bus Relay par Windows Azure Service Bus Queues. Les topics sont des queues avec plusieurs abonnés qui peuvent suivre des messages différents. Ici, on n'a qu'une destination, à savoir l'ERP dans un sens, ou la ferme Web dans l'autre donc les queues sont plus adaptées. On adapte donc le schéma de la façon suivante :

Le schéma reste le même, mais le « service de lien Azure » est développé différemment.

Environnement de simulation et de test de la solution

On montre dans cet article seulement certains aspects de la solution, mais dans le détail. De façon à disposer d'un environnement de simulation de ce qui se passe à demeure, on créera une machine virtuelle dans le datacenter d'Europe de l'Ouest de Windows Azure, que l'on n'exposera sur Internet que pour y avoir accès via le bureau à distance, et l'on fera tourner ce qui est effectivement dans Windows Azure dans le datacenter d'Europe du Nord. La création de l'environnement de simulation en Europe de l'Ouest se fera essentiellement par un script PowerShell.

De façon à ce que chacun puisse reproduire l'exercice dans son propre environnement, on met ici la chaîne de caractères 131103a dans les noms qu'il vous suffira de changer dans les différents scripts en choisissant la vôtre. Par exemple, il existe un seul chezwam131103a.cloudapp.net, mais quelqu'un d'autre peut créer son chezwam1337.cloudapp.net, un autre son chezwam42qr.cloudapp.net.

Ce que nous allons tester

Nous allons donc voir plus dans le détail ici comment :

- déployer une application ASP.NET sur Web Sites ;

- gérer l'authentification avec ADFS ;

- faire monter en charge automatiquement (Autoscaling) un Web Site.
En revanche, ce dernier point fera peut-être l'objet d'un autre article :

- utiliser les queues de Service Bus pour interagir avec le Web Service SOAP à demeure (via un composant à demeure).

Mise en œuvre

Environnement de simulation

L'environnement de simulation est initié par un script PowerShell.

Vous trouverez en annexes la façon d'initialiser votre environnement pour exécuter ce script. Il est à noter que ce script doit être lancé en tant qu'administrateur. Le démarrage de PowerShell ISE doit donc se faire par exemple de la façon suivante :

Le script à exécuter est le suivant :

#region import, add Azure Account
import-module Azure

#may be needed if the credentials have expired
#add-AzureAccount

#endregion

#region change with your own values
$subscription = 'Azure bengui'
$suffix = "131103a"
$username = "benjguin"
$password = "NR_yi_gpr_n93"
#endregion

#region initialization
$serviceName = "chezwam${suffix}"
$storageName = "chezwam${suffix}"
$domainname = "chezwam${suffix}"
$domainFQDN = "${domainname}.contoso.com"
$dcName = "dc1"
$memberName = "membre"
$region = "West Europe"
$affinityGroupName = "chezwamAG"
$virtualNetworkName = "chezwamNET"

$here = split-path -parent $MyInvocation.MyCommand.Definition

Select-AzureSubscription -Default $subscription
#endregion

#region functions
function GetLatestImage
{
param($imageFamily)
$images = Get-AzureVMImage | where { $_.ImageFamily -eq $imageFamily } | Sort-Object -Descending -Property PublishedDate
return $images[0].ImageName
}

function InstallWinRMCert($serviceName, $vmname)
{
$winRMCert = (Get-AzureVM -ServiceName $serviceName -Name $vmname | select -ExpandProperty vm).DefaultWinRMCertificateThumbprint

$AzureX509cert = Get-AzureCertificate -ServiceName $serviceName -Thumbprint $winRMCert -ThumbprintAlgorithm sha1

$certTempFile = [IO.Path]::GetTempFileName()
Write-Host $certTempFile
$AzureX509cert.Data | Out-File $certTempFile

# Target The Cert That Needs To Be Imported
$CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $certTempFile

$store = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine"
$store.Certificates.Count
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$store.Add($CertToImport)
$store.Close()

Remove-Item $certTempFile
}
#endregion

#region create affinity group, network, cloud service, storage&#8230;
New-AzureAffinityGroup -Name $affinityGroupName -Location $region

# cloud service
New-AzureService -ServiceName $serviceName -AffinityGroup $affinityGroupName

# storage account
New-AzureStorageAccount -StorageAccountName $storageName -AffinityGroup $affinityGroupName
Set-AzureStorageAccount -StorageAccountName $storageName -GeoReplicationEnabled $false

Set-AzureSubscription -SubscriptionName $subscription -CurrentStorageAccount $storageName

Get-AzureVNetConfig -ExportToFile "$here\existingNetworkConfig.xml"
echo "please merge files existingNetworkConfig.xml NetworkConfig.xml into mergedNetworkConfig.xml in folder $here (NOT AUTOMATED YET)"
pause

Set-AzureVNetConfig -ConfigurationPath "$here\mergedNetworkConfig.xml"
#endregion

#region create DC and its forest
Get-AzureVMImage | select -Unique ImageFamily | sort -Property ImageFamily

$vmImageName = GetLatestImage("Windows Server 2012 R2 Datacenter")
$vmImageName

$dcVM = `
New-AzureVMConfig -ImageName $vmImageName -InstanceSize Small -Name $dcName `
-DiskLabel "${dcName}os" `
-HostCaching ReadWrite -Label "$dcName" |
Add-AzureProvisioningConfig -Windows -AdminUsername $username -Password $password -NoRDPEndpoint -NoWinRMEndpoint |
Add-AzureDataDisk -CreateNew -DiskSizeInGB 30 -DiskLabel "${dcName}data1" -LUN 0 |
Add-AzureEndpoint -LocalPort 3389 -Name "RDP" -Protocol tcp -PublicPort 50101 |
Add-AzureEndpoint -LocalPort 5986 -Name "RemotePSStdPort" -Protocol tcp -PublicPort 5986 |
Add-AzureEndpoint -LocalPort 443 -Name "HTTPS" -Protocol tcp -PublicPort 443 |
Set-AzureSubnet 'Subnet-1'

#create the VM and wait for boot
New-AzureVM -ServiceName $serviceName -VMs $dcVM -VNetName $virtualNetworkName -WaitForBoot

$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $dcName

# this requires to be an admin on local machine
InstallWinRMCert $serviceName $dcName

$SecureStringadminPassword = ConvertTo-SecureString -String $password -AsPlainText -Force
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $SecureStringadminPassword

Invoke-Command -ConnectionUri $uri.ToString() -Credential $credential `
-ArgumentList $SecureStringadminPassword, $domainFQDN -ScriptBlock `
{
param($SecureStringadminPassword, $domainFQDN)

$logLabel = $((get-date).ToString("yyyyMMddHHmmss"))
$logPath = "$env:TEMP\init-webservervm_webserver_install_log_$logLabel.txt"
Import-Module -Name ServerManager
Install-WindowsFeature -Name AD-Domain-Services,ADFS-Federation -IncludeManagementTools -LogPath $logPath

$disks = Get-Disk | where { $_.NumberOfPartitions -eq 0 }
foreach ($d in $disks)
{
# there should be one disk only
$diskNumber = $d.Number
echo "will format disk $diskNumber"
Initialize-Disk $diskNumber
New-Partition -DiskNumber $diskNumber -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter F -Confirm:$False
get-volume -DriveLetter F
}

Import-module ADDSDeployment
Install-ADDSForest -DomainName $domainFQDN -InstallDns:$true -DatabasePath "F:\NTDS" `
-LogPath "F:\NTDS" -SysvolPath "F:\SYSVOL" -NoRebootOnCompletion:$false -Force:$true `
-SafeModeAdministratorPassword $SecureStringadminPassword
}
#endregion

#region wait for DC to reboot
Start-Sleep -Seconds 45

$dcVM = Get-AzureVM -ServiceName $serviceName -Name $dcName
While ($dcVM.InstanceStatus -ne "ReadyRole")
{
write-host "Waiting for DC to be ready&#8230; Current Status = " $DcVm.InstanceStatus
Start-Sleep -Seconds 15
$dcVM = Get-AzureVM -ServiceName $serviceName -Name $DcVmName
}

#endregion

#region create member VM

$memberVM = `
New-AzureVMConfig -ImageName $vmImageName -InstanceSize Small -Name $memberName `
-DiskLabel "${memberName}os" `
-HostCaching ReadWrite -Label "$memberName" |
Add-AzureProvisioningConfig -WindowsDomain -AdminUsername $username -Password $password `
-Domain $domainName -DomainUserName $username -DomainPassword $password -JoinDomain $domainFQDN `
-NoRDPEndpoint -NoWinRMEndpoint |
Add-AzureEndpoint -LocalPort 3389 -Name "RDP" -Protocol tcp -PublicPort 50102 |
Set-AzureSubnet 'Subnet-2'

if ($false)
{
#if you encounter the following exception
#http://social.msdn.microsoft.com/Forums/windowsazure/en-US/ed8a1bb9-0f35-4d7f-a5ab-d4fb7afa11c5/newazurevm-errors-when-provisioning-a-domain-joined-vm-missing-type-map-configuration-or?forum=WAVirtualMachinesforWindows
#please use this instead and then, join the domain manually
$memberVM = `
New-AzureVMConfig -ImageName $vmImageName -InstanceSize Small -Name $memberName `
-DiskLabel "${memberName}os" `
-HostCaching ReadWrite -Label "$memberName" |
Add-AzureProvisioningConfig -Windows -AdminUsername $username -Password $password `
-NoRDPEndpoint -NoWinRMEndpoint |
Add-AzureEndpoint -LocalPort 3389 -Name "RDP" -Protocol tcp -PublicPort 50102 |
Set-AzureSubnet 'Subnet-2'
}

New-AzureVM -ServiceName $serviceName -VMs $memberVM

#endregion

Le script crée les deux VM dans un réseau virtuel Windows Azure. Sur le DC, il installe un domaine, mais également ADFS sans le configurer. On peut configurer ADFS en PowerShell (cf. http://technet.microsoft.com/en-us/library/ee892329.aspx), mais on va le faire ici manuellement de façon à voir concrètement à quoi cela ressemble.

N.B. Bien sûr, il s'agit ici d'un environnement de simulation destiné au développeur pour mieux comprendre les principes et manipuler concrètement les outils. En production, on aurait une infrastructure beaucoup plus sophistiquée. Voici quelques éléments de comparaison :

- plusieurs contrôleurs de domaine ;

- séparation des machines sur lesquelles on déploie les DC et ADFS ;

- plusieurs serveurs ADFS pour la haute disponibilité ;

- zone DMZ spécifique pour ADFS proxy. Cette DMZ peut elle-même être dans Windows Azure (cf http://blogs.msdn.com/b/stephgou/archive/2013/05/24/f-233-d-233-ration-d-identit-233-pour-office-365-via-le-d-233-ploiement-d-une-infrastructure-adfs-sur-la-plateforme-windows-azure.aspx);

- certificats valides publiquement (au lieu du certificat autosigné d'exemple) ;

- …

Pour l'installation dans notre environnement de test, on utilise un certificat autosigné. On montre ici comment depuis une machine qui a Visual Studio, on peut le créer.

N.B. Si vous n'en avez pas, un fichier PFX exemple vous est fourni en annexes (dossier Scripts). Il a le même mot de passe que $password dans l'exemple PowerShell ci-dessus.

On trouvera des informations complémentaires à http://msdn.microsoft.com/en-us/library/ff699202.aspx

Puis entrez la ligne suivante :

makecert -sv SampleCertificate.pvk -n "CN=chezwamsample.contoso.com" SampleCertificate.cer -b 01/01/2013 -e 01/01/2020 -r

Puis entrez la ligne suivante :

pvk2pfx -pvk SampleCertificate.pvk -spc SampleCertificate.cer -pfx SampleCertificate.pfx -po NR_yi_gpr_n93

Entrez toujours le même mot de passe quand cela est demandé.

Cela donne les fichiers suivants :

Se connecter avec le bureau à distance (RDP) au contrôleur de domaine qui a été créé par le script PowerShell. Une façon de le faire facilement est d'aller dans le portail https://manage.windowsazure.com, sélectionner la VM et cliquer sur « Connecter » en bas.

Copiez le fichier pfx dans le serveur DC1 (copier/coller à travers le bureau à distance par exemple) :

Depuis le DC, allez dans le server manager pour accéder à la configuration manuelle d'ADFS.

Saisissez le mot de passe (NR_yi_gpr_n93 dans mon cas).

Le username et le password correspondent aux valeurs des variables PowerShell :

ADFS est configuré.

La console de gestion d'ADFS se lance de la façon suivante :

Nous réutiliserons cette console de gestion ADFS plus tard.

Comme on a utilisé un certificat PFX avec comme sujet chezwamsample.contoso.com, on crée une entrée DNS qui correspond à l'adresse du contrôleur de domaine :

Faites « Next > », « Next > », « Next > ».

Cliquez sur « Next > », puis « Finish ».

N.B. Dans un environnement de production, le certificat aurait un nom correspondant à son environnement. Ici, comme je fournis un certificat de test PFX qui doit fonctionner pour tout le monde, je raccorde cela avec l'environnement contenant le suffixe exemple 131103a via une entrée DNS.

Dans le navigateur, on peut accéder aux métadonnées exposées par ADFS à l'URL suivante.

https://chezwamsample.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml

En tapant sur la touche F12, le document XML est plus lisible (DOM Explorer) :

Sur le poste de développement, on a également besoin d'accéder à L'URL https://chezwamsample.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml avec ce nom. Cela simplifiera l'utilisation des outils. Pour faire cela par exemple, depuis un PowerShell en tant qu'administrateur, on peut modifier le fichier hosts. local via la commande :

notepad C:\windows\System32\drivers\etc\hosts.

Puis on ajoute l'entrée :

L'adresse IP est celle qu'on trouve dans le portail en inspectant le cloud service :

Gestion de l'identité, publication sur Azure Web Sites

Passons maintenant au code du site Web.

La gestion de l'identité à une dépendance sur l'URL. En développement, il peut être pratique de travailler directement sur un « Web Site » Windows Azure qui propose un chemin HTTPS par défaut en *.azurewebites.net.

On crée donc un « Web Site » (pensez à changer le nom) :

import-module azure
New-AzureWebsite -Location "North Europe" -Name "cloudtimesheet131103a"

Ainsi, ce qu'on déploiera sera accessible à https://cloudtimesheet131103a.azurewebsites.net

Créons le projet Web qui va utiliser l'authentification ADFS.

Les deux paramètres suivants peuvent être entrés :

https://chezwamsample.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml

https://cloudtimesheet131103a.azurewebsites.net

Le fichier Web.config contient les informations relatives à la fédération d'identité.

On va maintenant déclarer l'application à ADFS. Sur le contrôleur de domaine, dans la console, on déclare l'application (« Relying Party ») :

Cliquez sur « Start ».

Sur l'écran suivant, on entre les valeurs suivantes :

- Display Name : Cloud Time Sheets ;

- Notes : Faites « Next > », « Next > », « Next > ».

Faites « Next > », « Next > », « Next > », « Next > », « Next > ».

Cliquez sur « Close ».

Sur l'écran suivant, cliquez sur « Add Rule… ».

La règle importante ici est le fait que « Display-Name » d'Active Directory soit passé en tant que « Name » au niveau du jeton d'authentification envoyé à l'application.

Cliquez sur « Finish ».

Cliquez sur « OK ».

Puis on déploie directement dans Azure Web Sites.

N.B. Si vous n'avez pas l'intégration avec Visual Studio de Windows Azure dans Visual Studio 2013, vous pouvez télécharger les outils à http://www.windowsazure.com/fr-fr/downloads/?sdk=net,

Puis connectez Visual Studio à votre compte Windows Azure.

Revenons à la publication :

Le site est donc disponible sur Windows Azure.

On donne ensuite un nom (« Display-Name ») à l'utilisateur de test (qui dans notre cas est aussi l'admin) dans Active Directory :

sur le DC1, Windows+R « dsa/msc ».

Puis on se connecte avec ce même compte sur le serveur member (la deuxième VM créée par le script PowerShell).

On configure Internet Explorer.

On navigue ensuite vers :

https://chezwamsample.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml ce qui va nous permettre de faire reconnaître le certificat de test.

Cliquez sur « Next > ».

Cliquez sur « OK ».

Retourner à https://chezwamsample.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml dans une nouvelle session IE :

On peut maintenant tester :

Aller à https://cloudtimesheet131103a.azurewebsites.net.

L'utilisateur a une authentification intégrée (on ne lui demande pas son compte ni son mot de passe), et son nom est reconnu sur le site Web dans Windows Azure :



Configuration de la mise à l'échelle automatique

On peut ensuite configurer la façon dont le site Web monte en charge. Le but est que le bon nombre de ressources soit utilisé en fonction de l'utilisation effective du site, et ainsi optimiser le coût.

Cela se fait depuis le portail de gestion https://manage.windowsazure.com

Puis on configure la montée en charge elle-même de la façon suivante :

Après avoir enregistré les modifications, on voit que le site reste à une instance puisque la charge CPU est faible :

N.B. On peut avoir une seule VM pour le site Web puisque le SLA de Web Site s'applique pour des VM seules. Cela vient de ce que les VM de Web Sites sont standard et un pool déjà démarré est disponible de sorte que le site Web peut être déployé sur la nouvelle VM dans le temps d'une requête HTTP.

Combien ça coûte ?

Parlons prix, maintenant !

Évolution des tarifs depuis janvier 2010, pour la solution originale

On pourra comparer les tarifs de l'article original avec les tarifs actuels qui sont disponibles à http://www.windowsazure.com/pricing. L'article original les exprime en $, au lieu d'€. Il suffit de changer en bas de la page pour avoir les tarifs en $.

Voici quelques comparaisons :

Juil. 2010

Nov. 2013

Heure VM Small en Cloud Service

Tarification à l'heure
0,12 $ / heure

Tarification à la minute
0,08 $ / heure

Transferts de données (Europe, USA)

0,15 $ / Go sortant
0,10$ / Go entrant

0,12 $ / Go sortant, 5 1ers Go gratuits, tarifs dégressifs
0,00 $ / Go entrant

…

On voit donc que les tarifs ont diminué, et ont gagné en souplesse.

Coûts de ce qui est présenté dans cet article

Combien coûte ce qui a été présenté dans cet article ?

On utilise deux machines virtuelles de taille S pour simuler le contrôleur de domaine et une machine membre du domaine. Avec leur stockage cela coûte à peu près (extraits de http://www.windowsazure.com/fr-fr/pricing/calculator/) :

Donc si on fait le test en développement pendant 48 heures en laissant les machines allumées tout le temps, cela coûte :

0,135 € * 48 + 13,04 € * 48 / (24*31) + 0,38 € soit ~= 7,70 €

On utilise également un « Web Site » en mode standard avec une élasticité automatisée allant de 1 à 8 machines de type S. Pour adapter un peu par rapport au scénario original, on peut supposer qu'on a toujours le site Web déployé dans le cloud, ce qui évite les redirections complexes. Comme dans l'article original, on monte à 8 cœurs (ici 8 VM Small) pendant 6 heures le vendredi après-midi.

La présence de la VM 24h/24 coûte :

Puis si on prend le cas des 8 cœurs pendant 6 heures (donc 7 de plus) :

Soit 0,522 € * 6 h = 3,132 € pour absorber le pic de charge.

Conclusion

Cet article montre comment un développeur ou un architecte peut tester assez facilement la mise en place d'un environnement relativement complexe, pour un coût modique.

Il montre aussi concrètement comment le cloud et un environnement à demeure peuvent fonctionner ensemble (ici au niveau de l'authentification). Il s'agit là encore d'un exemple d'implémentation de ce que peut être le cloud hybride !

Téléchargements

Vous pouvez télécharger les scripts ici.

Annexes

Téléchargement et installation du module PowerShell pour gérer Windows Azure

Pour manipuler l'environnement Windows Azure depuis du code et depuis une machine Windows, PowerShell est un excellent environnement. PowerShell lui-même fait partie de Windows depuis déjà un certain nombre d'années. En revanche, le module de gestion de Windows Azure doit être téléchargé. Depuis la machine « dans-mes-murs », on se rend donc à l'adresse suivante :

http://www.windowsazure.com/fr-fr/downloads/#cmd-line-tools

On télécharge et installe ce module.

Puis on exécute Windows PowerShell.

Et l'on tape les commandes suivantes :

Import-module azure
Get-command -module azure

Ensuite, on ajoute le compte avec lequel on peut se connecter au portail Windows Azure (http://manage.windowsazure.com) de façon à pouvoir disposer des mêmes ressources depuis PowerShell.

N.B. Si vous n'avez pas de compte Windows Azure, vous pouvez vous en procurer un avec l'offre d'essai gratuite. Rendez-vous par exemple à http://aka.ms/tester-mon-azure.

Tapez en PowerShell :

Add-AzureAccount

Puis laissez-vous guider :

Une façon de vérifier que tout est correct est de taper :

Get-AzureSubscription

Cela doit vous donner la liste des abonnements auxquels votre compte entré ci-dessus a droit.

La suite des opérations dans PowerShell se fera dans l'IDE de PowerShell appelé ISE. On le démarre de la façon suivante :

Le bouton (ou F5) permet d'exécuter tout le script saisi.

Le bouton (ou F8) permet d'exécuter uniquement le code sélectionné.

Si on dispose de plusieurs abonnements Azure, comme c'est mon cas, on peut choisir l'abonnement par défaut de la façon suivante :

Select-AzureSubscription -Default "Azure bengui"

Dans votre cas, remplacez « Azure bengui » par le nom de votre propre abonnement.

Comment joindre manuellement le serveur membre au domaine

Au moment de l'écriture de cet article (avant le 6 novembre 2013), il y a un bogue dans le module PowerShell Azure et on doit donc joindre manuellement le serveur membre au domaine. Voici comment on fait.

N.B. Plus d'informations sur le bogue à http://social.msdn.microsoft.com/Forums/windowsazure/en-US/ed8a1bb9-0f35-4d7f-a5ab-d4fb7afa11c5/newazurevm-errors-when-provisioning-a-domain-joined-vm-missing-type-map-configuration-or?forum=WAVirtualMachinesforWindows

Se connecter en remote desktop à la VM :

depuis le portail manage.windowsazure.com

Le username correspond à la variable $username du script et le mot de passe à $password.