virginia ec2 east data aws amazon-web-services centos ami cloud-init

amazon-web-services - east - aws ec2 user data



¿Cómo configuro Cloud-init en AMI personalizados en AWS?(CentOS) (3)

Ampliando la respuesta anterior para cualquiera que intente crear un AMI de CentOS que esté habilitado para cloud-init (y capaz de ejecutar realmente sus scripts de CloudFormation), puede tener cierto éxito al hacer lo siguiente:

  1. lanzar un mercado CentOS AMI con actualizaciones - asegúrese de que cloud-init esté presente o 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. reemplace /etc/cloud/cloud.cfg con la configuración en la respuesta anterior, pero asegúrese de configurar la distro: rhel
  6. Agregue los ayudantes de CloudFormation ( http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-helper-scripts-reference.html )
  7. crea una imagen AMI desde esta instancia

Tuve un gran problema tratando de averiguar por qué mi UserData no se invocaba hasta que me di cuenta de que las imágenes en el mercado, naturalmente, solo ejecutan su UserData una vez por instancia Y, por supuesto, ya se habían ejecutado. Eliminar los indicadores de que ya se habían ejecutado junto con cambiar la distro: rhel en el archivo cloud.cfg hizo el truco.

Para los curiosos, el valor de la distro: debe corresponder a uno de los scripts de Python en /usr/lib/python2.6/site-packages/cloudinit/distros . Como resulta que el AMI que amazon.py no tenía amazon.py , entonces necesitas usar rhel para CentOS. Dependiendo de la AMI que inicie y la versión de cloud-init, YMMV.

La definición de datos de usuario para instancias en AWS parece realmente útil para realizar todo tipo de acciones de tipo bootstrap. Desafortunadamente, tengo que usar una AMI de CentOS personalizada que no se originó en uno de los AMI proporcionados por razones PCI, por lo que cloud-init aún no está instalado y configurado. Solo quiero que establezca un nombre de host y ejecute un pequeño script bash. ¿Cómo lo hago funcionar?

Aquí hay un breve tutorial sobre cómo ejecutar scripts durante el inicio usando cloud-init en AWS EC2 (CentOS).

Este tutorial explica:

  • cómo configurar el archivo de configuración /etc/cloud/cloud.cfg
  • cómo se ve la ruta de acceso de la nube /var/lib/cloud/scripts
  • los archivos de script bajo la ruta de la nube usando un ejemplo, y
  • cómo verificar si los archivos de script se ejecutan durante el inicio de la instancia

Archivo de configuración

El siguiente archivo de configuración está en AWS CentOS6. Para Amazon Linux, mira here .

# 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

Árbol de directorios

Aquí se muestra cómo se ve la ruta de acceso de la nube /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

Contenido de los archivos de script

Aquí están los contenidos de los archivos de script de ejemplo.
Los archivos deben estar en la root usuario. Vea mi camino en la creación del script de arranque .

# 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

Resultado de la ejecución

En el caso de una puesta en marcha inicial

# 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

En el caso de un reinicio

# 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

En el caso de comenzar desde el 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

Referencia
El momento en que se ejecuta el script en cloud-init (CentOS6) fue examinado (traducido)

cloud-init es una herramienta muy poderosa pero muy poco documentada. Incluso una vez que está instalado, hay muchos módulos activos por defecto que sobrescriben cosas que ya puede haber definido en su AMI. Aquí hay instrucciones para una configuración mínima desde cero:

Instrucciones

  1. Instale cloud-init desde un repositorio estándar. Si está preocupado por PCI, probablemente no quiera utilizar repositorios personalizados de AWS.

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

  2. Edite /etc/cloud/cloud.cfg , un archivo yaml, para reflejar su configuración deseada. A continuación se muestra una configuración mínima con documentación para cada módulo.

    #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. Si hay un defaults.cfg en /etc/cloud/cloud.cfg.d/ , elimínelo.

  4. Para aprovechar esta configuración, defina los siguientes datos de usuario para las nuevas instancias:

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

    También puede simplemente ejecutar un script bash reemplazando #cloud-config con #!/bin/bash y colocando el script bash en el cuerpo, pero si lo hace, debe eliminar todos los módulos relacionados con el nombre de host de cloud_init_modules .


Notas adicionales

Tenga en cuenta que esta es una configuración mínima, y ​​cloud-init es capaz de administrar usuarios, claves ssh, puntos de montaje, etc. Consulte las referencias a continuación para obtener más documentación sobre esas características específicas.

En general, parece que cloud-init hace cosas basadas en los módulos especificados. Algunos módulos, como "disable-ec2-metadata", hacen cosas simplemente por ser especificados. Otros, como "runcmd", solo hacen cosas si se especifican sus parámetros, ya sea en cloud.cfg o en datos de usuario de configuración de nube. La mayoría de la documentación a continuación solo le indica qué parámetros son posibles para cada módulo, no a qué se llama el módulo, pero el cloud.cfg predeterminado debe tener una lista completa de módulos para comenzar. La mejor forma que he encontrado para desactivar un módulo es simplemente eliminarlo de la lista.

En algunos casos, "rhel" puede funcionar mejor para la etiqueta "distro" que "amazon". Realmente no me di cuenta cuándo.


Referencias