Photo by Mabel Amber
En la entrada anterior k3d: desplegar un clúster de Kubernetes como código incluí un registry en el despliegue del clúster con k3d.
En esta entrada veremos cómo usarlo para desplegar aplicaciones en el clúster.
Ya he hablado de k3d otras veces en el blog; del mismo modo que kind permite desplegar Kubernetes en Docker: cada nodo del clúster se ejecuta en un contenedor.
k3d hace lo mismo pero en vez de Kubernetes vanilla, usa la distribución ligera de Kubernetes, k3s.
Este fin de semana he actualizado la documentación del repositorio onthedock/k8s-devops en lo relativo a k3d y he aprovechado para explorar un par de cosas nuevas: deplegar el clúster de forma declarativa (como código) y el uso del registry interno en k3s.
En este artículo me centro en la primera parte: el despliegue del clúster como código.
El ejemplo habitual para introducir los sparse checkouts es cuando todo el código de un equipo se encuentra en un mono repo, es decir, un repositorio para todo. En el repositorio cada “carpeta” contiene el código de un microservicio, por ejemplo…
En esta situación, un miembro del equipo tiene que clonar el repositorio entero aunque sólo tenga que trabajar en una parte muy pequeña del mismo, generalmente circunscrita a una funcionalidad que se encuentra en una carpeta del repositorio.
Del mismo modo, para compilar el código de uno de los microservicios de este mono repo, es necesario clonarlo completamente…
En este tipo de situaciones es cuando podemos usar git sparse-checkout.
Hace unas semanas comentaba que estaba trabajando en un proyecto personal para implementar un parseador de reglas para el proxy, en Go.
Después de leer los artículos Write packages, not programs y From packages to commands de John Arundel (así como los artículos a los que enlaza), decidí enfocar de manera diferente el parseador de reglas del proxy.
Empecé a escribir un nuevo módulo rules guiado por tests…
El resultado se encuentra disponible en ontehdock/proxy-rules en Github, pero aquí apunto algunas pinceladas (a modo de notas personales).
En la entrada Convertir CSV en JSON con Jq comentaba cómo realizar la conversión de un fichero CSV en JSON usando Jq.
En esta entrada repito (parcialmente) el ejercicio, pero usando Go.
Al definir un documento JSON, los campos pueden tener diferentes tipos, como string, number, boolean, etc… Sin embargo, al crear un documento usando --arg, el valor siempre se trata como string:
--arg name value:This option passes a value to the jq program as a predefined variable. If you run jq with –arg foo bar, then $foo is available in the program and has the value “bar”. Note that value will be treated as a string, so –arg foo 123 will bind $foo to “123”.
Una de las automatizaciones que hemos desarrollado consiste en un autoservicio para que los clientes puedan gestionar políticas en un proxy.
El usuario genera un fichero CSV con varios parámetros y los “sube” a un repositorio Git en su proyecto. El evento desencadena la ejecución de una pipeline en la que procesamos el fichero, validamos su contenido, etc. Una vez procesados, construimos un objeto JSON para cada una de las reglas, las agregamos y finalmente las integramos en el documento de configuración del proxy del cliente (que contiene otros campos que el cliente no debe editar).
Hace unos días me topé con el vídeo Why You Shouldn’t Nest Your Code del canal CodeAesthetic de YouTube. Me recordó en cierto modo al artículo de Mat Ryer Code: Align the happy path to the left edge.
Aprovechando la calma de estos días, he revisado algo del código que tenemos en algunas de nuestras pipelines. He aplicado las ideas explicadas en estos artículos y el incremento en la claridad del código ha sido espectacular.
En entradas anteriores he escrito sobre cómo interaccionar con una API a través de scripts en Bash, usando curl y poco más… En vez de dejar en manos de los usuarios la tarea de generar el payload que enviar vía curl a la API, desarrollé un cliente en Bash: Cliente API en Bash (con curl).
Desde entonces, he estado trabajando en una versión en Go del cliente para ésta API… Y creo que ¡ya está lista 🎉!
En esta entrada, describo por encima cómo funciona, pero sobre todo cómo ha sido la experiencia de desarrollarla.
En esta entrada describo un caso práctico sobre cómo manipular un documento JSON (una IAM Policy de Google Cloud) para añadir un nuevo miembro a un rol determinado.
Las políticas pueden gestionarse directamente mediante la herramienta de línea de comandos gcloud, por ejemplo, sobre un folder. Sin embargo puede ser interesante disponer de un registro con el estado deseado de los permisos de los recursos y así evitar drift (por ejemplo, si alguien modifica los permisos mediante gcloud o desde la consola).
Aunque el ejemplo se centra en un fichero de políticas de GCP, la entrada describe técnicas aplicables a la manipulación de cualquier fichero JSON.
