Setup: banco de pruebas local (`unomi-eval/`)¶

Stack de desarrollo y evaluación: Elasticsearch 9.1.3 + Apache Unomi 3.0.0 (+ Inoyu OSS UI opcional), aislado en una red y un volumen propios. Es la plantilla del stack de producción y el entorno donde correr la suite funcional antes de cualquier cambio.

Archivos: unomi-eval/ (docker-compose.yml, .env.example, smoke-test.sh, tests/, inoyu-ui/, deploy/).

Requisitos¶

Docker ≥ 24 con Compose v2.
Unos 3 GB de RAM libres (medido: Elasticsearch 1,6 a 1,8 GiB con heap de 1 GB; Unomi 0,9 GiB; Inoyu 0,1 GiB).
Puertos libres: 8181 y 9443 (Unomi), 9200 (Elasticsearch), 3131 (Inoyu). Cambiar en .env si están ocupados.
Elasticsearch en modo single-node no aplica los bootstrap checks: no hace falta subir vm.max_map_count.

Arranque¶

cd unomi-eval
cp .env.example .env
# cambiar las tres contraseñas y, si se usa la UI, las variables INOYU_*:  openssl rand -hex 16
docker compose up -d                         # solo Elasticsearch + Unomi
docker compose --profile ui up -d --build    # además Inoyu OSS UI (compila la imagen, ~5 min la primera vez)
docker compose ps                            # esperar "healthy"
./smoke-test.sh                              # validación de extremo a extremo

Otros comandos:

docker compose logs -f unomi         # logs (o: elasticsearch, inoyu-ui)
docker compose down                  # bajar conservando datos
docker compose down -v               # bajar y borrar datos (reset completo)
docker compose exec unomi bin/client -u karaf -p "$UNOMI_ROOT_PASSWORD"   # consola Karaf (SSH 8102 no se publica)

Variables de `.env`¶

Variable	Uso
`UNOMI_ROOT_PASSWORD`	Contraseña del usuario admin `karaf` (API administrativa y consola). Reemplaza `karaf:karaf`.
`UNOMI_HEALTHCHECK_PASSWORD`	Usuario `health` de `/health/check`.
`UNOMI_THIRDPARTY_PROVIDER1_KEY`	Clave de la cabecera `X-Unomi-Peer` para eventos protegidos (`login`, `updateProperties`).
`UNOMI_BIND`	`127.0.0.1` (solo la máquina) o `0.0.0.0` (red local).
`UNOMI_GRAPHQL`	`true` activa la API GraphQL y la consola GraphiQL en `/graphql-ui/` (beta; tarda ~45 s más en aparecer tras el arranque).
`ES_HEAP`, `UNOMI_HEAP`	Heaps de la JVM (por defecto 1g y 1536m).
`INOYU_*`	Credenciales y ajustes de la UI (ver Inoyu OSS UI).

Todas las variables UNOMI_* existen como ${env:...} en etc/custom.system.properties de la imagen oficial. En 3.0.0 no hay multi-tenancy ni X-Unomi-Api-Key (aparecen en 3.1).

Endpoints¶

Endpoint	Autenticación	Uso
`http://localhost:8181/cxs/cluster`	Basic `karaf`	Nodos del cluster; healthcheck del contenedor
`http://localhost:8181/cxs/context.json?sessionId=...`	ninguna	Endpoint público de contexto (crea perfil y sesión)
`http://localhost:8181/cxs/eventcollector`	ninguna (+ `X-Unomi-Peer` en eventos protegidos)	Ingesta de eventos
`http://localhost:8181/cxs/profiles`, `/segments`, `/rules`, `/scopes`, `/jsonSchema`, `/events/search`	Basic	API administrativa
`http://localhost:8181/health/check`	Basic `health`	Extensión healthcheck
`http://localhost:8181/graphql-ui/`	Basic en el panel "HTTP headers"	GraphiQL (única interfaz que trae Unomi)
`http://localhost:3131`	usuario de `INOYU_ADMIN_*`	Inoyu OSS UI

Los endpoints públicos no piden credenciales por diseño: mantener el stack en redes de confianza.

Suite de pruebas funcionales (`tests/`)¶

Scripts por fase con asserts (exit 0/1); todo lo creado lleva prefijo eval-.

cd unomi-eval/tests
./run-all.sh                 # 01..07 en orden y 99-cleanup al final; resumen en results/summary.txt
FASES="01 03" ./run-all.sh   # solo algunas fases
NO_CLEANUP=1 ./run-all.sh    # dejar los objetos eval-* para inspección
./99-cleanup.sh              # limpieza completa

Fase	Qué prueba
01	Esquemas JSON de `productView` / `addToCart` / `purchase`; eventos válidos e inválidos
02	Reglas de enriquecimiento y latencia evento → propiedad
03	Segmentos por propiedad y por `pastEventCondition`; entrada, salida y `/count`
04	Identity stitching: `login` protegido, `mergeProfilesOnPropertyAction`, aliases
05	Página con el tracker JS oficial (parcheado) y latencia p50/p95 de `context.json`
06	DELETE de perfil, endpoints `/cxs/privacy`, export, `docker compose restart`
07	Carga: 5.000 eventos / 200 perfiles / 8 hilos
08	Dataset de demostración (ver tutorial)
99	Limpieza y verificación

Resultados y fricción encontrada: Evaluación funcional de Unomi 3.0.0.

Notas¶

El arranque de Unomi tarda 1 a 3 minutos la primera vez; /cxs/context.json responde 500 unos segundos después de que /cxs/cluster ya devuelve 200.
Un sessionId ya ligado a un perfil manda sobre el profileId enviado.
Los índices en Elasticsearch llevan prefijo context-; los eventos se escriben por lotes con flush de 5 s.
Consumo medido tras el arranque: Elasticsearch 1,6 GiB, Unomi 0,9 GiB.

Setup: banco de pruebas local (unomi-eval/)¶