DEV Community: Jorge

Tired of AI

Jorge — Tue, 29 Jul 2025 05:23:17 +0000

now I understand what feel my seniors when I was all the day refactoring VBasic Desktop application to Web application in the old K2 days

QaQatua

Jorge — Fri, 21 Mar 2025 00:00:00 +0000

Hace unas semanas le eché una mano a un amigo QA, Oscar Islas, a "aterrizar" una idea con la que andaba trabajando y que me resultó muy atractiva desde el primer momento.

Como QA muchas veces tienes que preparar flujos de pruebas contra servicios que manejan información "sensible", por ejemplo "cuenta bancaria", "password", etc.

Algunos de estos servicios requieren el uso de criptografía de tal forma que estos campos van encriptados junto con el resto y a su vez son devueltos encriptados.

De cara al desarrollo no deja de ser "una capa más". Quiero decir, cuando desarrollo mi programa para enviar/recibir estos payloads, configuro mi aplicación con las claves publicas/privadas que el admin del entorno me proporcione y con unas cuantas líneas de código encripto/desencripto los mensajes.

El trabajo del QA es más laborioso. Debe preparar juegos de prueba que contemplen todos los escenarios así que le toca o bien pregenerar los mensajes o incluir algun tipo de librería que le haga lo mismo que hace el programador lo cual tampoco es fácil

Oscar Islas se enfrenta casi a diario a este tipo de situaciones. Como usa Postman pudo desarrollar una pequeña librería Groovy que embeber a la que invoca para que le haga el trabajo de encriptar/desencriptar payloads.

Tras echarle una mano revisando y poniendo a punto la librería Groovy se nos ocurrió que esta funcionalidad podría ser una buena herramienta para la comunidad y así comenzamos QaQatua (un giño a QA y a la funcionalidad que implementa que no deja de ser una cacatua que repite lo que le dices)

Idea

Básicamente QaQatua es una aplicación web que, tras configurarla, permite transformar las partes de un payload que le indiques tanto para encriptar como para desencriptar.

Así pues el "flujo" de un usuario (QA principalmente) sería:

preparar una prueba con datos "en claro"
invocar al endpoint QaQatua de encriptación, el cual le devolverá el payload transformado
invocar al servicio con el payload obtenido de la llamada a QaQatua
invocar al endpoint QaQatua de desencriptación, el cual le devolverá el payload transformado
validar que los campos retornados, ya "en claro", son los esperados

Usando Postman, SoapUI, o simple scripts con curl el uso es sencillo y evita tener que añadir dependencias a la herramienta

QaQatua

QaQatua permite a un usuario registrarse en el sistema mediante email/password.

Una vez identificado, el usuario puede crear hasta 3 proyectos, proporcionando un nombre identificativo a cada uno.

Cada proyecto consta de los siguientes campos:

fields, una lista de campos, separados por comas, a modificar en los payloads.
priv/pub keys, una pareja de clave pública/privada para operar con el payload.

Si el usuario no quiere "complicarse" con la gestión de claves puede solicitar a QaQatua que genere un juego de claves.

En cualquier caso estos tres campos son editables en todo momento por lo que puede empezar a diseñar sus casos de prueba y posteriormente proporcionar las claves que requiera el servicio a invocar.

Así mismo, al permitir más de un proyecto, es fácil crear casos de pruebas donde intervienen más de un servicio cada uno con claves diferentes.

Api

QaQatua ofrece un API realmente sencillo:

/api/projects:
-- get/post/put/delete
/api/encrypt:
-- post
/api/decrypt:
-- post

Además de contar con un interface Web, el api de projects permite la gestión vía REST

Los endpoints de encrypt/decrypt son altamente configurables y permiten especificar qué proyecto usar en cada petición (si el usuario tiene sólo un proyecto se usa por defecto) e incluso añadir fields a usar en una petición específica

Conclusion

En los próximos posts iremos contando más detalles de este proyecto, como tecnología usada, casos de éxito, nuevas funcionalidades, etc.

Clean your dockers trash

Jorge — Tue, 03 Dec 2024 09:03:49 +0000

Your computer is claiming your hard disk is running out of space?

If you use Docker frequently, probably pulling images, building new images to push, testings docker-compose files, ... and you don't clean once you don't need anymore them, soon or later you'll run out of space in your hard drive.

