Service collecteur Desired State Configuration

  • Article

Important

Le serveur collecteur (fonctionnalité Windows Service DSC) est un composant pris en charge de Windows Server. Toutefois, nous ne prévoyons pas de proposer de nouvelles fonctionnalités. nous aimerions que vous sachiez qu’une version plus récente de DSC est désormais en disponibilité générale, gérée par une fonctionnalité de Azure Policy configuration d’invité nommée. Le service de configuration invité combine les fonctionnalités d’Extension DSC, d’Azure Automation State Configuration, ainsi que les fonctionnalités les plus couramment demandées par les commentaires des clients. La configuration invité comprend également une prise en charge d’ordinateur hybride via des serveurs avec Arc.

Le gestionnaire de configuration local peut être centralisée par une solution de service collecteur. Lorsque vous utilisez cette approche, le nœud géré est inscrit auprès d’un service et se voit affecter une configuration dans les paramètres LCM. La configuration et toutes les ressources DSC nécessaires en tant que dépendances de la configuration sont téléchargées sur l’ordinateur et utilisées par le Gestionnaire de configuration local pour gérer la configuration. Des informations sur l’état de l’ordinateur géré sont chargées sur le service pour créer des rapports. Ce concept est appelé « service collecteur ».

Les options actuelles du service d’extraction sont les suivantes :

  • Service de Configuration d’état souhaité d’Azure Automation
  • Service collecteur exécuté sur Windows Server
  • Solutions open source gérées par la communauté
  • Partage SMB

L’échelle recommandée pour chaque solution est la suivante :

Solution Nœuds clients
Serveur Windows Pull utilisant une base de données MDB/ESENT Jusqu’à 500 nœuds
Serveur Windows Pull utilisant une base de données SQL Jusqu’à 3 500 nœuds
Azure Automation DSC Petits et grands environnements

La solution recommandée, qui est à la fois l’option offrant le plus de fonctionnalités, est Azure Automation DSC. Aucune limite supérieure du nombre de nœuds par compte Automation n’a été identifiée.

Le service Azure peut gérer les nœuds locaux dans des centres de données privés ou dans des clouds publics tels qu’Azure et AWS. Pour les environnements où les serveurs ne peut pas se connecter directement à Internet, envisagez de limiter le trafic sortant à la seule plage IP Azure publiée (voir Plages d’adresses IP Azure Datacenter).

Fonctionnalités du service en ligne qui ne sont actuellement pas disponibles dans le service d’extraction sur Windows Server :

  • Toutes les données sont chiffrées, en transit comme au repos
  • Les certificats clients sont créés et gérés automatiquement
  • Magasin des secrets pour une gestion centralisée des mots de passe/informations d’identification, ou des variables telles que les noms des serveurs ou les chaînes de connexion
  • Gestion centralisée du nœud configuration du LCM
  • Assignation centralisée de configurations aux nœuds clients
  • Mise des modifications de la configuration en « groupes de contrôle de validité » pour effectuer des tests avant la production
  • Création de rapports graphiques
    • Détails de l’état au niveau de la granularité de la ressource DSC
    • Messages d’erreur en clair des ordinateurs clients pour la résolution des problèmes
  • Intégration à Azure Log Analytics pour les alertes, tâches automatisées, application Android/iOS pour les rapports et les alertes

Service collecteur DSC dans Windows Server

Il est possible de configurer un service collecteur pour l’exécuter sur Windows Server. Notez que la solution de service collecteur incluse dans Windows Server contient uniquement les fonctionnalités de stockage des configurations et modules à télécharger, et les fonctionnalités de capture de données de rapport dans une base de données. Elle ne contient pas les nombreuses fonctionnalités offertes par le service dans Azure et n’est donc pas un bon outil pour évaluer la manière dont le service doit être utilisé.

Le service collecteur proposé dans Windows Server est un service web dans IIS qui utilise une interface OData pour mettre les fichiers de configuration DSC à la disposition des nœuds cibles quand ceux-ci en ont besoin.

Configuration requise pour utiliser un serveur collecteur :

  • Un serveur en cours d’exécution :
    • WMF/PowerShell 4.0 ou version supérieure
    • Rôle serveur IIS
    • Service DSC
  • Idéalement, des moyens de générer un certificat pour sécuriser les informations d’identification transmises au gestionnaire de configuration local sur les nœuds cibles

