Control Panel — Documentación

Description

Guide d'utilisation du DigDash Control Panel

Control Panel

El DigDash Control Panel es el portal de gestión de la plataforma de datos: permite desplegar, supervisar y administrar aplicaciones (PostgreSQL, Digdash BI, Apache Hop, nginx…) en el clúster Kubernetes de la plataforma, sin necesidad de manipular Kubernetes directamente.

Lo que puede hacer

Necesidad	Dónde ir
Desplegar una aplicación desde el catálogo	Desplegar una aplicación
Ajustar CPU, memoria, variables de entorno	Configurar una aplicación
Copiar y restaurar una base de datos	Copia de seguridad y restauración
Gestionar volúmenes persistentes y buckets S3	Volúmenes · Buckets S3
Dar acceso a una aplicación a un compañero	Acceso y permisos
Crear cuentas de usuario	Usuarios
Alojar y compartir código Git internamente	Git
Administrar namespaces, cuotas y ajustes	Ajustes

Primeros pasos

¿Nuevo en la plataforma? Empiece por Primeros pasos: inicio de sesión, recorrido por la interfaz y su primer despliegue en cinco minutos.

Búsqueda

Utilice la barra de búsqueda en la parte superior de esta documentación para encontrar directamente una página o un concepto (por ejemplo, «quota», «snapshot», «OIDC»).

Primeros pasos

Iniciar sesión

La autenticación se realiza mediante la cuenta corporativa (Keycloak). En la página de inicio de sesión, haga clic en Iniciar sesión: será redirigido al formulario Keycloak de la plataforma y, una vez identificado, volverá al panel de control.

Note

Sus permisos en el Control Panel (namespaces visibles, acciones permitidas) dependen de los roles que se le hayan otorgado — véase Acceso y permisos. Una pantalla vacía en el primer inicio de sesión suele significar que todavía no se le ha asignado ningún rol.

La interfaz de un vistazo

• Barra lateral (izquierda): navegación principal — Aplicaciones, Recursos, Volúmenes, Buckets, Jobs Spark, Acceso a apps, Permisos internos, luego Clúster (seguido del enlace Grafana si la supervisión está instalada), Usuarios, Ajustes. En la parte inferior: su perfil, su cuenta de Git y el cierre de sesión.
• Cabecera: el selector de namespace (su espacio de trabajo actual — todas las listas de la página se refieren a él), la búsqueda, la actualización manual o automática («Auto», cada 5 segundos), y los botones Nuevo namespace / Nueva app.
• Indicador de cuota: debajo de la cabecera, el consumo del namespace actual (CPU, memoria, pods, almacenamiento) respecto a sus cuotas — véase Namespaces y cuotas.
• Tarjetas de aplicación: una tarjeta por aplicación desplegada, con su estado (Running, Pending, Stopped, Error), sus indicadores de CPU/RAM y sus acciones.

Su primer despliegue

1. Elija su namespace en el selector de la cabecera.
2. Haga clic en Nueva app y elija una plantilla — por ejemplo PostgreSQL, la más rápida de iniciar.
3. Asígnele un nombre (letras minúsculas, dígitos y guiones), deje los valores predeterminados y luego Desplegar la aplicación.
4. La tarjeta aparece en Pending y luego pasa a Running — de unos segundos a varios minutos según la plantilla (Digdash BI es la más larga).

La configuración propia de cada aplicación se documenta en la sección Aplicaciones, una página por aplicación; los campos comunes a todos los despliegues se describen en Desplegar una aplicación.

Cambiar el idioma de la interfaz

Desde Mi perfil (parte inferior de la barra lateral), un selector de Idioma permite elegir francés, inglés o español. Un administrador también puede definir el idioma de cada cuenta desde la página Usuarios.

Clúster

La página Clúster (reservada a los administradores de plataforma) ofrece una vista global, en tiempo real, de los recursos Kubernetes de toda la plataforma — de todos los namespaces. Se actualiza automáticamente cada 30 segundos, o de inmediato mediante Actualizar.

La cabecera muestra cuatro indicadores rápidos: el número de nodos, el número de pods en ejecución, y el total de volúmenes y de buckets de la plataforma, de todos los namespaces.

Resumen global

Tres indicadores por recurso (CPU y memoria), en relación con la capacidad total del clúster:

Indicador	Significado
Usado	Consumo real medido por el servidor de métricas
Solicitado (requests)	Suma de las cantidades solicitadas por todos los pods — lo que Kubernetes garantiza
Límites	Suma de los topes configurados — puede superar la capacidad real (sobreasignación), a vigilar

Al hacer clic en la etiqueta de un indicador se abre el desglose por pod: la lista de todos los pods del clúster ordenada por consumo, con un enlace directo a la aplicación correspondiente cuando el pod pertenece a una release gestionada por el Control Panel.

Almacenamiento

Una tarjeta de almacenamiento Ceph completa el resumen global cuando la información está disponible. Muestra, según lo que se haya podido determinar:

• la cuota del pool Ceph RBD aplicativo y su ocupación, si ese pool tiene una cuota fijada;
• en su defecto, la ocupación del pool en relación con la capacidad total del clúster Ceph, si el pool no tiene cuota;
• como último recurso, la capacidad global del clúster Ceph (Rook), si no se ha podido determinar el pool aplicativo.

La tarjeta no aparece si ninguna de estas informaciones está disponible (por ejemplo, si la CLI ceph no está accesible).

Buckets S3

La sección Buckets S3 lista todos los buckets de la plataforma, del más grande al más pequeño: namespace, número de objetos, tamaño, tamaño almacenado tras la compresión y ahorro de compresión, con los totales encima. Al hacer clic en un namespace se abren sus buckets. Si la API de administración del almacenamiento de objetos (RGW) no es accesible, la sección lo indica.

Solo se cuentan los buckets creados en esta plataforma: cuando varias plataformas comparten el mismo almacenamiento Ceph, los buckets de las demás no aparecen.

Supervisión

Cuando la pila de supervisión de la plataforma (Prometheus, Grafana, Alertmanager) está instalada, la cabecera de la página ofrece tres enlaces externos Grafana, Prometheus y Alertmanager (autenticación con la cuenta de plataforma habitual), y una tarjeta Alertas activas lista las alertas Prometheus en curso (firing), las más graves primero, con su namespace y el pod afectado.

La misma pila alimenta también, en otros lugares del Control Panel:

• la columna Usado de la página Volúmenes;
• el enlace Métricas de las tarjetas de aplicación (dashboard Grafana del pod o del namespace) — ver Aplicaciones;
• el banner n alertas activas encima del panel de un namespace;
• el enlace Grafana de la barra lateral.

Si Prometheus no es accesible desde el Control Panel, los enlaces siguen visibles pero la tarjeta lo indica y los valores derivados (alertas, consumo de volúmenes) se muestran como no disponibles (n/d). Las URL públicas (GRAFANA_URL, PROMETHEUS_PUBLIC_URL, ALERTMANAGER_URL) y la dirección interna de Prometheus (PROMETHEUS_URL) pueden sobrescribirse en Parámetros del clúster.

Nodos

Cada nodo del clúster se presenta con su estado (Ready o no), sus roles, y los mismos seis indicadores (CPU/memoria × usado/solicitado/límites) en relación con su propia capacidad — útil para detectar un nodo desequilibrado antes de que el scheduler de Kubernetes tenga dificultades para ubicar nuevos pods en él.

Note

Estos indicadores ofrecen una vista completa de la plataforma, incluidas las cargas que no son aplicaciones del catálogo (componentes del sistema, otros servicios del clúster). Para el detalle de los recursos de un solo namespace, véase la tarjeta de aplicación correspondiente en el panel de control.

Licencia

Menú Licencia — acceso reservado a los administradores de la plataforma.

El Control Panel funciona con una licencia emitida por DigDash para un clúster concreto. Fija un cliente, una fecha de caducidad y un límite de CPU. La página Licencia muestra su estado, prepara una solicitud de licencia e instala la licencia recibida.

Qué se cuenta

El límite se aplica a la suma de los límites de CPU (limits.cpu) de las aplicaciones desplegadas, no a los núcleos de los nodos ni al consumo real:

• solo se cuentan los pods de los namespaces de aplicaciones (los que muestra el Control Panel);
• solo los pods en ejecución o pendientes de arrancar: una aplicación detenida (0 réplicas) deja de contar;
• no se cuentan los pods ubicados en los nodos del plano de control de Kubernetes;
• no se cuenta la infraestructura (almacenamiento, supervisión, pasarela, el propio Control Panel).

Ejemplo: una aplicación de 2 pods limitados cada uno a 1,5 CPU cuenta como 3 CPU, consuma 0,1 o 3 núcleos. El límite de CPU de una aplicación se ajusta en su configuración (ver Configurar una aplicación).

El total se mide cada minuto. Una medición de más de 10 minutos se considera desconocida y nunca bloquea nada.

Evolución en 30 días

La curva muestra la suma de los límites de CPU de las aplicaciones durante los últimos 30 días, un punto por hora (el valor más alto de la hora, para que los picos sigan visibles). La línea discontinua es el límite de la licencia. Al pasar el ratón se muestra el valor en una fecha dada.

Avisos y bloqueos

Situación	Efecto
Caducidad en 15 días o menos	Banner en la parte superior de todas las páginas, con los días restantes.
Límite de CPU superado	Banner, y se rechazan los nuevos despliegues mientras el total siga por encima del límite. Las aplicaciones existentes siguen funcionando.
Sin licencia, o licencia caducada, no válida o emitida para otro clúster	El Control Panel queda bloqueado: todas las páginas redirigen a la página Licencia. Las aplicaciones ya desplegadas siguen funcionando.

Sin licencia válida, los usuarios que no son administradores de la plataforma solo ven el estado de la licencia y la invitación a contactar con un administrador.

Obtener o renovar una licencia

La sección Solicitud de licencia reúne la información que necesita DigDash:

• el identificador del clúster (la licencia solo es válida en este clúster);
• el nombre de la plataforma y la versión del Control Panel;
• la suma actual de los límites de CPU de las aplicaciones;
• el número de nodos fuera del plano de control y su capacidad de CPU;
• la licencia actual, si la hay.

Descargar la solicitud genera un archivo JSON para enviar a DigDash; Copiar pone el mismo contenido en el portapapeles.

Instalar una licencia

Pegue la licencia proporcionada por DigDash en Instalar una licencia y haga clic en Instalar. Se verifica de inmediato y se rechaza si ha sido modificada o si se emitió para otro clúster. Una licencia aceptada sustituye a la anterior y desbloquea el Control Panel sin reinicio.

Consultar la licencia instalada

Mostrar la licencia muestra el texto de la licencia instalada, por ejemplo para comprobarla o enviarla a DigDash; Copiar la pone en el portapapeles. Cada consulta queda registrada en los logs de auditoría.

Actualizaciones

Menú Actualizaciones — acceso reservado a los administradores de la plataforma.

La página Actualizaciones muestra la versión instalada del Control Panel, las versiones más recientes disponibles con sus notas, e instala una nueva versión con un clic.

Canal

Cada plataforma sigue un canal de publicación:

Canal	Para quién	Contenido
stable (por defecto)	plataformas de clientes	versiones validadas por las pruebas de extremo a extremo antes de su publicación
beta	plataformas internas	cada nueva versión, en cuanto se publica

El canal se ajusta con el parámetro UPDATE_CHANNEL en los parámetros del clúster (stable o beta).

Comprobación de nuevas versiones

El Control Panel comprueba el canal cada hora. Comprobar ahora lanza la comprobación de inmediato; la fecha de la última comprobación aparece en la parte superior de la página. Cuando existe una versión más reciente, aparece una insignia vX.Y.Z disponible al pie del menú, en todas las páginas.

Cada versión disponible se muestra con sus notas; la más reciente lleva la insignia la más reciente.

Actualización automática

La sección Actualización automática instala una vez por semana, a la hora elegida, la última versión disponible en el canal. Está desactivada por defecto; la franja propuesta es el sábado a las 12:00, hora de París.

• Marque Activar la actualización automática, elija el día y la hora y pulse Guardar.
• A esa hora, el Control Panel comprueba el canal: si ya está actualizado, o si hay una actualización en curso, no ocurre nada. Si no, la actualización se desarrolla exactamente como una actualización manual (copia de seguridad, instalación, vuelta atrás automática en caso de fallo). Aparece en el historial con automatique como autor.
• El mismo ajuste existe en Ajustes → Tareas programadas (tarea auto_update_controlpanel), donde también se puede introducir una expresión crontab más precisa. En ese caso la página Actualizaciones lo indica; guardar desde la página sustituye la expresión por una franja semanal.

Cada cambio de este ajuste queda registrado en los logs de auditoría.

Actualizar

Actualizar a X.Y.Z pide confirmación y después:

1. Copia de seguridad: se hace una copia de la base de datos del Control Panel (copia CloudNativePG mediante snapshot de volumen, restaurable). Si la copia falla, la actualización se cancela y no se modifica nada.
2. Instalación: se instala la nueva versión.
3. Verificación: si la nueva versión no arranca, se restablece automáticamente la versión anterior.

La interfaz no está disponible durante uno o dos minutos mientras se instala; la página se actualiza sola. Las aplicaciones desplegadas no se ven afectadas. Una vez instalada la nueva versión, un botón propone recargar la página para cargar la nueva interfaz.

Se conservan las copias de las tres últimas actualizaciones; las más antiguas se eliminan automáticamente.

Nota

La actualización solo es posible desde el Control Panel desplegado en el clúster, no desde una instalación de desarrollo.

Historial

El historial lista las actualizaciones anteriores: fecha, versiones de origen y destino, autor y resultado (Correcta o Fallida, con el motivo). Registro muestra la salida de la instalación, útil para entender un fallo.

Aplicaciones

Aplicaciones

El panel de control muestra las aplicaciones del namespace actual, una tarjeta por aplicación.

El catálogo

El botón Nueva app abre el catálogo de plantillas disponibles, por categoría:

Categoría	Plantillas
Procesamiento	Apache Hop (GUI), Apache Hop Server, Trino, Spark Connect, Apache NiFi
Almacenamiento	PostgreSQL, Servidor SFTP
Visualización	Digdash BI
Gobernanza	Apache Iceberg (catálogo Polaris), OpenMetadata
Ciencia de datos	JupyterHub, MLflow
DevOps	Nginx (sitio estático)

Las plantillas Apache Iceberg, Trino y JupyterHub se combinan en un lakehouse sobre los buckets S3 de la plataforma — véase Lakehouse.

Forgejo, un caso aparte

El servidor Git Forgejo no aparece en este catálogo: es una aplicación transversal a la plataforma (una única instancia para todo el clúster), gestionada desde Ajustes → Git — véase Git.

Anatomía de una tarjeta

Cada tarjeta muestra:

• el nombre (o el nombre para mostrar si se ha personalizado), la plantilla y la imagen desplegada;
• el estado: Running, Pending (iniciando), Stopped, Error;
• los indicadores de CPU y RAM: consumo real respecto a los recursos solicitados;
• la fecha de creación y el autor del despliegue.

Entender los indicadores de CPU y RAM

Cada indicador muestra el consumo real del pod (obtenido del servidor de métricas del clúster) en relación con su límite si la aplicación tiene uno, o si no, con su cantidad solicitada (requested) — véase Configurar una aplicación para la diferencia entre ambos.

• 0,85 / 2,00 cores: 0,85 núcleos consumidos para un límite de 2 núcleos.
• 3,2 Gi / 4,0 Gi: 3,2 Gi de RAM consumidos para un límite de 4 Gi.
• n/d: el servidor de métricas del clúster aún no tiene medición para este pod (reinicio reciente, por ejemplo) — el indicador permanece en gris.

El color de la barra indica el nivel de consumo respecto a ese tope:

Color	Umbral	Significado
🟢 Verde azulado	< 60 %	Consumo normal
🟠 Ámbar	60 % – 79 %	Se acerca al tope — vigilar
🔴 Rojo	≥ 80 %	Cerca o en el tope — la aplicación puede verse limitada (CPU) o eliminada por el kernel (memoria, OOMKill)

En la captura anterior, la CPU (42,5 % del límite) permanece en verde azulado mientras que la RAM (80 % del límite) pasa a rojo — es la señal para aumentar el límite de memoria de la aplicación desde Configurar.

Acciones disponibles

Según la plantilla y el estado de la aplicación:

Acción	Efecto
Abrir (enlace externo)	Acceder a la aplicación desplegada en una nueva pestaña
Métricas (enlace externo)	Abrir el dashboard Grafana de la aplicación (pod o namespace) — presente si la supervisión de la plataforma está instalada, ver Clúster
Detener / Iniciar	Detener o reiniciar la aplicación sin eliminarla
Reiniciar	Reiniciar los pods (rollout)
Configurar	Modificar el nombre para mostrar, los recursos, las variables… — véase Configurar
Ver detalles	Pods, servicios, rutas, información de conexión interna
Gestionar acceso	Autorizar a otros usuarios — véase Acceso y permisos
Eliminar	Desinstalar la release (confirmación reescribiendo el nombre, irreversible)

