Para los clusters Kubernetes me auxilio de “Monitoring” (antes Stackdriver) en GCP o CloudWatch en AWS, o incluso Prometheus con Grafana.

Lo que hace de Weavescope un software Open Source tan peculiar no solo es ver métricas, sino pausar, detener, reiniciar un contenedor o acceder a la terminal del mismo para hacer algunas operaciones tal como si fuera una terminal remota.

Esta versatilidad de Weavescope me permite visualizar y hacer operaciones cuando solo cuento con un dispositivo móvil como una tableta o un iPad.

Weavescope ofrece varias alternativas de ser instalado, en mi caso donde uso VPS con docker-compose opte por esta version con algunos ajustes que no se mencionan en la version oficial, tal es el caso de la autenticacion, ya que de no contar con esto cualquiera que conozca la dirección de mi instalacion podria hacer un mal uso como detener o crear contenedores y vulnerar mi sistema.

Weaveworks la compañia creadora de Weavescope ofrece diferentes soluciones de automatizacion CI-CD, monitoreo y registros, una de las herramientas mas novedosas GitOps basado en Kubernetes.

No olvides contactarme si requieres asistencia en tus proyectos.

A continuacion dejo una serie de capturas de una de mis instalaciones de Weavescope.

Filtrando los recursos por contenedor

En la ficha del contenedor se observan varios botones para efectuar operaciones tales como adjuntar, acceder a la terminal, refrescar, pausar, detener el contenedor.

Esta version grafica es un atajo a la instruccion “docker exec -it dbadmin bash”

So, Kubernetes is deprecating Docker support and you’re either nervous or confused. That’s okay! I would like to help you understand what’s happening. A thread! 1/10

— Kat Cosgrove, but ✨festive✨ (@Dixie3Flatline) December 2, 2020

Quienes trabajamos con Kubernetes o en Desarrollo de Software hemos usado Docker para desarrollar y generar las imágenes que finalmente usaremos en nuestro clúster, por supuesto que existen mas proveedores compatibles con OCI (Open Container Initiative) y esto quiere decir que las imágenes que generamos en Docker cumplen con esta normativa.

Ayer 3 de Noviembre 2020, Docker publico un articulo (en inglés) detallando quá sucederá con este cambio dándonos una tranquilidad a toda la comunidad que usa la tecnología de contenedores.

What developers need to know about Docker, Docker Engine, and Kubernetes v1.20

En si, lo que se eliminará probablemente en un año será dockershim, por lo tanto, las imágenes que generes con Docker seguirán funcionando en tu clúster Kubernetes, el cambio es mas para los operadores y administradores de Kubernetes donde el acceso a la inspección de los contenedores usando comandos de Docker no podrán ser usados.

Así que mantén la calma y sigue usando Docker.

Al momento de recibir la orden vía Webhook inicia el proceso de integración del código a través de las ordenes indicadas en el Dockerfile, con esta imagen y/o con la ayuda de otras se realizan pruebas unitarias que los desarrolladores acompañan con sus commits.

Muchos creen que Delivery y Deployment son lo mismo, sin embargo, Deployment es el siguiente paso a Continuos Delivery. En el proceso de Delivery, existe un paso manual, sin embargo, en el Deployment todo sucede de forma automática.

Inspired by Yassal Sundman’s blog post on Crisp’s Blog.

Tras el éxito del paso previo, viene el despliegue o liberación del producto final, Codefresh provee una vasta serie de plugins e imágenes para que no tengas que recurrir a pasos adicionales fuera de su entorno, para mis actuales proyectos en clusters Kubernetes hice uso de su imagen k8s-blue-green, esta me permite hacer despliegues de la version actual y sacar la version previa “del aire“.

Si todo ha ido bien, o mal, el mismo SaaS de forma nativa o haciendo uso de sus plugins puedes notificar via Slack o Telegram a tu equipo sobre el ciclo, haciéndolos participes y corresponsables.

