BKT en Producción: Code Deploy

Este artículo continua con la serie BKT en Producción.

La variedad de servicios de AWS es enorme. Desde el primer día que vi el tablero inicial de AWS hasta hoy, su oferta de servicios no me deja de asombrar. Hay gran variedad en oferta y funcionalidad. De una u otra forma cubren muchos aspectos del ciclo de vida del desarrollo de software.

Code Deploy es un servicio de AWS que conocí por azares del destino. Estaba investigando cómo hacer un despliegue con Jenkins y encontré una integración entre ambos. Si bien AWS también tiene su servicio tipo Jenkins, solo opté por Code Deploy por que ya entendía un poco sobre la herramienta open source.

¿Qué es Code Deploy?

En pocas palabras, Code Deploy es un servicio para desplegar software web en máquinas EC2 y contenedores (mediante Fargate). Para hacerlo se vale un archivo de configuración que se agrega al repositorio de código y mediante el agente de CodeDeploy que debe instalarse en cada máquina o en la AMI.

Tiene la gran ventaja de que permite coordinar despliegues de mejor forma que si lo hicieramos, por ejemplo en aplicaciones Ruby on Rails, con Capistrano. Cuenta con mecanismos para hacer seguimiento a cada despliegue y ser capaces de revertir si algo va mal o en caso de que sea necesario.

Una de sus fortalezas es permitir el despliegue mediante la técnica o concepto de Azul y Verde. Donde el despliegue se hace a una flotilla de servidores que está en espera, cuando termina se levantan dichas máquinas y se conectan al balanceador de carga y las que se encontraban en ejecución pasan a estar en modo espera. Así casi que será imperceptible para los usuarios.

Algunas Cosas que Viví con Code Deploy

Lo primero, es esta presentación con la que obtuve un poco más de contexto y entendimiento sobre Code Deploy. Es bastante breve pero concisa y muestra casi que todo lo que se puede hacer con el servicio.

Error de Archivos Existentes

Otra cosa que me pasó y para la cual tuve que investigar bastante y que a día de hoy aún no se soluciona es la sobre escritura de archivos existentes en un despliegue.

Cuando se hace un despliegue, es común tener una carpeta definida donde caerán los archivos nuevos y se actualizarán los viejos (esto pensando en VPS). Por alguna razón, el agente CodeDeploy instalado en el servidor no sobre escribe sino que arroja un error al intentar pegar archivos o carpetas existentes en el destino:

2015-06-13 20:58:40 ERROR [codedeploy-agent(7589)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Error during perform: RuntimeError - File already exists at location /var/www/html/index.html - /opt/codedeploy-agent/lib/instance_agent/plugins/codedeploy/installer.rb:113:in

En el GitHub issue donde se discute este error (aún a día de hoy) hay varias formas de solucionar eso. La mejor es usando rsync .

Al final, el haber usado rsync me llevó a mejorar mis scripts de despliegue los cuales terminaron siendo más prácticos, sencillos y eficientes. En una próxima entrada los describiré con más detalle.

Error de Rol Invalido

En un mini proyecto de ese entonces, también configuré Code Deploy para el despliegue. Para mi ingrata sorpresa encontré este error:

InvalidRoleException: Cannot assume role provided

El cual debía ser arreglado en IAM actualizando el Trust Relationship de la cuenta que daba permisos de acceso al API.

Versión equivocada:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "codedeploy.us-east-1.amazonaws.com",
          "codedeploy.us-west-2.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Versión funcional:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "codedeploy.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Enviando Notificación de Despliegue a Slack

Finalmente, para lo que nacieron las lambdas(?): enviar notificaciones a Slack.

AWS también tiene oferta de lo que llaman Serverless o funciones lambdas. Con estas se puede hacer un puente para notificar a un espacio de trabajo en Slack cuando un despliegue falló o no.

Los pasos en ese entonces (tal vez ahora sea más fácil) a muy groso modo:

Con eso debería bastar. Toca probar y ajustar donde haga falta.

Si necesitas entender qué hay en lo que envía SNS a la Lambda, en este gist se ve el JSON con todo lo requerido para hacerlo funcionar o entender.

Es así como mediante el proyecto BKT aprendí sobre Code Deploy y en el camino otros servicios más que ofrece AWS.

Autor: cesc1989

Ingeniero de Sistemas que le gusta escribir y compartir sobre recursos que considera útiles, además que le gusta leer manga y ver anime.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .