Aprovisionando ambientes AWS con Ansible

En recientes fechas se nos encomendó la misión de optimizar costos y el uso de recursos de Amazon Web Services utilizados para el despliegue y operación de aplicaciones de uno de los clientes principales de InnBit.

Esta reestructura fue vista como una oportunidad para implementar mejoras en la forma de trabajo con AWS que habíamos estado teniendo. Un punto muy particular es el aprovisionamiento de ambientes que implica lanzar una nueva instancia de EC2, actualizar paquetes, instalar dependencias, configurar el ambiente y desplegar la aplicación para dejar todo listo para que esté disponible para su uso.

Todos los pasos descritos con anterioridad son repetitivos y son propensos a ser automatizados por lo que se decidió incluir la herramienta Ansible para facilitar las tareas de aprovisionamiento y despliegue así como reducir posibles errores y el tiempo que se empleaba para poner a punto las aplicaciones.

Ansible

Ansible es una herramienta de código abierto escrita en python para la automatización y orquestación de tareas 

A diferencia de otras soluciones similares, no requiere la instalación de agentes remotos pues su funcionamiento es mediante la ejecución remota de comandos mediante mecanismos como ssh o Windows Remote Managment.

Los comandos son definidos en archivos de texto en formato YAML y permite realizar ejecuciones de comandos repetibles y distribuidas en varios nodos.

Caso de uso

Durante 2016 se desarrollaron aplicaciones que estuvieron en producción casi todo el año. Cuando concluyó este, dichas aplicaciones también terminaron su ciclo debido al fin por el cual fueron construidas. Aún así el cliente solicitó que se mantuvieran activas para fines demostrativos. 

Por ciertas razones, en su momento se reservó una instancia EC2 con las siguientes características

• Red Hat Enterprise Linux 
• Reservada hasta el 20 Junio de 2017
• t2.medium

De acuerdo a los datos de uso y pruebas, se estima que esta instancia sería capaz de manejar de 3 a 4 aplicaciones con baja demanda. De este modo se determinó que la instancia RHEL sería aprovechada para hospedar las aplicaciones con propósito demostrativo.

Para facilitar la configuración y puesta en marcha de varias aplicaciones en un mismo servidor se decidió generar imágenes docker con cada una de las aplicaciones. Estas imágenes serían almacenadas en el registro de contenedores de EC2 (EC2 Container Registry, ECS) donde estarían disponibles para la ejecución de contenedores.

Otro beneficio de utilizar docker es el redireccionamiento de bitácoras. Anteriormente, para revisar una bitácora era necesario ingresar al servidor y explorar los archivos mediante comandos de Linux para procesamiento de texto. Conforme se incrementa el número de servidores y la incorporación de servidores surge la necesidad de concentrar las bitácoras en un solo punto de modo que la detección de errores y solución de problemas sea más ágil.

Docker ofrece un controlador que permite captar la bitácoras generadas por las aplicaciones dentro de los contenedores y enviarlas al servicio CloudWatch el cual incorpora una funcionalidad para concentrar bitácoras y explorarlas.

Todo el proceso desde la instalación de dependencias hasta la ejecución de las aplicaciones en forma de contenedores fue definido mediante un proyecto Ansible quedando el panorama como se muestra en la imágen.

Proyecto Ansible

Para intentar mantener ordenado y simple el proyecto, se ha organizado de la siguiente manera.

Inventario y Archivos de recursos

El inventario es el archivo de nombre hosts, el cual contiene un grupo de servidores con la ubicación de la instancia RHEL en Amazon.

En la carpeta resources/yum se guardan definiciones de repositorios para instalar los paquetes nginx y docker de acuerdo a la documentación de ambos productos. La idea es que estos archivos sean copiados, utilizando Ansible, a la instancia remota en la ubicación adecuada.

En la carpeta resources/env se guardan archivos con las variables de ambiente requeridas por las aplicaciones. En este punto se pretende nuevamente copiar estos archivos de configuración al servidor y leerlos mediante docker al momento de lanzar los contenedores.

