[Tuto] Web burst : Débordement Web vers Windows Azure

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èsmidi (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 } | SortObject -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 "$hereexistingNetworkConfig.xml"
echo "please merge files existingNetworkConfig.xml NetworkConfig.xml into
mergedNetworkConfig.xml in folder $here (NOT AUTOMATED YET)"

pause
Set-AzureVNetConfig -ConfigurationPath "$heremergedNetworkConfig.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:TEMPinit-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 `
Add-AzureEndpoint -LocalPort 3389 -Name "RDP" -Protocol tcp -PublicPort 50102 |
if ($false)
{
#if you encounter the following exception

#http://social.msdn.microsoft.com/Forums/windowsazure/en-US/ed8a1bb9-0f35-4d7fa5ab-d4fb7afa11c5/newazurevm-errors-when-provisioning-a-domain-joined-vm-missingtype-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 `
Add-AzureEndpoint -LocalPort 3389 -Name "RDP" -Protocol tcp -PublicPort 50102
|
}
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-pouroffice-365-via-le-d-233-ploiement-d-une-infrastructure-adfs-sur-la-plateforme-windowsazure.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/enus/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 :

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

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 :


Next
Next
Next

Display Name : Cloud Time Sheets
Notes:

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

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.

OK

Retourner à https://chezwamsample.contoso.com/FederationMetadata/200706/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 :
Heure VM Small en Cloud
Service
Transferts de données
(Europe, USA)

Juil. 2010
Tarification à l’heure
0,12 $ / heure

Nov. 2013
Tarification à la minute
0,08 $ / heure

0,15 $ / Go sortant

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

0,10$ / 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/B9BB74FB946E-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
Le bouton

(ou F5) permet d’exécuter tout le script saisi
(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/enUS/ed8a1bb9-0f35-4d7f-a5ab-d4fb7afa11c5/newazurevm-errors-when-provisioning-a-domain-joinedvm-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.

[Tuto] Web burst : Débordement Web vers Windows Azure

[Tuto] Web burst : Débordement Web vers Windows Azure

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie [Tuto] Web burst : Débordement Web vers Windows Azure

Ähnlich wie [Tuto] Web burst : Débordement Web vers Windows Azure (20)

Mehr von Microsoft Technet France

Mehr von Microsoft Technet France (20)

[Tuto] Web burst : Débordement Web vers Windows Azure