Funcionalidad Avanzada Installer

Funcionalidad completa del instalador

Este Anexo abarcará toda la información sobre las posibles configuraciones y utilidades no cubiertas en la pestaña principal del documento.

Preflight

Antes de ejecutar una instalación completa o un Platform Setup, el instalador ejecuta una fase de Preflight: un conjunto de comprobaciones automáticas sobre la configuración y sobre cada host del entorno, pensada para detectar problemas (puertos ocupados, falta de espacio, usuarios o permisos incorrectos, conectividad, etc.) antes de empezar a desplegar servicios.

Cuándo y cómo se ejecuta

El Preflight se lanza manualmente desde el panel de la página Deploy, con el botón Run, o mediante la API REST. Mientras se ejecuta, un visor de logs muestra el progreso en vivo.

Los checks se ejecutan en tres fases, con corte temprano si la configuración no es válida:

• Configuración (12 checks, alcance global): validan el fichero de configuración antes de tocar ningún host. Si alguno falla, la fase se detiene ahí y las comprobaciones de entorno no llegan a ejecutarse.

  • Campos obligatorios, formato de versión, de carpeta de instalación y de usuario de servicio

  • Topología de hosts y puertos

  • Coherencia de los servicios habilitados

  • Validez de la configuración de control de acceso por IP

  • Al menos un método de autenticación activo

  • Configuración de persistencias completa

  • Opt-in de release candidate y versiones de desarrollo.

• Entorno, alcance global (4 checks):

  • Conectividad con el repositorio Nexus

  • Alcanzabilidad del endpoint OTLP de monitorización (si está habilitado)

  • Resolución del mapa de versiones a instalar

  • Conectividad con el endpoint S3 personalizado (si está configurado).

• Entorno, por host (16 checks): se repiten en cada host del entorno.

  • Sistema operativo soportado

  • Conexión SSH

  • Sudo sin contraseña

  • Usuario de servicio

  • Permisos del directorio de instalación

  • Espacio en disco y memoria

  • Puertos libres

  • Resolución del hostname

  • Paquetes del sistema, Java 17, AWS CLI, módulos de nginx

  • Instalación previa

  • Espacio suficiente para el backup obligatorio de un upgrade

  • Puertos libres para los motores nuevos en 26.1.

En la interfaz, los resultados se agrupan en dos bloques: Configuration (los 12 checks de configuración) y Environment (los 20 checks de entorno restantes, tanto globales como por host).

Severidad y remediación

Cada check produce un resultado PASS, WARN o FAIL:

• Un FAIL bloquea el avance a Install/Platform Setup.

• Un WARN no bloquea el resultado del Preflight, pero la interfaz exige marcar una casilla de confirmación ("acknowledge the warnings") antes de permitir continuar con avisos pendientes.

En resumen: un FAIL debe resolverse siempre; un WARN puede aceptarse conscientemente para seguir adelante.

7 de los 32 checks son remediables: el panel muestra un botón Fix junto al check, que aplica la corrección automáticamente. El resto (25 checks) son solo de diagnóstico y requieren corrección manual del entorno.

Vigencia del reporte

El resultado del Preflight queda vinculado a la configuración con la que se generó. Install y Platform Setup quedan bloqueados hasta que exista un reporte:

• Generado dentro de los últimos 15 minutos (TTL configurable mediante anjana.installer.preflight-report-ttl-minutes).

• Sin cambios en la configuración desde que se generó: cualquier modificación invalida el reporte.

• Sin ningún check en estado FAIL.

Si el reporte expira o la configuración cambia, el panel lo marca como "(expired)" y es necesario volver a ejecutar Preflight. Desde la CLI/TUI, si se intenta lanzar una instalación sin un Preflight vigente, el instalador informa del motivo del bloqueo e indica que debe ejecutarse desde la interfaz web o la API antes de reintentar.

API REST

Respuestas relevantes: 409 (JOB_ACTIVE) si ya hay un Preflight en curso; 409 con motivo NO_REPORT, STALE_REPORT, CONFIG_CHANGED o FAILED_CHECKS si se intenta avanzar sin un reporte válido; 400 si se pide remediar un check no remediable o un host inexistente.

