He estado pensando en algunas mejoras con respecto al uso de NATS para montar un sistema de pipelines basado en las ideas de la entrada anterior PubSub con NATS y Bash.
PubSub con NATS y Bash (II)
- post
- Xavi Aznar
Bash
Photo by Mabel Amber
PubSub con NATS y Bash
- post
- Xavi Aznar
Bash es increiblemente permisivo, por lo que se ha convertido en mi lenguaje de prototipado por defecto. Combinado con SQLite y Jq, me faltaba una última pieza para completar los diseños: un sistema pubsub. Ahora he encontrado una manera sencilla de integrar NATS (corriendo en Docker) con Bash.
Hace un tiempo encontré el repositorio yaacov/argparse-sh, del autor del artículo argparse.sh: Simple Yet Powerful Bash argument parsing. Como indica en el post,
argparse-shes una forma sencilla y potente de gestionar parámetros en Bash.La idea en la que se basa, creando un array asociativo (un
dictionaryen Python), me recordó a Cobra, en Go. Pese a ser una library pequeña, permite definir parámetros obligatorios y opcionales, un mensaje de ayuda para cada parámetro, diferentes tipos de parámetros…La “única pega” es que, debido a que usa arrays asociativos, require Bash 4 o superior.
Así que me puse manos a la obra para hacer un backport y hacerlo compatible con Bash 3 (la que hay por defecto en los Mac).
Cloud Workstations nos permite tener la misma máquina a todos los miembros del equipo, independientemente de si usamos un Mac o un equipo con Windows. Partiendo de una imagen de contenedor, podemos desplegar una máquina virtual y usar Code OSS (la versión open source de Visual Studio Code) con las mismas extensiones pre-instaladas, la misma configuración, etc…
Quiero presentar el script a mis compañeros antes de subirlo a Github, así que en la entrada de hoy me voy a centrar en explicar cómo he simplificado el número de parámetros requeridos para gestionar (crear/arrancar/detener/eliminar) una workstation sin tener que recordar (o conocer) el nombre del clúster, de la configuración usada, etc…
Unmarshal JSON en Bash (Parte II)
- post
- Xavi Aznar
Este artículo es la segunda parte de Unmarshal JSON en Bash (Parte I).
Al final de la primera parte vimos cómo el MVP (minimum viable product) no producía el resultado esperado para keys en el documento JSON cuyo valor es un array o un object.
En esta segunda parte, vamos a resolver este problema.
Unmarshal JSON en Bash (Parte I)
- post
- Xavi Aznar
Unmarshal es uno de esos verbos ingleses que es difícil de traducir al castellano, al menos para mí. Según Google, sería algo así como “desmantelar”.
Aplicado a la programación, “to unmarshal” está relacionado con la idea de que, partiendo de un contenido ordenado, en JSON, desperdigamos su contenido en variables que podemos utilizar en nuestra aplicación.
Go, por ejemplo, proporciona la función Unmarshal, sin embargo en Bash, no he encontrado nada parecido.
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?
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.
Cliente API en Bash (con curl)
- post
- Xavi Aznar
En una entrada anterior, Obtener respuesta y código de la petición HTTP con curl, explicaba cómo mejorar, en mi opinión, la relación con la API desde los scripts (en Bash) que se ejecutan desde una pipeline.
La idea que explicaba en el artículo era cómo usar el código HTTP devuelto por la función que expone la API para controlar posibles errores.
Como prueba de concepto fue satisfactoria, pero no resulta práctica aplicarla; en un caso real se usan múltiples documentos y la repetición del mismo código una y otra vez hace que se alcance el límite de cuatro mil caracteres en un paso de la pipeline…
Así que la solución es encapsular esta idea en una función en vez de repetir el mismo código una y otra vez: Don’t repeat yourself
Sacando partido de la funcionalidad de jq
- post
- Xavi Aznar
Siguendo con el tema de ayer, hoy quiero revisar otro bloque de código.
En este caso, se construye un array en JSON usando Bash puro, cuando es el proceso se simplifica enormemente gracias a la función
--slurpdejq.