Uso de Deploys en ASYD Enterprise

Hace unos días hablamos del producto ASYD, en su versión Enterprise. Que nos permite gestionar, automatizar y monitorizar nuestros servidores desde un sólo panel. También comentamos que se podían generar una serie de Deploys, para crear y automatizar tareas. Hoy trataremos esa parte.

asyd-logo

Uso de Deploys en ASYD Enterprise

Antes de nada vamos a concretar lo que es un Deploy.  Lo podemos definir como un grupo de definiciones y configuraciones, ejecutables, que permiten automaticamente ejecutar instalaciones o desinstalaciones de software, cargar y analizar sintácticamente configuraciones, ejecutar comandos en el sistema de destino o de un tercer sistema, monitorizar servicios, y en general, configurar nuestra infraestructura y dejarlo todo listo. Esta definición no es mía, la podéis consultar en su documentación en castellano, aquí.

Veamos la estrucutra de los Deploys

  • Un directorio con el nombre del deploy, por ejemplo: «data/deploys/MYSQL» Dicho nombre se mostrará en el panel de control de ASYD
  • Un archivo llamado «def» : «data/deploys/MYSQL/def«, que contiene la definición de lo que el deploy hará, esto es, paquetes a instalar, comandos para ejecutar, configuraciones, etcétera.
  • Opcionalmente podemos crear un fichero llamado «def.sudo«, ubicado también en la misma carpeta: «data/deploys/MYSQL/def.sudo«, en caso que queramos utilizar un usuario no root.
  • De manera opcional, también, se puede generar el fichero «undeploy«, afincado en la misma carpeta: «data/deploys/MYSQL/undeploy«, con los pasos necesarios para revertir los campos en un deploy.
  • Al igual que con el fichero «def» y «def.sudo», podemos generar un «undeploy» llamado «undeploy.sudo» para usuarios no root.
  • Finalmente un directorio de «configs» con todas las carpetas y ficheros de configuración que necesitemos utilizar: «data/deploys/MYSQL/configs«

Creación de un fichero def

Tanto en los ficheros «def» o «def.sudo» se trabajan con los siguientes comandos y parámetros:

  • Comentarios. Al igual en todos los lenguajes de script se aceptan comentarios, similar a Bash, al principio de ellos deberemos utilizar el símolo almohadilla «#«, un ejemplo sería:  # Esto es un comentario
  • install / uninstall. Ambos comandos se utilizan para instalar o desinstalar los paquetes listados a continuación de la orden. Opcionalmente se pueden definicir condicionales. Un ejemplo: install [if <condición>] paquete-a-instalar
  • config file. Permite cargar una configuración almacenada en el directorio configs. El fichero que llamemos tiene que existir en la carpeta.  Aceptar argumentos condicionales y un argumentos llamado «noparse», si deseas que no se parsee, y se carge tal y como está escrito. Es importante leer el apartado sobre configuraciones. Su ejemplo de uso es el siguiente: [noparse] config file [if <condition>]: file conf, /destination/file.conf
  • config dir. Se comporta igual que en el apartado anterior.  A diferencia de éste, inspecciona de manera recursiva todos los ficheros y subdirectorios en el interior del directorio definido, parseando cada uno de los ficheros de configuración. También admite condicionales y el parámetro noparse. Su forma de uso es la siguiente: [noparse] config dir [if <condition>]: configdir, /destination/dir
  • exec.  Se trata del comando más versátil, ya que simplemente ejecuta cualquier comando de usuario definido, tipo bash/sh. Acepta también condicionales y parámetros host, por lo que permite añadir en la orden cualquier otro host.  Su uso es: exec [host] [if <condition>]: command
  • http. Dicho comando permite ejecutar órdenes HTTP GET o POST desde un deploy. Dicha llamada se ejecuta desde el propio servidor ASYD en lugar del host.  Es interesante para interactuar con una API, dado que se puede utilizar «http» desde el comando «var» (lo tratamos más adelante) y guardar la respuesta en una variable. Su forma de uso es: http get [if <condition>]: url o bien http post [if <condition>]:url [,key1=val1, key2=val2,…]
  • service. Permite controlar servicios en un host determinado. Se trata de un comando transparente al usuario, funciona tanto en sysvinit, systemd o bien en los init scripts de OpenBSD. Su sintáxis: <enable|disable|start|stop|restart> service [if  <condition>]: service
  • var. Se trata de un comando muy importante ya que permite asignar una variable de host desde un archivo «def» o «undeploy» , la cual puede ser llamada luego como una variable normal. Las variables pueden ser asignadas con el resultado del comando exec. Su funcionamiento : var <varname> = http <get|post> [if <condition>] : url [,key1=val1, key2=val2,…]
  • monitor / unmonitor. Dicho comando nos permite monitorizar o dejar de monitorizar, un servicio. El parámetro del servicio debe tener el mismo nombre que el fichero «monitor» ubicado en el interior del directorio «data/monitors«, el cual debe existir. Se pueden monitorizar varioas servicios, separados por comas. Su uso: monitor [if <condition >] : service o unmonitor [if <condifiton>]: service
  • deploy / undeploy.  Con dicho comando podemos lanzar otros deploys. Permitiendo incluso crear un meta-deploy definiendo los deploys que deberían ser lanzados dependiendo de unos condicionantes.  Su uso: deploy [if <condition>]: otro_deploy o bien undeploy [if <condition>] : otro_deploy
  • reboot. Se trata de un comando que simplemente reinicia el sistema. Se debe utilizar al final del deploy. Su uso es: reboot [if <condition>]

