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
Dev
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.
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…
Bitwarden Cli
- post
- Xavi Aznar
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.
Guardar el estado de Terraform en MinIO
- post
- Xavi Aznar
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 )
He estado buscando información sobre cuál es la manera correcta a la hora de definir los nombres de las variables en Bash… Y como en el caso de la eterna batalla entre espacios vs tabs o Vim vs Emacs, parece que no hay una solución definitiva (o seguida por todo el mundo de forma generalizada).
En VSCode, cuando colocas el cursor sobre una palabra o para ser más exactos, sobre un “bloque de texto delimitado por espacios”, toda la palabra se destaca con un fondo de color más claro (en un tema oscuro).
El color del fondo es el mismo tanto si el todo el texto de la palabra está seleccionado como si simplemente el cursor está en alguna posición entre el principio y el final de la palbra, lo que no es lo mismo.
En esta entrada, indico cómo modificar el texto del resaltado que hace Visual Studio Code cuando seleccionamos una palabra o bloque de texto.
GitOps es una forma de gestionar los clústers de Kubernetes y el proceso de application delivery, según consta en la definición que hacen los inventores del término, el equipo de Weave.works en What is GitOps?.
El concepto gitOps proporciona un modelo operativo en el que el estado deseado del clúster (y de las aplicaciones desplegadas en él) se encuentra definido de forma declarativa en un repositorio Git.
Un agente se encarga de reconciliar el estado deseado (en Git) con el estado real (en Kubernetes), considerando -en general- como fuente de la verdad el contenido del repositorio.
Aunque Weave.works desarrolló inicialmente Flux (ahora forma parte de la CNCF), en este post hablaré de ArgoCD. Hay otras herramientas con las que implementar GitOps, pero sin duda Flux y ArgoCD son las referencias indiscutibles.