De quel côté êtes-vous: pousser et tirer dans la configuration de l'état souhaité

Nous avons déjà décrit comment décrire la configuration dans DSC (Desired State Configuration) et désassemblé l'agent LCM (Local Configuration Manager) intégré pour appliquer la configuration sur le serveur. Dans la première partie de l'article, nous avons abordé pas à pas les principales fonctionnalités de l'outil avec Evgeny Parfenov de DataLine .

Ici, nous plongeons dans les paramètres et les fonctionnalités des modes Push et Pull.



Ce que nous dirons:


  1. Différences entre les modes Push et Pull
  2. Mode push en détail
  3. Mode Pull en détail

Différences entre les modes Push et Pull


En mode Push, nous lançons manuellement ou par script le processus d'application des modifications au serveur (localement ou à distance). Local Configuration Manager (LCM) applique la configuration de manière interactive.

En mode Pull, l'agent LCM planifié sur le serveur compare sa configuration avec la configuration publiée dans le référentiel de configuration partagé. S'il y a des changements, la configuration est copiée localement et appliquée.

Les avantages et les inconvénients des deux modes de fonctionnement sont assez évidents.
PousserTirer
+
  1. Coût. Il ne nécessite pas l'installation de serveurs supplémentaires.
  2. Architecture simple. Toutes les configurations sont stockées localement sous la forme qui convient à l'administrateur.
  3. Convient pour les tests. DSC
  4. DevOps Way. Lors du déploiement de serveurs, il est très facile à automatiser et s'inscrit dans la philosophie de l'infrastructure en tant que code.
  5. run-once .
  1. . .
  2. . DSC .
  3. Azure Automation State Configuration, Windows Server 2012R2+
  1. On-Premise c . , .
  1. , .
  2. On-Premise GPO, .
  3. — , .
La définition des ressources est également légèrement différente pour les différents modes. Comme nous nous en souvenons, pour utiliser une ressource, vous devez l'installer localement et sur le serveur.

Dans le cas de l'utilisation du mode Push, l'administrateur doit d'abord installer toutes les ressources nécessaires sur le serveur géré et sur le PC, d'où la configuration sera soumise.

En mode Pull, l'agent DSC sur le serveur géré peut installer indépendamment toutes les ressources nécessaires à partir du serveur Pull; la tâche de l'administrateur consiste à les placer sur le serveur Pull. Cependant, nous gardons à l'esprit qu'il est impossible de prédire l'application de la configuration en mode Pull, car le GPO n'est pas une livraison garantie des paramètres.

Mode push en détail






Le processus de niveau supérieur d'écriture et d'application des configurations DSC peut être représenté comme suit: À la première étape ( création ), nous décrivons la configuration à l'aide de n'importe quel IDE qui nous convient (Bloc-notes, PowerShell ISE, Visual Studio Code et autres). À la fin, nous compilons les fichiers de configuration mof (le processus de compilation est décrit dans notre article précédent ).

Dans la deuxième étape ( Staging / Compilation ), nous commençons à appliquer la configuration à partir du fichier mof compilé à l'aide de l' applet de commande Start-DSCConfiguration . Dans le processus, le serveur de gestion transmet le fichier .mof du serveur LCM, qui doit appliquer la configuration.
Dans ce cas, il est préférable d'utiliser le commutateur -Verbose. Pour un contrôle complet du processus de configuration:

PS C:\windows\system32> Start-DscConfiguration -Path C:\EnvironmentVariable_Path\ -Wait -Verbose

# C 
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer COMPUTER with user sid
S-1-5-21-SID.

#  
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]
VERBOSE: [COMPUTER]: LCM:  [ Start  Resource ]  [[Environment]CreatePathEnvironmentVariable]

#       (test)
VERBOSE: [COMPUTER]: LCM:  [ Start  Test     ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' does not exist.
VERBOSE: [COMPUTER]: LCM:  [ End    Test     ]  [[Environment]CreatePathEnvironmentVariable]  in 0.1320 seconds.
#      “Environment variable 'TestPathEnvironmentVariable' does not exist”

#       
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' created with value 'TestValue'.
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]  [[Environment]CreatePathEnvironmentVariable]  in 0.0690 seconds.
VERBOSE: [COMPUTER]: LCM:  [ End    Resource ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]    in  2.1900 seconds.
#  