La meilleure façon de configurer Windows Server pour héberger un service collecteur est d’utiliser une configuration DSC. Vous trouverez ci-dessous un exemple de script.

Systèmes de base de données pris en charge

WMF 4.0 WMF 5.0 WMF 5.1 WMF 5.1 (Windows Server Insider Preview 17090)
MDB ESENT (par défaut), MDB ESENT (par défaut), MDB ESENT (par défaut), SQL Server, MDB

À compter de la version 17090 de Windows Server, SQL Server est une option prise en charge du service collecteur (fonctionnalité Windows Service DSC). Vous disposez ainsi d’une nouvelle option pour mettre à l’échelle les grands environnements DSC qui n’ont pas été migrés vers Azure Automation DSC.

Notes

La prise en charge de SQL Server ne sera pas ajoutée aux versions précédentes de WMF 5.1 (ou versions antérieures) et sera uniquement disponible dans les versions de Windows Server supérieures ou égales à 17090.

Pour configurer le serveur collecteur de manière à utiliser SQL Server, définissez SqlProvider sur $true et SqlConnectionString sur une chaîne de connexion SQL Server valide. Pour plus d’informations, consultez Chaînes de connexion SqlClient. Pour obtenir un exemple de configuration de SQL Server avec xDscWebService, lisez d’abord Utilisation de la ressource xDscWebService, puis consultez l’exemple 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 sur GitHub.

Utilisation de la ressource xDSCWebService

Le moyen le plus simple de configurer un serveur collecteur web consiste à utiliser la ressource xDscWebService qui se trouve dans le module xPSDesiredStateConfiguration. Les étapes suivantes expliquent comment utiliser la ressource dans une Configuration qui configure le service web.

  1. Appelez l’applet de commande Install-Module pour installer le module xPSDesiredStateConfiguration.

    Notes

    Install-Module est inclus dans le module PowerShellGet de PowerShell 5.0 et versions ultérieures.

  2. Obtenez un certificat SSL pour le serveur collecteur DSC auprès d’une autorité de certification approuvée, au sein de votre organisation ou auprès d’une autorité publique. Le certificat reçu de l’autorité est généralement au format PFX.

  3. Installez le certificat sur le nœud qui sera le serveur DSC à l’emplacement par défaut, c’est-à-dire CERT:\LocalMachine\My.

    • Notez l’empreinte de certificat.

  4. Sélectionnez un GUID à utiliser comme clé d’inscription. Pour en générer un à l’aide de PowerShell, entrez ce qui suit à l’invite PowerShell et appuyez sur Entrée : [guid]::newGuid() ou New-Guid. Cette clé est utilisée par les nœuds clients comme une clé partagée pour l’authentification lors de l’inscription. Pour plus d’informations, consultez la section Clé d’inscription ci-dessous.

  5. Dans PowerShell ISE, démarrez (F5) le script de configuration suivant (inclus dans le dossier du module xPSDesiredStateConfiguration en tant que Sample_xDscWebServiceRegistration.ps1). Ce script configure le serveur collecteur.

    configuration Sample_xDscWebServiceRegistration
{
    param
    (
        [string[]]$NodeName = 'localhost',

        [ValidateNotNullOrEmpty()]
        [string] $certificateThumbPrint,

        [Parameter(HelpMessage='This should be a string with enough entropy (randomness)' +
            ' to protect the registration of clients to the pull server.  We will use new' +
            ' GUID by default.'
        )]
        [ValidateNotNullOrEmpty()]
        [string] $RegistrationKey   # A guid that clients use to initiate conversation with pull server
    )

    Import-DSCResource -ModuleName PSDesiredStateConfiguration
    Import-DSCResource -ModuleName xPSDesiredStateConfiguration

    Node $NodeName
    {
        WindowsFeature DSCServiceFeature
        {
            Ensure = "Present"
            Name   = "DSC-Service"
        }

        xDscWebService PSDSCPullServer
        {
            Ensure                  = "Present"
            EndpointName            = "PSDSCPullServer"
            Port                    = 8080
            PhysicalPath            = "$env:SystemDrive\inetpub\PSDSCPullServer"
            CertificateThumbPrint   = $certificateThumbPrint
            ModulePath              = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
            ConfigurationPath       = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
            State                   = "Started"
            DependsOn               = "[WindowsFeature]DSCServiceFeature"
            RegistrationKeyPath     = "$env:PROGRAMFILES\WindowsPowerShell\DscService"
            AcceptSelfSignedCertificates = $true
            UseSecurityBestPractices     = $true
            Enable32BitAppOnWin64   = $false
        }

        File RegistrationKeyFile
        {
            Ensure          = 'Present'
            Type            = 'File'
            DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
            Contents        = $RegistrationKey
        }
    }
}

  6. Exécutez la configuration, en passant l’empreinte du certificat SSL comme paramètre certificateThumbPrint et une clé d’inscription GUID comme paramètre RegistrationKey :

    # To find the Thumbprint for an installed SSL certificate for use with the pull server list all