Acciones específicas de determinadas plantillas

• Prueba de compatibilidad de la API (Digdash BI, Apache Hop Server, Forgejo): comprueba de extremo a extremo que la API de la aplicación responde, con un resultado detallado por punto de control (insignia Saludable o Degradado).
• Resincronizar conexiones Hop (Apache Hop GUI): regenera de inmediato los archivos de metadatos del proyecto Hop (conexiones a las bases PostgreSQL, a los servidores Hop y a los buckets del namespace), sin esperar a la sincronización periódica.
• Resincronizar conexiones DigDash (Digdash BI): reaprovisiona las conexiones internas de Audit / Comentarios / Formulario hacia el PostgreSQL integrado.
• Jobs de Hop (Apache Hop Server): seguimiento y lanzamiento de los pipelines y workflows programados — véase Apache Hop Server: jobs y planificación para más detalle.

Desplegar una aplicación

1. Compruebe el namespace seleccionado en la cabecera — la aplicación se desplegará ahí.
2. Haga clic en Nueva app y luego en Desplegar bajo la plantilla deseada.
3. Complete el formulario de configuración y luego Desplegar la aplicación.

Los campos comunes

• Nombre de la aplicación (obligatorio): solo letras minúsculas, dígitos y guiones. Identifica la release y ya no puede cambiarse después (el nombre para mostrar, en cambio, sigue siendo modificable — véase Configurar).
• Namespace: precargado con el namespace actual.
• Versión: la etiqueta (tag) de la imagen, cargada dinámicamente desde el registro de la plataforma.
• Capacidad (CPU / memoria / almacenamiento): cada plantilla tiene valores predeterminados razonables; redúzcalos si la cuota del namespace es ajustada. Memoria, disco y CPU se introducen como número entero + unidad: Mi, Gi o Ti para la memoria y los discos, m (milinúcleos) o núcleos para la CPU, m o g para los tamaños JVM (heap de NiFi, memoria Spark).

Los campos varían después según la plantilla: credenciales de administrador, propiedades de la aplicación, volúmenes, origen Git (para Apache Hop), copias de seguridad (para PostgreSQL y Digdash BI)…

Cuota insuficiente

Si el despliegue falla con un mensaje exceeded quota, el namespace ya no tiene suficiente CPU, memoria o almacenamiento disponible. Reduzca la capacidad solicitada, elimine recursos no utilizados o pida a un administrador que aumente la cuota.

Después del despliegue

La tarjeta aparece de inmediato en Pending. El paso a Running tarda:

• unas decenas de segundos para nginx o PostgreSQL;
• uno o dos minutos para Apache Hop;
• varios minutos para Digdash BI (JVM + base PostgreSQL integrada).

Algunas plantillas (Apache Hop, Digdash BI) también crean automáticamente un cliente OIDC en Keycloak: el acceso a la aplicación desplegada pasa entonces por la autenticación corporativa, y los usuarios autorizados se gestionan desde Gestionar acceso en la tarjeta.

Restaurar desde una copia de seguridad al crear la aplicación

Para PostgreSQL y Digdash BI, la sección Restauración del formulario permite crear la aplicación directamente a partir de una copia de seguridad S3 existente — véase Copia de seguridad y restauración.

Configurar una aplicación

El botón Configurar de una tarjeta abre la configuración del despliegue en curso. Si la aplicación tiene varios pods (por ejemplo, Digdash BI y su PostgreSQL integrado), primero se muestra un selector de pod.

Pestaña General

• Nombre para mostrar: la etiqueta que se muestra en la tarjeta, modificable en cualquier momento (a diferencia del nombre técnico).
• Réplicas: número de instancias del pod.

Pestaña del contenedor

Para cada contenedor de la aplicación:

• Imagen: la etiqueta (tag) es modificable (lista cargada desde el registro) — cambiar de versión vuelve a desplegar la aplicación.

• Recursos: CPU y memoria, cada uno con dos valores distintos:

  • Solicitado — la reserva garantizada en el clúster (contabilizada en la cuota del namespace);
  • Límite — el tope a partir del cual el contenedor se ve limitado (CPU) o se reinicia (memoria).

  Cada valor se introduce como número entero + unidad (m o núcleos para la CPU, Mi/Gi/Ti para la memoria). El límite debe ser mayor o igual que el solicitado. Modificar estos valores provoca un reinicio del pod.

• Variables de entorno: se muestran en modo solo lectura (nombre y valor de los contenedores estándar) — no se pueden modificar desde este modal.

Pestaña Volúmenes

Los volúmenes persistentes montados por la aplicación, con la posibilidad de apuntar un montaje a otro PVC existente (por ejemplo, un clon o un volumen restaurado desde una instantánea — véase Volúmenes).

Ajustes avanzados

Los campos propios de la plantilla (propiedades de Digdash, planificación de copias de seguridad, origen Git de Hop…) que siguen siendo modificables después del despliegue. Los campos marcados con un candado están bloqueados — su información sobre herramientas explica por qué (por ejemplo: «Cambiar el motor de base de datos requiere una reinstalación»).

Tip

Después de un Guardar, si los recursos o la imagen han cambiado, la aplicación se reinicia: la tarjeta vuelve brevemente a Pending antes de regresar a Running.

PostgreSQL

PostgreSQL: opciones de despliegue

La plantilla PostgreSQL despliega una base de datos gestionada por el operador CloudNativePG (CNPG) en el clúster.

Estos ajustes se eligen en el formulario Nueva app, antes de desplegar:

• Número de instancias: 1 por defecto (sin alta disponibilidad). A partir de 2, CNPG conmuta automáticamente a una réplica si el primario falla. Editable en cualquier momento desde Configurar, incluso después del despliegue: CNPG añade o retira réplicas en consecuencia.
• PostGIS (datos geoespaciales): una sola casilla. La imagen de PostgreSQL que incluye la extensión se elige automáticamente (parámetro de clúster POSTGIS_DEFAULT_IMAGE) y la extensión se crea en la base de datos al desplegar — no hay nada más que rellenar. Un campo Imagen PostGIS (avanzado), oculto, permite imponer otra versión, que debe corresponder entonces a la versión mayor de PostgreSQL del operador CNPG.
• Métricas Prometheus: activadas por defecto, exponen las métricas de CNPG a la Prometheus de la plataforma.
• Pooling de conexiones (PgBouncer): desactivado por defecto; útil para cargas de trabajo con muchas conexiones cortas. Una vez activado, las aplicaciones que quieran usarlo se conectan al servicio <nombre-app>-postgres-pooler en lugar del servicio -rw habitual.

Warning

Al igual que el nombre de la base o el usuario admin, PostGIS solo se aplica en la creación de la aplicación (bootstrap de CNPG): activarlo en una aplicación ya desplegada no tiene efecto.

Véase también

• Administración de PostgreSQL — bases de datos, usuarios y permisos, ejecución de SQL, acceso externo desde un puesto o una herramienta de terceros.
• Copia de seguridad y restauración — archivado continuo de los WAL hacia S3, restauración en una nueva aplicación, restauración a una fecha concreta.

Administración de PostgreSQL

El botón Administrar de una tarjeta PostgreSQL (chart/postgres) — visible una vez que la aplicación está Running, reservado a los usuarios con el rol admin en el namespace.

La modal se conecta en directo a la base de datos de la aplicación (sin copia ni caché en el Control Panel) con la cuenta administradora que el chart creó en el despliegue. Tres pestañas:

Bases de datos

Lista las bases existentes (excluyendo las técnicas) y permite crear una nueva indicando su nombre.

Usuarios y permisos

• Crear / reiniciar un usuario: si aún no existe, se crea; si ya existe, se regenera su contraseña. La contraseña generada se muestra solo una vez, justo después de la operación — Postgres nunca la almacena en texto plano, así que no se puede volver a leer después. Anótela o cópiela de inmediato.
• Los roles marcados como Sistema (streaming_replica, cnpg_metrics_exporter, y la cuenta administradora creada por el propio chart) son roles técnicos de la plataforma: no aparecen en el campo Otorgar permisos, y su contraseña no puede reiniciarse desde esta interfaz.
• Hacer clic en un usuario despliega sus permisos actuales, base por base (captura arriba). El nivel mostrado se deduce de los privilegios realmente presentes en las tablas del esquema public — no de un historial de concesiones: Acceso a la base significa que se otorgó CONNECT pero aún no hay ninguna tabla (un ALTER DEFAULT PRIVILEGES pendiente de una tabla futura no deja rastro antes de que exista), y Permisos personalizados significa un conjunto de privilegios que no coincide con ninguno de los tres niveles siguientes (modificados a mano desde la pestaña Ejecutar SQL).
• Otorgar permisos aplica un nivel — Solo lectura, Lectura-escritura o Todos los permisos — a un usuario sobre una base, incluidos los objetos creados posteriormente (ALTER DEFAULT PRIVILEGES).

Ejecutar SQL

Un comando SQL libre contra la base elegida, con resaltado de sintaxis. Un SELECT devuelve una tabla de resultados; cualquier otro comando (DDL/DML) muestra el estado devuelto por Postgres (p. ej. CREATE TABLE, número de filas afectadas).

Warning

Esta pestaña ejecuta cualquier comando SQL, incluidos los destructivos (DROP TABLE, DELETE sin WHERE…). No hay confirmación intermedia: verifique el comando y la base seleccionada antes de ejecutar.

Tip

No hay un botón de eliminación dedicado para una base o un usuario: use la pestaña Ejecutar SQL (DROP DATABASE, o DROP OWNED BY seguido de DROP ROLE para un usuario que recibió permisos). Una base no puede eliminarse estando conectado a ella — seleccione otra base antes de ejecutar el DROP DATABASE.

Acceso externo

Botón Acceso externo de una tarjeta PostgreSQL — visible en cuanto la aplicación está Running, reservado a los usuarios con el rol admin en el namespace.

Por defecto, una base de datos solo es accesible desde el clúster (<nombre-app>-rw.<namespace>.svc.cluster.local). Exponer la base de datos le asigna un puerto TCP en el Gateway compartido, elegido automáticamente dentro de un rango reservado (parámetro de clúster CUSTOM_PORT_AUTO_RANGE, por defecto 30000-35000): no hay que indicar ningún número de puerto, y no puede ocuparse un puerto que ya use la plataforma. El nombre público de la base de datos es <nombre-app>-<namespace>.pg.<dominio> cuando la plataforma dispone de un certificado público para las bases de datos (véase más abajo), y <nombre-app>-<namespace>.<dominio> en caso contrario.

La exposición exige TLS por defecto:

• las conexiones sin cifrar se rechazan en esta base de datos, incluidas las procedentes del propio clúster (regla hostnossl … reject añadida al pg_hba);
• la base de datos sirve un certificado que cubre su nombre público, lo que permite usar sslmode=verify-full;
• la ventana muestra la URI de conexión y la URL JDBC correspondientes.

Certificado de confianza pública (caso normal). Cuando hay un certificado wildcard de Let's Encrypt configurado para las bases de datos (parámetro de clúster POSTGRES_PUBLIC_TLS_SECRET), la base lo sirve en lugar del certificado de CNPG. El cliente verifica el servidor con su propio almacén de certificados: ningún archivo que facilitarle, y la renovación es automática y sin corte. Las URL mostradas lo tienen en cuenta: sslrootcert=system para psql y libpq 16 o posterior (con una versión más antigua, apunte sslrootcert al bundle del sistema, p. ej. /etc/ssl/certs/ca-certificates.crt), sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory en JDBC para usar el truststore de Java.

Sin certificado público configurado, el nombre público se añade al certificado generado por CNPG, firmado por una CA propia de la base. La ventana permite entonces descargar el certificado de la CA — que debe facilitarse al cliente (sslrootcert) para verificar el servidor. CNPG renueva esa CA periódicamente (fecha de caducidad mostrada): habrá que reemplazar entonces el archivo descargado. Para verify-full, la URI hace referencia a ese archivo con su nombre de descarga (sslrootcert=<nombre-app>-ca.crt): colóquelo en el directorio de trabajo del cliente, o adapte la ruta.

Qué cambia «Exigir TLS» para los clientes existentes

La mayoría de los clientes negocian TLS por sí mismos en cuanto el servidor lo ofrece — lo que CNPG hace siempre — y por tanto no notan ninguna diferencia: psql, psycopg y el driver JDBC que incluye DigDash (pgjdbc 42.7, sslmode=prefer por defecto desde 42.2.9). Las conexiones que DigDash crea automáticamente hacia una base de datos del mismo namespace están en ese caso: ya están cifradas y siguen funcionando.

Solo se rechaza un cliente que desactive explícitamente el cifrado (sslmode=disable). Para imponer el cifrado del lado del cliente sin depender de la negociación, utilice ?sslmode=require; en JDBC, no use ssl=true por sí solo, que equivale a verify-full y falla sin certificado de CA.

Warning

Como para cualquier puerto expuesto, el reenvío en el cortafuegos externo no está automatizado: dirija el puerto mostrado al Load Balancer del clúster, cuyas direcciones se recuerdan en la ventana.

Restringir las direcciones de origen

El campo Direcciones IP autorizadas limita las conexiones externas a una lista de direcciones IP o rangos CIDR, uno por línea (203.0.113.7, 198.51.100.0/24, IPv6 aceptado). Se rellena al exponer la base o más tarde, con la base ya expuesta, mediante Guardar. Si se deja vacío, se acepta cualquier dirección que el cortafuegos externo deje pasar.

El filtrado lo aplica el proxy del Gateway compartido, antes de que la conexión llegue a la base de datos: a un origen rechazado se le cierra la conexión sin ningún intercambio con PostgreSQL. Se aplica a la dirección pública del cliente tal como llega al clúster (dirección de salida de una VPN o de un NAT corporativo, por ejemplo).

Note

Un cambio se aplica a las nuevas conexiones; una sesión ya abierta desde una dirección retirada no se corta. Las aplicaciones del clúster (DigDash…) deben usar el acceso interno, que no pasa por este filtrado — mediante el nombre público, aparecerían con la dirección del cortafuegos.

Retirar la exposición elimina el puerto y la ruta. La exigencia de TLS permanece — puede que algunos clientes ya se hayan adaptado a ella — y se modifica desde Configurar, categoría Seguridad.

Los volúmenes de una base de datos PostgreSQL no se redimensionan ni se copian desde la página Volúmenes: consulte Volúmenes.

Copia de seguridad y restauración

Las bases PostgreSQL —ya sea la plantilla PostgreSQL independiente o el PostgreSQL integrado en Digdash BI— pueden respaldarse de forma continua en un almacenamiento S3, y luego restaurarse en una nueva aplicación.

Activar las copias de seguridad

En el formulario de despliegue (sección Copia de seguridad), o más adelante desde Configurar → Ajustes avanzados:

1. Activar copias de seguridad programadas: activa a la vez el archivado continuo de los registros (WAL) y la copia de seguridad base programada — ambas son necesarias para poder restaurar.
2. Política de retención: duración de conservación, por ejemplo 7d, 4w.
3. Ruta S3 (destinationPath): el bucket de destino. Elija Bucket existente para seleccionar un bucket de la plataforma — la ruta s3://… y el endpoint se completan automáticamente.
4. Access Key / Secret Key: las credenciales del bucket (proporcionadas por la página Buckets).

Copia de seguridad inmediata

La planificación predeterminada es diaria. Para generar una primera copia de seguridad sin esperar, hay disponible una opción de copia de seguridad inmediata en los ajustes de copia de seguridad.

Restaurar

La restauración crea una nueva aplicación cuya base arranca desde la copia de seguridad — la aplicación original no se modifica.

1. Nueva app → la misma plantilla que la de origen (PostgreSQL o Digdash BI).
2. En la sección Restauración:
   • active la restauración;
   • Nombre de la app de origen: el nombre exacto de la aplicación cuya copia de seguridad se escribió (tal como aparece en su tarjeta);
   • Ruta S3 de la copia de seguridad a restaurar: el mismo bucket que el de la copia de seguridad;
   • las credenciales S3 del bucket.
3. Despliegue: la nueva aplicación arranca reproduciendo la copia de seguridad y luego pasa a Running.

Warning

Si el origen S3 está vacío, es inaccesible o está corrupto, la nueva aplicación no arrancará (reinicios en bucle). Compruebe el contenido del bucket desde la página Buckets antes de iniciar la restauración.

Restaurar a una fecha precisa

Por defecto, la restauración reproduce la copia de seguridad hasta el punto más reciente disponible (el final del flujo de registros WAL). También es posible restaurar la base tal como estaba exactamente en un instante concreto del pasado — útil, por ejemplo, para deshacer los efectos de una eliminación o de una migración fallida ocurrida después de la última copia de seguridad válida.

Ejemplo: copias de seguridad diarias, restauración al estado de ayer a las 23:59

