gDown Instalación

gDown se instala solo, en una máquina o en clúster, con un único script. El script solo verifica y luego instala: comprueba un manifiesto firmado (Ed25519) y el SHA-256 del binario antes de escribir nada.

gDown pasa a ser un servicio systemd (usuario gluonify-gdown, datos en /var/lib/gluonify-gdown). Un primer nodo inicia un clúster nuevo de un miembro; la contraseña de administrador generada se guarda en un archivo legible solo por root.

Ejecute el primer comando en la primera máquina. Su token de clúster está en /etc/gluonify-gdown/gdown.env (GLUONIFY_GDOWN_AUTH_TOKEN): cópielo y ejecute el último comando en cada una de las demás máquinas, con --seed apuntando al primer nodo. El token pasa por el entorno, nunca como argumento. El nuevo miembro se configura a partir del primer nodo y se une. Tres miembros siguen funcionando cuando se pierde uno.

Opciones

  • --node-id: nombre del miembro (por defecto, el nombre de la máquina).
  • --advertise-host: la dirección con la que los demás miembros alcanzan a este (por defecto, el nombre de la máquina).
  • --seed: URL de un miembro de un clúster existente; omítala en el primer nodo.
  • --data-dir: directorio de datos (por defecto /var/lib/gluonify-gdown).
  • --version: versión que instalar (por defecto, la última).
  • --key-sha256: huella de la clave de publicación; el script rechaza cualquier otra clave.

Puertos

8080 (HTTP: API, consola web), 7687 (Bolt) y 9000 (Raft, solo entre miembros). Abra 9000 entre las máquinas de un clúster y, para sus clientes, nada más que 8080 y 7687.

Docker

La imagen pública gluonify/gdown ejecuta el binario nativo sobre Red Hat UBI 9 micro (desde la 0.6.1), para linux/amd64 y linux/arm64: usuario sin privilegios (uid 10001, o cualquier uid del grupo 0, como los asigna OpenShift), datos en el volumen /data, sistema de archivos raíz de solo lectura, comprobación de salud hecha por el propio binario (sin curl en la imagen). Funciona sin cambios con la política restricted-v2 de OpenShift; un StatefulSet de tres miembros está en esta página. No tiene contraseña por defecto y no arranca sin la contraseña del administrador inicial (preferiblemente en un archivo, un secreto de Docker, o en el entorno) o un proveedor OpenID Connect. Desde la 0.6.0 el binario se construye con Oracle GraalVM 25 y optimización guiada por perfiles (PGO); las partes de Oracle GraalVM que contiene se redistribuyen gratuitamente según los GraalVM Free Terms and Conditions (GFTC), cuyo texto se incluye en la imagen en /licenses.

Tres miembros con TLS mutuo (Docker Compose)

El ejemplo de Compose arranca tres miembros con TLS mutuo en Raft entre ellos, HTTPS para la consola y la API, y Bolt sobre TLS. Dos scripts generan certificados de prueba y secretos aleatorios; en producción, use su propia autoridad de certificación.

  • Secretos: la contraseña del administrador inicial puede darse directamente en GLUONIFY_GDOWN_AUTH_LOCAL_INITIAL_ADMIN_PASSWORD, pero se recomienda GLUONIFY_GDOWN_AUTH_LOCAL_INITIAL_ADMIN_PASSWORD_FILE (un archivo, por ejemplo un secreto de Docker), porque el entorno aparece en docker inspect; lo mismo para el token de servicio, con GLUONIFY_GDOWN_AUTH_TOKEN_FILE.
  • Sin TLS entre miembros el clúster funciona, pero Raft viaja en claro: gDown registra una advertencia al arrancar y en cada incorporación. El TLS mutuo es la configuración recomendada.
  • Volúmenes: /data (bases y registro Raft, consérvelo) y /var/lib/gdown/native, donde se desempaqueta la biblioteca TLS (debe permitir la ejecución, a diferencia de un /tmp noexec).
  • Las imágenes se firman con cosign con la clave de Gluonify e incluyen un SBOM y una atestación de procedencia; una actualización reemplaza un miembro cada vez.

OpenShift y Kubernetes

La imagen funciona sin cambios bajo la política restricted-v2 de OpenShift: uid aleatorio en el grupo 0, sin capacidades, sistema de archivos raíz de solo lectura. Deje runAsUser sin definir (OpenShift lo elige y su fsGroup hace el volumen escribible): no hace falta anyuid. Cree el secreto con la contraseña de administrador y el token de servicio, y aplique el manifiesto: un Service headless y un StatefulSet de tres miembros en el que gdown-0 inicia el clúster y los demás se unen.

Raft circula en claro entre los miembros: añada las variables TLS del ejemplo Compose del clúster para cifrarlo. HTTP pasa por una Route, Bolt por un Service LoadBalancer (una Route solo lleva HTTP); nunca exponga el puerto 9000. Verificado bajo Docker con uid aleatorios del grupo 0, aún no en un clúster OpenShift.

Inicio de sesión con Microsoft Entra ID

gDown acepta los tokens de acceso de Entra ID por HTTP, WebSocket y Bolt, y su consola inicia la sesión de las personas con Entra ID (código de autorización con PKCE). Los derechos vienen de los roles de aplicación, en el claim roles.

  1. Registre la API (un solo inquilino) y ponga accessTokenAcceptedVersion a 2 en su manifiesto, para obtener tokens v2.
  2. Exponga una API: URI de ID de aplicación api://<api-client-id> y un ámbito gdown.access, que los clientes piden para obtener un token destinado a gDown.
  3. Cree los roles de aplicación gDown.Reader, gDown.Writer y gDown.Admin; asígnelos a usuarios o grupos, y a los demonios como permisos de aplicación.
  4. Registre la consola como aplicación de una sola página (PKCE, sin secreto) con la dirección de la consola como URI de redirección, y dele el permiso delegado gdown.access.
  5. Monte la configuración siguiente en la imagen, en /opt/gdown/config/application.properties.

Lo que debe llevar el token

iss = https://login.microsoftonline.com/<tenant-id>/v2.0 (su inquilino, token v2); aud = el id de cliente de la API (un token para otra API se rechaza); roles = los roles de aplicación, asociados a reader, writer o admin; tid = su inquilino (comprobado mediante iss, o con allowed-tenants para varios inquilinos); exp y la firma de Microsoft. El claim scp es informativo: los derechos no dependen de él.

Use roles de aplicación en lugar del claim groups: a partir de 200 grupos Entra lo omite (overage), y gDown no llama a Microsoft Graph. Un token es válido hasta que expira.

Licencia

Copyright (c) 2026 Gluonify. gDown se publica bajo la Business Source License 1.1: puede copiarlo, modificarlo, redistribuirlo y usarlo en producción, salvo para ofrecer a terceros un servicio de base de datos alojado o gestionado. Cuatro años después de cada versión, esta pasa a la licencia Apache 2.0. Para cualquier otro uso hay una licencia comercial disponible. Los componentes de terceros conservan sus propias licencias, enumeradas en el archivo NOTICE del repositorio.

Neo4j, Bolt y Cypher son marcas de Neo4j, Inc. openCypher es un proyecto del openCypher Implementers Group (su TCK está bajo la licencia Apache 2.0). Oracle, Java y GraalVM son marcas de Oracle y/o sus filiales. Red Hat, UBI y Mandrel son marcas de Red Hat, Inc. Docker es una marca de Docker, Inc. gDown y Gluonify no están afiliados, patrocinados ni avalados por ninguno de ellos; «compatible con» designa únicamente la compatibilidad de protocolo y de lenguaje.