कॉन्सुलचे उदाहरण वापरून वितरित प्रणालींमध्ये सेवा शोध. अलेक्झांडर सिगाचेव्ह

मी सुचवितो की तुम्ही उदाहरण म्हणून कॉन्सुल वापरून वितरित प्रणालींमध्ये अलेक्झांडर सिगाचेव्हच्या सर्व्हिस डिस्कव्हरी अहवालाचा उतारा वाचा.

सर्व्हिस डिस्कव्हरी तयार करण्यात आली आहे जेणेकरून कमीत कमी खर्चात तुम्ही नवीन अॅप्लिकेशन आमच्या विद्यमान वातावरणाशी कनेक्ट करू शकता. सर्व्हिस डिस्कव्हरी वापरून, आम्ही डॉकर कंटेनर किंवा व्हर्च्युअल सेवा ज्या वातावरणात चालत आहे त्यापासून जास्तीत जास्त वेगळे करू शकतो.

मी सर्वांचे स्वागत करतो! मी अलेक्झांडर सिगाचेव्ह आहे, मी Inventos येथे काम करतो. आणि आज मी तुम्हाला सर्व्हिस डिस्कव्हरी सारख्या संकल्पनेची ओळख करून देईन. उदाहरण म्हणून Consul वापरून सर्व्हिस डिस्कव्हरी पाहू.

सर्व्हिस डिस्कव्हरी कोणत्या समस्या सोडवते? सर्व्हिस डिस्कव्हरी तयार करण्यात आली आहे जेणेकरून कमीत कमी खर्चात तुम्ही नवीन अॅप्लिकेशन आमच्या विद्यमान वातावरणाशी कनेक्ट करू शकता. सर्व्हिस डिस्कव्हरी वापरून, आम्ही डॉकर कंटेनर किंवा व्हर्च्युअल सेवा ज्या वातावरणात चालत आहे त्यापासून जास्तीत जास्त वेगळे करू शकतो.

ते कशासारखे दिसते? वेबवरील उत्कृष्ट उदाहरणामध्ये, हे समोरचे टोक आहे जे वापरकर्त्याची विनंती स्वीकारते. मग ते बॅकएंडवर राउट करते. या उदाहरणात, हा लोड-बॅलेंसर दोन बॅकएंड्स संतुलित करतो.

येथे आपण पाहतो की आपण अनुप्रयोगाचा तिसरा प्रसंग लॉन्च करत आहोत. त्यानुसार, जेव्हा अर्ज सुरू होतो, तेव्हा तो सर्व्हिस डिस्कवरीमध्ये नोंदणी करतो. सर्व्हिस डिस्कव्हरी लोड-बॅलेंसरला सूचित करते. लोड-बॅलेंसर आपोआप त्याचे कॉन्फिगरेशन बदलते आणि नवीन बॅकएंड कार्यान्वित केले जाते. अशा प्रकारे, बॅकएंड जोडले जाऊ शकतात, किंवा, उलट, कामातून वगळले जाऊ शकतात.

सर्व्हिस डिस्कवरीसह आणखी काय सोयीचे आहे? सर्व्हिस डिस्कव्हरी nginx कॉन्फिगरेशन, प्रमाणपत्रे आणि सक्रिय बॅकएंड सर्व्हरची सूची संग्रहित करू शकते.

सर्व्हिस डिस्कव्हरी तुम्हाला अपयश शोधण्यास आणि अपयश शोधण्यास देखील अनुमती देते. अपयश शोधण्यासाठी संभाव्य योजना कोणत्या आहेत?

• आम्ही विकसित केलेला हा ऍप्लिकेशन सर्व्हिस डिस्कवरीला आपोआप सूचित करतो की तो अजूनही कार्यरत आहे.
• सर्व्हिस डिस्कव्हरी, त्याच्या भागासाठी, उपलब्धतेसाठी अर्जाचे मतदान करते.
• किंवा आम्ही तृतीय-पक्ष स्क्रिप्ट किंवा ऍप्लिकेशन वापरतो जो आमचा ऍप्लिकेशन उपलब्धतेसाठी तपासतो आणि सर्व्हिस डिस्कवरीला सूचित करतो की सर्वकाही ठीक आहे आणि ते काम करू शकते, किंवा उलट, सर्व काही खराब आहे आणि ऍप्लिकेशनच्या या उदाहरणाला संतुलनातून वगळण्याची आवश्यकता आहे.

