Balanceador y API gateway

Dos componentes del catálogo reciben peticiones y las reparten entre los servicios del proyecto:

fundaia new tienda puerta --template traefik-3
fundaia new tienda api-gw --template krakend-2

Configurarlos

Funcionan como la receta de un servicio: eliges los destinos en el formulario de la pestaña Rutas, la plataforma genera el fichero, el fichero se ve, y la primera edición a mano lo congela. Desde ese momento el formulario deja de sobrescribirlo; volver a generarlo hay que pedirlo, y avisa de que descarta tus cambios.

fundaia config show tienda puerta --plain > routes.yml
fundaia config edit tienda puerta --file routes.yml

El puerto de cada destino sale de su variable PORT (la que escribe una conexión) o, si no la tiene, de su puerto de contenedor.

Antes de desplegar un fichero editado se comprueba su forma, no solo su sintaxis: que cada router apunte a un service que existe y que ningún service se quede sin servidores. Traefik arranca aunque no pueda usar su configuración y respondería 404 a todo con el despliegue en verde; esa comprobación lo evita. KrakenD, con un fichero inválido, no arranca y el despliegue lo cuenta.

Si borras un servicio al que apuntaba una ruta, el fichero no se toca: la pantalla marca la ruta como colgada y espera a que lo regeneres o lo edites.

Lo que no hacen

• No despiertan a un servicio dormido. Hablan con sus destinos por la red del proyecto, y solo la pasarela de la plataforma despierta servicios. Un destino dormido responde 502: desactívale el sueño.
• No llevan secretos en el fichero, que es legible dentro del contenedor. Un secreto (la clave de un JWT, por ejemplo) va como variable de entorno.
• No escuchan en el 80. Los contenedores arrancan sin privilegios, así que escuchan en el 8080; el dominio público es el de siempre.