यो कथा हामी कसरी उत्पादन वातावरणमा कन्टेनरहरू प्रयोग गर्छौं, विशेष गरी Kubernetes को बारेमा हो। लेख कन्टेनरहरूबाट मेट्रिक्स र लगहरू सङ्कलन गर्न, साथै छविहरू निर्माण गर्न समर्पित छ।

हामी फिनटेक कम्पनी Exness बाट हौं, जसले B2B र B2C का लागि अनलाइन व्यापार र फिनटेक उत्पादनहरूका लागि सेवाहरू विकास गर्छ। हाम्रो R&D सँग धेरै फरक टोलीहरू छन्, विकास विभागमा 100+ कर्मचारीहरू छन्।

हामी हाम्रो विकासकर्ताहरूको लागि कोड सङ्कलन र चलाउन प्लेटफर्मको लागि जिम्मेवार टोलीको प्रतिनिधित्व गर्छौं। विशेष गरी, हामी अनुप्रयोगहरूबाट मेट्रिक्स, लगहरू, र घटनाहरू सङ्कलन, भण्डारण र रिपोर्टिङको लागि जिम्मेवार छौं। हामी हाल उत्पादन वातावरणमा लगभग तीन हजार डकर कन्टेनरहरू सञ्चालन गर्छौं, हाम्रो 50 TB ठूलो डाटा भण्डारण कायम राख्छौं, र हाम्रो पूर्वाधारको वरिपरि निर्माण गरिएका वास्तु समाधानहरू प्रदान गर्दछौं: Kubernetes, Rancher, र विभिन्न सार्वजनिक क्लाउड प्रदायकहरू। 

हाम्रो प्रेरणा

के जलिरहेको छ? कसैले जवाफ दिन सक्दैन। चूल्हा कहाँ छ? बुझ्न गाह्रो छ। कहिले आगो लाग्यो ? तपाईंले पत्ता लगाउन सक्नुहुन्छ, तर तुरुन्तै होइन। 

किन केही कन्टेनरहरू उभिएका छन् र अरूहरू खसेका छन्? कुन कन्टेनर दोषी थियो? आखिर, कन्टेनरहरू बाहिर उस्तै छन्, तर प्रत्येक भित्र यसको आफ्नै नियो छ।

हाम्रा विकासकर्ताहरू सक्षम केटाहरू हुन्। तिनीहरू राम्रो सेवाहरू बनाउँछन् जसले कम्पनीलाई लाभ दिन्छ। तर त्यहाँ विफलताहरू छन् जब अनुप्रयोगहरू भएका कन्टेनरहरू भ्रामक हुन्छन्। एउटा कन्टेनरले धेरै CPU खपत गर्छ, अर्कोले नेटवर्क खपत गर्छ, तेस्रोले I/O सञ्चालनहरू खपत गर्छ, र चौथोले सकेटहरूसँग के गर्छ भन्ने पूर्ण रूपमा स्पष्ट छैन। यो सबै खस्छ र जहाज डुब्छ। 

एजेन्टहरू

भित्र के भइरहेको छ भनेर बुझ्न, हामीले एजेन्टहरूलाई कन्टेनरहरूमा सीधा राख्ने निर्णय गर्यौं।

यी एजेन्टहरू निषेध गर्ने कार्यक्रमहरू हुन् जसले कन्टेनरहरूलाई एकअर्कालाई नतोड्ने अवस्थामा राख्छन्। एजेन्टहरू मानकीकृत छन्, र यसले कन्टेनरहरू सेवा गर्ने मानकीकृत दृष्टिकोणको लागि अनुमति दिन्छ। 

हाम्रो अवस्थामा, एजेन्टहरूले लगहरू एक मानक ढाँचामा, ट्याग गरिएको र थ्रोटल प्रदान गर्नुपर्छ। तिनीहरूले हामीलाई मानकीकृत मेट्रिकहरू पनि उपलब्ध गराउनुपर्छ जुन व्यापार अनुप्रयोगको परिप्रेक्ष्यबाट विस्तार गर्न सकिन्छ।

