Provisionar nodos slave de jenkins dinámicamente gracias a aws spot fleet.

Hace unas semanas, un cliente contactó con el equipo de Geko Cloud. Su petición era simple: ¿Qué podemos hacer para optimizar aún más nuestro proceso automatizado de CI/CD en Jenkins?

Tras estudiar cuidadosamente las necesidades y la infraestructura actual del cliente, nos decidimos por cambiar de paradigma en cuanto a ejecución de tareas se refiere. Hasta ahora Jenkins ejecutaba las tareas en su nodo principal (La máquina en la que se está ejecutando Jenkins), al cambiar este paradigma a uno basado en el aprovisionamiento dinámico de nodos subordinados ganaríamos los siguientes beneficios:

• Ahorro de costes – Al mover todo el esfuerzo computacional de la compilación fuera del nodo principal. Este puede estar alojado en una maquina de menor rendimiento, y por lo tanto menor coste. Los nodos subordinados solo estarían en funcionamiento durante la ejecución de una tarea, ahorrando también dinero mientras no se ejecuta ninguna tarea.
• Seguridad – Al no ejecutar ningún tipo de código en el nodo principal, aseguramos su integridad aunque el código haya sido comprometido, y como este solo se ejecuta en una instancia efímera el atacante estará aislado.
• Rendimiento – El nodo subordinado existe solamente para ejecutar la tarea y puede dedicar todos los recursos del nodo para ella.

Requisitos

Para este cambio, realizaremos las siguientes tareas:

• Creación de Spot Fleet en AWS
• Instalación y configuración del plugin de Jenkins
• Adaptación de Jenkinsfile

Para esta publicación haremos las siguientes suposiciones:

• Contamos con una cuenta de AWS configurada
• Alojamos Jenkins en un servidor EC2
• Contamos con conocimiento sobre algunos conceptos base de Jenkins y AWS

Dicho esto, pongámonos manos a la obra.

En este artículo sobre «Nodos dinámicos en Jenkins vía AWS Spot Fleet» desarrollaremos todos los pasos necesarios para poder obtener un buen resultado.

Creación de launch template y spot fleet

Un Spot Fleet de AWS no es más que un AutoScaling Group de máquinas EC2 pero con instancias de tipo spot – excedente de Amazon que nadie está usando y que AWS deja a un precio económico. El primer paso consistirá en la creación de el Launch Template que utilizara el Spot Fleet:

Los puntos importantes a rellenar serán:

1. Nombre y descripción
2. AMI a usar – Por ejemplo Ubuntu 22
3. Tipo de instancia a usar – Elegir una adecuada al desempeño
4. Key Pair – Lo necesitaremos introducir mas adelante en Jenkins
5. Network – Utilizar la misma Subnet que Jenkins si es posible
6. Security Group – Para que se establezca la conexión entre nodos, es importante que demos acceso al puerto 22 desde el nodo principal. La manera mas fácil es crear una regla que permita el acceso o bien desde la IP del nodo principal (Si la tenemos estática) o desde su Security Group
7. Storage – Asignar el almacenamiento que vayamos a necesitar
8. User data – Para que el worker de Jenkins se ejecute en el nodo subordinado, tendremos que instalar JRE, nosotros además instalamos Docker como requisito:

#!/bin/bash
# Install docker
apt-get update
apt-get install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
apt-get update
apt-get install -y docker-ce
usermod -aG docker ubuntu

# Install docker-compose
curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

#Install JRE
sudo apt install -y default-jre

Una vez creado tendremos un Launch template parecido a este:

Ahora es momento de crear el Spot fleet como tal:

En este caso, los puntos a rellenar son:

1. Launch parameters – Seleccionar nuestro Launch Template creado arriba
2. Target Capacity – Asignar total a 0 por ahora, ya que lo controlará el plugin de Jenkins. Habilitar Maintain Target Capacity
3. Network – Asignar la VPC en la que está alojado el nodo principal
4. Instance type requirements – Elegir los tipos de instancia deseados en Manually select instance types, una mayor cantidad da una mejor pool entre la que iniciar instancias Spot
5. Allocation strategy – Capacity Optimized

Y listo, ya tenemos creado nuestro Spot Fleet.

Instalacion y configuracion del plugin de Jenkins

Antes de instalar el plugin, tendremos que crear y asignar un nuevo rol de IAM a la instancia que aloja el nodo principal para que sea capaz de administrar nuestro Spot fleet:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "ec2:DescribeSpotFleetInstances",
            "ec2:ModifySpotFleetRequest",
            "ec2:CreateTags",
            "ec2:DescribeRegions",
            "ec2:DescribeInstances",
            "ec2:TerminateInstances",
            "ec2:DescribeInstanceStatus",
            "ec2:DescribeSpotFleetRequests"
         ],
         "Resource":"*"
      },
      {
         "Effect":"Allow",
         "Action":[
            "autoscaling:DescribeAutoScalingGroups",
            "autoscaling:UpdateAutoScalingGroup"
         ],
         "Resource":"*"
      },
      {
         "Effect":"Allow",
         "Action":[
            "iam:ListInstanceProfiles",
            "iam:ListRoles",
            "iam:PassRole"
         ],
         "Resource":"*"
      }
   ]
}

Una vez hecho esto, instalaremos el plugin ec2-fleet-plugin y nos dirigiremos a configurar desde Administrar Jenkins > Administrar nodos > Configure Clouds > Añadir nueva nube > Amazon EC2 Fleet.