Gestión de secretos

El instalador incorpora un sistema de gestión encriptada de secretos para las credenciales de persistencias y demás información sensible, con varios modos de gestión disponibles:

AWS Secrets Manager

Cuando el instalador se ejecuta en un entorno con acceso a AWS Secrets Manager, las credenciales se recuperan directamente del servicio gestionado, aprovechando la encriptación y rotación nativas de AWS.

Este es el backend recomendado en entornos cloud.

Configuración

El backend se selecciona en el wizard (sección Secrets Backend) o directamente en el fichero installation.yaml:

secretsBackend:
  installerBackend: AWS_SECRETS_MANAGER
  awsRegion: eu-central-1
  awsSecretsPrefix: /secret/<env>

Formato del blob JSON

El instalador lee un único secret JSON ("blob") en la ruta {awsSecretsPrefix}/application_default. Este es el mismo formato que utiliza Horus via Spring Cloud Config (convención compartida por todos los microservicios de la plataforma).

El blob contiene un JSON plano con las claves de los secretos:

{
  "NEXUS_USER": "admin",
  "NEXUS_PASS": "...",
  "DB_PASS": "...",
  "S3_ACCESS_KEY": "...",
  "S3_SECRET_KEY": "...",
  "INDEX_PASS": "...",
  "MONGO_URI": "mongodb://user:pass@host:27017/db?tls=true&replicaSet=rs0",
  "VALKEY_PASS": "...",
  "RABBITMQ_PASS": "...",
  "LICENSE_INSTALLATION_CODE": "...",
  "LICENSE_PRIVATE_KEY": "...",
  "LICENSE_PUBLIC_KEY": "...",
  "INSTALLER_ADMIN_PASSWORD": "...",
  "INSTALLER_DEV_PASSWORD": "...",
  "INSTALLER_BUNDLE_SIGNING_KEY": "..."
}

Mapeo de claves (blob SM a installer):

NOTA: Este backend es read-only: las credenciales se gestionan externamente (IaC, consola AWS).

Las operaciones de escritura (rotación de credenciales desde la UI) no están disponibles en este modo. Por el mismo motivo, la política de caducidad de la contraseña de administrador de la propia interfaz (ver "Política de caducidad de contraseña" más abajo) tampoco se evalúa en este backend: al no poder registrarse la fecha del último cambio, el sistema nunca fuerza su renovación.

El IAM role o las credenciales utilizadas deben tener el permiso secretsmanager:GetSecretValue sobre el secret {awsSecretsPrefix}/application_default.

Almacenamiento local encriptado

Para entornos sin acceso a servicios de gestión de secretos en la nube (VM locales, WSL, entornos aislados), el instalador proporciona un almacenamiento local encriptado (AES-256-GCM).

Todas las credenciales se encriptan en reposo, eliminando la exposición de secretos en ficheros de texto plano.

No debería generarse ningún fichero de entorno que contenga credenciales en plano; toda la información sensible permanece encriptada en todo momento.

Contraseña de keystore TLS (ksPass)

El instalador genera una contraseña aleatoria para el keystore TLS en cada despliegue (platform setup).

Esta contraseña (ksPass) se almacena en el SecretsService y se renderiza automáticamente en los descriptores de servicio (systemd) de todos los microservicios. De esta forma, las JVM de los microservicios nunca utilizan una contraseña estática predecible para proteger el keystore de comunicaciones TLS internas.

Backend de configuración de Horus (horusConfigBackend)

El instalador permite configurar el backend desde el que Horus Config Server lee la configuración de la plataforma. Este ajuste es independiente del backend de secretos del propio instalador y se define en installation.yaml bajo la clave secretsBackend.horusConfigBackend.

Ejemplo de configuración con backend GIT:

secretsBackend:
  installerBackend: LOCAL_ENCRYPTED
  horusConfigBackend: GIT
  gitUri: git@github.com:ejemplo/config-repo.git
  gitDefaultLabel: main
  gitSearchPaths: anjana/{profile}
  gitPrivateKeyBase64: <clave-privada-SSH-en-base64>

Política de caducidad de contraseña (Web UI Access)