एजेन्टहरूले सञ्चालन र मर्मतसम्भारका लागि उपयोगिताहरू पनि बुझाउँछन् जुन विभिन्न छविहरू (डेबियन, अल्पाइन, सेन्टोस, आदि) लाई समर्थन गर्ने विभिन्न अर्केस्ट्रेशन प्रणालीहरूमा काम गर्न सक्छन्।

अन्तमा, एजेन्टहरूले साधारण सीआई/सीडी समर्थन गर्नुपर्छ जसमा डकर फाइलहरू समावेश छन्। अन्यथा, जहाज अलग हुनेछ, किनभने कन्टेनरहरू "कुटिल" रेलहरूमा डेलिभर गर्न सुरु हुनेछ।

प्रक्रिया र लक्षित छवि उपकरण निर्माण गर्नुहोस्

सबै कुरालाई मानकीकृत र व्यवस्थित राख्नको लागि, केहि प्रकारको मानक निर्माण प्रक्रिया अनुसरण गर्न आवश्यक छ। त्यसकारण, हामीले कन्टेनरहरू द्वारा कन्टेनरहरू सङ्कलन गर्ने निर्णय गर्यौं - यो पुनरावृत्ति हो।

यहाँ कन्टेनरहरू ठोस रूपरेखाद्वारा प्रतिनिधित्व गरिन्छ। उही समयमा, तिनीहरूले तिनीहरूमा वितरण किटहरू राख्ने निर्णय गरे ताकि "जीवन रास्पबेरीजस्तो देखिदैन।" यो किन गरियो, हामी तल व्याख्या गर्नेछौं।
 
परिणाम एक निर्माण उपकरण हो - एक संस्करण-विशिष्ट कन्टेनर जसले निर्दिष्ट वितरण संस्करणहरू र विशिष्ट लिपि संस्करणहरू सन्दर्भ गर्दछ।

हामीले यसलाई कसरी प्रयोग गर्ने? हामीसँग डकर हब छ जसमा कन्टेनर समावेश छ। बाह्य निर्भरताबाट छुटकारा पाउन हामी यसलाई हाम्रो प्रणाली भित्र मिरर गर्छौं। परिणाम पहेंलोमा चिन्ह लगाइएको कन्टेनर हो। हामीले कन्टेनरमा आवश्यक पर्ने सबै वितरण र स्क्रिप्टहरू स्थापना गर्न टेम्प्लेट सिर्जना गर्छौं। त्यस पछि, हामी प्रयोग गर्नको लागि तयार छवि जम्मा गर्छौं: विकासकर्ताहरूले कोड र तिनीहरूको आफ्नै विशेष निर्भरताहरू यसमा राख्छन्। 

यो दृष्टिकोणको बारेमा के राम्रो छ? 

• पहिलो, निर्माण उपकरणहरूको पूर्ण संस्करण नियन्त्रण - कन्टेनर, स्क्रिप्ट र वितरण संस्करणहरू निर्माण गर्नुहोस्। 
• दोस्रो, हामीले मानकीकरण हासिल गरेका छौं: हामी समान रूपमा टेम्प्लेटहरू, मध्यवर्ती र प्रयोग गर्न तयार छविहरू सिर्जना गर्छौं। 
• तेस्रो, कन्टेनरहरूले हामीलाई पोर्टेबिलिटी दिन्छ। आज हामी Gitlab प्रयोग गर्छौं, र भोलि हामी TeamCity वा Jenkins मा स्विच गर्नेछौं र हामी हाम्रा कन्टेनरहरू उही तरिकामा चलाउन सक्षम हुनेछौं। 
• चौथो, निर्भरता कम गर्दै। यो कुनै संयोग थिएन कि हामीले वितरण किटहरू कन्टेनरमा राख्यौं, किनभने यसले हामीलाई प्रत्येक पटक इन्टरनेटबाट डाउनलोड गर्नबाट बच्न अनुमति दिन्छ। 
• पाँचौं, निर्माण गति बढेको छ - छविहरूको स्थानीय प्रतिलिपिहरूको उपस्थितिले तपाईंलाई डाउनलोड गर्न समय बर्बाद गर्नबाट बच्न अनुमति दिन्छ, किनकि त्यहाँ स्थानीय छवि छ। 

