PI Services

Le blog des collaborateurs de PI Services

Desired State Configuration (Partie 1) : Introduction et syntaxe

Introduction

Powershell 4.0 (introduit avec Windows 2012 R2) apporte son lot de nouveautés. La plus importante est : Desired State Configuration.

En entreprise, il existe deux problématiques récurrentes au sein d’un système d’informations :

  • L’augmentation du nombre de serveurs
  • Le changement

Desired State Configuration apporte une solution à ces questions en proposant une solution pour l’automatisation des déploiements et la maintenance des serveurs (contrôle et retour en conformité).

Avec cette fonctionnalité, il sera possible de déployer rapidement et à grande échelle des améliorations à une infrastructure, tout en s’assurant que les systèmes ne varient pas au cours du temps.

Par exemple, on peut vouloir s’assurer qu’un groupe de serveurs web possède :

  • le rôle adéquat correctement configuré,
  • les services nécessaires démarrés
  • les sources valides d’un site web copiées dans le bon répertoire
  • la bonne adresse IP pour chaque serveur.

DSC permet de configurer un serveur via un script au travers d’une syntaxe simple (similaire aux fonctions Powershell). Les possibilités de configuration sont infinies (rôles, groupes et utilisateurs locaux, registre…). Cette configuration peut se faire en local ou à distance. De plus, au delà de la première application de la configuration du serveur, il existe des mécanismes de contrôles. Avec Desired State Configuration, Windows peut automatiquement vérifier si sa configuration est correcte et la remettre à niveau s’il y a eu un changement anormal. Ainsi, les dérives de configuration sont évitées !

    Pour appliquer une configuration, il existe deux modes :

  • Push : La configuration est envoyé au serveur
  • Pull : La configuration est demandé par le serveur client vers un serveur centrale qui gère toutes les configurations possibles.

Grâce au scripting il va être possible d’appliquer des configuration à des groupes de serveurs.

DSC est basé sur les fichiers “.mof”. Il est possible de les générer de la façon que l’on souhaite (éditeur de texte par exemple). Powershell 4.0 permet de simplifier la génération de ses fichiers notamment grâce à l’auto complétion mais aussi avec syntaxe accessible. Via le module PSDesiredStateConfiguration, on peut créer ses fichiers et les utiliser pour appliquer une configuration.

Cet article fait partie d’une série de 5 billets sur Desired State Configuration :

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Winsows 2012/8 et Windows 2008 R2/7.

Les ressources

Les éléments que l’on va pouvoir configurer sont appelés ressources.

Voici quelques exemples de ressources disponibles nativement : l’exécution de services, de clés de registre, de scripts ou de variables d’environnement. Les groupes et utilisateurs locaux ainsi que la copie de fichiers sur un serveur est aussi gérable. Les possibilités sont infinies.

Il est aussi possible de créer ses propres ressources, en définissant la façon de réaliser la configuration sur le serveur et de tester la conformité. Ainsi on peut imaginer une ressource qui s’occupera de la gestion du fichier “hosts”, un autre peut gérer la configuration IP ou même la présence et l’activation de règle firewall.

La liste des ressources disponibles nativement est listé dans le lien suivant : http://technet.microsoft.com/en-us/library/dn249921.aspx

La syntaxe

La syntaxe Powershell implémentée se base sur le mot clé Configuration. Voici un exemple :

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
Configuration TestDSC 
{ 

  Node WEBSRV01 #Nom du serveur
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” #Vérifie que le rôle est présent
      Name = “Web-Server” #Nom du rôle ou de la fonctionnalité à vérifier
    } 

    File DirectoryCopy
    {
        Ensure = "Present" #Vérifie que les fichiers/dossiers sont présents
        Type = "Directory" #Type d'objet à vérifier
        Recurse = $true #Inclus les fichiers/dossiers enfants
        SourcePath = "\\FILESRV01\MyWebSite" #Chemin des sources
        DestinationPath = "C:\inetpub\wwwroot\MyWebsite" #Destination où doivent se trouver les données
    }
   
    Group ViewerGroup
    {
        Ensure = "Present" #Vérifie qu'un groupe est présent
        GroupName = "Viewer" #Nom du groupe
    }
  } 
}

La déclaration se fait donc via des blocs entre accolades. Dans un bloc de type Configuration, on a un ou plusieurs blocs Node. Pour chaque bloc Node, un fichier MOF sera généré. A côté de ce mot clé, on inscrit le nom du serveur qui possédera cette configuration. A l’intérieur de chacun de ses blocs se trouvent les ressources que l’on souhaitent configurer. Dans l’exemple précédent, on retrouve dans l’ordre les 3 ressources suivantes :

  • WindowsFeature : S’assure que le rôle IIS est installée.
  • File : Vérifie que les fichiers sont bien présents sur le répertoire de destination.
  • Group : Constate que le groupe local Viewer existe.

Dans le cas où l’une des ressources retournerait un résultat incorrect alors l’opération serait réalisée afin de mettre l’ordinateur en conformité. Par exemple, pour les sources du site web (Ressource WebsiteDirectory), le fichier de configuration possède le chemin source et la destination.

