Kubernetes en AWS (EKS): 5. Creando el RDS (base de datos) y probando la PoC

1. Objetivos

En este articulo, vamos a crear una base de datos con el engine PostgreSQL en el servicio AWS RDS. Tambien vamos a crear los deployments para los distintos servicios para EKS, ajustando los templates que os proporcionamos para que se adapten a vuestro caso y vamos a desplegarlos en los Node Groups.

Una vez ya hemos desplegado todos los módulos de nuestra PoC de EKS, prepararemos todos los componentes para realizar las pruebas, que van a ser Postman y NodeRed, así como tambien vamos a crear la estructura básica de la base de datos que luego vamos a consultar desde nuestro backend.

Si no conoces alguno de estos software’s, te dejamos una version resumida de que hace cada uno.

¿Qué es Postman?

Postman es una herramienta de desarrollo de software que permite a los desarrolladores probar, depurar y documentar APIs.

Postman es útil para múltiples tareas, como por ejemplo:

• Testear colecciones o catálogos de APIs tanto para Frontend como para Backend.
• Organizar en carpetas, funcionalidades y módulos los servicios web.
• Gestionar el ciclo de vida (conceptualización y definición, desarrollo, monitoreo y mantenimiento) de nuestra API.
• Generar documentación de nuestras APIs.
• Trabajar con entornos (calidad, desarrollo, producción) y compartir la información con el resto del equipo involucrado en el desarrollo a través de un entorno cloud.

Para usar Postman, generalmente se comienza creando una colección, que permite agrupar solicitudes3. Luego, puedes incorporar en ella todas las solicitudes que necesites3. Postman permite trabajar cómodamente con todos los métodos del HTTP, como GET, POST, PUT, PATCH, DELETE3. Gracias a Postman, puedes guardar todas las solicitudes que quieras, para tenerlas preparadas y poder ejecutarlas las veces que haga falta3.

¿Qué es Node Red?

Node-RED es una herramienta de programación visual que permite conectar dispositivos de hardware, APIs y servicios en línea de formas nuevas e interesantes. Es especialmente útil para simplificar la programación, la conectividad y los servicios, distribuyéndolos de forma eficiente para ganar tiempo en el registro y gestión de la información.

En el caso que nos ocupa, lo usaremos para simular un dispositivo MQTT que se conectaria a nuesto mqtt broker que esta corriendo en nuestro clúster de EKS. Podriamos utilizarlo de las siguientes formas:

• Subscribirse a ciertos topics
• Recibir/Publicar mensajes en ciertos topics

¿Qué es un Security Group?

Un Security Group en AWS es un firewall virtual que controla el tráfico de entrada y salida de los recursos de AWS y las instancias de EC2.

Para cada Security Group, puedes agregar reglas que reflejen el rol de la instancia que está asociada al Security Group. Por ejemplo, una instancia configurada como servidor web necesita unas “reglas” de seguridad que permitan el acceso HTTP y HTTPS entrante, del mismo modo que una instancia de la base de datos necesita reglas que permitan el acceso para el tipo de base de datos (como el acceso a través del puerto 3306 para MySQL).

Además, puedes especificar el origen, el rango de puertos y el protocolo de cada regla de entrada, y el destino, el rango de puertos y el protocolo de cada regla de salida.

En resumen, un Security Group actúa como un firewall virtual y es la primera defensa de seguridad contra los accesos indeseados.

2. Creando nuestra base de datos en AWS

Para nuestra base de datos, usaremos Amazon RDS. Este es el servicio administrado que AWS ofrece a sus clietes para tener bases de datos relacionales en la nube de AWS. En el articulo 2. El proyecto, ¿Qué necesitamos? , explicavamos de forma más detallada que es AWS RDS.

Tendremos que realizar varios pasos para tener correctamente configurado nuestro RDS funcional.

2.1 Creando el subnet group

Antes de nada, crearemos un subnet group. Si no sabes lo que es, te recomiendo que te leas la brebe explicación.

¿Que es un subnet group?

Un Subnet Group de RDS (RDS Subnet Group) en AWS RDS es un recurso de la VPC que se utiliza para definir un conjunto específico de subnets donde se puede lanzar una instancia de RDS, lo que permite aumentar la disponibilidad y fiabilidad de la instancia de la base de datos.

En nuestro caso, crearemos un Subnet Group con las subredes privadas de back, esto permitira que no haya accesos externos desde fuera de nuestra VPC.

Vamos a crear un subnet group:

• Para ello nos dirigimos a Amazon RDS y busamos el apartado que pone “Subnet groups” una vez allí le daremos a crear nuevo subnet group.

