Cada elemento de ticketing.toml (opcional) también se puede pasar como variable de entorno. La prioridad es variable de entorno > ticketing.toml > valor por defecto, y las claves y valores booleanos no distinguen mayúsculas de minúsculas. La imagen de Docker se basa en scratch, por lo que inyectar la configuración mediante variables de entorno es el método por defecto (si se quiere usar un archivo de configuración, hay que montarlo e indicar la ruta con CONFIG).
| variable de entorno | valor por defecto | descripción |
|---|---|---|
PORT (SERVER_PORT) | 5225 | Puerto TCP de escucha. Se ignora en modo clúster, donde se usa el puerto de CLUSTER_SELF |
DEBUG (SERVER_DEBUG) | según el build | 1/true activa logs de debug |
SOCKET_BIND | 0.0.0.0 | Dirección de escucha |
SOCKET_NODELAY | true | TCP_NODELAY |
SOCKET_READ_BUF_LEN | 4096 | Búfer de lectura por conexión (bytes) |
SOCKET_REPLY_QUEUE | 1024 | Longitud de la cola de respuestas por conexión |
SOCKET_REPLY_BATCH | 64 | Número máximo de respuestas agrupadas en una sola escritura |
SWEEP_INTERVAL_SECS | 5 | Intervalo de limpieza de claves expiradas (segundos) |
CLUSTER_SELF | (ninguno) | Dirección anunciada de este nodo host:port. Si está presente, activa el modo clúster |
CLUSTER_PEERS | (ninguno) | Lista de direcciones de nodos (separadas por comas). El orden = prioridad de promoción, debe incluir self, mínimo 2 |
CONFIG | ./conf/ticketing.toml | Ruta del archivo de configuración |
[cluster] (ni CLUSTER_*), es un nodo único. Es lo más rápido, pero al reiniciar hay una breve interrupción y el estado, al ser en memoria, se pierde al reiniciar (lease actúa como red de seguridad).CLUSTER_PEERS (en orden de prioridad) y su propio CLUSTER_SELF apuntando a sí mismo. De entre los nodos vivos, el de mayor prioridad se convierte en activo y el resto son standbys que reciben replicación en tiempo real. Para más detalles, consulta Cómo funciona y Protocolo — servidor ↔ servidor.El despliegue en clúster de Kubernetes usa StatefulSet + servicio headless. Se hace que cada pod tenga un nombre DNS estable (
ticketing-0.ticketing…,ticketing-1.ticketing…), esos nombres se colocan enCLUSTER_PEERSen orden de prioridad, y elCLUSTER_SELFde cada pod se inyecta automáticamente mediante la downward API (metadata.name).
Ctrl+C); mediante el handoff un standby se promueve y los clientes conmutan hacia él.sarolab/ticketing · Github: saro-lab/ticketing