आम्ही कोणते सॉफ्टवेअर वापरतो त्यानुसार प्रत्येक योजना वापरली जाऊ शकते. उदाहरणार्थ, आम्ही नुकताच एक नवीन प्रकल्प विकसित करण्यास सुरुवात केली आहे, त्यानंतर जेव्हा आमचा ऍप्लिकेशन सर्व्हिस डिस्कवरीला सूचित करतो तेव्हा आम्ही सहजपणे एक योजना देऊ शकतो. किंवा आम्ही कनेक्ट करू शकतो की सर्व्हिस डिस्कव्हरी तपासत आहे.

जर आम्हाला अर्जाचा वारसा मिळाला असेल किंवा दुसर्‍याने विकसित केला असेल, तर जेव्हा आम्ही हँडलर लिहितो तेव्हा तिसरा पर्याय योग्य असतो आणि हे सर्व आपोआप आमच्या कामात येते.

हे एक उदाहरण आहे. nginx स्वरूपात लोड-बॅलेंसर रीबूट केले आहे. ही एक पर्यायी उपयुक्तता आहे जी कॉन्सुलसह प्रदान केली जाते. हे कॉन्सुल-टेम्प्लेट आहे. आम्ही नियमाचे वर्णन करतो. आम्ही म्हणतो की आम्ही टेम्प्लेट (गोलांग टेम्प्लेट इंजिन) वापरत आहोत. जेव्हा घटना घडतात, जेव्हा सूचना बदलल्या गेल्या आहेत, तेव्हा ते पुन्हा निर्माण केले जाते आणि “रीलोड” कमांड सर्व्हिस डिस्कवरीवर पाठवली जाते. सर्वात सोपा उदाहरण म्हणजे जेव्हा nginx एखाद्या इव्हेंटद्वारे पुन्हा कॉन्फिगर केले जाते आणि रीस्टार्ट केले जाते.

कॉन्सुल म्हणजे काय?

• सर्व प्रथम, ही सेवा शोध आहे.

• यात उपलब्धता तपासण्याची यंत्रणा आहे - आरोग्य तपासणी.

• यात KV स्टोअर देखील आहे.

• आणि ते मल्टी डेटासेंटर वापरण्याच्या क्षमतेवर आधारित आहे.

हे सर्व कशासाठी वापरले जाऊ शकते? केव्ही स्टोअरमध्ये आपण उदाहरण कॉन्फिग्स संचयित करू शकतो. आरोग्य तपासणी आम्ही स्थानिक सेवा तपासू शकतो आणि सूचित करू शकतो. मल्टी डेटासेंटर वापरला जातो जेणेकरून सेवा नकाशा तयार करता येईल. उदाहरणार्थ, Amazon कडे अनेक झोन आणि मार्ग रहदारी सर्वात इष्टतम मार्गाने आहे जेणेकरून डेटा सेंटर्समध्ये अनावश्यक विनंत्या नाहीत, ज्यांना स्थानिक रहदारीपासून वेगळे शुल्क आकारले जाते आणि त्यानुसार, कमी विलंब आहे.

Consul मध्ये वापरल्या जाणार्‍या संज्ञांबद्दल थोडे समजून घेऊ.