This happened to me yesterday so I executed:

$ docker system prune --all -f --volumes
....
a few minutes later
....
some minutes more
...
Total reclaimed space: 361.6GB

361 GB recovered !!!

But pay attention because this command will remove all images and volumes in your system which are not used at this moment so you can lost some important data (as a mysql-volume with a backup of the prod database ejem ejem)

Reading millions of json items

Jorge — Thu, 21 Nov 2024 18:27:28 +0000

I have wrote an small example to read a big file (vía http) with an array of items in json

10 millions are parsed in 5sec in my laptop!!!

https://github.com/jagedn/huge-json

the only one tool you need to be a good dev

Jorge — Tue, 22 Oct 2024 08:24:07 +0000

Cuando te rechazan por tu nivel de inglés

Jorge — Tue, 01 Oct 2024 17:26:23 +0000

from aguilera.soy to jorge-aguilera.blog

Jorge — Thu, 26 Sep 2024 10:51:56 +0000

A few days ago I've migrated my personal blog from "jorge.aguilera.soy" to "jorge-aguilera.blog"

the migration was as simple as run a cp -R blog/* newblog/* as I'm using a static site blog

no database, no exports, no imports, only provision a new domain name and a copy

but the shock come to me when I've checked the visits stats and verified I've doubled the numbers!!!

same blog, no (yet) new contents, ...

Also I could see a significant increment in USA visitors. Although I'm trying to write more post in English most of my content is still in Spanish

Thanks to @litlyx for this super-simple-util tool

CorreQueVuelan addons para Firedox

Jorge — Sat, 21 Sep 2024 20:56:51 +0000

He creado una extension para #Firefox, CorreQueVuelan, útil si usas el servicio de Bicimad para ir y venir al trabajo

Es muy común que llegada la hora de salida del trabajo, la estación se vaya quedando sin bicis libres, así que la idea es una extensión del navegador que va a estar consultando la disponibilidad y te muestra un icono cuando queden pocas ... corre que vuelan

Una vez instalada la extension te aparecerá el icono de una bicicleta

en la configuracion de la extension indicas la estacion que tienes más cerca (en futuras versiones podria hacer que usara tu ubicacion)

en cualquier momento puedes consultar cuantas bicis quedan libres simplemente pasando el rato por encima de la extension

Y cuando queden pocas bicis la extension mostrará un icono para llamar tu atención para que salgas corriendo sin salvar lo que estés haciendo

La URL por si quieres instalarlo

https://addons.mozilla.org/es/firefox/addon/correquevuelan/

RemoveCookieWall, una extension de Firefox

Jorge — Wed, 11 Sep 2024 00:00:00 +0000

¿Harto del banner que se ha puesto de moda en las webs para que aceptes cookis de terceros o pases por caja? En este post explico cómo me hecho (y publicado) una extensión de Firefox para evitarlo en la mayoría de sites

INFO: El código de esta extensión está publicado en https://github.com/jagedn/removecookiewall-addon y lo puedes instalar en Firefox (también en móvil) desde https://addons.mozilla.org/es/firefox/addon/removecookiewall/

Desde hace unos meses, y por una exigencia de Europa (creo), la mayoría de las webs te muestran un banner la primera vez que accedes a ellas que no te dejan continuar hasta que no decides entre:

te voy a colocar miles de cookies de terceros en tu navegador que van a espiar lo que navegas
pasa por caja y págame para que no lo haga

La mayoría de estas librerias ejecutan un javascript nada más cargar la página que leen tus cookies. Si ven que no has pasado por caja te muestran un dialogo HTML y bloquean el body cambiando el style a "block" (o similar)

Este diálogo no te deja leer lo que hay debajo pero … no deja de ser un elemento DOM del HTML, así que, como los navegadores te permiten abrir una consola de desarrollo e inspeccionar el HTML, me surgió la idea de eliminar manualmente el díalogo (simplemente le das a inspeccionar, buscas en el HTML donde está definido y le das a suprimir) y chimpón, el diálogo desaparece. Luego busco la declaración del "body" y dando doble click en el atributo style le quito la propiedad que lo bloquea y ya puedo hacer scroll.

Poca magia.

Qué es lo que está pasando entonces? Pues simplemente el código javascript sigue esperando que le llegue un evento de usuario diciendole qué botón has pulsado, pero estos botones ya no están, así que nunca le llegará y no te instalará cookies de terceros.

Ok, pero ¿y si refresco la página?. Pues vuelta a empezar … así que esto es perfecto para una nueva extensión del navegador que lo haga por mí.

Extension RemoveCookieWall

Una extensión Firefox, de forma resumida, es un espacio de memoria del navegador reservado donde se ejecuta un código javascript que puede dialogar con él.

Puede (si le concede permisos el usuario) inyectar código en las páginas que visitas, abrir pestañas, cerrarlas, comunicarse con servicios remotos, …

RemoveCookieWall es una extensión de Firefox que lo "único" que necesita es que el navegador inyecte en todas las páginas que el usuario visita un pequeño código javascript.

Este javascript según se ha cargado la página inspeccionará si existe un elemento DOM que coincida con alguno de los que he investigado que ese están usando. Si lo detecta usará funciones standard de Javascript para borrarlo.

Como el banner a veces puede aparecer (mili)segundos después de que nuestro código se ejecute lo que hace el script es repetir la búsqueda durante un par de segundos. Pasado este tiempo si el banner no ha aparecido la extensión asume que la página no tiene un CookieeWall y termina

Y esto es todo. Sólo queda empaquetar el código, añadir un fichero Manifest que indique los permisos que requiere nuestra extensión y publicarlo en Firefox

Código

El código JS básicamente es:

var readyStateCheckInterval;
var counter = 0;

function sanitizeBody() {
    document.body.style.overflow = "unset"
    document.body.classList.remove('sxnlzit')
    document.body.classList.remove('didomi-popup-open')
    document.body.parentNode.classList.remove('sp-message-open')
}

function removeMe(element) {
    element.remove();
    sanitizeBody();
}

readyStateCheckInterval = setInterval(function() {
    if (document.readyState === "complete") {
        counter++;
        const removeParent = ['div.pmConsentWall']; //elpais
        [...removeParent].forEach(s => {
            var divs = document.body.querySelectorAll(s);
            [...divs].forEach(element => {
                removeMe(element.parentNode);
            });
        });
        const removeThis = [
            'div[data-nosnippet="data-nosnippet"]',
            '#mrf-popup',
            '#didomi-popup',
            '[id^="sp_message_container_"]',
            '#cl-consent',
            'dialog.cookie-policy'
        ];
        [...removeThis].forEach(s => {
            var divs = document.body.querySelectorAll(s);
            [...divs].forEach(element => {
                removeMe(element);
            });
        });
        if (counter > 30) {
            clearInterval(readyStateCheckInterval);
        }
    }
}, 100);

Nada más ser inyectado el código en la página se inicia un interval cada 100 milis

El scrip busca si el document.body.querySelectorAll encuentra algún elmento tipo #mrf-popup, #didomi-popup, etc. Si lo encuentra simplemente lo elimina con element.remove()

Después de unos cuantos intentos termina borrando el interval

Toda extensión tiene que tener un fichero Manifest. El de esta extensión es simplemente:

{

    "description": "Remove CookieWall",
    "manifest_version": 2,
    "name": "RemoveCookieWall",
    "version": "0.11",
    "homepage_url": "https://github.com/jagedn/removecookiewall-addon",
    "icons": {
        "48": "icons/border-48.png"
    },
    "content_scripts": [{
        "matches": [
            "*://*/*"
        ],
        "js": ["removeCookieWall.js"]
    }],
    "browser_specific_settings": {
        "gecko": {
            "id": "remove-cookiewall@aguilera.soy"
        }
    }
}