¿Quieres emular un Delivery en esta plataforma?, sin problema, introduce el paso pending-aproval, y através de  Slack, el usuario indicado recibirá la notificación con las opciones para Aprobar o Declinar el proceso desde este medio o el Dashboard del SaaS.

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%

El render de las versiones web y móvil lo hacia el código monolítico frontal, mientras que otro código (copia salvo entradas diferentes) proveían el acceso a la ingesta de contenidos.

Antes de separar todo, por encargo me solicitaron una aplicación móvil con una vista a sugerencia mía con Material Design, para ello, en la parte “frontal” monolítica se genero un exportador de contenidos en formato JSON, de esta forma la aplicación accedería a los contenidos de las portadas. Es a partir de este punto en donde se realizaron platicas con el Director de IT de la casa editorial para mejorar el CMS y separarlo, de tal forma que no fuera un sistema monolítico.

Así es como el equipo de desarrollo empieza separar en bloques el complejo sistema, al tiempo que nacía un segundo sitio hermano. De forma paralela tome cursos sobre Docker, Kubernetes y todo lo que conlleva su orquestación y uso.

Una vez separados los CMS, me di a la tarea de generar las imágenes y la IaC (Infraestructure as Code) de cada uno de los componentes y generar las pruebas de conectividad.

Hoy en día, ambos sitios gozan de estabilidad y auto-escalado vertical y horizontal a libre demanda.

Mi lectura incluyo cursos sobre lo que Kubernetes era, como funcionaba, beneficios y los retos a resolver, despliegues blue/green, entre otros.

Previo a ello manejaba alrededor de 25 servidores en donde en conjunto se alojaban los Fronteds, APIs, Admin, cache, Base de Datos y servicios adicionales.

Hacer un despliegue en momentos operativos nos ocasiono en mas de una vez caidas donde tuvimos que hacer un rollback de emergencia.

Durante mi entrenamiento en Kubernetes tuve la experiencia de probar varios entornos CI/CD, entre ellos: Bitbucket pipelines, Circle CI, entorno local Jenkins.

Varios de los problemas que tuve, Codefresh ya los habia analizado y comparado, incluso mi entorno local infructuso de Jenkins -requiere de varios equipos y horas para tunning-, por lo que me di a la tarea de adentrarme en su interface y lenguaje yaml para codificar los pipelines y condicionales de despliegue.

Cabe mencionar que su equipo siempre estara listo para ayudarte, algo que tuve desde el primer momento que conoci a Maya -no es un bot- quien te dara una respuesta o canalizara con un especialista.

Codefresh te ofrece una version gratuita con una cantidad razonable de builds para que lo conozcas, las cuales agoté en el curso del PoC, ellos gentilmente me obsequiaron mas para concluir con mi Prueba de Concepto.

Codefresh esta basada en una tecnologia Docker in Docker, es decir, construyes tus imagenes Docker y testeas en un contenedor.

Codefresh no solo hace despliegues a entornos Kubernetes, tambien hace despliegues a entornos “Legacy”, esas apps que aun se resisten a migrar a este entorno.

Te preguntaras, mi cluster Kubernetes esta detras de mi firewall, puedo hacer el despliegue?, la respuesta es si, personalmente yo experimente este entorno con exito.

Codefresh se integra con cualquier proveedores de Kubernetes, incluidos los personalizados.” (ya que por medio de la opción “custom”, lo unico que se require es la IP/hostname, el certificado, etc.. y listo, ya nos podemos integrar.. sin importar donde este hosteado

Volviendo al tema de los despliegues, con Codefresh implemente su imagen de despliegue Blue/Green, imagina hacer un deploy de 16 contenedores de un microservicio sin tener una caida; con ellos fue posible hacerlo, incluso aplicar el escalado horizontal una vez que la nueva version ha sido publicada y recibir una notificacion en Slack en caso de exito o falla.

Estaras pensando en gitOps, por que no, recientemente vi un webinar donde usaron Terraform para hacer despliegues usando Github y Codefresh.

Por que no te das una vuelta por su sitio y pruebas las bondades que Codefresh tiene para ti, https://codefresh.io/