Pour générer le fichier MOF, il faut appeler notre configuration comme une fonction Powershell :

001
TestDSC -OutputPath c:\DSCConfig

Le paramètre OutputPath (facultatif) définie le dossier où vont être stockés les fichiers de configuration. Le fichier créé portera le nom de la machine portant cette configuration (ici WEBSRV01).

A l’instar des fonctions, on peut utiliser des paramètres. Voici, un exemple similaire au précédent où l’on spécifie la source et la destination des fichiers du site web ainsi qu’une liste de nom d’ordinateur auxquels appliquer cette configuration.

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
Configuration TestDSC 
{ 
 
  param(
    [Parameter(Mandatory=$true)]
    [String[]]$Computers,
    [Parameter(Mandatory=$true)]
    [String]$SourceWeb,
    [Parameter(Mandatory=$true)]
    [String]$DestinationWeb 
  )

  Node $Computers 
  { 
    WindowsFeature IIS 
    { 
      Ensure = “Present” 
      Name = “IIS-Server” 
    } 

    File DirectoryCopy
    {
        Ensure = "Present"
        Type = "Directory"
        Recurse = $true 
        SourcePath = $SourceWeb
        DestinationPath = $DestinationWeb 
    }

  } 
}

Il y aura autant de fichiers MOF générés que de noms dans le paramètre Computers. Voici la commande pour créer les fichiers MOF :

001
002
003
TestDSC -Computers @("WEBSRV01","WEBSRV02","WEBSRV03") `
-SourceWeb "\\FILESRV01\MyWebSite" -DestinationWeb "C:\inetpub\wwwroot\MyWebsite"`
-OutputPath c:\DSCConfig

Application d’une configuration

Ici, nous allons aborder brièvement l’application d’une configuration en local via le mode Push. Le détail de ce mode est expliqué dans la partie 2 de l’article sur Desired State Configuration. On utilise la commande Start-DscConfiguration. Voici l’explication des paramètres utilisées dans la commande ci-dessous :

  • Wait : Ne rend pas la main à l’utilisateur tant que la commande est en cours d’exécution (Par défaut l’exécution de DSC se fait en arrière plan).
  • Verbose : Affiche les opérations effectuées.
  • Path : Le dossier où se toruve le fichier MOF (DSC choisi le fichier portant le nom de l’ordinateur).
001
Start-DscConfiguration -Wait -Verbose -Path C:\DSCConfig

Il ne peut y avoir qu’une configuration active par machine. Si une seconde configuration est appliquée, il n’y aura plus de contrôle de conformité sur les ressources non présentes dans la nouvelle configuration.

Reporting Services: InvalidReportLink

 

Dans certains cas un message d’erreur est renvoyé lors de l’exécution de rapports sous SQL Reporting Services faisant état d’un lien invalide:

image

Si vous ouvrez le même rapport directement depuis le site web de votre instance Reporting Services (Dans cet exemple un rapport sur les performances mémoire de Sharepoint), le message est effectivement le même.

image 

image

Pour corriger cela, ouvrez les propriétés du rapport, toujours sur le même site (Pas le fichier .rdpl, mais le fichier du même nom, qui n’a pas d’extension affiché) et sélectionnez Gérer.

image

image

A présent il faut cliquer sur Changer le lien. Vous pouvez vous referez a un environnement de test, de preprod, pour voir quel est le lien vers la définition du rapport (Dans cet exemple il s’agit d’un rapport issu de System Center Operations Manager. La majorité des rapports de performance sont rattaché a Microsoft.SystemCenter.Datawarehouse.Report.Performance).

Cliquez sur Changer le lien, sélectionnez la définition du rapport et cliquez OK

image

image

image

 

Le rapport a récupéré son lien. Cliquez Sur Appliquer.

image

 

Et il est a nouveau disponible a l’exécution:

image

SCOM – Orchestrator: Vidage automatique du cache de l’agent SCOM

Une des actions récurrentes pour régler certains problèmes d’exécution des règles/moniteurs de supervision consiste en le vidage du cache de données de l’agent SCOM.

Voici un exemple d’implémentation dans un runbook Orchestrator:

Au passage veillez a ranger vos runbook par thèmes et a les nommer de manière explicite

image

image

 

image

le runbook débute avec une activité “Initialize Data” mais cela pourrait être en réponse, par exemple a un évènement dans l’eventlog OperationsManager.”

“Initialize Data” permet de débuter un runbook en lui passant des paramètres de départ. Dans cet exemple, on ne passe aucun paramètre.

On arrête le service de l’agent Scom sur une machine:

imageimage

 

On vide le cache de l’agent (dossier …\System Center Operations Manager\Agent\Health Service State\Health Service Store) avec une activité de type Delete File dans l’integration Pack File Management

image

imageimage

 

La suite du workflow dépend des retours faits par l’activité de vidage du cache

Si le vidage retourne en état Failed (propriétés du lien vers “Vidage cache KO”) on affiche une erreur d’exécution dans la console Orchestrator

imageimage

imageimage

 

Si le vidage retourne en état Success on affiche un message d’information dans la console Orchestrator

image

Et dans tout les cas on redémarre a la suite le service de l’agent Scom:

imageimage

imageimage