ही कथा आम्ही उत्पादन वातावरणात कंटेनर कसे वापरतो, विशेषत: कुबर्नेट्स. लेख कंटेनरमधून मेट्रिक्स आणि लॉग गोळा करण्यासाठी तसेच प्रतिमा तयार करण्यासाठी समर्पित आहे.

आम्ही फिनटेक कंपनी Exness कडून आहोत, जी B2B आणि B2C साठी ऑनलाइन ट्रेडिंग आणि फिनटेक उत्पादनांसाठी सेवा विकसित करते. आमच्या R&D मध्ये अनेक भिन्न संघ आहेत, विकास विभागात 100+ कर्मचारी आहेत.

आम्ही आमच्या डेव्हलपरसाठी कोड संकलित करण्यासाठी आणि चालवण्यासाठी प्लॅटफॉर्मसाठी जबाबदार असलेल्या टीमचे प्रतिनिधित्व करतो. विशेषतः, आम्ही ऍप्लिकेशन्समधील मेट्रिक्स, लॉग आणि इव्हेंट्स गोळा करणे, संग्रहित करणे आणि अहवाल देण्यासाठी जबाबदार आहोत. आम्ही सध्या उत्पादन वातावरणात अंदाजे तीन हजार डॉकर कंटेनर चालवतो, आमचा 50 TB मोठा डेटा स्टोरेज राखतो आणि आमच्या पायाभूत सुविधांभोवती तयार केलेली आर्किटेक्चरल सोल्यूशन्स प्रदान करतो: Kubernetes, Rancher आणि विविध सार्वजनिक क्लाउड प्रदाते. 

आमची प्रेरणा

काय जळत आहे? कोणीही उत्तर देऊ शकत नाही. चूल कुठे आहे? हे समजणे कठीण आहे. आग कधी लागली? आपण शोधू शकता, परंतु लगेच नाही. 

काही कंटेनर का उभे आहेत तर काही पडले आहेत? कोणत्या कंटेनरचा दोष होता? शेवटी, कंटेनरच्या बाहेरील बाजू समान आहेत, परंतु प्रत्येकाच्या आत स्वतःचे निओ आहे.

आमचे विकासक सक्षम लोक आहेत. ते चांगल्या सेवा देतात ज्यामुळे कंपनीला नफा मिळतो. परंतु जेव्हा अनुप्रयोगांसह कंटेनर भरकटतात तेव्हा अपयश येतात. एक कंटेनर खूप जास्त CPU वापरतो, दुसरा नेटवर्क वापरतो, तिसरा I/O ऑपरेशन वापरतो आणि चौथा सॉकेटसह काय करतो हे पूर्णपणे अस्पष्ट आहे. हे सर्व पडते आणि जहाज बुडते. 

एजंट

आत काय चालले आहे हे समजून घेण्यासाठी, आम्ही एजंटना थेट कंटेनरमध्ये ठेवण्याचा निर्णय घेतला.

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

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

एजंट्सचा अर्थ ऑपरेशन आणि देखरेखीसाठी उपयुक्तता देखील आहे ज्या वेगवेगळ्या प्रतिमांना (डेबियन, अल्पाइन, सेंटोस, इ.) सपोर्ट करणाऱ्या वेगवेगळ्या ऑर्केस्ट्रेशन सिस्टममध्ये काम करू शकतात.

शेवटी, एजंटांनी साध्या CI/CD चे समर्थन करणे आवश्यक आहे ज्यात डॉकर फाइल्स समाविष्ट आहेत. अन्यथा, जहाज खाली पडेल, कारण कंटेनर "कुटिल" रेलच्या बाजूने वितरीत करणे सुरू होईल.

प्रक्रिया आणि लक्ष्य प्रतिमा डिव्हाइस तयार करा

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

येथे कंटेनर घन रूपरेषा द्वारे दर्शविले जातात. त्याच वेळी, त्यांनी त्यांच्यामध्ये वितरण किट ठेवण्याचा निर्णय घेतला जेणेकरून "जीवन रास्पबेरीसारखे वाटू नये." हे का केले गेले, आम्ही खाली स्पष्ट करू.
 
