Saltar a contenido

Setup: Inoyu OSS UI

Interfaz web open source (Apache 2.0) para Apache Unomi, publicada por Inoyu (Serge Huber, presidente del PMC de Unomi) en julio de 2026. En este repositorio se integra como servicio inoyu-ui del compose (perfil ui en el banco de pruebas; servicio fijo en producción). El repositorio upstream no trae Dockerfile: el nuestro clona un commit fijo, aplica seis parches y compila Next.js en modo producción.

Archivos: unomi-eval/inoyu-ui/ (Dockerfile, patch-*.sh).

Arranque (banco de pruebas)

cd unomi-eval
# en .env: INOYU_ADMIN_EMAIL, INOYU_ADMIN_PASSWORD, INOYU_JWT_SECRET (openssl rand -hex 32)
docker compose --profile ui up -d --build
# abrir http://localhost:3131 y entrar con INOYU_ADMIN_EMAIL / INOYU_ADMIN_PASSWORD

Acceso desde otros equipos por HTTP plano: INOYU_BIND=0.0.0.0 e INOYU_COOKIE_SECURE=false (la cookie de sesión lleva Secure por defecto y el navegador la descarta sobre HTTP fuera de localhost; sin TLS el token viaja en claro: solo para evaluación). Reconstruir con --build.

Cómo se conecta con Unomi

  • El navegador nunca habla con Unomi: todas las llamadas van a /api/cxs/* en el servidor Next.js, que las reenvía a UNOMI_URL con Basic auth karaf / UNOMI_PASSWORD. No hace falta CORS ni exponer el 8181.
  • UNOMI_VERSION=3.0 oculta la gestión de tenants (exige Unomi 3.1).
  • UNOMI_URL, NEXT_PUBLIC_UNOMI_URL y UNOMI_VERSION se incrustan en el bundle al compilar (bloque env de next.config.js): el compose las pasa como build.args; cambiarlas exige reconstruir. Credenciales, JWT_SECRET, ADMIN_* y DEPLOYMENT_TYPE se leen en tiempo de ejecución.
  • Un único usuario administrador definido por variables de entorno; no hay base de usuarios ni roles.

Estado verificado con Unomi 3.0.0 (commit e78c1bd)

Funciona: perfiles y personas, segmentos (lista, conteo, match), reglas y estadísticas, scopes, tipos de propiedad, definiciones de condiciones y acciones, esquemas JSON (con parche), goals (con parche), campañas, scoring, listas de usuarios, salud del cluster.

No funciona: "Groovy Actions" (Unomi 3.0.0 responde 500 al listar); "Tenants" (oculto a propósito).

Parches aplicados en la imagen

Se aplican en orden dentro del Dockerfile, con sed y python3 sobre archivos concretos del commit fijado. Al cambiar el commit de Inoyu, cada uno debe revalidarse.

Parche Archivos del upstream que toca Motivo Tipo
patch-proxy-auth.sh pages/api/cxs/[...path].ts, src/middleware/middleware.ts El proxy a Unomi no exigía sesión (el middleware está en una ruta que Next.js no carga): cualquiera con acceso al puerto administraba Unomi. Añade auth: true. Seguridad, cambio propio
patch-cookie-secure.sh pages/api/auth/login.ts Permite COOKIE_SECURE=false para entrar por HTTP en la LAN (solo evaluación). Cambio propio
patch-json-schemas.sh crea pages/api/json-schemas/index.ts y [...id].ts La UI llama a /api/json-schemas pero esas rutas solo existen en la edición Pro: la pantalla "JSON Schemas" daba 404 y cada evento del perfil "Error loading schema". Reenvían a /cxs/jsonSchema. Carencia de la edición OSS
patch-goal-report.sh src/services/client/GoalService.ts Unomi 3.0.0 responde 500 a GET /cxs/goals/{id}/report y al POST sin agrupación; se fuerza un POST con agrupación neutra por scope. Bug de Unomi 3.0.0
patch-goal-report-viewer.sh src/components/goals/GoalList.tsx, crea GoalReportViewer.tsx El botón "View" de Goals usa un componente que solo existe en la edición Pro. Añade un visor mínimo. Carencia de la edición OSS
patch-property-type-basic.sh src/components/propertyTypes/PropertyTypeBasicInfo.tsx La pestaña "Basic" del editor de tipos de propiedad era un stub ("coming soon"): no se podía crear uno desde la UI. Añade el formulario. Carencia de la edición OSS

Los parches marcados "bug de Unomi 3.0.0" o "carencia OSS" pueden dejar de hacer falta al actualizar Unomi o Inoyu; los "cambios propios" deben revalidarse siempre. No existe un test que confirme que un parche quedó aplicado más allá del build: verificar en la UI las pantallas afectadas tras cada reconstrucción.

Particularidades de la edición open source

  • Condiciones y acciones de segmentos y reglas se editan en JSON (editor Monaco con validación); el constructor visual es de la edición Pro. Plantillas en Reglas, segmentos y scoring.
  • Los indicadores del encabezado del perfil ("Engagement Score 87", "Lifetime Value $3,250") son valores fijos del código de la UI, no datos de Unomi; sin firstName/lastName el nombre se muestra como "undefined undefined".
  • La búsqueda de perfiles filtra solo la página cargada; para buscar en todo el dataset usar la API.
  • Guardar dos veces una regla (doble clic, reintento tras un error) crea dos reglas con id distinto y los contadores suben de a dos.

Requisitos

Node ≥ 20.9 en la imagen de build (node:22-alpine); la imagen final pesa ~830 MB y usa ~80 a 100 MB de RAM en reposo. En devops-vm la compilación necesita build.network: host (DNS de la red bridge por defecto no funciona allí).