Digdash BI: opciones de despliegue¶
La plantilla Digdash BI (categoría Visualización) expone sus opciones en el despliegue (formulario) y, para la mayoría, después mediante Configurar → Avanzado — véase Configurar una aplicación para el mecanismo general de pestañas por categoría.
General¶
| Campo | Función |
|---|---|
| Versión Digdash | Tag de la imagen bi/digdash-tomcat. Por defecto la última versión estable de la mayor elegida (<mayor>_latest) — un tag "desnudo" (ej. 2026R1) queda fijado en el primer build de esa mayor y se vuelve obsoleto rápidamente (licencia rechazada en la práctica). |
| Clave de licencia | Clave Digdash a usar para esta instancia. |
| Límite de memoria, Límite de CPU | Recursos del contenedor principal (Tomcat/JVM). |
Autenticación y entorno¶
| Campo | Función |
|---|---|
| DIGDASH_AUTH_TYPE | Modo de autenticación: OIDC (por defecto) — SSO de la plataforma (Keycloak) y directorio LDAP — LDAP — solo directorio LDAP, inicio de sesión con usuario y contraseña DigDash — o SAML2 — SSO de la plataforma en SAML 2.0: se crea un cliente SAML en el Keycloak de la plataforma durante el despliegue, y un proveedor de identidad externo se conecta mediante la autenticación por relé. SAML2 se elige en la creación: pasar de OIDC o LDAP a SAML2, o de SAML2 a otro modo, requiere reinstalar la aplicación. En todos los casos, los usuarios y roles DigDash se almacenan en el directorio OpenLDAP del sidecar dedicado, siempre desplegado: DigDash no funciona sin él, no es una opción. |
| File Browser | Activa un gestor de archivos accesorio (subida/descarga), desactivable si no se usa. |
| JVM CATALINA_OPTS, DIGDASH_SYSTEM, DIGDASH_PROPERTIES | Ajustes avanzados (flags JVM en bruto, propiedades de sistema Digdash, Digdash.properties) — un ajuste por línea, # para comentar. Reservados para los casos sin campo dedicado en el resto de este formulario. |
Modo depuración¶
Interruptor reservado al equipo DigDash (pestaña Entornos, al principio de la lista), disponible únicamente en esta plantilla — véase la página dedicada Modo depuración (Digdash BI) (activación, puertos JDWP/LDAP, exposición externa temporal).
Base de datos¶
| Campo | Función |
|---|---|
| Tipo de base de datos (pestaña Entornos, al principio de la lista) | cnpg (PostgreSQL gestionado, por defecto) o un motor externo ya existente. Fijado en la creación: cambiar de motor requiere una reinstalación. |
Copia de seguridad y restauración¶
Un interruptor activa el archivado continuo de WAL y una copia de seguridad planificada (S3, solo motor cnpg); la restauración se realiza al crear una nueva aplicación, a partir de la copia de otra — la mecánica y los campos comunes se detallan en Copia de seguridad y restauración. Campos propios de Digdash BI: compresión separada WAL/datos (gzip/bzip2/snappy), owner reference de la copia planificada, y copia inmediata en la creación.
Copia de seguridad del entorno¶
Independientemente de la base de datos, el propio entorno DigDash — usuarios, roles, cuadros de mando, modelos de datos, fuentes de datos y directorio LDAP — se copia a un bucket S3 con la herramienta oficial backuptools: véase Copia de seguridad del entorno.
Perfil superadmin¶
El perfil DigDash superadmin, asignado a la cuenta admin y a quien despliega la instancia, recibe todos los roles de la instancia, con lectura, escritura y ejecución. Un rol creado después en DigDash se le añade automáticamente:
- justo después del despliegue;
- mediante la tarea programable Dar al perfil superadmin de DigDash todos los roles de su instancia (Parámetros → Tareas programadas), por ejemplo cada hora;
- a demanda, con el botón «Dar al perfil superadmin de DigDash todos los roles de la instancia» de la tarjeta (rol admin), por ejemplo justo después de crear un rol.
La Prueba de compatibilidad de API comprueba que el perfil superadmin tiene todos los roles, así como las llamadas de API que sirven para dárselos.
Volúmenes¶
En la pestaña Capacidad, junto a la memoria y la CPU: tamaños de los volúmenes appdata (datos de la aplicación) y openldap (directorio del sidecar OpenLDAP, siempre presente), además de adjuntar un volumen existente ya huérfano a cada uno. Fijados en la creación: el redimensionado o el cambio de volumen después se hace desde la pestaña Volúmenes, no desde este formulario.
Certificados CA personalizados¶
Para una instancia que deba confiar en una autoridad de certificación interna (ej. un servicio de terceros en HTTPS con un certificado corporativo): activa el montaje de un conjunto adicional de CA en el truststore del contenedor, en formato nombre_de_archivo: PEM (YAML), o desde un Secret de Kubernetes ya existente.
OpenID¶
SSO_LOGOUT (pestaña Entornos, al final de la lista): URL de redirección tras cerrar sesión — por defecto la de la plataforma, ajustarla solo para un flujo de cierre de sesión personalizado.