Alex Rodr铆guezEn 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:
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! 馃帀