• Consul ही गो मध्ये लिहिलेली सेवा आहे. गो प्रोग्रामचा एक फायदा म्हणजे तुम्ही नुकतीच डाउनलोड केलेली 1 बायनरी फाइल. कुठूनही लाँच केले आणि तुमच्याकडे कोणतेही अवलंबित्व नाही.
• मग, की वापरून, आम्ही ही सेवा क्लायंट मोडमध्ये किंवा सर्व्हर मोडमध्ये सुरू करू शकतो.
• तसेच, “डेटासेंटर” विशेषता तुम्हाला हा सर्व्हर कोणत्या डेटा सेंटरशी संबंधित आहे हे ध्वज सेट करण्याची परवानगी देते.
• एकमत - राफ्ट प्रोटोकॉलवर आधारित. जर कोणाला स्वारस्य असेल, तर तुम्ही कॉन्सुलच्या वेबसाइटवर याबद्दल अधिक वाचू शकता. हा एक प्रोटोकॉल आहे जो तुम्हाला नेता निर्धारित करण्यास आणि कोणता पैसा वैध आणि प्रवेशयोग्य मानला जातो हे निर्धारित करण्यास अनुमती देतो.
• गॉसिप हा एक प्रोटोकॉल आहे जो नोड्समधील परस्परसंवाद सक्षम करतो. शिवाय ही व्यवस्था विकेंद्रित आहे. एका डेटा सेंटरमध्ये, सर्व नोड्स त्यांच्या शेजाऱ्यांशी संवाद साधतात. आणि, त्यानुसार, वर्तमान स्थितीबद्दलची माहिती एकमेकांना प्रसारित केली जाते. आपण असे म्हणू शकतो की ही शेजाऱ्यांमधील गप्पाटप्पा आहे.
• LAN गॉसिप – त्याच डेटा सेंटरमधील शेजार्‍यांमध्ये स्थानिक डेटा एक्सचेंज.
• WAN गॉसिप - जेव्हा आम्हाला दोन डेटा केंद्रांमधील माहिती सिंक्रोनाइझ करायची असते तेव्हा वापरली जाते. सर्व्हर म्हणून चिन्हांकित केलेल्या नोड्स दरम्यान माहिती प्रवाहित होते.
• RPC - तुम्हाला सर्व्हरवरील क्लायंटद्वारे विनंत्या अंमलात आणण्याची परवानगी देते.

RPC चे वर्णन. समजा कॉन्सुल व्हर्च्युअल मशीन किंवा फिजिकल सर्व्हरवर क्लायंट म्हणून कार्यरत आहे. आम्ही त्याच्याशी स्थानिक पातळीवर संपर्क साधतो. आणि नंतर स्थानिक क्लायंट सर्व्हरकडून माहितीची विनंती करतो आणि सिंक्रोनाइझ केला जातो. सेटिंग्जवर अवलंबून, स्थानिक कॅशेमधून माहिती पुनर्प्राप्त केली जाऊ शकते किंवा सर्व्हर मास्टरसह लीडरसह सिंक्रोनाइझ केली जाऊ शकते.

या दोन योजनांचे फायदे आणि तोटे दोन्ही आहेत. जर आपण स्थानिक कॅशेसह काम केले तर ते जलद आहे. आम्ही सर्व्हरवर साठवलेल्या डेटासह कार्य केल्यास, यास जास्त वेळ लागतो, परंतु आम्हाला अधिक संबंधित माहिती मिळते.

जर तुम्ही हे ग्राफिक पद्धतीने चित्रित केले तर हे साइटचे चित्र आहे. आम्ही पाहतो की आमच्याकडे तीन मास्टर्स धावत आहेत. एकाला नेता म्हणून तारकाने चिन्हांकित केले आहे. या उदाहरणात, तीन क्लायंट आहेत जे स्थानिक पातळीवर UDP/TCP द्वारे माहितीची देवाणघेवाण करतात. आणि डेटा केंद्रांमधील माहिती सर्व्हर दरम्यान हस्तांतरित केली जाते. येथे ग्राहक स्थानिक पातळीवर एकमेकांशी संवाद साधतात.

कॉन्सुल कोणते API प्रदान करते? माहिती मिळविण्यासाठी, Consul चे दोन प्रकारचे API आहेत.

हे DNS API आहे. डीफॉल्टनुसार, कॉन्सुल पोर्ट 8600 वर चालते. आम्ही विनंती प्रॉक्सी कॉन्फिगर करू शकतो आणि स्थानिक डीएनएसद्वारे स्थानिक रिझोल्यूशनद्वारे प्रवेश प्रदान करू शकतो. आम्ही डोमेनद्वारे क्वेरी करू शकतो आणि प्रतिसादात IP पत्ता माहिती प्राप्त करू शकतो.

