Yo, Claude
o como dos días con Claude Code me ayudaron con mis clases
Prólogo
El curso que estoy dictando, tiene como objetivo tocar diversos temas relacionados a la gestión de proyectos sobre Software. Me está gustando mucho ser profesor, pues además de dictar la clase, estoy aprovechando a leer mucho (posiblemente en algún momento escriba sobre los libros que me han servido para este ciclo).
Pero soy humano y, como tal, hay temas que me han entusiasmado más al enseñar. DevOps y observabilidad son de esos. Durante clases, se explicaron los pilares de observabilidad, qué implica DevOps o qué herramientas y/o proveedores nos pueden ayudar con esto. La clase fue amena y hubo consultas de los alumnos; pero con algo que me quedé fue que un alumno me sugirió que deberíamos tener un taller sobre esto. A este comentario, me dije: ¿Por Qué no?. Ya había hecho un taller previamente en clases, pero relacionado a calidad de software (en esa ocasión usando sonarqube). Solo me faltaba definir cómo plantear este taller (porque existen muchos componentes relacionados) y el otro es cómo puedo encontrar tiempo para poder tener algo lo suficientemente decente para presentar en clase.
Capítulo I: Claude
Llevo usando Claude Code de forma recurrente hace algunas semanas. Me gusta que puedo usarlo en la terminal (que es otro interés que he ido teniendo en los últimos meses, pero esa será otra historia 🐇) y tener la pantalla partida entre mi código por un lado y Claude Code en otro. Inmediatamente supe que Claude me ayudaría a poder construir la aplicación que iba a ser monitoreada y todos los demás componentes que formarían parte del taller en clases.
Capítulo II: Qué quería enseñar en clases
Aquí tenía que estructurar bien lo que quería hacer. Ya tenía una aplicación web hecha en Django para el taller anterior de seguridad, así que decidí que repotenciaría este repositorio. Primero, decidí que tenía que asemejarse lo más posible a un ambiente de producción, así que a agregar lo clásico: un Dockerfile para construir la aplicación como una imagen, Nginx para que pueda generar logs de los requests y Gunicorn para conectar Nginx con la aplicación Django. Con esos puntos listos, tocaría lo siguiente: armar un repositorio donde se encontraran Grafana junto con sus fuentes de datos. Aquí habría de definir un poco mejor qué tecnologías tendría que usar como fuentes de datos, así como también que dashboards. Esto me llevo a decidir que las fuentes de datos serían: Prometheus y Loki.
Capítulo III: Yo, Claude
Okey, con todo ya decidido, manos a la obra (con Claude). Primero, toca indicarle qué modificaciones necesitaba dentro del repositorio usando Django: Claude, agrega Nginx y Gunicorn al repositorio. Claude, modifica el Dockerfile para que exponga ya no la aplicación de Django directamente, sino mediante Nginx.
Luego de eso, armar el repositorio donde se encuentre Grafana, Prometheus y Loki. Aquí, tuve que decidir qué dashboards quería utilizar. Felizmente, existe una página dentro de grafana con dashboards habilitados para su descarga. Con estos puntos, a indicarle a Claude que pueda generar el archivo docker compose con los servicios que necesitaba, que pueda configurar los servicios de Prometheus y Loki; y por último, que pueda descargar los dashboards indicados para tenerlos en los repositorios (este punto es vital, para que en clases se pueda examinar de forma visual todo lo aprendido).
Último paso: indicarle a Claude que integre el repositorio con la aplicación Django y lo envie a Prometheus y Loki. Aquí toca decidir donde quiere que se encuentren estos exporters. Me hizo más sentido que estén en la aplicación Django: Claude, agrega prometheus-nginx-exporter y promtail para que exporten datos hacia Prometheus y Loki.
Con los repositorios completos (y obviamente, validando que funcione) ya está todo listo para ser presentado en clases.
Capítulo IV: Claude strikes back
En clases, el taller considero que fue bien, todo funcionó y los alumnos pudieron ver como funciona en sus entornos locales. Hubo algunas dudas muy buenas sobre las tecnologías y cómo se comunican, que sirvieron para explicar múltiples conceptos sobre la arquitectura escogida (particularmente una sobre por qué obtenemos los logs de nginx y no sobre la capa de aplicación). Pero, me quedó algo pendiente: sentía que los gráficos están muy vacíos, no había mucha data. En este punto toca preguntarme, como hago para que pueda haber más data sobre la cual explorar.
Hace un tiempo, un amigo me comentó sobre usar K6 para hacer pruebas de performance en las aplicaciones web y enviar sus resultados a Grafana. Siempre me quedó poder hacer esa implementación, así que decidí que para la siguiente clase, reforzaría el taller con algunos temas más de observabilidad y agregaría data generada mediante pruebas de performance de K6 para que los alumnos pueda explorar los resultados.
Entonces nuevamente: Claude, agrega nuevas fuentes de datos al repositorio de grafana, quiero influxdb y Tempo. Claude, reemplaza promtail por Alloy en el repositorio de Django. Claude, agrega opentelemetry al repositorio de Django y envia esos datos a Alloy. Claude envía los datos de Alloy a Tempo y Loki. Claude, arma un repositorio donde hayan pruebas hacia la aplicación de Django y envia los datos a influxdb.
Con esto estos cambios, se pudo presentar todo en el siguiente taller y se logró un entendimiento algo más amplio de una gran parte de los conceptos de observabilidad. También surgieron algunas dudas, pues en este punto la arquitectura ya es algo más complejo, pero felizmente está siempre la pizarrita para poder explicar todo esto a más detalle.
Epílogo:
Bueno, esto es el fin de esta narración, fue una experiencia muy divertida y muy educativa. Me queda pendiente aun mejorar estos repositorios: me falta agregar algo que pueda ingestar métricas de bases de datos, y ver la forma que las trazas tengan más información; pero todo eso puede ser para una nueva oportunidad. 🚀🚀🚀
Nota de Autor:
Las instrucciones a Claude han sido reducidas con fines de esta narración. Han sido algo más complejas las instrucciones 😅
Todo lo desarrollado para esta clase tenía un fin más demostrativo para explicar conceptos que para usar en un ambiente de producción. Para ambientes de producción sí hay que revisar mucho más las configuraciones realizadas en las diversas herramientas.
Si existe algún interesado, estos son los repositorios:
Aplicación Django: https://github.com/gustavopp93/django-quality-demo
Grafana y sus fuentes de datos: https://github.com/gustavopp93/grafana-demo
Pruebas usando K6: https://github.com/gustavopp93/k6-demo