Como ves, content_scripts indica que queremos inyectar el js en todas las páginas. Otras extensiones pueden indicar sólo un site, otras ejecutar un javascript en backuground, …

Build and publish

Para publicar en Firefox simplemente tenemos que proveer un zip donde esten todos los ficheros que requiere la extension. Para hacerlo fácil me he hecho un build.sh que simplemente ejecuta el zip:

zip -r -FS ../remove-cookiewall.zip * --exclude '.git' --exclude 'build.sh'

Publicar una extension en Firefox no tiene ninguna complicación y es gratis. Lo único que tu extensión tiene que pasar una revisión inicial que puede tardar uno (o varios) días

Porqué leer Neuromante en el 2024

Jorge — Sun, 08 Sep 2024 20:23:42 +0000

Estas vacaciones me he llevado un libro conmigo que compré allá por el 1995 y que había intentado leer un par de veces sin conseguir terminarlo

Pero esta vez lo he leído casi del tirón

Seguramente mucha gente lo habrá leído y entendido a la primera, pero a mí se me hizo bola.

Puede que ahora, en el 2024, cuando The Matrix ya va por su veteasaber parte y me la he visto muchas veces, o que el concepto de la AI está tan de moda, o que ya haya madurado, el caso es que ahora es un libro más fácil de entender, y no por ello más simple