1. Asignamos un nombre
2. AWS Credentials – Lo dejamos en blanco, ya que nuestra maquina ya tiene el rol descrito más arriba
3. Region – Seleccionamos la región en la que alojamos nuestros servidores.
4. EC2 Fleet – Solo aparecerá cuando asignemos la región y el rol esté asignado a la máquina correctamente. Una vez rellenado, seleccionamos nuestro Spot fleet
5. Subimos la Private key generada en el Launch template como SSH Username with private key
6. Private IP – Seleccionar si queremos que el nodo maestro se conecte al subordinado usando la IP privada en vez de la publica
7. Always Reconnect – Recomendamos no habilitarlo, ya que las instancias Spot son efímeras por naturaleza
8. Restrict Usage – Restringirá el uso de este Spot Fleet solo a tareas que indiquen la etiqueta asignada, indistintamente de la configuración global de Jenkins
9. Label – La etiqueta que identifica esta nube de nodos, útil para asignar qué tareas se ejecutarán en el Fleet
10. Number of executors – La cantidad de trabajos simultáneos que podrá albergar cada instancia del Spot Fleet
11. Max Idle Minutes Before Scaledown – La cantidad de minutos que Jenkins mantendrá una instancia activa sin tareas pendientes. Si se deja a 0 Jenkins jamás apagará instancias, aunque estén sin uso
12. Minimum/Maximum cluster Size – El tamaño mínimo y máximo de instancias que queremos que tenga el Spot fleet. Lo ideal es dejar el mínimo a 0 para abaratar costes

Una vez guardada la configuración, tendremos una nueva sección en el dashboard de Jenkins, que nos indica el estado actual de nuestro Spot Fleet.

Adaptación de Jenkinsfile

Ahora que tenemos nuestro Spot fleet configurado, es hora de realizar unos pequeños cambios para que Jenkins use este nuevo tipo de nodo a su disposición. Si queremos que se use de manera sistemática a nivel global, podemos deshabilitar la ejecución de tareas en el nodo principal (el único otro nodo en nuestro caso) desde la pantalla de configuración de nodos.

Si por el contrario, queremos que ciertas tareas sean las que se ejecuten en los nodos subordinados, tendremos que especificarlos a nivel de JenkinsFile, a continuación un ejemplo de cómo hacerlo:

#!groovy
pipeline {
//Especificamos agente a nivel de Pipeline
  agent {
    label 'ec2-fleet'
  }

  stages {
        stage('Test') {
          agent {
            dockerfile {
              // Si usamos un agente en concreto, tendremos que volver a especificar la etiqueta
              label 'ec2-fleet'
              filename 'Dockerfile'
              dir 'docker/images/tests'
              args '-u root'
            }
          }
          steps {
            sh 'Hello World'
          }
        }
  }
}

Con este último paso, estamos listos para ejecutar cualquier tarea en nodos provisionados dinámicamente dentro de instancias Spot Fleet.

Desde Geko Consultoría Cloud, esperamos que este post te hayan gustado y sobre todo que te resulten útiles, nada nos alegraría más.
Te invitamos a que si necesitas información sobre el mundo Cloud y DevOps, nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles.

La entrada Nodos dinámicos en Jenkins vía AWS Spot Fleet se publicó primero en Geko Cloud.

Recuperar una IP elástica de AWS. Quizás no sea lo más habitual para el usuario promedio de AWS, pero para los que se dedican al sector cloud es corriente administrar varias cuentas de AWS. Ya sea mediante un catálogo de enlaces de login o mediante un listado de IDs de cuentas (y sus correspondientes credenciales), o mediante un gestor de impersonación de roles; el caso es que antes o después puede suceder que por error se confunda una cuenta con otra, y se termine realizando una acción no deseada.

Este es el caso que se expone hoy, en el que se estaba trabajando con una cuenta nueva, y en el que toda la infraestructura creada era de usar y tirar. Sucedió que por error se confundió esta cuenta con la cuenta base, la de Geko, donde se aloja la IP elástica que apunta al bastión de la compañía. Sí, efectivamente, ese punto clave que se usa para acceder a otras infraestructuras de manera segura, y que precisamente estas otras infraestructuras consideran seguro. Es decir, esa IP era usada como una de las medidas de seguridad a la hora de verificar la procedencia de las conexiones. Una IP que se encontraba en múltiples configuraciones, y que no era trivial cambiar. Pues bien, dicha IP se liberó por error. En AWS se emplea la palabra «liberar» (o «release» en Inglés) para referirse a la acción de eliminarla de una cuenta, dejándola disponible para el resto de usuarios del proveedor.

No hace falta describir los momentos de máxima alerta que sucedieron a la liberación de la IP, pero la posibilidad de haber perdido esa dirección para siempre porque se hubiera asignado a otro usuario, comenzaba a apoderarse de la tensión del momento. Sin embargo, para algo están los gabinetes de crísis y, por encima de todo, para algo está el poder contar con un equipo de profesionales del sector. La lluvia de ideas empañaba las ventanas cuando, de repente, un fulminante rayo de esperanza hizo que todo se parase en seco. Había esperanza. AWS había previsto este catastrófico caso, y Geko encontró como recuperar lo que siempre había sido suyo, pero que nunca había valorado tanto.

¿Te ha pasado? ¿Quieres saber cómo se solucionó? ¡Sigue leyendo y no te pierdas cómo terminó esta épica historia!

Recuperar la IP elástica de AWS que se ha borrado por accidente

Recuperar una IP elástica de AWS. Como se comentaba anteriormente, una vez se libera una dirección IP elástica ésta pasa a formar parte del grupo de IPs disponibles para el resto de usuarios, por lo que recuperarla podría llegar a ser imposible si se diese el caso de que ya hubiera sido reasignada. Sin embargo, AWS se dio cuenta de que esto podría representar un problema, y estableció un método de recuperación para este escenario. Aunque no es algo que se pueda realizar desde la consola web, recuperar la dirección IP perdida se puede realizar mediante un único comando.

MY_IP=48.151.62.342
aws ec2 allocate-address --domain vpc --address $MY_IP

Si bien es cierto que es necesario conocer la dirección IP a recuperar, si es crítica como para necesitar recuperarla, debería ser algo que se pueda averiguar.

¿Qué más podría salir mal?

Se da la casualidad de que en este caso había un factor adicional que podía entorpecer las cosas, y de hecho lo hizo. En Geko, para disponer de credenciales para el CLI de AWS, se generan unas claves temporales después de pasar por un proceso de verificación multi-factor (que además pueden ser revocadas en cualquier momento), y dichas credenciales se obtienen mediante el bastión anteriormente mencionado. Atando cabos se puede concluir que la situación había caído en una dependencia cíclica, ya que para arreglar el problema eran necesarias credenciales que el propio problema no permitía crear. Por supuesto existían métodos alternativos para salir del bucle, pero finalmente fue suficiente con usar unas credenciales aún no caducadas.

