Instalación

Manual de despliegue Installer

Antes de empezar

Limitaciones del instalador

Es necesario revisar este apartado para tener en cuenta las limitaciones cuando se hace uso del instalador.

  • El instalador se vincula a un solo entorno de Anjana. Serán necesarias múltiples instancias para gestionar distintos entornos.

  • La máquina donde se ejecute el instalador deberá pertenecer a un solo entorno de Anjana, ya que será plataformada y sufrirá cambios de acuerdo al entorno que se esté manejando.

  • En caso de que falle la instalación y el relanzamiento falle, será recomendable reaprovisionar la máquina en limpio y comenzar de nuevo.

  • El usuario anjana es un usuario reservado y no puede existir previamente en la máquina.

Requisitos

Conectividad

El instalador descargará todos los recursos necesarios desde el repositorio central de Anjana Data por protocolo HTTPS y puerto 443 contra el servidor releases.anjanadata.com, por lo que será necesario tener conectividad desde los servidores a provisionar con dicho servicio.

Adicionalmente, el instalador contactará con el servicio de licencias en veltesta.anjanadata.com para la activación y validación, por lo que esa conectividad también es requerida por HTTPS y puerto 443.

Máquina y accesos

El instalador se distribuye como un binario autónomo que incluye tanto el backend como el frontend - no instala ni configura nada más por su cuenta hasta que se ejecuta explícitamente. Para poder descargarlo y ponerlo en marcha se necesita:

  • Sistema operativo Ubuntu 24.04 o RedHat 9

  • Usuario con permisos root en la máquina

  • IP fija de salida a Internet

  • Arquitectura x86_64 (Intel/AMD 64 bits)

  • Credenciales de acceso al repositorio de Anjana Data (usuario Nexus), solicitadas previamente a cs@anjanadata.com - se usarán en el siguiente paso para descargar el kit

Instalar el binario del instalador

Una vez cumplidos los requisitos, los pasos para poner en marcha el servicio del instalador son los siguientes.

1. Descargar el kit

El kit se distribuye desde releases.anjanadata.com con el formato de nombre kit-anjana-installer-VERSION.tgz, bajo la ruta Maven com/anjana/kit-anjana-installer/VERSION/ (la versión va en su propio directorio).

Bash
wget --user=<nexus-user> --ask-password \
  "https://releases.anjanadata.org/repository/releasesraw/com/anjana/kit-anjana-installer/VERSION/kit-anjana-install
  er-VERSION.tgz" \
  -P /tmp/

2. Extraer en /opt

Bash
sudo tar -xzf /tmp/kit-anjana-installer-VERSION.tgz -C /opt

Esto crea el directorio /opt/anjana-installer/ con la siguiente estructura:

/opt/anjana-installer/
├── anjana-installer.service
├── bin/
│   └── anjana-installer        # Launcher
├── jre/                        # JRE embebido
└── lib/
    └── anjana-installer.jar    # Fat JAR Spring Boot

3. Ejecutar el comando install

Bash
sudo /opt/anjana-installer/bin/anjana-installer install

Este comando realiza automáticamente los siguientes pasos:

  1. Detecta el sistema operativo (debian / redhat)

  2. Instala JDK 17 vía apt-get o dnf según el SO

  3. Crea el directorio de datos en /opt/anjana-installer/data

  4. Registra la unit systemd en /etc/systemd/system/anjana-installer.service

  5. Ejecuta systemctl enable --now anjana-installer

No es necesario copiar manualmente el fichero .service ni ejecutar systemctl daemon-reload. El comando install gestiona todo el ciclo de registro del servicio.

4. Acceder a la interfaz

Al finalizar, el instalador está disponible por HTTPS en el puerto 8787 bajo la ruta /installer. El mensaje final del comando muestra la URL con el hostname o la IP de la máquina, por ejemplo https://<host-o-ip>:8787/installer.

El acceso se realiza directamente desde la red del cliente: red interna corporativa, VPN de la organización, o la vía de exposición controlada que se haya definido para la máquina del instalador (por ejemplo, un balanceador o un bastión propio). Si la máquina no es alcanzable directamente desde el puesto de quien va a administrar el instalador, deberá habilitarse la ruta de red correspondiente (regla de firewall, VPN, etc.) según cómo esté desplegado el entorno, antes de abrir la URL anterior en el navegador.

