User_data n'est exécuté qu'au premier démarrage. Comme votre image est personnalisée, je suppose qu'elle a déjà été démarrée une fois et que user_data est donc désactivé.
Pour Windows, cela peut être fait en cochant une case dans les propriétés des services Ec2. Je regarde en ce moment comment faire ça de manière automatisée à la fin de la création de l'image personnalisée.
Pour Linux, je suppose que le mécanisme est le même et que user_data doit être réactivé sur votre image personnalisée.
Le #cloud-boothook le faire fonctionner car il change le script d'un user_data mécanisme à un cloud-boothook qui s'exécute à chaque démarrage.
MODIF :
Voici le code pour réactiver le démarrage sur windows en utilisant powershell :
$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\Config.xml"
[xml] $xdoc = get-content $configFile
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2HandleUserData"} |%{ $_.State = "Enabled" }
$xdoc.SelectNodes("//Plugin") |?{ $_.Name -eq "Ec2SetComputerName"} |%{ $_.State = "Enabled" }
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile
$configFile = "C:\\Program Files\\Amazon\\Ec2ConfigService\\Settings\\BundleConfig.xml"
[xml] $xdoc = get-content $configFile
$xdoc.SelectNodes("//Property") |?{ $_.Name -eq "AutoSysprep"} |%{ $_.Value = "Yes" }
$xdoc.OuterXml | Out-File -Encoding UTF8 $configFile
(Je connais la question focus linux, mais ça pourrait aider d'autres...)
Lors de mes tests, il y avait des données d'amorçage dans /var/lib/cloud répertoire.Après avoir effacé ce répertoire, Données utilisateur le script a fonctionné normalement.
rm -rf /var/lib/cloud/*
J'ai également rencontré le même problème sur Ubuntu 16.04 hvm AMI. J'ai signalé le problème au support AWS, mais je n'ai toujours pas trouvé la raison/le bogue exact qui l'affecte.
Mais j'ai quand même quelque chose qui pourrait vous aider.
Avant de prendre AMI, supprimez le répertoire /var/lib/cloud (à chaque fois). Ensuite, lors de la création de l'image, définissez-la sur no-reboot.
Si ces choses ne fonctionnent toujours pas, vous pouvez le tester davantage en forçant les données utilisateur à s'exécuter manuellement. Aussi tailf /var/log/cloud-init-output.log pour l'état cloud-init. Il devrait se terminer par quelque chose comme modules:final pour faire fonctionner vos données utilisateur. Il ne doit pas rester bloqué sur modules:config.
sudo rm -rf /var/lib/cloud/*
sudo cloud-init init
sudo cloud-init modules -m final
Je ne sais pas trop si les commandes ci-dessus fonctionneront sur CentOS ou non. Je l'ai testé sur Ubuntu.
Dans mon cas, j'ai également essayé de supprimer le répertoire /var/lib/cloud, mais il n'a toujours pas réussi à exécuter les données utilisateur dans notre scénario. Mais j'ai trouvé une solution différente pour cela. Ce que nous avons fait, c'est que nous avons créé un script avec les commandes ci-dessus et que ce script s'exécute pendant le démarrage du système.
J'ai ajouté la ligne ci-dessous dans /etc/rc.local pour que cela se produise.
sudo bash /home/ubuntu/force-user-data.sh || exit 1
Mais voici le hic, il exécutera le script à chaque démarrage, ce qui fera que vos données utilisateur s'exécuteront à chaque démarrage, tout comme #cloud-boothook. Pas de soucis, vous pouvez simplement le modifier en supprimant simplement force-user-data.sh lui-même à la fin. Ainsi, votre force-user-data.sh ressemblera à quelque chose comme
#!/bin/bash
sudo rm -rf /var/lib/cloud/*
sudo cloud-init init
sudo cloud-init modules -m final
sudo rm -f /home/ubuntu/force-user-data.sh
exit 0
J'apprécierai si quelqu'un peut éclairer la raison pour laquelle il est incapable d'exécuter les données utilisateur.