Conclusión

A lo largo de esta corta (pero intensa) historia se ha visto la importancia de contar con el equipo que tienes a tu alrededor. Dejar a un lado el orgullo y dar la voz de alarma fue lo que consiguió que la solución apareciese en cuestión de minutos. Como se suele decir, dos pares de ojos ven más que uno.

Por otra parte, aprendimos y reforzamos una serie de buenas prácticas que podrían ser la clave la siguiente vez. Las enumeramos a continuación.

1. Asegúrate de tener unas credenciales de emergencia para el caso de que suceda algo en el bastión.
2. Asegúrate de que la cuenta que estás tratando de modificar, es la que de verdad quieres modificar. Es mejor perder un poco de tiempo en comprobar las cosas dos veces, que lamentarse luego.
3. Protege los recursos valiosos a toda costa, como por ejemplo creando políticas de IAM para denegar cualquier acción dañina.

Desde Geko Consultoría Cloud, esperamos que este artículo te haya servido de ayuda para aprender algo nuevo y seguir ampliando tus conocimientos. Te invitamos a que si necesitas información sobre el mundo Cloud y DevOps, nos contactes y sigas revisando nuestro blog para encontrar otras publicaciones útiles. ¡Hasta la próxima!

La entrada Cómo recuperar una IP elástica de AWS que se ha borrado por accidente se publicó primero en Geko Cloud.

Logs de AWS SES a Opensearch mediante AWS Kinesis.
Por defecto, el servicio de AWS Simple Email Service (SES) no nos ofrece poder visualizar logs de sus acciones/eventos, tan solo podemos ver algunas métricas en Cloudwatch. Desde Geko nos hemos encontrado más de una vez con la necesidad de ver logs de SES, ya sea para diagnosticar incidencias o para conocer mejor el estado del servicio. Pues bien, para que esto sea posible, hacemos uso de AWS Kinesis. Vamos a explicar como lo montamos. Empecemos!

Configuración en Kinesis

Kinesis es un recolector, procesador y transmisor de datos. El primer paso es crear un Delivery Stream. Accedemos al servicio de Kinesis, Delivery Streams y creamos un Delivery Stream

En «Source» eleccionamos «Direct PUT» y en Destination «Amazon OpenSearch Service». Existen otras opciones de destino como Redshift, S3, Dynatrace.. En el desplegable aparecen todas las disponibles.

Añadimos un nombre al objeto «Delivery Stream» y añadimos nuestro OpenSearch. En nuestro caso, al ya tener un OpenSearch creado y operativo simplemente accediendo a «Browse» nos ha aparecido para seleccionarlo.

Ponemos el nombre de índice que queremos que nos cree

Y por defecto nos selecciona VPC, Subnet y Security Group en base a nuestro OpenSearch.

Finalmente creamos el objeto «Delivery Stream»

Configuración SES

Ahora accedemos al servicio SES, accedemos a «Configuration Sets» y «Create Set»

Ponemos un nombre al «Configuration Set» y lo creamos.

Una vez creado el «Configuration Set» vamos a «Event Destionation» y «Add Destination» para crear uno.

Seleccionamos el tipo de evento que queremos y vamos al siguiente paso

Seleccionamos «Amazon Kinesis Data Firehose», ponemos un nombre y seleccionamos el «Delivery Stream» que hemos creado anteriormente.

Cuidado! Ahora hay que crear un «IAM Role» para que SES pueda escribir en Firehose, nosotros lo hemos creado así:

Con esta Policy

Y esta Trust Relationship

Finalmente creamos la «Configuration Set»

Ahora, para testearlo, se puede enviar un email de test desde SES asignando a nuestro test la «Configuration Set» que hemos creado. Esta «Configuration Set» se puede aplicar a cualquier Identity que tengamos en SES. De hecho vamos a hacer una prueba enviado un email de test. Vemos el log de test que hemos generado en nuestro OpenSearch:

Y en el monitoring de Delivery de Kinesis:

Desde Geko esperamos que si has llegado hasta aquí, esta entrada sea justo lo que andabas buscando! Te invitamos también a que leas otros de nuestros posts de labs.

La entrada Logs de AWS SES a Opensearch mediante AWS Kinesis se publicó primero en Geko Cloud.

Hoy en día, millones de organizaciones están aprovechando los servicios en la nube de AWS para crear aplicaciones sofisticadas que les ayudan a aumentar su fiabilidad, flexibilidad y escalabilidad. Este post sobre «¿Qué es AWS?» está diseñado para ayudarte a comprender en profundidad esta popular plataforma en la nube, sus ventajas, servicios y mucho más.

¿Qué es y para qué sirve AWS?

Amazon Web Services (AWS) es una plataforma de servicios de nube que ofrece una mezcla de paquetes de software como servicio (SaaS), plataforma como servicio (PaaS) e infraestructura como servicio (IaaS), desde decenas de centros de datos y múltiples zonas de disponibilidad (AZ) repartidas por regiones del mundo. Cada AZ contiene varios centros de datos. Los clientes pueden configurar máquinas virtuales y replicar sus datos en varias zonas de disponibilidad para disponer de un sistema altamente resistente al fallo de un servidor o centro de datos.

AWS tiene como objetivo permitir a las organizaciones crecer y obtener beneficios a través de su amplia gama de servicios. Gracias a esta plataforma, pueden almacenar, acceder y gestionar los datos de su empresa al tiempo que los protegen de accesos no autorizados. 

¿Qué servicios/productos ofrece AWS?

Dentro de todos los servicios que ofrece AWS encontramos diversos productos cloud computing, base de datos, blockchain, integración de aplicaciones, internet de las cosas, migración y transferencia, redes y entrega de contenido, y muchos más. Algunas de las tecnologías más utilizadas de Amazon Web Services son:

1. Amazon EC2