अर्को शब्दमा, हामीले एक नियन्त्रित र लचिलो विधानसभा प्रक्रिया हासिल गरेका छौं। हामी कुनै पनि पूर्ण संस्करण भएको कन्टेनरहरू निर्माण गर्न समान उपकरणहरू प्रयोग गर्छौं। 

हाम्रो निर्माण प्रक्रिया कसरी काम गर्दछ

विधानसभा एक आदेशको साथ सुरू गरिएको छ, प्रक्रिया छविमा कार्यान्वयन गरिएको छ (रातोमा हाइलाइट गरिएको)। विकासकर्तासँग डकर फाइल छ (पहेंलोमा हाइलाइट गरिएको), हामी यसलाई रेन्डर गर्छौं, मानहरूसँग चरहरू प्रतिस्थापन गर्दछौं। र बाटोमा हामी हेडर र फुटरहरू थप्छौं - यी हाम्रा एजेन्टहरू हुन्। 

हेडरले सम्बन्धित छविहरूबाट वितरण थप्छ। र फुटरले हाम्रा सेवाहरू भित्र स्थापना गर्दछ, कार्यभार, लगिङ र अन्य एजेन्टहरूको सुरुवात कन्फिगर गर्दछ, प्रविष्टि बिन्दुलाई प्रतिस्थापन गर्दछ, आदि। 

पर्यवेक्षक स्थापना गर्ने कि नगर्ने भनेर हामीले लामो समयदेखि सोचेका थियौं। अन्तमा, हामीले निर्णय गर्यौं कि हामीलाई उहाँको आवश्यकता छ। हामीले S6 रोज्यौं। पर्यवेक्षकले कन्टेनर व्यवस्थापन प्रदान गर्दछ: यदि मुख्य प्रक्रिया क्र्यास हुन्छ र यसलाई पुन: सिर्जना नगरी कन्टेनरको म्यानुअल व्यवस्थापन प्रदान गर्दछ भने तपाईंलाई यसमा जडान गर्न अनुमति दिन्छ। लगहरू र मेट्रिकहरू कन्टेनर भित्र चल्ने प्रक्रियाहरू हुन्। तिनीहरू पनि कुनै न कुनै रूपमा नियन्त्रण गर्न आवश्यक छ, र हामी यो एक पर्यवेक्षकको मद्दतले गर्छौं। अन्तमा, S6 ले हाउसकीपिङ, सिग्नल प्रशोधन र अन्य कार्यहरूको ख्याल राख्छ।

हामीले विभिन्न आर्केस्ट्रेशन प्रणालीहरू प्रयोग गर्ने भएकोले, निर्माण र चलाइसकेपछि, कन्टेनरले कुन वातावरणमा छ भनेर बुझ्नुपर्छ र परिस्थितिअनुसार काम गर्नुपर्छ। उदाहरणका लागि:
यसले हामीलाई एउटा छवि निर्माण गर्न र यसलाई विभिन्न अर्केस्ट्रेशन प्रणालीहरूमा चलाउन अनुमति दिन्छ, र यो अर्केस्ट्रेशन प्रणालीको विशिष्टताहरूलाई ध्यानमा राखेर सुरू गरिनेछ।

 

एउटै कन्टेनरको लागि हामीले डकर र कुबर्नेट्समा विभिन्न प्रक्रिया रूखहरू पाउँछौं:

पेलोड S6 को पर्यवेक्षण अन्तर्गत कार्यान्वयन गरिएको छ। कलेक्टर र घटनाहरूमा ध्यान दिनुहोस् - यी लगहरू र मेट्रिक्सका लागि जिम्मेवार हाम्रा एजेन्टहरू हुन्। Kubernetes सँग तिनीहरू छैन, तर डकरसँग छ। किन? 

