Base de conocimientos  /  Cloud Application Manager  /  Implementaciones automáticas
Base de conocimientos  /  Cloud Application Manager  /  Implementaciones automáticas

Código en ejecución fuera de una instancia con variables de tareas


Código del artículo: kb/1041

Los scripts del evento se ejecutan, por definición, en la instancia a la que pertenecen. Aunque, tal vez, tenga que ejecutar algún código por fuera del sistema operativo de la instancia, ya sea porque el código debe ejecutarse antes de que la instancia se haya suministrado o debido a que ya ha sido cancelada. En estos casos, puede usar las variables de tareas.

Esta función está disponible para casillas que han sido publicadas en el catálogo.

Aspectos básicos

Las variables de tareas definen el código y un evento asociado. Cuando se implementa una casilla con una variable de tareas, CAM ejecutará este código dentro del ciclo de vida de la instancia al momento indicado por el evento de la variable de tareas:

  • deploy (implementación): como el primer paso después de hacer clic en Deploy (implementación), antes de que se ejecute ningún aprovisionamiento en el proveedor; se ejecuta una vez por instancia.
  • post_deploy (posimplementación): tan pronto como se enciende la máquina y aparece en el Gestor de aplicaciones en la nube; esto puede ocurrir durante la implementación, cuando la instancia se activa después de un evento de cierre (iniciado desde el Gestor de aplicaciones en la nube o desde la consola del proveedor de nube) o cuando aparece una instancia durante un evento de escalado automático ascendente.
  • teardown (desmontaje): cuando una máquina se cierra; esto puede ocurrir durante un evento de cierre, cuando una instancia finaliza durante un evento de escalado automático descendente o un evento de finalización.
  • remove (eliminar): como el último paso una vez que la instancia ha finalizado en el proveedor; se ejecuta una vez por instancia.

Tanto deploy como remove están asociados con el tiempo de vida integral de la instancia, mientras que post_deploy y teardown están asociados con el tiempo de vida de cada máquina. Esto es especialmente útil para instancias con múltiples máquinas (según se define en una casilla para políticas de implementación) o para instancias con escalabilidad automática donde las máquinas pueden aparecer y desaparecer automáticamente.

Aunque no se ejecuten dentro de la instancia en sí, las variables de tareas se comportan de forma similar a los scripts del evento:

  • La sintaxis de plantilla Jinja está disponible, por eso puede tener acceso a variables dentro del script.
  • Los comandos elasticbox set y elasticbox config están disponibles.
  • Al usar una composición de casilla, las variables de tareas de casillas secundarias se ejecutan primero durante los eventos deploy y post_deploy, mientras que se ejecutan por último durante los eventos teardown y remove.
  • Una falla durante la ejecución de una variable de tareas generará un estado no disponible. Una falla puede ser activada desde dentro del script con un código de salida diferente a 0 o puede ocurrir si el script demoró demasiado para finalizar y se detuvo a la fuerza.
  • Los scripts deben ser idempotentes, al igual que los scripts del evento, en el caso de ser ejecutados varias veces debido a un error en la instancia.
  • El resultado del script aparecerá en el registro de actividad de la instancia.
  • Puede haber solo una variable de tareas de cada evento por casilla (por eso, hasta cuatro variables de tareas por casilla, una por evento). Puede agregar múltiples variables de archivo, pero como máximo uno por evento se convertirá en variable de tareas durante el proceso de verificación (más información sobre este tema más abajo).

Idiomas

El entorno admite secuencias en Bash, Python 3 y Node.js. Sin embargo, de forma predeterminada, todos los scripts deben comenzar como scripts de shell. Luego puede integrar el código en otros idiomas y ejecutarlo desde dentro del script de shell.

Disponibilidad y visibilidad

Las variables de tareas están solo disponibles para casillas públicas, verificadas y con control de la versión. Debido a este proceso de verificación, no existe ninguna opción de variable de tareas en la sección de códigos de una casilla: debe crear una variable de archivo y luego enviar una solicitud de publicación. Esta solicitud debe mencionar qué variables de archivo deben ser convertidas en variables de tareas y en qué evento de tareas se ejecutarán. Las variables serán marcadas como privadas y no aparecerán en el editor de ciclo de vida.

Ejemplo

