Qu’est-ce qu’Azure Automation State Configuration ?

10 minutes

Vous pouvez utiliser Azure Automation State Configuration pour vous assurer que les machines virtuelles d’une zone de cluster sont dans un état cohérent, avec le même logiciel installé et les mêmes configurations.

Dans cette unité, vous allez découvrir les fonctionnalités et les fonctionnalités d’Azure Automation, passer en revue le modèle déclaratif de PowerShell Desired State Configuration (DSC) et explorer ses avantages.

Azure Automation State Configuration est un service Azure basé sur PowerShell. Il vous permet de déployer de manière cohérente, de surveiller de manière fiable et de mettre automatiquement à jour l’état souhaité de toutes vos ressources. Azure Automation fournit les outils permettant de définir des configurations et de les appliquer à des machines, qu’elles soient réelles ou virtuelles.

Pourquoi utiliser Azure Automation State Configuration ?

Maintenir manuellement une configuration correcte et cohérente pour les serveurs qui exécutent vos services peut être difficile et sujet aux erreurs. Azure Automation State Configuration utilise le DSC PowerShell pour aider à résoudre ces problèmes. Il gère de manière centralisée vos artefacts DSC et le processus DSC.

Azure Automation State Configuration a un serveur Pull intégré. Vous pouvez cibler des nœuds pour qu’ils reçoivent automatiquement les configurations de ce serveur Pull, conformes à l’état souhaité et qu’ils indiquent leur conformité. Vous pouvez cibler des machines physiques ou virtuelles Windows ou Linux, dans le cloud ou en local.

Vous pouvez utiliser les journaux Azure Monitor pour passer en revue la conformité de vos nœuds en configurant Azure Automation State Configuration pour envoyer ces données.

Qu’est-ce que DSC PowerShell ?

DSC PowerShell est une plateforme de gestion déclarative utilisée par Azure Automation State Configuration pour configurer, déployer et contrôler des systèmes. Un langage de programmation déclaratif sépare l’intention (ce que vous voulez faire) de l’exécution (comment vous voulez le faire). Spécifiez ce que l’état souhaité doit être et laissez DSC faire le travail pour y parvenir. Vous n’avez pas besoin de savoir comment implémenter ou déployer une fonctionnalité quand une ressource DSC est disponible. Au lieu de cela, vous pouvez vous concentrer sur votre structure de déploiement.

Si vous utilisez déjà PowerShell, vous vous demandez peut-être pourquoi vous avez besoin de DSC. Considérez l’exemple suivant.

Quand vous voulez créer un partage sur un serveur Windows, vous pouvez utiliser la commande PowerShell suivante :

# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2

Le script est simple et facile à comprendre. Cependant, si vous utilisez ce script en production, vous allez rencontrer plusieurs problèmes. Pensez à ce qui peut se produire si le script est exécuté plusieurs fois ou si User2 a déjà un accès total plutôt qu’un accès en lecture seule.

Cette approche n’est pas idempotente. L’idempotence décrit une opération qui a le même effet, que vous l’exécutiez 1 fois ou 10 001 fois. Pour atteindre ce résultat dans PowerShell, vous devez ajouter de la logique et une gestion des erreurs. Si le partage de fichiers n’existe pas, créez-le. Si le partage existe, il n’est pas nécessaire de le créer. Si User2 existe mais n’a pas d’accès en lecture, vous ajoutez l’accès en lecture.

Votre script PowerShell ressemblerait à ceci :

$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
    Write-Verbose -Message "Share with name $Name exists"
    $shareExists = $true
}

if ($shareExists -eq $false)
{
    Write-Verbose "Creating share $Name to ensure it is Present"
    New-SmbShare @psboundparameters
}
else
{
    # Need to call either Set-SmbShare or *ShareAccess cmdlets
    if ($psboundparameters.ContainsKey("ChangeAccess"))
    {
       #...etc., etc., etc
    }
}