यदि हामीले "पोड" (यसपछि - कुबर्नेट्स पोड) को विनिर्देशन हेर्छौं भने, हामी घटना कन्टेनर पोडमा कार्यान्वयन गरिएको देख्नेछौं, जसमा मेट्रिक्स र लगहरू सङ्कलन गर्ने कार्य गर्ने छुट्टै कलेक्टर कन्टेनर छ। हामी Kubernetes को क्षमताहरू प्रयोग गर्न सक्छौं: एक पोडमा कन्टेनरहरू चलाउने, एकल प्रक्रिया र/वा नेटवर्क स्पेसमा। वास्तवमा तपाईंको एजेन्टहरू परिचय दिनुहोस् र केही कार्यहरू प्रदर्शन गर्नुहोस्। र यदि उही कन्टेनर डकरमा लन्च गरिएको छ भने, यसले आउटपुटको रूपमा सबै समान क्षमताहरू प्राप्त गर्नेछ, त्यो हो, यसले लगहरू र मेट्रिक्स डेलिभर गर्न सक्षम हुनेछ, किनकि एजेन्टहरू आन्तरिक रूपमा सुरू हुनेछन्। 

मेट्रिक्स र लगहरू

मेट्रिक्स र लगहरू डेलिभर गर्नु एक जटिल कार्य हो। उनको निर्णयका विभिन्न पक्ष छन् ।
पूर्वाधार पेलोडको कार्यान्वयनको लागि बनाइएको हो, न कि लगहरूको ठूलो डेलिभरीको लागि। त्यो हो, यो प्रक्रिया न्यूनतम कन्टेनर स्रोत आवश्यकताहरु संग प्रदर्शन गर्नुपर्छ। हामी हाम्रा विकासकर्ताहरूलाई मद्दत गर्न प्रयास गर्छौं: "एक डकर हब कन्टेनर प्राप्त गर्नुहोस्, यसलाई चलाउनुहोस्, र हामी लगहरू डेलिभर गर्न सक्छौं।" 

दोस्रो पक्ष लग को मात्रा सीमित छ। यदि लगहरूको भोल्युममा वृद्धि धेरै कन्टेनरहरूमा हुन्छ (एप्लिकेसनले लुपमा स्ट्याक-ट्रेस निकाल्छ), CPU, सञ्चार च्यानलहरू, र लग प्रशोधन प्रणालीमा लोड बढ्छ, र यसले होस्टको सञ्चालनलाई असर गर्छ। सम्पूर्ण र होस्टमा अन्य कन्टेनरहरू, त्यसपछि कहिलेकाहीँ यसले होस्टको "पतन" निम्त्याउँछ। 

तेस्रो पक्ष यो हो कि बाकस बाहिर सकेसम्म धेरै मेट्रिक्स सङ्कलन विधिहरूलाई समर्थन गर्न आवश्यक छ। फाइलहरू पढ्ने र प्रोमेथियस-अन्तबिन्दुबाट एप्लिकेसन विशिष्ट प्रोटोकलहरू प्रयोग गर्न।

र अन्तिम पक्ष भनेको स्रोतको खपत कम गर्नु हो।

हामीले Telegraf भनिने खुला स्रोत गो समाधान रोज्यौं। यो एक विश्वव्यापी कनेक्टर हो जसले 140 प्रकारका इनपुट च्यानलहरू (इनपुट प्लगइनहरू) र 30 प्रकारका आउटपुट च्यानलहरू (आउटपुट प्लगइनहरू) लाई समर्थन गर्दछ। हामीले यसलाई अन्तिम रूप दिएका छौं र अब हामी तपाईंलाई उदाहरणको रूपमा Kubernetes प्रयोग गरेर यसलाई कसरी प्रयोग गर्छौं भनेर बताउनेछौं। 

मानौं एक विकासकर्ताले कामको बोझ तैनाथ गर्छ र कुबेरनेटले पोड सिर्जना गर्न अनुरोध प्राप्त गर्छ। यस बिन्दुमा, कलेक्टर भनिने कन्टेनर प्रत्येक पोडको लागि स्वचालित रूपमा सिर्जना हुन्छ (हामी उत्परिवर्तन वेबहुक प्रयोग गर्दछौं)। कलेक्टर हाम्रो एजेन्ट हो। सुरुमा, यो कन्टेनरले प्रोमेथियस र लग सङ्कलन प्रणालीसँग काम गर्न आफैलाई कन्फिगर गर्दछ।