Una aplicación de origen tiene las copias de seguridad programadas activadas con una planificación diaria (0 0 0 * * *, es decir, medianoche cada día) y una retención de 7 días. Hoy se detecta un error y se desea recuperar la base tal como estaba ayer a las 23:59, justo antes de la copia de seguridad de medianoche:

1. Nueva app → la misma plantilla que la de origen.
2. Sección Restauración: actívela, complete el Nombre de la app de origen y la Ruta S3 de la copia de seguridad a restaurar como en una restauración normal.
3. Restaurar a una fecha precisa (opcional): introduzca 2024-06-24 23:59:00+02 (ajuste la fecha y la zona horaria).
4. Despliegue: CNPG restaura la copia de seguridad y luego reproduce los registros WAL archivados hasta el instante indicado, sin ir más allá.

Tip

La zona horaria forma parte del valor (+02, +00…) — sin ella, la hora se interpreta en la zona horaria del propio servidor PostgreSQL. La continuidad de los registros WAL entre la copia de seguridad y el instante objetivo debe estar intacta: una retención demasiado corta o una copia de seguridad faltante entre ambos impide que la restauración alcance la fecha solicitada.

Instantáneas de volúmenes

Independientemente de las copias de seguridad S3, cualquier volumen persistente puede ser objeto de instantáneas puntuales y clones — véase Volúmenes.

Digdash BI

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.

Copia de seguridad del entorno DigDash

Véanse también las opciones de despliegue de Digdash BI.

Independientemente de la base de datos, la categoría Copia de seguridad del entorno guarda el propio entorno DigDash — usuarios, roles, cuadros de mando, modelos de datos, fuentes de datos y directorio LDAP — con la herramienta oficial backuptools de DigDash, en un bucket S3. Funciona sea cual sea el tipo de base de datos.

Campo	Función
Activar la copia de seguridad del entorno DigDash	Añade al pod un contenedor dedicado a la copia y la restauración, necesario también para guardar y restaurar bajo demanda desde la tarjeta.
Bucket S3	Bucket de destino. Un bucket de este namespace se usa con sus propias credenciales; para otro S3, pase a entrada manual e indique el endpoint y las claves.
Prefijo S3	Carpeta de las copias en el bucket. Vacío = nombre de la aplicación.
Copia a restaurar al arrancar	Lista de las copias del bucket elegido (todas las aplicaciones del namespace). La copia elegida se importa en el primer arranque de una nueva instancia, una sola vez: un reinicio no la vuelve a importar. Permite crear una instancia a partir de la copia de otra.
Copia de seguridad diaria automática (hora UTC)	Una copia al día a la hora indicada (02:00 por defecto). Vacío = sin copia automática, solo bajo demanda desde la tarjeta.
Número de copias conservadas	Las más antiguas se eliminan de S3 tras cada copia (0 = todas).
Incluir el directorio LDAP / Incluir las fuentes de datos	Contenido de las copias y restauraciones.

Con la aplicación en marcha, su tarjeta muestra Copia de seguridad · Entorno DigDash. Por defecto la ventana lista las copias de esta instancia (su prefijo); la casilla Mostrar todas las copias del bucket muestra también las de otras instancias para restaurar una (solo bucket de este namespace). Permite:

• Guardar ahora (rol operador);
• Restaurar una copia en la instancia en servicio, sin reinicio (rol admin). Los elementos guardados sustituyen su versión actual; lo creado después se conserva.

Una sola copia o restauración a la vez; la ventana sigue la operación en curso y muestra su resultado.

Modo depuración (Digdash BI)

La plantilla Digdash BI ofrece un modo depuración reservado al equipo DigDash, para investigar un problema que no pueda investigarse de otra forma: abre un agente de depuración Java remoto (JDWP) en el contenedor principal y expone el puerto del directorio LDAP interno (sidecar OpenDJ). Ambos siguen siendo accesibles únicamente desde el clúster (Service ClusterIP) mientras no se cree una regla dedicada de exposición externa — véase Conectarse más abajo.

Activar

En el formulario de despliegue (pestaña Entornos, al principio de la lista), o después mediante Configurar → Avanzado → pestaña Entornos:

1. Modo depuración (JDWP): activa el flag -agentlib:jdwp=… en el puerto 5005 (depurador Java) y expone el puerto 1389 (directorio LDAP OpenDJ) en el Service de Kubernetes de la aplicación.
2. Aplicar: el pod se reinicia con ambos puertos activos.

Sin autenticación en JDWP

El protocolo de depuración Java (JDWP) no tiene autenticación integrada: cualquiera que alcance el puerto puede ejecutar código arbitrario dentro de la JVM. El puerto LDAP da acceso al directorio interno (cuentas/roles de Digdash). Reservado al equipo DigDash para una investigación puntual — no deje el modo depuración activo de forma continua ni en producción, desactívelo en cuanto termine la sesión.

Conectarse

Ambos puertos (5005 para JDWP, 1389 para LDAP) siguen siendo internos al clúster por defecto. Para acceder a ellos desde un equipo de desarrollo, expóngalos temporalmente mediante Puertos personalizados — véase Namespaces y cuotas → Aislamiento de red:

1. Cree una regla de Puerto personalizado con la app Digdash BI como destino, el puerto interno 5005 (o 1389 para LDAP) y un puerto externo libre a su elección. Para limitar las colisiones con otras reglas del clúster (el puerto externo debe ser único en todo el clúster) y facilitar su localización/limpieza después de la sesión, prefiera un puerto externo en la parte alta del rango 30000-35000 (ya reenviado por el cortafuegos), por ejemplo 34000 o superior: la parte baja de ese rango se asigna automáticamente al acceso externo de las bases PostgreSQL.

   El campo Direcciones IP autorizadas viene rellenado con su dirección actual, tal como la ve la plataforma: consérvela. Como JDWP no tiene autenticación, el puerto solo será accesible desde su puesto (o la salida de su VPN). Añada otras direcciones si un compañero debe conectarse; el icono de filtro de un puerto existente permite modificar la lista sin recrearlo. 2. El reenvío hacia un posible cortafuegos aguas arriba sigue siendo un paso manual de infraestructura, no automatizado desde esta interfaz — véase el recordatorio mostrado al crear la regla.

1. Conecte después su IDE (depurador remoto) o su cliente LDAP en <puerto externo>, en el nombre de dominio del propio Control Panel (ej. controlpanel.mi-cluster.digdash.com:30500) — no una IP: el puerto personalizado se expone en ese mismo Gateway compartido, cuya IP pública no es estable ni está pensada para usarse directamente.

Una vez terminada la sesión

Elimine la regla de Puertos personalizados y desactive el modo depuración (desmarcar + Aplicar): ninguno de los dos debe permanecer activo fuera de una investigación en curso.

Apache Hop GUI: opciones de despliegue

La plantilla Apache Hop (GUI) (categoría Processing) despliega Hop Web, la interfaz de diseño de los pipelines y workflows de Apache Hop. El proyecto Hop procede de un repositorio Git, clonado en el primer arranque y luego actualizado con git pull --ff-only en los siguientes. El trabajo, los favoritos del selector de archivos y el historial de cada usuario se conservan en el volumen data de la aplicación.

General

Campo	Función
Versión Hop	Tag de la imagen ds/hop-web.
Límite de memoria, Límite de CPU	Recursos del contenedor (categoría Capacidad).
File Browser	Gestor de archivos accesorio (subida/descarga), desactivable si no se usa.
Nombre del proyecto Hop	Nombre mostrado del proyecto en Hop Web. Vacío: el nombre del repositorio Git elegido en la creación. La carpeta del proyecto en disco no cambia.

Fuente Git

El proyecto abierto en Hop Web procede de un repositorio Git, elegido en la categoría Fuente Git:

Campo	Función
Fuente del proyecto Git	Ninguna (proyecto vacío), Instancia Forgejo gestionada o Entrada manual.
Instancia Forgejo, Repositorio, Rama	Modo Forgejo: una instancia de la plataforma, un repositorio visible para su cuenta admin, y luego la rama (vacío = rama por defecto del repositorio) — véase Git.
URL del repositorio, Rama, Usuario git, Token / contraseña git	Entrada manual: repositorio externo. Usuario y token solo para un repositorio privado; se guardan en un Secret del namespace y no se vuelven a mostrar.

Acceso

Apache Hop GUI es la única plantilla con concesión directa: desde Acceso, un usuario está autorizado o no, sin perfiles — véase Acceso y permisos.

Conexiones del proyecto

La plataforma escribe en el proyecto Hop los metadatos de conexión del namespace: bases PostgreSQL, servidores Hop y buckets S3. Se regeneran periódicamente, y de inmediato con la acción Resincronizar las conexiones Hop de la tarjeta. Las contraseñas se cifran con una clave AES común a la plataforma, por lo que las instancias Apache Hop Server también pueden descifrarlas.

Véase también

• Apache Hop Server: opciones de despliegue — ejecutar los pipelines diseñados aquí.
• Ejemplo: cadena de tratamiento datawarehouse — repositorio Git, base de datos, pipeline y job planificado, de principio a fin.

Apache Hop Server

Apache Hop Server: opciones de despliegue

La plantilla Apache Hop Server (categoría Processing) despliega un servidor de ejecución de Apache Hop: ejecuta los pipelines y workflows del proyecto Git sincronizado en la instancia, bajo demanda o planificados — véase Jobs y programación.

General

Campo	Función
Versión Hop	Tag de la imagen ds/hop-server.
Límite de memoria, Límite de CPU	Recursos del contenedor (categoría Capacidad): 4Gi y 2000m por defecto.
File Browser	Gestor de archivos accesorio (subida/descarga), activado por defecto.
Nombre del entorno Hop	HOP_ENVIRONMENT_NAME: entorno del proyecto activado al arrancar.

Fuente Git

La fuente del proyecto es obligatoria aquí, y se indica igual que en Apache Hop GUI: instancia Forgejo gestionada (instancia, repositorio, rama) o entrada manual (URL, rama, usuario y token para un repositorio privado).

Campo	Función
Intervalo de sincronización	Frecuencia con la que el sidecar git-sync consulta el repositorio (30s, 1m, 5m…), 60s por defecto.

A diferencia de Hop GUI, el proyecto se sincroniza de forma continua: un commit enviado a la rama seguida se tiene en cuenta en la siguiente sincronización, sin reiniciar la aplicación.

Véase también

• Jobs y programación — cola, lanzamiento de un job, planificación periódica.
• Prueba de compatibilidad de la API, acción de la tarjeta: comprueba que la API del servidor responde, punto de control por punto de control.

Apache Hop Server: jobs y planificación

La tarjeta Apache Hop Server abre, mediante el botón Jobs de Hop, una página dedicada al lanzamiento y seguimiento de los pipelines y workflows del proyecto Hop sincronizado en esta instancia (véase Git para la configuración del origen del proyecto).

Cola de espera

Un panel en la parte superior de la página indica el número de jobs en ejecución y en cola, así como el consumo real de CPU/RAM de la instancia Hop Server. El número máximo de jobs ejecutados en paralelo se ajusta aquí (Máx. en paralelo) — se crea una cola automáticamente (límite de 1) al lanzar el primer job si aún no existe ninguna.

Lanzar un job estándar

Lanzar un job abre una selección entre los pipelines (.hpl) y workflows (.hwf) del repositorio git sincronizado:

Campo	Función
Pipeline / Workflow	Archivo a ejecutar, listado desde el repositorio git de la instancia
Configuración de ejecución	Nombre de una configuración de ejecución existente en los metadatos del proyecto (metadata/pipeline-run-configuration o workflow-run-configuration)
Parámetros de ejecución	Pares clave/valor transmitidos al pipeline/workflow
Nivel de log	De Nothing a Rowlevel — por defecto, el configurado en Hop Server

El job aparece de inmediato en el historial, con su estado (En cola, En ejecución, Completado, Fallido, Cancelado) actualizado en directo. Cada línea permite:

• ver el detalle: vista previa gráfica del pipeline/workflow, estado de cada transform/acción, y logs completos;
• relanzar con los mismos parámetros;
• cancelar (job activo) o eliminar (job finalizado).

Los jobs también se seleccionan en bloque (relanzar / cancelar / eliminar varios a la vez).

Programar un job periódico

La sección Jobs programados recurrentes define ejecuciones automáticas del mismo archivo, según dos modos de planificación:

• Intervalo: cada N minutos/horas/días;
• Cron: expresión clásica (minuto, hora, día del mes, mes, día de la semana).

Cada programación conserva su propio nombre, sus parámetros y su configuración de ejecución — independientes del lanzamiento manual. Una vez creada, puede activarse/desactivarse, modificarse, ejecutarse de inmediato (sin esperar a su próxima ejecución) o eliminarse. La columna Última ejecución permite comprobar que una programación se ejecuta correctamente como estaba previsto.

Note

A diferencia del botón Tareas programadas de la tarjeta de aplicación (véase Aplicaciones) —que gestiona las tareas internas del Control Panel (limpieza, sincronizaciones...)—, esta planificación desencadena jobs Hop reales, ejecutados por la propia instancia Hop Server.

Apache Iceberg (catálogo Polaris)

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla Apache Iceberg (categoría Gobernanza) despliega un catálogo Iceberg REST — Apache Polaris — respaldado por una base PostgreSQL (CloudNativePG) creada con él.

Campo	Función
Bucket S3 del warehouse (pestaña Almacenamiento, obligatorio)	Bucket que contendrá tablas y metadatos. Elegir un bucket del namespace rellena automáticamente endpoint, región y claves de acceso. Fijado en la creación.
Endpoint S3, Región S3 (pestaña Almacenamiento)	Rellenados por el selector de bucket, a escribir a mano para un S3 externo. us-east-1 por defecto para la región. Fijados en la creación.
Access Key ID, Secret Access Key (pestaña Almacenamiento)	Credenciales del bucket, estas sí modificables después — por ejemplo tras una rotación de claves.
Nombre del catálogo Iceberg	lakehouse por defecto: es el warehouse al que se refieren Trino, Spark o PyIceberg. Fijado en la creación.
Realm Polaris	POLARIS por defecto, un realm por instancia. Fijado en la creación.
Límite de memoria, Límite de CPU (pestaña Capacidad)	2Gi y 1000m por defecto.
Tamaño del almacenamiento PostgreSQL (pestaña Capacidad)	5Gi por defecto. Solo se puede ampliar: un volumen no se reduce.

Al desplegar se ejecutan automáticamente dos tareas: la inicialización del realm (credenciales del principal root) y la creación del catálogo en el bucket, con los permisos necesarios. La tarjeta pasa a Running antes de que terminen — cuente uno o dos minutos más antes de que el catálogo sea utilizable.

Credenciales del catálogo

Los motores se autentican ante el catálogo con el principal root, guardado en el secreto <nombre>-root-principal del namespace (claves clientId, clientSecret, catalogUri, catalogName) — véase Secretos. El catálogo no distribuye credenciales S3 temporales (sin STS en el almacenamiento de objetos de la plataforma): cada motor usa sus propias claves del bucket, de ahí los campos S3 repetidos en las plantillas Trino y JupyterHub.

La API REST se expone en https://<nombre>-<namespace>.<dominio>/api/catalog (solo llamadas autenticadas — sin interfaz web).

Eliminación

Eliminar el catálogo Apache Iceberg elimina su base PostgreSQL y sus secretos, pero no los archivos del bucket: las tablas siguen siendo legibles por un nuevo catálogo que apunte a la misma ubicación, o pueden limpiarse desde la página Buckets.

Trino

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla Trino (categoría Procesamiento) despliega un coordinador y workers Trino con un catálogo lakehouse preconectado a la instancia Apache Iceberg elegida.

Trino no es una base de datos: es un motor SQL sin almacenamiento. El trabajo se reparte en tres papeles — el catálogo Apache Iceberg sabe qué tablas existen y qué archivos las componen, el bucket S3 contiene los datos en Parquet, y Trino ejecuta el SQL en memoria, repartido entre sus workers. De ahí el orden de despliegue: primero el catálogo, después Trino, en el mismo namespace y sobre el mismo bucket.

Opciones de despliegue

Campo	Función
Catálogo Apache Iceberg (Polaris) (obligatorio)	Instancia Apache Iceberg del mismo namespace. Fijado en la creación.
Catálogo Iceberg (warehouse)	Nombre del catálogo en Polaris (lakehouse por defecto).
Bucket S3 del warehouse (pestaña Almacenamiento)	El mismo bucket que el del catálogo: selecciónelo para rellenar endpoint, región y claves.
Endpoint S3, Región S3, Access Key ID, Secret Access Key (pestaña Almacenamiento)	Rellenados por el selector de bucket, modificables después — entrada manual para un S3 externo. us-east-1 por defecto para la región.
Número de workers (pestaña Capacidad)	1 por defecto.
Memoria del coordinador, Memoria por worker (pestaña Capacidad)	3Gi cada una por defecto. Mantener ≥ 3 Gi: el heap JVM está fijado en 1400M y el resto es fuera de heap — se ha observado un OOM con 2 Gi bajo carga.

Conectarse