HTTP API - किंवा आम्ही पोर्ट 8500 वरील विशिष्ट सेवेबद्दल स्थानिक पातळीवर माहितीची विनंती करू शकतो आणि JSON प्रतिसाद प्राप्त करू शकतो, सर्व्हरकडे कोणते IP आहे, कोणते होस्ट, कोणते पोर्ट नोंदणीकृत आहे. आणि अतिरिक्त माहिती टोकनद्वारे प्रसारित केली जाऊ शकते.

तुम्हाला कौन्सुल चालवण्याची काय गरज आहे?

पहिल्या पर्यायामध्ये, डेव्हलपर मोडमध्ये आम्ही फ्लॅग दर्शवतो की हा डेव्हलपर मोड आहे. एजंट सर्व्हर म्हणून सुरू होतो. आणि ते संपूर्ण कार्य एका मशीनवर स्वतंत्रपणे करते. पहिल्या प्रारंभासाठी सोयीस्कर, जलद आणि व्यावहारिकदृष्ट्या कोणत्याही अतिरिक्त सेटिंग्जची आवश्यकता नाही.

दुसरा मोड उत्पादन सुरू आहे. इथेच सुरुवात करणे थोडे क्लिष्ट होते. जर आमच्याकडे कन्सुलची कोणतीही आवृत्ती नसेल, तर आम्ही पहिले मशीन बूटस्ट्रॅपमध्ये आणले पाहिजे, म्हणजे हे मशीन, जे नेत्याची जबाबदारी स्वीकारेल. आम्ही ते वाढवतो, त्यानंतर आम्ही सर्व्हरचा दुसरा प्रसंग वाढवतो, आमचा मास्टर कुठे आहे याची माहिती देतो. आम्ही तिसरा वाढवतो. आमच्याकडे तीन मशीन्स आल्यावर, आम्ही ते चालू असलेल्या बूटस्ट्रॅपवरून पहिल्या मशीनवर सामान्य मोडमध्ये रीस्टार्ट करतो. डेटा सिंक्रोनाइझ केला आहे आणि प्रारंभिक क्लस्टर आधीच तयार आहे.

सर्व्हर मोडमध्ये तीन ते सात उदाहरणे चालवण्याची शिफारस केली जाते. हे या वस्तुस्थितीमुळे आहे की सर्व्हरची संख्या वाढल्यास, त्यांच्या दरम्यान माहिती सिंक्रोनाइझ करण्याची वेळ वाढते. कोरम सुनिश्चित करण्यासाठी नोड्सची संख्या विषम असणे आवश्यक आहे.

आरोग्य तपासणी कशी केली जाते? आम्ही कॉन्सुल कॉन्फिगरेशन डिरेक्टरीमध्ये जेसनच्या स्वरूपात पडताळणी नियम लिहितो. या उदाहरणातील google.com डोमेनची उपलब्धता हा पहिला पर्याय आहे. आणि आम्ही म्हणतो की ही तपासणी 30 सेकंदांच्या अंतराने करणे आवश्यक आहे. अशा प्रकारे आम्ही तपासतो की आमच्या नोडला बाह्य नेटवर्कमध्ये प्रवेश आहे.

दुसरा पर्याय म्हणजे स्वतःची तपासणी करणे. आम्ही 10 सेकंदांच्या अंतराने निर्दिष्ट पोर्टवर लोकलहोस्ट कॉल करण्यासाठी नियमित कर्ल वापरतो.

हे धनादेश सारांशित केले जातात आणि सर्व्हिस डिस्कवरीला पाठवले जातात. उपलब्धतेच्या आधारावर, हे नोड एकतर वगळलेले आहेत किंवा उपलब्ध आणि योग्यरित्या कार्यरत मशीनच्या सूचीमध्ये दिसतात.

Consul एक UI इंटरफेस देखील प्रदान करते, जो वेगळ्या ध्वजासह लॉन्च केला जातो आणि मशीनवर उपलब्ध असेल. हे तुम्हाला माहिती पाहण्याची परवानगी देते आणि तुम्ही काही बदल देखील करू शकता.

