En esta serie de entradas de nuestro blog vamos a explicaros cómo hacer que el despliegue de nuestra aplicación se realice de manera automática, también conocido como Despliegue Continuo (Continuous Deployment/CD).
El término Despligue Continuo consiste en preparar el sistema de manera que cada cambio es pasado por una serie de test automáticos y, si todos ellos son superados, se despliegan esos cambios en producción directamente. Esto permite que se reduzca notablemente el tiempo transcurrido desde que se escribe una línea de código hasta que ésta es usada por los usuarios finales en producción.
Es importante no confundir el término Despliegue Continuo con Entrega Continua (Continuos Delivery). La diferencia radica en el hecho de que mientras que el Despliegue continuo es totalmente automático, la Entrega Continua, aunque mejora los tiempos, deja el paso de despliegue en producción en manos del DevOps encargado del proyecto.

Servicios para el Despliegue Continuo

De cara a llevar a cabo el despliegue continuo de nuestra aplicación, es necesario utilizar diferentes herramientas que nos hagan la vida más sencilla. En primer lugar, se deberá tener un sistema de Integración Continua, que se encargue de realizar los test a nuestra aplicación, de manera que no cualquier commit que hagamos a nuestro repositorio se despliegue directamente, sino sólo aquellos que pasen nuestros controles de calidad. Hay muchísimos servicios de Integración Continua, Open Source y de pago. Podemos destacar Jenkins (https://jenkins.io), Gitlab CI (https://about.gitlab.com/features/gitlab-ci-cd), Travis CI (https://travis-ci.org) y CircleCI (https://circleci.com). En este post, utilizaremos CircleCI, ya que para proyectos pequeños permite tener hasta 1.500 minutos de builds gratuitos al mes, por lo que nos permitirá iniciarnos en el Despligue Continuo de manera rápida y fiable.
Por supuesto, será necesario tener un repositorio donde tener el código de nuestra aplicación. CircleCI tiene integración con Github y Bitbucket. En este caso vamos a usar Bitbucket ya que nos permite tener repositorios privados de manera gratuita.
Por último, de cara al despliegue continuo, nos hemos decantado por CodeDeploy de AWS. Este servicio te permite desplegar sobre la cloud de Amazon Web Services tu aplicación de manera continua y transparente para el usuario final. Este servicio hace uso de otros muchos servicios disponibles en AWS: S3, IAM, Auto Scaling, Elastic Load Balancer y CloudWatch son los más importantes.

 CodeDeploy como herramienta de Despligue Continuo

CodeDeploy es un servicio de AWS que busca facilitar el lanzamiento rápido de nuevas características en aplicaciones, consiguiendo evitar caídas temporales del servicio y disminuyendo la tasa de error gracias a la eliminación de procesos manuales.
Usar este tipo de tecnología necesita de bastantes conocimientos de las distintas herramientas disponibles en AWS: S3, Elastic LoadBalancer, Auto Scaling Groups, IAM y CloudWatch. En este post vamos a realizar un ejemplo lo más sencillo posible para que sirva como iniciación en este mundo del Despliegue Continuo.

Comenzamos: creación de bucket S3

El primer paso es crear nuestro bucket de S3. S3 (Simple cloud Storage Service) es un servicio de AWS para el almacenamiento de datos escalable, seguro y sencillo. Durante el proceso de despliegue continuo de nuestra aplicación, el primer paso será subir los datos a S3, por lo que necesitaremos un bucket en el que almacenar nuestro código.
Para crear nuestro bucket, nos vamos a la consola de AWS, buscamos la sección de S3 y le damos al botón de Crear bucket. Nos aparecerá una pantalla como la que vemos a continuación, donde debemos insertar el nombre de nuestro bucket (que debe cumplir con el formato DNS, ya que posteriormente formará parte del dominio e nuestro bucket), y la región. El último campo te permite copiar la configuración de otro bucket que tuvieras creado anteriormente.

Pulsando en Siguiente, veremos la pantalla de Propiedades. En ella, podemos configurar distintas características del bucket como el versionado, si queremos guardar un log de las acciones que tienen lugar en el bucket (a nivel de objeto y a nivel de servicio), y si queremos encriptar el contenido del bucket (esta última es muy recomendable).
Por último, hay que añadir al bucket los permisos de los usuarios que vayan a tener acceso a este bucket. En principio no le daremos ningún tipo de permiso especial, ya que vamos a usar un rol IAM para gestionar estos permisos.

Creación de Roles IAM para CodeDeploy e instancias

El siguiente paso será crear un par de roles IAM (Identity and Access Management) para añadírselos a nuestros servicios. Un rol IAM es un permiso que concedes a una entidad de AWS con una serie de políticas que indican qué acciones puede hacer esa entidad y cuáles no dentro de nuestro entorno AWS.
Como decíamos anteriormente, crearemos dos roles IAM en este ejemplo: uno que será asignado a las distintas instancias que se creen y otro que será usado por el servicio CodeDeploy. Para crear un rol IAM, debemos acceder a la pantalla del servicio IAM en la consola de AWS, ir al apartado de roles y pulsar en Crear rol. Aparecerá una pantalla como la que tenemos a continuación, donde debemos seleccionar el tipo de servicio que usará el rol. Para el primer rol, que será el usado por las instancias de EC2, el tipo de servicio será EC2, con caso de uso EC2 normal (que permite a las instancias llamar a los servicios AWS en tu nombre).

Tras esto pulsamos en Siguiente: Permisos donde seleccionaremos los permisos que daremos a nuestras instancias. Siempre es recomendable dar los mínimos permisos a los roles IAM, de cara a incrementar al máximo la seguridad. En este caso concreto, los permisos mínimos que debemos dar para garantizar el funcionamiento de nuestra aplicación son:

• AWSCodeDeployReadOnlyAccess: Da acceso de lectura a los servicios de CodeDeploy
• AmazonS3ReadOnlyAccess: Da acceso de lectura a los buckets de S3
• AmazonEC2ReadOnlyAccess: Da acceso de lectura a los servicios de EC2

Pulsando en siguiente nos sale una pantalla de revisión, donde le damos a nuestro rol un nombre (PostInstancesRole en nuestro caso) y una descripción y le damos a Crear rol.
El otro rol IAM que debemos crear será el usado por el servicio CodeDeploy. En este caso, en la selección de servicios debemos seleccionar CodeDeploy, en permisos dejar el que aparece por defecto (AWSCodeDeployRole) y en la revisión poner nombre (PostCodeDeployRole en nuestro caso) y una descripción y listo, ya tenemos nuestros dos roles.

Elastic Load Balancer

El siguiente paso que debemos realizar en nuestra configuración de AWS para Depliegue Continuo será crear la parte relativa a EC2: Elastic Load Balancer y Auto Scaling Group.
Para crear el Elastic Load Balancer, nos vamos a este apartado de la sección EC2 de la consola de AWS. Pulsamos en el botón Crear Load Balancer y seleccionamos el Classic Load Balancer. Le damos un nombre, seleccionamos la VPC en la que estará el Load Balancer y añadimos los listeners, de manera que redirijamos a través de él las peticiones que lleguen a los puertos de entrada a los puertos de nuestra aplicación. En nuestro caso, usaremos el protocolo HTTPS (puerto 443) redirigido a la instancia con el protocolo HTTP (puerto 80). Al ser la subred privada, no necesitamos que la instancia use HTTPS, por eso sólo lo ponemos en el Load Balancer.
El siguiente paso es añadirle un Security Group al Load Balancer. Este grupo de seguridad permite decir qué puertos del Load Balancer estarán accesibles desde el exterior. Para poder usar los listeners configurados previamente, debemos añadir al menos esos puertos al Security Group creado.
Como hemos seleccionado un Load Balancer con HTTPS, en el siguiente pasó será necesario añadir nuestro certificado SSL para la aplicación. Aquí tenemos dos opciones: subir un certificado a IAM o solicitar un certificado al servicio ACM (AWS Certificate Manager) de AWS. Los certificados ACM son gratuitos si vas a usar un Elastic Load Balancer u otro de los servicios compatibles. En caso de que decidas subir tu propio certificado, sólo debes copiar los valores de tu Clave Privada, Cuerpo del Certificado y Certificado de la entidad certificadora.

Tras esto, configuramos el Health Check, que sirve para comprobar que las máquinas siguen activas. Se debe poner aquí un puerto y un path al que el servicio pueda preguntar. Lo dejaremos por defecto, HTTP, puerto 80, index.html.
Para terminar, viene el paso de añadir instancias a nuestro Load Balancer. Como en este ejemplo vamos a usar grupos de auto escalado, no será necesario añadir instancias. Nos vamos a Revisar y crear y ¡ya tenemos creado nuestro Elastic Load Balancer!

Auto Scaling Group

Los grupos de auto escalado de AWS permiten configurar una serie de reglas que levanten nuevas máquinas y las pongan a trabajar en paralelo en caso de que los requerimientos de capacidad de memoria, disco duro o RAM sean elevados o disminuir el número de máquinas si están por debajo del rendimiento mínimo marcado, evitando así por un lado que la experiencia de usuario sea mala si las máquinas están saturadas, y disminuyendo costes si las máquinas están por encima de su rendimiento mínimo.
Para crear un nuevo Auto Scaling Group, nos vamos a este apartado dentro de la sección de EC2 y pulsamos en el botón de crear. Si teníamos previamente alguna configuración de lanzamiento de máquinas creada, podremos añadirla a nuestro grupo, si no, debemos crearla. El primer paso, será elegir el tipo de máquina base que vamos a utilizar. Teniendo en cuenta que en el Despliegue Continuo con CodeDeploy cada nuevo push que hagamos al repositorio hará una instalación desde cero de todas las dependencias, simplemente debemos elegir una AMI que se adapte a los requerimientos que tengamos en nuestra aplicación. En nuestro caso, seleccionaremos la Ubuntu Server 16.04. Tras esto, elegimos el tipo de instancia que debe lanzarse dentro del grupo. Esto dependerá bastante de los requerimientos de tu aplicación, del número de usuarios que tengas, etc. Como es para una prueba básica, seleccionaremos una t2.micro.
El siguiente paso es importante. Además de ponerle un nombre a nuestra configuración, debemos ponerle el Rol IAM que tendrá. Aquí debemos usar el que creamos para las instancias EC2, que nosotros llamamos PostInstancesRole. Importante también, abrir los Detalles Avanzados y, en el campo User Data, añadir el siguiente script

#!/bin/bash
sudo apt-get update -y
sudo apt-get install -y ruby
sudo apt-get install -y wget
cd /home/ubuntu
wget https://aws-codedeploy-eu-west-1.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent start

Lo que permite este script es instalar e iniciar el agente de CodeDeploy, necesario para llevar a cabo el proceso de Despliegue Continuo. Importante que pongamos en el wget la región en la que vayamos a hacer el deploy. En nuestro caso es eu-west-1 pero hay otras disponibles. También es importante destacar que este script está hecho para la distribución Ubuntu. Si has seleccionado otra, deberás adaptarlo a tu distribución.
Después añades el almacenamiento que requieras a tu máquina, configuras los Security Groups, donde debes añadir al menos el puerto 80 en el que levantaremos la aplicación, para que el Elastic Load Balancer pueda llegar a ella, y creamos la configuración de lanzamiento.
Ahora que ya tenemos creado nuestra configuración, vamos a crear el Auto Scaling Group. Le ponemos un nombre, el número de instancias con el que empezará el grupo (dejamos 1 para no incurrir en costes innecesarios) y elegimos la red y las subredes a las que va a tener acceso (importante que coincidan con las de nuestro Elastic Load Balancer). Abrimos además las opciones avanzadas y marcamos el check para recibir tráfico desde Load Balancers. Seleccionamos aquí el Load Balancer creado anteriormente y le damos a configurar las políticas de escalado.
Este paso nos lo vamos a saltar, ya que este post lo queremos enfocar en Despligue Continuo, pero configurar políticas de auto escalado es clave para todo DevOps. Lo mismo sucede con las notificationes. AWS te permite crear alertas que te avisen por mail, sms, incluso notificaciones push a una app, a partir de alertas que pongas en tus instancias/grupos de auto escalado. En este ejemplo, no lo vamos a configurar, pero también es muy interesante.
Terminados todos estos pasos, pulsamos en Crear y tendríamos listo nuestro Auto Scaling Group.

Configuración CodeDeploy

Y por fin estamos ante el último paso para dejar listo nuestro entorno AWS: la configuración del Despliegue Continuo usando CodeDeploy. Para comenzar, nos vamos a la sección CodeDeploy de nuestra consola de AWS y pulsamos el botón de Crear Aplicación.
Esta pantalla es clave, así que vamos a ir viendo los campos uno por uno:

• Application name: el nombre que va a tener nuestra aplicación CodeDeploy.
• Deployment group name: el nombre del grupo de despliegue.
• Deployment type: uno de los puntos críticos. Debemos elegir entre «In-place deployment» y «Blue/green deployment». El In-place es más rápido y menos costoso, ya que lo que hace es, en las máquinas que tengas levantadas actualmente, hacer un update de la aplicación. El problema: que para hacer eso, deja cada instancia offline cuando se produce la actualización, pudiendo provocar cortes en el servicio. El despliegue blue/green consiste en crear un nuevo entorno igual que el que tenías levantado, hace en él la instalación de la aplicación y, cuando todo es correcto, apunta el Load Balancer a este nuevo entorno. Es más lento y costoso, ya que tiene que levantar nuevas máquinas y tenemos un entorno duplicado durante el tiempo de despliegue, pero también mucho más eficiente ya que no dejamos ninguna instancia sin conexión (y por tanto el usuario tampoco lo estará).

• Environment configuration: aquí te pide que digas el grupo de Auto Escalado o las instancias que se usarán en el despliegue. Como hemos configurado previamente nuestro grupo de auto escalado, usaremos ese (sólo tenemos que seleccionarlo en el desplegable). Al seleccionarlo, aparecerán debajo las instancias disponibles en el grupo y su estado. También se deberá elegir en este apartado el Load Balancer que se usará. En nuestro caso, seleccionamos Classic Load Balancer y elegimos el nuestro en el desplegable.
• Deployment settings: este lo dejamos por defecto, de manera que una vez estén hecho todos los test en el nuevo entorno se redirija el tráfico automáticamente, y se eliminen las instancias del grupo de Auto Escalado previo cuando todo esté correcto.
• Advanced/Service Role: Por último, debemos asignar el Rol IAM que generamos para CodeDeploy a nuestra aplicación (en nuestro caso buscamos en el desplegable PostCodeDeployRole).

Creación del fichero appspec.yml

Para terminar, necesitamos añadir un fichero especial que usa AWS CodeDeploy para gestionar el despliegue. Este fichero tiene el nombre de appspec.yml, y debe estar situado en la raíz de nuestro proyecto.
La estructura de este fichero es la siguiente

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/demo-project
permissions:
  - object: /
    pattern: "**"
    owner: ubuntu
    group: ubuntu
hooks:
  BeforeInstall:
    - location: scripts/installDependencies.sh
      timeout: 300
      runas: ubuntu
  ApplicationStop:
    - location: scripts/stopServers.sh
      timeout: 300
      runas: ubuntu
  ApplicationStart:
    - location: scripts/startServers.sh
      timeout: 300
      runas: ubuntu

Revisando las distintas secciones del fichero es importante destacar las siguientes:

• files: donde se indica el origen y el destino de los ficheros de nuestra aplicación.
• permissions: donde se definen los permisos que tendrán los ficheros de nuestra aplicación
• hooks: donde se indican los scripts que se ejecutarán en cada uno de los hooks de CodeDeploy (http://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html)

¡Listo! ¡Acabamos de configurar nuestra primera aplicación en AWS CodeDeploy!
En la próxima entrega de esta serie en el blog de Secmotic, veremos cómo configurar nuestro sistema de Integración Continua para usar AWS CodeDeploy para el Despliegue Continuo.