Unión de streamers¶
cluster.control.nodes
Central almacena la configuración del clúster y determina qué streams ejecuta cada streamer. Para añadir una máquina, el operador abre una ventana de unión y le proporciona la dirección de central y el token de unión. Tras registrarse, el streamer obtiene una identidad persistente, sincroniza la configuración e informa de su estado.
No hace falta copiar la configuración de todos los streams al servidor nuevo. Central entrega las asignaciones; el operador administra la máquina mediante la configuración del streamer. Consulte la instalación para desplegar Sapsan.
Requisitos¶
Se necesitan:
- Dirección de central: dirección HTTP o HTTPS del grupo de gestión accesible desde el streamer.
- Token de unión: secreto de una ventana activa obtenido por el operador en central.
- Directorio de estado persistente: directorio escribible que se conserve al reiniciar el proceso o contenedor.
- Instalación compatible: la distribución y la licencia deben permitir participar en el clúster seleccionado.
El streamer inicia la conexión de sincronización. Las solicitudes inversas de central y la lectura de medios por otros streamers requieren direcciones correctas de la máquina. Consulte conectividad y entrega.
Ventana de unión¶
La acción permit_join abre una ventana de una hora y emite un token de unión. Durante ese plazo pueden registrarse los streamers que tengan el token. Es un permiso temporal de registro, no la contraseña permanente del streamer. No hay aprobación manual individual: el token activo permite el registro.
Abra la ventana mediante la API de gestión de central con una clave administrativa:
curl -fsS -X POST \
-H "Authorization: Bearer $ADMIN_KEY" \
https://central.example/central/api-v4/nodes/permit-join
La solicitud no necesita cuerpo. La respuesta contiene el token en token, el estado en open y los segundos restantes en remaining_secs. Guarde el token para las máquinas nuevas. Un GET normal a la misma dirección no revela el secreto; para recuperarlo mientras la ventana siga activa, use GET /central/api-v4/nodes/permit-join/reveal con autenticación administrativa.
Repetir permit_join con la ventana abierta la prolonga conservando el mismo token. Abrir una ventana después de su cierre o caducidad genera un token nuevo. La prolongación conserva el token ya entregado a las máquinas en instalación.
Un token permite unir varios streamers. Cierre la ventana al terminar. Su cierre o caducidad no revoca registros existentes: los streamers unidos siguen sincronizándose con sus propias credenciales.
curl -fsS -X DELETE \
-H "Authorization: Bearer $ADMIN_KEY" \
https://central.example/central/api-v4/nodes/permit-join
El streamer reintenta un registro inicial denegado. Compruebe que la ventana está abierta y que la máquina usa su token actual. Si la ventana anterior caducó, entregue el token nuevo a los streamers aún no registrados.
Activar el modo gestionado¶
Configure localmente la conexión en managed_by:
managed_by:
url: https://central.example
name: streamer-01
join_token: "JOIN_TOKEN_FROM_CENTRAL"
state_dir: /var/lib/sapsan/central
| Campo | Función |
|---|---|
url |
Dirección de central o lista de direcciones de un único grupo de gestión. |
name |
Etiqueta del operador; por defecto, el hostname de la máquina. |
join_token |
Token de registro inicial; no se vuelve a usar si existe una identidad guardada. |
state_dir |
Directorio de identidad y caché de configuración. Por defecto se usa el directorio de estado escribible de la instalación que contiene server.id. |
La dirección del grupo puede ser una lista:
managed_by:
url:
- https://central-1.example
- https://central-2.example
join_token: "JOIN_TOKEN_FROM_CENTRAL"
La lista establece la preferencia de direcciones. Ante un fallo de red, el streamer prueba otras del grupo. También guarda las direcciones recibidas de central para reutilizarlas tras reiniciar. No mezcle clústeres independientes: son entradas alternativas al mismo grupo.
Sin esquema se añade http://. Para TLS, indique https:// y configure el certificado del servidor.
También puede usar variables de entorno:
| Variable | Parámetro |
|---|---|
CENTRAL_URL |
managed_by.url; varias direcciones se separan con comas. |
NODE_NAME |
managed_by.name. |
JOIN_TOKEN |
managed_by.join_token. |
STATE_DIR |
managed_by.state_dir. |
El entorno prevalece sobre los valores de configuración correspondientes. Elimine las variables antiguas al trasladar la instalación a otro clúster.
managed_by activa el modo gestionado. La sección central configura el propio componente de gestión y no sustituye a managed_by. No se permite combinar managed_by con la fuente externa de configuración config_external.
Identidad persistente¶
El registro devuelve node_id y el secreto node_key. El streamer los guarda en identity.json, dentro de state_dir, para sincronizaciones posteriores. node_id es el identificador de la API; ni name ni el hostname constituyen esa identidad.
Al reiniciar normalmente, el streamer carga su identidad sin registrarse de nuevo. No necesita otra ventana aunque el token anterior haya caducado. Cambiar la etiqueta tampoco crea un registro nuevo.
Conserve el directorio al actualizar o recrear el contenedor. Perder identity.json supone perder las credenciales; un archivo corrupto produce un error en lugar de crear otro registro silenciosamente. Copiarlo a otra máquina transfiere la misma identidad, no une un streamer nuevo.
El archivo contiene un secreto y se crea con permisos 0600. Limite el acceso al proceso y a los administradores. No incluya identidades o tokens en informes públicos de diagnóstico.
Autenticación en ambos sentidos¶
La gestión y la lectura de medios usan credenciales distintas:
| Dirección | Mecanismo de acceso |
|---|---|
| Streamer → central | Tras unirse, presenta node_key como secreto Bearer. Central identifica el registro por esa clave. |
| Central → API de gestión del streamer | Central crea una cuenta api_auth independiente para HTTP Basic y la entrega en la configuración gestionada, por ejemplo para consultar sesiones y realizar acciones de gestión. |
| Streamer → otro streamer | La lectura de medios y archivo entre servidores usa un billete JWT firmado independiente. node_key no se entrega a los streamers vecinos. |
Cada sentido tiene su mecanismo de autorización. Esto no configura automáticamente TLS mutuo. Con HTTPS, el cliente verifica el certificado del servidor mediante TLS normal; la unión no fija una clave especial de central ni emite un certificado de cliente.
Compruebe la dirección y use HTTPS o una red protegida para transmitir secretos de gestión. Poseer un token de unión no autentica por sí solo al servidor central de destino.
Los billetes entre servidores se firman con Ed25519 y se verifican localmente. Su vigencia actual es de 24 horas; central los renueva antes de caducar. Un billete guardado y vigente permite leer de otros streamers durante una interrupción temporal, pero no da acceso indefinido sin renovación.
Propiedad de la configuración¶
En modo gestionado, central determina la lista de streams: el campo local streams no se combina con las asignaciones ni actúa como reserva al perder la conexión. Cree los streams y cambie su ubicación mediante central. Consulte la distribución de streams.
La configuración del servidor tiene varias capas. Central entrega los parámetros del streamer, pero los archivos include locales y el entorno pueden sobrescribir valores individuales. El valor guardado en central puede diferir del efectivo en la máquina. La interfaz señala estas sobrescrituras; consulte el orden de aplicación.
Actualice la configuración y supervise su aplicación desde central. En la máquina permanecen la dirección del grupo y los parámetros de inicio necesarios para conectarse.
Si central no está disponible¶
El streamer guarda en disco la configuración y su slice de streams. Los streams ya aplicados siguen funcionando durante pérdidas temporales de la conexión de gestión; la lista local no sustituye su configuración.
Tras reiniciar, puede restaurar el funcionamiento desde la caché y reanudar la sincronización. Sin una caché utilizable, como en el primer arranque, necesita central para recibir asignaciones. El token de unión no contiene la configuración de los streams.
El rechazo de node_key tampoco convierte al streamer en un miembro nuevo: informa del error y conserva la configuración aplicada. Recuperar la conexión exige la intervención del operador. Abrir otra ventana no repara un registro existente.
La caché no convierte al streamer en un plano de control independiente. Las asignaciones nuevas y los cambios esperan a que vuelva la conexión; los billetes caducan. La continuidad también depende de las fuentes, los discos y los demás streamers.
Verificar la unión¶
Después del arranque, compruebe:
- El streamer figura en el registro de central con la etiqueta esperada y el estado de conexión actual.
- El directorio persiste tras reiniciar y se reutiliza el mismo registro.
- Central alcanza la dirección API y los demás streamers alcanzan la dirección privada de entrega.
- La configuración se entrega y confirma como aplicada; el entorno no sobrescribe los valores necesarios.
- Los streams asignados funcionan y las lecturas entre servidores usan un billete vigente.
Evalúe la conexión y la aplicación de configuración por separado de los medios. El registro no garantiza una fuente accesible o un almacenamiento sano; perder central tampoco detiene inmediatamente una emisión en curso.