• यो गर्नको लागि, यसले पोड एनोटेसनहरू प्रयोग गर्दछ, र यसको सामग्रीमा निर्भर गर्दै, प्रोमेथियस अन्तिम बिन्दु सिर्जना गर्दछ, भन्नुहोस्; 
• पोड विशिष्टता र विशिष्ट कन्टेनर सेटिङहरूमा आधारित, यसले लगहरू कसरी डेलिभर गर्ने भनेर निर्णय गर्दछ।

हामी Docker API मार्फत लगहरू सङ्कलन गर्छौं: विकासकर्ताहरूले तिनीहरूलाई stdout वा stderr मा राख्न आवश्यक छ, र कलेक्टरले यसलाई क्रमबद्ध गर्नेछ। लगहरू सम्भावित होस्ट ओभरलोड रोक्न केही ढिलाइको साथ टुक्राहरूमा सङ्कलन गरिन्छ। 

मेट्रिकहरू कन्टेनरहरूमा वर्कलोड उदाहरणहरू (प्रक्रियाहरू) मा सङ्कलन गरिन्छ। सबै कुरा ट्याग गरिएको छ: नेमस्पेस, मुनि, र यस्तै, र त्यसपछि प्रोमेथियस ढाँचामा रूपान्तरण गरियो - र संग्रहको लागि उपलब्ध हुन्छ (लगहरू बाहेक)। हामी काफ्कालाई लग, मेट्रिक्स र घटनाहरू पनि पठाउँछौं र थप:

• लगहरू Graylog मा उपलब्ध छन् (दृश्य विश्लेषणको लागि);
• लग, मेट्रिक्स, घटनाहरू क्लिकहाउसमा दीर्घकालीन भण्डारणको लागि पठाइन्छ।

AWS मा सबै कुरा ठ्याक्कै उस्तै काम गर्छ, केवल हामी Graylog लाई Kafka ले क्लाउडवाचसँग बदल्छौं। हामी त्यहाँ लगहरू पठाउँछौं, र सबै कुरा धेरै सुविधाजनक हुन्छ: यो तुरुन्तै स्पष्ट हुन्छ कि तिनीहरू कुन क्लस्टर र कन्टेनर हुन्। Google Stackdriver को लागी पनि यो सत्य हो। अर्थात्, हाम्रो योजनाले काफ्कासँग र क्लाउडमा दुवै काम गर्छ। 

यदि हामीसँग पोडहरूसँग Kubernetes छैन भने, योजना अलि बढी जटिल छ, तर यसले समान सिद्धान्तहरूमा काम गर्दछ।

समान प्रक्रियाहरू कन्टेनर भित्र निष्पादित हुन्छन्, तिनीहरू S6 प्रयोग गरेर अर्केस्ट्रेटेड हुन्छन्। सबै समान प्रक्रियाहरू एउटै कन्टेनर भित्र चलिरहेका छन्।

अन्त्यमा

हामीले लग र मेट्रिक्स सङ्कलन र डेलिभर गर्ने विकल्पहरूको साथ छविहरू निर्माण र सुरुवात गर्नको लागि पूर्ण समाधान सिर्जना गरेका छौं:

• हामीले छविहरू जम्मा गर्ने मानकीकृत दृष्टिकोण विकास गर्यौं, र यसको आधारमा हामीले CI टेम्प्लेटहरू विकास गर्यौं;
• डाटा सङ्कलन एजेन्टहरू हाम्रो Telegraf विस्तारहरू हुन्। हामीले तिनीहरूलाई उत्पादनमा राम्रोसँग परीक्षण गर्यौं;
• हामी पोडहरूमा एजेन्टहरूसँग कन्टेनरहरू लागू गर्न उत्परिवर्तन वेबहुक प्रयोग गर्छौं; 
• Kubernetes/Rancher इकोसिस्टममा एकीकृत;
• हामी एउटै कन्टेनरहरू विभिन्न अर्केस्ट्रेशन प्रणालीहरूमा कार्यान्वयन गर्न सक्छौं र हामीले अपेक्षा गरेको परिणाम प्राप्त गर्न सक्छौं;
• पूर्ण रूपमा गतिशील कन्टेनर व्यवस्थापन कन्फिगरेसन सिर्जना गरियो। 

सह-लेखक: इल्या प्रुडनिकोभ

स्रोत: www.habr.com