Как настроить cloud-init для пользовательских AMI в AWS? (CentOS)

Question

Определение пользовательских данных для экземпляров в AWS кажется действительно полезным для выполнения всех видов действий типа начальной загрузки. К сожалению, мне приходится использовать пользовательский CentOS AMI, который не был создан ни по одному из предоставленных AMI по причинам PCI, поэтому cloud-init еще не установлен и не настроен. Я только очень хочу, чтобы он установил имя хоста и запустил небольшой скрипт bash. Как мне заставить это работать?

Answer 1

cloud-init - очень мощный, но очень недокументированный инструмент. Даже после установки многие модули по умолчанию активны и перезаписывают то, что вы уже определили в AMI. Вот инструкции для минимальной настройки с нуля:

инструкции

1. Установите cloud-init из стандартного репозитория. Если вы беспокоитесь о PCI, вы, вероятно, не хотите использовать пользовательские репозитории AWS.

   # rpm -Uvh https://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
   # yum install cloud-init
   

2. редактировать /etc/cloud/cloud.cfg, файл yaml, чтобы отразить желаемую конфигурацию. Ниже приведена минимальная конфигурация с документацией для каждого модуля.

   #If this is not explicitly false, cloud-init will change things so that root
   #login via ssh is disabled. If you don't want it to do anything, set it false.
   disable_root: false
   
   #Set this if you want cloud-init to manage hostname. The current
   #/etc/hosts file will be replaced with the one in /etc/cloud/templates.
   manage_etc_hosts: true
   
   #Since cloud-init runs at multiple stages of boot, this needs to be set so
   #it can log in all of them to /var/log/cloud-init.
   syslog_fix_perms: null
   
   #This is the bit that makes userdata work. You need this to have userdata
   #scripts be run by cloud-init.
   datasource_list: [Ec2]
   datasource:
     Ec2:
       metadata_urls: ['http://169.254.169.254']
   
   #modules that run early in boot
   cloud_init_modules:
    - bootcmd  #for running commands in pre-boot. Commands can be defined in cloud-config userdata.
    - set-hostname  #These 3 make hostname setting work
    - update-hostname
    - update-etc-hosts
   
   #modules that run after boot
   cloud_config_modules:
    - runcmd  #like bootcmd, but runs after boot. Use this instead of bootcmd unless you have a good reason for doing so.
   
   #modules that run at some point after config is finished
   cloud_final_modules:
    - scripts-per-once  #all of these run scripts at specific events. Like bootcmd, can be defined in cloud-config.
    - scripts-per-boot
    - scripts-per-instance
    - scripts-user
    - phone-home  #if defined, can make a post request to a specified url when done booting
    - final-message  #if defined, can write a specified message to the log
    - power-state-change  #can trigger stuff based on power state changes
   
   system_info:
     #works because amazon's linux AMI is based on CentOS
     distro: amazon
   

3. Если есть defaults.cfg в /etc/cloud/cloud.cfg.d/, удали это.

4. Чтобы воспользоваться преимуществами этой конфигурации, определите следующие пользовательские данные для новых экземпляров:

   #cloud-config
   hostname: myhostname
   fqdn: myhostname.mydomain.com
   runcmd:
    - echo "I did this thing post-boot"
    - echo "I did this too"
   

   Вы также можете просто запустить скрипт bash, заменив #cloud-config с #!/bin/bash и поместив скрипт bash в тело, но если вы это сделаете, вы должны удалить все связанные с именем хоста модули из cloud_init_modules,

Дополнительные примечания

Обратите внимание, что это минимальная конфигурация, и cloud-init способен управлять пользователями, ssh-ключами, точками монтирования и т. Д. Посмотрите ссылки ниже для получения дополнительной документации по этим конкретным функциям.

В общем, кажется, что cloud-init делает вещи на основе указанных модулей. Некоторые модули, такие как "disable-ec2-metadata", делают вещи просто по указанию. Другие, такие как "runcmd", делают вещи только в том случае, если их параметры указаны, либо в cloud.cfg, либо в userdata cloud-config. В большей части приведенной ниже документации сообщается только о том, какие параметры возможны для каждого модуля, а не о том, как этот модуль называется, но по умолчанию в cloud.cfg должен быть полный список модулей для начала. Лучший способ отключить модуль - это просто удалить его из списка.

В некоторых случаях "rhel" может работать лучше для тега "distro", чем "amazon". Я действительно не понял, когда.

Рекомендации

• Как установить cloud-init: http://web.archive.org/web/20140925130743/http://docs.openstack.org/grizzly/openstack-image/content/centos-image.html
• Справочник по модулям (неполный): http://cloudinit.readthedocs.org/en/latest/topics/examples.html
• Справочник по модулям (неполный): https://github.com/number5/cloud-init/blob/master/doc/examples/cloud-config.txt
• Общие инструкции по настройке: http://web.archive.org/web/20150110200930/http://www.scalehorizontally.com/2013/02/24/introduction-to-cloud-init
• Управление именем хоста: http://web.archive.org/web/20140805225413/http://docs.openstack.org/user-guide/content/user-data.html