La interfaz web de Amazon EC2 se utiliza para reducir los costosos servidores físicos mediante la creación de máquinas virtuales y administración de otras características de los servidores, como su almacenamiento, seguridad, puertos, etc. Con Amazon EC2 podrás crear servidores en cuestión de minutos con tu sistema operativo preferido.

2. Amazon RDS
Amazon nos ayuda en todo lo que puede para que nuestra infraestructura sea menos complicada, es por esto que nos provee el servicio de RDS. Al utilizar este servicio de AWS, se pueden crear instancias dedicadas de bases de datos en cuestión de minutos, totalmente administradas por el equipo de soporte de AWS y capaz de soportar múltiples motores de bases de datos como MySQL, PostgreSQL, SQL Server, MariaDB, y muchos más.

3. Amazon Simple Storage Service (S3)
Amazon S3 es el servicio principal de AWS para el almacenamiento y recuperación de archivos mediante un API (Application Programming Interface). Amazon S3 ofrece un servicio de almacenamiento de archivos y también de integraciones de alta calidad como PCI-DSS, HIPAA/HITECH y FedRAMP para que los datos no sean comprometidos. Además, el servicio S3 te ofrece distintos tipos de almacenaje para optimizar el coste.

4. Amazon CloudFront
Amazon CloudFront te ayuda a mejorar la velocidad del sitio web y el acceso a los datos que se encuentran en la nube. Además, gestiona todo el contenido de los usuarios de manera eficaz a través de un servicio de entrega de contenido global.

5. Amazon VPC
Si está listo para aislar toda su infraestructura de TI de la exposición, entonces la única manera de hacerlo es con Amazon VPC. Este servicio crea una red virtual privada a la que no puede acceder nadie ni nada excepto las personas y los sistemas que se autorice. Estas redes están lógicamente aisladas de otras redes virtuales en las nubes de AWS.

6. Amazon SNS
SNS es un Servicio de Notificación Simple que alerta a los servicios de los suscriptores para que realicen tareas automáticamente en respuesta a desencadenantes especificados. Amazon SNS es un sistema de notificaciones que ofrece integración con cualquier tipo de aplicación, llámese PHP, Python, Node, etc; y las notificaciones pueden ser enviadas a todo tipo de usuarios ya sea en la web o en el móvil.

7. AWS Lambda
¿Tu servidor se satura con muchas requests? AWS Lambda está diseñado para escalar, y así soportar cualquier carga de tráfico. Posiblemente sea uno de los servicios más innovadores de AWS, puesto que te permite ejecutar tu código de forma serverless, es decir, sin necesidad de gestionar servidores. Además, es compatible con los principales lenguajes de programación como Node.js, Python, Java, y más.

8. AWS Autoscaling
Si estás pensando en crecer o expandir tu aplicación para millones de usuarios entonces AWS Autoscaling es la solución. Esta herramientas permite administrar una flota de servidores cuando la aplicación lo demande, creándose múltiples instancias cuando se necesitan. El servicio es gratuito, únicamente se cobra por el número de instancias utilizadas.

9. AWS Beanstalk
AWS Beanstalk se creó para ayudar a los desarrolladores a administrar la infraestructura del sitio web y ahorrar tiempo. Esta herramienta automatiza la instalación, la configuración y el aprovisionamiento de otros servicios de AWS como EC2, RDS y S3.

Como ves, AWS dispone de una gran cantidad de servicios relacionados con la infraestructura en la nube, relacionada con los datos y el aprovechamiento de estos de cara a cualquier negocio, de cualquier tamaño y sector. Si quieres conocer más sobre todos los productos que ofrece AWS en el siguiente enlace obtendrás toda la información: Beneficios de cloud computing | Seguridad en la nube | AWS (amazon.com)

Ventajas de utilizar AWS

Muchas empresas, pequeñas o grandes, confían en AWS por el amplio abanico de servicios que ofrece. A continuación explicaremos algunas de las ventajas más destacables que lo diferencian de otras empresas. Estas son:

SEGURIDAD
La seguridad es uno de los puntos más importantes a la hora de trabajar en entornos cloud. AWS cuenta con docenas de centros de datos en todo el mundo que se supervisan continuamente, las 24 horas del día, los 7 días de la semana, y reciben un mantenimiento estricto. Además, AWS dispone de certificaciones y acreditaciones, cifrado de datos en reposo y en tránsito, módulos de seguridad hardware y una fuerte seguridad física.

PAY PER USE
Una de las ventajas más importantes es el modelo de facturación de pago por uso de AWS. No hay un coste inicial para construir un sistema de almacenamiento y no es necesario estimar el uso. Para las organizaciones que tienen picos diarios o estacionales, esto es una verdadera ventaja.

AMPLIA VARIEDAD DE SERVICIOS
AWS con el tiempo ha ido ampliando su gama de productos y servicios hasta tener más de 175 productos que van desde el almacenamiento y la computación básicos hasta los servicios más especializados como por ejemplo la robótica. En resumen, AWS ofrece una variedad tan amplia de servicios que seguramente algún producto o servicio encaje perfectamente a las necesidades de tu empresa.

COST-EFFECTIVE
Tanto si se trata de una start-up como de una gran organización empresarial, podrás beneficiarte de las ventajas económicas que ofrece AWS, como por ejemplo, que no se requiere pagar por adelantado para utilizar sus servicios o recursos.

GLOBAL LEADER
Amazon Web Services cuenta con redes en casi 190 países de todo el mundo y da soporte a más de un millón de clientes activos. Entre sus clientes se encuentran grandes empresas y organizaciones del sector público. A medida que las empresas siguen migrando al cloud, las alternativas de servicios basados en la nube siguen multiplicándose. Sin embargo, sólo un puñado de opciones logran satisfacer las diferentes necesidades empresariales que existen como Amazon Web Services (AWS).

¿Cómo funciona AWS?

Primero de todo, necesitas registrarte en AWS. Cuando vayas a crearte la cuenta, te pedirán los detalles de la tarjeta de crédito. Una vez creada la cuenta, puedes empezar a explorar la consola de gestión de AWS y ver sus servicios. Además, en Amazon puedes ver tutoriales de 10 minutos para conocer el funcionamiento de cada uno de sus productos.

