Скрипты пользовательских данных не работают на моем обычном AMI, но работают в стандартном Amazon linux

Question

Я искал много тем о «скрипте пользовательских данных не работает» за эти несколько дней, но до сих пор у меня нет узнал о моем случае, пожалуйста, помогите мне разобраться в том, что произошло, спасибо большое!

Согласно AWS User-data объяснение:

При запуске экземпляра в Amazon EC2, у вас есть возможность передачи данных пользователя к экземпляру, который может быть использован для выполнения общих автоматизированных задач конфигурации и даже запуск сценариев после запуска экземпляра.

Так что я пытался передать свои собственные пользовательские данные при запуске экземпляра, это мой пользователем данные:

#/бен/Баше

Echo 'теста'>/дома! /ec2-user/user-script-output.txt

Но нет ни одного файла на этом пути: /home/ec2-user/user-script-output.txt

Я проверил /var/lib/cloud/instance/user-data.txt, файл существует и такой же, как и мой скрипт пользовательских данных.

Также я проверил журнал в /var/log/cloud-init.log, нет сообщения об ошибке.

Но скрипт пользовательских данных работает, если я запускаю новый экземпляр с помощью Amazon linux (2014.09.01), но я не уверен, какая разница между моим AMI (на основе Amazon linux) и Amazon linux.

Единственная другая часть я видел, если я запускаю этот скрипт:

SUDO ня список установлен | Grep облако INIT

Мои AMI:

облако init.noarch 0.7.2-8.33.amzn1 @ AMZN магистральный

Amazon Linux:

cloud-init.noarch 0.7.2-8.33.amzn1 установлен

Я не уверен, что это причина?

Если вам нужна дополнительная информация, я рад предоставить, пожалуйста, сообщите мне, что произошло в моем собственном ОИМ и как это исправить?

большое спасибо

Update

Просто нашел ответ от этого post,

Если добавить # облако-boothook в верхней части файла данных пользователя, это работает!

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

Но все еще не уверен, почему.

Answer 1

Данные пользователя должны выполняться штрафом без использования #cloud-boothook (который используется для активации пользовательских данных как можно скорее во время процесса загрузки).

Я начал новый Amazon Linux AMI и использовал свой пользовательские данные, плюс немного дополнительный:

#!/bin/bash 

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

это успешно создано три файла.

Сценарии пользовательских данных выполнены как root, поэтому у него должно быть разрешение на создание файлов в любом месте.

Я заметил, что в вашем прилагаемом коде один пример относится к /home/ec2-user/user-script/output.txt (с поддиректорией), а один пример относится к /home/ec2-user/user-script-output.txt (без подкаталога). Команда будет понятна сбой, если вы попытаетесь создать файл в несуществующем каталоге, но ваш пример «обновления», похоже, показывает, что он действительно работает.

Answer 2

Как я протестировал, были некоторые данные бутстрапа в каталоге /var/lib/cloud. После того, как я очистил этот каталог, Пользовательские данные скрипт работал нормально.

rm -rf /var/lib/cloud/* 

Answer 3

User_data запускается только при первом запуске. Поскольку ваш образ является обычным, я предполагаю, что он уже был запущен один раз, и поэтому user_data деактивируется.

Для окон это можно сделать, установив флажок в поле Ec2 Services Properties. Я смотрю на то, как это сделать автоматическим способом в конце создания пользовательского образа.

Для linux я предполагаю, что механизм тот же, и user_data необходимо активировать на вашем пользовательском изображении.

#cloud-boothook заставляет его работать, потому что он меняет сценарий с user_data на cloud-boothook, который запускается при каждом запуске.

---

EDIT:

Вот код, чтобы активировать запуск на окна с помощью 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 

(я знаю вопрос фокусировки Linux, но это может помочь другим ...)

Answer 4

Я использую CentOS, и логика для пользовательских данных проста:

• В файле /etc/rc.local есть вызов для initial.sh сценария, но он ищет флаг первого:

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

initial.sh файл, который выполняет выполнение пользовательских данных, но в конце он удаляет флаг.Итак, если вы хотите, чтобы ваш новый AMI выполнить пользовательские данные еще раз, просто создать флаг снова перед создать образ:

touch /var/tmp/initial 

Answer 5

Я также столкнулся с теми же проблемами на Ubuntu 16.04 HVM AMI. Я поднял вопрос на поддержку AWS, но все же я не смог найти точную причину/ошибку, которая влияет на нее.

Но все же у меня есть что-то, что может вам помочь.

Перед тем, как взять AMI remove/var/lib/cloud directory (каждый раз). Затем, создав Image, установите его на no-reboot.

Если эти вещи все еще не работают, вы можете протестировать их дальше, заставляя пользовательские данные запускаться вручную. Также tailf /var/log/cloud-init-output.log для статуса облака-init. Он должен заканчиваться чем-то вроде модулей: final, чтобы выполнить ваши пользовательские данные. Он не должен зависеть от модулей: config.

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

Я не имею много идеи, будут ли эти команды работают на CentOS или нет. Я тестировал его на Ubuntu.

В моем случае я также попытался удалить каталог/var/lib/cloud, но при этом не удалось выполнить пользовательские данные в нашем сценарии. Но я придумал для этого другое решение. Что мы сделали, так это то, что мы создали скрипт с приведенными выше командами и запустили этот скрипт во время загрузки системы.

Я добавил ниже строку в /etc/rc.local, чтобы это произошло.

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

Но вот загвоздка, он будет выполнять скрипт каждый раз при загрузке, так что сделает ваши пользовательские данные для запуска на каждом ботинке, так же, как # облачной boothook. Не стоит беспокоиться, вы можете просто настроить его, просто удалив файл force -user-data.sh в конце. Так что ваш force-user-data.sh будет выглядеть как

#!/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

Я буду признателен, если кто-то может поставить некоторые огни на том, почему он не в состоянии выполнить данные пользователя.

Answer 6

У меня были проблемы с этим. Однако я подробно расскажу об этом.

Моя добавленная морщина заключается в том, что я использую terraform для создания экземпляров хостов через конфигурацию запуска и группу автомасштабирования.

Я не мог заставить его работать, добавив встроенный скрипт в lc.tf

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

Я мог бы извлечь его из пользовательских данных,

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

, но заметил, что я получал его с котировки все еще в нем.

Вот как я получил его на работу: я перетащил его из шаблона вместо того, что то, что вы видите, это то, что вы получаете.

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

Это означает, что я также должен объявить свой файл шаблона следующим образом:

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

} 

Но я все еще получаю ошибку в журналах инициализации облачных /var/log/cloud-init.log [ПРЕДУПРЕЖДЕНИЕ]: Неизвестное без многочастному (текст/х-не-многочастному) пользовательские данные: "Content-Type: текст/облака ...

Тогда я нашел this article about user data formatting user Это имеет смысл, если пользовательские данные могут прийти в нескольких частях, может быть, облако-init нуждается в командах cloud-init в одном месте и сценарий в другом.

Так что мой bootscript.tpl выглядит следующим образом:

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" 
--//