Un cóctel perfecto 🍹 ECS Fargate, Service Connect,Terraform y Github Actions.

#aws #ecs #awtwins #terraform

En nuestro último post de #AwtwinS comentamos un avance del Re:Invent donde utilizabamos EKS POD Identity para administrar las credenciales de aplicación 🔐 y como no, hablando de containers, como también comentamos la parte de AppRunner, EKS y ahora porque no... un poquito de ECS. 🚀

✌️En esta nueva Poc tenemos dos servicios en ECS Fargate✌️

Front: Usaremos un script en python que hará llamadas contra nuestro backend, como siempre. (dummy-dummy)
Backend: Servidor HTTP que escucha en un puerto especifico, este está en Nodejs. (otra dummy-dummy) ¡Prepárate para disfrutar de un cóctel!

No obstante cuando pensamos en servicios, debemos de pensar también en como vamos a conectar esos servicios y aquí en AWS surgen varias formas de conectarlos.🪢

En primera instancia pensamos en ELB por servicio, creando así un espectáculo de balanceadores. Sin embargo, cuanto nos cobran la entrada, el espectáculo deja de ser divertido, aquí es donde se complica.🤑 Y si tienes que luchar contra el Preserve IP? (Esta experiencia,que merecería otro post propio nos enseña que cada solución tiene sus desafios)🤯

En este caso vamos a hablar de Ecs Service Connect, baile de proxies 🕺 en perfecta coordinación 🕺. Service Connect despliega sus artes escenicas a través de un container Sidecar que se ejecuta a cada tarea del servicio. Este Sidecar actúa como proxy, gestionando las conexiones entre servicios. Pero aquí el paso brutal: Service connect registra los endpoints en Cloud Map por nosotros.

Para más información:
Service Connect

Tenemos dos subnets en la VPC con 2 servicios. Nuestro frontend es el encargado de hacerle peticiones a nuestro backend.

En este caso,la conexión se está usando con el nombre corto de ecs-backend en el puerto para nuestro backend, definiendo los puertos en el terraform de nuestra task definition.👏

Para entender mejor esto, el baile en el siguiente diagrama:

Comentada la teoría pasemos a la acción! Módulos de terraform de community 😶‍🌫️ Github Actions y Service Connect.😶‍🌫️

Para este caso los módulos que utilizaremos son los siguientes:

ECR
VPC
ECS

Cabe remarcar que añadiremos una parte de código (Service Discovery) en alguno de ellos para hacer nuestra PoC, no obstante,os dejamos nuestros repos públicos con la PoC. 💻

Terraform-ECS-PoC
Frontend Dummy
Backend Dummy

Al desplegar nuestro terraform desde el repositorio podremos ver el ECS con sus respectivos servicios.

Como decíamos, nuestro compi de baile se ejecuta a su lado como un Sidecar.

Una vez desplegado y configurado todo y al no tener endpoint público, usaremos cloudwatch para ver los registros y podemos ver que están conectando correctamente nuestras apps. 🥵

✌️ ¡Aviso Importante! Este post está creado con el propósito de compartir conocimientos y experiencias en el entorno de una Prueba de Concepto (PoC).

Etiqueta "latest" en Docker: ¡Atención! 🚨 (Puede ocasionar problemas en tus entornos)

Costos Asociados y Buenas Prácticas 📊: Además, en este entorno de Poc, hemos tomado decisiones que pueden tener implicaciones en términos de costes, VPC, Logs... En el mundo real, se recomienda seguiir unas buenas prácticas, optimizar costes y tener en cuenta la seguridad y eficiencia.

Por tanto, a testear con responsabilidad! 🔍

Esperamos vuestras reacciones y comentarios! 🎉