Playbooks

Los playbooks son archivos en formato YAML donde se definen todos los comandos que serán ejecutados en el servidor.

Se separaron las tareas de instalación y configuración de acuerdo al paquete y/o aplicación para mantener compactos los archivos.

nginx.playbook.yml. Instalación típica de NGINX para RHEL, en este caso se utilizó ansible para copiar el archivo ./resources/yum/nginx.repo con la ubicación de paquetes actualizados para la instalación.

awscli.playbook.yml. Instalación de la linea de comandos de AWS. Este se utilizará para la interacción con EC2 Container Registry.

docker.playbook.yml. Instalación y configuración de Docker de acuerdo a la documentación oficial. De igual modo que el anterior, se actualizó la definición de repositorios mediante el archivo ./resources/yum/docker.repo que es copiado al servidor para posteriormente realizar las tareas de actualización de paquetes. Al final se genera el grupo docker y se define al usuario ec2-user como miembro de modo que pueda ejecutar comandos docker sin permisos de super usuario.

cop13.playbook.yml. Ejecución de contenedor docker a partir de una imagen alojada en EC2 Container Registry. Esta imágen contiene una aplicación Ruby on Rails que será ejecutada en el puerto 3000 del contenedor. Mediante ansible, además de lanzar el contenedor, también se establece la correspondencia de puertos (3000:3000), el archivo con las variables de entorno requeridas y el redireccionamiento de bitácoras a CloudWatch.

igf.playbook.yml. Ejecución de un segundo contenedor docker a partir de otra imagen alojada en ECR. La ejecución del contenedor es similar al anterior con pequeñas diferencias como la imagen que se toma, el puerto del servidor que se redirecciona al contenedor (3100:3000), las variables de entorno y el destino de bitácoras dentro de CloudWatch.

rhel-demo-server.playbook.yml. Este archivo incluye referencias ordenadas a los demás archivos de modo que permite mantener la secuencia lógica con las cuales se van a ejecutar las instrucciones.

Conclusiones

Al final los archivos de ansible permitieron la puesta en marcha de las aplicaciones partiendo de una instancia nueva de EC2. Como ventaja estos archivos permiten la replicación automatizada de este ambiente en nuevas y diferentes instancias.

Estos scripts también son propensos de ser incluidos en un conducto de entrega y despliegue contínuo, pero será tema de otra entrada del blog.

Historias macabras hacia la certificación de AWS

Recientemente en el equipo nos hemos dado a la tarea de remotar el estudio de la plataforma de Amazon Web Services (AWS) para la construcción de soluciones tecnológicas. Para esto nuestro director Gustavo nos encomendó la empresa de llevar a cabo una serie de sesiones maratónicas de estudio incluyendo a los elegidos próximos a certificarse.

Aprovechando esta euforia renovada por la certificación como arquitecto de soluciones, decidí escribir un poco de mi experiencia propia de hace algunos meses que culminó con la aprobación del exámen de certificación.

Haciendo un poco de memoria, el tema de la certificación en AWS ya rondaba mi cabeza desde algunos ayeres y, como si fuera una de las tareas de Heracles, se propuso como objetivo de Innbit lograr una asociación con Amazon que implica, entre otros requisitos, tener un número de elementos certificados en el equipo.

La aventura inició tempestuosamente cuando por temas de los proyectos se requirió empezar a habilitar ambientes de despliegue y ejecución para la puesta en producción de aplicaciones web basadas en Ruby on Rails. Esa fue mi primera experiencia con EC2, RDS, Elastic Load Balancer y servicios como Route53 para la contratación y configuración de nombres de dominio.

Ya teniendo una primera experiencia con AWS y el objetivo de la certificación se estableció el objetivo de realizar el examen antes de mi participación en el panamericano de jiujitsu de este año (marzo 2016). Por razones de los proyectos que requerían gran cantidad de tiempo y dado que los temas del examen parecían volverse cada vez más amplios, el día D del examen se programó hasta mayo.