AWS y Geko Cloud

Esperamos que este post te haya ayudado a entender un poco más qué es Amazon Web Services. Como ves, AWS es algo que debes de tener en cuenta si te estás planteando migrar a la nube tu infraestructura.

En Geko Cloud somos expertos cloud y trabajamos con metodología DevOps, acompañando a nuestros clientes en todo el proceso desde la migración hasta la gestión en el cloud. ¡Contáctanos sin ningún compromiso!

La entrada ¿Qué es AWS? se publicó primero en Geko Cloud.

Introducción

En este post vamos a ver cómo solucionar el siguiente error que nos encontramos al trabajar con bases de datos MySQL utilizando el servicio EFS de AWS para el almacenamiento:

ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine

Situación de partida

Nuestro caso de uso consistía en un cluster de Kubernetes EKS, en el que necesitábamos crear y destruir nuevos entornos para desarrollo lo más rápido posible. Cada uno de estos entornos debían contener varias bases de datos MySQL, además de otras herramientas como Redis, RabbitMQ, etc.

Para ello decidimos utilizar Charts de Helm que levantasen estas herramientas como StatefulSets. En un primer momento, no especificamos ningún StorageClass, por lo que se utilizaba la de por defecto de EKS, que levanta volúmenes EBS gp2 (General Purpose SSD) al crear los PersistentVolumeClaims.

El problema de usar volúmenes EBS, es que cada volumen se encuentra disponible en una zona de disponibilidad concreta, por lo que si el cluster de Kubernetes necesita mover un pod de, por ejemplo, MySQL, no podrá levantarlo a no ser que encuentre recursos disponibles en otro nodo worker que este en la misma zona de disponibilidad que dicho volumen EBS.

Por este motivo, decidimos utilizar un nuevo StorageClass que utilizase EFS en lugar de EBS. De esta forma, teniendo el EFS montado en cada nodo worker del cluster de Kubernetes, los pods podían moverse sin ningún problema entre nodos, aunque estos estuviesen en distintas zonas de disponibilidad.

Error con EFS

Dado que nuestro caso de uso requería crear nuevos entornos de la forma mas rápida posible, al levantar una nueva base de datos MySQL, también ejecutábamos un importado de datos a partir de ficheros sql para disponer de un set de datos inicial por defecto.

Fue en este momento en el que empezamos a detectar el error, ya que al importar estos datos iniciales, empezamos a ver de forma continuada el siguiente error en los logs:

ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
ERROR 1030 (HY000) at line 1744: Got error 168 from storage engine
...

Este error comenzaba a aparecer a partir de un determinado número de instrucciones sql ejecutadas, y a partir de ese momento, se repetía hasta terminar de leer el fichero sql.

Resolución

Tras realizar una investigación, descubrimos que el problema residía en un límite del servicio EFS. Concretamente era el límite de 256 ficheros únicos bloqueados. Podemos ver este límite en las cuotas descritas en la documentación de AWS:

https://docs.aws.amazon.com/efs/latest/ug/limits.html#limits-client-specific

Debido a que nuestro importado de datos intentaba crear más de 256 tablas, este límite se alcanzaba y comenzaba a aparecer el error. Este límite no puede modificarse, pero pudimos evitarlo modificando los parámetros de MySQL para, en la medida de lo posible, no alcanzar esos 256 ficheros bloqueados.

El parámetro MySQL a modificar es innodb_file_per_table. En nuestras bases de datos MySQL, este parámetro venía activado por defecto. Esto hace que se cree un fichero de datos .idb por cada tabla de la base de datos en lugar de crear un solo fichero de datos. Podemos modificar este parámetro en el fichero de configuración de MySQL de la siguiente forma:

[mysqld]
innodb_file_per_table=OFF

https://dev.mysql.com/doc/refman/5.7/en/innodb-file-per-table-tablespaces.html

Tras desactivar este parámetro, no volvimos a encontrarnos con el error.

Queremos agradecer al blog ops.tips su trabajo realizando el post que os enlazamos, ya que nos ayudó mucho a entender este error, de forma que pudimos encontrar esta solución.

https://ops.tips/blog/limits-aws-efs-nfs-locks/

Conclusión

Al trabajar con bases de datos MySQL usando EFS para el almacenamiento, podemos encontrarnos errores al alcanzar el límite de 256 ficheros bloqueados siempre que tengamos esquemas con gran cantidad de tablas o en definitiva cualquier sistema que requiera bloquear simultáneamente grandes cantidades de ficheros como por ejemplo seria el caso de MongoDB, Oracle, etc.

Para evitar alcanzar ese límite, podemos desactivar el parámetro de MySQL innodb_file_per_table para que no se cree un fichero de datos por cada tabla.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otros posts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Error al utilizar AWS EFS para MySQL se publicó primero en Geko Cloud.

Introducción

Migrar al cloud es cada vez más común y ventajoso para la mayor parte de empresas que operan en Internet, dado que ofrece ventajas como la escalabilidad, agilidad, reducción de costes, disponibilidad, etc. Pero, a la hora de decidir proveedor cloud, ¿cómo decidimos cuál es más conveniente?

Vamos a hablar de los proveedores más populares, que ofrecen un servicio con ciertas similitudes pero funcionan bajo esquemas distintos, son AWS (Amazon Web Services) y Microsoft Azure, siendo estos los más elegidos por las empresas que quieren dar el salto a la nube. Pero a la hora de elegir, se ha de tener en cuenta las ventajas y ofertas de servicios de cada uno aplicado a nuestra estrategia de negocio.

Breve comparación entre AWS y Azure

Entraremos solo a comparar dos detalles que pueden ser fundamentales para esta elección, la inversión y los recursos que tiene cada uno de estos dos proveedores.