La contraseña del usuario admin de la propia interfaz del instalador tiene una caducidad configurable, independiente de la política de complejidad de las credenciales de persistencias (ver "Seguridad de credenciales antes del despliegue" en el Manual de despliegue).

• Valor por defecto: 60 días desde el último cambio de contraseña.

• Configuración: Settings > Web UI Access, sección Password Policy (rango admitido: 1 a 3650 días), o directamente vía API (GET/PUT /api/settings/password-policy).

• Comportamiento al caducar: al iniciar sesión con la contraseña caducada, se muestra un modal de cambio de contraseña obligatorio que bloquea el resto de la interfaz hasta completarlo.

• Aviso previo: unos días antes de la caducidad, la interfaz muestra un aviso no bloqueante para poder cambiarla con margen.

• Reducir la ventana de golpe: si se reduce el valor de caducidad y la antigüedad de la contraseña actual ya supera el nuevo límite, la interfaz lo detecta al guardar y ofrece forzar el cambio de contraseña de inmediato.

• Alcance: esta política aplica solo al usuario admin de la propia consola del instalador. No aplica al usuario de desarrollo (dev, solo disponible en modo devMode) ni a las credenciales de persistencias (gestionadas aparte en Tools > Credentials).

• Backend AWS Secrets Manager: al ser un backend read-only, la fecha del último cambio de contraseña no puede registrarse, por lo que la caducidad no se evalúa (nunca se fuerza el cambio) cuando el instalador usa este backend de secretos.

Arquitectura de configuración del core

El instalador genera y despliega los descriptores de servicio (systemd) de cada microservicio con los parámetros necesarios para que se conecte a Horus Config Server al arrancar, incluidos los datos de muestra (sampledata) provistos por Anjana durante la instalación inicial. El perfil utilizado por todos los microservicios es siempre 'default'.

No se generan ficheros de entorno de ningún tipo: las credenciales se gestionan exclusivamente a través del SecretsService del instalador, que las almacena encriptadas.

Tras operaciones que modifican la base de datos (RESET_ALL, RESTORE_ALL, LOAD_SAMPLE_DATA), el instalador re-puebla automáticamente la tabla app_configuration con las credenciales vigentes del SecretsService, sin necesidad de reinicio manual.

Servicio MCP

MCP se trata como cualquier otro servicio core: habilitado por defecto, desplegado y expuesto a través del proxy de la plataforma (ruta /mcp), tanto en despliegues cloud como on-premise.

La documentación del producto indica como utilizar este servicio.

En caso de no quererse desplegar, es posible desmarcarlo durante la instalación para evitar su despliegue y activación.

Configuración de autenticación (Zeus SSO)

El asistente de configuración (Wizard) permite configurar los proveedores de autenticación que utilizará Zeus para gestionar el acceso de usuarios a la plataforma Anjana. El instalador es compatible con los siguientes métodos, combinables entre sí:

• Local DB

• LDAP

• OIDC / OAuth2

• SAML2

El asistente exige que quede activo al menos uno de los cuatro métodos: no es posible guardar la configuración ni avanzar en el asistente si se desmarcan todos, ya que dejaría el acceso a la plataforma sin ninguna vía de entrada posible.

Local DB

Habilitado por defecto, no requiere configuración adicional.

LDAP

Campos a rellenar en el wizard:

El secret asociado (contraseña de conexión LDAP) se almacena en el secrets backend del instalador.

OIDC / OAuth2

Soporta múltiples proveedores simultáneos (Google, Azure AD, Keycloak, etc.). Campos a rellenar por proveedor:

El client secret de cada proveedor se almacena como oidcClientSecret.{registrationId} en el secrets backend.

SAML2

Soporta múltiples proveedores. Campos a rellenar por proveedor:

Los certificados y claves SAML2 (cuando se configuran) se almacenan como saml2SpSigningKey.{id} y saml2SpSigningCert.{id} en el secrets backend.

Aprovisionamiento de usuarios (sincronización con directorios externos)

Además de los proveedores de autenticación anteriores, el wizard incluye un paso independiente de Provisioning para sincronizar automáticamente usuarios y grupos desde un directorio externo hacia Anjana. Se soportan varios proveedores, y pueden configurarse varias instancias del mismo tipo (por ejemplo, dos tenants de Azure distintos), cada una identificada con una clave propia:

El secreto de conexión de cada instancia (API token, client secret o credenciales, según el proveedor) se almacena cifrado en el secrets backend del instalador, igual que el resto de credenciales de la plataforma.

Estado de secrets

El paso de revisión del wizard y la pantalla de Secrets muestran un checklist con el estado de inicialización de cada secret (GET /api/wizard/secrets/status), indicando cuáles están configurados y cuáles faltan. Esto incluye los secrets de persistencias, licencia, autenticación, los secrets dinámicos de cada proveedor OIDC/SAML2 configurado y los de cada proveedor de aprovisionamiento configurado.

Control de acceso por IP

El instalador permite restringir por dirección IP el acceso a la plataforma a través de su proxy, gestionado desde Settings > IP Access Control. Los cambios se aplican en caliente, sin necesidad de reiniciar servicios ni de un nuevo despliegue.

Se configuran tres bloques:

Cada entrada de whitelist se compone de una etiqueta libre y una IP o rango CIDR (IPv4 o IPv6). El instalador valida el formato al guardar y rechaza rangos mal formados o inconsistentes.

Flujo de uso

1. Save: guarda el borrador de la configuración sin aplicarlo todavía.

2. Apply: valida la configuración, la activa en el proxy y recarga el servicio. Si la validación falla no se llega a tocar la configuración activa; si algo falla ya aplicando el cambio, el instalador restaura automáticamente la configuración anterior.

3. Al activar la whitelist general, la pantalla muestra la IP detectada del propio operador como aviso de seguridad, para evitar que quien la activa se bloquee a sí mismo por error.

El instalador (puerto 8787) es independiente del proxy que gestiona esta whitelist, por lo que nunca queda bloqueado: si un cambio deja fuera al operador, siempre es posible entrar directamente por el puerto del instalador para corregir la configuración.

Nota: este control de acceso por IP protege el proxy de la plataforma (los frontales de negocio de Anjana). Es un mecanismo distinto e independiente de cualquier control de acceso sobre la propia consola del instalador (puerto 8787).

Exposición pública restringida

Un caso de uso habitual es publicar la plataforma en Internet pero limitar el acceso exclusivamente a los rangos de red de la organización. Para configurarlo:

1. Activar la whitelist general.

2. Añadir como entradas los rangos de salida corporativos: el proxy corporativo de navegación, las IPs públicas de las oficinas, la VPN corporativa, etc.

Notas operativas para este escenario:

• Si los servicios de la plataforma se llaman a sí mismos a través de la URL pública, es necesario incluir también en la whitelist la IP pública de salida (NAT) de la propia instalación; de lo contrario, esas llamadas internas quedarían bloqueadas por el filtro.

• Si hay un balanceador o proxy delante de la plataforma, configurar primero Trusted proxies con el rango del balanceador, para que el filtrado se evalúe sobre la IP real de cada cliente y no sobre la IP del balanceador.

Migración desde el kit Ansible

Al importar la configuración de un kit Ansible anterior (ver "Importación desde Ansible Kit" más abajo), es posible adjuntar también el fichero anjanauihosts.yaml: las whitelists ya definidas en el kit se portan automáticamente a la whitelist general e interna del instalador.

Gestión de persistencias

Configuración de conexión IaaS/PaaS

El instalador adapta su interfaz de configuración de persistencias según el modo de despliegue seleccionado. En modo Single VM sin persistencias cloud no es necesario rellenar las URLs de conexión, ya que siempre serán localhost. En modo Single VM con persistencias cloud se habilitan los campos de conexión a servicios gestionados (AWS RDS, AWS S3, etc.). En modo Core + Persistencias (Distribuido) se requiere la configuración completa de URLs, credenciales y parámetros de conexión.

Dependencias de persistencias

El instalador establece una dependencia obligatoria entre el core y las persistencias. El core no puede ser instalado sin que las persistencias estén previamente desplegadas o, en su defecto, sin que se hayan marcado las persistencias cloud correspondientes. Se realiza una detección previa del estado de las persistencias y se mostrará un aviso en las casillas de selección si son requisito obligatorio no cumplido.

