run - Los scripts de datos de usuario no se están ejecutando en mi AMI personalizado, pero funcionan en Amazon linux estándar

aws memory monitoring

Question

Busqué mucho tema sobre "la secuencia de comandos de datos de usuario no funciona" en estos pocos días, pero hasta ahora, todavía no tengo ninguna idea sobre mi caso, ayúdame a descubrir qué sucedió, ¡muchas gracias!

De acuerdo con User-data explicación de User-data AWS:

Cuando inicia una instancia en Amazon EC2, tiene la opción de pasar datos de usuario a la instancia que se puede usar para realizar tareas comunes de configuración automatizada e incluso ejecutar scripts una vez que se inicia la instancia.

Así que traté de pasar mis propios datos de usuario cuando se lanzó la instancia, estos son mis datos de usuario:

#! / bin / bash

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

Pero no hay ningún archivo en esta ruta: /home/ec2-user/user-script-output.txt

Comprobé /var/lib/cloud/instance/user-data.txt, el archivo existe y lo mismo que mi script de datos de usuario.

También revisé el registro en /var/log/cloud-init.log, no hay ningún mensaje de error.

Pero el script de datos de usuario funciona si lanzo una nueva instancia con Amazon linux (2014.09.01), pero no estoy seguro de la diferencia entre mi AMI (basado en Amazon linux) y Amazon linux.

La única parte diferente que vi es si ejecuto este script:

sudo yum list instalado | grep cloud-init

Mi AMI:

cloud-init.noarch 0.7.2-8.33.amzn1 @ amzn-main

Amazon linux:

cloud-init.noarch 0.7.2-8.33.amzn1 instalado

No estoy seguro de que este sea el motivo?

Si necesita más información, me complace proporcionarla, por favor avíseme qué sucedió en mi propia AMI y cómo solucionarla.

muchas gracias

Actualizar

Acabo de encontrar una respuesta de esta post ,

Si agrego # cloud-boothook en la parte superior del archivo de datos de usuario, ¡funciona!

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

Pero aún no estoy seguro por qué.

Answer 1

Como probé, había algunos datos de arranque en el directorio /var/lib/cloud . Después de borrar ese directorio, el script de Datos de usuario funcionó normalmente.

rm -rf /var/lib/cloud/*

Answer 2

Estaba teniendo muchos problemas con esto. Proporcionaré una caminata detallada.

Mi rasgo añadido es que estoy usando terraform para crear instancias de los hosts a través de un grupo de configuración de inicio y autoescala.

No pude hacerlo funcionar agregando el script en línea en lc.tf

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

Podría obtenerlo de los datos del usuario

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

pero me di cuenta de que lo estaba obteniendo con las citas aún en él.

Así es como lo hice funcionar: pasé a sacarlo de una plantilla, ya que lo que ves es lo que obtienes.

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

Esto significa que también necesito declarar mi archivo de plantilla así:

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

Pero todavía recibía un error en los registros de inicio de la nube /var/log/cloud-init.log [ADVERTENCIA]: datos de usuario no multiparte no enviados (texto / x-no-multiparte): ''Tipo de contenido: texto / nube. .. ''

Luego encontré este artículo sobre el usuario de formateo de datos de usuario. Tiene sentido, si los datos de usuario pueden venir en varias partes, tal vez cloud-init necesita comandos de cloud-init en un lugar y el script en el otro.

Entonces mi bootscript.tpl se ve así:

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

Answer 3

Estoy usando CentOS y la lógica para userdata es simple:

• En el archivo /etc/rc.local hay una llamada para un script initial.sh, pero primero busca un indicador:

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

initial.sh es el archivo que realiza la ejecución de datos de usuario, pero al final elimina el indicador. Por lo tanto, si desea que su nueva AMI vuelva a ejecutar datos de usuario, solo cree la bandera nuevamente antes de crear la imagen:

touch /var/tmp/initial

Answer 4

También me he enfrentado al mismo problema en Ubuntu 16.04 hvm AMI. He planteado el problema al soporte de AWS, pero aún así no pude encontrar el motivo / error exacto que lo afecta.

Pero aún tengo algo que podría ayudarte.

Antes de tomar AMI, elimine el directorio / var / lib / cloud (cada vez). Luego, al crear la imagen, configúrela para que no se reinicie.

Si estas cosas todavía no funcionan, puede probarlo aún más forzando a los datos de usuario a ejecutarse manualmente. También tailf /var/log/cloud-init-output.log para el estado de cloud-init. Debería terminar con algo así como módulos: final para ejecutar su información de usuario. No debería quedarse en los módulos: config.

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

No tengo mucha idea de si los comandos anteriores funcionarán en CentOS o no. Lo he probado en Ubuntu.

En mi caso, también he intentado eliminar el directorio / var / lib / cloud, pero todavía no pudo ejecutar los datos de usuario en nuestro escenario. Pero he encontrado una solución diferente para eso. Lo que hemos hecho es que hemos creado una secuencia de comandos con los comandos anteriores e hicimos que la secuencia de comandos se ejecute mientras el sistema arranca.

He agregado la línea a continuación en /etc/rc.local para hacerlo realidad.

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

Pero aquí está el truco, ejecutará la secuencia de comandos en cada arranque, por lo que hará que sus datos de usuario se ejecuten en cada arranque, al igual que # cloud-boothook. No se preocupe, puede modificarlo simplemente eliminando el archivo force-user-data.sh al final. Entonces tu force-user-data.sh se verá algo así como

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

Apreciaré si alguien puede iluminar por qué no puede ejecutar los datos del usuario.

Answer 5

User_data se ejecuta solo en la primera puesta en marcha. Como su imagen es personalizada, supongo que ya se inició una vez y, por lo tanto, user_data se desactivó.

Para Windows, se puede hacer marcando una casilla en Ec2 Services Properties . Estoy viendo el momento de cómo hacerlo de forma automática al final de la creación de imagen personalizada.

Para Linux, supongo que el mecanismo es el mismo, y user_data debe ser reactivado en su imagen personalizada.

El #cloud-boothook hace que funcione porque cambia el script de un mecanismo user_data a un cloud-boothook que se ejecuta en cada inicio.

EDITAR:

Aquí está el código para reactivar el inicio en Windows usando 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

(Sé que la pregunta se centra en Linux, pero podría ayudar a otros ...)

Answer 6

Los datos de usuario deben ejecutarse #cloud-boothook sin usar #cloud-boothook (que se utiliza para activar los datos de usuario lo antes posible durante el proceso de arranque).

Inicié un nuevo AMI de Amazon Linux y usé sus datos de usuario, más un poco más:

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

Esto creó con éxito tres archivos.

Los scripts de datos de usuario se ejecutan como root , por lo que debe tener permiso para crear archivos en cualquier ubicación.

/home/ec2-user/user-script/output.txt que en el código proporcionado, un ejemplo se refiere a /home/ec2-user/user-script/output.txt (con un subdirectorio) y un ejemplo hace referencia a /home/ec2-user/user-script-output.txt (sin subdirectorio). Es comprensible que el comando falle si intentas crear un archivo en un directorio inexistente, pero tu ejemplo de "Actualización" parece mostrar que realmente funcionó.