Jonny Nmenomic, Microsoft, Matriz, son creaciones de un chaval que en 1984 imaginó un futuro cyberpunk al que nos acercamos peligrosamente

En fin toda una obra de arte IMHO

Apisix Gateway con autentificación Keycloak (y SSL con Caddy)

Jorge — Fri, 06 Sep 2024 00:00:00 +0000

En este post voy a instalar en una máquina (linux obviamente) desde cuasi-cero un stack que nos permita tener un acceso https a unos microservicios pasando por un api gateway (con Apisix) que dialogará con Keycloack para gestionar la autentificación y autorización del usuario a los mismos.

De forma visual la arquitectura será algo parecido a:

Proyecto

La idea del proyecto es crear un stack en Internet de tal forma que se expongan unos servicios a los que el usuario accederá previa identificación.

Dicha identificación podrá ser mediante usuario/password o bien mediante un proveedor de identidades, en este caso Linkedin (de igual forma puede ser Github, Gitlab, Google, etc.)

El acceso a los servicios se realizará mediante https y la gestión de la autentificación residirá en una pieza ajena a los servicios. Estos recibirán una cabecera con un JWT donde podrán extraer la información del usuario sin preocuparse de cómo se ha obtenido.

Requisitos

Una máquina Linux (la mia tiene 2GB de memoria y unos pocos gigas de disco)
Tener acceso como root (seguramente podrías con otro usuario pero no me voy a complicar)
Docker instalado
Un dominio en internet (para este post usaré apisix.edn.es)
Una entrada en el DNS que apunte a la IP pública de la máquina
acceso ssh a la máquina.
si se desea probar la integración con Linkedin (o similar) se necesita crear una App en https://developer.linkedin.com/ y generar un ApiClient y SecretClient

Crear un dominio/subdominio suele tardar unos minutos, al igual que la propagación de la entrada DNS. Recomiendo hacer esto lo primero para que se vaya realizando la propagación DNS y así Caddy aprovisionará un certificado sin esperas.

Recomiendo tener todos los puertos de la máquina expuesta a internet cerrados (e incluso cambiar el puerto por defecto 22 de ssh a otro) salvo el 80 y el 443. El puerto 80 es necesario para que Caddy pueda gestionar la provisión del certificado

Servicios Web

La idea es tener nuestros microservicios "limpios" de cualquier lógica de identificar a un usuario. Simplemente recibirán un JWT donde podrá extraer el nombre, email, etc.

Para este ejemplo vamos a usar una imagen httpbin.org que simplemente muestra los parámetros que se le envían en la petición y así comprobar que el servicio recibe dichos parámetros.

Así mismo vamos a crear dos servicios, web1 y web2 para darle más contenido y poder explorar cómo manejarlos con Apisix

docker-compose.yml

services:
  web1:
    image: kennethreitz/httpbin

  web2:
    image: kennethreitz/httpbin

Caddy

Caddy es un reverse proxy que gestiona de forma automática el aprovisionar un certificado SSL con Let’s Encrypt de tal forma que será nuestra "puerta de entrada" al sistema mediante https. Una vez que securiza la conexión con el cliente mediante SSL realiza la labor de reverse proxy y le pasa la petición al servicio que se le indique

docker-compose.yml

  caddy:
   image: caddy
   ports:
     - "80:80"
     - "443:443"
   volumes:
     - ./caddy/data:/data/
     - ./caddy/config:/config/
     - ./caddy/Caddyfile:/etc/caddy/Caddyfile

