Ticketing Déploiement du serveur Ticketing
Variables d'environnement
La configuration du serveur se fait entièrement via des variables d'environnement. Les clés sont insensibles à la casse, une valeur vide compte comme non définie, et les valeurs de type indicateur ne sont vraies que pour 1/true/yes/on. L'image Docker est basée sur scratch, la configuration est donc injectée uniquement via des variables d'environnement, sans fichier de configuration.
| Variable d'environnement | Par défaut | Description |
|---|---|---|
PORT | 5225 | Port d'écoute en mode simple. Ignoré en mode cluster, où le port de CLUSTER_SELF est utilisé à la place |
SOCKET_BIND | 0.0.0.0 | Adresse d'écoute |
CLIENT_TOKENS | (aucun) | Liste de jetons d'authentification client séparés par des virgules. Si non défini, un jeton vide est autorisé |
CLUSTER_SELF | (aucun) | L'adresse annoncée de ce nœud, host:port. Sa présence active le mode cluster |
CLUSTER_PEERS | (aucun) | Liste des adresses annoncées de tous les nœuds, séparées par des virgules. Exactement 3 ou 5, même ordre sur chaque nœud, doit inclure self |
CLUSTER_TOKENS | (aucun) | Liste de jetons d'authentification entre pairs séparés par des virgules |
TLS_CERT / TLS_KEY | (aucun) | Chemins des fichiers PEM du certificat/de la clé privée — définissez les deux ensemble pour activer TLS |
TLS_CA | (aucun) | CA pour vérifier les certificats des pairs — retombe sur le magasin de confiance système si non défini |
TLS_SKIP_VERIFY | false | Ignore la vérification du certificat du pair — test uniquement |
DOCKER | false | Fixe les ports d'écoute internes à 5225/6225 en mode cluster — activé par défaut dans l'image officielle |
DEBUG | selon le build | 1/true active la journalisation de débogage |
Pour les règles complètes (dérivation de port, adresses annoncées, rotation des jetons sans interruption de service, etc.), voir Configuration (variables d'environnement).
Simple vs Cluster
- Simple (1 nœud) : sans
CLUSTER_*, le nœud fonctionne de façon autonome. Le plus rapide, mais avec une brève coupure au redémarrage, et l'état est en mémoire, donc perdu au redémarrage (leaseest le filet de sécurité). - Cluster (sans interruption) : 3 ou 5 nœuds. Les nœuds partagent un état de verrou unique via le consensus Raft — seul le leader traite les requêtes, et chaque changement d'état n'est finalisé qu'après un commit majoritaire. Si le leader meurt, un nouveau est élu en 0,5 à 1 seconde, et tant qu'une majorité reste active, l'état des verrous et le service continuent de fonctionner. Voir Comment ça marche et Protocole (Cluster) pour l'explication complète.
- Chaque nœud de cluster écoute sur le port client plus un port Raft (port client + 1000) — ouvrez les deux ports dans votre pare-feu.
Les déploiements de cluster Kubernetes utilisent un StatefulSet + Service headless. Donnez à chaque pod un nom DNS stable (
ticketing-0.ticketing…,ticketing-1.ticketing…), placez ces noms dansCLUSTER_PEERS, et injectez automatiquement leCLUSTER_SELFde chaque pod via la downward API (metadata.name).
Redémarrage sans interruption (progressif)
Il n'y a qu'une règle fondamentale — une majorité doit toujours rester active (au maximum 1 nœud sur 3 arrêté à la fois).
- Redémarrez d'abord les suiveurs, un par un. Une fois qu'un nœud redémarré a rattrapé son retard via la réplication ou un snapshot, passez au suivant.
- Enfin, arrêtez le leader — un nouveau est élu en 0,5 à 1 seconde, et les clients basculent de façon transparente.
- Remonter un nœud arrêté le fait rejoindre le cluster en tant que suiveur.
Voir la Procédure de redémarrage progressif pour les étapes détaillées.
Référence
- Image :
sarolab/ticketing· Github : saro-lab/ticketing - Enregistrez toutes les adresses de nœuds auprès du client (broker) pour un basculement automatique. Voir les Bibliothèques pour l'utilisation spécifique à chaque langage.