El inicio de sesión usa su cuenta de la plataforma (OpenID Connect), y el acceso se concede desde Acceso a los usuarios o grupos deseados — véase Acceso y permisos. Tres puertas de entrada:

• La interfaz web, https://<nombre>-<namespace>.<dominio>/ui/: una consola de supervisión — consultas en curso y pasadas, estado del clúster. No es un editor SQL, no sirve para escribir consultas;
• Un cliente SQL: trino --server https://… --external-authentication, que abre el navegador para iniciar sesión; o JDBC con externalAuthentication=true, para DBeaver o una herramienta de restitución de terceros;
• Un notebook de JupyterHub del mismo namespace: la variable TRINO_HOST ya está definida (nombre:8080, acceso interno al namespace), suficiente para conectar trino-python-client sin salir del clúster.

Consultar el lakehouse

CREATE SCHEMA lakehouse.ventas;
CREATE TABLE lakehouse.ventas.pedidos AS SELECT 1 AS id, 'test' AS etiqueta;
SELECT * FROM lakehouse.ventas.pedidos;

Los archivos Parquet y los metadatos Iceberg aparecen en el bucket bajo <esquema>/<tabla>-<uuid>/.

Es el mismo catálogo que Spark Connect, PyIceberg y los jobs Spark: una tabla escrita por un tratamiento Spark es legible por Trino acto seguido, y a la inversa. Una sola copia de los datos, varios motores — ese es todo el sentido del lakehouse.

Lo que Trino no hace aquí

• Sin federación de fuentes: hay un solo catálogo configurado, lakehouse, sobre la instancia Apache Iceberg elegida. Los catálogos de demostración del chart original (tpch, tpcds) están retirados, y no se expone en el formulario ningún conector hacia una base de datos aplicativa (PostgreSQL, MySQL…). Consultar una base así desde Trino exigiría añadir un catálogo en los valores del chart.
• Sin transformaciones pesadas y largas: para los tratamientos distribuidos costosos, Spark Connect para lo interactivo y los jobs Spark para el batch.

Primer arranque

Cuente de 3 a 4 minutos antes de la primera consulta, el tiempo de arrancar la JVM y cargar los plugins. La tarjeta pasa a Running antes de que Trino responda.

Eliminación

Eliminar una instancia Trino también retira su cliente OpenID de la plataforma.

JupyterHub

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla JupyterHub (categoría Ciencia de datos) da a cada usuario su propio servidor JupyterLab, con un volumen persistente personal e inicio de sesión mediante la cuenta de la plataforma. Quien despliega la instancia es su administrador (/hub/admin).

Campo	Función
Imagen de los notebooks, Versión de la imagen	Imagen Jupyter de los servidores de usuario (ds/jupyter-datastack por defecto: JupyterLab + clientes Spark Connect, PyIceberg, Trino, MLflow).
CPU máx. por usuario, Memoria máx. por usuario (pestaña Capacidad)	2 núcleos y 4 Gi por defecto, por servidor de usuario.
Almacenamiento por usuario (pestaña Capacidad)	10Gi por defecto. Volumen personal creado en el primer arranque de cada usuario. Fijado en la creación: el redimensionado de los volúmenes de usuario existentes no se hace desde esta interfaz.
Catálogo Apache Iceberg, Trino, Spark Connect, MLflow (pestaña Lakehouse, opcionales)	Instancias del mismo namespace que se preconectan en los notebooks (variables de entorno).
Catálogo Iceberg (warehouse) (pestaña Lakehouse)	Nombre del catálogo en Polaris, lakehouse por defecto (POLARIS_WAREHOUSE).
Bucket S3 (pestaña Almacenamiento, opcional)	Claves S3 expuestas a los notebooks (AWS_*).
Endpoint S3, Región S3, Access Key ID, Secret Access Key (pestaña Almacenamiento)	Rellenados por el selector de bucket, modificables después — entrada manual para un S3 externo.

Variables disponibles en cada notebook cuando el servicio correspondiente está configurado:

Variable	Contenido
POLARIS_URI, POLARIS_WAREHOUSE, POLARIS_CREDENTIAL, POLARIS_SCOPE	Catálogo Iceberg REST y credenciales clientId:clientSecret
TRINO_HOST	Coordinador Trino (nombre:8080, acceso interno al namespace)
SPARK_REMOTE, MLFLOW_TRACKING_URI	Spark Connect y MLflow (si están desplegados)
AWS_ENDPOINT_URL, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY	Acceso S3 al warehouse

Ejemplo con PyIceberg:

import os
from pyiceberg.catalog.rest import RestCatalog

catalog = RestCatalog(
    "lakehouse",
    uri=os.environ["POLARIS_URI"],
    warehouse=os.environ["POLARIS_WAREHOUSE"],
    credential=os.environ["POLARIS_CREDENTIAL"],
    scope=os.environ["POLARIS_SCOPE"],
    **{"s3.endpoint": os.environ["AWS_ENDPOINT_URL"],
       "s3.access-key-id": os.environ["AWS_ACCESS_KEY_ID"],
       "s3.secret-access-key": os.environ["AWS_SECRET_ACCESS_KEY"]},
)
print(catalog.list_namespaces())

Una instancia JupyterHub por namespace

El chart solo admite un JupyterHub por namespace; un segundo despliegue se rechaza con un mensaje explícito. Los servidores de usuario inactivos durante una hora se detienen automáticamente (el volumen personal se conserva).

Eliminación

Eliminar una instancia JupyterHub también retira su cliente OpenID de la plataforma.

Spark Connect

Spark Connect

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla Spark Connect (categoría Procesamiento) despliega un servidor Apache Spark en modo local (ejecutores dentro del pod) expuesto mediante el protocolo Spark Connect: los notebooks y clientes PySpark del namespace comparten una única instalación Spark, ya configurada sobre el catálogo Apache Iceberg elegido. Sin ruta pública (protocolo gRPC interno al namespace).

Campo	Función
Catálogo Apache Iceberg (Polaris) (obligatorio)	Instancia del mismo namespace. Fijado en la creación.
Catálogo Iceberg (warehouse)	Nombre del catálogo en Polaris, lakehouse por defecto.
Versión de Spark	Tag de la imagen ds/spark-connect. Vacío = versión del chart.
Bucket S3 del warehouse (pestaña Almacenamiento)	El mismo bucket que el del catálogo: selecciónelo para rellenar endpoint, región y claves.
Endpoint S3, Región S3, Access Key ID, Secret Access Key (pestaña Almacenamiento)	Rellenados por el selector de bucket, modificables después — entrada manual para un S3 externo.
Núcleos Spark (local[N]) (pestaña Capacidad)	Número de hilos de ejecución en el pod, 2 por defecto; el límite de CPU del pod lo sigue.
Memoria Spark (driver), Límite de memoria del pod (pestaña Capacidad)	2g y 3Gi por defecto: mantenga ~1 Gi de margen entre la memoria Spark y el límite del pod.
Exigir un token de conexión	Token compartido (spark.connect.authenticate.token), guardado en el secreto <nombre>-platform. Desactivado por defecto.

Desde un notebook JupyterHub asociado (SPARK_REMOTE prerrellenado) o cualquier cliente pyspark-client de la misma versión menor que el servidor:

from pyspark.sql import SparkSession
spark = SparkSession.builder.remote(os.environ["SPARK_REMOTE"]).getOrCreate()
spark.sql("CREATE TABLE lakehouse.demo.t (x INT) USING iceberg")
spark.sql("SELECT * FROM lakehouse.demo.t").show()

Eliminación

Eliminar una instancia Spark Connect no afecta a nada más; los jobs Spark que la usan como perfil ya no podrán relanzarse tal cual.

Jobs Spark batch (Spark Operator)

Forma parte del lakehouse (visión general y esquema de interacciones).

Para los tratamientos Spark autónomos o planificados (fuera de una sesión interactiva Spark Connect), la página Jobs Spark de la barra lateral lanza y sigue jobs batch en el namespace actual, mediante el Kubeflow Spark Operator instalado en la plataforma: cada job es un recurso Kubernetes SparkApplication del namespace (o ScheduledSparkApplication para una planificación cron); el operador lanza el driver y luego los ejecutores como pods, y limpia al final. El botón Jobs Spark de una tarjeta Spark Connect abre la misma página, filtrada en esa instancia como perfil.

Lanzar un job

Nuevo job abre el formulario:

Campo	Función
Perfil	Una instancia Spark Connect del namespace: el job reutiliza su imagen Spark (jars Iceberg incluidos), su secreto de registro y la configuración de su catálogo Apache Iceberg / S3 (catálogo por defecto de la sesión). Sin perfil, indique una imagen Spark explícita (y su secreto de registro).
Origen	El archivo principal del job: un script PySpark escrito directamente, un archivo S3 (bucket del namespace + ruta del objeto; endpoint y claves rellenados por el selector de bucket), o un archivo de un repositorio Git Forgejo (instancia, repositorio, rama, ruta — clonado con su token personal, véase Git). Una clase principal (opciones avanzadas) cambia a un job Scala/Java sobre un .jar.
Nombre	Identificador Kubernetes del job (minúsculas, cifras, guiones) — propuesto a partir del archivo.
Dimensionamiento	Núcleos y memoria del driver, número de ejecutores, núcleos y memoria por ejecutor.
Opciones avanzadas	Argumentos, propiedades Spark adicionales (spark.*), retención del recurso tras el fin — en horas, 168 (7 días) por defecto.

El driver se ejecuta con la cuenta de servicio spark del namespace (límites de CPU/memoria en cada contenedor, como exige la cuota del namespace); los orígenes S3 y Git los recupera un initContainer (aws s3 cp / git clone) en un volumen montado en /opt/job, y el script escrito mediante un ConfigMap sparkjob-<nombre>. Las credenciales (catálogo, S3, Git) permanecen en Secretos del namespace, nunca en el formulario anotado en el recurso.

Seguimiento

El historial lista los jobs del namespace con su estado (SUBMITTED, RUNNING, COMPLETED, FAILED…), su origen, su perfil y su duración; se refresca solo mientras un job está activo. Para cada job:

• Detalle y logs: pods driver/ejecutores y últimas líneas del driver, en directo mientras el job se ejecuta;
• Relanzar tal cual: nuevo recurso <nombre>-<sufijo> a partir del formulario original (perfil resuelto de nuevo, es decir imagen y configuración al día); Relanzar con cambios reabre el formulario prerrellenado;
• Cancelar (job activo) detiene driver y ejecutores; Eliminar (job terminado) retira el recurso y sus logs.

Se aplican los roles habituales: lectura para un viewer, lanzamiento/cancelación/eliminación para un operator, planificación para un admin del namespace.

Jobs planificados

Planificar un job reutiliza el formulario de lanzamiento con una expresión cron (5 campos), una zona horaria, una política de concurrencia (prohibir solapamientos, permitir, reemplazar) y el número de runs conservados. Cada planificación puede lanzarse ahora, suspenderse y reactivarse, o eliminarse; sus runs aparecen en el historial con el marcador ⏱ del nombre de la planificación.

Sin la interfaz

Los recursos siguen siendo manipulables con kubectl -n <namespace> get sparkapplications: un job creado a mano aparece en el historial (cancelación/eliminación posibles, pero sin relanzamiento al no existir formulario original). En un clúster sin acceso a Docker Hub, las imágenes de los initContainers se sobrescriben en Parámetros del clúster: SPARK_JOB_GIT_IMAGE (por defecto alpine/git) y SPARK_JOB_S3_IMAGE (por defecto amazon/aws-cli).

Namespaces creados antes del operador

La cuenta de servicio spark se crea con cada namespace y se comprueba en cada lanzamiento; para los namespaces anteriores a la instalación del operador, la instalación también la crea (o python manage.py ensure_spark_rbac en ControlPanel).

MLflow

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla MLflow (categoría Ciencia de datos) despliega un servidor de tracking MLflow: experimentos, runs y registro de modelos en una base PostgreSQL (CloudNativePG) creada con él, artefactos servidos por el servidor en un bucket S3. El acceso web está protegido por el inicio de sesión de la plataforma (el servidor MLflow no tiene autenticación propia): como con Apache Hop, los usuarios y grupos autorizados se gestionan desde Acceso.

Campo	Función
Versión de MLflow	Tag de la imagen ds/mlflow. Vacío = versión del chart.
Bucket S3 de los artefactos, Prefijo en el bucket (pestaña Almacenamiento, bucket obligatorio)	Ubicación de los artefactos, prefijo mlflow por defecto. Fijados en la creación: los runs existentes apuntan ahí.
Endpoint S3, Región S3, Access Key ID, Secret Access Key (pestaña Almacenamiento)	Rellenados por el selector de bucket, modificables después — entrada manual para un S3 externo.
Procesos del servidor	Número de workers del servidor, 2 por defecto.
Límite de memoria, Límite de CPU (pestaña Capacidad)	2Gi y 1000m por defecto.
Tamaño del almacenamiento PostgreSQL (pestaña Capacidad)	5Gi por defecto. Solo se puede ampliar: un volumen no se reduce.

Desde un notebook asociado (MLFLOW_TRACKING_URI prerrellenado, acceso interno sin login): import mlflow; mlflow.set_tracking_uri(os.environ["MLFLOW_TRACKING_URI"]); mlflow.log_metric("accuracy", 0.99). Los artefactos pasan por el servidor: los notebooks no necesitan claves S3.

Eliminación

Eliminar una instancia MLflow también retira su cliente OpenID de la plataforma.

Apache NiFi

Forma parte del lakehouse (visión general y esquema de interacciones).

La plantilla Apache NiFi (categoría Procesamiento) despliega NiFi 2 con inicio de sesión mediante la cuenta de la plataforma: quien despliega la instancia obtiene automáticamente el derecho de modificar el flow (el administrador inicial es una cuenta técnica de la plataforma, invisible en NiFi) y autoriza las demás cuentas desde la interfaz NiFi (menú Users / Policies). El flow y los repositorios (FlowFiles, contenido, procedencia, estado) están en un volumen persistente.

Campo	Función
Versión de NiFi	Tag de la imagen apache/nifi. Vacío = versión del chart.
Número de nodos (pestaña Clúster)	1 por defecto. NiFi funciona siempre en clúster (elección de líder y estado compartido nativamente en Kubernetes, Leases/ConfigMap, sin ZooKeeper), un pod y un volumen por nodo. Modificable en cualquier momento (ver más abajo).
Heap JVM, Límite de memoria, Límite de CPU (pestaña Capacidad)	2g, 3Gi y 2 núcleos por defecto; mantenga ~1 Gi de margen entre el heap y el límite de memoria.
Tamaño del volumen (repositorios y flow) (pestaña Capacidad)	20Gi por defecto, por nodo. Fijado en la creación: el redimensionado de un volumen existente no se hace desde esta interfaz.
Catálogo Apache Iceberg (Polaris) (pestaña Lakehouse, opcional)	Define POLARIS_URI, POLARIS_CREDENTIAL y las variables S3_* en el pod, a referenciar uno mismo en un flow: NiFi no tiene procesador Iceberg nativo, no se conecta nada automáticamente.

Cambiar el número de nodos

Desde la ventana de configuración de la aplicación (campo Número de nodos, o Réplicas):

• Añadir nodos: los nodos existentes siguen funcionando; cada nodo nuevo se une al clúster y recibe su flow.
• Retirar nodos: los nodos de número más alto se detienen y el Control Panel los retira del clúster NiFi (si no, NiFi rechazaría cualquier cambio del flow mientras un nodo siga «desconectado»). Un nodo retirado conserva su volumen: los datos aún en cola en ese nodo vuelven si se añade de nuevo.
• Apagar / Iniciar: detiene todos los nodos y los reinicia con el mismo número.

Tras un cambio del número de nodos o un reinicio, NiFi puede pedir que se vuelva a iniciar sesión: cada nodo firma sus propias sesiones, por lo que una sesión abierta en otro nodo deja de reconocerse. El flow y los datos no se ven afectados. Justo después de un inicio, la interfaz también puede mostrar un error mientras los nodos forman el clúster (normalmente menos de un minuto): actualice la página.

Aplicaciones NiFi creadas antes de la versión 2.8.70

Una aplicación de nodo único anterior se migra automáticamente en su primera actualización (cambio de configuración o reinicio): se detiene, su volumen se clona con el nombre que espera el nuevo modo y se reinicia con su flow y sus datos. El volumen antiguo se elimina después.

TLS de extremo a extremo

NiFi 2 solo escucha en HTTPS: se genera un certificado interno al desplegar, verificado por la pasarela de la plataforma. El primer arranque tarda de 1 a 3 minutos (carga de extensiones).

Eliminación

Eliminar una instancia Apache NiFi también retira su cliente OpenID de la plataforma.

Nginx: sitio estático

La plantilla Nginx (categoría DevOps) sirve un sitio estático desde un volumen persistente, detrás de una ruta HTTPS de la plataforma.