El punto de partida de la misión suicida fue revisar la descripción del examen en el portal de AWS, donde se contempla información como el perfil del candidato y enlaces a la guía del examen, un documento con preguntas de muestra y otros recursos. Dentro de la guía del examen se tiene información sobre los temas que son evaluados así como su ponderación, lo que me dió mucha guía sobre el grado de dominio que tenía sobre los temas en relación a la espectativa y resolver ese primer grupo de preguntas muestra me dio un poco de luz (u oscuridad en ese momento) del punto en le que estaba.

Ya con los temas en el radar y el conocimiento acotado, me di a la tarea de iniciar los cursos de CloudAcademy y Udemy que se componen de videos explicativos por tema, laboratorios y cuestionarios. Personalmente completé en su mayoría la ruta de certificación de CloudAcademy. Por otro lado me apoyé de Udemy para las evaluaciones y cuestionarios. Otro recurso interesante es el portal https://qwiklabs.com/, que tiene laboratorios interesantes utilizando recursos de AWS reales, donde también completé algunos.

De CloudAcademy también fue instalada la aplicación móvil la cual permite realizar pequeños cuestionarios de 5 o 10 preguntas, esto a modo de guía para profundizar en los temas que me se requerían refo falta. Esta práctica me permitió estudiar sin saturarme de información, dado que hacía esos pequeños cuestionarios en cualquier oportunidad que tenía y, posteriormente en momentos de más calma, poder referirme a la documentación de AWS o experimentar un poco en la consola.

Además de la información teórica propia de AWS de los cursos y manuales, también me fue muy útil retomar conceptos básicos de computación (redes, almacenamiento, arquitectura,...) y hacer varios experimentos prácticos o en su defecto, ver videos de como implementar ciertas soluciones que trato de resumir a continuación. 

IAM

• Laboratorio de CloudAcademy para generar usuarios, grupos y permisos
• Entender los diferentes tipos de autenticación de usuarios: contraseña, token de acceso, MFA,
• Laboratorio de CloudAcademy para generar un rol, asociarlo a una instancia de EC2 y comprobar que pueda acceder a un bucket de S3.

EC2

• Comprender los sabores de instancias de EC2, diferencias y casos de uso (t, m, c, g, d)
• Generar una instancia Linux y una Windows y acceder a ellas. Esto se aborda en los laboratorios de CloudAcademy y Udemy.
• Generar un AMI a partir de una instancia.
• Implementar una arquitectura pública en alta disponibilidad con componentes como: Balanceador de carga, grupo de autoescalamiento, configuración de lanzamiento, etc. 
• Configurar SSL en un balanceador de carga público.
• Implementar una arquitectura privada en alta disponibilidad con componentes como: Balanceador de carga, grupo de autoescalamiento,  configuración de lanzamiento, etc.

Distribución de contenido

• Generar una lista de distribución de contenido a partir de un bucket de S3
• Agregar otros origenes adicionales a la lista de distribución.
• Configurar un nombre de dominio personalizado, previamente registrado en Route53 
• Configurar SSL
• Configurar origin access identity para restringir que el acceso a los objetos de S3 para que solamente se permita desde la lista de distribución de cloudfront.

Almacenamiento

• Generar un bucket de S3 y habilitar un sitio web estático
• Comprender las distintas clases de almacenamiento de S3, así como sus niveles de durabilidad y disponibilidad
• Laboratorios de Udemy del ciclo de vida y versionamiento de objetos en S3
• Revisar los conceptos sobre arreglos de discos: RAID 0, 1, 10
• Revisar el video RAID 0 on Amazon linux EBS/EC2 para entender como implementar un arreglo de discos mediante volúmenes EBS.
• Laboratorios de CloudAcademy y/o Udemy para generar un volúmen EBS y montarlo en una instancia de EC2. 
• Laboratorios de CloudAcademy y/o Udemy para generar un snapshot a partir de un volumen EBS y un volumen a partir de un snapshot.
• Revisar el video Veeam - Archive Backups using AWS Storage Gateway and S3 que hace una demostración real del uso de Gateway Storage
• Leer sobre los modos en que se pueden configurar los volúmenes de Gateway Storage (Gateway-cached, Gateway-stored, virtual tape library)
• Generar un vault de Glacier desde la consola y generar una regla del ciclo de vida en S3 para enviar objetos.
• Leer sobre las diferencias entre import/export disk y snowball.

