Para desplegar un clúster mono-nodo de Kubernetes usando K3s, he clonado una máquina virtual con Ubuntu Server 22.04 LTS que uso como “golden image”.
Una de las tareas que realizo sobre la máquina clonada es la de configurar una IP estática, pero siempre tengo que buscar cómo realizar esta configuración en Google, ya que nunca lo recuerdo.
El objetivo de esta entrada es servirme de recordatorio para el futuro.
Desde entonces uso Devcontainers más y más; por ejemplo, para desarrollar en Go ya no tengo que levantar una máquina virtual o instalar Go en mi equipo: genero un fichero devcontainer.json, indico la imagen oficial de Go y ¡listo!
No todo es perfecto; una de las cosas que últimamente estaba sufriendo es que Git no autocompleta, por ejemplo, los nombres de las ramas.
Uno de los problemas que he encontrado en mi reinterpretación de la API que uso en el trabajo ha sido la conexión con la base de datos.
Siguiendo las buenas prácticas, mi intención era reutilizar el cliente a la base de datos. En vez de usar una variable global, que suele ser la aproximación recomendada, guardaba la struct en el contexto de Gin.
Sin embargo, el contexto se propaga para una misma petición, pero no se mantiene entre peticiones… Así que para cada nueva petición que recibía la API se creaba un nuevo client 😞.
Todo lo relacionado con la base de datos se encuentra en su propio paquete, por lo que tendría sentido crear una variable “global” dentro del paquete…
Sin embargo, seguía quedando pendiente el tema de cerrar la conexión con la base de datos al finalizar la aplicación…
En esta entrada explico la solución que quiero probar (ya veremos si funciona 😉, parece que sí).
Apple no incluye versiones modernas de Bash; la versión incluida por defecto es 3.2. Esto se debe a que a partir de esta versión la licencia que cubre Bash es la GPLv3 y ésta obliga a compartir el código fuente, cosa que Apple no quiere hacer.
El caso es que ahora uso un Mac M2 para el trabajo y algunas funcionalidades como los arrays asociativos (name["dog"]="snoopy"), sólo están disponibles en Bash v4 o superior.
La solución más obvia, actualizar Bash manualmente en el Mac, es posible pero tiene inconvenientes. El Bash “nativo” de Mac OS se encuentra en /usr/bin, mientras que otra versión de Bash, sólo puede ser instalada fuera de /usr/bin, porque el Mac usa algo llamado System Integrity Protection, que evita la ejecución de código no autorizado. Aunque SIP puede deshabilitarse, no es una buena idea.
Dado que en Bash nuestros scripts usan el shebang#!/bin/bash (ver Shell Style Guide de Google), al ejecutar el script en Mac OS, se usaría Bash 3.2 y no la nueva versión (p.ej, Bash v5).
Ayer estaba revisando un script desarrollado por un compañero y me llamó la atención la manera en la que solucionaba un problema “habitual”: ¿cómo añadir una línea a un fichero sólo si no está ya presente?
El functional options pattern permite crear un objeto con un número arbitrario de “opciones” manteniendo siempre la signature de la función que lo crea.
La idea original fue propuesta, si no estoy equivocado, por Dave Cheney allá por 2014 en el artículo Functional options for friendly APIs. El artículo muestra múltiples maneras de atacar el problema y cómo las functional options es una de la soluciones más sencillas.
Imagina que quieres crear un objeto pizza. Pero no todo el mundo quiere la misma pizza; unos quieren masa fina, con extra de queso o con peperoni y champiñones, otros masa normal sin ningún extra o topping adicional, etc.
¿Cómo defines la función NewPizza para que puedas satisfacer a todos tus clientes? Tampoco quieres tener que cambiar la función cada vez que se añada una nueva opción o ingrediente a la pizza…
La solución son las funcional options.
Actualización: 26/12/2023
Algunos aspectos de este artículo quizás no están del todo bien explicados; por ejemplo, las propiedades en config están en mayúsculas (exportadas), por lo que se puede establecer sin necesidad de functional options. La signatura de la función NewClient es incorrecta, pues no incluye que devuelve (*DBClient, error)… En vez de corregirla, he creado una entrada más concisa y sin errores conocidos, al menos por ahora.
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.
