कुबेरनेट्स दुनिया पर कब्ज़ा कर लेंगे। कब और कैसे?

की पूर्व संध्या पर DevOpsConf विटाली खाबरोव साक्षात्कार दिमित्री स्टोलारोव (डिस्टोल), फ़्लैंट कंपनी के तकनीकी निदेशक और सह-संस्थापक। विटाली ने दिमित्री से पूछा कि फ़्लैंट क्या करता है, कुबेरनेट्स, पारिस्थितिकी तंत्र विकास, समर्थन के बारे में। हमने चर्चा की कि कुबेरनेट्स की आवश्यकता क्यों है और क्या इसकी बिल्कुल भी आवश्यकता है। और माइक्रोसर्विसेज, अमेज़ॅन AWS, DevOps के लिए "मैं भाग्यशाली रहूंगा" दृष्टिकोण, Kubernetes का भविष्य, क्यों, कब और कैसे यह दुनिया पर कब्ज़ा करेगा, DevOps की संभावनाएं और इंजीनियरों को इसके लिए क्या तैयारी करनी चाहिए, इसके बारे में भी सरलीकरण और तंत्रिका नेटवर्क के साथ उज्ज्वल और निकट भविष्य।

मौलिक साक्षात्कार DevOps Deflop पर पॉडकास्ट फॉर्म में सुनें - DevOps के बारे में एक रूसी भाषा का पॉडकास्ट, और नीचे टेक्स्ट संस्करण है।

यहां और नीचे वह प्रश्न पूछता है विटाली खाबरोव Express42 से इंजीनियर।

फ़्लैंट के बारे में

- नमस्ते दीमा। आप तकनीकी निदेशक हैं"फ़्लैंट” और इसके संस्थापक भी। कृपया हमें बताएं कि कंपनी क्या करती है और आप इसमें क्या हैं?

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




मैं, एक तकनीकी निदेशक और कंपनी के संस्थापकों में से एक के रूप में, पूरा दिन और रात यह पता लगाने में बिताता हूं कि उत्पादन की पहुंच कैसे बढ़ाई जाए, इसके संचालन को सरल कैसे बनाया जाए, प्रशासकों के जीवन को आसान बनाया जाए और डेवलपर्स के जीवन को और अधिक बेहतर बनाया जाए। आनंददायक.

कुबेरनेट्स के बारे में

- हाल ही में मैं "फ्लैंट" और से बहुत सारी रिपोर्टें देख रहा हूं सामग्री कुबेरनेट्स के बारे में तुम उसके पास कैसे आये?

दिमित्री: मैं पहले भी कई बार इस बारे में बात कर चुका हूं, लेकिन मुझे इसे दोहराने में कोई आपत्ति नहीं है। मुझे लगता है कि इस विषय को दोहराना सही है क्योंकि कारण और प्रभाव के बीच भ्रम है।

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

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

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

हमारे पास एक पल भी नहीं था जब हमने कुबेरनेट्स का उपयोग करने या न करने के बारे में सोचा हो। हम इसके प्रकट होने से बहुत पहले से इसकी प्रतीक्षा कर रहे थे, और हमने स्वयं इसके अनुरूप बनाने का प्रयास किया।

कुबेरनेट्स के बारे में

— क्या आप कुबेरनेट्स के विकास में सीधे तौर पर शामिल हैं?

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

— साथ ही, क्या आप अपने कई उपकरण कुबेरनेट्स के आसपास विकसित करते हैं?

दिमित्री: रणनीति यह है: हम जाते हैं और उन सभी चीजों के लिए अनुरोध खींचते हैं जो पहले से मौजूद हैं। यदि पुल अनुरोध वहां स्वीकार नहीं किए जाते हैं, तो हम बस उन्हें स्वयं फोर्क करते हैं और तब तक जीवित रहते हैं जब तक वे हमारे निर्माण के साथ स्वीकार नहीं किए जाते हैं। फिर, जब यह अपस्ट्रीम पर पहुंचता है, तो हम अपस्ट्रीम संस्करण में वापस जाते हैं।

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

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

रास्ता हमेशा इस तरह होता है: हम बहुत सावधानी से खोज करते हैं और अगर हमें रोटी की एक रोटी से ट्रॉलीबस बनाने का कोई समाधान नहीं मिलता है, तो हम अपनी खुद की रोटी और अपनी ट्रॉलीबस बनाते हैं।

फ़्लैंटा उपकरण

- मुझे पता है कि फ़्लैंट के पास अब ऐडऑन ऑपरेटर्स, शेल ऑपरेटर्स और डैप/वेर्फ़ टूल्स हैं। जैसा कि मैं समझता हूं, विभिन्न अवतारों में यह एक ही उपकरण है। मैं यह भी समझता हूं कि फ़्लॉन्ट के भीतर कई और अलग-अलग उपकरण हैं। यह सच है?

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

ढेर सारी उपयोगिताएँ! और और भी अधिक होंगे, क्योंकि इस वर्ष कई आंतरिक समाधान जारी किये जायेंगे। ऐडऑन ऑपरेटर पर आधारित बहुत बड़े ऐडऑन में से, कुबेरनेट्स के लिए ऐडऑन का एक समूह है, साथ ही सर्ट मैनेजर को ठीक से कैसे स्थापित करें - प्रमाणपत्रों के प्रबंधन के लिए एक उपकरण, प्रोमेथियस को एक्सेसरीज़ के एक समूह के साथ सही तरीके से कैसे स्थापित करें - ये लगभग बीस अलग-अलग हैं बायनेरिज़ जो डेटा निर्यात करते हैं और इसके लिए कुछ एकत्र करते हैं प्रोमेथियस के पास सबसे अद्भुत ग्राफिक्स और अलर्ट हैं। यह सब कुबेरनेट्स के ऐडऑन का एक समूह मात्र है, जिन्हें एक क्लस्टर में रखा गया है, और यह सरल से शांत, परिष्कृत, स्वचालित में बदल जाता है, जिसमें कई मुद्दों को पहले ही हल किया जा चुका है। हाँ, हम बहुत कुछ करते हैं।

पारिस्थितिकी तंत्र विकास

— मुझे ऐसा लगता है कि यह इस उपकरण के विकास और इसके उपयोग के तरीकों में एक बहुत बड़ा योगदान है। क्या आप मोटे तौर पर अनुमान लगा सकते हैं कि पारिस्थितिकी तंत्र के विकास में समान योगदान कौन देगा?

दिमित्री: रूस में, हमारे बाज़ार में काम करने वाली कंपनियों में से कोई भी इसके करीब भी नहीं है. बेशक, यह एक ज़ोरदार बयान है, क्योंकि मेल और यांडेक्स जैसे बड़े खिलाड़ी हैं - वे कुबेरनेट्स के साथ भी कुछ कर रहे हैं, लेकिन वे दुनिया भर की उन कंपनियों के योगदान के करीब भी नहीं आते हैं जो हमसे कहीं अधिक करते हैं। अगर मैं गलत नहीं हूं, तो फ़्लैंट की तुलना 80 लोगों के स्टाफ और रेड हैट से करना मुश्किल है, जिसमें अकेले प्रति कुबेरनेट्स पर 300 इंजीनियर हैं। तुलना करना कठिन है. हमारे आरएनडी विभाग में मेरे सहित 6 लोग हैं, जो हमारे सभी उपकरणों में कटौती करते हैं। 6 लोग बनाम 300 Red Hat इंजीनियर - तुलना करना कठिन है।

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

दिमित्री: यह संभवतः इंटीग्रेटर की एक विशेषता है, इसकी विशिष्टता है। हमारे पास कई परियोजनाएं हैं और हम कई अलग-अलग स्थितियां देखते हैं। हमारे लिए, अतिरिक्त मूल्य बनाने का मुख्य तरीका इन मामलों का विश्लेषण करना, समानताएं ढूंढना और उन्हें हमारे लिए जितना संभव हो उतना सस्ता बनाना है। यह कुछ ऐसा है जिस पर हम सक्रिय रूप से काम कर रहे हैं। मेरे लिए रूस और दुनिया के बारे में बात करना मुश्किल है, लेकिन हमारी कंपनी में लगभग 40 DevOps इंजीनियर हैं जो Kubernetes पर काम करते हैं। मुझे नहीं लगता कि रूस में ऐसी कई कंपनियां हैं जिनके पास तुलनीय संख्या में विशेषज्ञ हैं जो कुबेरनेट्स को समझते हैं, यदि कोई हो तो।

मैं नौकरी के शीर्षक DevOps इंजीनियर के बारे में सब कुछ समझता हूं, हर कोई सब कुछ समझता है और DevOps इंजीनियरों को DevOps इंजीनियर कहने का आदी है, हम इस पर चर्चा नहीं करेंगे। ये सभी 40 अद्भुत DevOps इंजीनियर हर दिन समस्याओं का सामना करते हैं और उन्हें हल करते हैं, हम बस इस अनुभव का विश्लेषण करते हैं और सामान्यीकरण करने का प्रयास करते हैं। हम समझते हैं कि अगर यह हमारे अंदर रहता है, तो एक या दो साल में उपकरण बेकार हो जाएगा, क्योंकि समुदाय में कहीं न कहीं एक तैयार तुला दिखाई देगा। इस अनुभव को आंतरिक रूप से संचित करने का कोई मतलब नहीं है - यह केवल ऊर्जा और समय को शून्य/शून्य में बहा रहा है। और हमें बिल्कुल भी अफ़सोस नहीं है. हम हर चीज को बहुत खुशी के साथ प्रकाशित करते हैं और समझते हैं कि इसे प्रकाशित करने, विकसित करने, बढ़ावा देने, प्रचारित करने की आवश्यकता है, ताकि लोग इसका उपयोग करें और अपना अनुभव जोड़ें - फिर सब कुछ बढ़ता है और जीवित रहता है। फिर दो साल बाद वह यंत्र कूड़े के ढेर में नहीं जाता। ताकत झोंकना जारी रखना कोई अफ़सोस की बात नहीं है, क्योंकि यह स्पष्ट है कि कोई आपके उपकरण का उपयोग कर रहा है, और दो साल बाद हर कोई इसका उपयोग कर रहा है।

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

हमने अपनी ऊर्जा खर्च की, गो में डैप को फिर से लिखा और इसे वेयरफ़ कहा। Dapp अब समर्थित नहीं है, विकसित नहीं है, कुछ नवीनतम संस्करण में चल रहा है, लेकिन शीर्ष पर एक पूर्ण अपग्रेड पथ है, और आप इसका अनुसरण कर सकते हैं।

डैप क्यों बनाया गया?

— क्या आप हमें संक्षेप में बता सकते हैं कि डैप क्यों बनाया गया, यह किन समस्याओं का समाधान करता है?

दिमित्री: पहला कारण है असेंबली. प्रारंभ में, जब डॉकर के पास मल्टी-स्टेज क्षमताएं नहीं थीं, तो हमें निर्माण में गंभीर समस्याएं थीं, और हमने अपने दम पर मल्टी-स्टेज बनाया। तब हमारे सामने छवि सफ़ाई को लेकर और भी कई समस्याएँ थीं। हर कोई जो सीआई/सीडी करता है, देर-सवेर, इस समस्या का सामना करता है कि एकत्र की गई छवियों का एक समूह है, जो आवश्यक नहीं है उसे किसी तरह साफ करना और जो आवश्यक है उसे छोड़ना आवश्यक है।

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

यह दिलचस्प है कि हम कहते हैं: "हेल्म, पैकेज इंस्टॉल करें," और जब वह जवाब देता है कि उसने इसे इंस्टॉल किया है, तो यह पता चलता है कि उसने अभी इंस्टॉलेशन शुरू किया है - उसने कुबेरनेट्स को संकेत दिया: "इस चीज़ को लॉन्च करें!", और यह शुरू हुआ या नहीं चाहे यह काम करे या नहीं, हेल्म इस मुद्दे को बिल्कुल भी हल नहीं करता है।

यह पता चला है कि हेल्म सिर्फ एक टेक्स्ट प्रीप्रोसेसर है जो डेटा को कुबेरनेट्स में लोड करता है।

लेकिन किसी भी परिनियोजन के भाग के रूप में, हम जानना चाहते हैं कि एप्लिकेशन को उत्पादन के लिए जारी किया गया है या नहीं? उत्पाद के लिए रोल आउट का मतलब है कि एप्लिकेशन वहां चला गया है, नया संस्करण तैनात किया गया है, और कम से कम यह वहां क्रैश नहीं होता है और सही ढंग से प्रतिक्रिया देता है। हेल्म किसी भी तरह से इस समस्या का समाधान नहीं करता है. इसे हल करने के लिए, आपको बहुत अधिक प्रयास करने की आवश्यकता है, क्योंकि आपको कुबेरनेट्स को रोल आउट करने और वहां क्या हो रहा है इसकी निगरानी करने का आदेश देने की आवश्यकता है - चाहे वह तैनात किया गया हो या रोल आउट किया गया हो। और तैनाती, सफाई और संयोजन से संबंधित कार्यों का एक समूह भी है।

योजनाएं

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

हमारे लिए अगला कदम है डेवलपर मित्रता में निवेश करें. किसी प्रोजेक्ट को एक उपकरण के साथ स्थानीय स्तर पर शीघ्रता से तैनात करने के लिए, इसे विकसित करें, इसे Git में धकेलें, और यह पाइपलाइनों के आधार पर चरण या परीक्षण के लिए भी रोल आउट होगा, और फिर उत्पादन में जाने के लिए उसी उपकरण का उपयोग करें। स्थानीय परिवेश से लेकर बिक्री तक बुनियादी ढांचे की यह एकता, एकीकरण, पुनरुत्पादकता हमारे लिए बहुत महत्वपूर्ण बिंदु है। लेकिन यह अभी तक वेयरफ़ में उपलब्ध नहीं है - हम बस ऐसा करने की योजना बना रहे हैं।