Laboratorio de pruebas

Para probar el uso de los deploy voy a utilizar la instancia gratuita que cree en el anterior artículo.  Desde entonces he eliminado los dos host que cree, y ahora tengo uno nuevo, sin ningún servicio adiconal instalado. Se trata de un servidor Debian, en su última versión, que es la 8, con codename «Jessie«

Vamos a utilizar un deploy del proyecto contrib ubicado en GitHub, desde donde podemos ver varios ejemplos.  Utilizaremos el que nos ayudará a crear una instancia de DokuWiki.

asyd-deploy-01

Es un ejemplo bastante ilustrativo. Tenemos un fichero «def» con el código a ajecutar, que utiliza dos ficheros ubicados en la carpeta «configs«, llamados «docuwiki» y «www.conf«, que contienen la información para el servicio web. Para aplicarlo en nuestra instancia, sólo debemos irnos al apartado «Deploys» Una vez allí creamos uno nuevo.

asyd-deploy-02

Accedemos marcando sobre el botón «Details» Y hacer un copiar y pegar con el contenido de GitHub, si los ficheros no existen los creamos.

asyd-deploy-03

Si analizamos el fichero «def«, vemos que primero detecta si utilizamos el sistema de paquetería yum o apt, una vez detectado instala el servicio web nginx más una librería de PHP. Para mejorar el script se tendría que cambiar yum por dnf, me lo apunto. Una solución sería añadir un parámetro OR (if <%pkg_manager%> == yum or <%pkg_manager%> == dnf) Después utilizando «exec» ejecuta una serie de ordenes, crea la carpeta /var/www y descarga el contenido de DocuWiki, para más tarde utilizar los ficheros de configuración ubicados en la carpeta «configs«.

Para que todo funciona debemos crear los dos ficheros en «configs» y copiar la configuración del proyecto en GitHub.

asyd-deploy-04

Volvemos a cargar «Deploys» Señalamos el servidor «DebianJessie«, que hemos añadido con anterioridad. Y lanzamos nuestro nuevo deploy. Entonces nos aparecerá el mensaje:

asyd-deploy-05

Nos informa que la variable «http_port» no ha sido declarada, si no la declaramos la dejará vacía. Para evitar eso le debemos asignar un puerto, ya sea el 80, que es el habitual, el 8080 o el que queramos.

Si todo ha ido bien, al escribir la IP pública del servidor o bien el dominio o subdominio configurado, veremos el resultado:

asyd-deploy-06

Tened en cuenta que podemos hacer el Deploy que queramos, a nuestra medida, para cualquier servicio. Una vez creado quedará guardado, para poder utilizarlo a posteriori, incluso podemos ejecutarlo en varios servidores a la vez, con la opción de «Hosts Groups«

Hasta aquí el artículo de hoy. Quiero agradecer al equipo de ASYD, especialmente a Sergio y Diana, por resolver todas mis dudas, que han sido unas cuantas.

En el tercer y último capítulo sobre éste producto hablaremos de la Monitorización de servidores, utilizando la herramienta monit.

Cualquier duda o sugerncia podéis dejar un comentario.