• La inversión es una de las principales incógnitas de la ecuación cuando vamos a migrar a la nube, como cualquier cambio que decidimos hacer en la empresa. El aumento de la oferta de proveedores cloud, lo que supone aumento de competencia, ha supuesto un abaratamiento y una adopción de pago por uso (PAYG), con el fin de ofertar la mejor opción al cliente. Algo que anteriormente se ofrecía bajo pago mensual. Lo que sí cambia es el modelo de pago:

• También podemos distinguir entre los recursos que ofrecen ambos proveedores:

Otras características a comparar entre AWS y Azure

• Amazon Web Services proporciona herramientas para dejar a un lado el hardware, licencias y costes añadidos, focalizándose en un modelo serverless.
• Por otro lado, Azure se enfoca en nubes híbridas aprovechando que los modelos on-premise funcionan mejor al tener licencia Microsoft.
• AWS ofrece producto de soluciones de machine learning automatizados.
• Azure también tiene productos de machine learning pero necesitan más desarrollo y puede ocasionar limitaciones para la adaptabilidad.
• La escalabilidad y la flexibilidad sin un mínimo de consumo es una de las ventajas de AWS.
• En el caso de Azure, cuenta con paquete de almacenamiento predeterminado.

Conclusión

Teniendo en cuenta las características mencionadas anteriormente y otras que podemos encontrar para realizar una comparación entre AWS y Azure, podemos establecer los siguientes motivos para elegir un proveedor u otro:

• ¿Por qué elegir AWS?

Si tu empresa necesita aumentar notablemente su escalabilidad, tiene flexibilidad en modelos de pago y necesita de consultoría para migrar a la nube sí o sí.

• ¿Por qué elegir Azure?

Si tu empresa ya utiliza o tiene relación con Microsoft y, además, necesita una infraestructura robusta y muy segura.

En Geko te ayudamos a migrar al cloud

Si buscas un proveedor de servicios que migre o gestione tu plataforma en la nube, no dudes en consultar con nosotros, en Geko elegimos el proveedor que más se adapte a tus necesidades o tecnologías, y adaptamos la consultoría DevOps a tus metodologías de trabajo.

¡Contáctanos sin compromiso!

La entrada AWS vs Azure, cuál elijo para migrar al cloud se publicó primero en Geko Cloud.

Los módulos en Terraform son una colección de recursos que se pueden vincular o simplemente crear individualmente. Cuando llamamos a un módulo, estamos llamando a un archivo con una serie de recursos y algunos parámetros, los cuales necesitamos especificar o bien en el propio recurso o en otro archivo que almacene nuestras variables.

¿Por qué usar Terraform?

• Es una herramienta muy útil para desarrollar, cambiar y tener un versioning de nuestra infraestructura de manera eficiente y segura.
• Es una herramienta que permite definir infraestructura como código y habilita cambiar y hacer un seguimiento de la infraestructura con facilidad.
• Es independiente de la plataforma o ‘cloud agnostic’ y permite trabajar con múltiples proveedores cloud.

¿Qué necesitamos para este lab?

• Terraform instalado. En este caso, ejecutamos la v.0.12.7.
• En nuestro caso, utilizamos AWS como nuestro proveedor de servicios en la nube, por lo que necesitamos un usuario con acceso mediante programación. También necesitamos dar acceso a este usuario con la Política de IAM adecuada.
• Tu editor de código preferido.

¡Empecemos!

Por lo general, primero deberíamos configurar un módulo Terraform con nuestros parámetros requeridos o simplemente obtener algún módulo oficial de la red. En nuestro caso, estamos usando un módulo propio con un Bucket S3 y su propia política y, por lo tanto, especificamos qué parámetros queremos en nuestro módulo.

resource "aws_s3_bucket" "this" {
  bucket            = var.bucket_name
  acl               = var.type_acl
  force_destroy     = var.destroy

  tags = {
    Name            = var.tag_name
  }
  versioning {
    enabled         = var.versioning
  } 
}

resource "aws_s3_bucket_policy" "this" {
  bucket = var.bucket_name
  policy = templatefile("${path.module}/templates/s3_origin_access_identity.json", {
    origin_access_identity_arn         = aws_cloudfront_origin_access_identity.this.iam_arn,
    origin_access_identity_bucket_name = var.bucket_name
  })
}

Como veis, hay algunos valores que los introducimos con variables por lo tanto, necesitaremos un fichero llamado «variables.tf» en el cuál introduciremos los valores.

En la misma carpeta que tenemos nuestro archivo “main.tf”, creamos nuestro fichero “variables.tf”:

### S3 VARIABLES

variable "bucket_name"      { }
variable "tag_name"         { }
variable "type_acl"         { }
variable "versioning"       { }
variable "destroy"          { }
variable "aliases"          { }
variable "certificate_arn"  { }

En este caso particular, puede que os preguntéis por qué estas variables no tienen ningún valor almacenado. Y la respuesta es que estamos usando un archivo principal llamado «terragrunt.hcl» el cuál almacenará todos nuestros valores cuando llamemos al módulo.

Otra cosa que puede resultar confusa es cómo especificar la política del Bucket. Podemos especificarla o bien con un archivo heredoc (EOF) o directamente con una función de Terraform llamada «templatefile».

El primer ejemplo está en la documentación oficial de Terraform, una web que os sugiero visitar para entender el verdadero poder de los módulos y sus recursos.

En nuestro caso usamos el segundo ejemplo y necesitamos que en la misma carpeta, haya otra llamada «templates» y dentro de ella, la política del Bucket como un archivo JSON.

{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateS3Content",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "${origin_access_identity_arn}"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::${origin_access_identity_bucket_name}/*"
        }
    ]
  }

Como seguramente os habréis dado cuenta, hemos introducido varias variables ${origin_access_identity_arn} y ${origin_access_identity_bucket_name} y eso es porque así, introduciremos los valores desde fuera de esa política, desde el propio archivo ‘main.tf».

policy = templatefile("${path.module}/templates/s3_origin_access_identity.json", {
    origin_access_identity_arn         = aws_cloudfront_origin_access_identity.this.iam_arn,
    origin_access_identity_bucket_name = var.bucket_name
  })

