Photo by Mabel Amber
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.
He intentado añadir un comentario al artículo How to Connect to EC2 with SSM (Session Manager)? pero no ha habido manera…
El autor indica que es necesario configurar la instancia para aceptar tráfico de entrada HTTPS 443 desde cualquier origen…
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.
Hace unos días leía en el foro de Kubernetes el caso de un usuario que no tenía claro cómo hacer que su aplicación fuera escalable, ya que al llegar a un determinado nivel de carga, la aplicación se saturaba.
El problema, por lo que entendí, es que la aplicación hacía “todo el trabajo”: recibía las peticiones de los usuarios, gestionaba las acciones para procesar cada petición y devolvía el resultado a los usuarios una vez finalizado.
Una solución rápida podría ser desplegar un horizontal pod autoscaler, pero probablemente lo ideal sería cambiar la arquitectura de la aplicación…
Así que me puse a ello en mi lenguaje de programación favorito: Go ;)
Habitualmente, al insertar un valor en el backend a través de la API, si la operación tiene éxito, se devuelve el identificador del registro creado.
En el tutorial de Jeremy Morgan Building a Web App with Go and SQLite, se devuelve un mensaje genérico {"message": "success"}, que no permite realizar acciones adicionales sobre el nuevo registro.
En esta entrada modificamos el código de la función AddPerson para devolver el identificador del nuevo registro.
En la entrada Mejora al tutorial ‘Building a Web App with Go and SQLite’: limitar el número de registros devueltos por defecto modificamos el código original del tutorial de Jeremy Morgan Building a Web App with Go and SQLite para que el usuario pudiera especificar el número de resultados devueltos al consultar la API a través del parámetro count: http://<URL>/api/v1/person?count=15.
El problema es que siempre se devuelven las entradas empezando por la de Id más bajo (habitualmente, 1).
En esta entrada, modificamos la función getPersonById para introducir también el parámetro count y que se devuelvan count resultados a partir del Id especificado.