लेकिन डैप/वेर्फ़ का रास्ता हमेशा वही रहा है जो शुरुआत में कुबेरनेट्स के साथ था। हमने समस्याओं का सामना किया, उन्हें वर्कअराउंड का उपयोग करके हल किया - शेल का उपयोग करके, किसी भी चीज़ का उपयोग करके अपने लिए कुछ समाधान निकाले। फिर उन्होंने इस मामले में इन वर्कअराउंड को किसी तरह बायनेरिज़ में सीधा, सामान्यीकृत और समेकित करने का प्रयास किया, जिसे हम आसानी से साझा करते हैं।

इस पूरी कहानी को उपमाओं के साथ देखने का एक और तरीका है।

कुबेरनेट्स एक इंजन युक्त कार फ्रेम है। वहां कोई दरवाज़ा नहीं, कोई शीशा नहीं, कोई रेडियो नहीं, कोई क्रिसमस ट्री नहीं - कुछ भी नहीं। केवल फ्रेम और इंजन. और वहाँ हेल्म है—वह स्टीयरिंग व्हील है। बढ़िया - एक स्टीयरिंग व्हील है, लेकिन आपको स्टीयरिंग पिन, स्टीयरिंग रैक, गियरबॉक्स और पहियों की भी आवश्यकता है, और आप उनके बिना नहीं कर सकते।

वेयरफ़ के मामले में, यह कुबेरनेट्स का एक अन्य घटक है। केवल अब हमारे वेयरफ़ के अल्फा संस्करण में, उदाहरण के लिए, हेल्म को वेयरफ़ के अंदर संकलित किया गया है, क्योंकि हम इसे स्वयं करने से थक गए हैं। ऐसा करने के कई कारण हैं, मैं आपको इस बारे में विस्तार से बताऊंगा कि हमने वेयरफ़ के अंदर टिलर सहित पूरे हेल्म को एक साथ क्यों संकलित किया RIT++ की रिपोर्ट में.

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

क्या कुबेरनेट्स को बनाए रखना मुश्किल है?

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

दिमित्री: यह एक बहुत ही कठिन प्रश्न है और इसका उत्तर देने के लिए हमें यह समझने की आवश्यकता है कि समर्थन क्या है और हम कुबेरनेट्स से क्या चाहते हैं। शायद आप इसका खुलासा करेंगे?

— जहां तक ​​मुझे पता है और जैसा मैं देख रहा हूं, अब कई टीमें कुबेरनेट्स को आज़माना चाहती हैं। हर कोई अपने आप को इससे जोड़ता है, इसे अपने घुटनों पर रखता है। मुझे लगता है कि लोग हमेशा इस प्रणाली की जटिलता को नहीं समझते हैं।

दिमित्री: मै सोने के लिए जाना चाहता हूँ।

— कुबेरनेट्स को शून्य से लेना और स्थापित करना कितना मुश्किल है ताकि यह उत्पादन के लिए तैयार हो?

दिमित्री: आपके अनुसार हृदय का प्रत्यारोपण करना कितना कठिन है? मैं समझता हूं कि यह एक समझौतावादी प्रश्न है। स्केलपेल का उपयोग करना और गलती न करना उतना मुश्किल नहीं है। यदि वे आपको बताते हैं कि कहाँ काटना है और कहाँ सीना है, तो प्रक्रिया स्वयं जटिल नहीं है। समय-समय पर यह गारंटी देना कठिन है कि सब कुछ ठीक हो जाएगा।

कुबेरनेट्स को स्थापित करना और उस पर काम करना आसान है: चिक! — स्थापित, बहुत सारी स्थापना विधियाँ हैं। लेकिन जब समस्याएँ आती हैं तो क्या होता है?

सवाल हमेशा उठते हैं: हमने अभी तक क्या ध्यान नहीं दिया है? हमने अभी तक क्या नहीं किया है? कौन से लिनक्स कर्नेल पैरामीटर गलत तरीके से निर्दिष्ट किए गए थे? भगवान, क्या हमने उन्हें इंगित भी किया?! हमने कौन से कुबेरनेट्स घटक वितरित किए हैं और कौन से नहीं? हज़ारों सवाल उठते हैं और उनका जवाब देने के लिए आपको इस इंडस्ट्री में 15-20 साल गुज़ारने होंगे.

मेरे पास इस विषय पर एक हालिया उदाहरण है जो समस्या का अर्थ बता सकता है "क्या कुबेरनेट्स को बनाए रखना मुश्किल है?" कुछ समय पहले हमने कुबेरनेट्स में एक नेटवर्क के रूप में सिलियम को लागू करने की कोशिश पर गंभीरता से विचार किया था।

आइए मैं समझाता हूं कि सिलियम क्या है। कुबेरनेट्स में नेटवर्किंग सबसिस्टम के कई अलग-अलग कार्यान्वयन हैं, और उनमें से एक बहुत अच्छा है सिलियम। इसका मतलब क्या है? कर्नेल में, कुछ समय पहले कर्नेल के लिए हुक लिखना संभव हो गया, जो किसी तरह नेटवर्क सबसिस्टम और विभिन्न अन्य सबसिस्टम पर आक्रमण करता है, और आपको कर्नेल में बड़े हिस्से को बायपास करने की अनुमति देता है।

लिनक्स कर्नेल में ऐतिहासिक रूप से एक आईपी रूट, एक ओवरफिल्टर, ब्रिज और कई अलग-अलग पुराने घटक हैं जो 15, 20, 30 साल पुराने हैं। सामान्य तौर पर, वे काम करते हैं, सब कुछ बढ़िया है, लेकिन अब उन्होंने कंटेनरों को ढेर कर दिया है, और यह एक दूसरे के ऊपर 15 ईंटों के टॉवर जैसा दिखता है, और आप उस पर एक पैर पर खड़े हैं - एक अजीब एहसास। यह प्रणाली ऐतिहासिक रूप से कई बारीकियों के साथ विकसित हुई है, जैसे शरीर में अपेंडिक्स। उदाहरण के लिए, कुछ स्थितियों में प्रदर्शन संबंधी समस्याएँ होती हैं।

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

क्या हुआ? बहुत बढ़िया प्रदर्शन, बढ़िया सुविधाएँ - बिल्कुल बढ़िया! लेकिन हम इसे देखते हैं और देखते हैं कि प्रत्येक मशीन पर एक प्रोग्राम होता है जो कुबेरनेट्स एपीआई से जुड़ता है और, इस एपीआई से प्राप्त डेटा के आधार पर, सी कोड उत्पन्न करता है और बायनेरिज़ संकलित करता है जिसे यह कर्नेल में लोड करता है ताकि ये हुक काम करें कर्नेल स्थान में.

अगर कुछ गलत हो गया तो क्या होगा? हम नहीं जानते हैं। इसे समझने के लिए, आपको यह सारा कोड पढ़ना होगा, सारे तर्क समझने होंगे और यह आश्चर्यजनक है कि यह कितना कठिन है। लेकिन, दूसरी ओर, ये पुल, नेट फिल्टर, आईपी मार्ग हैं - मैंने उनके स्रोत कोड नहीं पढ़े हैं, और हमारी कंपनी में काम करने वाले 40 इंजीनियर भी हैं। हो सकता है कि कुछ हिस्से केवल कुछ ही लोग समझते हों।

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

