Débordement Web vers Windows Azure

Avertissement Cet article s’inspire d’un article publié en janvier 2010 que l’on propose en annexes. 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. Egalement, 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 performance

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 évolution 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, ...

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... 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.

NB : 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.

NB : Si vous n’en n’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 entrer la ligne suivante

makecert -sv SampleCertificate.pvk -n "CN=chezwamsample.contoso.com"

SampleCertificate.cer -b 01/01/2013 -e 01/01/2020 -r

Puis entrer la ligne suivante :

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

SampleCertificate.pfx -po NR_yi_gpr_n93

Entrer 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.

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

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

Entrer 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 :

Next, Next, Next

Next, Finish

NB : 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’adminstrateur, 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 ») :

Start

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

Display Name : Cloud Time Sheets

Notes:

Next

Next

Next

Next

Next

Next

Next

Next

Close

Sur l’écran suivant, cliquer 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.

Finish

OK

Puis on déploie directement dans Azure Web Sites.

NB : 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 connecter 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.

Next

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 à 1 instance puisque la charge CPU est

faible :

NB : 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 !

Evolution 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 !

Annexes Le code source Le code source est disponible sur https://stockageazure2.blob.core.windows.net/public/B9BB74FB-

946E-4F22-9E6B-7DF4BCF6ADEB-developpez/hybride/web-burst-annexes-Scripts.zip

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.

NB : 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ération 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 bug dans le module

PowerShell azure et on doit donc joindre manuellement le serveur membre au domaine. Voici comment

on fait.

NB : Plus d’informations sur le bug à 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.