Ha pasado algo más de un mes desde la última entrada en el blog… Así que en vez de escribir una entrada como si no hubiera pasado nada, he decidido crear ésta entrada para comentar qué he estado haciendo…
De vuelta al Blog
- post
- Xavi Aznar
Posts
Photo by Mabel Amber
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.Llevo una temporada revisando código -MUCHO, MUCHO código- en Bash.
Como parte de uno de los steps de ejecución de una pipeline, se consulta una API para obtener o actualizar información de una base de datos y hacer cosas con esa información, como desplegar recursos en un proveedor cloud (usando la cli) o lanzando Terraform.
Uno de los patrones que me encontrado a la hora de interaccionar con la API es el siguiente:
- Generar el payload en JSON y guardarlo en una variable.
- Ejecutar la petición usando
curly guardar la respuesta en un fichero. - Filtrar la respuesta usando
jqleyendo el fichero.
Tras solucionar los problemas con Vagrant al actualizar a PoP_OS! 22.04 (basada en Ubuntu 22.04), encuentro otro problema relacionado también con SSH :(
k3sup, el instalador de clústers de Kubernetes usando k3s, no puede conectar con las máquinas virtuales basadas en la imagen ubuntu/jammy64 (la nueva versión de Ubuntu 22.04).
La solución para el Error en Vagrant tras actualizar a Pop_Os! 22.04 es la instalación de una versión concreta del software, en este caso, la 2.2.19.
TL,DR; Solución en Vagrant up error on Ubuntu 22.04: pkeys are immutable on OpenSSL 3.0
Ayer actualicé a la nueva versión de PoP_OS!, basada en Ubuntu 22.04 LTS. Todo funcionó de maravilla, como debe ser. El único problema -por llamarlo de algún modo- identificado tras la actualización ha sido la pérdida de la configuración de Cool Retro Term; no big deal…
Cockpit: Cannot refresh cache whilst offline
- post
- Xavi Aznar
Hoy he instalado Cockpit y después de configurar una IP estática para el servidor que uso de laboratorio, la sección Software Updates ha dejado de funcionar, mostrando el mensaje de error
Cannot refresh cache whilst offline.La solución la he encontrado en Cockpit – “cannot refresh cache whilst offline”.
El título tiene una sonoridad un poco a click bait, así que explicaré rápidamente a qué me refiero.
Hace poco que hemos empezado a colaborar en un proyecto nuevo. Mientras nos vamos poniendo al día estoy ayudando a uno de mis compañeros -un crack en networking- con temas relacionados con contenedores, con los que está menos familiarizado.
Revisando los ficheros de configuración de Google Cloud Build, encontramos, en el mismo fichero, referencias a la imagen de un contenedor como
hashicorp/terraform:latest, otras en las que el nombre es de la formagcr.io/cloud-builders/gcloudy otras en las que es, simplemente,alpine.Y claro, mi compañero no entiende nada…
Estaba leyendo las nuevas entradas en el foro de Kubernetes y me he encontrado con Getting Pod ID and container ID of a container when it restarts.
La pregunta es cómo obtener el identificador de un pod (y de un contenedor dentro del pod) cuando éste se reinicia. Lo curioso -al menos para mí- es que esa información es necesaria porque hay otro pod que monitoriza el primero que necesita esta información (supondo que para identificar el pod monitorizado).