web-dev-qa-db-fra.com

Les scripts de données utilisateur ne s'exécutent pas sur mon AMI personnalisée, mais fonctionnent dans Amazon Linux standard

J'ai cherché beaucoup de sujets sur "le script de données utilisateur ne fonctionne pas" ces derniers jours, mais jusqu'à présent, je n'ai encore aucune idée de mon cas, veuillez m'aider à comprendre ce qui s'est passé, merci beaucoup!

Selon AWS ser-data explication:

Lorsque vous lancez une instance dans Amazon EC2, vous avez la possibilité de transmettre des données utilisateur à l'instance qui peut être utilisée pour effectuer des tâches de configuration automatisées courantes et même exécuter des scripts après le démarrage de l'instance.

J'ai donc essayé de transmettre mes propres données utilisateur lors du lancement de l'instance, voici mes données utilisateur:

\#!/bin/bash

echo 'test' > /home/ec2-user/user-script-output.txt

Mais il n'y a pas de fichier dans ce chemin: /home/ec2-user/user-script-output.txt

J'ai vérifié /var/lib/cloud/instance/user-data.txt, le fichier existe et est identique à mon script de données utilisateur.

J'ai également vérifié le journal /var/log/cloud-init.log, il n'y a pas de message d'erreur.

Mais le script de données utilisateur fonctionne si je lance une nouvelle instance avec Amazon linux (2014.09.01), mais je ne sais pas quelle différence entre mon AMI (basée sur Amazon linux) et Amazon linux.

La seule partie différente que j'ai vue est que si j'exécute ce script:

Sudo yum list installed | grep cloud-init

Mon AMI:

cloud-init.noarch 0.7.2-8.33.amzn1 @ amzn-main

Amazon linux:

cloud-init.noarch 0.7.2-8.33.amzn1 installé

Je ne suis pas sûr que ce soit la raison?

Si vous avez besoin de plus d'informations, je suis heureux de fournir, s'il vous plaît laissez-moi savoir ce qui s'est passé dans ma propre AMI et comment y remédier?

merci beaucoup

Mise à jour

Je viens de trouver une réponse à ce post ,

Si j'ajoute # cloud-boothook en haut du fichier de données utilisateur, cela fonctionne!

#cloud-boothook
#!/bin/bash
echo 'test' > /home/ec2-user/user-script-output.txt

Mais je ne sais toujours pas pourquoi.

linuxamazon-web-servicesamazon-ec2user-data
45
Kai

User_data n'est exécuté qu'au premier démarrage. Comme votre image est une image personnalisée, je suppose qu'elle a déjà été démarrée une fois et donc user_data est désactivée.

Pour les fenêtres, cela peut être fait en cochant une case dans Propriétés des services Ec2 . Je regarde en ce moment comment faire cela 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 le faire fonctionner car il change le script d'un user_data mécanisme à un cloud-boothook celui qui s'exécute à chaque démarrage.

MODIFIER:

Voici le code pour réactiver le démarrage sur Windows à l'aide de 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 les autres ...)

24
Thibault Deheurles

Comme je l'ai testé, il y avait des données bootstrap dans /var/lib/cloud répertoire. Après avoir effacé ce répertoire, le script ser Data a fonctionné normalement.

rm -rf /var/lib/cloud/*
4
jkim

J'ai également rencontré le même problème sur Ubuntu 16.04 hvm AMI. J'ai soulevé le problème au support AWS mais je n'ai toujours pas pu trouver la raison/bogue exact qui l'affecte.

Mais j'ai encore 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 aucun redémarrage.

Si ces choses ne fonctionnent toujours pas, vous pouvez les tester davantage en forçant les données utilisateur à s'exécuter manuellement. Aussi tailf /var/log/cloud-init-output.log pour l'état d'initiation au cloud. Il devrait se terminer par quelque chose comme des modules: final pour faire fonctionner vos données utilisateur. Il ne doit pas rester bloqué sur les modules: config.

Sudo rm -rf /var/lib/cloud/* Sudo cloud-init init Sudo cloud-init modules -m final

Je n'ai pas beaucoup d'idée 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 hic, il exécutera le script à chaque démarrage, ce qui fera fonctionner vos données utilisateur à chaque démarrage, tout comme # cloud-boothook. Pas de soucis, vous pouvez simplement le modifier en supprimant simplement le fichier 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 expliquer pourquoi il est incapable d'exécuter les données utilisateur.

1
Sagar Ghuge

J'avais beaucoup de mal avec ça. Je vais vous fournir une procédure détaillée.

Mon pli supplémentaire est que j'utilise terraform pour instancier les hôtes via une configuration de lancement et un groupe de mise à l'échelle automatique.

Je n'ai PAS pu 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 récupérer à partir des données utilisateur,

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

mais j'ai remarqué que je l'obtenais avec les citations encore dedans.

Voici comment je l'ai fait fonctionner: je suis passé à le retirer d'un modèle à la place, 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 de modèle comme suit:

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

}

Mais j'obtenais toujours une erreur dans les journaux d'initialisation du cloud /var/log/cloud-init.log [AVERTISSEMENT]: données utilisateur non gérées non multiparties (texte/x-non-multipart): 'Content-Type: text/cloud. .. "

Ensuite, j'ai trouvé cet article sur l'utilisateur de la mise en forme des données utilisateur Cela a du sens, si les données utilisateur peuvent être divisées en plusieurs parties, peut-être que cloud-init a besoin de commandes cloud-init à un endroit et du script à 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"
--//
1
jorfus

J'utilise CentOS et la logique des données utilisateur est simple:

  • Dans le fichier /etc/rc.local, il y a un appel pour un script initial.sh, mais il cherche d'abord un drapeau:

    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 à nouveau avant de créer l'image:

touch /var/tmp/initial
1
Pedreiro

ser Data devrait s'exécuter correctement sans utiliser #cloud-boothook (qui est utilisé pour activer les données utilisateur le plus tôt possible pendant le processus de démarrage).

J'ai commencé une nouvelle AMI Amazon Linux et utilisé vos données utilisateur, en 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). La commande échouerait naturellement si vous tentez de créer un fichier dans un répertoire inexistant, mais votre exemple "Update" semble montrer qu'il a réellement fonctionné.

0
John Rotenstein

voici la réponse à titre d'exemple: assurez-vous que vous n'avez dans le titre que #!/bin/bash

#!/bin/bash
yum update -y
yum install httpd mod_ssl
service httpd start
chkconfig httpd on
0
ben othman zied