Ticketing सर्वर डिप्लॉयमेंट
एनवायरनमेंट वेरिएबल
सर्वर कॉन्फ़िगरेशन पूरी तरह एनवायरनमेंट वेरिएबल के ज़रिए किया जाता है। कुंजियाँ केस-असंवेदनशील हैं, एक खाली मान को अनसेट माना जाता है, और फ़्लैग-शैली के मान केवल 1/true/yes/on के लिए सत्य होते हैं। Docker इमेज scratch-आधारित है, इसलिए कॉन्फ़िग बिना किसी कॉन्फ़िग फ़ाइल के, केवल एनवायरनमेंट वेरिएबल के ज़रिए इंजेक्ट किया जाता है।
| एनवायरनमेंट वेरिएबल | डिफ़ॉल्ट | विवरण |
|---|---|---|
PORT | 5225 | सिंगल मोड में लिसन पोर्ट। क्लस्टर मोड में अनदेखा किया जाता है, जहाँ इसके बजाय CLUSTER_SELF से पोर्ट लिया जाता है |
SOCKET_BIND | 0.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_VERIFY | false | पीयर सर्टिफ़िकेट सत्यापन छोड़ता है — केवल परीक्षण के लिए |
DOCKER | false | क्लस्टर मोड में आंतरिक लिसन पोर्ट को 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 नीचे)।
- पहले फॉलोवर्स को एक-एक करके रीस्टार्ट करें। एक बार रीस्टार्ट किया गया नोड प्रतिकृति या स्नैपशॉट के ज़रिए पकड़ ले, तो अगले पर जाएँ।
- अंत में, लीडर को नीचे लाएँ — 0.5-1 सेकंड के भीतर एक नया चुना जाता है, और क्लाइंट पारदर्शी रूप से स्विच हो जाते हैं।
- एक नीचे लाए गए नोड को फिर से ऊपर लाना उसे एक फॉलोवर के रूप में फिर से जोड़ देता है।
विस्तृत चरणों के लिए रोलिंग रीस्टार्ट प्रक्रिया देखें।
संदर्भ
- इमेज:
sarolab/ticketing· Github: saro-lab/ticketing - क्लाइंट (ब्रोकर) के साथ हर नोड का पता पंजीकृत करें ताकि यह स्वचालित रूप से फ़ेल ओवर हो सके। भाषा-विशिष्ट उपयोग के लिए लाइब्रेरी देखें।