और बेहद शानदार सिलियम 30 साल पुराना नहीं है, यह अभी तक परिपक्व नहीं हुआ है। कुबेरनेट्स में भी यही समस्या है, प्रतिलिपि। वह सिलियम बढ़िया काम करता है, वह कुबेरनेट्स बढ़िया काम करता है, लेकिन जब उत्पादन में कुछ गलत होता है, तो क्या आप गंभीर स्थिति में तुरंत समझ पाते हैं कि क्या गलत हुआ?

जब हम कहते हैं कि क्या कुबेरनेट्स को बनाए रखना मुश्किल है - नहीं, बहुत आसान है, और हाँ, अविश्वसनीय रूप से कठिन है। कुबेरनेट्स अपने आप में बहुत अच्छा काम करता है, लेकिन अरबों बारीकियों के साथ।

"मैं भाग्यशाली रहूँगा" दृष्टिकोण के बारे में

— क्या ऐसी कंपनियाँ हैं जहाँ इन बारीकियों के प्रकट होने की लगभग गारंटी है? मान लीजिए कि यांडेक्स अचानक सभी सेवाओं को कुबेरनेट्स पर स्विच कर देता है, तो वहां बहुत बड़ा भार होगा।

दिमित्री: नहीं, यह भार के बारे में बातचीत नहीं है, बल्कि सबसे सरल चीजों के बारे में है। उदाहरण के लिए, हमारे पास कुबेरनेट्स है, हमने वहां एक एप्लिकेशन तैनात किया है। आप कैसे जानते हैं कि यह काम कर रहा है? यह समझने के लिए कोई तैयार उपकरण नहीं है कि एप्लिकेशन क्रैश न हो। ऐसी कोई तैयार प्रणाली नहीं है जो अलर्ट भेजती हो; आपको इन अलर्ट और प्रत्येक शेड्यूल को कॉन्फ़िगर करने की आवश्यकता है। और हम कुबेरनेट्स को अपडेट कर रहे हैं।

मेरे पास उबंटू 16.04 है। आप कह सकते हैं कि यह पुराना संस्करण है, लेकिन हम अभी भी इस पर हैं क्योंकि यह एलटीएस है। वहाँ systemd है, जिसकी चेतावनी यह है कि यह C-समूहों को साफ़ नहीं करता है। कुबेरनेट्स पॉड्स लॉन्च करता है, सी-ग्रुप बनाता है, फिर पॉड्स हटाता है, और किसी तरह यह पता चलता है - मुझे विवरण याद नहीं है, क्षमा करें - सिस्टम स्लाइस बने हुए हैं। इससे यह तथ्य सामने आता है कि समय के साथ कोई भी कार बहुत धीमी होने लगती है। यह हाईलोड का प्रश्न भी नहीं है। यदि लगातार पॉड्स लॉन्च किए जाते हैं, उदाहरण के लिए, यदि कोई क्रॉन जॉब है जो लगातार पॉड्स उत्पन्न करता है, तो उबंटू 16.04 वाली मशीन एक सप्ताह के बाद धीमी होनी शुरू हो जाएगी। इस तथ्य के कारण लगातार उच्च लोड औसत रहेगा कि सी-समूहों का एक समूह बनाया गया है। यह एक ऐसी समस्या है जिसका सामना किसी भी व्यक्ति को करना पड़ेगा जो केवल Ubuntu 16 और Kubernetes को शीर्ष पर स्थापित करता है।

मान लीजिए कि वह किसी तरह सिस्टमडी या कुछ और अपडेट करता है, लेकिन 4.16 तक लिनक्स कर्नेल में यह और भी मजेदार है - जब आप सी-समूह हटाते हैं, तो वे कर्नेल में लीक हो जाते हैं और वास्तव में हटाए नहीं जाते हैं। इसलिए, इस मशीन पर एक महीने तक काम करने के बाद, सबसर्वर द्वारा मेमोरी पर आँकड़े देखना असंभव होगा। हम एक फ़ाइल निकालते हैं, उसे प्रोग्राम में रोल करते हैं, और एक फ़ाइल 15 सेकंड के लिए रोल करती है, क्योंकि कर्नेल को अपने भीतर एक लाख सी-समूहों की गिनती करने में बहुत लंबा समय लगता है, जो हटाए गए प्रतीत होते हैं, लेकिन नहीं - वे लीक हो रहे हैं .

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

सवाल यह है कि जब हम बर्फ पर चलते हैं तो हमें उसकी मोटाई तब तक नहीं पता चलती जब तक हम उसे पहले से नाप न लें। बहुत से लोग चलते हैं और चिंता नहीं करते, क्योंकि वे पहले भी चलते थे।

मेरे दृष्टिकोण से, किसी भी प्रणाली को संचालित करने की बारीकियां और जटिलता यह सुनिश्चित करना है कि बर्फ की मोटाई हमारी समस्याओं को हल करने के लिए पर्याप्त हो। यह इस बारे में है.

मुझे ऐसा लगता है कि आईटी में "मैं भाग्यशाली रहूँगा" दृष्टिकोण बहुत अधिक हैं। बहुत से लोग सॉफ़्टवेयर स्थापित करते हैं और सॉफ़्टवेयर लाइब्रेरी का उपयोग इस आशा में करते हैं कि वे भाग्यशाली होंगे। सामान्य तौर पर, बहुत से लोग भाग्यशाली होते हैं। शायद इसीलिए यह काम करता है।

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

दिमित्री: वस्तुत: ऐसा ही है। अपने दम पर एक छोटी सी टीम के लिए कुबेरनेट्स कहानी में शामिल होने में कई जोखिम शामिल हैं।

क्या हमें कंटेनरों की आवश्यकता है?

— क्या आप हमें बता सकते हैं कि रूस में कुबेरनेट्स कितना व्यापक है?

दिमित्री: मेरे पास यह डेटा नहीं है, और मुझे यकीन नहीं है कि किसी और के पास यह है। हम कहते हैं: "कुबेरनेट्स, कुबेरनेट्स," लेकिन इस प्रश्न को देखने का एक और तरीका है। मैं यह भी नहीं जानता कि कंटेनर कितने व्यापक हैं, लेकिन मैं इंटरनेट पर रिपोर्टों से यह आंकड़ा जानता हूं कि 70% कंटेनर कुबेरनेट्स द्वारा व्यवस्थित किए जाते हैं। यह दुनिया भर में काफी बड़े नमूने के लिए एक विश्वसनीय स्रोत था।

फिर एक और सवाल - क्या हमें कंटेनरों की ज़रूरत है? मेरी व्यक्तिगत भावना और फ़्लैंट कंपनी की समग्र स्थिति यह है कि कुबेरनेट्स एक वास्तविक मानक है।

कुबेरनेट्स के अलावा कुछ भी नहीं होगा।

यह बुनियादी ढांचा प्रबंधन के क्षेत्र में एक पूर्ण गेम-चेंजर है। बिल्कुल निरपेक्ष - बस इतना ही, अब कोई अन्सिबल, शेफ, वर्चुअल मशीन, टेराफॉर्म नहीं। मैं पुरानी सामूहिक कृषि पद्धतियों के बारे में बात नहीं कर रहा हूँ। कुबेरनेट्स अंतिम परिवर्तक है, और अब ऐसा ही होगा.