या उदाहरणात, “सेवा” टॅब उघडला आहे. तीन सेवा सुरू असल्याचे दाखवले आहे, त्यापैकी एक कॉन्सुल आहे. केलेल्या तपासण्यांची संख्या. आणि तीन डेटा सेंटर आहेत ज्यामध्ये मशीन्स आहेत.

हे नोड्स टॅबचे उदाहरण आहे. आम्ही पाहतो की त्यांच्याकडे डेटा केंद्रांचा समावेश असलेली कंपाऊंड नावे आहेत. हे देखील दर्शविते की कोणत्या सेवा चालू आहेत, म्हणजे आम्ही पाहतो की कोणतेही टॅग सेट केलेले नाहीत. हे अतिरिक्त टॅग काही माहिती देऊ शकतात ज्याचा वापर विकासक अतिरिक्त पॅरामीटर्स निर्दिष्ट करण्यासाठी करू शकतो.

आपण डिस्क्सची स्थिती आणि सरासरी लोडबद्दल कॉन्सुलला माहिती देखील पाठवू शकता.

प्रश्न

प्रश्न: आमच्याकडे डॉकर कंटेनर आहे, तो कॉन्सुलसह कसा वापरायचा?

उत्तर: डॉकर कंटेनरसाठी अनेक पद्धती आहेत. नोंदणीसाठी जबाबदार तृतीय-पक्ष डॉकर कंटेनर वापरणे हे सर्वात सामान्य आहे. स्टार्टअपवर, एक डॉकर सॉकेट त्यास दिले जाते. सर्व कंटेनर नोंदणी आणि डि-प्रकाशन इव्हेंट कॉन्सुलमध्ये रेकॉर्ड केले जातात.

प्रश्न: तर कन्सुल स्वतः डॉकर कंटेनर सुरू करतो?

उत्तर: नाही. आम्ही डॉकर कंटेनर चालवत आहोत. आणि कॉन्फिगर करताना आम्ही सूचित करतो - अशा आणि अशा सॉकेट ऐका. आम्ही प्रमाणपत्रासह कसे कार्य करतो, आमच्याकडे कोठे आणि काय आहे याची माहिती अपलोड करताना हे अंदाजे समान आहे.

प्रश्न: असे दिसून आले की डॉकर कंटेनरच्या आत आम्ही सर्व्हिस डिस्कवरीशी कनेक्ट करण्याचा प्रयत्न करीत आहोत असे काही तर्क असावे जे कॉन्सुलला डेटा पाठवू शकेल?

उत्तर: खरंच नाही. जेव्हा ते सुरू होते, तेव्हा आपण पर्यावरण व्हेरिएबलमधून व्हेरिएबल्स पास करतो. चला सेवा नाव, सेवा पोर्ट म्हणू. रजिस्टर ही माहिती ऐकते आणि कॉन्सुलमध्ये प्रवेश करते.

प्रश्न: मला UI बद्दल आणखी एक प्रश्न आहे. आम्ही UI उपयोजित केले, उदाहरणार्थ, उत्पादन सर्व्हरवर. सुरक्षेचे काय? डेटा कुठे साठवला जातो? कसा तरी डेटा जमा करणे शक्य आहे का?

उत्तरः UI मध्ये डेटाबेस आणि सर्व्हिस डिस्कवरी मधील डेटा असतो. आम्ही स्वतः सेटिंग्जमध्ये पासवर्ड सेट करतो.

प्रश्न: हे इंटरनेटवर प्रकाशित केले जाऊ शकते?

उत्तर: डीफॉल्टनुसार, कॉन्सुल लोकलहोस्टवर सुरू होते. इंटरनेटवर प्रकाशित करण्यासाठी, तुम्हाला काही प्रकारचे प्रॉक्सी स्थापित करणे आवश्यक आहे. आम्ही आमच्या स्वतःच्या सुरक्षा नियमांसाठी जबाबदार आहोत.

प्रश्न: हे बॉक्सच्या बाहेर ऐतिहासिक डेटा प्रदान करते का? आरोग्य तपासणीची आकडेवारी पाहणे मनोरंजक आहे. सर्व्हर अनेकदा अयशस्वी झाल्यास आपण समस्यांचे निदान देखील करू शकता.

उत्तर: मला खात्री नाही की तेथे चेकचे तपशील आहेत.