परिणाम म्हणजे बिल्ड टूल—एक आवृत्ती-विशिष्ट कंटेनर जो विशिष्ट वितरण आवृत्त्या आणि विशिष्ट स्क्रिप्ट आवृत्त्यांचा संदर्भ देतो.

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

या दृष्टिकोनाबद्दल काय चांगले आहे? 

• प्रथम, बिल्ड टूल्सचे पूर्ण आवृत्ती नियंत्रण - कंटेनर, स्क्रिप्ट आणि वितरण आवृत्त्या तयार करा. 
• दुसरे म्हणजे, आम्ही मानकीकरण प्राप्त केले आहे: आम्ही त्याच प्रकारे टेम्पलेट्स, इंटरमीडिएट आणि वापरण्यासाठी तयार प्रतिमा तयार करतो. 
• तिसरे, कंटेनर आम्हाला पोर्टेबिलिटी देतात. आज आम्ही Gitlab वापरतो आणि उद्या आम्ही TeamCity किंवा Jenkins वर जाऊ आणि आम्ही आमचे कंटेनर त्याच प्रकारे चालवू शकू. 
• चौथे, अवलंबित्व कमी करणे. आम्ही डिस्ट्रिब्युशन किट कंटेनरमध्ये ठेवल्या हा योगायोग नव्हता, कारण यामुळे आम्हाला ते प्रत्येक वेळी इंटरनेटवरून डाउनलोड करणे टाळता येते. 
• पाचवे, बिल्डची गती वाढली आहे - प्रतिमांच्या स्थानिक प्रतींची उपस्थिती आपल्याला डाउनलोड करण्यात वेळ वाया घालवण्यास टाळण्यास अनुमती देते, कारण स्थानिक प्रतिमा आहे. 

दुसऱ्या शब्दांत, आम्ही एक नियंत्रित आणि लवचिक असेंबली प्रक्रिया साध्य केली आहे. कोणतीही पूर्ण आवृत्ती असलेले कंटेनर तयार करण्यासाठी आम्ही समान साधने वापरतो. 

आमची बिल्ड प्रक्रिया कशी कार्य करते

असेंब्ली एका कमांडसह लॉन्च केली जाते, प्रक्रिया प्रतिमेमध्ये अंमलात आणली जाते (लाल रंगात हायलाइट केलेली). डेव्हलपरकडे डॉकर फाईल आहे (पिवळ्या रंगात हायलाइट केलेली), आम्ही व्हेरिएबल्सला व्हॅल्यूजसह रेंडर करतो. आणि वाटेत आम्ही शीर्षलेख आणि तळटीप जोडतो - हे आमचे एजंट आहेत. 

शीर्षलेख संबंधित प्रतिमांमधून वितरण जोडते. आणि फूटर आमच्या सेवा आत स्थापित करते, वर्कलोड, लॉगिंग आणि इतर एजंट्सचे प्रक्षेपण कॉन्फिगर करते, एंट्रीपॉइंट बदलते इ. 

पर्यवेक्षक बसवायचा की नाही यावर आम्ही बराच वेळ विचार केला. शेवटी, आम्ही ठरवले की आम्हाला त्याची गरज आहे. आम्ही S6 निवडले. पर्यवेक्षक कंटेनर व्यवस्थापन प्रदान करतात: मुख्य प्रक्रिया क्रॅश झाल्यास आणि कंटेनर पुन्हा न बनवता त्याचे मॅन्युअल व्यवस्थापन प्रदान केल्यास आपल्याला त्यास कनेक्ट करण्याची परवानगी देते. लॉग आणि मेट्रिक्स ही कंटेनरच्या आत चालणाऱ्या प्रक्रिया आहेत. त्यांना कसेतरी नियंत्रित करणे देखील आवश्यक आहे आणि आम्ही हे पर्यवेक्षकाच्या मदतीने करतो. शेवटी, S6 हाऊसकीपिंग, सिग्नल प्रोसेसिंग आणि इतर कामांची काळजी घेते.

