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 --slurp
de jq
.
Photo by Mabel Amber
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 --slurp
de jq
.
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:
curl
y guardar la respuesta en un fichero.jq
leyendo 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…
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 forma gcr.io/cloud-builders/gcloud
y 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).
Hoy en día es obligatorio usar un gestor de contraseñas. En mi caso, uso Bitwarden (la edición Personal).
Como cada vez paso más tiempo en la línea de comandos, he decido probar la versión CLI de Bitwarden.
Terraform almacena el estado de la configuración en un fichero. Este fichero es crítico para que Terraform pueda mantener la coherencia entre el estado definido en los ficheros de configuración y el estado real de la infraestructura desplegada.
Por defecto, Terraform almacena el estado de forma local; para facilitar la colaboración entre diferentes miembros de un equipo -entre otros casos de uso-, Terraform ofrece la posibilidad de usar otras ubicaciones para guardar el estado. Estas ubicaciones reciben el nombre de backends en Terraform (y hay unos cuantos disponibles, como puedes observar desplegando la entrada Available Backends en la web de Terraform).
Una opción habitual es la de usar un bucket en un servicio como S3 de AWS como remote backend. Pero si no tienes acceso a una cuenta de AWS, puedes usar MinIO para trabajar con un backend de tipo S3 de forma completamente offline (por ejemplo, para aprender cómo funciona Terraform ;-D )