Plesk द्वारा तीन RIT 2018 तकनीकी रिपोर्ट

स्कोल्कोवो में आरआईटी 2018 उत्सव बड़ा और बहुत ही विविध था। मोबाइल विकास, बैकएंड, फ्रंटएंड, देवओप्स, परियोजना प्रबंधन और यहां तक ​​कि मनोविज्ञान हर स्वाद और सुबह से शाम तक व्यस्त कार्यक्रम के लिए विषय हैं। थीम को अलग ट्रैक में विभाजित किया गया है, पटरियों को हॉल से बांधा गया है। यदि केवल विशेष रिपोर्ट ही रूचि है, तो आप सही कमरे में बस सकते हैं। हालांकि, विभिन्न विषयों के वक्ताओं द्वारा आवश्यकतानुसार मुख्य हॉल का उपयोग किया गया था।

द्वारा और बड़े, मैं DevOps के ज्ञान के साथ प्रबुद्ध था, और अपने सहयोगियों के साथ सम्मेलन के अपने छापों को साझा करने के बाद, मैंने उन रिपोर्टों की एक छोटी सूची बनाई जो मुझे याद थी। कई महीने बीत गए, और मुझे अभी भी अच्छी तरह याद है कि वे किस बारे में बात कर रहे थे।

इसलिए, 3 तकनीकी रिपोर्ट जो मुझे RIT 2018 में याद हैं।

निगरानी और कुबेरनेट्स

अब उपयोग किए जाने वाले मॉनिटरिंग टूल माइक्रोसवर्क आर्किटेक्चर एप्लिकेशन का इतना अच्छा समर्थन नहीं करते हैं। सिस्टम में जितनी अधिक गतिशीलता है, उतनी ही मुश्किल इसके लिए निगरानी को कॉन्फ़िगर करना है। कुबेरनेट्स जैसे क्लस्टर सिस्टम के लिए सुविधाजनक निगरानी, ​​जो अतिवाद को गतिशीलता लाती है, आमतौर पर एक गैर-तुच्छ कार्य है। ऐसा क्यों? फ्लंट के तकनीकी निदेशक दिमित्री स्टोलारोव, इस जटिलता के कारणों और मुख्य निगरानी मिशन पर इसके प्रभाव के बारे में बात करते हैं।

पारंपरिक निगरानी प्रणाली स्थैतिक सर्वर के साथ काम करने पर निर्भर करती है, जो अपेक्षाकृत कम ही जोड़ा जाता है और अनुप्रयोग बुनियादी ढांचे से हटा दिया जाता है। कुबेरनेट्स में, चूल्हा वातावरण और सेवा अनुप्रयोगों का निर्माण और विलोपन हर सेकंड होता है, इसलिए मौजूदा स्वचालित खोज प्रक्रियाएं बस इस वॉल्यूम के साथ सामना नहीं कर सकती हैं।

स्वयं पर्यावरण की संख्या दसियों और सैकड़ों में भी है। तदनुसार, टेलीमेट्री प्रेषित की मात्रा उसी राशि से बढ़ जाती है। और उसे अभी भी कहीं संग्रहीत करने की आवश्यकता है।

एक अलग समस्या भौतिक और आभासी दुनिया की टक्कर है: कुबेरनेट्स में अनुप्रयोगों द्वारा संसाधन की खपत काफी अल्पकालिक है और यह चूल्हा पर प्रतिबंध के संदर्भ में परिलक्षित होता है। लेकिन फली संसाधन खपत पहले से ही उपलब्ध सर्वर क्षमताओं पर एक विशिष्ट शारीरिक प्रभाव है। चार्ट को देखते समय, आपको हमेशा इस बात पर विचार करना होगा कि आप संसाधनों को किस दृष्टिकोण से देखते हैं। व्यवहार में, कुछ लोग व्यक्तिगत फली में रुचि रखते हैं। ब्याज की एक पूरे के रूप में आवेदन द्वारा संसाधनों की खपत है, और यह पहले से ही उपयोगकर्ताओं द्वारा परिभाषित कुछ मानदंडों के अनुसार टेलीमेट्री पॉड्स के एक लचीले समूह की आवश्यकता है।

और आपको व्यापक देव / मंचन / ठेस वातावरण के लिए परिणामी योजना को कई बार बढ़ाने की आवश्यकता है!

रिपोर्ट की सिफारिश किसी ऐसे व्यक्ति से की जाती है जिसे कुबेरनेट क्लस्टर का समर्थन करना है।

प्रस्तुति का लिंक।

बॉक्स डेवलपमेंट देवप्स

मैक्सिम लापिशिन की रिपोर्ट को सुनना हमारे लिए बेहद दिलचस्प था, जिसमें उन्होंने बॉक्सिंग उत्पादों के विकास में देव-प्रथाओं का उपयोग करने का दुर्लभ अनुभव साझा किया। एक बॉक्सिंग उत्पाद एक ऐसा पारंपरिक सॉफ्टवेयर है जो उपयोगकर्ता की क्षमताओं को स्थापित करता है और चलाता है।