Este ejemplo lo guiará por los pasos para crear una casilla, agregar un script, publicarla con el script como una variable de tareas y ejecutarla.

  • Primero, cree una script box como lo haría normalmente.
  • Vaya a la pestaña Code (código), haga clic en New (nuevo) y luego haga clic en la pestaña File (archivo).
  • Ingrese un nombre descriptivo para la variable y haga clic en Create Empty File (crear archivo vacío)*. Puede ingresar un nombre de archivo con la extensión sh, pero no es estrictamente necesario.
    nueva variable de archivo
  • La variable aparecerá en la lista. Haga clic en el nombre del archivo y aparecerá un editor.
    variable de archivo lista
  • Ingrese el código que quiere ejecutar. Debería comenzar con la oración #!/bin/bash. Después de eso, puede usar bash, nodejs o python. Puede integrar el código como HEREDOC y luego ejecutarlo. Puede acceder a otras variables de casilla a través de la sintaxis Jinja. Por ejemplo, el siguiente código imprime el valor de variable1. Una vez que esté listo, guarde el código.
    editor del código

El código utilizado en el ejemplo se detalla aquí como referencia.

#!/bin/bash

echo "printing from bash"

pythonfile=/tmp/pythontest.py
nodefile=/tmp/nodetest.js

cat <<PYTHON> $pythonfile
#!/usr/bin/python3
print("printing from python")

PYTHON

chmod +x $pythonfile
$pythonfile

cat <<NODE> $nodefile
console.log('printing from node the value of variable1: {{ variable1 }}')

NODE

node $nodefile

elasticbox set variable1 value_set_from_task

  • Vaya a la pestaña Versions (versiones), luego haga clic en el botón New (nuevo). Agregue una descripción y haga clic en Save (guardar).
    nueva versión
  • La versión que acaba de agregar aparecerá en la lista. Haga clic en el botón del engranaje en el extremo derecho de la fila, luego haga clic en Publish Box (publicar casilla).
    publicar casilla
  • Ingrese los detalles de la casilla como quiera que aparezcan en el catálogo. Especifique las variables de archivos que quiere convertir a variables de tareas.
    publicar detalles
  • Su casilla atravesará un proceso de verificación y, si es aprobada, será eventualmente publicada y aparecerá en el catálogo. Se le notificarán los resultados de la revisión. Cuando ingresa a la casilla, aparecerá una tilde verde cerca de la versión que publicó.
    versión publicada
  • Después de eso, se puede implementar la script box desde el catálogo con una política de implementación como lo haría normalmente. Las variables de tareas no son visibles durante la implementación y no se pueden modificar. Tenga en cuenta que solo la casilla publicada con control de versión ejecutará los scripts como variables de tareas. Si intenta ejecutar el borrador de la casilla, se implementará normalmente, pero el código en las variables de archivos no se ejecutarán.
    nueva instancia de la versión publicada
  • Una vez que hace clic en Deploy (implementar), se creará la instancia y será transferido a la página de actividades de la instancia. Cada variable de tareas de implementación aparecerá en su propio paso de actividad donde se imprimirá la salida del script. Una vez que se hayan completado correctamente todas las variables de tareas, se aprovisionará un nuevo VM en el proveedor y todos los scripts del evento se ejecutarán como lo hacen habitualmente.
    implementación de instancia con variables de tareas
  • Si el script establece el valor de la variable durante la ejecución de la variable de tareas, los scripts del evento podrán acceder a esos valores. Tenga en cuenta que no se puede acceder a las variables de tareas en el editor del ciclo de vida.
    editor de ciclo de vida
  • Cuando cancela la instancia, las variables de tareas del evento eliminar se ejecutarán después de que la instancia se haya detenido y eliminado del proveedor.

Fallas del script

El código de salida de las variables de tareas afecta el estado de la instancia, como lo hacen las secuencias de evento: cualquier valor que no sea 0 hará que la instancia esté en estado unavailable (no disponible):

  • Si esto ocurre durante la operación deploy, no se aprovisionará ningún VM y la acción volver a intentar implementación estará disponible.
  • Un error que ocurre en la operación post_deploy convertirá a la instancia en no disponible. Si esto ocurre durante la implementación inicial, la acción volver a intentar implementación estará disponible. Si esto ocurre durante una operación de escalabilidad automática o encendido, tendrá que volver a configurar o instalar.
  • Si esto ocurre durante la operación teardown, el VM estará en un estado no disponible y tendrá que volver a configurar o forzar la cancelación.
  • Si esto ocurre durante la operación terminate, el VM se eliminará, pero la instancia aparecerá como no disponible. En ese punto, puede forzar la cancelación de la instancia, activando las variables de tareas, o borrarla, eliminando la instancia del espacio de trabajo sin ejecutar las variables de tareas nuevamente.

falla en la variable de tareas

Las variables de tareas también pueden fallar si la secuencia no finaliza en el momento correspondiente: el límite actual del tiempo de ejecución es de 30 segundos. Si eso ocurre, el script será desactivado forzosamente y aparecerá el mensaje La variable de tareas demoró demasiado, cancelando... en el registro.

expiró la variable de tareas

Powered by Translations.com GlobalLink OneLink SoftwarePowered By OneLink