Résoudre les problèmes d’approvisionnement des machines virtuelles avec cloud-init

S’applique à : ✔️ Machines virtuelles Linux ✔️ Ensembles de mise à l'échelle flexibles

Si vous créez des images personnalisées généralisées et utilisez cloud-init pour l’approvisionnement, la machine virtuelle risque de ne pas générer correctement. Dans ce cas, examinez l'image pour identifier le problème.

Voici quelques exemples de problèmes d’approvisionnement :

• L’API Fournisseur de ressources de calcul retourne une erreur et cloud-init signale l’échec résultant.
• La machine virtuelle est bloquée lors de la « création » pendant 40 minutes, et la création de la machine virtuelle est marquée comme ayant échoué.
• Les données personnalisées ou les données utilisateur ne sont pas traitées.
• Le disque éphémère ne parvient pas à être monté (pour les machines virtuelles de type SKU fournies avec des disques SCSI de ressources).
• Les utilisateurs ne sont pas créés ou rencontrent des problèmes d’accès utilisateur.
• La mise en réseau n’est pas configurée correctement.
• Échecs de fichier ou de partition d’échange.

Cet article vous explique les procédures pour résoudre des problèmes avec cloud-init. Pour plus d’informations, consultez Formation approfondie sur cloud-init.

Résolution des échecs signalés par cloud-init et enregistrés en tant qu’erreur

Cloud-init émet des erreurs structurées lors du signalement d’un échec à Azure lors de l’approvisionnement. Ces messages d’erreur incluent une raison et des données de prise en charge (telles que l’horodatage, l’identificateur de machine virtuelle, l’URL de documentation, etc.) pour vous aider à examiner l’échec.

Pour obtenir de l’aide sur l’activation et la vérification des diagnostics de démarrage, consultez Diagnostics de démarrage.

Si l’un de ces problèmes persiste lors des tentatives suivantes d’approvisionnement, il est dû à une mauvaise configuration dans l’image. S’il existe une raison de croire qu’il existe un problème cloud-init, signalez-le au suivi des problèmes GitHub cloud-init.

Résolution des autres échecs non signalés par cloud-init

En fonction de l’échec, tenez compte de ces étapes.

Étape 1 : Tester le déploiement sans customData

Cloud-init peut accepter customData qui lui est transmis lors de la création de la machine virtuelle. Tout d’abord, vous devez vous assurer que cette configuration n’entraîne aucun problème avec les déploiements. Voici quelques problèmes courants :

• Le YAML est mal formé
• Les scripts à l’intérieur de customData échouent ou se bloquent
• Outrepasser un paramètre dont dépend cloud-init (par exemple, la configuration des disques ou le réseau)
• Les données contiennent des caractères ou des problèmes d’encodage non pris en charge Essayez de provisionner la machine virtuelle sans passer de configuration. Si la machine virtuelle ne parvient pas à provisionner, suivez les étapes de résolution des problèmes recommandées. Si la configuration n’est pas appliquée, reportez-vous à l’étape 4.

Étape 2 : Vérifier les exigences des images

La cause principale de l’échec de l’approvisionnement de la machine virtuelle est que l’image du système d’exploitation ne satisfait pas les conditions préalables à l’exécution sur Azure. Assurez-vous que vos images sont correctement préparées avant d’essayer de les configurer dans Azure.

Les articles ci-après expliquent comment préparer les diverses distributions Linux prises en charge sur Azure :

• Distributions CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES et openSUSE
• Ubuntu
• Autres - Distributions non approuvées

Pour les images Azure cloud-init prises en charge, les distributions Linux disposent déjà de tous les packages et configurations nécessaires pour approvisionner correctement l’image dans Azure. Si vous constatez que la création de votre machine virtuelle échoue à partir de votre propre image, essayez une image de la Place de marché Azure prise en charge qui est déjà configurée pour cloud-init, avec votre customData facultatif. Si le customData fonctionne correctement avec une image de la Place de marché Azure, il y a probablement un problème avec votre image organisée.

Étape 3 : Collecter et passer en revue les journaux des machines virtuelles

Lorsque la machine virtuelle ne parvient pas à provisionner, Azure affiche l’état « création », pendant 20 minutes, puis redémarrez la machine virtuelle, puis attendez 20 minutes avant de marquer enfin le déploiement de la machine virtuelle comme ayant échoué, avant de le marquer avec une OSProvisioningTimedOut erreur.

Pendant l’exécution de la machine virtuelle, vous avez besoin des journaux d’activité de la machine virtuelle pour comprendre pourquoi l’approvisionnement a échoué. Pour comprendre pourquoi l’approvisionnement de machine virtuelle a échoué, n’arrêtez pas la machine virtuelle. Laissez la machine virtuelle en cours d’exécution. Vous devez conserver l’état d’exécution de la machine virtuelle qui a échoué afin de collecter les journaux. Pour collecter les journaux, utilisez l’une des méthodes suivantes :

• Activez les diagnostics de démarrage avant de créer la machine virtuelle, puis les afficher au cours du démarrage.

• Console série