Así, introducimos el arn llamando a otro recurso llamado «aws_cloudfront_origin_access_identity» y el nombre del bucket lo introducimos como hemos visto antes con nuestro archivo de variables.

Ahora solo necesitamos especificar el proveedor de Terraform y llamar al módulo con otro archivo que llamaremos «provider.tf» con los valores que hemos especificado:

provider "aws" {
  region     = var.region
  version    = "~> 2.0"
}

provider "aws" {
  alias  = "aws_us_east_1"
  region = "us-east-1"
}
module "s3" {
    source               = "../../../../../../modules/s3-cloudfront/"
    bucket_name          = var.bucket_name
    tag_name             = var.tag_name
    type_acl             = var.type_acl
    versioning           = var.versioning
    destroy              = var.destroy
    aliases              = var.aliases
    certificate_arn      = var.certificate_arn    
}

Y por último, desplegar nuestro módulo con los comandos terraform init, terraform plan y terraform apply.

Conclusión

En este post, hemos visto como desplegar un Bucket S3 con su respectiva política con Terraform. Os sugiero que visitéis la documentación oficial de Terraform para seguir aprendiendo sobre los módulos, recursos y sus parámetros.

También os invito a contactar con nosotros en caos de que necesitéis información acerca del mundo DevOps y no dudéis en seguir nuestro blog para descubrir otros posts útiles.

La entrada Una vista rápida de los módulos de Terraform se publicó primero en Geko Cloud.

Tenemos diferentes formas de usar estos volúmenes NFS en nuestros contenedores:

• En primer lugar, podemos crear un volumen que podremos usar tanto en docker compose como usando un docker run. Para esto usaremos el siguiente comando: 

    $ docker volume create --driver local 
        --opt type=nfs 
        --opt o=nfsvers=4,addr=nfs.example-domain.com,rw 
        --opt device=:/path/to/dir 
        volume-name

   Una vez que tenemos creado el volumen, podremos montarlo dentro de nuestro contenedor 

    $ docker run -it --rm 
      --mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,"volume-opt=o=nfsvers=4,addr=nfs.example-domain.com",volume-opt=device=:/host/path 
      volume-name

• Esta misma configuración podemos aplicarlas dentro de nuestro docker-comper. Dentro de nuestro docker-compose.yaml tendremos que crear el volumen y montarlo dentro de nuestro contenedor.

  # Container conf
    ...
    container-conf:
      container_name: foo/bar
      image: imagename:tag
      ports:
        - 80:80
      volumes:
        - new_volume:/path/inside/container
    ...
  # Create volume
    ...
    volumes:
      new_volume:
        driver: local
        driver_opts:
          type: nfs
          o: nfsvers=4,addr=nfs.example-domain.com,rw
          device: ":/host/path/to/dir"
    ...

  Esta misma situación nos la hemos encontrado teniendo la necesidad de montar al contenedor un EFS (Elastic File System) de Amazon Web Services. Este servicio de AWS proporciona almacenamiento escalable, elástico y concurrente y podremos añadirlo usando el mismo driver de NFS en docker.

  # Container conf
   ...
    container-conf:
      container_name: foo/bar
      image: imagename:tag
      ports:
        - 80:80
      volumes:
        - new_volume:/path/inside/container
   ... 
  # Create volume
   ...
    volumes:
      efs_volume:
        driver: local
        driver_opts:
          type: nfs
          o: addr=[EFS_DNS],nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2
          device: [EFS_DNS]:/
   ...

  Hay que tener en cuenta que si acabamos de crear este EFS, puede ser que cuando intentemos crear este volumen nos dé un error avisando de que no encuentra el endpoint de EFS. Esto se debe a que esas DNS tardaran unos minutos en propagarse. En el caso de que no podáis añadirlo mediante el endpoint, podremos hacerlo directamente desde la IP del EFS.

Esperamos que esta explicación te haya sido de utilidad y no olvides que en Geko cloud estamos a tu disposición para la gestión de infraestructuras cloud y microservicios.

Si tienes otras dudas relacionadas con docker o Kubernetes, quizá puedas encontrar respuestas en otras de las entradas de nuestro blog.

¡Hasta la próxima!

¡Contacta con nosotros y charlemos sobre cómo podemos ayudarte a hacer tu plataforma más ágil y segura!

La entrada Volúmenes NFS en contenedores Docker se publicó primero en Geko Cloud.

RDS es el servicio de BBDD gestionadas que ofrece AWS, con el que resuelven los principales problemas de gestión, operación y mantenimiento que comporta tener una plataforma de bases de datos relacional. Con RDS todo es muy sencillo, garantizas el servicio y la operativa permitiendo crecer y decrecer según necesidad.

Además, Amazon tiene su propio motor basado en Mysql, Aurora, que incluso permite tener una plataforma de base de datos serverless, de la cual hablaremos en otro post más adelante.

El escenario que enfrentamos

Un cliente, con su plataforma full basada en AWS, con todas sus BBDD relacionales usando RDS, manifiesta en una de sus plataformas problemas de rendimiento, caídas, comportamiento errante y poco predecible, etc.

Dicho problema no ocurre desde el inicio del proyecto, sino que en cierto momento empezó a degradar hasta convertirse en un problema real. Apreciamos que RDS estaba desplegado usando instancia de bursting T3, dónde los créditos parecían decrecer de forma periódica.

Se opta por cambiar la instancia al tipo M5 para tener un mejor rendimiento y disponibilidad de recursos, tras lo cual la performance mejora muy sensiblemente hasta que advertimos lo siguiente:

Las métricas siguen advirtiendo de que existe latencia de escritura/lectura y se encolan IOPS. ¿Cómo es esto posible en un disco SSD de uso general?

La métrica que para nosotros es importante seguir en cualquier RDS es la referente al Disk QueueDepth, esta métrica indica el tamaño de la cola que el sistema tiene en espera para ser procesada en operación IO de disco, es decir, la deuda en operaciones a disco que el sistema tiene. La latencia de disco de Read Write no es más que un espejismo de este hecho.

La solución

