Usando código en Typescript trabaje en un PoC para vincular 3 Droplets y balancear sus cargas, para ello hice uso de Pulumi para generar la arquitectura en donde un balanceador de carga recibirá las peticiones y las dirigirá hacia los droplets, a su vez un firewall evitara accesos a puertos no solicitados.

En un post previo hable de Pulumi con Digital Ocean, con el que trabaje en un PoC y Kubernetes. Para este PoC me base en este código  al cual le hice algunas adecuaciones para instalar docker y ejecutar el contenedor de Simple Web y validar el balanceo a través de los 3 Droplets creados.

En la primer creación del Load Balancer, el verificador de salud lo habia definido para revisar el protocolo TCP en el puerto 80, esto genero un fallo general debido al uso del contenedor con python, por lo que procedí a ajustarlo para revisar el protocolo HTTP en el codigo de Typescript en lugar de hacerlo en el panel administrativo de Digital Ocean obteniendo así el estado de salud satisfactorio.

Cabe señalar que existen algunos glitches que Pulumi deberá resolver como en el caso de actualizar el Userdata de los Droplets se generan errores en el recurso del Firewall y Load Balancer.

Les dejo a continuación unas capturas del PoC.

Pulumi Stack

DO VPC creado

DO DROPLETS creados

DO LB creado

DO FW creado

Puedes usar una gran variedad de software para llevarlo a cabo, lo que implica en algunos casos aprender un nuevo lenguaje, algo que Pulumi ha tomado en cuenta para su rápida adopción, por lo que si sabes Typescript, Go, Python, Javascript o .Net reducirás enormemente la curvatura de aprendizaje.

Había escuchado de Pulumi hace un año, hace unas semanas tome dos webinars  y las dudas que tenia sobre su uso, escenarios me animo a probarlo con una promo que obtuve en Digital Ocean por lo que inicie con la creación de un cluster Kuberntes usando Typescript. Pulumi te ofrece una version gratuita si únicamente tú usas el entorno.

La ventaja de esto que puedes ir haciéndolo poco a poco y esta es la lista ordenada de lo que fui administrando con mi código.

1. Creación del Cluster Kubernetes.
2. Creación de algunos namespaces, ex: staging, website
3. Creación de un primer Deployment con nginx en el namespace de staging.
4. Creación de un ClusterIP Service para el Deployment creado en el punto 3.
5. Una gran pausa para instalar Istio (muy complicado y tomaría mas horas) o nginx como Ingress
6. Después de decidirme en el punto 5 por nginx, procedí a crear el código para instalarlo como Ingress, con su namespace usando el Helm v3 Chart; esto me genero un LoadBalancer en Digital Ocean a su vez asignándome la IP Publica.
7. Creación de un Service Ingress para dirigir el tráfico del ingress-nginx creado en el punto 6 hacia el ClusterIP creado en el punto 4, puedes verlo en do.webmago.dev (puede no estar disponible en el futuro).

Ejecucion Paso 1 Pulumi

Revision Dashboard Digital Ocean

Dashboard Pulumi paso 1

Cabe señalar que para mantener mi entorno aislado y no interferir con mis configuraciones de mi equipo trabaje desde un contenedor de docker.

Tengo que aclarar que tuve algunos glitches con Pulumi al aplicar/actualizar cambios y al parecer es un comportamiento algo raro que tiene Digital Ocean, por lo que recibía errores y tenia que volver a ejecutar la actualización de cambios.

En mi experiencia, puedo decir que Pulumi reduce considerablemente su curvatura de aprendizaje y adopción permitiéndote administrar tu Infraestructura como Código con los lenguajes antes mencionados.

Hoy que estoy trabajando en todo el ciclo de DevOps con Kubernetes no me hacia sentido trabajar en un VPS para generar mis ciclos y demos que veras en el blog, por lo que analice las diferentes ofertas como AWS, Azure, Digital Ocean y finalmente Google donde se encuentra hospedado este blog.

Al inicio intente poner en marcha October CMS, sin embargo tiene muchos puntos que resolver aun para hacer una portación a K8S de forma completa, por lo que opte por WordPress, ya lo he usado con otros proyectos y sé cómo vincularlo a un Volumen.

Inicie el cluster de forma micro, con 3 instancias f1-micro las cuales te dan 1 vCPU y 0.6 GB RAM, sin embargo siempre presentaba un problema alguno de los nodos, por lo que lo incremente a 8 y resulto mas o menos la estabilidad, nace un nuevo problema, montar una BD MySQL para el blog, ya lo he aplicado en clusters K8S con mayores recursos sin problemas, claro, sin la HA que ofrece Cloud SQL; debido a la poca memoria que los nodos tienen, era imposible mantener estable el pod de MySQL, así que analice el costo y bien podría usar una instancia micro sin obtener, claro esta, el SLA por una instancia mas grande, algo que para este proyecto personal no es de gran impacto.

Todo marcha bien hasta que recordé a spotinst.com quienes te ofrecen reducir en un margen del 70 al 80 por ciento del costo de tu cluster, así que manos a la obra y ahora tenemos un cluster de 2 nodos n1-standard-1, lo que representa 1 vCPU y 3.75 GB por nodo, ya les contare en otro post como me ha ido en costos con spotinst.com, de momento el dashboard indica que me he ahorrado 78.97%