Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Déploiement et configuration en IAAS Azure

Poster un commentaire

Nous allons rester dans le IAAS et parler de méthodes pour automatiser un déploiement. Nous avons déjà vu qu’il est possible de créer des modèles de VM comme base de déploiement:

https://amethyste16.wordpress.com/2015/04/13/pilotez-vos-vm-azure-avec-powershell/

Toutefois certains scénarios nécessitent une configuration à la volée. Nous allons examiner dans cet articles 3 solutions possibles:

  1. Windows PowerShell Remoting
  2. Extension CustomScript
  3. Extension DSC

Il en existe d’autres, moins spécifiques au IAAS, mais elles sont encore en preview.

Windows PowerShell Remoting

WinRM (Windows Remoting) est un service d’accès distant sous Windows qui est activé par défaut sous Windows 2012 Server. Il est accessible en HTTPS (port 5986)  à travers Internet ou en HTTP (port 5985) de VM à VM si elles sont situées dans le même réseau.

2015-04-19_16-12-00

Un certificat est auto généré par Azure dans le magasin du cloud service associé pour se connecter en HTTPS:

2015-04-19_16-13-40

Pour vérifier si WinRM est présent sur une machine:

Get-Service WinRM

Et par exemple sur une VM nouvellement montée:

2015-04-26_15-39-43

Get-Service est d’ailleurs un exemple de remoting dans lequel la plomberie de connexion à une machine distante est intégrée dans la commande.

Si le service a besoin d’être lancé et configuré:

Enable-PSRemoting -Force

Si on est sur un réseau public avec une version cliente de Windows on peut ajouter SkipNetworkProfileCheck.

La commande lance le service, met en place un socket d’écoute, configure le pare feu.

On peut tester si l’hôte distant a activé WinRM avec la cmdlet Test-WSMan.

 

http://www.it-connect.fr/powershell-remoting-avec-winrm/

La connexion distante s’effectue avec la cmdlet Enter-PSSession. Voici le script:

$vmname = NOM VM
$serviceName=SERVICE CLOUD
$user= USER
$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $vmname
$option = New-PSSessionOption –SkipCACheck
Enter-PSSession -ConnectionUri $uri -Credential « $vmname\$user » -SessionOption $option

Une fois la connexion ouverte, entrer hostname pour vérifier que vous êtes sur la machine distante.

L’option SkipCACheck demande de ne pas valider le certificat. Ce n’est bien sûr pas une très bonne pratique dans la vie réelle. On va corriger ce problème dans un moment.

Saisir exit pour se déconnecter de la session.

 

On ne cherche pas forcément à ouvrir une session, mais à lancer une commande distante. On doit utiliser Invoke-Command:

$cred = Get-Credential -UserName « $vmname\$user » -Message « Connectez vous $vmname »
$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $vmname
$option = New-PSSessionOption -SkipCACheck
Invoke-Command -ConnectionUri $uri -Credential $cred -SessionOption $option –ScriptBlock {
        « Hello amethyste »  | Out-File « c:\log.txt »
        }

En sortant le credential de la commande on peut relancer Invoke-command sans se ré authentifier à chaque fois. La commande créée un simple fichier de log.

On peut aussi lancer une commande située dans un fichier *.ps1. On utilisera FilePath à la place de ScriptBlock.

 

On va mettre un peu de sécurité. On aura besoin de l’empreinte digitale du certificat du point de terminaison WinRMHTTPS et le certificat.

Le certificat est logé au niveau du service on peut donc retrouver l’empreinte facilement:

2015-04-26_18-39-30

Ou bien par code:

$vm = Get-AzureVM -ServiceName $serviceName -Name $vmname
$certthumbrint = $vm.VM.DefaultWinRmCertificateThumbprint

Pour le certificat il faut PowerShell:

$cert = Get-AzureCertificate -ServiceName $serviceName -Thumbprint $certthumbrint -ThumbprintAlgorithm sha1
$cert.Data | Out-File -FilePath « .\my_cert.cer »
certutil.exe -f -addstore Root .\my_cert.cer

Le certificat est extrait et monté dans le magasin local:

2015-04-26_18-43-32

Il existe encore une 3ème méthode développée dans un article précédent:

https://amethyste16.wordpress.com/2015/03/07/fournir-ses-credentials-aux-services-azure/#more-3853

On peut maintenant se connecter à distance sans SkipCACheck:

$cred = Get-Credential -UserName « $vmname\$user » -Message « Connectez vous $vmname »
$uri = Get-AzureWinRMUri -ServiceName $serviceName -Name $vmname
$option = New-PSSessionOption
Invoke-Command -ConnectionUri $uri -Credential $cred -SessionOption $option -ScriptBlock {
        « Hello amethyste »  | Out-File « c:\log.txt »
        }

En cas de problèmes

Le premier essai avec Enter-PSSession donne généralement le message d’erreur suivant:

Enter-PSSession : Connecting to remote server 100.112.80.59 failed with the following error message : The WinRM client cannot process the request. If
the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the
destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the
TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more
information, see the about_Remote_Troubleshooting Help topic.
At line:10 char:1
+ Enter-PSSession -ComputerName XXXXX-Port 63847 -Credential « $vmname\$us …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (XXXX:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Ca fait un peu peur!

La version courte est que l’on doit configurer des trucs sur AmethysteVM2. Tout est expliqué dans le tuto déjà présenté:

http://www.it-connect.fr/powershell-remoting-avec-winrm/

En gros on fait deux choses:

  1. on active l’accès distant, les règles du pare feu…
  2. on définit les hôtes de confiance

 

En cas de grosse panique, voici de l’aide:

https://technet.microsoft.com/en-us/library/dd347642.aspx

Diverses choses

Plusieurs directives de Add-AzureProvisioningConfig permettent de modifier le réglage relatif au remoting:

  • DisableWinRMHttps
  • NoWinRMEndpoint
  • EnableWinRMHttp
  • WinRMCertificate

On peut ne pas vouloir autoriser le remote sur la VM ce que l’on obtient soit en supprimant le point de terminaison à la main ou bien en ne le créant pas dès le début:

New-AzureService -ServiceName $serviceName -Location $location

$Config = New-AzureVMConfig -Name $vmName -InstanceSize $size -ImageName $imageName
$Config | Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd –NoWinRMEndpoint
$config | New-AzureVM -ServiceName $serviceName  -WaitForBoot

Un certificat sera tout de même créé il suffit de rajouter le point de terminaison. On peut également ne pas créer le certificat que ce soit celui Azure ou un passé en paramètre:

$Config | Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd –DisableWinRMHttps

 

EnableWinRMHttp permet d’activer WinRM en HTTP (port 5985). Pour faire du remoting de VM à VM avec l’IP interne. cela suppose bien entendu que les VM soient sur le même réseau.

Les extensions Azure

On peut activer différentes extensions Azure depuis PowerShell. Par exemple pour retrouver les extensions d’une VM on peut lancer:

Get-AzureVM -ServiceName $serviceName -Name $vmName |Get-AzureVMExtension

Qui va par exemple afficher:

2015-04-21_07-54-57

BGInfo est l’extension qui affiche des informations au sujet VM sur le bureau. Elle est installée par défaut. Le nom des extensions suit une systématique:

AzureVM*Extension

Pour les extensions de VM. Par exemple on récupère la liste ainsi:

get-command | where {$_.Name -like « get-*azurevm*extension »} | select -ExpandProperty Noun

2015-04-21_07-59-01

Celle qui nous intéresse ici est CustomScript. Nous allons voir le pattern utilisé pour activer une extension.

Note: Pour activer une extension un agent doit avoir été déployé sur la VM, c’est le cas par défaut, mais on pourrait choisir de ne pas le faire:

Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd –DisableGuestAgent

Pour en savoir un peu plus:

http://blogs.msdn.com/b/mast/archive/2014/02/17/bginfo-guest-agent-extension-for-azure-vms.aspx

Note: contrairement à ce qui est écrit dans l’article, c’est avec Add-AzureProvisioningConfig que l’on désactive l’agent, pas New-AzureVM

Et aussi:

https://msdn.microsoft.com/fr-fr/library/azure/dn606311.aspx

 

On peut obtenir la liste des agents installés sur une VM depuis le portail en se rendant dans le tableau de bord de la VM:

2015-04-21_08-10-50Contrairement au script précédent, la VM doit avoir été lancée pour que cela s’affiche!

On peut installer une extension sur une VM déjà créée, mais seulement depuis le nouveau portail:

2015-04-21_08-22-53

 

Pour finir les extensions émettent des logs dans le répertoire:

C:\WindowsAzure\Logs\Plugins

L’extension CustomScript

Cette extension est typiquement utilisée pour lancer des scripts complémentaires lors de la création d’une VM. Par exemple reformater un disque de données, déployer ou activer un service Windows… Mais on peut s’en servir pour lancer un script à tout instant. Nous allons démontrer les deux scénarios.

Dans tous les cas la  cmdlet est Set-AzureVMCustomScriptExtension.

 

Tout d’abord il nous faut un script. Le script peut se trouver dans un stockage Azure ou bien dans Github.

Je créée un fichier test.ps1 contenant ce valeureux script:

$stream = [System.IO.StreamWriter] « d:\test.txt »

1..10000 | % {
      $stream.WriteLine($s)
}

$stream.close()

Je l’installe dans le blob:

$uri = »https://demordpstorage.blob.core.windows.net/scripts/test.ps1″

Et je lance la création de la VM:

$familyName= « Windows Server 2012 R2 Datacenter »
$size= « Small »
$vmName= « AmethysteVM »
$serviceName= »serviceAmethyste »
$location = « West Europe »
$user= « admin489 »
$pwd= « azerty@12345 »
$storage = « demordpstorage »
$container= »scripts »
$scriptName= »test.ps1″

New-AzureService -ServiceName $serviceName -Location $location

$imageName = get-azurevmimage | where {$_.ImageFamily -eq $familyName}| sort PublishedDate -Descending|select -ExpandProperty ImageName -First 1

$uri= »http://$storage.blob.core.windows.net/$container/$scriptName »

$Config = New-AzureVMConfig -Name $vmName -InstanceSize $size -ImageName $imageName
$Config | Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd 
$config | Set-AzureVMCustomScriptExtension -FileUri $uri -Run $scriptName
$config | New-AzureVM -ServiceName $serviceName  -WaitForBoot

On pourrait si nécessaire passer un paramètre avec l’argument Argument. FileUri attend un tableau, on peut donc passer plusieurs valeurs, il suffit de les séparer par une virgule.

Une des étapes du déploiement devrait afficher ceci:

2015-04-22_10-01-12

Qui indique qu’une extension est en cours d’installation.
On vérifie l’apparition du fichier c:\test.txt. On peut aussi se rendre dans le tableau de bord de la VM qui indique le statut de la dernière exécution:

2015-04-21_17-54-47

Note: Le script suppose que le blob soit accessible en public sinon ça ne marchera pas.

 

Une autre possibilité est d’installer le script dans Github. Une démonstration se trouve ici:

http://azure.microsoft.com/blog/2014/08/20/automate-linux-vm-customization-tasks-using-customscript-extension/

 

Le script peut être lancé en ligne de commande même une fois que la VM a été construite. Bien sur il nous faut installer l’extension si cela n’a pas été fait à la création. On peut le faire depuis le portail (le nouveau uniquement):

2015-04-21_08-24-46

On peut désactiver l’extension:

Set-AzureVMCustomScriptExtension -Disable

On pourrait aussi désinstaller l’extension avec l’argument Uninstall.

L’exécution en ligne du script peut se faire ainsi:

get-azurevm -ServiceName $servicename -Name $vmName |
Set-AzureVMCustomScriptExtension -FileName $scriptName -StorageAccountName $storage -ContainerName $container -Run $scriptName  |
Update-AzureVM

Note: bien sûr, la syntaxe avec FileUri est tout à fait valable.

Il existe une dernière possibilité, déclarer le script depuis le portail lorsque l’on créée une VM depuis la galerie:

2015-04-22_21-55-35

Si on coche Custom Script, un formulaire s’ouvre afin de désigner un script de configuration et ses éventuels paramètres.

L’extension DSC

Note: DSC est du gros morceau. Il ne s’agit ici que d’un tutoriel, je ne prétends certainement pas faire le tour de cet outil.

Les fondamentaux

DSC est une extension de PowerShell 4, livrée avec Windows 2012 R2 et Windows 8.1. On peut vérifier sa version en entrant:

$PSVersionTable

DSC permet de configurer une VM de façon déclarative plutôt qu’au niveau d’un script. L’architecture DSC repose sur trois éléments:

  1. Un script de configuration en PowerShell
  2. Conversion du fichier au format MOF (Managed Object Format) qui sera consommé par DSC
  3. Un agent d’exécution, le LCM (Local Configuration Manager)

Et deux modes de fonctionnement:

  1. Push
    On lance depuis un serveur un script DSC sur une liste de machines (les nœuds)
  2. Pull
    On place le script sur un serveur doté d’un service Web. Les nœuds font appel à ce service pour récupérer le script et le lancer

Schématiquement pour que les choses soient plus claires:

2015-04-25_22-16-25

Un serveur dédié au déploiement lance un script avec 3 nœuds pour configurer un serveur Web, un serveur de base de données et un serveur de domaine. C’est le serveur qui initie la demande et lance le déploiement. C’est le mode push.

En pull le schéma est celui-là:

2015-04-25_22-26-55

Les serveurs sont les même, mais le sens des flèches est différent. Le déclenchement de la configuration est effectué à l’initiative des serveurs cible. Il peut être déclenché ou planifié.

La capacité de DSC de supporter à la fois du pull et du push est intéressante et c’est précisément ce qui manque aux Group Policy qui ne distribue des configurations qu’en  push. Push est je pense le modèle de choix pour garantir que votre parc de VM Azure ne verra pas sa configuration dériver au fil du temps. Le système détecte automatiquement toutes dérives et la corrige aussitôt.

 

Notez tout de suite un point, DSC s’appuie sur PowerShell Remoting qui devra donc être activé.

 

Examinons un exemple que l’on supposera dans le fichier config.ps1. On peut écrire ce script avec Notepad si on le souhaite, mais c’est plus confortable depuis la console ISE qui dispose d’IntelliSense et de la vérification syntaxique. Le script installe le rôle IIS sur un serveur:

Configuration ContosoWebsite
{
  param ($MachineName)
  Node $MachineName
  {
    #Installer le Rôle IIS 
    WindowsFeature IIS
    {
      Ensure = « Present » 
      Name = « Web-Server » 
    }
  }
}

Le mot clef Configuration définit une configuration appelée ContosoWebSiteNode désigne la VM cible du script. On peut avoir plusieurs nœuds correspondants à autant de VM chacune avec sa configuration. C’est un scénario typique du mode de fonctionnement pull. En gras dans le script sont signalés des fournisseurs. DSC est livré avec des fournisseurs standards que l’on peut retrouver ici:

https://technet.microsoft.com/en-us/library/dn249921.aspx

Il existe d’autres fournisseurs que l’on peut utiliser, par exemple ici:

https://gallery.technet.microsoft.com/scriptcenter/DSC-Resource-Kit-All-c449312d

 

Pour obtenir la liste des ressources installées dans votre environnement:

Get-DSCResource

On peut en ajouter d’autres ou bien en créer soi-même.

Chaque fournisseur a son jeu particulier de propriétés, mais certaines sont récurrentes comme Ensure. Ensure prend deux valeurs  « Present » ou « Absent« . Present indique que la ressource doit être installée si elle est absente du serveur et Absent qu’elle doit au contraire être désinstallée.

Name est le nom de la feature que l’on souhaite installer. IIS est juste le nom de la ressource, on peut mettre ce que l’on souhaite, mais c’est mieux que ce soit plus informatif que « Marcel« . Comme on le voit une Configuration est une fonction puisqu’elle peut avoir des paramètres et en reprend la syntaxe.

Le principe de DSC est donc simple. On décrit la configuration que l’on souhaite et le moteur DSC se charge de gérer la logique qui charge les ressources, vérifier que les services soient dans l’état voulu ou les activer/désactiver si nécessaire.

 

Pour terminer le chapitre, un tutoriel pour déboguer les problèmes de DSC:

http://blogs.technet.com/b/learningittogether/archive/2014/10/09/troubleshooting-the-dsc-extension-for-azure.aspx

Premier exemple

Essayons maintenant de faire fonctionner le script précédent en mode push qui est le plus facile à mettre en œuvre. On commence par le publier sur un compte de stockage Azure avec Publish-AzureVMDscConfiguration:

Publish-AzureVMDscConfiguration -ConfigurationPath « config.ps1 »

ConfigurationPath désigne un fichier ps1, un module PowerShell ou un zip. La cmdlet publie l’ensemble des ressources requises pour exécuter la configuration.

Avec les valeurs par défaut la publication a lieu dans le conteneur Windows-powershell-dsc:

2015-04-21_22-26-55

On remarque que les ressources sont disposées dans un .zip. Une fois le script publié il peut s’appliquer à n’importe quelle VM pendant sa création ou après. Puisque DSC apparaît sous la forme d’une extension on l’exécute avec du code similaire à celui présenté au chapitre précédent:

$Config = New-AzureVMConfig -Name $vmName -InstanceSize $size -ImageName $imageName
$Config | Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $pwd 
$config | Set-AzureVMDscExtension -ConfigurationArchive config.ps1.zip -ConfigurationArgument @{MachineName = « $vmName »} -ConfigurationName « ContosoWebsite »
$config | New-AzureVM -ServiceName $serviceName  -WaitForBoot

  • ConfigurationArchive
    Le nom du blob avec le script et les ressources
  • ConfigurationArgument
    Hashtable avec les arguments, s’il y en a
  • ConfigurationName
    Nom de la fonction de configuration

Testez le script et vérifiez sur le serveur que le rôle a été activé.

Tout ce qui a été dit sur les extensions précédemment s’applique aussi à DSC. Si l’extension est activée sur la VM il est possible de lancer un script de configuration à tout moment.

Pourquoi Publish-AzureVMDscConfiguration?

Il existe d’autres moyens de pousser un zip sur un blob. Dans les coulisses, Publish-AzureVMDscConfiguration fait pas mal de travail laborieux à notre place. Regardons un autre exemple plus sophistiqué.

Dans cet exemple très classique nous allons déployer un site web en garantissant qu’il a le bon environnement .Net:

Configuration ContosoWebsite
{

Import-DSCResource -Module xWebAdministration

  # installer IIS
  WindowsFeature IIS
  {
   Ensure = « Present »
   Name = « Web-Server »
  }
  
  #Installer .Net 4.5
  WindowsFeature AspNet45
  {
   Ensure = « Present »
   Name = « Web-ASP-Net45 »
  }
  
  #Arrêter le site par défaut
  xWebSite DefaultSite
  {
   Ensure = « Present »
   Name = « Default Web Site »
   State = « Stopped »
   PhysicalPath = »c:\inetpub\wwwroot »
   DependsOn = »[WindowsFeature]IIS »
  }
  
  #Copier le contenu du site
  File WebContent
  {
   Ensure = « Present »
   SourcePath = »C:\inetpub\Contoso »
   DestinationPath = « c:\inetpub\contoso »
   Recurse=$true
   Type= »Directory »
   DependsOn = »[WindowsFeature]AspNet45″
  }
  
  #Créer le site et le lancer
  xWebSite Contoso
  {
   Ensure = « Present »
   Name = « Site Contoso »
   State = « Started »
   PhysicalPath = »c:\inetpub\contoso »
   DependsOn = »[File]WebContent »
  }
}

Commentons un peu ce script:

  • DependsOn: indique que la ressource AspNet45 doit avoir été installé avant de configurer la ressource courante
  • Recurse: $true indique que les sous-répertoires doivent aussi être copiés. Cette propriété n’a de sens que si Type est à Directory
  • Type: File ou Directory pour indiquer que la ressource est un fichier ou un répertoire
  • SourcePath: c’est l’emplacement du site. Je l’ai déployé sur mon poste
  • DestinationPath: emplacement du site sur la VM cible

Le script démarre par un appel à la cmdlet Import-DscRessource qui sert comme l’indique son nom, à importer la ressource xWebAdministration dans le package.

Le déroulé du script est le suivant:

  1. Activer le rôle IIS
  2. Vérifier que .Net 4.5 est installé
  3. Arrêter le site par défaut
  4. Copier le source du site de Contoso
  5. Créer le site web et le lancer
    Faudra donc créer un site web basique pour tester l’exemple

On remarque tout de suite un fournisseur ne faisant pas partie du package standard: xWebSite. On doit le télécharger ici:

https://gallery.technet.microsoft.com/scriptcenter/xWebAdministration-Module-3c8bb6be

On télécharge le zip et le déploie dans le répertoire:

C:\Program Files\WindowsPowerShell\Modules

J’ai un peu galéré la dessus. Les conditions pour que ça fonctionne:

  • Les répertoires en MSFT_* se trouvent dans
    C:\Program Files\WindowsPowerShell\Modules\xWebAdministration\DSCResources
  • Le fichier de manifeste en *.psd1 se trouve dans:
    C:\Program Files\WindowsPowerShell\Modules\xWebAdministration

Si on lance Get-DSCResource :

2015-04-22_13-58-21

Voici un peu d’aide:

http://blogs.msdn.com/b/powershell/archive/2013/12/05/how-to-deploy-and-discover-windows-powershell-desired-state-configuration-resources.aspx

Note: le nom de la ressource commence par un x. Le X signifie Experimental. Il est donc probable que le nom change dans les prochaines versions de PowerShell. On peut aussi rencontrer un c pour Community. Cela signifie simplement que vous utilisez un fork Github du script.

 

Ce n’est pas tout, une partie des ressources sont locales à mon poste de travail il est hors de question qu’une VM Azure puisse y accéder. Comment les choses vont donc se passer?

On déroule la même procédure que dans le premier exemple, mais pour on va ajouter un attribut supplémentaire:

Publish-AzureVMDscConfiguration -ConfigurationPath « config.ps1 » –ConfigurationArchivePath « c:\temp\config.zip »

Il indique que le zip devra être poussé dans c:\temp et pas dans Azure, cela nous permettra de l’examiner plus facilement. Si vous ouvrez le Zip vous devriez constater que les fichiers du modules sont tous présents en plus de config.ps1:

2015-04-23_09-40-08

Malheureusement les fichiers du site web ne sont pas présents. Une solution possible (mais pas terrible) est de la copier dans les répertoires du module et de modifier en conséquence la ressource:

  #Copier le contenu du nouveau site
  File WebContent
  {
   Ensure = « Present »
   SourcePath = »C:\Program Files\WindowsPowerShell\Modules\xWebAdministration\DSCResourcesC:\Program Files\WindowsPowerShell\Modules\xWebAdministration\DSCResources »
   DestinationPath = « c:\inetpub\contoso »
   Recurse=$true
   Type= »Directory »
   DependsOn = »[WindowsFeature]AspNet45″
  }

 

On a donc pas besoin de déployer le module sur la cible. Relançons la ligne de normale afin de créer le blob:

Publish-AzureVMDscConfiguration -ConfigurationPath « config.ps1 »

Et on déploie, par exemple sur une VM existante:

get-azurevm -ServiceName $servicename -Name $vmName | Set-AzureVMDscExtension -ConfigurationArchive config.ps1.zip -ConfigurationName « ContosoWebsite » | update-azurevm

Cela prend quelques minutes et nécessite un reboot, attendre un peu donc.

On oubliera pas le point de terminaison sur le port 80 si on veut interroger le nouveau site depuis la VIP.

2015-04-23_23-10-15

Et en on premises?

DSC est une fonctionnalité PowerShell indépendante d’Azure. Rien nous oblige à lancer une configuration à travers la plomberie Azure comme on vient de le faire. Regardez ce scénario de base.

On construit le fichier config.ps1 que l’on place dans c:\:

Configuration ContosoWebsite
{
  Node « localhost »
  {

    #Installer le Rôle IIS
    WindowsFeature IIS
    {
      Ensure = « Present »
      Name = « Web-Server »
    }
  }
}

ContosoWebsite -output « . »

Depuis la console PowerShell en mode administrateur, on lance le script:

.\config.ps1

Cela aura pour effet de:

  1. Créer un répertoire c:\ContosoWebSite
  2. Dans ce répertoire créer autant de fichier *.mof qu’il y a de nœud. Chaque fichier portant le nom du nœud.
    Les fichiers *.mof sont les fichiers consommés par DSC

2015-04-22_22-44-28

Puis on lance la configuration avec:

Enable-PSRemoting -Force
Start-DscConfiguration -Path .\ContosoWebsite -ComputerName « localhost » -Wait

  • Path désigne un répertoire contenant les fichiers mof des configurations
  • ComputerName désigne la VM à configurer

Enable-PSRemoting force le remoting, DSC repose là dessus même pour une commande sur la VM locale.

On peut tester la configuration en lançant:

Test-DscConfiguration

Qui renvoi $True si la configuration de la VM est la même que celle du fichier de configuration.

Industrialiser le script de configuration

On peut souhaiter réutiliser le script qui précède afin de déployer d’autres sites Web et en tout cas rendre dynamique les ressources codées en dur. DSC propose une solution, nous allons séparer le script de ses paramètres. Ce fichiers est un fichier *.psd1 (PowerShell Data) contenant une table de hachage avec les valeurs dynamiques. Revoyons le script précédent.

Tout d’abord le fichier ContosoConfig.psd1:

@{
 AllNodes=@(
  @{
      NodeName = « localhost »

       SiteName = « Site Contoso »
       TargetPath = « c:\inetpub\contoso »
       SourcePath = « C:\Program Files\WindowsPowerShell\Modules\xWebAdministration\DSCResources\Contoso »
  }
 );
}

Notez la présence de la propriété NodeName qui indique à quel nœud s’appliquent les paramètres. « localhost » est juste un nom, vous pouvez mettre Zezette si vous voulez du moment que l’on retrouve le même nom dans le ps1.Et notre script devient, notez la syntaxe en gras:

Configuration ContosoWebsite
{
 Import-DSCResource -Module xWebAdministration

  Node localhost {
  # installer IIS
  WindowsFeature IIS
  {
   Ensure = « Present »
   Name = « Web-Server »
  }
  
  #Installer .Net 4.5
  WindowsFeature AspNet45
  {
   Ensure = « Present »
   Name = « Web-ASP-Net45 »
  }
  
  #Arrêter le site par défaut
  xWebSite DefaultSite
  {
   Ensure = « Present »
   Name = « Default Web Site »
   State = « Stopped »
   PhysicalPath = »c:\inetpub\wwwroot »
   DependsOn = »[WindowsFeature]IIS »
  }
  
  #Copier le contenu du nouveau site
  File WebContent
  {
   Ensure = « Present »
   SourcePath = $Node.SourcePath
   DestinationPath = $Node.TargetPath
   Recurse=$true
   Type= »Directory »
   DependsOn = »[WindowsFeature]AspNet45″
  }
  
  #Créer le site et le lancer
  xWebSite Contoso
  {
   Ensure = « Present »
   Name = $Node.SiteName
   State = « Started »
   PhysicalPath = $Node.TargetPath
   DependsOn = »[File]WebContent »
  }}
}

On pousse dans le blob le *.ps1 exactement comme avant:

Publish-AzureVMDscConfiguration -ConfigurationPath « c:\temp\config.ps1 » -Force

Puis on déploie presque comme avant également, en gras la différence:

get-azurevm -ServiceName $servicename -Name $vmName | Set-AzureVMDscExtension -ConfigurationArchive config.ps1.zip -ContainerName « windows-powershell-dsc » -ConfigurationName « ContosoWebsite » –ConfigurationDataPath « C:\temp\ContosoConfig.psd1 »  |
update-azurevm

Mon exemple n’est sans doute pas des plus grandiose, mais il permet de comprendre comment ça marche.

Vous avez du remarquer que le script qui précède retourne alors que l’exécution de la configuration n’a pas même démarrée. On peut donc avoir besoin de récupérer le statut en cours du script:

get-azurevm -ServiceName $servicename -Name $vmName | Get-AzureVMDscExtensionStatus

2015-04-24_23-41-29

On peut aussi souhaiter récupérer des informations sur l’extension:

get-azurevm -ServiceName $servicename -Name $vmName | Get-AzureVMDscExtension

2015-04-24_23-43-33

Lancer en Pull

La tâche demande un peu de travail et si vous souhaitez le scripter je recommande d’utiliser les cmdlet proposées par Michael Washam:

https://github.com/opsgility/azuredsc

Sinon j’ai trouvé une procédure pas à pas ici:

L’article (à par le dernier) est en français. Il n’y a donc pas vraiment de valeur ajoutée à faire un copier/coller ici

Bibliographie

DSC

Remoting

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s