Erlyvideo एक वीडियो स्ट्रीमिंग सर्वर विकसित कर रहा है, हम एक इंटरनेट सेवा कॉन्फ़िगरेशन सर्वर हैं। हमारी समस्याएं कई मायनों में ऐसी ही हैं जिनके कारण ErOlvideo का DevOps रूपांतरण हुआ।

मैक्सिम सबसे महत्वपूर्ण सवाल के जवाब के साथ रिपोर्ट शुरू करता है: "यह सब किस लिए है?" सेवाओं के विकास में DevOps संस्कृति की शुरूआत करने वाले सभी समान कारक उन उद्योगों में भी मौजूद हैं जहां अधिक परंपरागत विकास चल रहा है। और बॉक्सिंग उत्पादों में इन कारकों का प्रभाव संभवतः एक सेवा पर काम करने की तुलना में अधिक नाटकीय होगा। उदाहरण के लिए, कम रिलीज, परिवर्तनों की अधिक से अधिक मात्रा को तैनात किया जाएगा। यदि आप एक नई सेवा शुरू कर रहे हैं, तो आप यह सुनिश्चित कर सकते हैं या बस खुद को समझा सकते हैं कि यह सुरक्षित है। लेकिन यदि आप बड़ी संख्या में परिवर्तनों के साथ उत्पाद वितरण जारी करते हैं, तो आपके लिए यह पर्याप्त नहीं है कि आप स्वयं को अपडेट की सुरक्षा प्रदान करें, आपको अपने उपयोगकर्ताओं को इसकी सुरक्षा भी समझानी होगी। परिवर्तन के छोटे लेकिन लगातार भाग यहां बचाव के लिए आते हैं। और यह सिर्फ समस्याओं में से एक है।

निरंतर डिलीवरी का उपयोग करने, समानताएं खींचने और सेवाओं के साथ सीआई / सीडी मोड में आम तौर पर सरल काम से मतभेदों पर जोर देने के लिए रिपोर्ट इस और कई अन्य कारणों से गहराई में जाती है।

यह कैसे संभव है? रिपोर्ट में, मैक्सिम ने परिवर्तनों के प्रवाह के निरंतर वितरण को वास्तविक बनाने के लिए एर्लीविडियो में प्रयुक्त प्रथाओं के सेट का वर्णन किया है। कई दृष्टिकोण उपयोगी होंगे, कुछ को हमारे काम की वास्तविकताओं के अनुकूलन की आवश्यकता होगी। लेकिन, किसी भी मामले में, यह अद्भुत सफलता की कहानी विभिन्न प्रकार की DevOps प्रथाओं में उनकी समस्याओं पर पुनर्विचार करने और समाधान खोजने के लिए प्रेरित कर सकती है।

उत्पाद वितरण पर काम करने वाले सभी लोगों के लिए रिपोर्ट देखना बहुत दिलचस्प होगा।

प्रस्तुति का लिंक।

कुबेरनेट्स नेटवर्किंग बेस

सर्वव्यापी त्वरित शुरुआत गाइड, क्रैश कोर्स और ट्यूटोरियल "कैसे कुबेरनेट्स के साथ शुरू करने के लिए" इस कार में कूदना, क्लस्टर को तैनात करना और एप्लिकेशन को तैनात करना अपेक्षाकृत आसान है। इस विषय की अविश्वसनीय लोकप्रियता को देखते हुए, कई करते हैं। लेकिन यह मत भूलो कि, संक्षेप में, कुबेरनेट्स एक जटिल प्रणाली है, जिसके रखरखाव के लिए विशिष्ट ज्ञान की आवश्यकता होती है। इनग्राम माइक्रो क्लाउड में, इस ज्ञान की आवश्यकता तब होती है जब अगला एप्लिकेशन अचानक नेटवर्क पर अनुपलब्ध हो जाता है। इस घटना की जांच से, नेटवर्क सबसिस्टम के माध्यम से अलेक्जेंडर खयोरोव की आकर्षक यात्रा शुरू हुई।

रिपोर्ट हमें कुबेरनेट्स नेटवर्क स्टैक के धीरे-धीरे अधिक जटिल तत्वों से परिचित कराती है, यह बताते हुए कि बड़े और जटिल मार्ग प्राथमिक ब्लॉकों से कैसे बने हैं। यह विशेष रूप से दिलचस्प हो जाता है जब अलेक्जेंडर के बारे में बात करता है कि यह क्यों किया जाता है, और अन्यथा नहीं, काल्पनिक अन्य कार्यान्वयन विकल्प मॉडलिंग करते हैं।

यह वास्तव में कुबेरनेट्स वर्णमाला है जो अधिकांश उपयोगकर्ता मुठभेड़ करेंगे। मैंने खुद से सवाल पूछा "क्यों नोडपॉर्ट?" और "मैं इंटरफ़ेस पर अपनी सेवा का आईपी क्यों नहीं देख रहा हूं?"

दिलचस्प और जानकारीपूर्ण।

प्रस्तुति का लिंक।