Además, la pantalla de servicios del asistente muestra un aviso no bloqueante cuando se desmarca cualquier microservicio del core: todo el core es necesario para que la plataforma funcione correctamente, así que desactivar uno de sus componentes puede dejar la instalación en un estado parcial o inconsistente.

OpenSearch estará disponible próximamente.

Importación de configuraciones

Importación desde Installer YAML

Permite reimportar un fichero YAML exportado previamente por el instalador (botón "Export YAML" en la página de Configuración). Es la pestaña seleccionada por defecto en el diálogo de importación.

Importación desde Ansible Kit

Permite importar los ficheros all.yaml y hosts.yaml de un kit Ansible anterior. El proceso consta de dos pasos:

1. Preview: se mapean todos los valores, se detecta la topología, se muestran warnings y los secrets encontrados. Se ofrece la opción de migrar a OpenSearch (marcada por defecto como opción recomendada).

2. Confirm: se persiste la configuración y los secrets. Si hay warnings (como credenciales protegidas), se muestra un paso de resultado antes de cerrar.

Protección de credenciales durante la importación

Al confirmar cualquier importación, el instalador comprueba qué servicios de persistencia están ya desplegados (via systemctl is-enabled). Para cada servicio deployed, la credencial importada se descarta del proceso de guardado. Se muestra un aviso agrupado: "Credentials not overwritten for deployed services: PostgreSQL, SeaweedFS, RabbitMQ, MongoDB, OpenSearch, Valkey. Use Tools > Credentials to rotate them."

Esto evita la desincronización entre la contraseña almacenada en el secrets store y la contraseña real configurada en el servicio, que impediría la rotación posterior y la conexión de los microservicios.

Descriptores de servicio (Service Descriptors)

El instalador permite editar los parámetros de los descriptores de servicio (systemd units) de cada microservicio directamente desde la interfaz gráfica, en la pestaña Service Descriptors de la página Configuration.

Parámetros editables por servicio

Funcionalidades

• Override por servicio: los valores editados se almacenan como overrides sobre los defaults built-in del instalador

• Preview: previsualización del unit file systemd generado con los parámetros actuales, antes de aplicar

• Reset to defaults: restaurar un servicio a sus valores por defecto eliminando los overrides

• Raw unit editor: edición directa del contenido del unit file systemd para casos avanzados

• Apply changes: aplicar todos los cambios pendientes, lo que regenera los unit files y reinicia los servicios afectados (equivalente a la operación Update Service Units)

Uso recomendado

Los overrides de memoria son útiles para ajustar el rendimiento del entorno sin tocar los templates del instalador. Los cambios se persisten a disco y sobreviven actualizaciones del instalador. El preview permite validar el resultado antes de aplicar.

Configuración de plugins (Plugin Configs)

El instalador permite editar los ficheros de configuración local de los plugins cuando estos operan en modo standalone (no utilizan Horus Config Server).

Modo standalone vs Config Server

• Config Server (por defecto): los plugins obtienen su configuración de Horus al arrancar. El instalador no permite editar la configuración local en este modo

• Standalone: los plugins leen un fichero application-default.yaml local. El instalador habilita la edición de estos ficheros

Funcionalidades

• Lista de plugins: muestra todos los plugins habilitados con indicación de si tienen fichero de configuración local

• Editor YAML: editor de texto para el fichero application-default.yaml de cada plugin, con validación de sintaxis YAML antes de guardar

• Save & Restart: guardar cambios y opcionalmente reiniciar el plugin inmediatamente

• Restart individual: reiniciar un plugin sin modificar su configuración

Ruta de ficheros

Los ficheros de configuración se almacenan en: /{installFolder}/data/config/{plugin}/application-default.yaml

Ejemplo: /opt/anjana/data/config/tot_plugin_jdbc/application-default.yaml

Cloud vault para plugins standalone

Cuando los plugins operan en modo standalone (pluginsConfig.standalone: true), es posible configurar un vault cloud que inyecte secretos en tiempo de ejecución. El vault se configura con el parámetro vaultType:

En modo standalone también debe configurarse totDomain con el dominio del servidor TOT al que los plugins se registran.

Herramientas de datos (Tools)