En el primer arranque, si no se ha fijado una contraseña de antemano, el instalador genera automáticamente una contraseña aleatoria segura para el usuario admin y la muestra una única vez en el log de arranque del servicio. Esta contraseña generada no obliga a cambiarla en ese primer inicio de sesión: la obligación de cambio se activa más adelante, en el momento en que se inicializa el gestor de secretos del instalador, lo cual ocurre al guardar la configuración del asistente (Wizard) por primera vez. A partir de ese guardado, el sistema exigirá cambiar la contraseña de admin antes de continuar. Para despliegues automatizados es posible fijar la contraseña inicial mediante variable de entorno antes del primer arranque, evitando así la generación aleatoria.

Primer arranque y configuración inicial

Con el instalador ya corriendo y accesible, el siguiente paso es completar el asistente de configuración (Wizard). Hay tres caminos para llegar a una configuración completa - elige el que corresponda a tu situación:

  • A. Configurar desde cero: para un entorno nuevo que nunca se ha desplegado.

  • B. Importar una configuración ya exportada del propio instalador: para restaurar o clonar una configuración previa (fichero YAML).

  • C. Migrar desde un kit Ansible existente: para un entorno ya desplegado con el kit Ansible que pasa a gestionarse con el instalador.

A. Configurar desde cero

El asistente solicita los siguientes datos:

  • Modo de instalación (nuevo entorno)

  • Credenciales de Nexus solicitadas previamente a Anjana Data.

  • Dominio necesario para el frontal y la comunicación entre microservicios

  • Certificado TLS correspondiente al dominio elegido (el instalador genera uno autofirmado por defecto si no se especifica uno)

  • Licencia clave del producto proporcionada por Anjana Data

  • Monitorización, para habilitar el agente Open Telemetry

  • Persistencias, con la configuración de conexión a bases de datos, servicios S3 y demás persistencias

Un botón de comprobación de conexión permite validar las credenciales de Nexus introducidas antes de avanzar al siguiente paso del asistente.

Single VM: Para entornos Single VM no se requieren ajustes adicionales de conectividad a persistencias cuando éstas son locales. No es necesario rellenar las URLs de persistencias ya que siempre serán localhost.

Core + Persistencias (Distribuido): Para entornos distribuidos será necesario configurar las credenciales de conexión SSH a las instancias adicionales y las URLs de las persistencias gestionadas o remotas.

Autenticación (Zeus SSO)

Como parte del asistente, se configuran los proveedores de autenticación que utilizará Zeus para el acceso de usuarios a la plataforma Anjana. Se soportan cuatro tipos de proveedores:

Proveedor

Descripción

Local DB

Autenticación contra la base de datos interna de Anjana (habilitado por defecto)

LDAP

Autenticación contra un directorio LDAP corporativo. Configurable: URL, Base DN, atributos de búsqueda, tipo de conexión

OIDC / OAuth2

Autenticación mediante OpenID Connect. Soporta múltiples proveedores simultáneos (Google, Azure AD, Keycloak, etc.). Configurable: issuer URI, client ID, scopes, atributo de username

SAML2

Autenticación mediante SAML 2.0. Soporta múltiples proveedores. Configurable: entity ID, IdP Metadata URI, clave y certificado del Service Provider (opcional)

Los secrets asociados a cada proveedor (contraseña LDAP, client secrets OIDC, claves SAML2) se almacenan en el secrets backend del instalador y se gestionan desde la pantalla de Secrets del wizard. Detalle completo de parámetros por proveedor y del paso de aprovisionamiento de usuarios en Funcionalidad Avanzada Installer.

B. Importar una configuración ya exportada del propio instalador

Permite importar un fichero YAML exportado previamente por el propio instalador (botón "Export YAML" en la página de Configuración). El fichero se deserializa directamente y se aplica toda la configuración. Es la pestaña seleccionada por defecto en el diálogo de importación, accesible desde la página de Configuración.

Por motivos de seguridad, el YAML exportado por el instalador nunca incluye las credenciales de las persistencias (PostgreSQL, MongoDB, S3/SeaweedFS, etc.) en texto plano: esos valores no forman parte del fichero exportado. Tras importar esta configuración, dichas credenciales deberán rellenarse manualmente en el wizard antes de continuar.

C. Migrar desde un kit Ansible existente

Aplica a entornos ya desplegados con el kit Ansible de Anjana que pasan a gestionarse con el instalador. La importación traduce la configuración del kit al formato del instalador, de forma que no es necesario reconstruirla a mano en el asistente.