यह स्पष्ट है कि कुछ लोगों को इसे समझने में कुछ साल लग जाते हैं, और कुछ को कुछ दशक लग जाते हैं। मुझे इसमें कोई संदेह नहीं है कि कुबेरनेट्स और इस नए रूप के अलावा कुछ भी नहीं होगा: हम अब ऑपरेटिंग सिस्टम को नुकसान नहीं पहुंचाते हैं, लेकिन इसका उपयोग करते हैं कोड के रूप में बुनियादी ढांचा, केवल कोड के साथ नहीं, बल्कि yml के साथ - एक घोषणात्मक रूप से वर्णित बुनियादी ढांचा। मुझे लग रहा है कि ये हमेशा ऐसा ही रहेगा.

— अर्थात्, वे कंपनियाँ जिन्होंने अभी तक कुबेरनेट्स पर स्विच नहीं किया है, वे निश्चित रूप से इस पर स्विच कर देंगी या गुमनामी में रहेंगी। मैंने आपको सही ढंग से समझा?

दिमित्री: यह भी पूर्णतः सत्य नहीं है। उदाहरण के लिए, यदि हमारा काम DNS सर्वर चलाना है, तो इसे FreeBSD 4.10 पर चलाया जा सकता है और यह 20 वर्षों तक पूरी तरह से काम कर सकता है। बस काम करो और बस इतना ही। शायद 20 वर्षों में एक बार कुछ अद्यतन करने की आवश्यकता होगी। यदि हम उस प्रारूप में सॉफ़्टवेयर के बारे में बात कर रहे हैं जिसे हमने लॉन्च किया है और यह वास्तव में बिना किसी अपडेट के, बिना बदलाव किए कई वर्षों तक काम करता है, तो, निश्चित रूप से, वहां कोई कुबेरनेट्स नहीं होगा। वहां उसकी जरूरत नहीं है.

सीआई/सीडी से संबंधित हर चीज - जहां भी सतत वितरण की आवश्यकता है, जहां आपको संस्करण अपडेट करने, सक्रिय परिवर्तन करने की आवश्यकता है, जहां भी आपको गलती सहनशीलता बनाने की आवश्यकता है - केवल कुबेरनेट्स।

माइक्रोसर्विसेज के बारे में

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

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

उदाहरण के लिए, एक मोनोलिथ है जिसे 300 लोगों ने लिखा है, और विकास में भाग लेने वाले सभी लोग समझते हैं कि वहां समस्याएं हैं, और इसे सूक्ष्म टुकड़ों में तोड़ दिया जाना चाहिए - लगभग 10 टुकड़े, जिनमें से प्रत्येक 30 लोगों द्वारा लिखा गया है न्यूनतम संस्करण में. यह महत्वपूर्ण, आवश्यक और अच्छा है. लेकिन जब कोई स्टार्टअप हमारे पास आता है, जहां 3 बहुत अच्छे और प्रतिभाशाली लोगों ने अपने घुटनों पर 60 माइक्रोसर्विसेज लिखी हैं, तो हर बार मैं कॉर्वोलोल की तलाश करता हूं।

मुझे ऐसा लगता है कि इस बारे में पहले ही हजारों बार बात की जा चुकी है - उन्हें किसी न किसी रूप में वितरित मोनोलिथ मिला है। यह आर्थिक रूप से उचित नहीं है; सामान्य तौर पर यह बहुत कठिन है। यह सिर्फ इतना है कि मैंने इसे इतनी बार देखा है कि यह वास्तव में मुझे दुख पहुंचाता है, इसलिए मैं इसके बारे में बात करना जारी रखता हूं।

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

यहाँ यह है - या तो हम तेजी से आगे बढ़ते हैं, और कुबेरनेट्स हमें कई चीजें बहुत तेजी से और बेहतर तरीके से करने की अनुमति देता है, या हम विश्वसनीय, समय-परीक्षणित समाधानों का उपयोग करते हैं, लेकिन बहुत धीमी गति से आगे बढ़ते हैं। यह एक ऐसा विकल्प है जिसे हर कंपनी को अवश्य चुनना चाहिए। आप इसे जंगल के एक रास्ते के रूप में सोच सकते हैं - जब आप पहली बार चलते हैं, तो आपकी मुलाकात एक सांप, एक बाघ या एक पागल बिज्जू से हो सकती है, और जब आप 10 बार चल चुके होते हैं, तो आप उस रास्ते पर चल चुके होते हैं, हटा दिया जाता है शाखाएँ और चलना आसान है। हर बार रास्ता चौड़ा होता जाता है. फिर यह एक डामर सड़क है, और बाद में एक सुंदर बुलेवार्ड है।

कुबेरनेट्स अभी भी खड़ा नहीं है। प्रश्न फिर से: कुबेरनेट्स, एक ओर, 4-5 बायनेरिज़ है, दूसरी ओर, यह संपूर्ण पारिस्थितिकी तंत्र है। यह वह ऑपरेटिंग सिस्टम है जो हमारी मशीनों पर होता है। यह क्या है? उबंटू या क्यूरियोस? यह लिनक्स कर्नेल है, अतिरिक्त घटकों का एक समूह। यहां ये सब चीजें, एक जहरीले सांप को सड़क से बाहर फेंक दिया गया, वहां बाड़ लगा दी गई। कुबेरनेट्स बहुत तेज़ी से और गतिशील रूप से विकसित हो रहा है, और जोखिमों की मात्रा, अज्ञात की मात्रा हर महीने घटती जाती है और, तदनुसार, ये पैमाने पुनर्संतुलित होते हैं।

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

मैं स्टार्टअप्स और स्थापित व्यवसायों को उस आकार तक आउटसोर्सिंग की दृढ़ता से अनुशंसा करता हूं जहां आप 10 लोगों की एक टीम को संचालन के लिए समर्पित कर सकते हैं, क्योंकि अन्यथा कोई मतलब नहीं है। इसे आउटसोर्स करना निश्चित रूप से समझ में आता है।

अमेज़न और गूगल के बारे में

— क्या अमेज़न या गूगल के समाधान वाले होस्ट को आउटसोर्स माना जा सकता है?

दिमित्री: हाँ, निःसंदेह, इससे कई समस्याओं का समाधान हो जाता है। लेकिन फिर भी कुछ बारीकियाँ हैं। आपको अभी भी यह समझने की आवश्यकता है कि इसका उपयोग कैसे करना है। उदाहरण के लिए, अमेज़ॅन एडब्ल्यूएस के काम में हजारों छोटी चीजें हैं: लोड बैलेंसर को गर्म करने की आवश्यकता है या पहले से एक अनुरोध लिखा जाना चाहिए कि "दोस्तों, हमें ट्रैफ़िक मिल रहा है, हमारे लिए लोड बैलेंसर को गर्म करें!" ” आपको इन बारीकियों को जानना होगा.