• Exécutez AZ VM Repair pour attacher et monter le disque du système d’exploitation (lvm, no lvm), ce qui vous permettra de collecter et d’examiner ces journaux :

  /rescue/var/log/waagent*
  /rescue/var/log/syslog*
  /rescue/var/log/rsyslog*
  /rescue/var/log/messages*
  /rescue/var/log/kern*
  /rescue/var/log/dmesg*
  /rescue/var/log/boot*
  /rescue/ /var/log/cloud-init.log
  /rescue//var/log/cloud-init-output.log
  

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Journaux de série/démarrage

Dans tous les logs, commencez à rechercher « Failed », « WARNING », « WARN », « err », « error » et « ERROR ». Il est recommandé de configurer pour ignorer la sensibilité à la casse lors des recherches.

Vous pouvez en alternative utiliser la commande cloud‑init collect‑logs pour collecter tous les journaux nécessaires. Les dernières versions cloud-init d’Azure (≥ 18.2) incluent la commande collect-logs, qui :

Collecte les journaux essentiels : /var/log/cloud-init*.log, métadonnées d’instance, informations système.

Emballe tout dans une archive horodatée au format .tar.gz.

Enregistre l’archive localement (par exemple, /tmp/cloud-init-logs-timestamp.tar.gz).

Analyse des logs

Voici plus de détails sur ce qu'il faut rechercher dans chaque journal cloud-init.

/var/log/cloud-init.log

Par défaut, tous les événements cloud-init avec une priorité de débogage ou plus sont écrits dans /var/log/cloud-init.log. Ce journal fournit des logs détaillés de chaque événement survenu lors de l’initiation de cloud-init.

Par exemple:

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

Lorsque vous trouvez une erreur ou un avertissement, lisez vers l’arrière dans le journal cloud-init pour comprendre ce que cloud-init a tenté avant d’atteindre l’erreur ou l’avertissement. Dans de nombreux cas, cloud-init exécute des commandes de système d’exploitation ou effectue des étapes d’approvisionnement avant que l’erreur se produise. Ces actions peuvent expliquer pourquoi l'erreur apparaît dans les journaux de bord. L’exemple suivant montre que cloud-init a tenté de monter un appareil juste avant de rencontrer le problème.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Si vous avez accès à la Console série , vous pouvez réexécutez la commande que cloud-init essayait d’exécuter.

La journalisation de /var/log/cloud-init.log peut également être reconfigurée dans /etc/cloud/cloud.cfg.d/05_logging.cfg. Pour plus d’informations sur la journalisation cloud-init, consultez la documentation cloud-init.

/var/log/cloud-init-output.log

Vous pouvez récupérer des informations à partir de stdout et stderr au cours des différentes étapes de cloud-init. Ces données impliquent normalement des informations de table de routage, des informations réseau, des informations de vérification de clé hôte ssh, stdout, et stderr pour chaque étape de cloud-init, ainsi que les horodatages. Si vous le souhaitez, la journalisation de stderr et stdout peut être reconfigurée à partir de /etc/cloud/cloud.cfg.d/05_logging.cfg.

Journaux de démarrage/série

Cloud-init a plusieurs dépendances. Ces dépendances sont documentées dans les conditions préalables requises pour les images sur Azure, telles que la mise en réseau, le stockage, la possibilité de monter un ISO et de monter et de mettre en forme le disque temporaire. L’une de ces dépendances peut générer des erreurs et provoquer l’échec de cloud-init. Par exemple, si la machine virtuelle ne peut pas obtenir un bail DHCP, cloud-init échoue.

Si vous ne pouvez toujours pas isoler la raison pour laquelle cloud-init n’a pas pu être approvisionné, vous devez comprendre les étapes cloud-init et quand les modules s’exécutent. Pour plus d’informations, consultez Exploration approfondie de cloud-init.

Étape 4 : Rechercher la raison pour laquelle la configuration n’est pas appliquée

Toutes les défaillances dans cloud-init entraînent un échec d’approvisionnement irrécupérable. Par exemple, si vous utilisez le runcmd module dans une configuration cloud-init, un code de sortie différent de zéro de la commande entraîne l’échec du provisionnement de machine virtuelle. Ce comportement se produit parce que le module s’exécute après les étapes d’approvisionnement principales dans les trois premières étapes de cloud-init. Pour résoudre les problèmes de configuration qui ne s’appliquaient pas, passez en revue manuellement les journaux d’activité de l’étape 3 et les modules cloud-init. Par exemple:

• runcmd : les scripts s’exécutent-ils sans erreur ? Pour vous assurer qu’ils s’exécutent comme prévu, exécutez la configuration manuellement à partir du terminal.
• Installation de packages : la machine virtuelle a-t-elle accès aux référentiels de packages ?
• Vérifiez la customData configuration fournie à la machine virtuelle. Le fichier se trouve dans /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Étapes suivantes

Si cloud-init ignore la configuration, examinez chaque étape cloud-init et le minutage de l’exécution du module pour identifier la cause. Pour plus d’informations, consultez Plongée plus en détail dans la configuration cloud-init.