Les autres cas spéciaux que vous n’avez pas pris en compte peuvent être considérés comme maigres lorsque des problèmes surviennent. DSC gère automatiquement les cas inattendus. Avec DSC, vous décrivez le résultat final au lieu du processus à effectuer pour obtenir ce résultat.

L’extrait de code DSC suivant affiche un exemple :

Configuration Create_Share
{
   Import-DscResource -Module xSmbShare
   # A node describes the VM to be configured

   Node $NodeName
   {
      # A node definition contains one or more resource blocks
      # A resource block describes the resource to be configured on the node
      xSmbShare MySMBShare
      {
          Ensure      = "Present"
          Name        = "MyFileShare"
          Path        = "C:\Shared"
          ReadAccess  = "User1"
          FullAccess  = "User2"
          Description = "This is an updated description for this share"
      }
   }
}

L’exemple précédent utilise le module xSmbShare , qui indique à DSC comment vérifier l’état d’un partage de fichiers. Le kit de ressources DSC compte actuellement plus de 100 modules de ressources, notamment un pour l’installation d’un site IIS. Un lien vers le kit de ressources DSC est disponible dans le récapitulatif à la fin de ce module.

Vous en saurez plus sur la structure du code DSC PowerShell dans l’unité suivante.

Qu’est-ce que le Gestionnaire de configuration locale ?

Le Gestionnaire de configuration local est un composant de Windows Management Framework (WMF) sur un système d’exploitation Windows. Le Gestionnaire de configuration local est responsable de la mise à jour de l’état d’un nœud, comme une machine virtuelle, pour le faire correspondre à l’état souhaité. Chaque fois que le Gestionnaire de configuration local s’exécute, il effectue les étapes suivantes :

Obtenir : obtient l’état actuel du nœud.
Tester : compare l’état actuel d’un nœud à l’état souhaité en utilisant un script DSC compilé (fichier .mof).
Définir : met à jour le nœud pour qu’il corresponde à l’état souhaité décrit dans le fichier .mof.

Vous configurez le Gestionnaire de configuration local quand vous inscrivez une machine virtuelle auprès d’Azure Automation.

Architectures Envoi (push) et Tirage (pull) dans DSC

Le Gestionnaire de configuration local sur chaque nœud peut fonctionner en deux modes.

Mode push : Un administrateur envoie manuellement ou pousse (push) les configurations vers un ou plusieurs nœuds. Le Gestionnaire de configuration local s’assure que l’état de chaque nœud correspond à ce qui est spécifié par la configuration.
Mode Tirage (pull) : un serveur Pull contient les informations de configuration. Le Gestionnaire de configuration local sur chaque nœud interroge le serveur Pull à intervalles réguliers, par défaut toutes les 15 minutes, pour obtenir les informations de configuration les plus récentes. Ces requêtes constituent l’étape 1 dans le diagramme ci-dessous. À l’étape 2, le serveur Pull renvoie les détails de toutes les modifications de la configuration à chaque nœud.

Quand vous utilisez cette approche, chaque nœud doit être inscrit auprès du service Tirage (pull).

Les deux modes présentent des avantages :

Le mode Envoi (push) est facile à configurer. Il n’a pas besoin de sa propre infrastructure dédiée et peut s’exécuter sur un ordinateur portable. Le mode Envoi (push) est utile pour tester les fonctionnalités de DSC. Vous pouvez également utiliser le mode Envoi (push) pour obtenir une machine nouvellement mise en image avec l’état souhaité pour la base de référence.
Le mode Tirage (pull) est pratique quand vous avez un déploiement d’entreprise qui s’étend sur un grand nombre de machines. Le Gestionnaire de configuration local interroge régulièrement le serveur Pull et vérifie que les nœuds sont dans l’état souhaité. Si un outil ou une équipe externe applique des correctifs logiciels qui aboutissent à des écarts de la configuration sur des machines individuelles, ces machines sont rapidement annulées en ligne et la configuration est rétablie à celle que vous avez définie. Ce processus vous permet d’obtenir un état de conformité continue pour vos obligations réglementaires et de sécurité.