Campo	Función
Versión de la imagen nginx	Tag de la imagen oficial, stable-alpine por defecto.
Límite de memoria, Límite de CPU	Recursos del contenedor: 128Mi y 200m por defecto.
Tamaño del almacenamiento, Adjuntar un volumen existente (pestaña Capacidad)	Volumen con los archivos del sitio. Fijados en la creación: el redimensionado o el cambio de volumen después se hace desde la pestaña Volúmenes.
File Browser, Usuario admin de File Browser, Contraseña admin de File Browser	Gestor de archivos web para subir el contenido del sitio al volumen, y las credenciales para conectarse. Desactivado por defecto.

Servidor SFTP

La plantilla SFTP (categoría Storage) despliega un servidor SFTP (SFTPGo) con su propio volumen persistente. Sirve para recibir archivos de socios, clientes o scripts, o ponerlos a su disposición, desde la red interna o desde Internet.

Campo	Función
Tamaño del almacenamiento (pestaña Capacidad)	Volumen de los archivos depositados y de la base de cuentas, 10Gi por defecto.
Adjuntar un volumen existente (pestaña Capacidad)	Reutiliza el volumen de un servidor SFTP eliminado: se recuperan archivos y cuentas.
Límite de memoria, Límite de CPU (pestaña Capacidad)	256Mi y 500m por defecto.
Desconexión tras inactividad	En minutos, 15 por defecto (0 = nunca).
Conexiones simultáneas máx. por IP	20 por defecto (0 = ilimitado).
Protección contra fuerza bruta	Bloquea temporalmente una dirección IP que acumula intentos fallidos. Activada por defecto.
File Browser	Consulta de los archivos depositados desde el navegador, tras el inicio de sesión de la plataforma. Activado por defecto.

Una vez iniciada la aplicación, el botón SFTP — Cuentas y acceso de su tarjeta abre la administración del servidor.

Cuentas SFTP

Las cuentas SFTP son propias del servidor: no son usuarios de la plataforma y no tienen acceso al Control Panel. Los roles de la plataforma solo deciden quién puede gestionarlas:

Rol en el namespace o la aplicación	Derechos
viewer	Ver las cuentas, las carpetas compartidas y los datos de conexión.
operator	Crear, modificar, suspender y eliminar cuentas; cambiar sus contraseñas; gestionar las carpetas compartidas.
admin	Abrir o cerrar el acceso desde Internet, filtrar las direcciones IP autorizadas.

Cada creación, modificación o eliminación queda registrada en los logs de auditoría, con el usuario de la plataforma que la realizó — nunca las contraseñas.

Una cuenta incluye:

• un nombre de usuario (de 2 a 32 caracteres: minúsculas, dígitos, ., _, -), que no se puede cambiar;
• un modo de autenticación:
  • Solo clave SSH (por defecto, recomendado desde Internet);
  • Solo contraseña, para clientes que no pueden usar una clave;
  • Clave SSH o contraseña;
  • Clave SSH y contraseña, ambas exigidas en cada conexión;
• sus claves públicas SSH (varias posibles, con una etiqueta);
• una carpeta personal, raíz de lo que ve la cuenta;
• las carpetas compartidas que se le asignan, cada una en solo lectura o en lectura y escritura;
• restricciones opcionales: solo lectura, cuota (tamaño, número de archivos), fecha de caducidad, cuenta suspendida.

Eliminar una cuenta no elimina sus archivos: permanecen en el volumen, visibles en el File Browser.

Contraseñas

Una contraseña generada por la plataforma se muestra una sola vez, justo después de guardar: cópiela antes de cerrar el mensaje. Solo se guarda en forma de hash y no se puede volver a leer; si se pierde, use Nueva contraseña en la fila de la cuenta. Una contraseña escrita debe tener al menos 12 caracteres.

Claves SSH

El usuario genera su par de claves en su equipo y solo envía la clave pública — la clave privada nunca debe salir de su equipo:

ssh-keygen -t ed25519 -C "socio-x"
# enviar el contenido de ~/.ssh/id_ed25519.pub

En Windows, ssh-keygen viene con OpenSSH (PowerShell); con PuTTYgen, copie la línea «Public key for pasting into OpenSSH authorized_keys file».

En la ficha de la cuenta, pegue la clave o cargue el archivo .pub y pulse Añadir. Tipos aceptados: ssh-ed25519, ecdsa-sha2-nistp256/384/521, ssh-rsa (mínimo 2048 bits) y las claves de hardware sk-*. Una clave privada pegada por error se rechaza. La huella SHA256:… mostrada es la que da ssh-keygen -lf id_ed25519.pub: el usuario puede comprobar que es su clave.

Para sustituir una clave sin interrupción, añada la nueva, deje que el usuario la pruebe y luego quite la antigua.

Carpetas compartidas

Una carpeta compartida aparece en /partage/<nombre> en cada cuenta a la que se asigna. El acceso se ajusta cuenta por cuenta: un socio puede depositar archivos mientras otra cuenta solo lee. Eliminar una carpeta compartida la retira de todas las cuentas; sus archivos permanecen en el volumen.

Conexión y acceso desde Internet

La pestaña Conexión indica el host, el puerto, un comando sftp listo para copiar y las huellas del servidor. Compártalas con los usuarios: su cliente las muestra en la primera conexión, para comprobar que se trata de este servidor.

Por defecto, el servidor solo es accesible desde el clúster. Abrir el acceso desde Internet (admin) le asigna un puerto TCP en la Gateway, elegido automáticamente. Las direcciones IP autorizadas (una IP o rango CIDR por línea) restringen los orígenes; vacío, se acepta cualquier dirección que deje pasar el cortafuegos externo. Como para las bases PostgreSQL, la redirección del cortafuegos externo hacia el Load Balancer del clúster se configura a mano.

sftp -P <puerto> <usuario>@<host>
sftp -i ~/.ssh/id_ed25519 -P <puerto> <usuario>@<host>

Archivos y File Browser

En el volumen, los archivos se guardan en files/home/<usuario>/ (carpetas personales) y files/shared/<nombre>/ (carpetas compartidas). El File Browser de la aplicación muestra el conjunto a quien tenga acceso a la aplicación en la plataforma; la base de cuentas no aparece en él.

Eliminación

Eliminar la aplicación cierra el acceso desde Internet, libera su puerto y retira su cliente OpenID. El volumen sigue la regla habitual de los volúmenes.

Helm genérico: cualquier chart Helm

La plantilla Helm genérico despliega cualquier chart Helm, con sus propios values, para probar un software antes de que tenga una plantilla dedicada. Solo aparece en el catálogo si el ajuste de clúster GENERIC_HELM_ENABLED vale true, y está reservada a los administradores del namespace.

A diferencia de las demás plantillas, no configura ni ruta HTTPS, ni certificado, ni autenticación: el chart se instala tal cual.

Desplegar un chart

