कुबेरनेट दुनिया भर में ले जाएगा। कब और कैसे?

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

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



इसके बाद विटाली खाबरोव को एक्सप्रेस 42 के एक इंजीनियर द्वारा प्रश्न पूछे गए हैं।

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

- दिमा, हाय। आप फ्लंट के तकनीकी निदेशक हैं और इसके संस्थापक भी हैं। मुझे बताओ, कृपया, कंपनी क्या कर रही है और आप इसमें हैं?

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


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

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

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

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

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

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

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

हमारे पास वह क्षण नहीं था जिसे हमने कुबेरनेट्स का उपयोग करने के लिए सोचा था या नहीं। हम उसके प्रकट होने से बहुत पहले से उसकी प्रतीक्षा कर रहे थे, और खुद को एनालॉग बनाने की कोशिश कर रहे थे।

कुबेरनेट्स के पास

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

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

- क्या आप कुबेरनेट्स के आसपास अपने बहुत सारे उपकरण विकसित करते हैं?

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

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

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

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

फ्लंट उपकरण

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

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

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

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

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

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

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

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

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

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

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

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

- क्या आप हमें संक्षेप में बता सकते हैं कि क्यों बनाया गया था, इससे क्या समस्याएं हल होती हैं?

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

दूसरा कारण तैनाती में है। हां, यहां हेलम है, लेकिन यह समस्याओं का केवल एक हिस्सा है। विडंबना यह है कि यह लिखा है कि "हेल्म - द पैकेज मैनेजर फॉर कुबेरनेट्स"। अर्थात् ""। "पैकेज मैनेजर" शब्द भी हैं - पैकेज मैनेजर से सामान्य अपेक्षा क्या है? हम कहते हैं: "पैकेज प्रबंधक - पैकेज वितरित करें!" और उससे अपेक्षा करें कि वह हमें बताए: "पैकेज दिया गया है।"

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

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

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

योजनाओं

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

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

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

इस पूरी कहानी का एक और दृश्य उपमाओं के साथ है।

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

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

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

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

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

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

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

दिमित्री : यही बात है।

- कुबेरनेट्स को लेने और देने के लिए कितना मुश्किल है कि इसे तैयार न किया जाए?

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

कुबेरनेट्स रखो और इसे सरल काम करें: लड़की! - दिया, स्थापना विधियों का एक समूह है। लेकिन क्या होता है जब समस्याएं उत्पन्न होती हैं?

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

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

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

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

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

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

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

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

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

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

« »

— , ? , Kubernetes, - .

: , , . , Kubernetes, . , ? , , , . , — , . Kubernetes.

Ubuntu 16.04. , , , LTS. systemd, , C-. Kubernetes , C-, , - — , , — systemd. , . highload. , , Cron Job, , Ubuntu 16.04 . load average - , C-. , , Ubuntu 16 Kubernetes.

, - systemd - , Linux 4.16 — C- . . , , 15 , C-, , — .

. , - — , . — Kubernetes, — . . , - - , , , . , Kubernetes — ?

, , , . , .

, , , , . .

IT, , « ». , , . , . .

— : , , «», , Red Hat, , Kubernetes, .

: . Kubernetes — .

?

— , Kubernetes ?

: , , -. : «Kubernetes, Kubernetes», . , , , 70% Kubernetes. .

— ? «» , Kubernetes — -.

, Kubernetes .

game-changer . — , Ansible, Chef, , Terraform. . Kubernetes — changer , .

, - , - , . , , Kubernetes : , infrastructure as code , , yml — . , .

— , Kubernetes, . ?

: . , dns-, FreeBSD 4.10 20 . . , 20 - . , - , , , , Kubernetes. .

, CI/CD — , Continuous Delivery, , , , — Kubernetes.

— . Kubernetes, — . — - , , , Kubernetes , . — Kubernetes - , Kubernetes?

: . «: ». , . , . , , . «». , , - , — , , . ऐसा नहीं है।

, , 300 , , , , , - — 10, 30 . , . , 3 60 , .

, — . , . , , .

, , , , Kubernetes , , , , , , Kubernetes, . — , , , . . — , , — .

— , Kubernetes , , , . . — , , , 10 — , . . , .

Kubernetes . : Kubernetes, , 4-5 , — . , . यह क्या है Ubuntu Curios? Linux, . , . Kubernetes , , , , .

, , — «», 150 DevOps easy service. — . , DevOps, , . , . , , . , . , Kubernetes.

, 10 , . .

Amazon Google

— Amazon Google?

: , , . . , . , Amazon AWS: Load Balancer , «, , Load Balancer!» .

, , . 40 , , , 60 — . - , , .

, — , hosted- - . , , . Amazon Google . — . . clouds, , — Ager, , , OpenStack : Headster, Overage — , . , .

, — , , , hosted- .

Kubernetes?

— - Kubernetes? Kubernetes, «», Kubernetes?

: , Kubernetes : «, , Kubernetes, !». : «, Kubernetes, , ». , CI/CD , . , , .

, , , — ! — Kubernetes . . , , — Kubernetes , ! — ! — , ! — 100% uptime, 50 , . , !

, : «, ». , . , . CI/CD, . , .

, Kubernetes — Kubernetes .

, Kubernetes. , , , . , . Kubernetes — , , « », « », - .

. : , , — . . , , , , . , .

, - Kubernetes — .

Kubernetes , , , . — . - , — . - , , , , . . , DevOps , - , - . - .

. : «, !» — , : « , ». . , , - , , .

: Kubernetes. .

, :

• ;
  
• , , - ;
  
• , , , .
  

: / . , - IT-, , - — soft for easing the world, , . Kubernetes , .

serverless

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

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

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

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

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

कैसे कुबेरनेट का विकास होगा

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

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

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

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

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

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

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

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

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

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

इंजीनियरों के साथ क्या करना है?

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

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

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

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

सामान्य तौर पर, सभी क्षेत्रों में ऐसा पथ। कारों के साथ भी ऐसा ही है: पहले, एक कार मैकेनिक और तीन ड्राइवर कार से जुड़े थे। अब कार चलाना सबसे सरल प्रक्रिया है जिसमें हम सभी रोज हिस्सा लेते हैं। कोई यह नहीं सोचता है कि एक कार कुछ जटिल है।

DevOps या सिस्टम इंजीनियरिंग कहीं भी नहीं जाएंगे - उच्च-स्तरीय और परिचालन दक्षता बढ़ेगी।

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

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

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

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

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

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

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

इच्छाओं और विज्ञापन का एक मिनट

- आपकी कोई इच्छा होगी?

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

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

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

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

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

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

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

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