आम्ही विविध ऑर्केस्ट्रेशन प्रणाली वापरत असल्याने, बांधल्यानंतर आणि चालवल्यानंतर, कंटेनरने ते कोणत्या वातावरणात आहे हे समजून घेतले पाहिजे आणि परिस्थितीनुसार कार्य केले पाहिजे. उदाहरणार्थ:
हे आम्हाला एक प्रतिमा तयार करण्यास आणि ती वेगवेगळ्या ऑर्केस्ट्रेशन सिस्टममध्ये चालविण्यास अनुमती देते आणि या ऑर्केस्ट्रेशन सिस्टमची वैशिष्ट्ये लक्षात घेऊन ती लॉन्च केली जाईल.

 

त्याच कंटेनरसाठी आम्हाला डॉकर आणि कुबर्नेट्समध्ये भिन्न प्रक्रिया झाडे मिळतात:

पेलोड S6 च्या देखरेखीखाली कार्यान्वित केले जाते. कलेक्टर आणि इव्हेंट्सकडे लक्ष द्या - हे लॉग आणि मेट्रिक्ससाठी जबाबदार आमचे एजंट आहेत. कुबर्नेट्सकडे ते नाहीत, परंतु डॉकरकडे आहेत. का? 

जर आपण “पॉड” चे स्पेसिफिकेशन बघितले (यापुढे – कुबर्नेट्स पॉड), तर आपल्याला दिसेल की इव्हेंट कंटेनर पॉडमध्ये कार्यान्वित केला जातो, ज्यामध्ये स्वतंत्र कलेक्टर कंटेनर आहे जो मेट्रिक्स आणि लॉग गोळा करण्याचे कार्य करतो. आम्ही Kubernetes च्या क्षमता वापरू शकतो: कंटेनर एका पॉडमध्ये, एकाच प्रक्रियेत आणि/किंवा नेटवर्क स्पेसमध्ये चालवणे. वास्तविकपणे आपल्या एजंट्सची ओळख करून द्या आणि काही कार्ये करा. आणि जर तोच कंटेनर डॉकरमध्ये लॉन्च केला गेला असेल तर, त्यास आउटपुट सारख्याच सर्व क्षमता प्राप्त होतील, म्हणजेच, ते लॉग आणि मेट्रिक्स वितरित करण्यास सक्षम असतील, कारण एजंट्स आंतरिकरित्या लॉन्च केले जातील. 

मेट्रिक्स आणि लॉग

मेट्रिक्स आणि नोंदी वितरित करणे हे एक जटिल काम आहे. तिच्या या निर्णयाला अनेक पैलू आहेत.
पायाभूत सुविधा पेलोडच्या अंमलबजावणीसाठी तयार केल्या जातात, लॉगच्या मोठ्या प्रमाणात वितरणासाठी नाही. म्हणजेच, ही प्रक्रिया कमीतकमी कंटेनर संसाधन आवश्यकतांसह केली जाणे आवश्यक आहे. आम्ही आमच्या विकासकांना मदत करण्याचा प्रयत्न करतो: "डॉकर हब कंटेनर मिळवा, तो चालवा आणि आम्ही लॉग वितरित करू शकतो." 

दुसरा पैलू म्हणजे लॉगची मात्रा मर्यादित करणे. जर अनेक कंटेनरमध्ये लॉगच्या व्हॉल्यूममध्ये वाढ झाली (अॅप्लिकेशन लूपमध्ये स्टॅक-ट्रेस आउटपुट करते), CPU, कम्युनिकेशन चॅनेल आणि लॉग प्रोसेसिंग सिस्टमवरील भार वाढतो आणि याचा परिणाम होस्टच्या ऑपरेशनवर होतो. होस्टवर संपूर्ण आणि इतर कंटेनर, नंतर कधीकधी यामुळे होस्टचे "पडणे" होते. 

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

आणि शेवटचा पैलू म्हणजे संसाधनांचा वापर कमी करणे.

आम्ही टेलीग्राफ नावाचे ओपन-सोर्स गो सोल्यूशन निवडले. हा एक सार्वत्रिक कनेक्टर आहे जो 140 पेक्षा जास्त प्रकारच्या इनपुट चॅनेल (इनपुट प्लगइन्स) आणि 30 प्रकारच्या आउटपुट चॅनेल (आउटपुट प्लगइन्स) चे समर्थन करतो. आम्ही ते अंतिम केले आहे आणि आता आम्ही उदाहरण म्हणून Kubernetes वापरून ते कसे वापरतो ते सांगू. 