Plateformes et systèmes d’exploitation pris en charge

Azure Automation DSC est pris en charge par le cloud Azure et d’autres fournisseurs cloud, par votre infrastructure locale ou par une combinaison hybride couvrant tous ces environnements.

Azure Automation DSC prend en charge les systèmes d’exploitation suivants :

Windows
- Server 2022
- Server 2019
- Server 2016
- Server 2012 R2
- Server 2012
- Server 2008 R2 SP1
- 11
- 10
- 8.1
- 7
Linux
- L’extension Linux DSC prend en charge toutes les distributions Linux listées dans la documentation DSC PowerShell.

DSC PowerShell est installé sur toutes les machines Linux prises en charge par Azure Automation DSC.

Exigences de DSC pour Windows

Pour les machines Windows, l’extension de machine virtuelle Azure Desired State Configuration (DSC) utilise WMF pour gérer les versions de fonctionnalités Windows telles que Windows PowerShell DSC et Windows Remote Management (WinRM). Azure DSC prend en charge WMF 4.0 et versions ultérieures. Les machines Windows doivent donc exécuter Windows Server 2008 R2 SP1, Windows 7 ou version ultérieure.

La première fois que l’extension Azure DSC est appelée, elle installe une version de WMF compatible avec le système d’exploitation sur toutes les versions de Windows, à l’exception de Windows Server 2016 ou version ultérieure. La dernière version de WMF est déjà installée sur Windows Server 2016 et ses versions ultérieures. Une fois WMF installé, la machine doit être redémarrée.

WinRM est activé sur les nœuds de machines qui exécutent Windows Server 2012 ou ultérieur et Windows 7 ou ultérieur.

La prise en charge du proxy pour l’agent DSC est disponible dans les builds 1809 et ultérieures de Windows. La prise en charge du proxy n’est pas disponible dans DSC pour les versions antérieures de Windows.

Autres exigences de DSC

Si vos nœuds se trouvent sur un réseau privé, le port et les URL suivants sont nécessaires pour que DSC communique avec Automation :

Port : seul le port TCP 443 est nécessaire pour l’accès Internet sortant.
URL globale : *.azure-automation.net
URL globale de US Gov Virginia : *.azure-automation.us
Service de l’agent : https://<workspaceId>.agentsvc.azure-automation.net

Contrôler vos connaissances

Qu’est-ce qu’Azure Automation State Configuration ?

Une plateforme de gestion déclarative permettant de configurer, de déployer et de contrôler des systèmes.

Un service utilisé pour écrire, gérer et compiler des configurations PowerShell Desired State Configuration (DSC), pour importer des ressources DSC et pour affecter des configurations à des nœuds cibles.

Un service qui gère la configuration d’état sur chaque destination ou chaque nœud.

Un script DCS PowerShell ______________.

Contient les étapes nécessaires pour configurer une machine virtuelle et la placer dans un état spécifié.

Est idempotent.

Décrit l’état souhaité.

Pourquoi utiliser le mode Tirage (pull) au lieu du mode Envoi (push) pour DSC ?

Le mode Tirage (pull) est idéal pour les environnements complexes nécessitant une redondance et une mise à l’échelle.

Le mode Tirage (pull) est facile à configurer et n’a pas besoin de sa propre infrastructure dédiée.

Le mode Tirage (pull) utilise le Gestionnaire de configuration local (LCM) pour garantir que l’état de chaque nœud correspond à celui spécifié par la configuration.

Vous devez répondre à toutes les questions avant de vérifier votre travail.

Qu’est-ce qu’Azure Automation State Configuration ?

Pourquoi utiliser Azure Automation State Configuration ?

Qu’est-ce que DSC PowerShell ?

Qu’est-ce que le Gestionnaire de configuration locale ?

Architectures Envoi (push) et Tirage (pull) dans DSC

Plateformes et systèmes d’exploitation pris en charge

Exigences de DSC pour Windows

Autres exigences de DSC

Contrôler vos connaissances

Commentaires