Campo	Función
Referencia del chart	Nombre del chart en su repositorio (nginx), o referencia OCI completa (oci://registro/ruta/chart).
URL del repositorio Helm	Repositorio clásico del chart (https://charts.ejemplo.com). Se ignora para una referencia oci://.
Versión del chart	Versión que se instala; la más reciente si está vacío.
Values Helm (YAML)	Values pasados al chart, en un editor YAML.

Una vez introducida la referencia (y, si procede, la versión), Cargar los values por defecto del chart rellena el editor con el values.yaml del chart, comentarios incluidos: basta con modificar lo necesario. Si ya hay values introducidos, el Control Panel pregunta antes de sustituirlos. Ver el README muestra la documentación del chart.

Si el chart incluye un esquema de values (values.schema.json, indicado por Esquema de values incluido), Helm comprueba los values al desplegar y rechaza los que no lo cumplen, con el mensaje de error del chart.

Actualizar la release

En la tarjeta de la aplicación, Versión, values e historial abre la release Helm.

La pestaña Versión y values muestra la versión del chart y los values desplegados actualmente. Las etiquetas y anotaciones que el Control Panel pone para seguir la aplicación no aparecen: se vuelven a añadir automáticamente en cada actualización.

• Comprobar envía la actualización a Helm sin aplicar nada (helm upgrade --dry-run): esquema de values, renderizado de los manifiestos, existencia de la versión.
• Actualizar aplica la nueva versión del chart y los nuevos values.
• Values por defecto de esta versión y README muestran, junto al editor, los de la versión introducida, para comparar antes de un cambio de versión.

Aplicación desplegada antes de esta funcionalidad

El origen del chart (referencia y repositorio) no se registraba. La pestaña lo pide una vez; se conserva tras la primera actualización.

Historial y vuelta atrás

La pestaña Historial lista las revisiones de la release, de la más reciente a la más antigua: estado, chart y versión, versión de la aplicación, fecha y descripción Helm. Values muestra los de una revisión.

Volver a esta revisión (tras confirmación) restablece la versión del chart y los values de esa revisión (helm rollback). La vuelta crea una nueva revisión: el historial se conserva y se puede volver hacia delante de la misma forma.

Lakehouse: visión general

Seis plantillas del catálogo forman juntas un lakehouse sobre los buckets S3 de la plataforma: un catálogo de tablas Apache Iceberg (implementado por Apache Polaris), el motor SQL distribuido Trino, notebooks JupyterHub, un servidor Spark Connect, un servidor de tracking MLflow y Apache NiFi para la ingesta. El catálogo se despliega primero, el resto en el orden deseado, en el mismo namespace.

flowchart LR
    B[(Bucket S3<br/>warehouse)]
    P[Apache Iceberg<br/>catálogo Polaris]
    T[Trino]
    J[JupyterHub]
    S[Spark Connect]
    M[MLflow]
    N[Apache NiFi]
    T -- metadatos --> P
    J -- metadatos --> P
    P -- archivos de metadatos --> B
    T -- datos Parquet --> B
    J -- datos --> B
    J -- Spark Connect --> S
    S -- metadatos --> P
    S -- datos --> B
    J -- runs --> M
    M -- artefactos --> B
    N -- ingesta --> B

Aplicaciones

• Apache Iceberg (catálogo Polaris) — catálogo de tablas Iceberg REST (Apache Polaris), a desplegar primero
• Trino — motor SQL distribuido
• JupyterHub — notebooks JupyterLab por usuario
• Spark Connect — servidor Spark compartido para los notebooks y clientes PySpark
• MLflow — tracking de experimentos y registro de modelos
• Apache NiFi — ingesta de datos
• Jobs Spark batch (Spark Operator) — procesamientos Spark batch y planificados (página Jobs Spark)

Ejemplo: cadena de tratamiento datawarehouse

Este ejemplo presenta el flujo de trabajo estándar para construir una cadena de tratamiento de datos de extremo a extremo en la plataforma: un repositorio Git para versionar el proyecto Apache Hop, una base PostgreSQL como destino, Apache Hop GUI para diseñar el pipeline, un Apache Hop Server para ejecutarlo, y una planificación recurrente para automatizarlo.

Visión general

1. Crear un repositorio Git.
2. Crear una base de datos.
3. Lanzar Apache Hop GUI, con el repositorio como parámetro.
4. Crear un pipeline en Hop GUI.
5. Lanzar un Apache Hop Server sobre el mismo repositorio y la misma rama.
6. Crear un job recurrente sobre ese pipeline.
7. Supervisar el resultado.

1. Crear un repositorio Git

Desde la página Git, sección Mi cuenta Git, Crear un repositorio — personal o en una organización. Este repositorio versionará el proyecto Apache Hop (pipelines .hpl, workflows .hwf, conexiones y metadatos).

2. Crear una base de datos

Desde el catálogo (Nueva app), despliegue la plantilla PostgreSQL — véase Desplegar una aplicación. Es la base de datos destino en la que el pipeline escribirá los datos. Anote el nombre de la aplicación: identifica la conexión PostgreSQL expuesta automáticamente a Apache Hop (véase el siguiente paso).

3. Lanzar Hop GUI con el repositorio como parámetro

Despliegue la plantilla Apache Hop (GUI). En la sección Origen Git del formulario:

• Instancia Forgejo: la instancia gestionada por la plataforma;
• Repositorio: el repositorio creado en el paso 1;
• Rama: déjelo vacío para la rama predeterminada.

Una vez que la aplicación esté en Running, ábrala (Abrir): el proyecto Hop se sincroniza con este repositorio/rama, y las conexiones hacia las bases PostgreSQL, servidores Hop y buckets S3 del namespace se aprovisionan automáticamente en los metadatos del proyecto.

Tip

Si la base creada en el paso 2 no aparece de inmediato como conexión en Hop, use Resincronizar conexiones Hop en la tarjeta de la aplicación (véase Aplicaciones) en lugar de esperar la sincronización periódica.

4. Crear un pipeline

En Hop GUI, cree un nuevo pipeline (.hpl) usando como destino la conexión PostgreSQL aprovisionada en el paso anterior, y luego confírmelo (commit) en el repositorio (Hop GUI incluye un cliente Git integrado). Este archivo es lo que el Hop Server ejecutará en los siguientes pasos.

5. Lanzar un Hop Server sobre el mismo repositorio/rama

Despliegue la plantilla Apache Hop Server, con la misma configuración de origen Git que en el paso 3 (misma instancia Forgejo, mismo repositorio, misma rama) — el Hop Server debe ver exactamente el mismo proyecto, pipeline incluido, que el usado en Hop GUI.

6. Crear un job recurrente sobre el pipeline

Abra Jobs Hop desde la tarjeta del Hop Server, y luego, en Jobs recurrentes planificados, cree una planificación que apunte al pipeline creado en el paso 4 (intervalo o expresión cron) — véase Apache Hop Server: jobs y programación para el detalle de los campos.

7. Supervisar el resultado

Desde la misma página Jobs Hop:

• la columna Última ejecución de la planificación confirma que se dispara como se esperaba;
• el historial enumera cada ejecución con su estado (Completado, Fallido…) — haga clic en una fila para ver el detalle gráfico del pipeline y los logs completos;
• el panel superior de la página ofrece una vista instantánea de los jobs en curso/en espera y de la carga de la instancia.

Almacenamiento

Volúmenes

La página Volúmenes muestra los volúmenes persistentes (PVC) del namespace actual: nombre, capacidad, espacio usado, clase de almacenamiento, estado, y los pods que los utilizan.

La columna Usado (indicador + porcentaje) proviene de la supervisión de la plataforma (Prometheus, métricas del kubelet): solo se rellena para un volumen montado por un pod; en caso contrario, o si la supervisión no está disponible, muestra n/d.

Acciones sobre un volumen

El menú ⋮ a la derecha de cada fila agrupa todas las acciones disponibles para ese volumen:

Acción	Efecto
Redimensionar	Aumenta la capacidad (nunca se puede reducir — limitación de Kubernetes)
Instantánea	Congela una instantánea del volumen en un momento dado
Clonar	Crea un nuevo volumen, copia independiente del original
Restaurar una instantánea	Crea un nuevo volumen a partir de una instantánea existente
Eliminar	Elimina el volumen — no es posible si sigue conectado a un pod

Volúmenes de las bases de datos PostgreSQL

Los volúmenes de una base de datos PostgreSQL (aplicación PostgreSQL o base de datos integrada en otra aplicación) los gestiona el operador CloudNativePG: Redimensionar, Clonar e Instantánea aparecen atenuados y la API los rechaza incluso si se evita la interfaz.

• Ampliar la base de datos: hágalo desde Configurar → Tamaño del almacenamiento de la aplicación. El operador amplía por sí mismo los volúmenes de sus instancias; un redimensionamiento hecho directamente aquí sería revertido por el operador. Reducir sigue siendo imposible.
• Copiar la base de datos: utilice sus copias de seguridad. Una instantánea o un clon tomado sobre una base de datos en funcionamiento no garantiza la coherencia.

Caso de uso: volver atrás tras una manipulación errónea

1. Antes de la operación arriesgada, haga una instantánea del volumen en cuestión.
2. Si surge un problema, restaure la instantánea en un nuevo volumen.
3. En Configurar → Volúmenes de la aplicación, apunte el montaje a este nuevo volumen — la aplicación se reinicia con los datos restaurados.

Note

Las instantáneas viven en el clúster (no en S3): protegen contra errores de manipulación, no contra la pérdida del clúster. Para una copia de seguridad realmente externalizada de las bases de datos, véase Copia de seguridad y restauración.

Buckets S3

La página Buckets gestiona el almacenamiento de objetos S3 del namespace (servido por el propio clúster): repositorios de archivos, destinos de copias de seguridad, fuentes de datos para Apache Hop…

Tamaño y compresión

Cada bucket muestra su tamaño (suma de los tamaños de sus objetos), el tamaño realmente almacenado en Ceph tras la compresión, el ahorro de compresión cuando lo hay y su número de objetos. Estos valores proceden de la API de administración del almacenamiento de objetos (RGW) y se actualizan como máximo cada minuto; no aparecen si esa API no es accesible. Sin compresión activada en Ceph, tamaño y tamaño almacenado son idénticos.

Crear un bucket

Nuevo bucket → un nombre corto (letras minúsculas y dígitos). El bucket pasa por una fase de aprovisionamiento y luego se convierte en Bound — a partir de ahí es utilizable.

Credenciales de acceso

Cada bucket expone sus credenciales S3 (endpoint, access key, secret key) desde su fila en la lista. Estos son los valores que esperan:

• la sección Copia de seguridad de PostgreSQL y Digdash BI;
• cualquier cliente S3 externo (rclone, AWS CLI, DBeaver…).

Claves de acceso por aplicación

La pestaña Claves de acceso permite crear identidades S3 adicionales de alcance reducido (solo lectura o lectura/escritura) para confiar a una aplicación, en lugar de compartir las credenciales principales del bucket.

Explorar los objetos

El contenido de un bucket (archivos y carpetas) se consulta directamente desde la página — útil para comprobar que una copia de seguridad se ha escrito correctamente antes de iniciar una restauración.

Nueva carpeta crea una carpeta en la ubicación mostrada. Como S3 no tiene carpetas reales (una carpeta solo existe si contiene un objeto), el Control Panel deposita en ella un archivo de texto vacío .keep; la carpeta sigue visible mientras contenga este archivo u otro objeto.

Acceso y permisos

Coexisten dos conceptos distintos:

• Acceso a apps — quién puede usar una aplicación desplegada (conectarse a Digdash BI, a Hop…);
• Permisos internos — quién puede administrar qué en el propio Control Panel.

Acceso a apps

La página Acceso a apps (o el botón Gestionar acceso de una tarjeta, no disponible para PostgreSQL) muestra, para cada aplicación con autenticación OIDC, todos los usuarios de la plataforma repartidos en dos secciones, Con acceso / Sin acceso, con búsqueda y selección múltiple para actuar sobre varios usuarios a la vez.

Dos mecanismos según la plantilla, mostrados automáticamente por la página:

• Perfiles (la mayoría de las plantillas, p. ej. Digdash BI): conceder el acceso consiste en asignar uno o varios perfiles (roles de la aplicación) al usuario — un usuario sin perfil no tiene acceso. El botón Añadir perfiles abre la selección, individualmente o en bloque sobre la selección actual.
• Conceder / revocar directo (solo Apache Hop GUI): una simple concesión binaria, sin noción de perfil — botones Conceder / Revocar, también disponibles en bloque.

Permisos internos

Los roles del Control Panel se otorgan por namespace (el usuario actúa sobre todo el namespace, desde la pestaña Namespaces) o por aplicación (alcance limitado a una sola aplicación, desde esta página). La página Permisos internos reutiliza la misma interfaz que Acceso a apps (búsqueda, secciones Con/Sin permiso, selección múltiple para las acciones en bloque), pero solo muestra y modifica los permisos definidos directamente en la aplicación: los roles heredados del namespace no aparecen aquí — un recordatorio que la propia pantalla muestra, junto con la tabla de derechos siguiente. Aparecen todas las aplicaciones del namespace, incluidas las que no tienen conexión Keycloak (PostgreSQL, Apache Iceberg, Nginx, Spark Connect…), ausentes de la página Acceso a apps por no haber ningún acceso que otorgar.

Rol	Lo que permite
viewer	Ver las aplicaciones, volúmenes y buckets del ámbito
operator	+ iniciar/detener/reiniciar, configurar, resincronizar
admin	+ desplegar y eliminar, gestionar el acceso y los permisos del ámbito

A esto se suma el estado de administrador de plataforma, transversal: gestión de usuarios, grupos, namespaces y cuotas, de los ajustes del clúster, de la instancia Git y de la autenticación por relé.

Derecho de creación de namespaces

Crear un namespace ya no requiere ser administrador de plataforma. El derecho Creación de namespaces puede concederse:

• a un usuario, en su ficha (Usuarios → Modificar el usuario), al crearlo, o mediante la columna creation_namespaces de la importación masiva;
• a un grupo: todos sus miembros lo reciben mientras formen parte de él.

Quien crea un namespace pasa a ser su administrador (admin), solo de ese. El derecho no da nada más: ni eliminar un namespace, que sigue reservado al administrador de plataforma, ni gestionar grupos o ajustes del clúster. Como cualquier administrador de namespace, puede crear cuentas de usuario, pero no modificarlas ni eliminarlas. Solo un administrador de plataforma puede concederlo.

En la lista de Usuarios, una etiqueta señala a quienes tienen el derecho; al pasar el ratón, indica si proviene de un grupo. Un administrador de plataforma lo tiene de oficio.

Grupos

Reservado a los administradores de plataforma.

Un grupo es un conjunto de usuarios. Todo lo que se concede al grupo se aplica a cada uno de sus miembros mientras sean miembros: salir del grupo retira lo que el grupo aportaba, y solo eso.

Lo que puede llevar un grupo

Elemento	Lo que reciben los miembros	Aplicación
Acceso a una aplicación (y sus perfiles, para Digdash BI y NiFi)	El derecho a iniciar sesión en la aplicación, con esos perfiles	Enviado a Keycloak
Rol en un namespace	viewer, operator o admin en todo el namespace	Inmediata
Rol en una aplicación	Un rol limitado a esa aplicación	Inmediata
Creación de namespaces	El derecho a crear namespaces	Inmediata

Los roles y el derecho de creación se calculan en cada acción: un cambio es efectivo al instante. El acceso a las aplicaciones, en cambio, debe inscribirse en Keycloak (véase Cuándo se aplican los cambios).

Cómo se combinan los derechos

Un usuario puede recibir derechos de varias fuentes: directamente y mediante uno o varios grupos. Nada se sobrescribe:

• Roles: prevalece el más alto. Un rol asignado a una aplicación prevalece sobre el rol del namespace que la contiene.
• Accesos y perfiles: se suman. Un miembro de dos grupos recibe la unión de sus perfiles, más los que tiene asignados directamente. Un acceso se mantiene mientras al menos una fuente lo justifique: retirar a alguien de un grupo no le quita un acceso que también tiene directamente o por otro grupo.

Cuándo se aplican los cambios

• Añadir o retirar un miembro: sus accesos se actualizan de inmediato.
• Asociar o disociar una aplicación, cambiar sus perfiles, eliminar el grupo: el cambio se registra al instante y después se aplica a todos los miembros mediante una tarea en segundo plano, cuyo progreso se muestra en la página. En un grupo de varios miles de miembros tarda unos minutos. Tras un fallo parcial, el botón Resincronizar vuelve a enviar el acceso y los perfiles a todos los miembros.
• Reconciliación periódica: la tarea de sistema de reconciliación restablece en Keycloak los accesos que los grupos justifican pero que faltarían. Nunca retira nada: varios Control Panel pueden compartir el mismo Keycloak, y un acceso sin justificación aquí puede tenerla en otro lugar.

Accesos a aplicaciones y perfiles

Solo se proponen las aplicaciones iniciadas: no se podría aplicar nada a una aplicación detenida. Para Digdash BI y Apache NiFi, el botón Perfiles de una aplicación asociada permite elegir los perfiles que el grupo confiere; las demás aplicaciones conservan un acceso simple.

Lo que viene de un grupo aparece en gris

En la página Acceso a apps, los perfiles heredados de un grupo se muestran en gris, con el nombre del grupo al pasar el ratón, y una etiqueta «vía grupo» señala a los usuarios afectados. En Modificar los perfiles, aparecen marcados pero no se pueden desmarcar: quitarlos ahí no tendría efecto, el grupo los volvería a otorgar. Del mismo modo, Revocar está desactivado para un usuario cuyo acceso solo proviene de un grupo. Estos accesos se retiran desde la página Grupos.

Nombres de grupo

Un nombre de grupo es único sin distinguir mayúsculas: «Negocio» y «negocio» son el mismo grupo. La importación masiva vincula por tanto a un usuario con el grupo existente sea cual sea la capitalización, y solo crea un grupo si realmente no existe.

Note

Los permisos del Control Panel son independientes de los roles internos de cada aplicación: otorgar operator en un namespace no concede, por ejemplo, derechos de administración dentro de la propia Digdash BI.

Usuarios

Reservado a los administradores de plataforma. Un administrador de namespace también accede a ella para consultar la lista, crear o importar cuentas: sin poder hacerlas administradoras de plataforma ni darles el derecho de crear namespaces, y sin modificar ni eliminar una cuenta existente.

La página Usuarios gestiona las cuentas de la plataforma (creadas en Keycloak, el proveedor de identidad corporativo).

Crear un usuario

Nuevo usuario → identificador, correo electrónico, nombre, contraseña inicial (temporal por defecto: el usuario deberá cambiarla en su primer inicio de sesión), idioma de la interfaz, y opcionalmente el estado de administrador de plataforma.

Al crearse, la cuenta Git personal del usuario se aprovisiona automáticamente en la instancia Forgejo de la plataforma (véase Git) — por lo que puede añadirse de inmediato como colaborador de un repositorio, sin esperar a su primer inicio de sesión.

Importar varios usuarios

Importar crea un lote de cuentas de una vez, a partir de un archivo CSV o de un texto escrito directamente — un usuario por línea. El archivo lo lee el navegador y se vuelca en el área de texto: usted ve, y puede corregir, lo que va a crear antes de confirmar.

El botón Descargar un ejemplo proporciona una plantilla lista para rellenar.

Columnas reconocidas, en este orden si el archivo no tiene línea de encabezado:

Columna	Contenido	Obligatoria
identificador	Identificador de acceso	sí
email	Dirección de correo	no
nombre, apellido	Nombre de la persona	no
idioma	fr, en o es	no
admin	sí/no — administrador de plataforma	no
activo	sí/no — cuenta activada	no
derechos	namespace:rol, separados por comas (contabilidad:admin,rrhh:viewer)	no
grupos	Nombres de grupos separados por comas	no
creation_namespaces	sí/no — derecho a crear namespaces, reservado al administrador de plataforma	no

Un grupo citado pero inexistente se crea automáticamente y se señala como tal en el informe — conviene leerlo: una errata en esta columna crea un grupo en lugar de unirse a uno.

El separador (;, tabulación, , o |) se detecta automáticamente. Con una línea de encabezado, el orden de las columnas es libre y puede indicar solo algunas. Las líneas vacías y las que empiezan por # se ignoran.

Cuentas ya existentes

Un identificador que ya existe no se vuelve a crear ni se modifica: contraseña, correo, nombre, idioma, estado activo y estado de administrador se mantienen. La línea solo sirve para completar sus accesos:

• se une a los grupos indicados (creados si no existen);
• los derechos de namespace se añaden, o se elevan si el rol pedido es superior — nunca se rebajan;
• el derecho de creación de namespaces se concede si se pide — nunca se retira.

La línea aparece entonces con el estado Actualizada. Reimportar un archivo para añadir personas a un grupo es, por tanto, seguro: nunca se retira un acceso.

Contraseña

Una única elección se aplica a toda la importación:

• Generada automáticamente: una contraseña aleatoria por cuenta, que deberá cambiarse en el primer inicio de sesión. Se muestra en el informe — como la plataforma no envía correos, le corresponde a usted transmitirla.
• Sin definir: ninguna credencial de acceso. Para cuentas que iniciarán sesión mediante un proveedor de identidad externo.

Informe

Cada línea del archivo tiene su propio estado, incluidas las que nunca se intentaron — sintaxis inválida, identificador repetido en el archivo, autorización denegada. El recuento distingue las cuentas creadas, las existentes actualizadas y los errores. El informe puede descargarse en CSV, y las contraseñas generadas copiarse con un clic.

Warning

Las contraseñas solo se muestran una vez. Cópielas o descargue el informe antes de cerrar la ventana.

Note

Una línea cuyas autorizaciones no pasen se rechaza sin crear nada: nunca una cuenta a medio aprovisionar. Asignar un grupo o crear un administrador requiere ser administrador de plataforma; conceder un derecho requiere ser administrador del namespace de destino.

Modificar / deshabilitar / eliminar

Desde la fila de cada usuario: edición de los campos, cambio de contraseña, habilitación/deshabilitación de la cuenta, eliminación (que también retira su cuenta Git personal).

Acciones en bloque

Al seleccionar varios usuarios:

• Habilitar / Deshabilitar las cuentas seleccionadas;
• Cambiar el idioma de todas las cuentas seleccionadas;
• Eliminar en bloque.

El resultado detalla los éxitos y los fallos usuario por usuario.

Note

El idioma definido aquí determina el idioma de los mensajes que la plataforma devuelve a este usuario. Cada usuario también puede modificarlo por sí mismo desde Mi perfil.

Git

La plataforma aloja un servidor Git interno (Forgejo), utilizado en particular como origen de proyectos para Apache Hop. Dos puntos de entrada:

• Git (parte inferior de la barra lateral): su cuenta Git personal — accesible para todos;
• Ajustes → Git: la administración de la propia instancia Forgejo — solo administradores de plataforma.

Mi cuenta Git

En la primera visita, su identidad Forgejo se aprovisiona automáticamente. La página muestra:

• el enlace a su perfil de Forgejo;
• su token de acceso personal: muéstrelo para usarlo en un git clone https://usuario:token@… o en un gestor de credenciales. Regenerar mi clave crea uno nuevo si el anterior se ha perdido o se ha visto comprometido;
• sus organizaciones y sus repositorios.

Repositorios y organizaciones

• Crear una organización: un espacio para agrupar repositorios, del que usted pasa a ser propietario.
• Crear un repositorio: personal o dentro de una de sus organizaciones, privado por defecto, inicializado con una rama principal — utilizable de inmediato como origen Git de una aplicación, en particular Apache Hop.
• Colaboradores (en un repositorio): añada un usuario de la plataforma con un nivel read, write o admin — el autocompletado busca por nombre o identificador.
• Miembros (en una organización): añada miembros, que obtienen todos los derechos sobre los repositorios de la organización.
• Eliminar un repositorio: posible solo si usted lo administra; irreversible.

Administración de la instancia (Ajustes → Git)

La instancia Forgejo es única para toda la plataforma. Desde esta pestaña, un administrador puede:

• desplegarla si aún no existe (el catálogo genérico rechaza cualquier segunda instancia);
• supervisarla y configurarla como una aplicación estándar (recursos, reinicio, detalles).

Instancia compartida

Modificar los recursos de la instancia Forgejo reinicia el servicio Git para todos los usuarios de la plataforma — hágalo con conocimiento de causa.

Ajustes

Namespaces y cuotas

Pestaña Ajustes → Namespaces — la creación y eliminación están reservadas a los administradores de plataforma.

Un namespace es un espacio de trabajo aislado: sus aplicaciones, volúmenes y buckets están separados de los de otros namespaces, y tiene sus propias cuotas y permisos.

Crear un namespace

Nuevo namespace (desde la cabecera del panel de control o la pestaña Namespaces) → nombre (letras minúsculas y dígitos), descripción, y cuotas:

Cuota	Lo que limita
CPU requests / limits	La suma de las reservas y los topes de CPU de los pods
Memoria requests / limits	Lo mismo para la memoria
Pods	El número de pods simultáneos
Almacenamiento	La suma de las capacidades de los volúmenes persistentes

Los valores predeterminados de la plataforma se precargan y son ajustables en el momento de la creación. CPU, memoria y almacenamiento se introducen como número entero + unidad (m/núcleos, Mi/Gi/Ti), el número de pods como entero.

Una casilla Aislar el namespace en la red (marcada por defecto) aplica de inmediato la política de red deny-all descrita más abajo — desmárquela para crear un namespace abierto; el aislamiento se puede activar en cualquier momento posterior desde la pestaña Namespaces.

Seguir y ajustar las cuotas

• El indicador de cuota del panel de control muestra continuamente el consumo del namespace actual.
• En la pestaña Namespaces, el botón Cuotas de cada fila permite ajustar los topes de un namespace existente.
• Al seleccionar varios namespaces, la edición se aplica en bloque a toda la selección.

Tip

Un despliegue rechazado por exceeded quota indica la cuota en cuestión y los valores solicitados/usados/tope — con eso puede decidir entre liberar recursos o aumentar la cuota.

Permisos de un namespace

El botón Permisos de una fila otorga a un usuario un rol (viewer, operator, admin) en ese namespace — véase Acceso y permisos.

Aislamiento de red

El botón Red de una fila abre el aislamiento de red del namespace — deny-all por defecto una vez activado: ya no se permite ningún tráfico entrante ni saliente salvo las reglas declaradas a continuación (y algunos flujos técnicos siempre necesarios: DNS, acceso al Gateway para las HTTPRoute, etc.).

• Activar / desactivar el aislamiento: alterna el namespace entre abierto (comportamiento histórico) y aislado. Las reglas declaradas siguen visibles y editables incluso desactivadas, simplemente sin efecto mientras el aislamiento no esté reactivado.
• Conexiones salientes (internet): casilla marcada por defecto, que permite a las aplicaciones del namespace alcanzar el exterior del clúster — descarga de paquetes, llamadas a API de terceros. Sin marcar, solo quedan los flujos técnicos (DNS, API de Kubernetes, Forgejo, Keycloak) y las reglas declaradas. El aislamiento cubre por tanto el tráfico entre namespaces, no el acceso a internet.
• Edición masiva: marque varios namespaces en la lista y haga clic en Red en la barra de herramientas para activar o desactivar el aislamiento, o permitir o cortar las conexiones salientes, en toda la selección a la vez. Los namespaces sin nada que cambiar (ya en el estado solicitado, o no aislados para las conexiones salientes) se omiten y se listan al final.
• Reglas de acceso: autoriza a un namespace (y opcionalmente a una app concreta de ese namespace) a alcanzar este namespace en un puerto dado — útil por ejemplo para una replicación entre namespaces o un acceso aplicativo legítimo entre namespaces.
• Puertos expuestos: expone un Service de este namespace en un puerto TCP público a través del Gateway compartido, para un acceso desde fuera del clúster. Cada puerto puede restringirse a una lista de direcciones IP autorizadas (IP o rangos CIDR, rellenada con su dirección actual al crearlo, modificable después con el icono de filtro): un origen fuera de la lista es rechazado por el proxy antes de llegar a la aplicación. Si se deja vacía, se acepta cualquier dirección que el cortafuegos externo deje pasar. Una base de datos PostgreSQL se expone mejor desde su propia tarjeta (botón Acceso externo), que elige el puerto y exige TLS — véase Administración PostgreSQL.

Note

Solo los namespaces creados después de la introducción de esta funcionalidad pueden aislarse — y entre ellos, el aislamiento solo es efectivo desde la creación si se marcó la casilla correspondiente (véase más arriba). Un namespace no aislado (más antiguo, o creado sin marcar la casilla) muestra «no aislado»: las reglas declaradas no tienen entonces ningún efecto en el clúster hasta que se active el aislamiento.

Warning

Exponer un puerto (pestaña Puertos expuestos) también requiere el forward correspondiente del lado de la infraestructura, en un posible cortafuegos aguas arriba — no automatizado desde esta interfaz.

Eliminar un namespace

Eliminación con confirmación — destruye todo el contenido del namespace (aplicaciones, volúmenes, buckets). Irreversible.

Parámetros del clúster

Pestaña Ajustes → Parámetros del clúster.

Los parámetros del clúster son ajustes textuales tipados que controlan el comportamiento de la plataforma. Cada parámetro tiene:

• un tipo (ajuste de clúster, licencia Digdash, token de API…);
• un nombre (su clave) y un valor;
• un alcance: global (namespace vacío — se aplica en todas partes, gestión reservada a los administradores de plataforma) o limitado a un namespace (gestionado por los administradores de ese namespace, con prioridad sobre el valor global).

Ejemplos de ajustes reconocidos

Nombre	Efecto
USE_DIGDASH_BETA	true para ofrecer las versiones BETA de Digdash en la selección de versión
DIGDASH_QA_DATABASE_TYPES	true para mostrar los motores de base de datos reservados a QA interno (MariaDB, PostgreSQL side-car) en el formulario de Digdash BI
DIGDASH_FILEBROWSER	Valor predeterminado de la opción File Browser de los despliegues Digdash
DEFAULT_DIGDASH_RAM	Memoria predeterminada propuesta para un despliegue de Digdash BI
CPU_REQUEST_RATIO_<APLICACIÓN>	Parte del límite de CPU reservada (requests), en porcentaje — p. ej. 20: un Hop Web limitado a 2 núcleos solo reserva 0,4. Un parámetro por tipo de aplicación: POSTGRES, DIGDASH_BI, HOP_WEB (o APACHE_HOP_WEB), HOP_SERVER, FORGEJO, NGINX, ICEBERG. Se aplica en el despliegue (después, la reserva se ajusta directamente en Configurar → recursos del contenedor); 100 (por defecto) = reserva igual al límite.
GRAFANA_URL, PROMETHEUS_PUBLIC_URL, ALERTMANAGER_URL	URL públicas de las herramientas de supervisión (enlaces de la página Clúster, de la barra lateral y de las tarjetas) — por defecto https://grafana|prometheus|alertmanager.<dominio>
PROMETHEUS_URL	Dirección del Prometheus interno consultado para el consumo de volúmenes y las alertas (por defecto el servicio del namespace monitoring)
SPARK_JOB_GIT_IMAGE, SPARK_JOB_S3_IMAGE	Imágenes de los initContainers que recuperan el origen de un job Spark (repositorio Git / objeto S3) — a sobrescribir en un clúster sin acceso a Docker Hub
POSTGIS_DEFAULT_IMAGE	Imagen de PostgreSQL que incluye PostGIS, utilizada cuando se marca la opción PostGIS (debe corresponder a la versión mayor del operador CNPG)
CUSTOM_PORT_AUTO_RANGE	Rango (inicio-fin) del que se asigna automáticamente un puerto, en particular para el acceso externo de una base de datos PostgreSQL — por defecto 30000-35000
CUSTOM_PORT_RESERVED_PORTS	Puertos rechazados sistemáticamente para una exposición TCP, además de los puertos que realmente tienen las Gateways — por defecto 80,443,222
POSTGRES_PUBLIC_TLS_SECRET	Secret (namespace/nombre) del certificado wildcard de Let's Encrypt que sirven las bases PostgreSQL expuestas, p. ej. default/pg-wildcard-tls: el cliente verifica entonces el servidor sin archivo de CA. Se copia en cada base expuesta y se resincroniza cada noche. Vacío o none: certificado de CNPG y archivo de CA para descargar
POSTGRES_PUBLIC_DOMAIN	Dominio cubierto por ese wildcard (*.<dominio>): las bases expuestas se llaman <nombre-app>-<namespace>.<dominio> — por defecto pg.<dominio de la plataforma>

Valores sensibles

El valor de un parámetro se muestra en texto claro a cualquiera que tenga acceso a su ámbito. Coloque un secreto ahí solo si el ámbito es adecuado.

Uso

La lista se filtra por namespace y por tipo; la creación, edición y eliminación se realizan directamente en la tabla. Un parámetro creado en duplicado (mismo namespace, tipo y nombre) se rechaza.

Tareas programadas

Pestaña Ajustes → Tareas programadas.

Las tareas programadas ejecutan automáticamente operaciones recurrentes en la plataforma.

Tipos de tareas

• Tareas de aplicación: se dirigen a una aplicación de un namespace — reiniciar, iniciar, detener una aplicación, tomar una instantánea con retención, encolar un job Hop…
• Tareas del sistema: mantenimiento de la plataforma (limpieza de la base de datos, reconciliación de aplicaciones…), reservadas a los administradores.

Crear una tarea

Nueva tarea → nombre, descripción, tarea a ejecutar (elegida del catálogo), destino (aplicación/namespace para una tarea de aplicación), y planificación:

• Intervalo: cada n segundos/minutos/horas/días;
• Cron: minuto, hora, día del mes, mes, día de la semana, con zona horaria.

Una tarea puede deshabilitarse sin eliminarse, y ejecutarse de inmediato (botón dedicado) independientemente de su planificación.

Crear o modificar una tarea de aplicación requiere el rol admin en el namespace de la aplicación destino.

Tareas de aplicación

Una tarea de aplicación se dirige a una aplicación concreta — salvo Detener todas las aplicaciones de un namespace, que se dirige directamente a un namespace completo (el campo aplicación queda oculto en favor de un campo namespace).

El nombre y el namespace de la aplicación destino se deducen siempre de la aplicación seleccionada: no indicarlos nunca como argumentos con nombre.

Reiniciar / Iniciar / Detener la aplicación

Nada que indicar: basta con elegir la aplicación.

Solo para Iniciar la aplicación, el número de réplicas puede indicarse en Opciones avanzadas → Argumentos con nombre (1 por defecto):

{ "replicas": 2 }

Warning

No añadir release_name a los argumentos con nombre: ya se transmite automáticamente, y el duplicado hace fallar la ejecución.

Detener todas las aplicaciones de un namespace

No hay tarea/aplicación que elegir en el formulario principal: aparece un campo Namespace dedicado en lugar del campo Aplicación. No hay argumentos con nombre que indicar — {"namespace": "..."} se inyecta automáticamente desde ese campo.

Instantánea de aplicación (con retención)

Formulario simplificado (visible sin "Opciones avanzadas"): un único campo, Número de copias a conservar (entero ≥ 1, 7 por defecto). release_name/namespace se deducen automáticamente de la aplicación seleccionada — no indicarlos como argumento con nombre.

Ejemplo: copia automática de un volumen

Una instantánea diaria del volumen de una aplicación crítica: planificación cron 0 2 * * *, retención de 7 instantáneas. Para restaurar una instantánea así creada, ver Volúmenes.

Llamar a una API REST

{
  "url": "https://ejemplo.com/api/hook",
  "method": "POST",
  "json_body": { "clave": "valor" },
  "headers": { "X-Custom": "valor" },
  "auth_param": "nombre_del_parametro_namespace",
  "timeout": 30
}

• url (obligatorio).
• method: GET, POST… (POST por defecto).
• json_body: cuerpo JSON enviado tal cual (opcional).
• headers: cabeceras HTTP adicionales (opcional).
• auth_param: nombre de un parámetro del namespace de la aplicación seleccionada — su valor se lee y se inyecta tal cual en la cabecera Authorization (p. ej. Bearer xxx). Es el nombre del parámetro, no el token en sí. El namespace lo impone la aplicación elegida: un namespace indicado en los argumentos se ignora.
• timeout: segundos (30 por defecto).

Encolar un job Hop

{
  "queue_name": "mi-hopqueue",
  "kind": "pipeline",
  "path": "/files/projects/current/mipipeline.hpl",
  "name": "MiPipeline",
  "parameters": {},
  "run_config": "local"
}

• queue_name: nombre de una HopQueue existente en la aplicación Hop Server (no confundir con el campo Cola descrito más abajo — una cola de Celery, un concepto distinto).
• kind: pipeline o workflow.
• path: ruta del archivo .hpl/.hwf, tal como la devuelve la lista de archivos de la aplicación Hop Server (con el prefijo /files/projects/current/).
• name: nombre interno del pipeline/workflow (atributo name del archivo Hop — no el nombre de la propia tarea programada indicado arriba en el formulario).
• parameters: parámetros del pipeline/workflow (objeto, opcional).
• run_config: run configuration de Hop (p. ej. local) — en la práctica requerida, la ejecución falla en Hop Server sin ella.

Note

Esta entrada sigue siendo un acceso de bajo nivel. Para planificar jobs Hop recurrentes de verdad, la sección dedicada Jobs recurrentes planificados de la propia aplicación Hop Server (formulario guiado, historial por job) es la vía recomendada — ver Apache Hop Server: jobs y planificación.

Opciones avanzadas

El botón Opciones avanzadas del formulario revela campos normalmente ocultos:

• Argumentos con nombre: parámetros de la tarea en formato JSON libre — ver el detalle por tarea más arriba. Instantánea de aplicación y Detener todas las aplicaciones de un namespace tienen su propio formulario simplificado y no lo necesitan.
• Cola: la cola de Celery que ejecuta la tarea (ajuste avanzado, rara vez necesario — sin relación con una HopQueue).
• Argumentos posicionales: equivalente a los argumentos con nombre en forma de lista posicional, para una necesidad puntual.

Seguimiento

Cada tarea muestra su última ejecución y su contador total; su historial enumera las ejecuciones pasadas con su estado y su resultado, filtrable por estado.

Autenticación por relé

Pestaña Ajustes → Autenticación por relé — solo administradores de plataforma.

La autenticación por relé permite a los usuarios conectarse a la plataforma a través de un proveedor de identidad externo (el SSO de la empresa, un directorio de terceros…): el Keycloak de la plataforma delega entonces la autenticación a ese proveedor externo, mediante OpenID Connect o SAML 2.0.

Añadir un proveedor de identidad

Añadir un proveedor de identidad:

1. Alias: identificador técnico único (aparece en las URL — no modificable después).
2. Protocolo: OpenID Connect o SAML 2.0 — el formulario se adapta.
3. Nombre para mostrar: la etiqueta del botón de conexión que se muestra a los usuarios.
4. Importar desde una URL: pegue la URL de descubrimiento del proveedor (…/.well-known/openid-configuration en OIDC, la URL de metadatos en SAML) y haga clic en Importar — las URL de autorización, de token, JWKS… se completan automáticamente.
5. Complete el Client ID y el Client secret proporcionados por el administrador del proveedor externo, y luego Guardar.

El proveedor aparece en la lista; puede deshabilitarse temporalmente, modificarse o eliminarse en cualquier momento. La configuración vive directamente en Keycloak — no hay copia local, lo que ve es siempre el estado real.

Cuentas existentes: vinculación automática

La opción Vincular automáticamente a las cuentas existentes, marcada por defecto, resuelve el caso de un usuario ya creado en el Control Panel (página Usuarios) que inicia sesión por primera vez mediante el SSO:

• marcada: su identidad SSO se vincula directamente a la cuenta con el mismo correo o nombre de usuario, sin pedirle contraseña. Las cuentas destinadas al SSO pueden crearse, por tanto, sin contraseña;
• desmarcada: comportamiento predeterminado de Keycloak, la pantalla «La cuenta ya existe» pide la contraseña de la cuenta existente antes de vincularla.

Un usuario SSO sin cuenta existente obtiene una cuenta en su primer inicio de sesión, en ambos casos.

Solo proveedores de confianza

Con la vinculación automática, la plataforma confía plenamente en el proveedor externo: un usuario que pueda elegir libremente allí su correo o nombre de usuario podría acceder a la cuenta correspondiente de la plataforma. Manténgala activa solo para un proveedor que garantice esta información (directorio corporativo, Entra ID, Google…).

Los proveedores creados antes de esta opción conservan el comportamiento predeterminado de Keycloak: marque la opción al editarlos, o ejecute python manage.py enable_idp_auto_link en el backend para cambiarlos todos.

Mappers

Al desplegar la fila de un proveedor, la sección Mappers proyecta la información recibida del proveedor externo hacia la plataforma:

• Atributo: copia una claim OIDC (o un atributo SAML) a un atributo de la cuenta de usuario — por ejemplo department → atributo department.
• Rol: otorga un rol del realm cuando una claim tiene un valor determinado — por ejemplo groups = "admins" → rol platform_admin.

Del lado del proveedor externo

El administrador del proveedor de identidad debe registrar la plataforma como cliente y autorizar la URL de redirección de Keycloak (https://<keycloak>/realms/<realm>/broker/<alias>/endpoint), visible en la consola de Keycloak.

Ejemplo: conectarse con una cuenta Google

Google expone un proveedor OpenID Connect estándar — no se necesita ninguna configuración particular del lado de la plataforma más allá del flujo descrito arriba.

1. Crear las credenciales del lado de Google

En Google Cloud Console (proyecto dedicado o existente):

1. APIs y servicios → Pantalla de consentimiento de OAuth: configúrela si aún no lo está (nombre de la aplicación, dominios autorizados).
2. APIs y servicios → Credenciales → Crear credenciales → ID de cliente de OAuth, tipo Aplicación web.
3. URI de redirección autorizados: añada https://<keycloak>/realms/<realm>/broker/google/endpoint (el alias elegido en el siguiente paso — google aquí — debe coincidir).
4. Anote el ID de cliente y el secreto del cliente generados.

2. Configurar el proveedor de identidad del lado de la plataforma

Desde Añadir un proveedor de identidad:

1. Alias: google (debe coincidir con el URI de redirección autorizado del lado de Google).
2. Protocolo: OpenID Connect.
3. Nombre para mostrar: por ejemplo Google.
4. Importar desde una URL: https://accounts.google.com/.well-known/openid-configuration, luego Importar — los endpoints de Google (autorización, token, JWKS, userinfo) se completan automáticamente.
5. Client ID / Client secret: los valores anotados en el paso anterior.
6. Guardar.

El botón Google aparece entonces en la pantalla de conexión de la plataforma.

Restringir a un dominio de Google Workspace

Para permitir solo las cuentas de una organización Google Workspace en lugar de cualquier cuenta Google, publique la pantalla de consentimiento OAuth de forma interna a la organización (en lugar de externa) del lado de Google Cloud Console — la restricción se aplica entonces del lado de Google, antes incluso de que el usuario llegue a la plataforma.

Redirecciones de URL

Pestaña Parámetros → Redirecciones — solo administradores de la plataforma.

Una redirección responde con un 301 (redirección permanente) a toda petición dirigida a un nombre de host, hacia la URL de su elección. Sirve para las migraciones de servicios, en ambos sentidos:

• del exterior hacia el clúster: el antiguo dominio de un servicio (www.cliente.com, por ejemplo) se redirige hacia la aplicación que lo sustituye en el clúster;
• del clúster hacia el exterior, o hacia otra aplicación: la antigua dirección de una aplicación del clúster (app-antigua.<dominio del clúster>) se redirige hacia su nuevo servicio, interno o externo.

Los navegadores y los motores de búsqueda recuerdan una redirección permanente: los enlaces y favoritos existentes siguen funcionando.

Crear una redirección

Nueva redirección:

1. Nombre de host redirigido: solo el nombre, sin https:// ni ruta. Ya no puede cambiar después: para cambiarlo, elimine la redirección y vuelva a crearla.
2. Destino:
   • Aplicación del clúster: elija el namespace y luego la aplicación; la URL de destino pasa a ser la raíz de la aplicación;
   • URL: cualquier dirección http:// o https://, sin parámetros (?…) ni ancla (#…).
3. Conservar la ruta de la petición (marcado por defecto): https://antigua-direccion/docs/a.pdf lleva a <destino>/docs/a.pdf. Desmarcado, toda petición lleva a la propia URL de destino. Los parámetros de la petición se conservan en ambos casos.
4. Crear.

Las direcciones http:// del nombre redirigido también se redirigen.

Certificado del nombre de host

• Subdominio del clúster (app-antigua.<dominio del clúster>): cubierto por el certificado del clúster, la redirección está activa en unos segundos.
• Dominio externo: se solicita un certificado dedicado a Let's Encrypt. Apunte primero el DNS del dominio a la dirección pública del clúster, indicada en la ventana de creación: Let's Encrypt verifica el dominio accediendo a él. El certificado suele emitirse en uno o dos minutos.

• Certificado proporcionado (opción de la ventana, para cualquier nombre de host): utilice un certificado generado fuera de la plataforma (autoridad interna, certificado comprado, etc.). Pegue o cargue desde un archivo:

  • el certificado en formato PEM: el del servidor primero, seguido de los certificados intermedios;
  • la clave privada en formato PEM, sin cifrar.

  El Control Panel comprueba que la clave corresponde al certificado, que el certificado cubre el nombre de host (nombre exacto o wildcard *.dominio) y que no ha caducado. La clave solo se conserva en el clúster (Secret TLS), nunca en la base de datos del Control Panel. El DNS del dominio debe seguir apuntando al clúster, pero no hay verificación de Let's Encrypt.

Sin renovación automática

Un certificado proporcionado no lo renueva la plataforma: la fila muestra su fecha de caducidad (en naranja a menos de 30 días). Antes de que caduque, abra Modificar y suba el nuevo certificado y su clave; si se dejan vacíos, se conserva el certificado actual.

Seguir una redirección

Cada fila indica:

• Dominio del clúster o Dominio externo;
• Ruta conservada o Ruta reemplazada;
• Ruta: listo cuando la pasarela del clúster sirve la redirección; pendiente justo después de una creación o modificación;
• Certificado (dominio externo): pendiente mientras Let's Encrypt no haya emitido el certificado. Pase el ratón sobre la etiqueta para leer el detalle, por ejemplo un DNS que aún no apunta al clúster. Para un certificado proporcionado: listo, o error una vez caducado, con su emisor y su fecha de caducidad.

Actualizar vuelve a leer el estado desde el clúster.

Modificar, eliminar

• Modificar: cambie el destino, la opción de ruta, la descripción o el certificado (paso al certificado proporcionado o vuelta al automático, subida de un nuevo certificado). El nuevo destino se aplica en unos segundos.
• Eliminar: el nombre de host deja de redirigirse; su certificado dedicado (emitido o proporcionado) también se elimina.

Nombre de host aún en uso

No se puede crear una redirección para un nombre de host que una aplicación o una ruta aún sirve: el mensaje indica el objeto correspondiente. Para redirigir la antigua dirección de una aplicación, elimine primero la aplicación.

Secretos

Pestaña Ajustes → Secretos — acceso reservado a los administradores del namespace (o de la aplicación) correspondiente.

La pestaña Secretos muestra los Secrets de Kubernetes de tipo Opaque o basic-auth de un namespace (o de una sola aplicación, mediante el filtro). Los secretos OIDC gestionados por la plataforma (clientes Keycloak de las aplicaciones) quedan excluidos de la lista — no se listan ni se pueden consultar aquí.

Consulta bajo demanda

La lista solo muestra los nombres de las claves de cada secreto, nunca su valor. Al hacer clic en Mostrar se obtiene y revela el valor en texto claro de una sola clave, bajo demanda — el valor permanece oculto para todas las demás claves mientras no se haga clic en ellas individualmente.

Trazabilidad

Cada consulta (Mostrar) y cada copia (Copiar) genera su propia llamada, registrada de forma distinta en el registro de auditoría (pestaña Ajustes → Auditoría) — quién vio o copió qué clave, y cuándo.

Copiar un valor

El botón Copiar coloca el valor en el portapapeles sin necesariamente mostrarlo antes — útil para pegar una contraseña o una clave de API directamente en otra herramienta sin exponerla en pantalla.

Filtrar

Un selector de namespace y un selector de aplicación permiten restringir la lista — un administrador de aplicación (sin derechos sobre todo el namespace) solo ve los secretos de sus propias aplicaciones.

Logs de auditoría

La pestaña Logs de auditoría (Ajustes, reservada a los administradores de la plataforma) registra las acciones mutantes realizadas por los usuarios — creación, modificación, eliminación — sobre los recursos gestionados por el Control Panel: aplicaciones, cuentas, permisos, volúmenes, namespaces, secretos Git, proveedores de identidad…

Lo que no se registra aquí

Solo se registran las acciones que tienen éxito — un intento rechazado por un permiso o un error técnico no aparece en este registro (sigue visible en los logs técnicos generales). La simple consulta de datos (lectura) no suele registrarse, salvo las lecturas consideradas sensibles: la consulta de un token Git personal (git_token.view) y la consulta o copia del valor de un secreto Kubernetes (secret.view, secret.copy — véase Secretos).

Columnas de la tabla

Columna	Contenido
Marca de tiempo	Fecha y hora de la acción, en la zona horaria del navegador.
Usuario	El nombre de usuario que realizó la acción — anonymous para una acción no autenticada (normalmente inexistente, ya que estas acciones requieren una sesión).
Acción	Un identificador corto y estable con formato recurso.verbo, por ejemplo app.create, user.delete, pvc.resize, git_token.regenerate — véanse los ejemplos a continuación.
Namespace	El namespace afectado, cuando la acción depende de uno (una aplicación, un PVC…) — vacío para acciones transversales (gestión de usuarios, proveedores de identidad…).
Detalles	Los identificadores propios del objetivo de la acción (nombre de la aplicación, del pod, del volumen, del grupo…), en forma clave=valor, específicos de cada tipo de acción.

Ejemplos de acciones

Acción	Ámbito
app.create, release.delete, release.scale, deployment.restart, workload.update	Ciclo de vida de las aplicaciones
pvc.create, pvc.resize, pvc.delete, pvc.clone, pvc.snapshot, snapshot.restore, snapshot.delete	Volúmenes e instantáneas
app_access.grant, app_access.revoke, app_access.set_profiles, application_permission.delete	Acceso a las aplicaciones
user.create, user.update, user.delete, user.bulk_update, user.bulk_delete	Cuentas de usuario
group.member_add, group.member_remove, group.namespace_permission_add, group.namespace_permission_remove, group.delete	Grupos y permisos
namespace.create, namespace.quota_update, namespace.quota_bulk_update, namespace_permission.delete	Namespaces y cuotas
git_token.view, git_token.regenerate	Token de acceso Git personal
identity_provider.create, identity_provider.update, identity_provider.delete, identity_provider.mapper.create, identity_provider.mapper.update, identity_provider.mapper.delete	Autenticación por relé (véase Autenticación por relé)
secret.view, secret.copy	Consulta o copia del valor de un secreto Kubernetes (véase Secretos)

Nunca se registra ningún valor secreto

Una contraseña, un token o una clave secreta nunca aparece en texto plano en los detalles de una acción — solo se registra el hecho de que se haya cambiado (ej. password_changed=True).

Filtrar y seguir el registro

• Usuario, Acción, Namespace: listas desplegables alimentadas dinámicamente con los valores ya vistos.
• Búsqueda: filtro de texto completo sobre la columna Detalles.
• Rango de fechas: restringe a las entradas cuya marca de tiempo esté dentro del intervalo elegido.
• Número de líneas: volumen de logs recuperados del servidor (de 100 a 5000).
• Live: se actualiza automáticamente cada 5 segundos; Pausa congela la visualización sin detener la recolección.

Paquete de logs

El paquete de logs es un archivo único que reúne los logs y el estado de la plataforma, destinado al equipo de soporte de DigDash: cuando necesita entender un incidente, este es el archivo que pide. Se genera desde la pestaña Logs (Ajustes, reservada a los administradores de la plataforma), con el botón Exportar el paquete de logs — sin línea de comandos ni acceso al clúster.

Un archivo para el equipo de soporte de DigDash, y solo para él

El archivo está cifrado: solo el equipo de soporte de DigDash puede abrirlo. Nadie más puede leer su contenido, ni siquiera un administrador de la plataforma. Por lo tanto no sirve de otro modo, y se envía únicamente a ese equipo.

Iniciar una exportación

Exportar el paquete de logs abre la ventana Exportar un paquete de logs. Pide dos cosas — qué debe contener el paquete y sobre qué periodo — y luego Exportar inicia la recopilación. Exportar permanece atenuado mientras no haya nada marcado.

Al abrirse, la ventana puede mostrar Leyendo el clúster: namespaces, aplicaciones y su estado…: consulta la plataforma para saber qué se puede marcar. En una plataforma grande, puede tardar hasta un minuto. Si ya hay una exportación en curso o lista, su seguimiento se muestra sin esperar.

Perímetro

Bloque	Qué aporta al paquete
DigDash DataStack System	El estado del clúster, el Control Panel y los namespaces de sistema: todo lo que DigDash entregó con la plataforma. Marcado al abrir la ventana; se toma o se deja entero. El enlace N namespaces de sistema muestra los namespaces afectados.
Namespaces y aplicaciones	Los namespaces gestionados en el Control Panel y sus aplicaciones. Marcar un namespace lo toma entero; la flecha a su izquierda despliega sus aplicaciones, para marcar solo algunas. Seleccionar todo y Deseleccionar todo actúan sobre todos los namespaces.

El soporte suele indicar qué marcar. Si no, conservar DigDash DataStack System y añadir la aplicación o el namespace afectado por el incidente da un paquete útil sin hacerlo innecesariamente grande.

Plegado, un namespace indica cuántas aplicaciones contiene, cuántas están marcadas y cuántas están detenidas. Desplegado, cada aplicación lleva su estado:

Estado	Significado
En marcha	Todo lo que la aplicación debe ejecutar está listo.
Degradada	Una parte de la aplicación no está lista: arranque en curso, pod con error…
Detenida	La aplicación está detenida. No tiene ningún pod, por lo tanto ningún log: marcada, solo aporta su estado al paquete.

Aplicaciones o estados no mostrados

Cuando la lista de aplicaciones de un namespace no se puede leer, el namespace se sigue proponiendo, para tomarlo entero (Aplicaciones no listadas). Cuando lo que no se puede leer es su estado, las aplicaciones se muestran sin estado.

Ventana temporal

La Ventana temporal acota lo que se recopila: Última hora, Últimas 24 horas (propuesta al abrir la ventana), Últimos 2 días, Últimos 3 días o Últimos 7 días.

Es un máximo. Cada nodo solo conserva un volumen limitado de logs por contenedor: un contenedor que escribe mucho a veces solo cubre unas horas, sea cual sea el periodo solicitado. Además, los logs de un pod desaparecen con él: tras una actualización o un redespliegue, no se remontan más allá de la creación del nuevo pod.

Seguir la recopilación

La ventana muestra Recopilación en curso… y el avance, en objetivos tratados. La recopilación dura de unos segundos a unos quince minutos, según el perímetro.

• La ventana se puede cerrar: la recopilación continúa en la plataforma, y el botón Exportar el paquete de logs recupera su seguimiento.
• Cancelar la exportación detiene la recopilación; no se conserva nada.
• Una sola exportación a la vez en la plataforma. Si otro administrador ha iniciado una, la ventana muestra su seguimiento en lugar del formulario.

Descargar el paquete

Terminada la recopilación, la ventana muestra El paquete está listo. con:

Elemento	Contenido
Archivo	El nombre del archivo, con la forma ds-bundle-<plataforma>-<fecha>-k<clave>.zip.age: la plataforma de origen, el inicio de la recopilación (hora UTC) y la clave de cifrado utilizada, la que muestra la ventana antes de exportar (Clave de cifrado).
Tamaño	El tamaño del archivo cifrado.
Huella SHA-256	La huella del archivo, que permite comprobar que no ha sido alterado.
N archivos · N valores enmascarados	El número de archivos del paquete y el número de valores sensibles enmascarados (véase Qué contiene el paquete).
Disponible hasta el…	La hora a la que el paquete se eliminará de la plataforma: una hora después de generarse.

Descargar entrega el archivo al navegador, que lo comprueba con su huella antes de guardarlo en las descargas.

Mensaje	Qué ha ocurrido	Qué hacer
Paquete descargado y verificado.	El archivo está intacto, y se ha eliminado de la plataforma.	Si no aparece en las descargas del navegador, Guardar de nuevo antes de cerrar la ventana: una vez cerrada, hay que iniciar otra exportación.
Paquete descargado. Este navegador no ha podido verificar su integridad…	El archivo está guardado, pero el navegador no ha podido comprobarlo — es el caso cuando el Control Panel se abre en HTTP y no en HTTPS. El paquete permanece en la plataforma, una hora como máximo.	Comparar la huella mostrada con la del archivo recibido (sha256sum en Linux, shasum -a 256 en macOS, Get-FileHash en Windows) y luego Eliminar de la plataforma.
El archivo recibido no coincide con la huella anunciada y no se ha guardado…	El archivo recibido no es el que generó la plataforma: la transferencia lo ha alterado. El paquete sigue en la plataforma.	Volver a pulsar Descargar.

Nada queda en la plataforma

El paquete se elimina en cuanto se ha descargado y verificado, y en todo caso una hora después de generarse. Mientras está ahí, la ventana lo muestra a cualquier administrador de la plataforma; para iniciar otra exportación, primero hay que descargarlo o borrarlo con Eliminar este paquete.

Enviar el archivo al soporte

El archivo .zip.age se envía tal cual al equipo de soporte de DigDash, por el canal de soporte habitual. Es mejor no cambiarle el nombre: su nombre indica al soporte de qué plataforma procede y qué clave lo abre.

Qué contiene el paquete

Perímetro	Contenido
DigDash DataStack System	Estado de los nodos, diario de su kubelet y de su motor de contenedores; eventos del clúster; alertas activas, alertas que saltaron durante el periodo y reglas de alerta en error; versiones instaladas; versión, canal de actualización y estado de la licencia del Control Panel, su registro de auditoría, el resultado de sus tareas durante el periodo (una línea por resultado distinto, con su número de ocurrencias), sus últimas actualizaciones; eventos, descripción y logs de los pods de los namespaces de sistema.
Un namespace o una aplicación	Eventos y alertas del namespace; para cada aplicación, su release Helm (nombre, chart, versión, estado), el estado de sus componentes (réplicas, bases de datos, última parada o arranque solicitado), la descripción y los logs de sus pods — incluidos los del contenedor anterior tras un reinicio — y las peticiones que la pasarela recibió para ella, incluidas las que no pudo transmitir a ninguna ruta.

Nunca entran en el paquete: los secretos de Kubernetes, los valores de configuración de las aplicaciones (values de Helm, contenido de los ConfigMap, valores de las variables de entorno — solo se conserva el nombre de las variables), el kubeconfig, el contenido de la licencia.

En todo el paquete, los valores reconocidos como sensibles se sustituyen por [REDACTED]: contraseñas, tokens, claves de acceso, cabeceras de autenticación y cookies, credenciales de una URL, claves privadas. Su número se muestra con el paquete listo (valores enmascarados).

El enmascaramiento es una precaución, no una garantía

Los logs se recogen tal como las aplicaciones los escribieron: pueden contener datos de negocio (nombres, identificadores, consultas). Por eso el archivo está cifrado y se destina únicamente al equipo de soporte de DigDash.

Si la exportación no termina

Lo que se muestra	Causa	Qué hacer
Botón atenuado y Exportación no disponible: no hay ninguna clave de cifrado configurada en esta plataforma…	La clave de cifrado del soporte no se instaló con la plataforma.	Contactar con el soporte de DigDash: la clave se instala con la infraestructura, no desde el Control Panel.
No se puede leer el perímetro exportable.	La plataforma no pudo consultar el clúster.	Reintentar.
La exportación ha fallado.	La recopilación se interrumpió — se muestra el mensaje técnico — o permaneció cinco minutos sin avanzar.	Nueva exportación. Si el fallo se repite, reducir el perímetro y transmitir el mensaje al soporte.
Esta exportación ya no existe: fue abandonada o ha caducado.	La exportación se canceló durante la recopilación, desde otra ventana o por otro administrador.	Iniciar otra exportación.

Trazabilidad

Cada exportación y cada descarga quedan registradas en los logs de auditoría, con su autor: acciones log_bundle.export y log_bundle.download.