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.
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…
A raíz de la entrada anterior GitOps con ArgoCD - Instalación y acceso a la consola he visto que la versión desplegada en el clúster de laboratorio era la 2.2.1, mientras que la versión actual es la 2.2.5.
Antes de actualizar, al tratarse de una versión patch release, no es necesario tener en cuenta ninguna consideración especial, según se indica en la documentación oficial Upgrading > Overview.
Sin embargo, aplicando el fichero correspondiente a la última versión estable, se sobreescriben los ConfigMaps de configuración, por lo que las modificaciones realizadas se pierden; en mi caso, la configuración del modo inseguro necesario para el acceso a través de un ingress.
Como solución temporal, se puede aplicar de nuevo el fichero con el ConfigMap y ejecutar kubectl -n argocd rollout restart deploy argocd-server.
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.
Hace unas entradas, en
Crear usuarios en Kubernetes (y en K3s), escribía sobre cómo generar nuevos usuarios con acceso al clúster de Kubernetes usando un fichero kubeconfig.
El método descrito implicaba extraer fuera del clúster el certificado privado de la entidad certificadora (CA) de Kubernetes, lo que no me parecía la mejor solución.
Desde Kubernetes 1.19 existe un nuevo recurso en la API, el CertificateSigningRequest, que permite firmar certificados para proporcionar acceso (por ejemplo) al clúster.
En esta entrada se describe cómo aprovechar esta nueva funcionalidad para dar acceso a un usuario usando un certificado firmado por la CA del clúster.
En la entrada Envío de eventos de CloudFormation a CloudWatch Events explicaba una manera alternativa -sin Lambdas- para enviar notificaciones SNS con información de ARNs de recursos generados en CloudFormation a través de CloudWatch Events.
En esta entrada explico cómo he realizado una prueba de concepto para validar que es viable.
Con Ansible podemos automatizar la gestión de la configuración de las máquinas virtuales (o no) que creamos. Pero para poder explotar la potencia de Ansible necesitamos que la máquina gestionada cumpla unos requisitos previos: disponer de Python 2.6 o superior y que Ansible pueda conectar con la máquina.
Todas estas tareas se pueden automatizar, así que vamos a ver cómo conseguirlo.
En la entrada anterior explicaba cómo automatizar la instalación de Gitea usando un script y Docker.
Todos los pasos necesarios para crear los volúmenes de datos, la red interna entre Gitea y la base de datos, etc usan Docker.
En esta entrada usaremos Docker Compose para obtener el mismo resultado y analizar las diferencias entre los dos métodos de instalación.