RDS

• Generar un database group
• Generar una instancia de RDS sin replicación multizona
• Configurar la replicación multizona de la instancia de RDS
• Generar una réplica de solo lectura

VPC

• Estudiar conceptos básicos de direcciones IP, máscaras de subred, clases de direcciones IP.
• Generar una VPC con al menos dos subredes públicas y dos privadas. Configurar el internet gateway, NACL's, NAT (como servicio y apartir de una instancia de EC2). Para este ejercicio se tienen dos laboratorios en CloudAcademy que contemplan todos los puntos.

Route53

• Estudiar sobre conceptos básicos de DNS y los diferentes tipos de registro (CNAME, A, MX, SOA, NS, etc)
• Registrar un nombre de dominio. Puede comprarse desde la consola
• Generar una hosted zone e identificar el default record set.
• Generar diferentes alias y asociarlos a balanceadores de carga y listas de distribución de CloudFront
• Leer sobre que es la zona APEX y sus restricciones. 

 CloudWatch

• Explorar las gráficas generadas para EC2 y RDS
• Explorar las alertas enviadas a la consola
• Realizar el laboratorio de qwiklabs.com para generar métricas personalizadas de memoria y uso de disco de una instancia de EC2 y mostrarlas en la consola de CloudWatch

Otros

• Leer sobre MemCache y Redis, los cuales se ofrecen como servicios en Elastic Cache, así como sus casos de uso.
• Retomar los conceptos de colas de mensajes y las diferencias y casos de uso de los modelos productor-consumidor y publicador-subscriptor.
• Entender como se implementan los modelos de mensajería y notificaciones a través de los servicios SQS y SNS.
• Retomar conceptos de Hadoop y entender como se implementan a través del servicio EMR.
• Generar una tabla en DynamoDB y experimentar con un cliente Rails para escribir y recuperar datos en JSON.

Al estudiar estos temas uno puede notar que en realidad es bastante información. Cuando estudié la carrera tuve cursos específicos para algunos de los temas y la realidad no terminé de sentirme totalmente preparado al llegar la fecha del examen. Aún así, decidí relizarlo en la fecha pactada y al final concluí lo siguiente.

• Dedicar un tiempo diario en solitario (incluso fines de semana) al estudio y la práctica. No tiene que ser intenso todo el tiempo pero si constante. Personalmente me funciona estudiar algo muy concreto a ratos en lugar de saturarme de información en una sesión demasiado larga.
• Establecer una fecha de examen, diría que alrededor de mes y medio de estudio constante puede ser suficiente.
• El examen no tiene un mínimo de aciertos definido para acreditar, uno debe mentalizarse para obtener la calificación más alta posible.
• No postergar tanto el examen a pesar de la sensación de no estar totalmente preparado. En el peor de los casos solo no se acredita y se vuelve a programar, lo cual también es experiencia valiosa.
• En el examen tratar de no dedicar demasiado tiempo a una pregunta, si se tiene que leer más de dos veces o se lleva más de 45 segundos sin contestar mejor dejarla para después. El examen se compone de 60 preguntas en un tiempo de 80 minutos, lo que da un promedio de 1:15 por pregunta.
• Disfrutar la experiencia. Uno de mis profesores de jiujitsu siempre que ha enseñado que la probabilidad de éxito se incrementa cuando se disfruta cada emoción que se vive al entrar a una competencia. Este exámen para mi fue un torneo más para ganarse el Valhalla y la entrada al Mictlan.