प्रश्नः सद्यस्थिती ही गतिमानता इतकी महत्त्वाची नाही.

उत्तरः विश्लेषणासाठी - होय.

प्रश्न: कॉन्सुल डॉकरसाठी सर्व्हिस डिस्कव्हरी न वापरणे चांगले आहे का?

उत्तरः मी ते वापरण्याची शिफारस करणार नाही. अहवालाचा उद्देश अशी संकल्पना अस्तित्वात आणणे हा आहे. ऐतिहासिकदृष्ट्या, माझ्या मते, त्याने 1ल्या आवृत्तीपर्यंत मजल मारली आहे. आता तेथे आधीच अधिक पूर्ण समाधाने आहेत, उदाहरणार्थ, कुबर्नेट्स, ज्यामध्ये हे सर्व आहे. Kubernetes सर्व्हिस डिस्कवरीचा भाग म्हणून Etcd पेक्षा कनिष्ठ आहे. पण मी कॉन्सुलशी जितका परिचित आहे तितका परिचित नाही. म्हणून, मी कॉन्सुलचा एक उदाहरण म्हणून सर्व्हिस डिस्कव्हरी करण्याचा निर्णय घेतला.

प्रश्न: लीडर सर्व्हर असलेली योजना संपूर्णपणे ऍप्लिकेशनची सुरुवात मंद करत नाही का? आणि जर हा खोटे बोलत असेल तर कॉन्सुल नवीन नेता कसा ठरवतो?

उत्तरः त्यांच्याकडे संपूर्ण प्रोटोकॉल वर्णन केले आहे. आपल्याला स्वारस्य असल्यास, आपण ते वाचू शकता.

प्रश्न: कॉन्सुल आमच्यासाठी पूर्ण वाढ झालेला सर्व्हर म्हणून काम करतो आणि सर्व विनंत्या त्याद्वारे उडतात?

उत्तर: हे पूर्ण सर्व्हर म्हणून काम करत नाही, परंतु विशिष्ट क्षेत्राचा ताबा घेते. हे सहसा service.consul सह समाप्त होते. आणि मग आपण तर्कशुद्धपणे पुढे जाऊ. आम्‍ही प्रोडक्‍शनमध्‍ये डोमेन नेम वापरत नाही, तर अंतर्गत इन्फ्रास्ट्रक्‍चर, जी सहसा सर्व्हर कॅशिंगच्‍या मागे लपलेली असते, जर आम्‍ही DNS वापरत असल्‍यास.

प्रश्न: म्हणजे, जर आपल्याला डेटाबेसमध्ये प्रवेश करायचा असेल, तर कोणत्याही परिस्थितीत आपण प्रथम हा डेटाबेस शोधण्यासाठी कॉन्सुलला खेचू, बरोबर?

उत्तर: होय. आम्ही DNS वापरून काम करत असल्यास, जेव्हा आम्ही DNS नावे वापरतो तेव्हा ते सल्लागाराशिवाय कार्य करते. सामान्यतः, आधुनिक अनुप्रयोग प्रत्येक विनंतीमध्ये डोमेन नाव खेचत नाहीत, कारण आम्ही कनेक्ट स्थापित केले आहे, सर्वकाही कार्य करते आणि नजीकच्या भविष्यात आम्ही ते व्यावहारिकपणे वापरत नाही. जर कनेक्शन तुटले असेल, तर होय, आम्ही पुन्हा विचारतो की आमचा आधार कुठे आहे आणि त्यावर जा.

hashicorp उत्पादन चॅट — Hashicorp वापरकर्ता चॅट: Consul, Nomad, Terraform

आरोग्य तपासणीबाबत पी.एस. कॉन्सुल, कुबर्नेट्स प्रमाणे, कोड स्थितीवर आधारित सेवेची टिकून राहण्याची स्थिती तपासण्यासाठी समान प्रणाली वापरते.

200 OK for healthy
503 Service Unavailable for unhealthy

स्त्रोत:
https://www.consul.io/docs/agent/checks.html
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
https://thoslin.github.io/microservice-health-check-in-kubernetes/

स्त्रोत: www.habr.com