Ticketing Implantação do servidor Ticketing
Variáveis de Ambiente
A configuração do servidor é feita inteiramente por variáveis de ambiente. As chaves não diferenciam maiúsculas de minúsculas, um valor vazio conta como não definido, e valores do tipo flag só são verdadeiros para 1/true/yes/on. A imagem Docker é baseada em scratch, então a configuração é injetada apenas por variáveis de ambiente, sem arquivo de configuração.
| Variável de ambiente | Padrão | Descrição |
|---|---|---|
PORT | 5225 | Porta de escuta no modo single. Ignorada no modo cluster, onde a porta de CLUSTER_SELF é usada em seu lugar |
SOCKET_BIND | 0.0.0.0 | Endereço de escuta |
CLIENT_TOKENS | (nenhum) | Lista de tokens de autenticação do cliente separada por vírgulas. Se não definida, um token vazio é permitido |
CLUSTER_SELF | (nenhum) | O endereço anunciado deste nó, host:port. Sua presença ativa o modo cluster |
CLUSTER_PEERS | (nenhum) | Lista separada por vírgulas do endereço anunciado de todo nó. Exatamente 3 ou 5, na mesma ordem em todo nó, deve incluir self |
CLUSTER_TOKENS | (nenhum) | Lista de tokens de autenticação entre pares separada por vírgulas |
TLS_CERT / TLS_KEY | (nenhum) | Caminhos para os arquivos PEM de certificado/chave privada — defina ambos juntos para ativar o TLS |
TLS_CA | (nenhum) | CA para verificar certificados de pares — recorre ao repositório de confiança do sistema se não definida |
TLS_SKIP_VERIFY | false | Pula a verificação do certificado do par — apenas para testes |
DOCKER | false | Fixa as portas de escuta internas em 5225/6225 no modo cluster — definido por padrão na imagem oficial |
DEBUG | Depende do build | 1/true ativa o log de depuração |
Para as regras completas (derivação de porta, endereços anunciados, rotação de token sem downtime etc.), veja Configuração (Variáveis de Ambiente).
Single vs. Cluster
- Single (1 nó): sem
CLUSTER_*, o nó roda de forma independente. É o mais rápido, mas há uma breve interrupção ao reiniciar, e o estado fica em memória, então se perde ao reiniciar (leaseé a rede de segurança). - Cluster (sem interrupções): 3 ou 5 nós. Os nós compartilham um único estado de lock via consenso Raft — somente o líder trata as requisições, e toda mudança de estado só é finalizada após um commit da maioria. Se o líder morre, um novo é eleito dentro de 0,5-1 segundo, e, enquanto uma maioria permanecer viva, o estado do lock e o serviço continuam funcionando. Veja Como Funciona e Protocolo (Cluster) para a explicação completa.
- Cada nó do cluster escuta na porta do cliente mais uma porta Raft (porta do cliente + 1000) — abra as duas portas no seu firewall.
As implantações de cluster no Kubernetes usam um StatefulSet + Service headless. Dê a cada pod um nome DNS estável (
ticketing-0.ticketing…,ticketing-1.ticketing…), coloque esses nomes emCLUSTER_PEERS, e injete automaticamente oCLUSTER_SELFde cada pod via downward API (metadata.name).
Reinício sem Interrupção (Rolling)
Há uma regra central — uma maioria deve sempre permanecer viva (no máximo 1 de 3 fora do ar por vez).
- Reinicie primeiro os seguidores, um de cada vez. Assim que um nó reiniciado se atualiza via replicação ou um snapshot, passe para o próximo.
- Por fim, derrube o líder — um novo é eleito dentro de 0,5-1 segundo, e os clientes trocam de forma transparente.
- Subir novamente um nó derrubado o reingressa como seguidor.
Veja Procedimento de Reinício sem Interrupção (Rolling) para os passos detalhados.
Referência
- Imagem:
sarolab/ticketing· Github: saro-lab/ticketing - Registre todo endereço de nó no cliente (broker) para que ele faça failover automaticamente. Veja Bibliotecas para o uso específico de cada linguagem.