जब आप ऐसे लोगों की ओर रुख करते हैं जो इसमें विशेषज्ञ हैं, तो आपको लगभग सभी सामान्य चीजें बंद मिल जाती हैं। वर्तमान में हमारे पास 40 इंजीनियर हैं, वर्ष के अंत तक संभवतः 60 होंगे - हमने निश्चित रूप से इन सभी चीजों का सामना किया है। यहां तक ​​कि अगर हमें किसी प्रोजेक्ट पर दोबारा यह समस्या आती है, तो हम तुरंत एक-दूसरे से पूछते हैं और जानते हैं कि इसे कैसे हल किया जाए।

संभवतः इसका उत्तर यह है कि, निश्चित रूप से, एक होस्ट की गई कहानी कुछ हिस्सों को आसान बना देती है। सवाल यह है कि क्या आप इन होस्टर्स पर भरोसा करने के लिए तैयार हैं और क्या वे आपकी समस्याओं का समाधान करेंगे। Amazon और Google ने अच्छा प्रदर्शन किया है। हमारे सभी मामलों के लिए - बिल्कुल। हमारे पास और कोई सकारात्मक अनुभव नहीं है. अन्य सभी बादल जिनके साथ हमने काम करने की कोशिश की, उन्होंने बहुत सारी समस्याएं पैदा कीं - एगर, और वह सब कुछ जो रूस में है, और विभिन्न कार्यान्वयन में सभी प्रकार के ओपनस्टैक: हेडस्टर, ओवरएज - जो भी आप चाहते हैं। वे सभी ऐसी समस्याएं पैदा करते हैं जिन्हें आप हल नहीं करना चाहते।

इसलिए, उत्तर हां है, लेकिन वास्तव में, बहुत अधिक परिपक्व होस्टेड समाधान नहीं हैं।

कुबेरनेट्स की आवश्यकता किसे है?

- और वैसे भी कुबेरनेट्स की जरूरत किसे है? किसे पहले से ही कुबेरनेट्स पर स्विच करना चाहिए, विशिष्ट फ्लॉन्ट क्लाइंट कौन है जो विशेष रूप से कुबेरनेट्स के लिए आता है?

दिमित्री: यह एक दिलचस्प सवाल है, क्योंकि अभी, कुबेरनेट्स की लहर पर, कई लोग हमारे पास आते हैं: "दोस्तों, हम जानते हैं कि आप कुबेरनेट्स बना रहे हैं, इसे हमारे लिए करें!" हम उन्हें उत्तर देते हैं: "सज्जनों, हम कुबेरनेट्स नहीं करते हैं, हम उत्पाद और उससे जुड़ी हर चीज़ करते हैं।" क्योंकि सभी सीआई/सीडी और इस पूरी कहानी के बिना कोई उत्पाद बनाना असंभव है। हर कोई इस विभाजन से दूर चला गया है कि हमारे यहां विकास दर विकास और फिर शोषण दर शोषण है।

हमारे ग्राहक अलग-अलग चीजों की अपेक्षा करते हैं, लेकिन हर कोई किसी अच्छे चमत्कार की प्रतीक्षा कर रहा है कि उन्हें कुछ समस्याएं हों, और अब - हॉप! - कुबेरनेट्स उन्हें हल करेंगे। लोग चमत्कारों में विश्वास करते हैं. अपने मन में वे समझते हैं कि कोई चमत्कार नहीं होगा, लेकिन अपनी आत्मा में वे आशा करते हैं कि यह कुबेरनेट्स अब हमारे लिए सब कुछ हल कर देगा, वे इसके बारे में बहुत बात करते हैं! अचानक उसे छींक आ रही है! - और एक चाँदी की गोली, छींक! - और हमारे पास 100% अपटाइम है, सभी डेवलपर्स जो कुछ भी प्राप्त करते हैं उसे 50 बार उत्पादन में जारी कर सकते हैं, और यह क्रैश नहीं होता है। सामान्य तौर पर, एक चमत्कार!

जब ऐसे लोग हमारे पास आते हैं, तो हम कहते हैं: "माफ़ करें, लेकिन चमत्कार नहीं होते।" स्वस्थ रहने के लिए, आपको अच्छा खाना और व्यायाम करना होगा। एक विश्वसनीय उत्पाद बनाने के लिए, इसे विश्वसनीय रूप से बनाने की आवश्यकता है। एक सुविधाजनक सीआई/सीडी पाने के लिए, आपको इसे इस तरह बनाना होगा। यह बहुत सारा काम है जिसे करने की जरूरत है।

इस प्रश्न का उत्तर देने के लिए कि कुबेरनेट्स की आवश्यकता किसे है, किसी को भी कुबेरनेट्स की आवश्यकता नहीं है।

कुछ लोगों को यह ग़लतफ़हमी है कि उन्हें Kubernetes की आवश्यकता है। लोगों को बुनियादी ढांचे की सभी समस्याओं और अपने एप्लिकेशन चलाने की समस्याओं के बारे में सोचना, अध्ययन करना, दिलचस्पी लेना बंद करने की जरूरत है, उन्हें इसकी गहरी जरूरत है। वे चाहते हैं कि एप्लिकेशन केवल काम करें और आसानी से तैनात हों। उनके लिए, कुबेरनेट्स आशा है कि वे यह कहानी सुनना बंद कर देंगे कि "हम वहां पड़े थे," या "हम बाहर नहीं निकल सकते," या जो भी हो।

तकनीकी निदेशक आमतौर पर हमारे पास आते हैं। वे उससे दो बातें पूछते हैं: एक ओर, हमें सुविधाएँ दें, दूसरी ओर, स्थिरता। हमारा सुझाव है कि इसे अपने ऊपर लें और ऐसा करें। अच्छी बात यह है कि आप इन समस्याओं के बारे में सोचना और समय बर्बाद करना बंद कर दें। आपके पास विशेष लोग होंगे जो इस मुद्दे को बंद कर देंगे।

यह शब्द कि हमें या किसी और को कुबेरनेट्स की आवश्यकता है, गलत है।

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

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

अंतिम उत्तर है: आपको कुबेरनेट्स की आवश्यकता नहीं है। आपको अपनी समस्याओं का समाधान करना होगा.

आप क्या हासिल कर सकते हैं:

• उत्पाद गिरता नहीं है;
• अगर वह गिरने की कोशिश भी करता है, तो हमें इसके बारे में पहले से पता होता है, और हम वहां कुछ डाल सकते हैं;
• हम इसे उस गति से बदल सकते हैं जिस गति से हमारे व्यवसाय को इसकी आवश्यकता है, और हम इसे आसानी से कर सकते हैं; इससे हमें कोई समस्या नहीं होती है।

दो वास्तविक ज़रूरतें हैं: विश्वसनीयता और गतिशील/लचीला रोलआउट। हर कोई जो वर्तमान में किसी प्रकार की आईटी परियोजनाएं कर रहा है, चाहे वह किसी भी व्यवसाय में हो - दुनिया को आसान बनाने के लिए नरम, और जो इसे समझता है, उसे इन जरूरतों को हल करने की जरूरत है। सही दृष्टिकोण, सही समझ और पर्याप्त अनुभव के साथ कुबेरनेट्स उन्हें हल करने की अनुमति देता है।

सर्वर रहित के बारे में

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