#  
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 2.749 seconds

On peut voir que le moteur a vérifié la présence de la variable, ne l'a pas trouvée et en a créé une nouvelle, selon la configuration spécifiée:



dans la troisième étape ( Exécution ), l'agent DSC LCM entre en jeu. Il reçoit un fichier mof, le vérifie, le place dans un dossier $env:systemRoot/system32/configurationet lance un workflow d'application du fichier de configuration:

  1. LCM reçoit, applique le fichier de configuration. Le fichier est renommé en attente.mof et placé dans$env:systemRoot/system32/configuration
    • Si l'application du fichier de configuration échoue, le fichier pending.mof reste et LCM tentera de l'appliquer au cycle suivant.
  2. Si le fichier current.mof est déjà dans le dossier, il est renommé en previous.mof
  3. Si l'application du fichier de configuration se termine avec succès, LCM le renomme en courant.mof
  4. Le fichier current.mof est copié dans le fichier backup.mof

Graphiquement, le flux de travail peut être représenté comme suit:



Pour gérer différents fichiers de configuration, il existe une applet de commande Remove-DSCConfigurationDocument qui vous permet de supprimer des documents spécifiques si cela est nécessaire pour une raison quelconque. Cependant, rien ne nous empêche de les supprimer manuellement.

Mode Pull en détail


Le mode Pull est plus difficile à déployer et à configurer, mais il simplifie considérablement le processus de gestion des serveurs qui lui sont connectés.

Le schéma général ressemblera à ceci: le



mode Pull nécessite le déploiement d'un serveur Pull. En fait, il s'agit d'un serveur Web classique, qui peut donner aux clients des fichiers mof et des ressources qui peuvent être nécessaires lors de l'application de configurations à partir de fichiers mof. Ce dernier simplifie considérablement le processus de gestion et de configuration des serveurs, car la tâche de fournir les ressources nécessaires incombe au client. Le serveur Pull agit en même temps comme un référentiel \ référentiel de ressources.

Pull-server peut fournir l'accès aux ressources et aux fichiers de configuration via deux protocoles:

  1. SMB. . DFS-R. , , . SMB , Kerberos.
  2. Http\https. . IIS.

L'installation du serveur d'extraction peut être effectuée via les ressources régulières proposées par l'équipe de développement DSC. Plus de détails peuvent être trouvés ici . Ou utilisez des solutions axées sur la communauté: ici ou ici .

Le flux de travail pour les travaux ultérieurs avec le serveur d'extraction est le suivant:

  1. Nous configurons les clients (LCM) pour fonctionner avec un pull-server.
  2. Nous téléchargeons des fichiers de ressources sur le serveur pull.
  3. Nous préparons les fichiers de configuration client (écriture et compilation) et les fichiers avec sommes de contrôle.
  4. Profitez du résultat.

Configuration des clients (LCM) pour fonctionner avec un serveur pull

Pour ce faire, utilisez les paramètres LocalConfigurationManager (v5) suivants :

Bloc de paramètres:

  • CertificateID - indique l'empreinte digitale du certificat pour protéger les connexions / mots de passe transmis dans la configuration.
  • ConfigurationID - contient le GUID du client. Seules les configurations qui contiennent son GUID dans le nom du fichier de configuration seront appliquées au client. Le paramètre est laissé pour la compatibilité avec les anciennes versions du serveur pull. Il est préférable d'utiliser le paramètre RegistrationKey.
  • RefreshMode - pour travailler avec des serveurs Pull, spécifiez Pull dans ce paramètre.