La configuración es además bastante simple, al menos para el alcance de este artículo:

caddy/Caddyfile

{
  email TU_EMAIL@TU_EMAIL
}

apisix.edn.es {
  reverse_proxy http://apisix:9080
}

En este fichero indicarás tu correo y el dominio a usar ( apisix.edn.es en mi ejemplo)

Una vez que Caddy resuelve el SSL realizará el reverse proxy hacia el servicio apisix que crearemos a continuación

Keycloak

Keycloak es un sistema de autenticación y autorización seguro (Open Source). Es decir, es el encargado de "gestionar los usuarios" y los "accesos a los recursos"

En su uso más básico podremos dar de alta usuarios vía interface web y los servicios podrán dialogar con él para validar si un usuario es quien dice ser y saber a qué tiene acceso.

También puedes conectarlo con directorios de usuarios típicos en empresa (Kerberos, Active Directory, etc.) e incluso usar identity providers como Google, Linkedin, Github, etc.

Para este ejemplo vamos a crear un usuario con el interface web y además añadir Linkedin como identity provider (es decir, un usuario podrá identificarse mediante user/password o usando su cuenta de Linkedin)

docker-compose.yml

  keycloak:
    image: quay.io/keycloak/keycloak:25.0
    container_name: keycloak
    env_file:
      - .env
    command: start-dev
    depends_on:
      - keycloakdb
    ports:
      - 8080:8080

  keycloakdb:
    image: postgres:15
    volumes:
      - postgres_data:/var/lib/postgresql/data
    env_file:
     - .env

El interface de Keycloak realiza dos funciones:

mostrar el dialogo para autentificar un usuario
mostrar el dashboard de admin que permite la configuración y gestion del propio Keycloak

Obviamente NO queremos que el dashboard esté accesible a todo el mundo así usaremos las variables de entorno que nos ofrece para configurarle dos URLs diferentes. Una será accesible a todos los usuarios que quieran acceder a nuestro sistema y otra sólo estará disponible para administradores

Para nuestro ejemplo estas URLs serán:

.env

Usamos un fichero .env para tener en un sitio las variables de entorno de configuración, así como usuarios y password de sistema, así que este fichero NO debería ser versionado

.env

KC_DB=postgres
KC_DB_URL=jdbc:postgresql://keycloakdb:5432/keycloak
KC_DB_USERNAME=keycloak
KC_DB_PASSWORD=password

KC_HOSTNAME=https://apisix.edn.es/keycloak
KC_HOSTNAME_PORT=443
KC_HOSTNAME_STRICT=true
KC_HOSTNAME_STRICT_HTTPS=true

KC_HOSTNAME_ADMIN=http://localhost:8080

KC_LOG_LEVEL=info

KEYCLOAK_ADMIN=admin
KEYCLOAK_ADMIN_PASSWORD=admin

POSTGRES_DB=keycloak
POSTGRES_USER=keycloak
POSTGRES_PASSWORD=password

INFO: Básicamente, las variables que empiezan por KC_ son propias de Keycloak y las que empiezan por POSTGRES son del motor de la base de datos. De ahí que estén duplicados los valores

Preparando Keycloak

A estas alturas estamos listos para levantar la primera fase de nuestro proyecto

docker compose up -d

Si todo va bien, Caddy gestionará el tema del SSL y Keycloak preparará la base de datos … pero cómo acceder a la consola de Keycloak si está corriendo en una máquina en nuestro proveedor?

ssh -p 2222 -L 8080:localhost:8080 root@TU.IP

Es decir, abrimos una conexión ssh con nuestra máquina (yo uso el puerto 2222) y hacemos enrutado de puertos 8080 entre la máquina remota y la nuestra.

WARNING: Esta NO es la manera de segurizar un acceso remoto en una máquina en internet, pero para este artículo no me voy a complicar.

Existen tutoriales más detallados sobre cómo manejar Keycloak. En este artículo simplemente voy a enumerar los pasos a realizar, pues son realmente muy fáciles e intuitivos

crear un realm apisix_test
en este realmn crear un client apisix
configurar en este cliente valid redirect URL con https://apisix.edn.es/web1/anything y https://apisix.edn.es/web2/anything
asegurarnos en este cliente que está marcada la opción "Client authentication". De esta forma la autentificación en este realm es gestionada entre servicios. Si estuviera OFF sería para aplicaciones Javascript por ejemplo

