Ticketing Despliegue del servidor Ticketing
Variables de entorno
La configuración del servidor se hace exclusivamente mediante variables de entorno. Las claves no distinguen mayúsculas de minúsculas, un valor vacío cuenta como no definido, y los valores de tipo indicador solo son verdaderos con 1/true/yes/on. La imagen de Docker se basa en scratch, así que la configuración se inyecta únicamente mediante variables de entorno, sin ningún archivo de configuración.
| Variable de entorno | Valor por defecto | Descripción |
|---|---|---|
PORT | 5225 | Puerto de escucha en modo único. Se ignora en modo clúster, donde se usa en su lugar el puerto de CLUSTER_SELF |
SOCKET_BIND | 0.0.0.0 | Dirección de escucha |
CLIENT_TOKENS | (ninguno) | Lista de tokens de autenticación de clientes separados por comas. Si no está definida, se permite un token vacío |
CLUSTER_SELF | (ninguno) | La dirección anunciada de este nodo, host:port. Su presencia activa el modo clúster |
CLUSTER_PEERS | (ninguno) | Lista separada por comas de la dirección anunciada de cada nodo. Exactamente 3 o 5, mismo orden en todos los nodos, debe incluir self |
CLUSTER_TOKENS | (ninguno) | Lista de tokens de autenticación entre pares separados por comas |
TLS_CERT / TLS_KEY | (ninguno) | Rutas a los archivos PEM del certificado y la clave privada — defínelos juntos para activar TLS |
TLS_CA | (ninguno) | CA para verificar los certificados de los pares — recurre al almacén de confianza del sistema si no está definida |
TLS_SKIP_VERIFY | false | Omite la verificación del certificado del par — solo para pruebas |
DOCKER | false | Fija los puertos de escucha internos en 5225/6225 en modo clúster — activado por defecto en la imagen oficial |
DEBUG | según la compilación | 1/true activa el registro de depuración |
Para las reglas completas (derivación de puertos, direcciones anunciadas, rotación de tokens sin tiempo de inactividad, etc.) consulta Configuración (variables de entorno).
Único vs. clúster
- Único (1 nodo): sin
CLUSTER_*, el nodo funciona de forma independiente. El más rápido, pero hay un breve corte al reiniciar, y el estado está en memoria, así que se pierde al reiniciar (leasees la red de seguridad). - Clúster (sin interrupciones): 3 o 5 nodos. Los nodos comparten un único estado de bloqueo mediante consenso Raft — solo el líder atiende las solicitudes, y cada cambio de estado solo se confirma tras un commit de mayoría. Si el líder muere, se elige uno nuevo en 0,5-1 segundo, y mientras siga viva una mayoría, el estado del bloqueo y el servicio siguen funcionando. Consulta Cómo funciona y Protocolo (clúster) para la explicación completa.
- Cada nodo del clúster escucha en el puerto de cliente además de un puerto Raft (puerto de cliente + 1000) — abre ambos puertos en tu firewall.
Los despliegues de clúster en Kubernetes usan un StatefulSet + Service headless. Dale a cada pod un nombre DNS estable (
ticketing-0.ticketing…,ticketing-1.ticketing…), pon esos nombres enCLUSTER_PEERS, e inyecta automáticamente elCLUSTER_SELFde cada pod mediante la downward API (metadata.name).
Reinicio sin interrupciones (progresivo)
Hay una regla central — siempre debe seguir viva una mayoría (como máximo 1 de 3 caído a la vez).
- Reinicia primero los seguidores, uno a uno. En cuanto un nodo reiniciado se pone al día mediante replicación o un snapshot, pasa al siguiente.
- Por último, baja el líder — se elige uno nuevo en 0,5-1 segundo, y los clientes cambian de forma transparente.
- Volver a levantar un nodo caído lo reincorpora como seguidor.
Consulta Procedimiento de reinicio progresivo para los pasos detallados.
Referencia
- Imagen:
sarolab/ticketing· Github: saro-lab/ticketing - Registra todas las direcciones de los nodos en el cliente (broker) para que el failover sea automático. Consulta Bibliotecas para el uso específico de cada lenguaje.