दिमित्री: यहां हमें फिर से एक टिप्पणी करने की जरूरत है कि मैं कोई भविष्यवक्ता नहीं हूं जो आगे देखकर कहता है, "ऐसा ही होगा!" हालाँकि मैंने बस वही काम किया। मैं अपने पैरों को देखता हूं और वहां ढेर सारी समस्याएं देखता हूं, उदाहरण के लिए, कंप्यूटर में ट्रांजिस्टर कैसे काम करते हैं। यह मज़ेदार है, है ना? हमें सीपीयू में कुछ बग का सामना करना पड़ रहा है।

पारिस्थितिकी तंत्र की सभी समस्याओं का समाधान करते हुए सर्वर रहित को काफी विश्वसनीय, सस्ता, कुशल और सुविधाजनक बनाएं। यहां मैं एलोन मस्क से सहमत हूं कि मानवता के लिए लचीलापन बनाने के लिए एक दूसरे ग्रह की आवश्यकता है। हालाँकि मुझे नहीं पता कि वह क्या कह रहा है, मैं समझता हूँ कि मैं स्वयं मंगल ग्रह पर उड़ान भरने के लिए तैयार नहीं हूँ और यह कल नहीं होगा।

सर्वर रहित होने से यह स्पष्ट है कि यह वैचारिक रूप से सही बात है, मानवता के लिए दोष सहनशीलता की तरह - दो ग्रहों का होना एक से बेहतर है। लेकिन अब हम ऐसा कैसे कर सकते हैं? यदि आप अपने प्रयासों पर ध्यान केंद्रित करते हैं तो एक अभियान भेजना कोई समस्या नहीं है। मुझे लगता है कि कई अभियान भेजना और कई हजार लोगों को वहां बसाना भी यथार्थवादी है। लेकिन इसे पूरी तरह से दोष-सहिष्णु बनाना ताकि आधी मानवता वहां रह सके, यह अब मुझे असंभव लगता है, इस पर विचार नहीं किया जाता है।

सर्वर रहित वन ऑन वन के साथ: बात अच्छी है, लेकिन यह 2019 की समस्याओं से बहुत दूर है। 2030 के करीब - आइए इसे देखने के लिए जीवित रहें। मुझे इसमें कोई संदेह नहीं है कि हम जीवित रहेंगे, हम निश्चित रूप से जीवित रहेंगे (बिस्तर पर जाने से पहले दोहराएं), लेकिन अब हमें अन्य समस्याओं को हल करने की जरूरत है। यह परी कथा टट्टू इंद्रधनुष पर विश्वास करने जैसा है। हां, कुछ प्रतिशत मामले हल हो जाते हैं, और वे पूरी तरह से हल हो जाते हैं, लेकिन व्यक्तिपरक रूप से, सर्वर रहित एक इंद्रधनुष है... मेरे लिए, यह विषय बहुत दूर और बहुत समझ से बाहर है। मैं बात करने को तैयार नहीं हूं. 2019 में, आप सर्वर रहित एक भी एप्लिकेशन नहीं लिख सकते।

कुबेरनेट्स कैसे विकसित होंगे

- जैसे-जैसे हम इस संभावित अद्भुत दूर के भविष्य की ओर बढ़ रहे हैं, आपको क्या लगता है कि कुबेरनेट्स और इसके आसपास का पारिस्थितिकी तंत्र कैसे विकसित होगा?

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

संक्षेप में, स्टेटफुल को बहुत मजबूती से विकसित होना चाहिए - और होगा - क्योंकि हमारे सभी एप्लिकेशन स्टेटस स्टोर करते हैं; कोई स्टेटलेस एप्लिकेशन नहीं हैं। यह एक भ्रम है; आपको हमेशा किसी प्रकार के डेटाबेस और कुछ और की आवश्यकता होती है। स्टेटफुल हर संभव चीज़ को सीधा करने, सभी बगों को ठीक करने, उन सभी समस्याओं को सुधारने के बारे में है जिनका लोग वर्तमान में सामना कर रहे हैं - आइए इसे अपनाना कहें।

अज्ञात का स्तर, अनसुलझी समस्याओं का स्तर, किसी चीज़ का सामना करने की संभावना का स्तर काफी कम हो जाएगा। यह एक महत्वपूर्ण कहानी है. और ऑपरेटर - एक आसान सेवा प्राप्त करने के लिए प्रशासन तर्क, नियंत्रण तर्क के संहिताकरण से संबंधित सब कुछ: MySQL आसान सेवा, RabbitMQ आसान सेवा, मेमकैच आसान सेवा - सामान्य तौर पर, ये सभी घटक जिन्हें हमें काम करने की गारंटी देने की आवश्यकता है डिब्बा। यह केवल उस दर्द को हल करता है कि हम एक डेटाबेस चाहते हैं, लेकिन इसे प्रशासित नहीं करना चाहते हैं, या कुबेरनेट्स चाहते हैं, लेकिन इसे प्रशासित नहीं करना चाहते हैं।

किसी न किसी रूप में ऑपरेटर विकास की यह कहानी अगले कुछ वर्षों में महत्वपूर्ण होगी।

मुझे लगता है कि उपयोग में आसानी बहुत बढ़नी चाहिए - बॉक्स अधिक से अधिक काला, अधिक से अधिक विश्वसनीय, अधिक से अधिक सरल नॉब वाला हो जाएगा।

मैंने एक बार यूट्यूब पर सैटरडे नाइट लाइव शो में इसहाक असिमोव के साथ 80 के दशक का एक पुराना साक्षात्कार सुना था - उर्जेंट जैसा कार्यक्रम, केवल दिलचस्प। उन्होंने उनसे कंप्यूटर के भविष्य के बारे में पूछा। उन्होंने कहा कि भविष्य सादगी में है, जैसे रेडियो के साथ था। रेडियो रिसीवर मूलतः एक जटिल चीज़ थी। एक तरंग को पकड़ने के लिए, आपको 15 मिनट तक घुंडी घुमानी होगी, सींकों को घुमाना होगा और आम तौर पर यह जानना होगा कि सब कुछ कैसे काम करता है, रेडियो तरंग संचरण की भौतिकी को समझना होगा। परिणामस्वरूप, रेडियो में केवल एक नॉब बचा था।

अब 2019 में कौन सा रेडियो है? कार में, रेडियो रिसीवर सभी तरंगों और स्टेशनों के नाम ढूंढ लेता है। प्रक्रिया की भौतिकी 100 वर्षों में नहीं बदली है, लेकिन उपयोग में आसानी हुई है। अब, और केवल अभी ही नहीं, पहले से ही 1980 में, जब अज़ीमोव के साथ एक साक्षात्कार हुआ था, सभी ने रेडियो का उपयोग किया था और किसी ने भी नहीं सोचा था कि यह कैसे काम करता है। यह हमेशा काम करता है—यह एक प्रदत्त बात है।

असिमोव ने तब कहा कि कंप्यूटर के साथ भी ऐसा ही होगा। उपयोग में आसानी बढ़ेगी. यदि 1980 में आपको कंप्यूटर पर बटन दबाने के लिए विशेष शिक्षा प्राप्त करने की आवश्यकता होगी, तो भविष्य में ऐसा नहीं होगा।

