Elastic Beanstalk un sistema a tener en cuenta

Este artículo está en el horno. Verás cambios con el tiempo.

Última revisión: 19 de feb 2018

Consideraciones previas

Tenía pensado hablar directamente sobre Elastic Beanstalk pero quiero hacer unas pequeñas consideraciones al inicio por si os sentís frustrados al empezar con esta tecnología. Debo decir, que una vez ya sumergido en las posibilidades que ofrece y teniendo cierto conocimiento decir que alguien es experto en esto es arriesgado. Es evidente que hay que tener conocimientos previos del funcionamiento de los despliegues, los nodos y saber como funcionan las .ebextensions. Sin embargo quiero recalcar que la manera de preparar el proyecto para el despliegue depende total y absolutamente del conocimiento que tengan los desarrolladores sobre la aplicación y el stack que usen. Ya que todo lo que se va a preparar depende absolutamente del funcionamiento de la aplicación.

El comienzo

Hace unos meses (mediados de 2018) en la empresa donde trabajo apareció la necesidad de disponer de un entorno "indestructible" para una aplicación de gestión que estamos desarrollando. En ese momento instalada directamente sobre hierro con los servicios necesarios para que funcionase a la antigua usanza.

  • AWS con Elastic Beanstalk. A.K.A. EBS
  • Nuestro proyecto en Laravel.

Presentados los contrincantes la diversión y el sufrimiento esta servido sobre la mesa del DevOp.

/var/log/eb-activity.log

El godlog es decir un log para dominarlos a todos.

Voy a intentar describir el sencillo pero doloroso proceso de aprender que os llevará a la victoria. Y no voy a pasar por explicaros cada paso punto por punto. Si no que me voy a centrar en los que no son tan obvios y que son infumables de encontrar en la documentación de AWS.

  • .ebextensions
  • .elasticbeanstalk
  • HTTPS
  • CORS
  • Supervisor

Antes de empezar a meternos en comandos. Voy a explicaros el workflow que he visto en el caso de como funcionan los despliegues en EBS.

 +-------------------+             +---------------+
 |                   |             |               |
 |  /var/app/ondeck  +-------------> Mover carpeta |
 |                   |             |               |
 +-------------------+             +--------+------+
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX          |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX          |
  +---------------+                +--------v-------+
  |               |                |                |
  | /var/www/html |                |/var/app/current|
  |               |                |                |
  +-------^-------+  +----------+  +--------+-------+
          |          | Enlace   |           |
          +----------+ simbólico| <---------+
                     +----------+

Bueno esto es a groso modo un poco lo que hace. No os penséis que esto es evidentemente todo. Pero os aclarará muchas dudas. La idea es que el staging se realiza en un directorio específico (Llaman a staging al momento en el que se prepara el código para su puesta en producción). Aquí es donde debéis realizar los cambios de permisos y demás cosillas que queráis hacer previa puesta en producción. Esto son una serie de comandos que os permitirán instalar node, y realizar operaciones de limpieza antes de instalar Laravel.

container_commands:
    01updateComposer:
      command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update
    02installNode:
      command: "curl -sL https://rpm.nodesource.com/setup_8.x | bash -E -"
    03updateYum:
      command: "sudo yum update"
    04installNodeJs:
      command: "sudo yum -y install nodejs"
    05cache:
      command: "php /var/app/ondeck/artisan cache:clear"
    06permissionsCache:
      command: "chmod -R 777 /var/app/ondeck/bootstrap/cache"
    07permissionsStorage:
      command: "chmod -R 777 /var/app/ondeck/storage"
    08migrate:
      command: "php /var/app/ondeck/artisan migrate --force"

option_settings:
   - namespace: aws:elasticbeanstalk:application:environment
     option_name: COMPOSER_HOME
     value: /root

Una vez realizados los cambios el proceso pasa por mover la carpeta a su ubicación definitiva /var/app/current. Y ojo que no es un enlace simbólico como hacen otros sistemas de despliegue. Una vez ahí crea un enlace simbólico en /var/www/html con el contenido.

Apache tiene una configuración estandard y ejecutará lo que se encuentre en la carpeta /var/www/html

Entonces teniendo en mente esta forma de desplegar ya podemos realizar muchas operaciones con los .ebextensions. Que por si no lo sabéis es la manera que EBS se entera de lo que queréis hacer en las fases previas, posteriores y durante el despliegue. Es decir, si hay que cambiar permisos, ejecutar comandos, etc. Va aquí.

Intuyo que están puestos para ejecutarse en orden alfabético. Es decir que por ejemplo tenemos una estructura:

  • 01-myconfig-wapen.config
  • 02-myconfig-wapen2.config
  • 03-myconfig-wapen3.config

Va evidentemente en el orden previsto. Por cierto, los ficheros .config en realidad son ficheros .yml lo que pasa que algún genio de la lámpara prefirió ponerles `.config` porque quedaba mas cool. Es decir, que si los abrís con un editor de YML os debería pintar bien la sintaxis.

Es importante ya que necesitaréis conocer esto para poder hacer la magia que nos gusta a los desarrolladores.

Para poner la zona horaria hay que crear el fichero /.ebextensions/00-set-timezone.config podéis ordenarlo como queráis

commands:
  set_time_zone:
    command: ln -f -s /usr/share/zoneinfo/Europe/Madrid /etc/localtime


Supervisor

Este tema requiere un espacio a parte en el artículo porque me está dando bastantes quebraderos de cabeza. Por motivos de agilidad he decidido que los servidores van a realizar un despliegue continuo sin reinstanciar nada. Y eso tiene varias implicaciones:

  • Supervisor debe instalarse cuando se instancia un nodo
  • Al actualizar el código de un nodo hay que releer la configuración de Supervisor y reiniciar los procesos.
  • Si hace falta actualizar /etc/supervisor/supervisord.conf hay que reiniciar el servicio.

Parecen cosas obvias pero no son triviales en absoluto. A día de hoy sigo haciendo tweaks para que estas configuraciones funcionen como un reloj.