समजा डेव्हलपर वर्कलोड तैनात करतो आणि कुबर्नेट्सला पॉड तयार करण्याची विनंती प्राप्त होते. या टप्प्यावर, प्रत्येक पॉडसाठी कलेक्टर नावाचा कंटेनर स्वयंचलितपणे तयार केला जातो (आम्ही उत्परिवर्तन वेबहुक वापरतो). जिल्हाधिकारी आमचे एजंट आहेत. सुरुवातीला, हा कंटेनर प्रोमिथियस आणि लॉग संग्रह प्रणालीसह कार्य करण्यासाठी स्वतःला कॉन्फिगर करतो.

• हे करण्यासाठी, ते पॉड भाष्ये वापरते आणि त्यातील सामग्रीवर अवलंबून, प्रोमिथियस एंड पॉइंट तयार करते; 
• पॉड तपशील आणि विशिष्ट कंटेनर सेटिंग्जच्या आधारावर, लॉग कसे वितरित करायचे ते ठरवते.

आम्ही डॉकर API द्वारे लॉग संकलित करतो: विकसकांना त्यांना फक्त stdout किंवा stderr मध्ये ठेवणे आवश्यक आहे आणि जिल्हाधिकारी ते क्रमवारी लावतील. संभाव्य होस्ट ओव्हरलोड टाळण्यासाठी लॉग काही विलंबाने भागांमध्ये गोळा केले जातात. 

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

• ग्रेलॉगमध्ये लॉग उपलब्ध आहेत (दृश्य विश्लेषणासाठी);
• लॉग, मेट्रिक्स, इव्हेंट दीर्घकालीन स्टोरेजसाठी क्लिकहाऊसला पाठवले जातात.

AWS मध्ये सर्व काही अगदी सारखेच कार्य करते, फक्त आम्ही ग्रेलॉगला काफ्कासह क्लाउडवॉचसह बदलतो. आम्ही तेथे लॉग पाठवतो आणि सर्वकाही अतिशय सोयीस्कर होते: ते कोणत्या क्लस्टर आणि कंटेनरचे आहेत हे लगेच स्पष्ट होते. Google Stackdriver साठीही हेच आहे. म्हणजेच आमची योजना काफ्कासोबत आणि क्लाउडमध्ये दोन्ही ठिकाणी काम करते. 

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

त्याच प्रक्रिया कंटेनरच्या आत अंमलात आणल्या जातात, त्या S6 वापरून ऑर्केस्ट्रेटेड केल्या जातात. सर्व समान प्रक्रिया एकाच कंटेनरमध्ये चालू आहेत.

शेवटी

आम्ही लॉग आणि मेट्रिक्स संकलित आणि वितरित करण्याच्या पर्यायांसह, प्रतिमा तयार करण्यासाठी आणि लॉन्च करण्यासाठी संपूर्ण समाधान तयार केले आहे:

• आम्ही प्रतिमा एकत्रित करण्यासाठी एक प्रमाणित दृष्टीकोन विकसित केला आणि त्यावर आधारित आम्ही CI टेम्पलेट विकसित केले;
• डेटा कलेक्शन एजंट हे आमचे टेलीग्राफ विस्तार आहेत. आम्ही उत्पादनात त्यांची चांगली चाचणी केली;
• पॉड्समध्ये एजंटसह कंटेनर लागू करण्यासाठी आम्ही उत्परिवर्तन वेबहुक वापरतो; 
• Kubernetes/Rancher इकोसिस्टममध्ये समाकलित;
• आम्ही वेगवेगळ्या ऑर्केस्ट्रेशन सिस्टममध्ये समान कंटेनर कार्यान्वित करू शकतो आणि आम्हाला अपेक्षित परिणाम मिळू शकतो;
• पूर्णपणे डायनॅमिक कंटेनर व्यवस्थापन कॉन्फिगरेशन तयार केले. 

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

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