Photo by Mabel Amber
Desde hace unos días he empezado a usar de forma exclusiva un teclado Magic Keyboard, tanto con mi equipo de trabajo (un Mac) como con el personal (con Linux - Pop!_OS).
Como el teclado no incluye una tecla dedicada PrtSc, en esta entrada indico cómo asignar una combinación de teclas en Pop!_OS para realizar capturas de pantalla.
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).
El CIS publica imágenes hardenizadas en el Marketplace público de Google Cloud Platform (GCP). Estas imágenes se actualizan de vez en cuando, por lo que es importante usar siempre la versión más actualizada.
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).
Después de un tiempo focalizado casi exclusivamente en aprender Go, hoy he vuelto a mis raíces: Kubernetes.
En el repositorio onthedock/vagrant tengo los scripts que me permiten desplegar varias máquinas virtuales usando Vagrant, instalar K3s y configurar un clúster de Kubernetes con (en este momento) un nodo master y dos workers. Como parte de la automatización, también despliego Longhorn como storageClass .
Hoy he testeado con éxito el despliegue de ArgoCD y Gitea en el clúster, dando un pasito adelante para desplegar una plataforma completa de desarrollo sobre Kubernetes.