# certificates in your local store and then copy the thumbprint for the appropriate certificate
# by     reviewing the certificate subjects

dir Cert:\LocalMachine\my

# Then include this thumbprint when running the configuration
$sample_xDscWebServiceRegistrationSplat = @{
    certificateThumbprint = 'A7000024B753FA6FFF88E966FD6E19301FAE9CCC'
    RegistrationKey = '140a952b-b9d6-406b-b416-e0f759c9c0e4'
    OutputPath = 'C:\Configs\PullServer'
}
Sample_xDscWebServiceRegistration @sample_xDscWebServiceRegistrationSplat

# Run the compiled configuration to make the target node a DSC Pull Server
Start-DscConfiguration -Path c:\Configs\PullServer -Wait -Verbose

Clé d’inscription

Pour que les nœuds clients puissent s’inscrire auprès du serveur afin de pouvoir utiliser les noms de configuration au lieu de l’ID de configuration, une clé d’inscription, créée par la configuration ci-dessus, est enregistrée dans un fichier nommé RegistrationKeys.txt dans C:\Program Files\WindowsPowerShell\DscService. La clé d’inscription fonctionne comme un secret partagé utilisé lors de l’inscription initiale par le client avec le serveur collecteur. Le client génère un certificat auto-signé qui est utilisé pour l’authentification unique auprès du serveur collecteur, une fois l’inscription terminée. L’empreinte de ce certificat est stockée localement et associée à l’URL du serveur collecteur.

Notes

Les clés d’inscription ne sont pas prises en charge dans PowerShell 4.0.

Pour configurer un nœud pour l’authentification auprès du serveur collecteur, la clé d’inscription doit se trouver dans la métaconfiguration de tous les nœuds cibles que vous prévoyez d’inscrire auprès de ce serveur. Notez que la propriété RegistrationKey dans la métaconfiguration ci-dessous est supprimée une fois que l’ordinateur cible a été correctement inscrit, et que la valeur doit correspondre à celle stockée dans le fichier RegistrationKeys.txt sur le serveur collecteur (« 140a952b-b9d6-406b-b416-e0f759c9c0e4 » dans cet exemple). Conservez la valeur de la clé d’inscription en lieu sûr, car elle permet d’inscrire n’importe quel ordinateur cible auprès du serveur.

[DSCLocalConfigurationManager()]
configuration Sample_MetaConfigurationToRegisterWithLessSecurePullServer
{
    param
    (
        [ValidateNotNullOrEmpty()]
        [string] $NodeName = 'localhost',

        [ValidateNotNullOrEmpty()]
        [string] $RegistrationKey, # the key used to set up pull server in previous configuration

        [ValidateNotNullOrEmpty()]
        [string] $ServerName = 'localhost' # The name of the pull server, same as $NodeName used in previous configuration
    )

    Node $NodeName
    {
        Settings
        {
            RefreshMode        = 'Pull'
        }

        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL          = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey    = $RegistrationKey
            ConfigurationNames = @('ClientConfig')
        }

        ReportServerWeb CONTOSO-PullSrv
        {
            ServerURL       = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey = $RegistrationKey
        }
    }
}

$MetaConfigurationSplat = @{
    RegistrationKey = $RegistrationKey
    OutputPath = 'c:\Configs\TargetNodes'
}

Sample_MetaConfigurationToRegisterWithLessSecurePullServer @MetaConfigurationSplat

Notes

La section ReportServerWeb permet d’envoyer les données de rapport au serveur collecteur.

Si la propriété ConfigurationID est absente du fichier de métaconfiguration, cela signifie implicitement que ce serveur collecteur prend en charge la version V2 du protocole du serveur collecteur et donc qu’une inscription initiale est nécessaire. Inversement, si la propriété ConfigurationID est présente, la version V1 du protocole du serveur collecteur est utilisée et il n’y a pas de traitement de l’inscription.

