Tutoriel : Débordement Web vers Windows Azure

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.

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.

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

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.

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 :

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 :



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.

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 :

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

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.

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.

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.