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

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

3 ответов


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. чтобы воспользоваться этой конфигурацией, определите следующие userdata для новых экземпляров:

    #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", делают вещи, только если их параметры указаны, либо в облаке.cfg, или в cloud-config userdata. Большая часть документации ниже только сказать вам, какие параметры возможны для каждого модуля, не то, что модуль называется, но облако по умолчанию.cfg должен иметь полный список модулей для начала. Лучший способ отключить модуль это просто удалить его из списка.

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


ссылки


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

  1. запустите marketplace CentOS AMI с обновлениями-убедитесь, что cloud-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.


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

в случае запуска из в AMI

# 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) был исследован (перевод)