Notes

Dans un scénario PUSH, la version actuelle contient un bogue qui demande de définir une propriété ConfigurationID dans le fichier de métaconfiguration pour les nœuds qui n’ont jamais été inscrits auprès d’un serveur Pull. Cette opération permet de forcer le protocole du serveur collecteur V1 et d’éviter les messages d’échec d’inscription.

Placement des configurations et des ressources

Une fois l’installation du serveur collecteur terminée, vous placez les modules et configurations à extraire par les nœuds cibles dans les dossiers définis par les propriétés ConfigurationPath et ModulePath de la configuration du serveur collecteur. Ces fichiers doivent se trouver dans un format spécifique afin que le serveur collecteur puisse les traiter correctement.

Format du package de module de ressources DSC

Chaque module de ressources doit être compressé et nommé selon le modèle suivant : {Module Name}_{Module Version}.zip

Par exemple, un module xWebAdminstration avec une version de module 3.1.2.0 est nommé xWebAdministration_3.1.2.0.zip. Chaque version d’un module doit être contenue dans un seul fichier zip. Étant donné que chaque fichier zip ne contient qu’une seule version d’une ressource, le format du module ajouté dans WMF 5.0, qui contient plusieurs versions de module dans un seul répertoire, n’est pas pris en charge. Cela signifie qu’avant de créer le package des modules de ressources DSC à utiliser avec le serveur collecteur, vous devez apporter une petite modification à la structure de répertoires. Le format par défaut des modules contenant des ressources DSC dans WMF 5.0 est {Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\. Avant de créer des packages pour le serveur collecteur, supprimez le dossier {Module version} afin que le chemin devienne {Module Folder}\DscResources\{DSC Resource Folder}\. Ensuite, compressez le dossier comme décrit ci-dessus et placez ces fichiers zip dans le dossier ModulePath.

Utilisez New-DscChecksum {module zip file} afin de créer un fichier de somme de contrôle pour le module qui vient d’être ajouté.

Format du fichier MOF de configuration

Un fichier MOF de configuration doit être associé à un fichier de somme de contrôle pour que le gestionnaire de configuration local sur un nœud cible puisse valider la configuration. Pour créer une somme de contrôle, appelez l’applet de commande New-DscChecksum. L’applet de commande prend un paramètre Path qui spécifie le dossier où se trouve le fichier MOF de configuration. L’applet de commande crée un fichier de somme de contrôle nommé ConfigurationMOFName.mof.checksum, où ConfigurationMOFName est le nom du fichier MOF de configuration. S’il existe plusieurs fichiers MOF de configuration dans le dossier spécifié, une somme de contrôle est créée pour chaque configuration du dossier. Placez les fichiers MOF et leurs fichiers de somme de contrôle associés dans le dossier ConfigurationPath.

Notes

Si vous modifiez le fichier MOF de configuration de quelque façon que ce soit, vous devez aussi recréer le fichier de somme de contrôle.

Outillage

Pour faciliter la configuration, la validation et la gestion du serveur collecteur, les outils suivants sont fournis comme exemples dans la dernière version du module xPSDesiredStateConfiguration :

  1. Module permettant de créer le package des modules de ressources DSC et les fichiers de configuration à utiliser sur le serveur collecteur. PublishModulesAndMofsToPullServer.psm1. Exemples ci-dessous :

    # Example 1 - Package all versions of given modules installed locally and MOF files are in c:\LocalDepot
$moduleList = @('xWebAdministration', 'xPhp')
Publish-DSCModuleAndMof -Source C:\LocalDepot -ModuleNameList $moduleList

# Example 2 - Package modules and mof documents from c:\LocalDepot
Publish-DSCModuleAndMof -Source C:\LocalDepot -Force

  2. Script qui valide la configuration du serveur collecteur. PullServerSetupTests.ps1.

Solutions de service collecteur de la communauté

La communauté DSC a créé plusieurs solutions pour implémenter le protocole de service collecteur. Pour les environnements locaux, elle offre des fonctionnalités de service collecteur et la possibilité de contribuer en retour avec des améliorations incrémentielles.

Configuration du client collecteur

Les rubriques suivantes décrivent la configuration des clients collecteurs en détail :

Voir aussi