वर्तमान में परीक्षण चल रहा है: पूरा होने पर GitHub कोड खोला जाएगा।

Ticketing सर्वर डिप्लॉयमेंट

एनवायरनमेंट
शेल
मोड
bash
क्लाइंट कनेक्शन उदाहरण
rust
nc से त्वरित परीक्षण
bash

एनवायरनमेंट वेरिएबल

सर्वर कॉन्फ़िगरेशन पूरी तरह एनवायरनमेंट वेरिएबल के ज़रिए किया जाता है। कुंजियाँ केस-असंवेदनशील हैं, एक खाली मान को अनसेट माना जाता है, और फ़्लैग-शैली के मान केवल 1/true/yes/on के लिए सत्य होते हैं। Docker इमेज scratch-आधारित है, इसलिए कॉन्फ़िग बिना किसी कॉन्फ़िग फ़ाइल के, केवल एनवायरनमेंट वेरिएबल के ज़रिए इंजेक्ट किया जाता है।

एनवायरनमेंट वेरिएबलडिफ़ॉल्टविवरण
PORT5225सिंगल मोड में लिसन पोर्ट। क्लस्टर मोड में अनदेखा किया जाता है, जहाँ इसके बजाय CLUSTER_SELF से पोर्ट लिया जाता है
SOCKET_BIND0.0.0.0लिसन पता
CLIENT_TOKENS(कोई नहीं)क्लाइंट प्रमाणीकरण टोकन की कॉमा-सेपरेटेड सूची। यदि अनसेट है, तो एक खाली टोकन अनुमत है
CLUSTER_SELF(कोई नहीं)इस नोड का विज्ञापित पता, host:port। इसकी मौजूदगी क्लस्टर मोड सक्षम करती है
CLUSTER_PEERS(कोई नहीं)हर नोड के विज्ञापित पते की कॉमा-सेपरेटेड सूची। ठीक 3 या 5, हर नोड पर समान क्रम, self को शामिल करना आवश्यक
CLUSTER_TOKENS(कोई नहीं)पीयर-टू-पीयर प्रमाणीकरण टोकन की कॉमा-सेपरेटेड सूची
TLS_CERT / TLS_KEY(कोई नहीं)सर्टिफ़िकेट/निजी कुंजी PEM फ़ाइलों के पथ — TLS सक्षम करने के लिए दोनों को साथ सेट करें
TLS_CA(कोई नहीं)पीयर सर्टिफ़िकेट सत्यापित करने के लिए CA — यदि अनसेट है तो सिस्टम ट्रस्ट स्टोर पर वापस चला जाता है
TLS_SKIP_VERIFYfalseपीयर सर्टिफ़िकेट सत्यापन छोड़ता है — केवल परीक्षण के लिए
DOCKERfalseक्लस्टर मोड में आंतरिक लिसन पोर्ट को 5225/6225 पर स्थिर करता है — आधिकारिक इमेज में डिफ़ॉल्ट रूप से सेट
DEBUGबिल्ड पर निर्भर1/true डीबग लॉगिंग सक्षम करता है

पूरे नियमों (पोर्ट व्युत्पत्ति, विज्ञापित पते, शून्य-डाउनटाइम टोकन रोटेशन, आदि) के लिए कॉन्फ़िगरेशन (एनवायरनमेंट वेरिएबल) देखें।

सिंगल बनाम क्लस्टर

  • सिंगल (1 नोड): CLUSTER_* के बिना, नोड स्वतंत्र रूप से चलता है। सबसे तेज़, लेकिन रीस्टार्ट पर एक संक्षिप्त झटका लगता है, और स्थिति इन-मेमोरी होने के कारण रीस्टार्ट पर खो जाती है (lease ही सुरक्षा जाल है)।
  • क्लस्टर (रुकावट-रहित): 3 या 5 नोड। नोड Raft सर्वसम्मति के ज़रिए एक ही लॉक स्थिति साझा करते हैं — केवल लीडर अनुरोधों को संभालता है, और हर स्थिति परिवर्तन तभी अंतिम रूप से लागू होता है जब बहुमत कमिट कर चुका हो। यदि लीडर मर जाता है, तो 0.5-1 सेकंड के भीतर एक नया चुना जाता है, और जब तक बहुमत जीवित रहता है, लॉक स्थिति और सेवा चलती रहती है। पूरी व्याख्या के लिए यह कैसे काम करता है और प्रोटोकॉल (क्लस्टर) देखें।
  • हर क्लस्टर नोड क्लाइंट पोर्ट के साथ-साथ एक Raft पोर्ट (क्लाइंट पोर्ट + 1000) पर भी सुनता है — अपने फ़ायरवॉल में दोनों पोर्ट खोलें।

Kubernetes क्लस्टर परिनियोजन एक StatefulSet + हेडलेस सर्विस का उपयोग करते हैं। हर पॉड को एक स्थिर DNS नाम दें (ticketing-0.ticketing…, ticketing-1.ticketing…), उन नामों को CLUSTER_PEERS में डालें, और डाउनवर्ड API (metadata.name) के ज़रिए हर पॉड के CLUSTER_SELF को स्वचालित रूप से इंजेक्ट करें।

रुकावट-रहित रीस्टार्ट (रोलिंग)

इसका एक ही मूल नियम है — बहुमत हमेशा जीवित रहना चाहिए (3 में से एक समय में अधिकतम 1 नीचे)।

  1. पहले फॉलोवर्स को एक-एक करके रीस्टार्ट करें। एक बार रीस्टार्ट किया गया नोड प्रतिकृति या स्नैपशॉट के ज़रिए पकड़ ले, तो अगले पर जाएँ।
  2. अंत में, लीडर को नीचे लाएँ — 0.5-1 सेकंड के भीतर एक नया चुना जाता है, और क्लाइंट पारदर्शी रूप से स्विच हो जाते हैं।
  3. एक नीचे लाए गए नोड को फिर से ऊपर लाना उसे एक फॉलोवर के रूप में फिर से जोड़ देता है।

विस्तृत चरणों के लिए रोलिंग रीस्टार्ट प्रक्रिया देखें।

संदर्भ

  • इमेज: sarolab/ticketing · Github: saro-lab/ticketing
  • क्लाइंट (ब्रोकर) के साथ हर नोड का पता पंजीकृत करें ताकि यह स्वचालित रूप से फ़ेल ओवर हो सके। भाषा-विशिष्ट उपयोग के लिए लाइब्रेरी देखें।