Ficheros a preparar

A diferencia de la importación de un YAML propio (camino B), el fichero all.yaml del kit Ansible sí contiene las credenciales de las persistencias en texto plano, tal y como las gestiona ese kit. La migración las extrae de ahí automáticamente para las persistencias que aún no estén desplegadas en la máquina; no es necesario volver a introducirlas a mano en el wizard para esos casos. Para las persistencias ya desplegadas no se sobrescribe la credencial existente (ver "Protección de credenciales durante la importación" más abajo): en ese caso sí deberá revisarse o completarse manualmente en el wizard.

Del inventario del kit Ansible se necesitan:

  • all.yaml (group_vars): configuración y credenciales del entorno

  • hosts.yaml: inventario y definición de nodos

De forma opcional, la importación acepta también el fichero anjanauihosts.yaml (group_vars del grupo anjana_ui) para portar las whitelists de acceso del kit: la whitelist de apache pasa a la lista General y las whitelists de persistencias y horus se combinan en la lista Internal de IP Access Control (ver Ajustes, detalle completo en Funcionalidad Avanzada Installer). El diálogo de importación de la interfaz solicita all.yaml y hosts.yaml; el fichero anjanauihosts.yaml puede aportarse como tercer fichero opcional a través de la API de importación del instalador.

Flujo de importación

  1. En Configuración, abrir el diálogo de importación y seleccionar la pestaña Ansible Kit

  2. Seleccionar los ficheros all.yaml y hosts.yaml y pulsar Preview Import (si los ficheros se suben en orden equivocado, el instalador lo detecta y los intercambia automáticamente, indicándolo con un aviso)

  3. Revisar el preview: configuración mapeada (topología detectada, versión, dominio, hosts, persistencias, Nexus, monitorización), lista de warnings, avisos de migración y secrets detectados

  4. Pulsar Confirm Import para persistir la configuración y los secrets

Qué se mapea automáticamente

  • Todos los valores de configuración del all.yaml al formato del instalador

  • La topología del entorno (Single VM, Distribuido, etc.) a partir del inventario

  • Las credenciales detectadas, que se almacenan como secrets del instalador

  • Las whitelists de acceso, si se aporta el fichero anjanauihosts.yaml (las entradas malformadas o con CIDR inválido se descartan y se notifican como warnings)

Avisos de migración

Durante el preview pueden mostrarse avisos que requieren acción:

  • MinIO a SeaweedFS: MinIO ya no está soportado como backend de almacenamiento de objetos; el instalador despliega SeaweedFS en su lugar. En este flujo de importación desde kit Ansible la migración de los datos es manual: tras completar la instalación, hay que migrar los buckets de MinIO a SeaweedFS con mc mirror y retirar MinIO del kit Ansible original (anjana -t delete-minio)

  • Regeneración de certificados TLS: Platform Setup genera certificados autofirmados y keystores nuevos; los certificados desplegados por el kit Ansible no se importan. Tras Platform Setup se requiere un reinicio completo de todos los servicios de Anjana para aplicar los nuevos certificados

Este aviso de migración manual aplica solo a la importación desde un kit Ansible existente (camino C). Es un caso distinto de la actualización 25.2 → 26.1 de un entorno que ya está gestionado por el instalador: en ese caso, si la actualización incluye migración de almacenamiento de objetos, MinIO se migra y se elimina completamente (servicio, binario y datos) de forma automática, una vez confirmada la validación de salud posterior a la migración (ver "Actualización de la plataforma" más abajo).

Protección de credenciales durante la importación

Al confirmar una importación, el instalador comprueba qué persistencias están ya desplegadas (via systemctl). Las credenciales de servicios deployed no se sobreescriben, evitando desincronizar el secrets store con la contraseña real del servicio. Se muestra un aviso agrupado: "Credentials not overwritten for deployed services: PostgreSQL, SeaweedFS, ... Use Tools > Credentials to rotate them."

Las credenciales de servicios no desplegados se importan normalmente y se aplicarán durante la instalación.

Qué revisar después de importar

  • Los warnings mostrados en el preview y en el resultado de la importación (secciones ausentes, valores desconocidos sustituidos por defaults, referencias no resueltas)

  • Las entradas de whitelist portadas, desde Settings > IP Access Control (rangos, etiquetas y entradas descartadas)

  • La configuración completa en el asistente antes de lanzar el Preflight, especialmente credenciales y URLs de persistencias

Instalar Anjana Data Platform