मुझे लगता है कि कुबेरनेट्स और बुनियादी ढांचे के साथ उपयोग में आसानी में भी भारी वृद्धि होगी। यह, मेरी राय में, स्पष्ट है - यह सतह पर है।

इंजीनियरों का क्या करें?

— तो फिर कुबेरनेट्स का समर्थन करने वाले इंजीनियरों और सिस्टम प्रशासकों का क्या होगा?

दिमित्री: 1सी के आगमन के बाद अकाउंटेंट का क्या हुआ? उसी के बारे में। इससे पहले वे कागजों पर गिनती करते थे - अब एक कार्यक्रम में। श्रम उत्पादकता में परिमाण के क्रम में वृद्धि हुई है, लेकिन श्रम स्वयं गायब नहीं हुआ है। यदि पहले एक प्रकाश बल्ब को पेंच करने में 10 इंजीनियरों की आवश्यकता होती थी, तो अब एक ही पर्याप्त होगा।

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

लेकिन निर्णय अभी भी किसी को लेना होगा। स्पष्ट है कि इस व्यक्ति की योग्यता एवं विशेषज्ञता का स्तर ऊँचा है। आजकल, लेखांकन विभाग में, आपको किताबें रखने के लिए 10 कर्मचारियों की आवश्यकता नहीं होती है ताकि उनके हाथ थक न जाएँ। यह बिल्कुल जरूरी नहीं है. कई दस्तावेज़ इलेक्ट्रॉनिक दस्तावेज़ प्रबंधन प्रणाली द्वारा स्वचालित रूप से स्कैन और पहचाने जाते हैं। एक स्मार्ट मुख्य लेखाकार ही काफी है, जिसके पास पहले से ही बहुत अधिक कौशल और अच्छी समझ है।

सामान्यतः सभी उद्योगों में यही तरीका है। कारों के साथ भी ऐसा ही है: पहले, एक कार एक मैकेनिक और तीन ड्राइवरों के साथ आती थी। आजकल, कार चलाना एक सरल प्रक्रिया है जिसमें हम सभी हर दिन भाग लेते हैं। कोई नहीं सोचता कि कार कोई जटिल चीज़ है।

DevOps या सिस्टम इंजीनियरिंग ख़त्म नहीं होगी - उच्च-स्तरीय और कुशल कार्य में वृद्धि होगी।

— मैंने एक दिलचस्प विचार यह भी सुना कि काम वास्तव में बढ़ जाएगा।

दिमित्री: बिल्कुल, एक सौ प्रतिशत! क्योंकि हमारे द्वारा लिखे जाने वाले सॉफ़्टवेयर की मात्रा लगातार बढ़ रही है। सॉफ़्टवेयर द्वारा हमारे द्वारा हल की जाने वाली समस्याओं की संख्या लगातार बढ़ रही है। काम की मात्रा बढ़ रही है. अब DevOps बाज़ार बुरी तरह गर्म हो गया है। इसे वेतन अपेक्षाओं में देखा जा सकता है। एक अच्छे तरीके से, विवरण में जाए बिना, ऐसे जूनियर्स होने चाहिए जो एक्स चाहते हैं, मिडिल्स जो 1,5एक्स चाहते हैं, और सीनियर्स जो 2एक्स चाहते हैं। और अब, यदि आप मॉस्को डेवऑप्स वेतन बाजार को देखें, तो एक जूनियर X से 3X तक चाहता है और एक सीनियर X से 3X तक चाहता है।

कोई नहीं जानता कि इसकी कीमत कितनी है. वेतन का स्तर आपके आत्मविश्वास से मापा जाता है - एक पूर्ण पागलखाना, ईमानदारी से कहें तो, एक बहुत ही गर्म बाजार।

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

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

दिमित्री: एक सौ प्रतिशत। सामान्य तौर पर, हम 2019 में जी रहे हैं और जीवन का नियम यह है: जीवन भर सीखना - हम जीवन भर सीखते हैं. मुझे ऐसा लगता है कि अब हर कोई इसे पहले से ही जानता है और महसूस करता है, लेकिन जानना पर्याप्त नहीं है - आपको इसे करना होगा। हर दिन हमें बदलना होगा। यदि हम ऐसा नहीं करेंगे तो देर-सबेर हमें पेशे से हाशिये पर धकेल दिया जायेगा।

180 डिग्री के तीव्र मोड़ के लिए तैयार रहें। मैं इस संभावना से इंकार नहीं करता कि कुछ मौलिक रूप से बदल जाएगा, या कुछ नया आविष्कार किया जाएगा - ऐसा होता है। कूदना! - और अब हम अलग ढंग से कार्य करते हैं। इसके लिए तैयार रहना और चिंता न करना महत्वपूर्ण है। ऐसा हो सकता है कि कल मैं जो कुछ भी करता हूं वह अनावश्यक हो जाएगा - कुछ भी नहीं, मैंने जीवन भर अध्ययन किया है और कुछ और सीखने के लिए तैयार हूं। कोई परेशानी की बात नहीं। आपको नौकरी की सुरक्षा से डरना नहीं चाहिए, लेकिन आपको लगातार कुछ नया सीखने के लिए तैयार रहना होगा।

शुभकामनाएं और एक मिनट का विज्ञापन

—क्या आपकी कोई इच्छा है?

दिमित्री: हाँ, मेरी कई इच्छाएँ हैं।

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

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

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

इसका मतलब यह नहीं है कि आपको प्रयोग नहीं करना चाहिए। हमें प्रयोग करने की ज़रूरत है, हम इसे स्वयं करते हैं। सच कहूँ तो, हम खुद भी कभी-कभी खेलते हैं - बेशक, यह बहुत बुरा है, लेकिन कोई भी इंसान हमारे लिए पराया नहीं है। आइए 2019 को गंभीर, सुविचारित प्रयोगों का वर्ष घोषित करें, न कि उत्पादन पर खेल का। शायद इसलिए।

- आपका बहुत-बहुत धन्यवाद!

दिमित्री: विटाली, आपके समय और साक्षात्कार दोनों के लिए धन्यवाद। प्रिय पाठकों, अगर आप अचानक इस मुकाम पर पहुंच गए हैं तो आपका बहुत-बहुत धन्यवाद। मुझे आशा है कि हम आपके लिए कम से कम कुछ विचार लेकर आये हैं।

साक्षात्कार में, दिमित्री ने वेयरफ़ के मुद्दे पर बात की। अब यह एक सार्वभौमिक स्विस चाकू है जो लगभग सभी समस्याओं का समाधान करता है। पर हमेशा से ऐसा नहीं था। पर DevOpsConf  महोत्सव में आरआईटी++ दिमित्री स्टोलारोव इस टूल के बारे में विस्तार से बात करेंगे। रिपोर्ट में "वेर्फ़ कुबेरनेट्स पर सीआई/सीडी के लिए हमारा उपकरण है।" इसमें सब कुछ होगा: कुबेरनेट्स की समस्याएं और छिपी हुई बारीकियां, इन कठिनाइयों को हल करने के विकल्प और वेयरफ़ के वर्तमान कार्यान्वयन के बारे में विस्तार से। 27 और 28 मई को हमसे जुड़ें, हम उत्तम उपकरण बनाएंगे।

स्रोत: www.habr.com