Agents de provisionnement Windows au premier démarrage dans le cloud : EC2Launch v2, Azure VM Agent et cloudbase-init

Ce que c'est

Les fournisseurs de cloud offrent aux nouvelles instances Windows un moyen d'exécuter une configuration à leur premier démarrage. Cette configuration prend la forme d'un bloc de texte (un script ou une configuration structurée) fourni à la création de l'instance et lu par un agent déjà intégré à l'image.

AWS : l'agent EC2Launch v2, que la documentation d'AWS décrit comme un logiciel utilisé « to perform tasks during EC2 Windows instance launch » (pour effectuer des tâches au lancement d'une instance EC2 Windows), exécute les user data de l'instance (scripts PowerShell/batch ou listes de tâches en YAML). C'est l'agent par défaut des AMI AWS Windows Server 2022 et 2025, et AWS publie aussi des AMI 2016/2019 qui l'embarquent ; les anciennes AMI 2016/2019 utilisent EC2Launch v1, et les AMI antérieures à 2016 utilisent EC2Config. Pour les AMI personnalisées, il faut lancer Sysprep via EC2Launch v2 (son outil de paramétrage ou EC2Launch.exe sysprep) afin que l'état propre à l'agent soit réinitialisé en même temps que celui de Windows.

Azure : l'Azure Windows VM Agent (visible dans le Gestionnaire des tâches sous le processus WindowsAzureGuestAgent.exe) exécute les extensions de VM et reste facultatif ; le démarrage n'exige que l'agent de provisionnement, qui est distinct. Sous Windows, les custom data d'Azure sont écrites dans %SystemDrive%\AzureData\CustomData.bin « but it isn't processed » (mais ne sont pas traitées). Elles ne s'exécutent donc que si l'image contient du code qui les lit, ou si l'on utilise à la place la Custom Script Extension. Les user data peuvent être récupérées auprès de l'Instance Metadata Service pendant toute la durée de vie de la VM. Sous Linux, cloud-init traite les custom data par défaut, tandis que le Linux VM Agent (waagent) ne le fait que si Provisioning.ExecuteCustomData est activé dans une image personnalisée.

Autres clouds et clouds privés sur site : de nombreuses images cloud Windows qui ne relèvent ni d'AWS ni d'Azure embarquent plutôt cloudbase-init, un agent open source. Sa documentation décrit un format de user data #cloud-config comme « Cloud-config YAML configuration as supported by cloud-init, excluding Linux specific content » (configuration YAML cloud-config telle que prise en charge par cloud-init, hors contenu propre à Linux), ce qui offre une interface de configuration commune à des plateformes cloud par ailleurs différentes.

Pourquoi c'est important

Lorsqu'une instance Windows démarre sans que la configuration attendue ait été appliquée, le correctif dépend de l'agent présent et de l'endroit où il journalise, car aucun de ces agents ne transforme de façon fiable l'échec d'un script de user data en échec du lancement.

Comment l'appliquer

• Sur AWS : consulter %ProgramData%\Amazon\EC2Launch\log\agent.log pour connaître l'état et les erreurs de l'agent, conformément au guide de dépannage d'EC2Launch v2 d'AWS.
• Sur Azure Windows : vérifier que le processus WindowsAzureGuestAgent.exe est en cours d'exécution, puis consulter les journaux de l'agent et des extensions sous C:\WindowsAzure\Logs (WaAppAgent.log, Plugins\).
• Sur Azure Linux : consulter /var/log/waagent.log (waagent) et, sur les images cloud-init, /var/log/cloud-init.log et cloud-init-output.log.
• Sur les images cloudbase-init : consulter le répertoire de journaux configuré (défini par l'option log_dir dans le fichier de configuration propre à cloudbase-init) pour y repérer les erreurs d'exécution des user data.
• Sur Azure, utiliser les custom data pour une charge traitée une seule fois lors du provisionnement, et les user data lorsqu'elles doivent rester récupérables et modifiables sans recréer l'image de la VM. Les custom data d'une VM donnée ne peuvent pas être modifiées après sa création.

Pièges

• Supposer qu'une image Windows se comporte comme une image Linux avec cloud-init : l'agent, ses chemins de journaux et les formats de user data pris en charge varient selon la plateforme et selon l'agent qu'embarque l'image concernée.
• Interpréter l'absence d'un fichier journal comme « rien n'a été fourni » plutôt que comme « l'agent n'est pas installé ou n'est pas celui que l'on attendait » : il faut déterminer quel agent est présent, le cas échéant, avant de conclure que les user data étaient vides.
• S'attendre à ce qu'une VM Windows sur Azure exécute d'elle-même les custom data, ou considérer un état de provisionnement réussi sous Linux comme la preuve que le script de custom data a fonctionné : Microsoft indique que les erreurs de script ne constituent pas des échecs de provisionnement fatals.