Recientemente hemos estado haciendo PoC´s con Pulumi y Digital Ocean así que metimos a un tercero a la ecuación, ArgoCD, una herramienta de Delivery para Kubernetes.

A partir del PoC hecho con Pulumi y Digital Ocean instalamos ArgoCD en el cluster de Kubernetes creado y vinculamos un único repositorio con dos ramas, master y feature/python-simple-web para dos apps diferentes mypage y simple-web en ArgoCD, lo que hace difiere estas dos ramas son el namespace del proyecto, la imagen del contenedor y la url que nginx-ingress deberá administrar.

Esta nueva herramienta después de hacer todos los ajustes se vuelve divertida y amigable, como primer acercamiento puedo decir que tiene una agradable interface gráfica y que me hace pensar si dejaremos fuera a Pulumi para administrar el estatus deseado de los recursos creados previamente como deployments/services/ingress/configMaps etc, en el cluster.

A continuación les dejo unas capturas del PoC.

Branches Repositorio Git

ArgoCD Dashboard Applications

ArgoCD vista de red del app “mypage”

ArgoCD vista de arbol del app “mypage”

ArgoCD vista de red del app “simple-web”

ArgoCD vista de arbol del app “simple-web”

Vista en vivo de app “mypage”

Vista en vivo de app “simple’web” balance pod 2

Vista en vivo de app “simple’web” balance pod 1

Si requieres de mi ayuda para administrar tu infraestructura e implementar un sistema GitOps contáctame.

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.

Los desafios eran:

• Enviar los respaldos de la BD.
• Enviar el storage  de los objetos generados
• Mantener una sincronía de objetos de los respaldos de la BD y los objetos creados/actualizados/eliminados con el software.

Por cuestiones de costos decidimos usar S3 respecto a un NFS, EBS, por lo que busque una herramienta que me permitiera sincronizar los contenidos usando la linea de comandos.

Entre la vastedad de resultados apareció RClone, en su pagina principal indicaba los protocoles y fabricantes soportados, FTP y SSH quedaban descartados, no precisábamos adquirir un servidor y storage y salirnos del presupuesto por lo que analizamos los que eran S3, entre ellos casi al final de la lista estaba Wasabi, nos llamo la atención y accedimos a visitarle.

Lo que nos engancho fue el ahorro de un 80% del costo en comparación con AWS y GCE, tan solo a $5.99 por TB lo que lo hace muy competitivo ante Mega o Google Drive.

Wasabi te ofrece la oportunidad de probarlo por un mes, por lo que optamos por esta opción y validar la integración con RClone.

La configuración del RClone respecto a la version y zonas actuales que posee Wasabi al momento de hacer nuestro PoC están desfasadas por lo que tuvimos que contactar con el soporte de Wasabi, quienes amablemente y un tiempo razonable nos apoyaron para ajustar los parámetros y la zona (de recién integración en Wasabi) que elegimos al momento de adquirir nuestra cuenta.

Una vez configurado RClone empezamos con nuestra PoC listando los volumenes creados  en su interface grafica.

webmago ~: rclone lsd wasabi:
-1 2021-01-19 09:37:49 -1 desarrollos
-1 2021-01-18 19:20:56 -1 fotos-webmago


Creamos una carpeta local, generamos algunos archivos y los sincronizamos con nuestro volumen.

webmago ~: mkdir -p wasabi/one wasabi/two wasabi/three

Listando los contenidos locales de wasabi.

webmago ~: ls wasabi/
one tree two

Generando archivos que enviaremos a wasabi.

webmago ~: touch wasabi/one/uno.txt wasabi/two/dos.txt wasabi/three/tres.txt

webmago ~: rclone sync ./wasabi/ wasabi:desarrollos/wasabi

Listando los contenidos enviados a Wasabi

webmago ~: rclone ls wasabi:desarrollos/wasabi
15 one/uno.txt
0 three/tres.txt
0 two/dos.txt


Si no quieres batallar con la linea de comandos, Wasabi recomienda algunos clientes Windows, Linux y Mac para acceder a los volumenes y hacer operaciones similares a un Finder (Mac), Explorador (Windows), en mi caso use Nextcloud como cliente web, en un  PoC previo tuve unos comportamientos inesperados con Google Cloud Storage, como solo poder elminar objetos y no poder crear a pesar de tener los privilegios, por lo que pensé que con Wasabi podria ocurri algo similar, sin embargo, todas las operaciones de Lectura, Escritura, Eliminación fueron exitosas.

Nextcloud – Wasabi

Wasabi nos convencio no solo en el precio, sino en el valor agregado que dan al responderte e indicarte la gran cantidad de informacion que tienen sobre sus productos, las certificaciones, redundancia y sistemas de seguridad en torno a todas sus soluciones hacen de Wasabi una gran opcion de almacenamiento.

Finalmente declinas probarte ese calzado y continuas con tu búsqueda, unos metros mas adelante encuentras otra tienda con un calzado similar y con mejores características, como 2 pares de cuerdas extras de color para combinar con tus atuendos, preguntas al encargado si puedes verlos y probártelos, a lo que el te responde que si, de tu experiencia previa preguntas si debes pagar algo por probártelos; el te responde que eso no es necesario, que puedes hacerlo sin un compromiso de compra. Es cierto, acabo de ver tu cara de felicidad.

Algo parecido me ocurrió con Amazon SES, parecía una buena opción, acudí a un partner, AWS me contacto y me puso en contacto con otro partner al que le indique que me gustaría probar y ver el panel de AWS SES para ofrecer un POC a un futuro cliente.

Después de una semana, la respuesta del ultimo partner fue una cotización para poder habilitarme el panel y yo hacer el POC, imagina si el cliente no aprueba contratar el servicio de AWS SES, para mí eso seria reflejado como perdida.

En varios de mis proyectos he usado Sendgrid, por las siguientes características:

• Envío de correo usando API.
• Sin limite de envíos por día, solo en paquetes de pago.
• Paquete gratuito 100 emails por día.
• Cuando contratas un paquete, no tienes limite en el tamaño del envío.
• Si excedes de tu paquete en envíos tus excedente serán cobrados en la siguiente factura.
• Estadísticas.
• Registros  del estatus de cada correo enviado.
• Manejo de campañas de marketing.
• Manejo de usuarios.
• IP dedicada con paquetes PRO en adelante.

Por lo tanto, Sendgrid es una buena opción si vas empezando con tu proyecto o si deseas lanzarte a lo grande.

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%