El instalador incluye un menú lateral Tools con cuatro pestañas, accesibles tanto desde la interfaz gráfica como desde la línea de comandos (CLI).

Credentials: Gestión de credenciales

Muestra todas las credenciales de persistencias habilitadas con su estado de seguridad. La política de seguridad requiere: mínimo 8 caracteres, al menos una mayúscula, una minúscula, un dígito y un carácter especial.

Funcionalidades:

• Rotación individual: introducir contraseña manualmente o generar una segura, con campo de confirmación y toggle de visibilidad

• Rotación masiva ("Fix All Insecure"): genera y aplica contraseñas seguras a todas las credenciales inseguras en secuencia

• Detección de estado deployed: para servicios desplegados, la rotación cambia la contraseña en el servicio (ALTER USER, mongosh, valkey-cli, etc.) y actualiza el secrets store; para servicios no desplegados, solo actualiza el secrets store

• Update secret only: toggle disponible para servicios deployed que permite actualizar solo el secrets store sin conectar al servicio. Caso de uso: recuperar una desincronización entre la contraseña almacenada y la real del servicio

• Servicios externos/cloud: las credenciales de AWS S3, RDS y otros servicios gestionados se marcan como "External" y no son rotables; se indica al usuario que las gestione desde la consola del proveedor

• Confirmación para deployed: al rotar credenciales de servicios en ejecución, se muestra un modal de confirmación advirtiendo que los microservicios perderán conexión hasta ser reiniciados

Si existen credenciales inseguras, las operaciones de despliegue se bloquean y la página Deploy muestra un warning con enlace directo a Tools > Credentials.

Persistence: Operaciones de datos

Operaciones organizadas en cards por servicio, con botones por operación:

Operaciones por servicio:

Operaciones compuestas:

Reset All: modos de restauración:

La operación Reset All borra todos los datos de todas las persistencias (PostgreSQL, MongoDB, S3, Solr/OpenSearch, Valkey, RabbitMQ, Config) y ofrece tres modos mediante un modal con selector:

La operación requiere confirmación con contraseña. El botón de confirmación refleja el modo seleccionado: "Reset All" / "Reset & Load" / "Reset & Restore". Si la fase de borrado tiene éxito pero la restauración falla, los logs indican exactamente qué fase falló y sugieren cómo reintentar.

Los microservicios que se detienen para poder borrar los datos con seguridad se reinician automáticamente al terminar, respetando el orden de dependencias entre ellos para evitar fallos de arranque por dependencias no disponibles.

Restore desde fichero:

Las operaciones de restore desde fichero permiten subir ficheros directamente desde el navegador mediante un selector de archivos nativo. Los ficheros se suben al servidor, se procesan y se eliminan tras completar la operación.

• Restore from .sql (PostgreSQL): acepta múltiples ficheros .sql, que se ejecutan secuencialmente contra la base de datos de Anjana

• Restore from .tgz (S3/SeaweedFS): acepta un archivo .tgz que contiene carpetas correspondientes a los buckets (cdn, imports, textarea, etc.) con su contenido; se extraen y se sincronizan vía AWS CLI

• Restore from .tar.gz (MongoDB, Config): acepta archivos .tar.gz con los datos a restaurar

Todas las operaciones destructivas requieren confirmación explícita. El histórico de jobs es colapsable y muestra estado, operación, timestamp y resultado. Cada fila del histórico incluye además un icono de exportación de diagnóstico acotado a ese job concreto (ver "Exportación de paquete de diagnóstico" más abajo).

Backups: Inventario y gestión

Inventario de todos los backups almacenados, agrupados por servicio con nombre funcional + badge de tecnología:

• Listado: muestra todos los backups por servicio con nombre, tamaño y fecha

• Download: descarga individual de cualquier backup (directorios se empaquetan como .tar.gz)

• Delete: elimina backups individuales (el último backup requiere doble confirmación con contraseña)

• Data Exports: sección dedicada para archivos .tar.gz generados por Export Data

• Retención: número máximo de backups por servicio (configurable, default 5). Se aplica automáticamente tras cada backup. El cambio se persiste a disco y sobrevive reinicios