Answer 2

Вот краткое руководство по запуску сценариев во время запуска с использованием cloud-init в AWS EC2 (CentOS).

Этот урок объясняет:

• как установить файл конфигурации /etc/cloud/cloud.cfg
• как облако путь /var/lib/cloud/scripts похоже
• файлы сценариев под облачным путем, используя пример, и
• как проверить, выполняются ли файлы скриптов при запуске экземпляра

Конфигурационный файл

Файл конфигурации ниже находится на AWS CentOS6. Для Amazon Linux, смотрите здесь.

# cat /etc/cloud/cloud.cfg
manage_etc_hosts: localhost
user: root
disable_root: false
ssh_genkeytypes: [ rsa, dsa ]

cloud_init_modules:
 - resizefs
 - update_etc_hosts
 - ssh

cloud_final_modules:
 - scripts-per-once
 - scripts-per-boot
 - scripts-per-instance
 - scripts-user

Дерево каталогов

Вот то, что путь облака /var/lib/cloud/scripts похоже:

# cd /var/lib/cloud/scripts
# tree `pwd`
/var/lib/cloud/scripts
├── per-boot
│     └── per-boot.sh
├── per-instance
│     └── per-instance.sh
└── per-once
       └── per-once.sh

Содержание скриптовых файлов

Вот содержимое файлов примеров сценариев.
Файлы должны быть под пользователем root, Смотрите мой способ создания загрузочного скрипта.

# cat /var/lib/cloud/scripts/per-boot/per-boot.sh
#!/bin/sh
echo per-boot: `date` >> /tmp/per-xxx.txt

# cat /var/lib/cloud/scripts/per-instance/per-instance.sh
#!/bin/sh
echo per-instance: `date` >> /tmp/per-xxx.txt

# cat /var/lib/cloud/scripts/per-once/per-once.sh   
#!/bin/sh
echo per-once: `date` >> /tmp/per-xxx.txt

Результат исполнения

В случае первоначального запуска

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST

В случае перезагрузки

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST

В случае старта с АМИ

# cat /tmp/per-xxx.txt
per-once: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:30:16 JST 
per-instance: 1 January 3, 2013 Thursday 17:30:16 JST 
per-boot: 1 January 3, 2013 Thursday 17:32:24 JST 
per-boot: 1 January 3, 2013 Thursday 17:44:08 JST

Ссылка
Время запуска скрипта в cloud-init (CentOS6) было проверено (переведено)

Answer 3

Расширение предыдущего ответа для тех, кто пытается создать CentOS AMI, который cloud-init включен (и способен фактически выполнять ваши сценарии CloudFormation), вы можете добиться определенного успеха, выполнив следующие действия:

1. запустить торговую площадку CentOS AMI с обновлениями - убедитесь, что облачный init присутствует или sudo yum install -y cloud-init
2. rm -rf /var/lib/cloud/data
3. rm -rf /var/lib/cloud/instance
4. rm -rf /var/lib/cloud/instances/*
5. замещать /etc/cloud/cloud.cfg с конфигурацией в ответе выше, но убедитесь, что вы установили distro: rhel
6. Добавьте помощников CloudFormation ( http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-helper-scripts-reference.html)
7. создать изображение AMI из этого экземпляра

У меня было немало времени, чтобы выяснить, почему мои UserData не вызывались, пока я не понял, что изображения на рынке, естественно, запускают ваши UserData только один раз за экземпляр и, конечно, они уже запускались. Удаление индикаторов, которые уже были выполнены, а также изменение distro: rhel в cloud.cfg файл сделал свое дело.

Для любопытных distro: значение должно соответствовать одному из скриптов Python в /usr/lib/python2.6/site-packages/cloudinit/distros , Как оказалось, AMI, который я запустил, не имел amazon.py так что вам нужно использовать rhel для CentOS. В зависимости от запускаемого вами AMI и версии cloud-init, YMMV.

Answer 4

Спасибо тем, кто уже так много разъяснил по поводу cloud-init! Однако, по крайней мере, в отношении AWS, необходимо выделить один вопрос:

По умолчанию сценарии пользовательских данных и директивы cloud-init запускаются <em><strong>только во время первого цикла загрузки</strong></em> при запуске экземпляра EC2.

Другими словами, они не будут работать при последующих загрузках . Об этом не всегда упоминают, и я подозреваю, что это вызывает путаницу. Подробнее об этом:

cloud-init должен определить, является ли текущая загрузка первой загрузкой нового экземпляра или нет, чтобы применить соответствующую конфигурацию. При первой загрузке экземпляра он должен запускать всю конфигурацию «для каждого экземпляра», тогда как при последующей загрузке он должен запускать только конфигурацию «для каждой загрузки».