• Vamos a introducir un nombre como por ejemplo “eks-poc-rds-sub-group”, hay que añadir una descripción (es obligatorio). Finalmente, seleccionaremos el VPC que se ha creado con cloud formation.

• Bajaremos y seleccionaremos todas las subnets groups.

• Para obtener que subnets debemos seleccionar, abriremos en una ventana aparte y abriremos la página de “VPC”, en la parte superior izquierda, en el apartado filter by VPC filtraremos para el VPC que creamos con el template de cloudformation. Posteriormente, nos dirigiremos al apartado de subnets.

• En el buscador escribiremos “back”. Esto nos permitira filtrar unicamente por las que son de backend (todo: explicar porque)

• Miraremos que el final del Name (para saber en qué zona esta) y seleccionaremos las mismas en el subnet group (la zona se indica en el Name, es decir, todo lo que acabe con -1a estará en eu-central-1a). Finalmente, le daremos a “create”.

2.2 Creación de la base de datos en Amazon RDS

• Iremos al apartado de RDS y le daremos al apartado “DB Instances”.

• Buscaremos el apartado de “Create Database”.

• Dejaremos seleccionado “standard create” y seleccionaremos PostgreSQL como motor de nuestra base de datos.

• Seleccionaremos el template de “Free Tier”. Esto lo haremos ya que no es un RDS que vayamos a poner a producción, sino que al estar haciendo una PoC con esto tendremos de sobras. Si tu cuenta de AWS tiene aún free tier, este servicio te salgrá gratuito. Para más información, AWS Free Tier.

• Le pondremos un nombre a la base de datos, dejaremos seleccionado “self managed”, en master password pondremos “superpass” (puedes poner otra, pero entonces también lo tendrás que cambiar del código).

• Dejaremos la instancia t3.micro seleccionada.

• Dejaremos estos valores por defecto. GP2 en RDS es un pelín más barato que GP3 (almenos en el momento de la redacción de este artículo).

• Seleccionar el VPC que hemos creado anteriormente con los templates de CloudFormation.

• Seleccionaremos como subnet group, el que hemos creado en los pasos anteriores.

• Dejaremos el Public Access como NO. Tal como está montado, no tendremos acceso a la base de datos desde internet, así nos evitamos la “Public IPv4” que usaría que tiene coste.

• Dejaremos el security group que viene por defecto en nuestra VPC.

• Dejaremos que la autenticación de la base de datos sea por password.

• Desactivaremos el check de performace insights, ya que para nuestra PoC no harán falta.

• Pondremos que la base de datos inicial se llame “postgres”, y el “DB parameter group” lo vamos a dejar por defecto.

• Finalmente, le daremos a crear la base de datos, y nos esperaremos unos 5 minutos a que acabe de crearse.
• Nos guardaremos el endpoint que nos dé RDS, ya que será donde nuestra capa de backend apuntara.

3. Preparando las pruebas de nuestro EKS

3.1 Crear deployments en el EKS

Vale, ahora tenemos las máquinas, pero nos falta ejecutar algo dentro de ellas, ahí es donde entran los “deployments” de Kubernetes. Los deployments son como ficheros de configuración donde le indicamos a kubernetes donde, como y que tiene que desplegar en nuestro cluster.

Para ello se han proporcionado en el zip “Imagenes y configuracion” unos ficheros *.yaml que se encuentran dentro de las carpetas Config de cada servicio.

3.1.1 Modificaciones necesarias

Hay diversas modificaciones que tienen que hacerse en los ficheros de configuración. Te guiaremos para realizar cada una de ellas.

\Backend\Image\app.py :

Este fichero tiene el código que ejecutará tu backend.

Hay que ir al principio del fichero y cambiar el valor de dentro de la variable RDS_HOST por el valor que nos ha proporcionado RDS anteriormente. Si hemos indicado un password distinto a “superpass” durante la creación del RDS, también deberemos modificarlo en la variable RDS_PASS.

Una vez que hagamos hecho estos cambios, tendremos que volver a compilar la imagen. Para ello seguiremos las instrucciones que nos proporciona ECR o sino puedes revisar como se hacia en el artículo 4 en el apartado 3.2 .

\Backend\Config\backend.yaml

Este es el fichero de configuración que utilizara kubernetes para crear el servicio, deployment y el POD.

Tendrás que dirigirte a la línea 43, donde se indica la imagen, y substituir el valor de “image:” por el que nos proporciona ECR (OJO: Al final tiene que quedar <ECR URI>:latest, ya que de momento no usaremos los tags).

\Frontend\Config\config.yaml :

