Les scripts de données utilisateur ne sont pas exécutés sur mon AMI personnalisée, mais fonctionnent dans Amazon linux standard

User_data est exécuté uniquement au premier démarrage. Comme votre image est personnalisée, je suppose qu’elle a déjà été lancée une fois et que user_data est désactivé.

Pour Windows, cela peut être fait en cochant une case dans les propriétés des services Ec2 . Je regarde le moment de le faire de manière automatisée à la fin de la création d’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 fait fonctionner car il change le script d’un mécanisme user_data à un cloud-boothook qui s’exécute à chaque démarrage.

MODIFIER :

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 cela pourrait aider les autres …)

Comme je l’ai testé, il y avait des données de démarrage dans le répertoire /var/lib/cloud . Après avoir effacé ce répertoire, le script User Data fonctionnait normalement.

 rm -rf /var/lib/cloud/* 

Les données utilisateur doivent s’exécuter #cloud-boothook sans utiliser #cloud-boothook (utilisé pour activer les données utilisateur le plus tôt possible pendant le processus de démarrage).

J’ai démarré une nouvelle AMI Amazon Linux et utilisé vos données utilisateur, plus un peu plus:

 #!/bin/bash echo 'bar' > /tmp/bar echo 'test' > /home/ec2-user/user-script-output.txt echo 'foo' > /tmp/foo 

Cela a réussi à créer trois fichiers.

Les scripts de données utilisateur sont exécutés en tant que root , il doit donc être autorisé à créer des fichiers dans n’importe quel emplacement.

Je remarque que dans votre code fourni, un exemple fait référence à /home/ec2-user/user-script/output.txt (avec un sous-répertoire) et un exemple fait référence à /home/ec2-user/user-script-output.txt (pas de sous-répertoire). Il est compréhensible que la commande échoue si vous tentez de créer un fichier dans un répertoire inexistant, mais votre exemple de «mise à jour» semble montrer qu’il a bien fonctionné.

J’utilise CentOS et la logique pour userdata est simple:

• Dans le fichier /etc/rc.local, il y a un appel pour un script initial.sh, mais il recherche d’abord un indicateur:

   if [ -f /var/tmp/initial ]; then /var/tmp/initial.sh & fi 

initial.sh est le fichier qui exécute les données utilisateur, mais à la fin, il supprime l’indicateur. Donc, si vous voulez que votre nouvelle AMI exécute à nouveau les données utilisateur, créez simplement le drapeau avant de créer l’image:

 touch /var/tmp/initial 

J’ai également rencontré le même problème sur Ubuntu 16.04 hvm AMI. J’ai soulevé le problème sur le support AWS mais je ne pouvais toujours pas trouver 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-le sur sans redémarrage.

Si cela ne fonctionne 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 le statut cloud-init. Il devrait se terminer par quelque chose comme des modules: final pour exécuter vos données utilisateur. Il ne faut pas coller sur les 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 a été exécuté pendant le démarrage du système.

J’ai ajouté la ligne ci-dessous dans /etc/rc.local pour y arriver.

sudo bash /home/ubuntu/force-user-data.sh || exit 1

Mais voici le problème, il exécutera le script à chaque démarrage, ce qui rendra vos données utilisateur exécutables sur chaque démarrage, comme # cloud-boothook. Pas de soucis, vous pouvez simplement le modifier en supprimant simplement la force-user-data.sh elle-même à la fin. Donc, votre force-user-data.sh ressemblera à quelque chose

#!/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 expliquer pourquoi il est impossible d’exécuter les données d’utilisateur.

J’avais beaucoup de problèmes avec ça. Je vais fournir des détails détaillés.

Ma ride supplémentaire est que j’utilise terraform pour instancier les hôtes via un groupe de configuration de lancement et de mise à l’échelle automatique.

Je ne pouvais pas le faire fonctionner en ajoutant le script en ligne dans lc.tf

 user_data = DATA << " #cloud-boothook #!/bin/bash echo 'some crap'\' " DATA 

Je pourrais le chercher des données d'utilisateur,

 wget http://169.254.169.254/latest/user-data 

mais j'ai remarqué que je l'avais avec les citations encore dans.

C'est comme ça que j'ai réussi à le faire: j'ai plutôt choisi de le retirer d'un modèle car ce que vous voyez est ce que vous obtenez.

 user_data = "${data.template_file.bootscript.rendered}" 

Cela signifie que je dois également déclarer mon fichier modèle comme suit:

 data "template_file" "bootscript" { template = "${file("bootscript.tpl")}" } 

Mais je recevais toujours une erreur dans les journaux d'initialisation de cloud /var/log/cloud-init.log [AVERTISSEMENT]: non-multi-parties non gérées (text / x-pas-multipart) userdata: 'Content-Type: text / cloud. .. '

Ensuite, j'ai trouvé cet article sur l'utilisateur du formatage des données utilisateur . Si les données utilisateur peuvent se présenter en plusieurs parties, il est possible que cloud-init ait besoin de commandes cloud-init à un endroit et le script dans l'autre.

Donc mon bootscript.tpl ressemble à ceci:

 Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 --// Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cloud-config.txt" #cloud-config cloud_final_modules: - [scripts-user, always] --// Content-Type: text/x-shellscript; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="userdata.txt" #!/bin/bash echo "some crap" --//