La explicación es simple, AWS RDS provisiona un total de 3 IOPS/Gb según el tamaño del disco EBS que se crea. La RDS del cliente se creó con 20Gb de tamaño total = 60 Provisiones IOPS , que AWS por defecto provisiona siempre un mínimo de 100 IOPS .

Esto explicaba el por qué la CPU y RAM no se veían afectados pero sí el rendimiento como tal.

En cuanto detectamos el cuello de botella, procedemos a ampliar mediante Terraform el tamaño del volumen EBS asociado a 100Gb, con sus correspondientes 300IOPS (el triple que antes).

El resultado lo tenéis aquí:

Nada más que añadir, se acabaron la latencias, los bloqueos y en general los problemas con esta plataforma, os dejamos el enlace a la documentación oficial de AWS sobre RDS y EBS

Recordad que para entornos productivos, la recomendación es siempre provisionar al menos de 100Gb el disco (aunque no nos hagan falta), para obtener esos 300 IOPS mínimo.

Recordad que en Geko seguimos a vuestra disposición para ayudaros con cualquier problema de rendimiento que tengáis con vuestra plataforma.

La entrada Problemas de rendimiento en RDS por IOPS en GP SSD se publicó primero en Geko Cloud.

Velero es una herramienta de código abierto para realizar copias de seguridad y restaurar de forma segura, realizar recuperación ante desastres y migrar recursos de clúster de Kubernetes y volúmenes persistentes.

Dicho esto, enumeremos en qué situaciones Velero puede ayudarnos:

• Copia de seguridad de aplicaciones con estado
• Aplicaciones de respaldo instaladas de manera no declarativa
• Copia de seguridad de información de PVC
• Migraciones de clúster
• Replicar configuraciones de clúster (por ejemplo, desde producción hasta pruebas o clústeres de desarrollo.

Después de la aburrida introducción, comenzaremos con la parte divertida.

Instala Velero en tu clúster de kubernetes

Para este ejemplo, utilizaremos AWS EKS como nuestro proveedor cloud.

En primer lugar, debes instalar el cliente Velero en tu estación de trabajo. Para hacerlo, simplemente ve aquí y descarga el último tarball de acuerdo con el sistema operativo de tu estación de trabajo y extrae el tarball:

tar -xvf RELEASE-TARBALL-NAME.tar.gz

Mueve el binario Velero a algún lugar de tu $ PATH. En MacOS simplemente ejecuta esto:

brew install velero

velero install 
    --provider aws 
    --bucket where-to-store-velero-backups 
    --use-restic 
    --secret-file ~/.aws/credentials 
    --use-volume-snapshots=false 
    --plugins=velero/velero-plugin-for-aws:v1.0.0 
    --backup-location-config region=eu-west-1

De forma predeterminada, Velero se instala en el namespace velero, pero puedes cambiarlo agregando el indicador –namespace. Velero utiliza restic para almacenar los datos de los volúmenes adjuntos. Cuando finalices la instalación, deberías ver algo como ésto en su clúster k8s:

$ kubectl get all -n velero
NAME                          READY   STATUS    RESTARTS   AGE
pod/restic-4xr6v              1/1     Running   0          157d
pod/restic-bg58w              1/1     Running   0          157d
pod/restic-hf2fm              1/1     Running   0          157d
pod/restic-w4rvh              1/1     Running   0          157d
pod/velero-57cd659988-bd6nd   1/1     Running   0          73d

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/restic   4         4         4       4            4                     157d

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/velero   1/1     1            1           157d

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/velero-57cd659988   1         1         1       157d

En nuestro caso, tenemos 4 nodos de trabajo y restic está instalado en cada nodo que tenemos (se configurará un daemonset).

Por defecto, Velero no incluirá los volúmenes en la copia de seguridad. Para respaldarlos, debes agregar una anotación. Puedes agregarla así:

$ kubectl -n annotate pod/your_pod backup.velero.io/backup-volumes=volume_1,volume_2

(agregua volúmenes separados por comas) o simplemente agrégalo en su definición de implementación, por ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
      annotations:
        backup.velero.io/backup-volumes: myapp-logs
    spec:
      volumes:
        - name: myapp-logs
          persistentVolumeClaim:
           claimName: myapp-logs
      containers:
      - image: myapp:latest
        name: myapp
        ports:
        - containerPort: 80
        volumeMounts:
          - mountPath: "/var/log/myapp"
            name: myapp-logs
            readOnly: false

Nota: los volúmenes hostPath no son compatibles, pero sí se admite el nuevo tipo de volumen local.

Y, por último, algunos ejemplos de utilización para crear, restaurar y mostrar copias de seguridad:

Backup manual:

# Copia de seguridad de TODOS los recursos en el clúster (todo el clúster)
$ velero backup create my-backup-20200515

# Copia de seguridad de un namespace
$ velero backup create my-backup-20200515 --include-namespaces namespace_to_backup

# Copia de seguridad de TODOS los namespaces excepto los especificados
$ velero backup create my-backup-20200515 --exclude-namespaces namespace_1_to_exclude,namespace_2_to_exclude

Backup Programado:

$ velero create schedule myapp-backup-daily --schedule="0 7 * * *" --include-namespaces namespace_to_backup

Velero respaldará todos los recursos incluidos en tu selección (pods, implementaciones, servicios, …)

La retención de copia de seguridad predeterminada es de 30 días. Si deseas cambiarla, agregue la bandera –ttl. Este indicador te permite especificar el período de retención de la copia de seguridad con el valor especificado en horas, minutos y segundos en la forma –ttl 24h0m0s. Si no se especifica, se aplicará un valor TTL predeterminado de 30 días.

Restaurar Backup:

$ velero restore create --from-backup backup_name

Otros comandos que te serán muy útiles de conocer:

# Para mostrar todas las listas de copias de seguridad almacenadas (nombre, estado, fecha de creación y caducidad)
$ velero get backups

# Para mostrar detalles de una copia de seguridad específica
$ velero describe backup backup_name

Velero es bastante fácil de instalar y ejecutar y puede salvarte la vida en algunas circunstancias.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Kubernetes backups con Velero se publicó primero en Geko Cloud.