En este fichero se especifica toda la información referente al servicio de frontend.

En este caso hay que modificar la línea 36, lo mismo que en el caso anterior, cambiar la URI pero dejando “:latest” al final.

\mqtt-broker\Config\mqtt-broker.yaml :

En este fichero se especifica toda la información referente al servicio de frontend.

En este fichero hay que modificar la línea 37, lo mismo que en el caso anterior.

3.1.2 Creando todos los deployments en EKS

Para crear estos deployments de kubernetes haremos lo siguiente:

• Nos colocaremos en la carpeta del deployment que queremos realizar en un terminal, en este caso “mqtt-broker\Config”, y ejecutaremos el siguiente comando:

kubectl apply -f .\mqtt-broker.yaml

• Deberíamos ver un output tal que así.

• Repetiremos esta operativa para los otros 3 deploys (ASEGURATE DE CAMBIAR DE CARPETA)

• Si has aplicado los Kubernetes Labels de forma correcta, deberías ver que, aparte de algunos pods propios de Kubernetes y AWS, solo el pod del servicio está en ese node group (y no por ejemplo el MQTT-BROKER ejecutándose en el node group FRONTEND).

3.2 Preparando NodeRed

Para realizar las pruebas vamos a necesitar Docker y Node Red. Para configurarlo haremos lo siguiente:

• Iniciaremos el servicio docker (recomendamos actualizar a la última versión).
• Una vez el servicio de docker esta corriendo, ejecutaremos el siguiente comando en un terminal.

docker run -it -p 1880:1880 -v node_red_data:/data --name mynodered nodered/node-red

• Tras haberse descargado la imagen y configurado el contenedor, veremos que nos saldrá por el terminal el siguiente mensaje.