Bloquer la configurationRepositoryWeb:

  • AllowUnsecureConnection - autorise \ n'autorise pas la connexion sans authentification.
  • CertificateID - indique l'empreinte digitale du certificat sur le client, qui sera utilisée dans le processus d'authentification mutuelle avec le serveur.
  • ConfigurationNames - un tableau de noms de configuration qui seront appliqués au client.
  • RegistrationKey - un secret généré sur le serveur, qui est utilisé par le client pour s'inscrire sur le serveur.
  • ServerURL - URL du serveur Pull avec des configurations.

Bloc ResourceRepositoryWeb:

  • AllowUnsecureConnection - autorise \ n'autorise pas la connexion sans authentification.
  • CertificateID - indique l'empreinte digitale du certificat sur le client, qui sera utilisée dans le processus d'authentification mutuelle avec le serveur.
  • RegistrationKey - un secret généré sur le serveur, qui est utilisé par le client pour s'inscrire sur le serveur.
  • ServerURL - URL du serveur Pull avec des ressources.

Bloc ReportServerWeb:

  • AllowUnsecureConnection - autorise \ n'autorise pas la connexion sans authentification.
  • CertificateID - indique l'empreinte digitale du certificat sur le client, qui sera utilisée dans le processus d'authentification mutuelle avec le serveur.
  • RegistrationKey - un secret généré sur le serveur, qui est utilisé par le client pour s'inscrire sur le serveur.
  • ServerURL - URL du serveur Pull avec des rapports.

Téléchargement de fichiers de ressources sur le serveur Pull

Après avoir appliqué les nouveaux paramètres sur LCM, qui lui apprendront à utiliser le serveur Pull, vous pouvez télécharger des fichiers de ressources sur le serveur . Les ressources sont téléchargées sur le serveur sous forme de fichiers zip (le dossier contenant la ressource est compressé en zip). Règle pour nommer un tel fichier:

{ModuleName}_{Version}.zip

L'emplacement de fichier par défaut $env:PROGRAMFILES\WindowsPowerShell\DscService\Modules. Lors de l'installation du serveur Pull, ce dossier peut être redéfini. En plus du fichier avec le dossier de ressources compressé en zip, vous devez également placer le fichier avec la somme de contrôle de cette ressource compressée au même endroit. Par exemple, comme ceci:

New-DscChecksum -Path .\xPSDesiredStateConfiguration_8.4.4.0.zip

Placement des fichiers de configuration client sur le serveur Pull

Il est important de noter ici que nous pouvons utiliser deux modes de fonctionnement client dans ce cas (en fait deux ans et demi): le client recevra la configuration du serveur à l'aide de ConfigurationID , ou le client utilisera le nom de configuration - ConfigurationName . S'il est nécessaire d'appliquer plusieurs configurations, toutes peuvent être spécifiées dans ConfigurationName, mais vous devrez configurer LCM pour fonctionner avec des configurations partielles.

Lors de l'utilisation de ConfigurationID, il faut souligner que le fichier de configuration mof qui sera appliqué au client contiendra un GUID (il est contenu dans ConfigurationID). Dans le cas de l'utilisation de ConfigurationName, le fichier mof contiendra le nom de configuration, que nous spécifierons dans ConfigurationName. Dans les deux cas, en plus du fichier mof, le fichier de contrôle de configuration y sera également placé:

New-DscChecksum -Path '.\' -Force

En conclusion


Nous avons examiné deux façons d'appliquer des modifications au serveur en modes Push et Pull. Nous sommes passés en revue les fonctionnalités d'utilisation et avons essayé d'expliquer toutes les nuances qui peuvent survenir lorsque vous travaillez avec ces modes dans DSC. Si vous avez encore des questions - discutons-en dans les commentaires. Et si vous n'aviez pas assez de visibilité, rendez-vous à notre réunion en ligne le 28 mai: nous analyserons les systèmes de communications unifiées et les installations de communication (configuration du téléchargement des journaux Exchange dans Elastic, Microsoft Endpoint Manager pour gérer iOS, Android et Windows 10) et discutons plus en détail des limites de l'applicabilité Configuration de l'état souhaité de PowerShell. Il vous suffit de vous inscrire .

All Articles