Una vez creado, Keycloak nos creará un client y un secret para este client que deberemos proporcionar a Apisix (paso siguiente)

crearemos un usuario test con password test y marcaremos como que su email ha sido validado y que no necesita cambiar la password en el primer acceso. (Por no complicarnos)
Si quieres añadir Linkedin como Identity Provider, en el menú de la izquierda te permitirá elegirlo y añadir las claves creadas desde Linkedin

Apisix

Apisix es un ApiGateway Open Source (la lógica de negocio no reside en él, sino que se dedica a enrutar, transformar, etc. peticiones hacia los servicios).

En este post lo vamos a usar en modo "standalone" de tal forma que la configuración y gestión sea lo más sencilla posible.

INFO: Puedes instalarlo con varias instancias, que use etcd como respaldo de la configuración, puedes instalarlo en kubernetes, etc.

docker-compose.yml

  apisix:
    image: apache/apisix:${APISIX_IMAGE_TAG:-3.10.0-debian}
    volumes:
      - ./apisix_conf/apisix-standalone.yaml:/usr/local/apisix/conf/apisix.yaml
    env_file:
      - .env
    environment:
      - APISIX_STAND_ALONE=true

Añadiremos en el fichero .env la configuración creada por Keycloak

.env

KC_OIDC_CLIENTID=apisix
KC_OIDC_SECRET=myhg------------
KC_OIDC_ISSUER=apisix_test

Por último el fichero apisix-standalone.yml donde ocurre toda la magia:

apisix-standalone.yml

