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

Ответ 1

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

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

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

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

EDIT:

Вот код для активации запуска в Windows с помощью 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, но он может помочь другим...)

Ответ 2

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

rm -rf /var/lib/cloud/*

Ответ 3

Я использую CentOS, и логика для userdata проста:

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

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

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

touch /var/tmp/initial

Ответ 4

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

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

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

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

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

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

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

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

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

Но вот поймать, он будет выполнять script при каждой загрузке, чтобы заставить ваши пользовательские данные запускаться при каждой загрузке, точно так же, как # cloud-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

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

Ответ 5

У меня было много проблем с этим. Я предоставлю подробную прогулку.

Я добавил, что я использую 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 [ПРЕДУПРЕЖДЕНИЕ]: необработанные пользовательские данные не из нескольких частей (text/x-not-multipart): 'Content-Type: text/cloud..."

Затем я обнаружил эту статью о пользователе форматирования данных пользователя. Это имеет смысл, если пользовательские данные могут состоять из нескольких частей, возможно, cloud-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"
--//

Ответ 6

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

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

#!/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 (без подкаталога). Если вы попытаетесь создать файл в несуществующем каталоге, команда будет понятна, но ваш пример "Обновить", похоже, показывает, что он действительно работает.

Ответ 7

это ответ в качестве примера: убедитесь, что в заголовке есть только #!/bin/bash

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