Cada item do ticketing.toml (opcional) também pode ser definido como variável de ambiente. A prioridade é variável de ambiente > ticketing.toml > valor padrão, e chaves e valores booleanos não diferenciam maiúsculas de minúsculas. A imagem Docker é baseada em scratch, então injetar a configuração via variáveis de ambiente é o padrão (para usar um arquivo de configuração, monte-o e informe o caminho com CONFIG).
| Variável de ambiente | Padrão | Descrição |
|---|---|---|
PORT (SERVER_PORT) | 5225 | Porta TCP de escuta. Ignorada em modo cluster, usa a porta de CLUSTER_SELF |
DEBUG (SERVER_DEBUG) | depende do build | Se 1/true, ativa log de debug |
SOCKET_BIND | 0.0.0.0 | Endereço de escuta |
SOCKET_NODELAY | true | TCP_NODELAY |
SOCKET_READ_BUF_LEN | 4096 | Buffer de leitura por conexão (bytes) |
SOCKET_REPLY_QUEUE | 1024 | Tamanho da fila de respostas por conexão |
SOCKET_REPLY_BATCH | 64 | Número máximo de respostas agrupadas em uma única escrita (write) |
SWEEP_INTERVAL_SECS | 5 | Intervalo de limpeza de chaves expiradas (segundos) |
CLUSTER_SELF | (nenhum) | Endereço anunciado deste nó, no formato host:port. Se definido, ativa o modo cluster |
CLUSTER_PEERS | (nenhum) | Lista de endereços de nós (separados por vírgula). A ordem = prioridade de promoção, deve incluir self, com 2 ou mais entradas |
CONFIG | ./conf/ticketing.toml | Caminho do arquivo de configuração |
[cluster] (ou CLUSTER_*), o nó roda isolado. É o modo mais rápido, mas há uma breve interrupção ao reiniciar, e o estado é mantido em memória, sendo perdido ao reiniciar (o lease atua como rede de segurança).CLUSTER_PEERS (na ordem de prioridade) e o seu próprio CLUSTER_SELF apontando para si mesmo. Entre os nós vivos, o de maior prioridade se torna ativo, e os demais ficam em standby recebendo replicação em tempo real. Para entender o funcionamento em detalhes, consulte Princípio de funcionamento e Protocolo — servidor ↔ servidor.A implantação em cluster no Kubernetes usa StatefulSet + serviço headless. Cada pod recebe um nome DNS estável (
ticketing-0.ticketing…,ticketing-1.ticketing…), esses nomes são colocados emCLUSTER_PEERSna ordem de prioridade, e oCLUSTER_SELFde cada pod é injetado automaticamente via downward API (metadata.name).
Ctrl+C); com isso, o handoff promove um standby e os clientes migram automaticamente.sarolab/ticketing · Github: saro-lab/ticketing