Le service Azure Machine Configuration (anciennement connu sous le nom de Guest Configuration) est une fonctionnalité qui parait encore méconnue ou boudée au profit d’autres mécanismes comme Ansible. Elle est pourtant la digne descendante du vénérable  PowerShell DSC (Desired State Configuration). et de ses implémentations Azure (extension DSC et Azure Automation DSC, dont la dépréciation a été annoncée pour 2027) : elle permet d’auditer et de configurer l’intérieur de vos machines virtuelles (paramètres de l’OS, registres, applications) à l’aide de packages constitués de modules et de configurations DSC classiques accessibles en HTTPS (souvent via un storage account).

A la différence des méthodes précédentes, Machine Configuration n’utilise pas le Local Configuration Manager (LCM) natif de Windows mais plutôt une extension Azure dédiée qui se charge de la récupération des packages, de l’application des configurations qu’ils contiennent et de la remontée des informations d’audit. Machine Configuration permet également d’appliquer plusieurs configurations (assignments) à une machine, alors que les méthodes traditionnelles ne pouvaient prendre en compte qu’une seule.

Un défaut historique de DSC réside dans ses configurations qui sont des fichiers .mof statiques, obtenus après « compilation » d’un script Powershell DSC. Il était donc nécessaire de créer un fichier .mof pour chaque serveur, au lieu de pouvoir simplement utiliser une configuration générique et lui passer les paramètres propres à chaque serveur.

Mais réjouissez-vous : c’est de l’histoire ancienne! Même si Machine Configuration repose toujours sur des packages contenant des .mof compilés et donc des valeurs statiques, il introduit la possibilité de les modifier directement via la propriété configurationParameter de la ressource guestConfigurationAssignments. Autrement dit, il est possible de créer des .mof contenant les ressources nécessaires à la configuration d’un role sur vos serveurs (par exemple IIS) avec une série de paramètres standardisés, mais avec des valeurs fictives; puis de modifier ces valeurs à la volée dans vos templates ARM en fonction du serveur auxquels vous appliquez les guestConfigurationAssignments!

Concrètement, comment cela fonctionne-t-il ? Lors de l’assignation de la configuration via l’API Azure (par exemple lors du déploiement de votre template ARM), le service transmet vos paramètres à l’agent local (l’extension Azure présente sur la VM). Ce dernier va alors lire le fichier MOF téléchargé et écraser littéralement les valeurs textuelles statiques avec celles que vous avez fournies, juste avant l’application de l’état désiré. Vous n’avez plus besoin d’exécuter la moindre commande à l’intérieur de la machine ou de regénérer un package par environnement. Un seul package IIS.zip compilé une bonne fois pour toutes suffit désormais pour tous vos serveurs !

Pour bien visualiser, voici à quoi ressemblerait le code source de cette configuration DSC générique (avant sa compilation en fichier .mof). On y installe le rôle IIS natif, et on y configure un site web basique à l’aide du module WebAdministrationDsc. Remarquez comment les valeurs utilisées sont fictives (placeholders) et n’ont pas vocation à rester telles quelles en production :

Configuration IIS {
    # Import des ressources natives et du module IIS
    Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
    Import-DscResource -ModuleName 'WebAdministrationDsc'

    Node localhost {
        # 1. Installation du rôle IIS
        WindowsFeature InstallIIS {
            Ensure = "Present"
            Name   = "Web-Server"
        }

        # 2. Création et paramétrage du site web (avec des valeurs fictives)
        WebSite MyCompanySite {
            Ensure       = "Present"
            Name         = "MySite"
            State        = "Started"
            PhysicalPath = "C:\inetpub\wwwroot\dummy" # Valeur statique destinée à être écrasée
            DependsOn    = "[WindowsFeature]InstallIIS"
        }
    }
}

Pour modifier une de ces valeurs (par exemple PhysicalPath) ou même le statut du site (State) à la volée dans vos templates ARM, il faut utiliser le paramètre configurationParameter de votre ressource  Microsoft.Compute/virtualMachines/providers/guestConfigurationAssignments. Attention, la syntaxe n’est pas très intuitive : la clé name du paramètre doit cibler précisément la ressource DSC et sa propriété selon le modèle suivant : [ClasseDeLaRessource]NomDeLaRessource;NomDeLaPropriete.

En reprenant le code DSC ci-dessus (la ressource nommée MyCompanySite de classe WebSite), pour définir le véritable chemin d’accès aux fichiers du site pour un serveur spécifique de production, la définition dans le template ARM inclura ce bloc JSON :

"properties": {
  "guestConfiguration": {
    "name": "IIS",
    "assignmentType": "ApplyAndMonitor",
    "configurationParameter":[
      {
        "name": "[WebSite]MyCompanySite;PhysicalPath",
        "value": "D:\ProductionWeb\MySite"
      }
    ]
  }
}

Attention cependant : tous les paramètres passés à Machine Configuration doivent être de type string. L’API Azure ne supporte pas le passage de tableaux (arrays) via la propriété configurationParameter et ce, même si la ressource DSC sous-jacente est techniquement capable de les interpréter (comme c’est le cas avec la propriété BindingInfo du module WebAdministrationDsc par exemple).

Si ce mécanisme vous semble familier, c’est normal : c’est en effet exactement le même qui se cache derrière les « Azure Security Baselines » déployées via Azure Policy. Lorsque vous configurez une policy Azure pour imposer des paramètres d’OS à votre parc, le service se contente d’orchestrer la création de ces assignations en injectant dynamiquement vos valeurs dans les fichiers MOF pré-packagés par Microsoft.

Le même résultat est bien sûr atteignable à l’aide de Terraform, mais cela sera l’objet du prochain article!