Los backups siguen una convención de nombres estandarizada: anjana_{servicio}_{timestamp} (ej: anjana_postgresql_20260327_143025.sql). Se almacenan en /opt/backup/{servicio}/.

Logs: Visor de logs en tiempo real

Permite consultar los logs de cualquier microservicio, persistencia o plugin habilitado:

• Selector de servicio: dropdown agrupado por categoría (Core / Persistence / Plugins)

• Tail: carga las últimas N líneas (configurable, 10-5000, default 100) vía journalctl

• Follow: streaming en tiempo real vía WebSocket/STOMP con indicador LIVE animado

• Coloreado: líneas de error en rojo, éxito en verde

Exportación de paquete de diagnóstico

El instalador permite descargar un paquete de diagnóstico en texto plano para soporte, redactado de credenciales por el mismo mecanismo de redacción de secretos que usa el resto de la aplicación.

• Exportación general: botón Export Diagnostics en Tools > Persistence, o GET /api/diagnostics/export. Incluye el log del último job de despliegue, el último informe de Preflight, una foto de estado de salud, el inventario de versiones y un resumen de entorno no sensible.

• Exportación por job concreto: en el historial de jobs de Tools > Persistence, cada fila incluye un icono de exportación que descarga el diagnóstico acotado a ese job en concreto (GET /api/diagnostics/export?jobId=...), en vez del último job genérico. Según el registro de origen del job, la sección de log se etiqueta "TOOL JOB LOG" (backups, restores, resets, etc.) o "DEPLOYMENT JOB LOG" (Install, Upgrade, Platform Setup, etc.).

• Formato: fichero de texto plano descargable, nombre anjana-diagnostics-<timestamp>.txt.

• Auditoría: cada exportación queda registrada en el log de auditoría con el job solicitado.

Inventario de versiones

El instalador proporciona un inventario consolidado de versiones accesible desde el Dashboard y la API (GET /api/versions):

• Versión del instalador: versión actual del binario del instalador

• Versión de Anjana: versión de la plataforma configurada

• Estado por servicio: para cada microservicio, persistencia y plugin, muestra la versión configurada, la versión en ejecución (detectada automáticamente) y el estado actual (UP, DOWN, DEGRADED, UNKNOWN)

Los datos se agrupan por categoría (Core, Frontend, Persistence, Plugin) para facilitar la lectura.

Actualización automática del instalador (Self-Update)

El instalador incorpora un mecanismo completo de auto-actualización con rollback automático:

Detección de versiones

• Comprobación manual: desde Settings, botón "Check for updates" que consulta Nexus

• Comprobación automática: programable (cada hora si está habilitada), configurable desde Settings

• Respuesta: indica si hay actualización disponible, versión actual y última versión

Proceso de actualización

1. Descarga la nueva versión del JAR desde Nexus y la guarda como {jar-actual}.new

2. Genera un script de actualización en un fichero temporal único bajo /tmp/anjana-update-*.sh

3. El script espera a que el proceso actual termine (max 30s)

4. Crea backup del JAR actual como {jar-actual}.bak

5. Realiza swap atómico: mueve .new a la ubicación del JAR principal

6. Reinicia el servicio vía systemd

7. Espera 20 segundos y verifica que el servicio está activo

8. Si el arranque falla: restaura automáticamente el backup y reinicia la versión anterior

Configuración

La preferencia de auto-update se persiste en {dataDir}/update-settings.json y es accesible desde la API (GET/PUT /api/updates/settings).

Robustez operativa

Tiempos de espera de los trabajos de despliegue

Cada trabajo de despliegue (Install, Update, Platform Setup, Restart, Start, Stop, actualización de descriptores de servicio) tiene un tiempo máximo de ejecución vigilado automáticamente por el instalador. Si un trabajo se queda bloqueado más allá de ese tiempo, se marca como fallido y queda reflejado en el log con el motivo. Se distinguen dos categorías:

• Trabajos largos (Install, Update, Platform Setup): 45 minutos por defecto, configurable.

• Trabajos cortos (Restart, Start, Stop, actualización de descriptores de servicio): 10 minutos por defecto, configurable.

Caché de estado de servicios y refresco manual