• Nos conectaremos a la URL que nos ha dado por terminal (http://127.0.0.1:1880) y veremos una pantalla tal que así.

• Iremos al menú de la parte superior derecha, donde seleccionaremos import.

• Importaremos el fichero que se encuentra debajo, que contiene una configuración básica.

• Hay que hacer cambios en el fichero proporcionado dado que el endpoint no sera el mismo para todos. Por lo tanto, obtendremos el valor de DNS que hay asignado al load balancer que se ha levantado automáticamente (desde kubernetes) dado que se ha creado un servicio. Para ello ejecutaremos “kubectl describe services”.

• Una vez ejecutado, buscaremos en la salida del terminal la información del ‘mqtt-broker’, para ello debes fijarte en el campo “Name”, y nos guardaremos el contenido de “LoadBalancer Ingress”. El puerto debería ser el 1883 si no has hecho cambios en el template, de lo contrario, guardate también este campo.

• Seleccionaremos el módulo “/hello” que tiene dentro la conexión con el broker mqtt que hemos desplegado en nuestro clúster de EKS. Al darle doble click se nos abrira un panel a la derecha de configuración.

• En el panel de configuración, le daremos a editar.

• Remplazaremos el valor indicado en el campo server por el que hemos obtenido anteriormente.

• Una vez dado a guardar, haremos click en la parte superior derecha donde pone deploy.

• Una vez hecho el deploy, le daremos click al pequeño cuadrado dentro del módulo Message, que hará que se mande un mensaje al topic mqtt /hello y hará que se printe el mensaje enviado por el apartado de debug.

• Para acceder a los mensajes de debug, iremos al icono de la parte superior derecha que tiene el símbolo de un escarabajo.

• Para saber si la conexión se ha realizado con éxito, debemos ver que debajo de los modulos de color rosado, aparece un símbolo verde con la palabra “connected”. También debemos comprovar que quando mandamos un mensaje, en el apartado de debug nos aparece un mensaje con el formato {“Returned_message”: timestamp} como en la imagen anterior.

3.3 Preparando Postman

Potman es un programa que nos permite hacer llamadas HTTP a endpoints.

Para configurarlo debemos:

• Nos dirigiremos a la página oficial de postman https://www.postman.com/ desde donde nos descargaremos la versión de escritorio.

• Una vez descargado lo instalaremos y ejecutamos.
• Nos iremos al apartado de “Collections” en la parte superior izquierda, y le daremos a “Create new collection”.

• Seleccionaremos “Blank Collection”.

• Le pondremos un nombre, por ejemplo “Kubernetes-PoC”.

• Obtendremos el endpoint de la parte frontend de EKS ejecutando el siguiente comando.

kubectl get services

• En postman, crearemos una nueva request de tipo get (por defecto) e introduciremos la url en el campo (2). También le pondremos un nombre a la request (1).

• Haremos una llamada al path “/”. Para ello pondremos la URL y le daremos al botón de “Send” y nos tendria que devolver lo siguiente.

3.4 Inicializando la base de datos

Con el Postman ya configurado, vamos a hacer una llamada al path “/initialize”. Esto va a hacer que se cree una tabla llamada “devices” donde se insertara un registro con los campos siguientes:

Nombre del campo	Valor	Ejemplo
id	int (autogenerado)	1
mac_address	str(20) MAC del dispositivo	00:00:00:00:00:01
device_name	str(30) Nombre asigando por el usuario al dispositivo	testing device
creation_date	TIMESTAMP Fecha en que se creó el dispositivo en la Base de Datos	2024-04-03 08:30:15

Pasos a segir:

• Ir a PostMan, duplicar la request anterior (click derecho encima de la request, y darle a duplicar) y modificar su nombre y su path a initialize
• Le daremos a send

Esto hara una peticion a nuestro clúster de EKS donde se hara la inicialización (desde la parte backend)

Para comprobar que se ha ejecutado correctamente, miraremos la respuesta que nos devuelve la petición.

4. Realizando pruebas para comprobar el correcto funcionamiento

4.1 Comprobar que todos los servicios están levantados en EKS

Antes de nada verificaremos que de todos los servicios hay al menos un POD levantado. Para ello haremos la siguiente operativa:

• Ejecutaremos el comando inferior y checkearemos que en todos los casos hay al menos uno.

kubectl get deployments

4.2 Realizando pruebas contra el clúster de EKS

Comprobaremos que el backend y el frontend esten funcionando correctamente ejecutando una llamada get desde Postman al path “/”. Tendria que devolvernos un Status 200 con el mensaje que aparece en la imagen inferior.

Una vez comprobado que esos dos componentes funcionan, vamos a inicializar la base de datos.

Para ello tendremos que hacer una llamada desde POSTMAN al path “/initilize” y esperar una respuesta como la que aparece en la imagen inferior.

Una vez comprobado, vamos a ejecutar varias acciones de enviar mensajes desde Node Red.

Entonces iremos nuestro navegador, introduciremos la misma url que tenemos en PostMan, pero esta vez llamaremos al path “/mqtt”

Nos aparecera una pantalla como en la imagen inferior, donde deberemos poner una mac, y pondremos “00:00:00:00:00:01” y le daremos a submit. Esto se hace porque así podemos desde el backend comprobar el input y se podrian hacer cosas a partir de ese input.

Una vez hecho esto, nos aprecera una pantalla tal que así. Donde se devuelve un json con el status de la respuesta, la información del dispositivo que hemos introducido en la pantalla anterior (recuperado de la base de datos), los mensajes que se han enviado desde Node Red, y la mac del dispositivo que hemos introducido anteriormente.

Aquí daremos por concluida nuestra prueba de concepto basada en el servicio de EKS.

5. Conclusión general

Hemos conseguido desplegar nuestro primer cluster funcional de EKS, donde hemos aprendido sobre:

• Que és Amazon EKS y que nos aporta respecto a crear y mantener un clúster de kubenetes.
• Como crear un cluster de Amazon EKS tanto desde la consola como usando eksctl.
• Como crear imagenes con docker y subirlas a Amzon ECR para que puedan ser desplegadas en nuestro clúster hosteado en EKS.
• Como crear nodos para EKS, y que modelo de aprovisionamiento nos conviene.
• Que són los add-on de EKS y como aplicarlos.
• Qué és y como crear un RDS para postgres, y conectarlo a nuestro EKS.
• Como funcionan los PODS, los DEPLOYMENTS y los SERVICES de Kubernetes.
• Como crear una infraestructura autobalanceada en EKS y autoescalable.

Ademas, otros puntos que hemos tocado són:

• Como securizar nuestros recursos limitando su acceso a internet
• Que són los Security Groups de Amazon, y como nos ayudan a proteger nuestros recursos de actores no deseados.
• Qué és Node Red y hacer una demo pequeña.
• Que es un broker MQTT.

6. Feedback

Esperamos que este articulo te haya ayudado a conocer un poco más el servicio de Amazon EKS. Nos gustaria que respondieras a unas preguntas y que nos dejaras un comentario. Esto nos ayudara a mejorar en futuros artículos así como mejorar la serie de artículos que has estado siguiendo. Muchas gracias!

Djeanos tu comentario sobre que te ha parecido EKS y el mundo de kubernettes. Si en algún momento te has atascado o crees que podemos mejorar alguna parte de algún artículo, por favor indicanoslo para que podamos corregir el artículo.

---