routes:
  -
      uris: ["/keycloak/js/*", "/keycloak/resources/*", "/keycloak/realms/*", "/keycloak/robots.txt"]
      upstream_id: 3
      plugins:
         proxy-rewrite:
           regex_uri: ["/keycloak/(.*)","/$1"]

  -
      uri: /web1/*
      upstream_id: 1
      plugins:
        proxy-rewrite:
           regex_uri: ["/web1/(.*)"]
        openid-connect:
           client_id: ${{KC_OIDC_CLIENTID}}
           client_secret: ${{KC_OIDC_SECRET}}
           discovery: https://apisix.edn.es/keycloak/realms/${{KC_OIDC_ISSUER}}/.well-known/openid-configuration
           redirect_uri: https://apisix.edn.es/web1/anything
           scope: openid profile

  -
      uri: /web2/*
      upstream_id: 2
      plugins:
        proxy-rewrite:
           regex_uri: ["/web2/(.*)"]
        openid-connect:
           client_id: ${{KC_OIDC_CLIENTID}}
           client_secret: ${{KC_OIDC_SECRET}}
           discovery: https://apisix.edn.es/realms/${{KC_OIDC_ISSUER}}/.well-known/openid-configuration
           redirect_uri: httsp://apisix.edn.es/web2/anything
           scope: openid profile

upstreams:
  -
      id: 1
      nodes:
          "web1:80": 1
      type: roundrobin

  -
      id: 2
      nodes:
          "web2:80": 1
      type: roundrobin

  -
      id: 3
      nodes:
         "keycloak:8080": 1
      type: roundrobin

#END

Lo primero: El fichero debe acabar en "#END" !!!! Esto es así porque estamos usando la versión standalone. En una instalación en producción NO usaríamos este modo y la gestión de rutas, etc las tendríamos en ficheros separados por ejemplo.

Como ves este fichero es donde configuramos tanto las rutas, como los backends (upstreams) y plugins.

Para nuestro ejemplo vamos a usar 3 upstreams:

web1
web2
los endpoints de keycloak "abiertos"

Así mismo en este ejemplo sencillo vamos a configurar 3 tipos de rutas:

Los endpoints abiertos de keycloak los dirigimos tal cual
Creamos rutas para web1 y web2, y para complicar el ejemplo cada uno podría estar configurado para usar diferentes realm (web1 por ejemplo permitiría accesos a un realm y web2 a otros)

En el caso de web1 (idem para web2) podríamos dirigir las llamadas al endpoint del servicio /api por ejemplo. Como estamos usando la imagen de httpbin.org usamos un endpoint suyo llamado anything que simplemente vuelca los parámetros de la llamada (y así poder comprobar que recibe el JWT entre otros)

Ejecutando

Si levantamos todos los servicios docker compose up -d nuestro stack debería estar completo ahora:

caddy recibe una petición https y la pasa a apisix
apisix evalúa que route despachar
si es para web1 el plugin openid valida si hay una autentificadion valida en la petición
si no la hay o es inválida openid se la envía a keycloak
keycloak presenta el interface para que el usuario haga login y dialoga con el usuario
una vez validado el acceso, keycloak redirige la petición original de web1
apisix la recibe y la enruta a web1
web1 puede acceder al JWT

Puedes probarlo accediendo a http://apisix.edn.es/web1/index.html (al menos mientras tenga esta máquina de pruebas levantada, que cuesta sus dineros)

Conclusión

Este ejemplo NO debería de usarse como tal en producción pero creo que sirve de ejemplo para ver cómo encajan las diferentes piezas al montar una arquitectura de microservicios con un ApiGateway y con autentificadión delegada

Executing Nextflow pipelines with Nomad by Hashicorp

Jorge — Fri, 30 Aug 2024 00:00:00 +0000

Nextflow enables scalable and reproducible scientific workflows using software containers. It allows the adaptation of pipelines written in the most common scripting languages.

Nomad is a simple and flexible scheduler and orchestrator to deploy and manage containers and non-containerized applications across on-premises and clouds at scale.

In this post, I’ll explore how to use a Nomad cluster to run Nextflow pipelines.

About Nomad

In some ways, Nomad is an alternative to Kubernetes (and similar orchestrators) without its complexity. You can create a cluster of low-resources machines and Nomad orchestrates how/where deploy your workloads.

Workloads are defined in Nomad by a Job witch contains 1 or more TaskGroup, and every TaskGroup contains 1 or more Task. This task can be a Jar application, a system process or a Docker image

Also, you can share volumes across your cluster. These volumes can be a local folder, in case you have only one machine, or use some of the available plugins to share CSI volumes as NFS, etc.

About nf-nomad

As you can imagine, this is enough to run Nextflow pipelines (a container orchestrator and shared volumes) and the "only" missing piece is some Nextflow Executor to submit tasks into the cluster and control their execution and this missing piece is the nf-nomad plugin

nf-nomad is a new Nextflow plugin, similar to the nf-k8s kubernetes plugin, implementing the bridge logic between Nextflow and Nomad.

When you execute a pipeline in Nextflow using this plugin as executor, it will translate, create and submit the Nextflow process to the cluster the Nomad Job specification.

Once submitted, the plugin will maintain the status of every task in the Nexflow session.

The plugin is open source, and you can find it at https://github.com/nextflow-io/nf-nomad

Running a Nomad Cluster

Install and run a Nomad cluster it’s as easy as download and execute the binary from the official website. In the same way, configure and attach clients to the cluster are straightforward, and it only requires a text configuration file.

For simplicity, In this post, we’ll create a cluster with only one machine on (our computer). We’ll use, also, a local folder as shared volume.

Steps in this post have been tested using a Linux machine, not sure if they will work on a Mac. Surely it will not work in a Windows OS

Download the Git repo https://github.com/nextflow-io/nf-nomad and unzip it (or clone with git clone) in some folder

Open a terminal console and navigate to the validation sub-folder and run on it:

./start-nomad.sh

This sh will perform the following steps:

download the nomad binary from the official website
create a server and a client configuration files
create a nomad_temp folder and configure it as a "shared" volume called scratchdir
run the nomad executable

If all goes well, you have running a Nomad cluster into your computer. You see the UI at http://localhost:4646/

Running a "hello world" pipeline

In this validation folder you can find several pipelines examples. They are used to validate different plugin features.

We’ll try to run a simple "hello world" nextflow pipeline.

Open a terminal console and navigate to the validation sub-folder and run on it:

export NOMAD_PLUGIN_VERSION=0.2.0 (1)
nextflow run -w $(pwd)/nomad_temp/scratchdir/ -c basic/nextflow.config basic/main.nf (2)

| 1 | Last version at this moment |
| 2 | This post assumes you have nextflow 24.x.x installed in your PATH |

Using the NOMAD_PLUGIN_VERSION environment variable, we instruct to basic/nextflow.config about which version we want to use. Feel free to use a fixed value in basic/nextflow.config

If all goes well, you will see the typical "'Bonjour world', 'Ciao world', 'Hello world', 'Hola world'" output

basic/main.nf is the typical Nextflow "hello world", nothing special here.

basic/nextflow.config configures nomad as the default executor. Also, it contains the minimal configuration required by the plugin:

process {
    executor = "nomad"
}

nomad {
    client {
        address = "http://localhost:4646"
    }
    jobs {
         volume = { type "host" name "scratchdir" }
    }
}

As you can see, the plugin requires the endpoint to the cluster (localhost in our case) and a volume to attach to the Job. This volume was created previously by the start-nomad.sh. In a more realistic situation probably this volume will be a csi type

nf-core/demo

In the same terminal and in the validation folder run:

export NXF_ASSETS=$(pwd)/nomad_temp/scratchdir/assets
export NXF_CACHE_DIR=$(pwd)/nomad_temp/scratchdir/cache
nextflow run -w $(pwd)/nomad_temp/scratchdir/ -c basic/nextflow.config nf-core/demo -profile test,docker --outdir $(pwd)/nomad_temp/scratchdir/outdir

....
* Software dependencies
  https://github.com/nf-core/demo/blob/master/CITATIONS.md
------------------------------------------------------
executor > nomad (7)
[21/35f6ba] process > NFCORE_DEMO:DEMO:FASTQC (SAMPLE1_PE) [100%] 3 of 3 ✔
[9b/5e0157] process > NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE3_SE) [100%] 3 of 3 ✔
[da/0eadbc] process > NFCORE_DEMO:DEMO:MULTIQC [100%] 1 of 1 ✔
-[nf-core/demo] Pipeline completed successfully-

if all goes well, you’ll be able to see the nf-core/demo outputs at ./nomad_temp/scratchdir/outdir/pipeline_info folder

Volumes

In all these examples, we’ve used a local folder as a shared volume between our nextflow command line and containers created into the nomad cluster. However, you can also use a S3 bucket (with wave+fusion), or install some of the available Nomad plugins and mount an NFS server, for example.

nf-nomad plugin allows also mounting more than one volume:

jobs {
    volumes = [
        { type "host" name "scratchdir" },
        { type "host" name "scratchdir" path "/var/data" }, // can mount same volume in different path
    ]
}

Delete Jobs

Using the jobs.deleteOnCompletion boolean configuration you can specify if the jobs are removed once completed or maintain them for posterior inspection (using the nomad UI for example)

Secrets

One feature of Nomad is to store variables into the cluster (and configure which roles can access to them,) and you can use them in your Job definition avoiding using fixed values into it.

nf-nomad plugin use this feature to provide a Nextflow SecretsProvider as a bridge between your pipelines and these variables:

Create a key=value variable into the cluster using the nomad cli.

./nomad var put secrets/nf-nomad/MY_ACCESS_KEY MY_ACCESS_KEY=TheAccessKey

use this variable as a secret into your pipeline

workflow.onComplete {
    println("The secret is: ${secrets.MY_ACCESS_KEY}")
}

INFO: The start-nomad.sh shell create a namespace and two variables. You can see how to use them in the secrets/main.nf pipeline

Stop and clean

Stop the cluster is so easy as kill the nomad process. You can use the stop-nomad.sh shell to do it and clean the temporal folder

Configuration

Using the nomad closure you can configure different aspects of the plugin as:

endpoint to the cluster
access token (in case you’ve protected the access with a token)
list of datacenters to use
region where allocate jobs
namespace to use in jobs
list of volume specs
list of affinities and constraints
attempts in case of failure
…

Also, in current version, some of them can be overwritten using environment variables:

NOMAD_ADDRESS
NOMAD_TOKEN
NOMAD_DC (datacenters)
NOMAD_REGION
NOMAD_NAMESPACE

Raspberry Pi

As a side/fun note, I would like to comment I was able to run the bactopia pipeline in a raspberry pi attached to the cluster

Conclusion

At this moment the plugin is in version 0.2.0 and it is being testing by the Universitey Gent team.

The Current version covers almost all the requirements to run typical pipelines, but surely new features will be included in the plugin