Para no sobrecargar los hosts con comprobaciones repetidas, el instalador mantiene en caché durante 5 minutos (configurable) el resultado de comprobar si un servicio está instalado en cada host. Si el operador necesita un estado actualizado al instante, puede forzar la comprobación desde la interfaz o mediante el endpoint POST /api/status/refresh, que ignora la caché y repite la comprobación en el momento.

Un fallo puntual comprobando un servicio o un plugin (por ejemplo, un host temporalmente inalcanzable) no interrumpe la comprobación del resto de la plataforma.

Endpoint de estado para balanceadores externos

La ruta /_health/* del proxy de la plataforma está pensada para que un balanceador de carga o sistema de monitorización externo compruebe si la instancia está viva, sin exponer el detalle de estado de cada microservicio: responde simplemente si la plataforma está operativa o no.

Pantalla de carga durante el despliegue

Mientras se instala o arranca la plataforma, la pantalla de carga que ve el usuario muestra únicamente la fase en curso (por ejemplo, "Instalando servicios", "Configurando red") en lugar de una lista de servicios individuales, evitando confusión si algún estado tarda en sincronizarse. La comprobación de progreso está protegida frente a respuestas vacías o incompletas: en ese caso se trata como "progreso indeterminado" en lugar de darse por completada antes de tiempo.

Estado extendido del entorno (Dashboard)

Detección de estado de microservicios

La funcionalidad de status del instalador va más allá de una simple comprobación de puerto. Se cruzan múltiples fuentes de información para determinar el estado real de cada microservicio:

• Estado del servicio a nivel de sistema operativo (descriptor/systemd)

• Verificación del arranque correcto mediante análisis de logs

• Estado de registro en el servicio de descubrimiento

Los servicios no desplegados se muestran como NOT_INSTALLED en lugar de DOWN.

Detección de versiones y formato JSON

La versión de cada microservicio se detecta automáticamente mediante el análisis de los logs de arranque, sin necesidad de consultar endpoints adicionales ni ficheros de versión. Todos los datos de estado se estandarizan en formato JSON, facilitando su consumo por herramientas externas y scripts de automatización. El estado global del entorno (HEALTHY, DEGRADED, DOWN, UNKNOWN) se calcula alineado con la lógica del backend.

Logs y auditoría

El instalador registra toda su actividad en dos pipelines diferenciados:

• Log de operaciones: registro de despliegues, actualizaciones, backups y operaciones de datos.

• Log de auditoría: registro de inicios de sesión y operaciones autenticadas, separado en una pipeline independiente para facilitar la integración con sistemas SIEM del cliente.

Descriptores de servicio: Dependencias

Dependencias entre microservicios

Los microservicios se configuran con dependencias a nivel descriptor de servicio. Cada microservicio espera a que sus dependencias estén arrancadas antes de iniciar, eliminando la necesidad de la funcionalidad de arranque manual ordenado del kit Ansible.

Gestión del fichero hosts

El instalador asigna nombres en el fichero hosts del sistema operativo por máquina en lugar de por microservicio, como ocurría en el kit Ansible anterior. Esto evita que se envíe un DNS incorrecto durante el registro del microservicio en el servicio de descubrimiento, resolviendo un problema conocido del kit anterior.

Interfaz de línea de comandos (CLI)

Toda la funcionalidad disponible en la interfaz gráfica es también accesible desde la línea de comandos. El mismo binario del instalador se conecta vía HTTPS al instalador en ejecución.

Comandos de herramientas

Ejemplos de uso

# Backup completo
tools run BACKUP_ALL --yes

# Reset y carga de datos de ejemplo
tools run RESET_ALL --param restore=sample --param dataset=nativo --param version=26.1 --yes

# Carga de datos de ejemplo sin reset
tools run LOAD_SAMPLE_DATA --param dataset=nativo --yes

# Seguir logs de horus en tiempo real
logs horus --follow --lines 200

La rotación de credenciales no está disponible como operación tools run. Para rotar credenciales usar la pantalla Tools > Credentials de la interfaz gráfica, o el endpoint API POST /api/tools/credentials/rotate/{service}.

Esto permite automatización mediante scripts, integración con pipelines de CI/CD, ejecución en entornos sin interfaz gráfica y operaciones batch desatendidas.