कुबर्नेट्स जगाचा ताबा घेतील. कधी आणि कसे?

अपेक्षेने DevOpsConf विटाली खबररोव मुलाखत घेतली दिमित्री स्टोल्यारोव्ह (डिस्टॉल), फ्लॅंट कंपनीचे तांत्रिक संचालक आणि सह-संस्थापक. विटालीने दिमित्रीला फ्लॅंट काय करते, कुबर्नेट्स, इकोसिस्टम डेव्हलपमेंट, समर्थन याबद्दल विचारले. कुबर्नेट्सची गरज का आहे आणि त्याची अजिबात गरज आहे का यावर आम्ही चर्चा केली. आणि मायक्रोसर्व्हिसेस, Amazon AWS, DevOps बद्दलचा “मी भाग्यवान असेल” दृष्टीकोन, कुबर्नेट्सचेच भविष्य, ते जग का, केव्हा आणि कसे ताब्यात घेईल, DevOps ची संभावना आणि अभियंत्यांनी कोणत्या गोष्टींसाठी तयारी करावी याबद्दल देखील. सरलीकरण आणि न्यूरल नेटवर्कसह उज्ज्वल आणि नजीकचे भविष्य.

मूळ मुलाखत DevOps Deflop वर पॉडकास्ट म्हणून ऐका - DevOps बद्दल रशियन भाषेतील पॉडकास्ट आणि खाली मजकूर आवृत्ती आहे.

येथे आणि खाली तो प्रश्न विचारतो विटाली खबररोव एक्सप्रेस 42 मधील अभियंता.

"फ्लंट" बद्दल

- हॅलो दिमा. तू तांत्रिक संचालक आहेस"चपळ"आणि त्याचे संस्थापक देखील. कृपया आम्हाला सांगा की कंपनी काय करते आणि तुम्ही त्यात काय आहात?

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




मी, तांत्रिक संचालक आणि कंपनीचा एक संस्थापक या नात्याने, उत्पादनाची सुलभता कशी वाढवता येईल, त्याचे कार्य सुलभ कसे करावे, प्रशासकांचे जीवन कसे सोपे करावे आणि विकसकांचे जीवन अधिक आनंददायी कसे बनवता येईल हे शोधण्यात दिवसरात्र घालवतो. .

कुबर्नेट्स बद्दल

- अलीकडे मी फ्लॅंट आणि कडून बरेच अहवाल पाहत आहे लेख कुबर्नेट्स बद्दल. तुला ते कसे आले?

दिमित्री: याविषयी मी यापूर्वीही अनेकदा बोललो आहे, पण त्याची पुनरावृत्ती करायला मला हरकत नाही. माझ्या मते हा विषय पुन्हा सांगणे योग्य आहे कारण कारण आणि परिणाम यात गोंधळ आहे.

आम्हाला खरोखर एक साधन हवे होते. आम्ही अनेक समस्यांचा सामना केला, संघर्ष केला, विविध क्रॅचेसने त्यांच्यावर मात केली आणि एका साधनाची गरज वाटली. आम्ही अनेक विविध पर्यायांमधून गेलो, आमच्या स्वत:च्या बाईक बनवल्या आणि अनुभव मिळवला. हळूहळू आम्ही अशा टप्प्यावर पोहोचलो जिथे आम्ही डॉकर दिसल्याबरोबरच वापरायला सुरुवात केली - 2013 च्या आसपास. त्याच्या दिसण्याच्या वेळी, आम्हाला कंटेनरचा आधीच खूप अनुभव होता, आम्ही आधीच "डॉकर" चे अॅनालॉग लिहिले होते - पायथनमधील आमचे स्वतःचे काही क्रॅच. डॉकरच्या आगमनाने, क्रॅचेस बाहेर टाकणे आणि विश्वासार्ह आणि समुदाय-समर्थित उपाय वापरणे शक्य झाले.

कुबर्नेट्सची कथा सारखीच आहे. तोपर्यंत त्याला गती मिळू लागली - आमच्यासाठी ही आवृत्ती 1.2 आहे - आमच्याकडे आधीच शेल आणि शेफ या दोन्हींवर क्रॅचेसचा एक समूह होता, ज्याला आम्ही डॉकरसह ऑर्केस्ट्रेट करण्याचा प्रयत्न केला. आम्ही रँचर आणि इतर विविध उपायांकडे गांभीर्याने पाहत होतो, परंतु नंतर कुबर्नेट्स दिसू लागले, ज्यामध्ये सर्वकाही आम्ही केले असते त्याप्रमाणे किंवा त्याहूनही चांगले अंमलात आणले जाते. तक्रार करण्यासारखे काही नाही.

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

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

कुबर्नेट्स बद्दल

— कुबर्नेट्सच्या विकासात तुम्ही थेट सहभागी आहात का?

दिमित्री: मध्यम. उलट, आम्ही परिसंस्थेच्या विकासात सहभागी होतो. आम्ही विशिष्ट संख्येने पुल विनंत्या पाठवतो: प्रोमिथियसला, विविध ऑपरेटरला, हेल्मला - इकोसिस्टमला. दुर्दैवाने, आम्ही करत असलेल्या प्रत्येक गोष्टीचा मागोवा ठेवण्यास मी सक्षम नाही आणि मी चुकीचे असू शकते, परंतु आमच्याकडून कोरमध्ये एकही पूल नाही.

— त्याच वेळी, तुम्ही कुबरनेटच्या आसपास तुमची बरीच साधने विकसित करता का?

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

उदाहरणार्थ, आमच्याकडे प्रोमिथियस ऑपरेटर आहे, ज्याच्या मदतीने आम्ही आमच्या असेंब्लीच्या अपस्ट्रीममध्ये 5 वेळा आधीच स्विच केले आहे. आम्हाला काही प्रकारचे वैशिष्ट्य हवे आहे, आम्ही एक पुल विनंती पाठवली आहे, आम्हाला ते उद्या रोल आउट करायचे आहे, परंतु आम्ही ते अपस्ट्रीम रिलीझ होण्याची प्रतीक्षा करू इच्छित नाही. त्यानुसार, आम्ही स्वतःसाठी एकत्र होतो, आमच्या वैशिष्ट्यासह आमची असेंब्ली रोल आउट करतो, ज्याची आम्हाला काही कारणास्तव गरज असते, आमच्या सर्व क्लस्टर्समध्ये. मग, उदाहरणार्थ, ते अपस्ट्रीममध्ये या शब्दांसह आमच्याकडे वळवतात: "अगं, ते अधिक सामान्य प्रकरणासाठी करूया," आम्ही किंवा इतर कोणीतरी ते पूर्ण करतो आणि कालांतराने ते पुन्हा विलीन होते.

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

मार्ग नेहमीच असा असतो: आम्ही खूप काळजीपूर्वक शोधतो आणि जर आम्हाला ब्रेडमधून ट्रॉलीबस कसा बनवायचा यावर काही उपाय सापडला नाही तर आम्ही आमची स्वतःची वडी आणि स्वतःची ट्रॉलीबस बनवतो.

फ्लांटा साधने

— मला माहित आहे की फ्लॅंटमध्ये आता अॅडॉन ऑपरेटर, शेल ऑपरेटर आणि dapp/werf टूल्स आहेत. जसे मला समजले आहे, वेगवेगळ्या अवतारांमध्ये हे एकच वाद्य आहे. मला हे देखील समजले आहे की Flaunt मध्ये आणखी बरीच भिन्न साधने आहेत. हे खरं आहे?

दिमित्री: आमच्याकडे GitHub वर बरेच काही आहे. मला आता जे आठवत आहे त्यावरून, आमच्याकडे एक स्टेटसमॅप आहे - ग्राफानासाठी एक पॅनेल जो प्रत्येकाने पाहिला आहे. कुबर्नेट्स ऑन मिडियम मॉनिटरिंग बद्दल जवळजवळ प्रत्येक दुसऱ्या लेखात याचा उल्लेख आहे. स्टेटसमॅप म्हणजे काय हे थोडक्यात सांगणे अशक्य आहे - त्याला एका स्वतंत्र लेखाची आवश्यकता आहे, परंतु कालांतराने स्थितीचे निरीक्षण करण्यासाठी ही एक अतिशय उपयुक्त गोष्ट आहे, कारण कुबर्नेट्समध्ये आपल्याला वेळोवेळी स्थिती दर्शवावी लागते. आमच्याकडे लॉगहाऊस देखील आहे - ही क्लिकहाऊसवर आधारित गोष्ट आहे आणि कुबर्नेट्समध्ये लॉग गोळा करण्यासाठी काळ्या जादूवर आधारित आहे.

अनेक उपयुक्तता! आणि आणखी बरेच काही असेल, कारण या वर्षी अनेक अंतर्गत उपाय सोडले जातील. अॅडऑन ऑपरेटरवर आधारित असलेल्या खूप मोठ्यांपैकी, कुबर्नेट्ससाठी अॅडऑन्सचा एक समूह आहे, अला सर्ट मॅनेजर योग्यरित्या कसे स्थापित करावे - प्रमाणपत्रे व्यवस्थापित करण्यासाठी एक साधन, अॅक्सेसरीजच्या गुच्छासह प्रोमिथियस योग्यरित्या कसे स्थापित करावे - हे सुमारे वीस भिन्न आहेत. बायनरी जे डेटा निर्यात करतात आणि काहीतरी गोळा करतात, या प्रोमिथियसकडे सर्वात आश्चर्यकारक ग्राफिक्स आणि अलर्ट आहेत. हे सर्व कुबर्नेट्सच्या ऍडऑन्सचा एक समूह आहे, जे क्लस्टरमध्ये स्थापित केले आहे आणि ते साध्या ते थंड, अत्याधुनिक, स्वयंचलित बनते, ज्यामध्ये बर्याच समस्यांचे आधीच निराकरण केले गेले आहे. होय, आम्ही बरेच काही करतो.

इकोसिस्टम विकास

"मला असे वाटते की या उपकरणाच्या आणि त्याच्या वापराच्या पद्धतींच्या विकासासाठी हे खूप मोठे योगदान आहे." परिसंस्थेच्या विकासात इतर कोणाचे योगदान समान असेल याचा अंदाज लावता येईल का?

दिमित्री: रशियामध्ये, आमच्या बाजारात कार्यरत असलेल्या कंपन्यांपैकी कोणीही जवळ नाही. अर्थात, हे एक मोठे विधान आहे, कारण मेल आणि यांडेक्स सारख्या प्रमुख खेळाडू आहेत - ते कुबर्नेट्ससह काहीतरी करत आहेत, परंतु तरीही ते आपल्यापेक्षा बरेच काही करणार्‍या संपूर्ण जगातील कंपन्यांच्या योगदानाच्या जवळ येत नाहीत. माझी चूक नसेल तर फ्लॅंट, ज्यात 80 लोकांचा स्टाफ आहे आणि Red Hat, ज्यात एकट्या कुबरनेटसाठी 300 अभियंते आहेत, यांची तुलना करणे कठीण आहे. तुलना करणे कठीण आहे. आमच्याकडे RnD विभागात माझ्यासह 6 लोक आहेत, ज्यांनी आमची सर्व साधने कापली. 6 लोक विरुद्ध 300 Red Hat अभियंते - तुलना करणे कठीण आहे.

- तथापि, जेव्हा हे 6 लोक देखील खरोखर उपयुक्त आणि परके काहीतरी करू शकतात, जेव्हा त्यांना व्यावहारिक समस्येचा सामना करावा लागतो आणि ते समाजाला समाधान देतात - एक मनोरंजक प्रकरण. मला समजते की मोठ्या तंत्रज्ञान कंपन्यांमध्ये, जिथे त्यांची स्वतःची कुबर्नेट्स डेव्हलपमेंट आणि सपोर्ट टीम आहे, तत्त्वतः, समान साधने विकसित केली जाऊ शकतात. कुबर्नेट्सचा वापर करणार्‍या संपूर्ण समुदायाला चालना देऊन समाजाला काय विकसित केले जाऊ शकते आणि काय दिले जाऊ शकते याचे हे त्यांच्यासाठी एक उदाहरण आहे.

दिमित्री: हे कदाचित इंटिग्रेटरचे वैशिष्ट्य आहे, त्याचे वैशिष्ठ्य. आमच्याकडे अनेक प्रकल्प आहेत आणि आम्ही अनेक भिन्न परिस्थिती पाहतो. आमच्यासाठी, अतिरिक्त मूल्य तयार करण्याचा मुख्य मार्ग म्हणजे या प्रकरणांचे विश्लेषण करणे, समानता शोधणे आणि ते आमच्यासाठी शक्य तितके स्वस्त करणे. यावर आम्ही सक्रियपणे काम करत आहोत. रशिया आणि जगाबद्दल बोलणे माझ्यासाठी कठीण आहे, परंतु आमच्याकडे कंपनीत सुमारे 40 DevOps अभियंते आहेत जे Kubernetes वर काम करतात. मला वाटत नाही की रशियामध्ये अशा अनेक कंपन्या आहेत ज्यांच्या तज्ञांची संख्या तुलनात्मक आहे ज्यांना कुबेरनेट्स समजतात, जर काही असेल तर.

मला DevOps अभियंता पदाविषयी सर्व काही समजले आहे, प्रत्येकाला सर्वकाही समजते आणि DevOps अभियंत्यांना DevOps अभियंते म्हणण्याची सवय आहे, आम्ही यावर चर्चा करणार नाही. हे सर्व 40 आश्चर्यकारक DevOps अभियंते दररोज समस्यांना तोंड देतात आणि सोडवतात, आम्ही फक्त या अनुभवाचे विश्लेषण करतो आणि सामान्यीकरण करण्याचा प्रयत्न करतो. आम्ही समजतो की जर ते आपल्या आतच राहिले तर एक-दोन वर्षांत ते साधन निरुपयोगी होईल, कारण समाजात कुठेतरी तयार तुला दिसेल. हा अनुभव आंतरिकरित्या जमा करण्यात काही अर्थ नाही - हे फक्त ऊर्जा आणि वेळ dev/null मध्ये काढून टाकत आहे. आणि आम्हाला त्याबद्दल अजिबात वाईट वाटत नाही. आम्ही सर्व काही मोठ्या आनंदाने प्रकाशित करतो आणि समजतो की ते प्रकाशित करणे, विकसित करणे, प्रचार करणे, प्रचार करणे आवश्यक आहे, जेणेकरून लोक ते वापरतील आणि त्यांचे अनुभव जोडतील - मग सर्वकाही वाढते आणि जगते. त्यानंतर दोन वर्षांनी ते वाद्य कचऱ्यात जात नाही. सामर्थ्य ओतत राहणे ही वाईट गोष्ट नाही, कारण हे स्पष्ट आहे की कोणीतरी आपले साधन वापरत आहे आणि दोन वर्षांनंतर प्रत्येकजण ते वापरत आहे.

dapp/werf सह आमच्या मोठ्या धोरणाचा हा भाग आहे. आम्ही ते केव्हा बनवायला सुरुवात केली ते मला आठवत नाही, हे 3 वर्षांपूर्वीचे दिसते. सुरुवातीला, ते सामान्यतः शेलवर होते. हा संकल्पनेचा एक उत्कृष्ट पुरावा होता, आम्ही आमच्या काही विशिष्ट समस्यांचे निराकरण केले - ते कार्य केले! परंतु शेलमध्ये समस्या आहेत, ते आणखी विस्तृत करणे अशक्य आहे, शेलवरील प्रोग्रामिंग हे दुसरे कार्य आहे. आम्हाला रुबीमध्ये लिहिण्याची सवय होती, त्यानुसार आम्ही रुबीमध्ये काहीतरी रिमेक केले, विकसित केले, विकसित केले, विकसित केले आणि या वस्तुस्थितीकडे धाव घेतली की समाज, “आम्हाला ते हवे आहे किंवा आम्हाला ते नको आहे,” असे न म्हणणारी गर्दी. ” रुबीकडे नाक वळवते, हे कसे मजेदार नाही? आम्हाला जाणवले की चेकलिस्टमधील पहिला मुद्दा पूर्ण करण्यासाठी आम्ही ही सर्व सामग्री Go मध्ये लिहिली पाहिजे: DevOps टूल हे स्टॅटिक बायनरी असले पाहिजे. गो असणे किंवा नसणे इतके महत्त्वाचे नाही, परंतु गो मध्ये लिहिलेली स्थिर बायनरी अधिक चांगली आहे.

आम्ही आमची ऊर्जा खर्च केली, गो मध्ये dapp पुन्हा लिहिला आणि त्याला werf म्हटले. Dapp यापुढे समर्थित नाही, विकसित नाही, काही नवीनतम आवृत्तीमध्ये चालू आहे, परंतु शीर्षस्थानी एक परिपूर्ण अपग्रेड मार्ग आहे आणि तुम्ही त्याचे अनुसरण करू शकता.

डॅप का तयार केला गेला?

— डॅप का तयार केले गेले, ते कोणत्या समस्यांचे निराकरण करते हे तुम्ही आम्हाला थोडक्यात सांगू शकाल?

दिमित्री: पहिले कारण विधानसभेत आहे. सुरुवातीला, डॉकरकडे मल्टी-स्टेज क्षमता नसताना बिल्डमध्ये आम्हाला गंभीर समस्या होत्या, म्हणून आम्ही स्वतः मल्टी-स्टेज बनवले. मग आम्हाला प्रतिमा साफ करताना आणखी काही समस्या आल्या. प्रत्येकजण जो सीआय/सीडी करतो, उशिरा ऐवजी लवकर, या समस्येचा सामना करावा लागतो की संग्रहित प्रतिमांचा एक समूह आहे, आपल्याला आवश्यक नसलेल्या गोष्टी साफ करणे आवश्यक आहे आणि जे आवश्यक आहे ते सोडणे आवश्यक आहे.

दुसरे कारण तैनाती आहे. होय, हेल्म आहे, परंतु ते फक्त काही समस्यांचे निराकरण करते. मजेशीरपणे, असे लिहिले आहे की "हेल्म हे कुबर्नेट्ससाठी पॅकेज व्यवस्थापक आहे." नक्की काय “द”. "पॅकेज मॅनेजर" असे शब्द देखील आहेत - पॅकेज मॅनेजरकडून नेहमीची अपेक्षा काय असते? आम्ही म्हणतो: "पॅकेज व्यवस्थापक - पॅकेज स्थापित करा!" आणि आम्ही अपेक्षा करतो की त्याने आम्हाला सांगावे: "पॅकेज वितरित केले गेले आहे."

हे मनोरंजक आहे की आम्ही म्हणतो: "हेल्म, पॅकेज स्थापित करा," आणि जेव्हा त्याने उत्तर दिले की त्याने ते स्थापित केले आहे, तेव्हा असे दिसून आले की त्याने नुकतीच स्थापना सुरू केली - त्याने कुबर्नेट्सला सूचित केले: "ही गोष्ट लाँच करा!", आणि ते सुरू झाले की नाही. , ते कार्य करते किंवा नाही, हेल्म हा प्रश्न अजिबात सोडवत नाही.

असे दिसून आले की हेल्म हा फक्त एक मजकूर प्रीप्रोसेसर आहे जो कुबर्नेट्समध्ये डेटा लोड करतो.

परंतु कोणत्याही उपयोजनाचा भाग म्हणून, आम्हाला हे जाणून घ्यायचे आहे की अर्ज उत्पादनासाठी सोडला गेला आहे की नाही? उत्पादनावर रोल आउट केले म्हणजे अनुप्रयोग तेथे हलविला गेला आहे, नवीन आवृत्ती तैनात केली गेली आहे आणि कमीतकमी तो तेथे क्रॅश होत नाही आणि योग्य प्रतिसाद देतो. हेल्म कोणत्याही प्रकारे ही समस्या सोडवत नाही. ते सोडवण्यासाठी, तुम्हाला खूप प्रयत्न करावे लागतील, कारण तुम्हाला कुबर्नेट्सला रोल आउट करण्याची आणि तेथे काय घडत आहे यावर लक्ष ठेवण्याची आज्ञा देणे आवश्यक आहे - ते तैनात केले आहे किंवा रोल आउट केले आहे. आणि तैनाती, साफसफाई आणि असेंब्लीशी संबंधित बरीच कामे देखील आहेत.

योजना

या वर्षी आम्ही स्थानिक विकास सुरू करू. व्हॅग्रंटमध्ये पूर्वी जे होते ते आम्हाला साध्य करायचे आहे - आम्ही "व्हॅग्रंट अप" टाइप केले आणि आम्ही आभासी मशीन तैनात केली. आम्हाला Git मध्ये एक प्रकल्प आहे त्या ठिकाणी जायचे आहे, आम्ही तेथे "werf up" लिहितो आणि ते या प्रकल्पाची स्थानिक प्रत आणते, स्थानिक मिनी-कुबमध्ये तैनात केली जाते, विकासासाठी सोयीस्कर असलेल्या सर्व निर्देशिका कनेक्ट केल्या जातात. . विकासाच्या भाषेवर अवलंबून, हे वेगळ्या पद्धतीने केले जाते, परंतु असे असले तरी, माउंट केलेल्या फायलींच्या अंतर्गत स्थानिक विकास सोयीस्करपणे केला जाऊ शकतो.

आमच्यासाठी पुढची पायरी आहे विकासकांच्या सोयीसाठी गुंतवणूक करा. एका साधनासह स्थानिक पातळीवर प्रकल्प त्वरित उपयोजित करण्यासाठी, तो विकसित करा, त्याला Git मध्ये ढकलून द्या आणि पाइपलाइनवर अवलंबून ते स्टेज किंवा चाचण्यांसाठी देखील रोल आउट होईल आणि नंतर उत्पादनावर जाण्यासाठी तेच साधन वापरा. स्थानिक वातावरणापासून विक्रीपर्यंतच्या पायाभूत सुविधांची ही एकता, एकीकरण, पुनरुत्पादनक्षमता हा आपल्यासाठी अतिशय महत्त्वाचा मुद्दा आहे. परंतु हे अद्याप werf मध्ये नाही - आम्ही फक्त ते करण्याची योजना करत आहोत.

पण डॅप/वेर्फचा मार्ग सुरुवातीच्या काळात कुबर्नेट्स सारखाच असतो. आम्हाला समस्या आल्या, वर्कअराउंडसह त्यांचे निराकरण केले - आम्ही शेलवर, कशावरही स्वतःसाठी काही उपाय शोधून काढले. मग त्यांनी या वर्कअराउंड्स कसे तरी सरळ करण्याचा प्रयत्न केला, सामान्यीकृत आणि या प्रकरणात बायनरीमध्ये एकत्रित करण्याचा प्रयत्न केला, जे आम्ही फक्त सामायिक करतो.

या संपूर्ण कथेकडे साधर्म्यांसह पाहण्याचा आणखी एक मार्ग आहे.

Kubernetes एक इंजिन असलेली कार फ्रेम आहे. दरवाजे, काच, रेडिओ, ख्रिसमस ट्री - काहीही नाही. फक्त फ्रेम आणि इंजिन. आणि हेल्म आहे - हे स्टीयरिंग व्हील आहे. छान - एक स्टीयरिंग व्हील आहे, परंतु आपल्याला स्टीयरिंग पिन, स्टीयरिंग रॅक, गिअरबॉक्स आणि चाके देखील आवश्यक आहेत आणि आपण त्यांच्याशिवाय करू शकत नाही.

werf च्या बाबतीत, कुबर्नेट्सचा हा आणखी एक घटक आहे. फक्त आता werf च्या अल्फा आवृत्तीमध्ये, उदाहरणार्थ, हेल्म हे werf च्या आत संकलित केले आहे, कारण आपण ते स्वतःच करून थकलो आहोत. हे करण्याची अनेक कारणे आहेत, मी तुम्हाला संपूर्ण हेल्म एकत्रितपणे टिलर इन वेर्फसह का संकलित केले याबद्दल तपशीलवार सांगेन. RIT++ च्या अहवालात.

आता werf अधिक एकात्मिक घटक आहे. आम्हाला एक तयार स्टीयरिंग व्हील, एक स्टीयरिंग पिन मिळतो - मी कारमध्ये फारसा चांगला नाही, परंतु हा एक मोठा ब्लॉक आहे जो आधीच बर्‍याच विस्तृत समस्यांचे निराकरण करतो. आम्हाला स्वतः कॅटलॉगमधून जाण्याची गरज नाही, दुसर्‍यासाठी एक भाग निवडा, त्यांना एकत्र कसे स्क्रू करायचे याचा विचार करा. आम्हाला एक रेडीमेड कॉम्बाइन मिळते जे एकाच वेळी मोठ्या संख्येने समस्या सोडवते. पण आत ते त्याच ओपन सोर्स घटकांपासून बनवलेले आहे, तरीही ते असेंबलीसाठी डॉकर, काही कार्यक्षमतेसाठी हेल्म आणि इतर अनेक लायब्ररी वापरतात. बॉक्समधून थंड CI/CD द्रुतपणे आणि सोयीस्करपणे मिळवण्यासाठी हे एक एकीकृत साधन आहे.

कुबर्नेट्सची देखभाल करणे कठीण आहे का?

— तुम्ही कुबर्नेट्स वापरण्यास सुरुवात केलेल्या अनुभवाबद्दल तुम्ही बोलता, ही तुमच्यासाठी एक फ्रेम आहे, एक इंजिन आहे आणि त्यावर तुम्ही बर्‍याच वेगवेगळ्या गोष्टी टांगू शकता: एक शरीर, एक स्टीयरिंग व्हील, पेडल्सवर स्क्रू, सीट. प्रश्न उद्भवतो - कुबर्नेट्स आपल्यासाठी समर्थन किती कठीण आहे? तुम्हाला खूप अनुभव आहे, बाकी सर्व गोष्टींपासून वेगळे राहून कुबर्नेट्सला पाठिंबा देण्यासाठी तुम्ही किती वेळ आणि संसाधने खर्च करता?

दिमित्री: हा एक अतिशय कठीण प्रश्न आहे आणि त्याचे उत्तर देण्यासाठी, आम्हाला कुबर्नेट्सकडून समर्थन काय आहे आणि आम्हाला काय हवे आहे हे समजून घेणे आवश्यक आहे. कदाचित आपण प्रकट करू शकता?

— माझ्या माहितीनुसार आणि मी पाहिल्याप्रमाणे, आता बर्‍याच संघांना कुबर्नेट्स वापरायचे आहेत. प्रत्येकजण ते वापरतो, गुडघ्यावर ठेवतो. मला अशी भावना आहे की लोकांना या प्रणालीची जटिलता नेहमीच समजत नाही.

दिमित्री: असे आहे.

— कुबर्नेट्स सुरवातीपासून घेणे आणि स्थापित करणे किती कठीण आहे जेणेकरून ते उत्पादन तयार होईल?

दिमित्री: हृदय प्रत्यारोपण करणे किती कठीण आहे असे तुम्हाला वाटते? मला समजते की हा एक तडजोड करणारा प्रश्न आहे. स्केलपेल वापरणे आणि चूक न करणे इतके अवघड नाही. जर ते तुम्हाला कुठे कापायचे आणि कुठे शिवायचे ते सांगतात, तर प्रक्रिया स्वतःच क्लिष्ट नाही. वेळोवेळी सर्वकाही कार्य करेल याची खात्री देणे कठीण आहे.

कुबर्नेट्स स्थापित करणे आणि ते कार्य करणे सोपे आहे: चिक! — स्थापित, अनेक प्रतिष्ठापन पद्धती आहेत. पण जेव्हा समस्या उद्भवतात तेव्हा काय होते?

प्रश्न नेहमी उद्भवतात - आपण अद्याप काय विचारात घेतले नाही? आम्ही अजून काय केले नाही? कोणते लिनक्स कर्नल पॅरामीटर्स चुकीचे नमूद केले होते? प्रभु, आम्ही त्यांचा उल्लेखही केला का?! आम्ही कोणते कुबर्नेट्स घटक वितरित केले आहेत आणि कोणते नाहीत? हजारो प्रश्न निर्माण होतात आणि त्यांची उत्तरे मिळवण्यासाठी तुम्हाला या उद्योगात 15-20 वर्षे घालवावी लागतील.

माझ्याकडे या विषयावरील एक अलीकडील उदाहरण आहे जे कदाचित "कुबर्नेट्स राखणे कठीण आहे का?" या समस्येचा अर्थ प्रकट करू शकते. काही काळापूर्वी आम्ही Cilium ला Kubernetes मध्ये नेटवर्क म्हणून कार्यान्वित करण्याचा प्रयत्न केला पाहिजे का यावर गंभीरपणे विचार केला.

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

लिनक्स कर्नलमध्ये ऐतिहासिकदृष्ट्या एक ip राउट, एक ओव्हरफिल्टर, पूल आणि अनेक जुने घटक आहेत जे 15, 20, 30 वर्षे जुने आहेत. सर्वसाधारणपणे, ते कार्य करतात, सर्व काही छान आहे, परंतु आता त्यांनी कंटेनरचे ढीग केले आहेत आणि ते एकमेकांच्या वर 15 विटांचे टॉवरसारखे दिसते आणि आपण त्यावर एका पायावर उभे आहात - एक विचित्र भावना. ही प्रणाली ऐतिहासिकदृष्ट्या शरीरातील परिशिष्टाप्रमाणे अनेक बारकाव्यांसह विकसित झाली आहे. काही परिस्थितींमध्ये कार्यप्रदर्शन समस्या आहेत, उदाहरणार्थ.

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

काय झालं? खूप छान कामगिरी, छान वैशिष्ट्ये - फक्त छान! परंतु आम्ही हे पाहतो आणि पाहतो की प्रत्येक मशीनवर एक प्रोग्राम आहे जो कुबर्नेट्स API ला जोडतो आणि या API कडून प्राप्त झालेल्या डेटाच्या आधारे, C कोड तयार करतो आणि बायनरी संकलित करतो जे ते कर्नलमध्ये लोड करतात जेणेकरून हे हुक कार्य करतात. कर्नल जागेत

काही चूक झाली तर काय होईल? आम्हाला माहित नाही. हे समजून घेण्यासाठी, तुम्हाला हा सर्व कोड वाचावा लागेल, सर्व तर्कशास्त्र समजून घ्यावे लागेल आणि हे किती कठीण आहे हे आश्चर्यकारक आहे. पण, दुसरीकडे, हे ब्रिज, नेट फिल्टर, आयपी राउट आहेत - मी त्यांचा सोर्स कोड वाचलेला नाही आणि आमच्या कंपनीत काम करणारे ४० इंजिनीअरही नाहीत. कदाचित काहींनाच काही भाग समजतात.

आणि फरक काय आहे? असे दिसून आले की तेथे ip रूट, लिनक्स कर्नल आहे आणि एक नवीन साधन आहे - यामुळे काय फरक पडतो, आम्हाला एक किंवा दुसरे समजत नाही. पण आपण काहीतरी नवीन वापरण्यास घाबरतो - का? कारण जर टूल 30 वर्षांचे असेल, तर 30 वर्षांमध्ये सर्व दोष सापडले आहेत, सर्व चुका झाल्या आहेत आणि आपल्याला सर्वकाही माहित असणे आवश्यक नाही - ते ब्लॅक बॉक्ससारखे कार्य करते आणि नेहमी कार्य करते. प्रत्येकाला माहित आहे की कोणता डायग्नोस्टिक स्क्रू ड्रायव्हर कोणत्या ठिकाणी चिकटवायचा, कोणता tcpdump कोणत्या क्षणी चालवायचा. प्रत्येकाला निदान उपयुक्तता चांगल्या प्रकारे माहित आहे आणि लिनक्स कर्नलमध्ये घटकांचा हा संच कसा कार्य करतो - ते कसे कार्य करते हे नाही तर ते कसे वापरावे हे समजते.

आणि अप्रतिम थंड Cilium 30 वर्षांचे नाही, अजून म्हातारे झालेले नाही. Kubernetes समान समस्या आहे, कॉपी. ते Cilium उत्तम प्रकारे स्थापित केले आहे, की Kubernetes उत्तम प्रकारे स्थापित केले आहे, परंतु जेव्हा उत्पादनात काहीतरी चूक होते, तेव्हा काय चूक झाली हे आपणास त्वरीत समजू शकते का?

जेव्हा आपण म्हणतो की कुबर्नेट्स राखणे कठीण आहे - नाही, हे खूप सोपे आहे आणि होय, हे आश्चर्यकारकपणे कठीण आहे. कुबर्नेट्स स्वतःच उत्तम कार्य करते, परंतु अब्जावधी बारकावे सह.

"मी भाग्यवान होईन" या दृष्टिकोनाबद्दल

- अशा काही कंपन्या आहेत जेथे या बारकावे दिसण्याची जवळजवळ हमी आहे? समजा यांडेक्सने अचानक सर्व सेवा कुबर्नेट्सला हस्तांतरित केल्या, तर तेथे खूप मोठा भार असेल.

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

माझ्याकडे उबंटू १६.०४ आहे. तुम्ही म्हणू शकता की ही जुनी आवृत्ती आहे, परंतु आम्ही अजूनही त्यावर आहोत कारण ती LTS आहे. सिस्टमड आहे, ज्याचा महत्त्वाचा मुद्दा म्हणजे तो सी-गट साफ करत नाही. Kubernetes पॉड लाँच करते, सी-ग्रुप तयार करते, नंतर पॉड हटवते, आणि कसे तरी ते निष्पन्न होते - मला तपशील आठवत नाही, क्षमस्व - ते सिस्टम केलेले स्लाइस शिल्लक आहेत. यामुळे कालांतराने कोणतीही कार जोरदार मंद होऊ लागते. हा हायलोडचा प्रश्नही नाही. जर कायमस्वरूपी पॉड्स लॉन्च केले असतील, उदाहरणार्थ, क्रॉन जॉब असेल जे सतत पॉड तयार करत असेल, तर Ubuntu 16.04 सह मशीन एका आठवड्यानंतर मंद होण्यास सुरवात करेल. सी-गटांचा समूह तयार केल्यामुळे सतत उच्च भार सरासरी असेल. ही समस्या आहे ज्याने उबंटू 16.04 आणि कुबर्नेट्स शीर्षस्थानी स्थापित केलेल्या कोणत्याही व्यक्तीला सामोरे जावे लागेल.

समजा तो कसा तरी systemd किंवा दुसरे काहीतरी अपडेट करतो, परंतु लिनक्स कर्नलमध्ये 4.16 पर्यंत ते आणखी मजेदार आहे - जेव्हा तुम्ही C-ग्रुप हटवता तेव्हा ते कर्नलमध्ये लिक होतात आणि प्रत्यक्षात हटवले जात नाहीत. त्यामुळे या मशिनवर महिनाभर काम केल्यानंतर चूलांच्या मेमरीची आकडेवारी पाहणे अशक्य होईल. आम्ही एक फाईल काढतो, प्रोग्राममध्ये रोल करतो आणि एक फाईल 15 सेकंदांसाठी रोल करते, कारण कर्नलला स्वतःमध्ये एक दशलक्ष सी-ग्रुप मोजण्यासाठी खूप वेळ लागतो, जे हटवलेले दिसते, परंतु नाही - ते गळत आहेत. .

अजूनही अशा अनेक छोट्या छोट्या गोष्टी इकडे तिकडे आहेत. ही एक समस्या नाही ज्याला महाकाय कंपन्यांना कधीकधी खूप जास्त भार सहन करावा लागतो - नाही, ही रोजची बाब आहे. लोक असे महिने जगू शकतात - त्यांनी कुबर्नेट्स स्थापित केले, अनुप्रयोग तैनात केले - ते कार्य करते असे दिसते. बर्याच लोकांसाठी हे सामान्य आहे. त्यांना हे देखील कळणार नाही की हे ऍप्लिकेशन काही कारणास्तव क्रॅश होईल, त्यांना अलर्ट मिळणार नाही, परंतु त्यांच्यासाठी हे सर्वसामान्य प्रमाण आहे. पूर्वी, आम्ही देखरेख न करता व्हर्च्युअल मशीनवर राहत होतो, आता आम्ही कुबर्नेट्समध्ये गेलो, ते देखील निरीक्षण न करता - काय फरक आहे?

प्रश्न असा आहे की जेव्हा आपण बर्फावर चालतो तेव्हा त्याची जाडी आपण आधीच मोजल्याशिवाय आपल्याला कधीच कळत नाही. बरेच लोक चालतात आणि काळजी करू नका, कारण ते आधी चालले आहेत.

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

आयटीमध्ये, मला असे वाटते की, "मी भाग्यवान होईन" असे बरेच मार्ग आहेत. बरेच लोक सॉफ्टवेअर स्थापित करतात आणि सॉफ्टवेअर लायब्ररी वापरतात या आशेने की ते भाग्यवान होतील. सर्वसाधारणपणे, बरेच लोक भाग्यवान असतात. म्हणूनच कदाचित ते कार्य करते.

— माझ्या निराशावादी मूल्यमापनावरून, असे दिसते: जेव्हा जोखीम जास्त असते आणि अनुप्रयोगाने कार्य करणे आवश्यक असते, तेव्हा Flaunt कडून समर्थन आवश्यक असते, कदाचित Red Hat कडून, किंवा तुम्हाला तुमच्या स्वतःच्या अंतर्गत टीमची आवश्यकता असते, विशेषत: Kubernetes ला समर्पित, जे तयार आहे ते काढण्यासाठी.

दिमित्री: वस्तुनिष्ठपणे, हे असे आहे. कुबर्नेट्सच्या कथेत स्वतःहून लहान संघासाठी प्रवेश करणे अनेक जोखमींचा समावेश आहे.

आम्हाला कंटेनरची गरज आहे का?

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

दिमित्री: माझ्याकडे हा डेटा नाही आणि मला खात्री नाही की इतर कोणाकडेही आहे. आम्ही म्हणतो: "कुबर्नेट्स, कुबर्नेट्स," परंतु या समस्येकडे पाहण्याचा आणखी एक मार्ग आहे. मला हे देखील माहित नाही की कंटेनर किती व्यापक आहेत, परंतु मला इंटरनेटवरील अहवालातील एक आकृती माहित आहे की 70% कंटेनर कुबेरनेट्सने तयार केले आहेत. जगभरातील बऱ्यापैकी मोठ्या नमुन्यासाठी हा एक विश्वसनीय स्रोत होता.

मग दुसरा प्रश्न - आम्हाला कंटेनरची गरज आहे का? माझी वैयक्तिक भावना आणि फ्लॅंट कंपनीची एकूण स्थिती अशी आहे की कुबर्नेट्स हे एक वास्तविक मानक आहे.

कुबेरनेट्सशिवाय काहीही होणार नाही.

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

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

— म्हणजे, ज्या कंपन्या अद्याप कुबर्नेट्सवर स्विच केल्या नाहीत त्या नक्कीच त्याकडे जातील किंवा विस्मृतीत राहतील. मी तुला बरोबर समजले?

दिमित्री: हे देखील पूर्णपणे सत्य नाही. उदाहरणार्थ, जर आमच्याकडे DNS सर्व्हर चालवण्याचे काम असेल, तर ते FreeBSD 4.10 वर चालवले जाऊ शकते आणि ते 20 वर्षे उत्तम प्रकारे कार्य करू शकते. फक्त काम करा आणि तेच. कदाचित 20 वर्षांत काहीतरी एकदा अद्यतनित करणे आवश्यक आहे. आम्ही लॉन्च केलेल्या फॉरमॅटमधील सॉफ्टवेअरबद्दल बोलत असल्यास आणि ते प्रत्यक्षात अनेक वर्षे कोणत्याही अपडेटशिवाय, बदल न करता कार्य करते, तर नक्कीच, कुबर्नेट्स नसतील. त्याची तिथे गरज नाही.

CI/CD शी संबंधित सर्व काही - जिथे सतत डिलिव्हरी आवश्यक असेल, जिथे तुम्हाला आवृत्त्या अपडेट कराव्या लागतील, सक्रिय बदल करा, जिथे तुम्हाला दोष सहिष्णुता वाढवायची आहे - फक्त कुबर्नेट्स.

मायक्रोसर्व्हिसेस बद्दल

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

दिमित्री: मस्त प्रश्न. माझ्याकडे मायक्रोसर्व्हिसेसबद्दल चर्चा आहे "मायक्रोसर्व्हिसेस: साइज मॅटर." मी बर्‍याच वेळा मायक्रोस्कोपने नखे मारण्याचा प्रयत्न करीत असलेल्या लोकांचा सामना केला आहे. दृष्टीकोन स्वतःच योग्य आहे; आम्ही स्वतः आमचे अंतर्गत सॉफ्टवेअर अशा प्रकारे डिझाइन करतो. परंतु जेव्हा तुम्ही हे करता तेव्हा तुम्ही काय करत आहात हे स्पष्टपणे समजून घेणे आवश्यक आहे. मायक्रो सर्व्हिसेसबद्दल मला सर्वात जास्त तिरस्कार असलेला शब्द "मायक्रो" आहे. ऐतिहासिकदृष्ट्या, हा शब्द तिथून उद्भवला आणि काही कारणास्तव लोकांना असे वाटते की मायक्रो हे अगदी लहान, मिलीमीटरपेक्षा कमी, मायक्रोमीटरसारखे आहे. हे चुकीचे आहे.

उदाहरणार्थ, एक मोनोलिथ आहे जो 300 लोकांनी लिहिलेला आहे, आणि विकासात सहभागी झालेल्या प्रत्येकाला समजते की तेथे समस्या आहेत आणि ते सूक्ष्म तुकड्यांमध्ये मोडले पाहिजे - सुमारे 10 तुकडे, त्यातील प्रत्येक 30 लोकांनी लिहिलेले आहे. किमान आवृत्तीत. हे महत्वाचे, आवश्यक आणि थंड आहे. पण जेव्हा एखादा स्टार्टअप आमच्याकडे येतो, जिथे 3 अतिशय हुशार आणि हुशार लोकांनी त्यांच्या गुडघ्यावर 60 मायक्रोसर्व्हिसेस लिहून ठेवल्या, प्रत्येक वेळी मी Corvalol शोधतो.

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

सुरुवातीच्या प्रश्नासाठी, एकीकडे, कुबर्नेट्स वापरण्यास भितीदायक आहे या वस्तुस्थितीमध्ये संघर्ष आहे, कारण तेथे काय खंडित होऊ शकते किंवा कार्य करणार नाही हे स्पष्ट नाही, दुसरीकडे, हे स्पष्ट आहे की सर्व काही तेथे जाते. आणि कुबर्नेट्सशिवाय काहीही अस्तित्वात नाही. उत्तर - मिळणार्‍या फायद्याचे, तुम्ही सोडवू शकणार्‍या कार्यांचे प्रमाण मोजा. हे प्रमाणाच्या एका बाजूला आहे. दुसरीकडे, डाउनटाइमशी संबंधित जोखीम आहेत किंवा प्रतिसाद वेळ कमी होणे, उपलब्धतेची पातळी - कार्यप्रदर्शन निर्देशकांमध्ये घट.

हे असे आहे - एकतर आपण त्वरीत हालचाल करतो आणि Kubernetes आम्हाला बर्‍याच गोष्टी जलद आणि चांगल्या प्रकारे करण्याची परवानगी देतो किंवा आम्ही विश्वासार्ह, वेळ-चाचणी उपाय वापरतो, परंतु अधिक हळू चालतो. ही निवड प्रत्येक कंपनीने करणे आवश्यक आहे. तुम्ही याचा जंगलातील मार्ग म्हणून विचार करू शकता - जेव्हा तुम्ही पहिल्यांदा चालता तेव्हा तुम्हाला साप, वाघ किंवा वेडा बॅजर भेटू शकता आणि जेव्हा तुम्ही 10 वेळा चाललात, तेव्हा तुम्ही रस्ता तुडवलात, काढला होता. शाखा आणि सोपे चालणे. प्रत्येक वेळी वाट रुंद होत जाते. मग तो डांबरी रस्ता आणि नंतर एक सुंदर बुलेव्हार्ड.

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

स्टार्टअपने काय करावे या प्रश्नाचे उत्तर देताना, मी म्हणेन - फ्लॉंटवर या, 150 हजार रूबल द्या आणि टर्नकी DevOps सुलभ सेवा मिळवा. तुम्ही काही डेव्हलपर्ससह एक लहान स्टार्टअप असल्यास, हे कार्य करते. तुमचे स्वतःचे DevOps कामावर घेण्याऐवजी, ज्यांना तुमच्या समस्यांचे निराकरण कसे करावे आणि यावेळी पगार कसा द्यावा हे शिकण्याची आवश्यकता असेल, तुम्हाला सर्व समस्यांचे समाधान मिळेल. होय, काही तोटे आहेत. आम्ही, आउटसोर्सर म्हणून, इतके सहभागी होऊ शकत नाही आणि बदलांना त्वरीत प्रतिसाद देऊ शकत नाही. पण आमच्याकडे बरेच कौशल्य आणि तयार पद्धती आहेत. आम्ही हमी देतो की कोणत्याही परिस्थितीत आम्ही ते निश्चितपणे त्वरीत शोधून काढू आणि कोणत्याही कुबर्नेट्सला मृतांमधून उठवू.

मी स्टार्टअप्स आणि स्थापित व्यवसायांसाठी आउटसोर्सिंगची जोरदार शिफारस करतो जिथे तुम्ही 10 लोकांची टीम ऑपरेशनसाठी समर्पित करू शकता, कारण अन्यथा काहीही अर्थ नाही. हे आउटसोर्स करण्यात नक्कीच अर्थ आहे.

Amazon आणि Google बद्दल

— Amazon किंवा Google कडील सोल्यूशनमधील होस्टला आउटसोर्स मानले जाऊ शकते?

दिमित्री: होय, नक्कीच, यामुळे अनेक समस्यांचे निराकरण होते. पण पुन्हा बारकावे आहेत. ते कसे वापरावे हे आपल्याला अद्याप समजून घेणे आवश्यक आहे. उदाहरणार्थ, Amazon AWS च्या कामात हजारो छोट्या गोष्टी आहेत: लोड बॅलन्सर गरम करणे आवश्यक आहे किंवा आगाऊ विनंती लिहिणे आवश्यक आहे की "मित्रांनो, आम्हाला रहदारी मिळेल, आमच्यासाठी लोड बॅलन्सर गरम करा!" आपल्याला या बारकावे माहित असणे आवश्यक आहे.

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

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

म्हणून, उत्तर होय आहे, परंतु, खरं तर, तेथे बरेच प्रौढ होस्ट केलेले उपाय नाहीत.

कुबर्नेट्सची कोणाला गरज आहे?

- आणि तरीही, कुबर्नेट्सची कोणाला गरज आहे? कुबर्नेट्सवर आधीपासून कोणी स्विच केले पाहिजे, विशेषत: कुबर्नेट्ससाठी येणारा ठराविक फ्लॉंट क्लायंट कोण आहे?

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

आमचे क्लायंट वेगवेगळ्या गोष्टींची अपेक्षा करतात, परंतु प्रत्येकजण काही चांगल्या चमत्काराची वाट पाहत आहे की त्यांना काही समस्या आहेत आणि आता - हॉप! - कुबर्नेट्स त्यांचे निराकरण करतील. लोक चमत्कारांवर विश्वास ठेवतात. त्यांच्या मनात ते समजतात की कोणताही चमत्कार होणार नाही, परंतु त्यांच्या आत्म्यामध्ये त्यांना आशा आहे - जर हे कुबरनेट आता आपल्यासाठी सर्वकाही सोडवेल तर ते याबद्दल खूप बोलतात! अचानक तो आता - शिंक! - आणि एक चांदीची गोळी, शिंक! - आणि आमच्याकडे 100% अपटाइम आहे, सर्व डेव्हलपर जे काही उत्पादनात 50 वेळा रिलीज करू शकतात आणि ते क्रॅश होत नाही. सर्वसाधारणपणे, एक चमत्कार!

जेव्हा असे लोक आमच्याकडे येतात तेव्हा आम्ही म्हणतो: "माफ करा, परंतु चमत्कार असे काहीही नाही." निरोगी राहण्यासाठी, आपल्याला चांगले खाणे आणि व्यायाम करणे आवश्यक आहे. एक विश्वासार्ह उत्पादन मिळविण्यासाठी, ते विश्वसनीयरित्या तयार करणे आवश्यक आहे. सोयीस्कर CI/CD असण्यासाठी, तुम्हाला ते असे बनवावे लागेल. त्यासाठी खूप काम करावे लागेल.

कुबर्नेट्सची कोणाला गरज आहे या प्रश्नाचे उत्तर देताना - कोणालाही कुबर्नेट्सची गरज नाही.

काही लोकांचा असा गैरसमज आहे की त्यांना कुबरनेटची गरज आहे. लोकांना गरज आहे, त्यांना विचार करणे, अभ्यास करणे आणि पायाभूत सुविधांच्या सर्व समस्या आणि त्यांचे अनुप्रयोग चालवण्याच्या समस्यांमध्ये रस असणे थांबवण्याची खोल गरज आहे. त्यांना अनुप्रयोगांनी फक्त काम करायचे आहे आणि फक्त तैनात करायचे आहे. त्यांच्यासाठी, Kubernetes ही आशा आहे की ते "आम्ही तिथे पडून होतो," किंवा "आम्ही बाहेर पडू शकत नाही," किंवा आणखी काहीतरी ऐकणे थांबवतील.

तांत्रिक संचालक सहसा आमच्याकडे येतात. ते त्याला दोन गोष्टी विचारतात: एकीकडे, आम्हाला वैशिष्ट्ये द्या, दुसरीकडे, स्थिरता. आम्ही सुचवितो की तुम्ही ते स्वतःवर घ्या आणि ते करा. सिल्व्हर बुलेट, किंवा ऐवजी चांदीचा मुलामा, आपण या समस्यांबद्दल विचार करणे आणि वेळ वाया घालवणे थांबवाल. तुमच्याकडे खास लोक असतील जे हा मुद्दा बंद करतील.

आम्हाला किंवा इतर कोणालाही कुबर्नेट्सची गरज आहे असा शब्दप्रयोग चुकीचा आहे.

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

उत्पादनाशी खेळण्याची गरज नाही. मी स्पष्टपणे जे काही करू नये अशी शिफारस करतो आणि जे मी आता एकत्रितपणे पाहतो: "अरे, एक नवीन खेळणी!" - ते विकत घेण्यासाठी धावले, ते विकत घेतले आणि: "चला आता शाळेत घेऊन जाऊ आणि आमच्या सर्व मित्रांना दाखवू." असे करू नका. मी माफी मागतो, माझी मुले नुकतीच मोठी होत आहेत, मी सतत मुलांमध्ये काहीतरी पाहतो, ते स्वतःमध्ये लक्षात घेतो आणि नंतर ते इतरांना सामान्यीकृत करतो.

अंतिम उत्तर आहे: तुम्हाला कुबर्नेट्सची गरज नाही. तुम्हाला तुमच्या समस्या सोडवायला हव्यात.

आपण काय साध्य करू शकता ते आहे:

• उत्पादन पडत नाही;
• जरी त्याने पडण्याचा प्रयत्न केला, तरीही आपल्याला त्याबद्दल आधीच माहित आहे आणि तेथे काहीतरी ठेवू शकतो;
• आमच्या व्यवसायाला आवश्यक असलेल्या वेगाने आम्ही ते बदलू शकतो आणि आम्ही ते सोयीस्करपणे करू शकतो; यामुळे आम्हाला कोणतीही अडचण येत नाही.

दोन वास्तविक गरजा आहेत: विश्वासार्हता आणि गतिशीलता/रोलआउटची लवचिकता. प्रत्येकजण जो सध्या काही प्रकारचे आयटी प्रकल्प करत आहे, मग तो कोणत्याही प्रकारचा व्यवसाय असो - जग सुलभ करण्यासाठी मऊ, आणि ज्यांना हे समजले आहे, त्यांना या गरजा सोडवण्याची गरज आहे. योग्य दृष्टीकोन, योग्य समज आणि पुरेसा अनुभव असलेले कुबर्नेट्स तुम्हाला त्यांचे निराकरण करण्यास अनुमती देतात.

सर्व्हरलेस बद्दल

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

दिमित्री: इथे पुन्हा एक टिपण्णी करणे आवश्यक आहे की मी काही द्रष्टा नाही जो पुढे पाहून म्हणतो - असे होईल! जरी मी फक्त तेच केले. मी माझ्या पायांकडे पाहतो आणि तेथे समस्यांचा एक समूह पाहतो, उदाहरणार्थ, ट्रान्झिस्टर संगणकात कसे कार्य करतात. हे मजेदार आहे, बरोबर? आम्हाला CPU मध्ये काही बग येत आहेत.

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

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

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

कुबर्नेट्स कसे विकसित होतील

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

दिमित्री: मी यावर खूप विचार केला आहे आणि माझ्याकडे स्पष्ट उत्तर आहे. पहिले स्टेटफुल आहे - शेवटी, स्टेटलेस करणे सोपे आहे. कुबर्नेट्सने सुरुवातीला यामध्ये अधिक गुंतवणूक केली, हे सर्व त्याच्यापासून सुरू झाले. कुबर्नेट्समध्ये स्टेटलेस जवळजवळ उत्तम प्रकारे कार्य करते, तक्रार करण्यासारखे काहीच नाही. अजूनही बर्‍याच समस्या आहेत, किंवा त्याऐवजी, बारकावे आहेत. तेथे सर्व काही आमच्यासाठी चांगले कार्य करते, परंतु ते आम्ही आहोत. हे सर्वांसाठी कार्य करण्यासाठी आणखी किमान दोन वर्षे लागतील. हे गणना केलेले सूचक नाही, परंतु माझ्या डोक्यातून आलेली भावना आहे.

थोडक्‍यात, स्टेटफुलने - आणि होईल - खूप मजबूतपणे विकसित केले पाहिजे, कारण आमचे सर्व अॅप्लिकेशन स्टेटस स्टोअर करतात; कोणतेही स्टेटलेस अॅप्लिकेशन नाहीत. हा एक भ्रम आहे; तुम्हाला नेहमी कोणत्या ना कोणत्या प्रकारचा डेटाबेस आणि दुसरे काहीतरी हवे असते. स्टेटफुल म्हणजे जे काही शक्य आहे ते सरळ करणे, सर्व दोषांचे निराकरण करणे, सध्या भेडसावत असलेल्या सर्व समस्या सुधारणे - याला आपण दत्तक म्हणू या.

अज्ञात पातळी, निराकरण न झालेल्या समस्यांची पातळी, काहीतरी समोर येण्याच्या संभाव्यतेची पातळी लक्षणीयरीत्या कमी होईल. ही एक महत्त्वाची कथा आहे. आणि ऑपरेटर - प्रशासनाच्या तर्कशास्त्राच्या कोडिफिकेशनशी संबंधित सर्व काही, सुलभ सेवा मिळविण्यासाठी नियंत्रण तर्कशास्त्र: MySQL सुलभ सेवा, RabbitMQ सुलभ सेवा, Memcache सुलभ सेवा - सर्वसाधारणपणे, हे सर्व घटक ज्यांच्यावर कार्य करण्यासाठी आम्हाला हमी देणे आवश्यक आहे. बॉक्स हे फक्त वेदना सोडवते की आम्हाला डेटाबेस हवा आहे, परंतु आम्हाला ते प्रशासित करायचे नाही, किंवा आम्हाला कुबर्नेट्स हवे आहेत, परंतु आम्हाला ते प्रशासित करायचे नाहीत.

ऑपरेटरच्या विकासाची ही कहाणी एका ना कोणत्या स्वरूपात येत्या काही वर्षांत महत्त्वाची ठरेल.

मला वाटते की वापरण्याची सुलभता मोठ्या प्रमाणात वाढली पाहिजे - बॉक्स अधिकाधिक काळा होईल, अधिकाधिक विश्वासार्ह होईल, अधिकाधिक साध्या नॉब्ससह.

मी एकदा 80 च्या दशकातील आयझॅक असिमोव्हची जुनी मुलाखत YouTube वर शनिवारी रात्री लाइव्हवर ऐकली - Urgant सारखा कार्यक्रम, फक्त मनोरंजक. त्यांनी त्याला संगणकाच्या भविष्याबद्दल विचारले. ते म्हणाले की, भविष्य हे रेडिओप्रमाणेच साधेपणात आहे. रेडिओ रिसीव्हर ही मुळात एक गुंतागुंतीची गोष्ट होती. लाट पकडण्यासाठी, तुम्हाला 15 मिनिटांसाठी नॉब्स फिरवावे लागतील, स्क्युअर्स फिरवावे लागतील आणि सामान्यत: सर्वकाही कसे कार्य करते हे जाणून घ्या, रेडिओ वेव्ह ट्रान्समिशनचे भौतिकशास्त्र समजून घ्या. परिणामी, रेडिओमध्ये एकच घुटमळत राहिली.

आता 2019 मध्ये कोणता रेडिओ? कारमध्ये, रेडिओ रिसीव्हरला सर्व लहरी आणि स्थानकांची नावे सापडतात. प्रक्रियेचे भौतिकशास्त्र 100 वर्षांत बदललेले नाही, परंतु वापरण्यास सुलभता आहे. आता, आणि फक्त आताच नाही, आधीच 1980 मध्ये, जेव्हा अझिमोव्हची मुलाखत होती, तेव्हा प्रत्येकाने रेडिओ वापरला आणि ते कसे कार्य करते याबद्दल कोणीही विचार केला नाही. हे नेहमीच कार्य करते - ते दिले आहे.

अझीमोव्ह म्हणाले की संगणकांबाबतही असेच होईल - वापर सुलभता वाढेल. 1980 मध्ये तुम्हाला संगणकावरील बटणे दाबण्यासाठी प्रशिक्षित करावे लागले, परंतु भविष्यात असे होणार नाही.

मला असे वाटते की कुबर्नेट्स आणि पायाभूत सुविधांसह वापरण्याच्या सुलभतेतही मोठी वाढ होईल. हे, माझ्या मते, स्पष्ट आहे - ते पृष्ठभागावर आहे.

अभियंत्यांचे काय करायचे?

— मग कुबर्नेट्सचे समर्थन करणारे अभियंते आणि सिस्टम प्रशासकांचे काय होईल?

दिमित्री: ‘सी’च्या आगमनानंतर अकाउंटंटचे काय झाले? त्याच बद्दल. या आधी, ते कागदावर मोजले - आता कार्यक्रमात. श्रम उत्पादकता प्रचंड प्रमाणात वाढली आहे, परंतु श्रम स्वतःच नाहीसे झाले नाहीत. जर पूर्वी एका लाइट बल्बमध्ये स्क्रू करण्यासाठी 1 अभियंते लागायचे, तर आता एक पुरेसे असेल.

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

पण तरीही कोणीतरी निर्णय घेणे आवश्यक आहे. हे स्पष्ट आहे की या व्यक्तीची पात्रता आणि स्पेशलायझेशनची पातळी जास्त आहे. आजकाल, लेखा विभागात, आपल्याला पुस्तके ठेवण्यासाठी 10 कर्मचाऱ्यांची गरज नाही जेणेकरून त्यांचे हात थकू नये. हे फक्त आवश्यक नाही. इलेक्ट्रॉनिक दस्तऐवज व्यवस्थापन प्रणालीद्वारे अनेक दस्तऐवज स्वयंचलितपणे स्कॅन केले जातात आणि ओळखले जातात. एक हुशार चीफ अकाउंटंट पुरेसा आहे, आधीच जास्त कौशल्ये, चांगली समज.

सर्वसाधारणपणे, सर्व उद्योगांमध्ये जाण्याचा हा मार्ग आहे. कारच्या बाबतीतही असेच आहे: पूर्वी, एक कार मेकॅनिक आणि तीन ड्रायव्हर्ससह आली होती. आजकाल, कार चालवणे ही एक सोपी प्रक्रिया आहे ज्यामध्ये आपण सर्वजण दररोज सहभागी होतो. कार काहीतरी क्लिष्ट आहे असे कोणालाही वाटत नाही.

DevOps किंवा सिस्टम अभियांत्रिकी दूर होणार नाही - उच्च-स्तरीय कार्य आणि कार्यक्षमता वाढेल.

- मी एक मनोरंजक कल्पना देखील ऐकली की काम प्रत्यक्षात वाढेल.

दिमित्री: नक्कीच, शंभर टक्के! कारण आपण लिहित असलेल्या सॉफ्टवेअरचे प्रमाण सतत वाढत आहे. आम्ही सॉफ्टवेअरद्वारे सोडवलेल्या समस्यांची संख्या सतत वाढत आहे. कामाचे प्रमाण वाढत आहे. आता DevOps मार्केट कमालीचे गरम झाले आहे. हे पगाराच्या अपेक्षांमध्ये पाहिले जाऊ शकते. चांगल्या प्रकारे, तपशीलात न जाता, X पाहिजे असलेले कनिष्ठ, 1,5X हवे असलेले मध्यम आणि 2X हवे असलेले वरिष्ठ असावेत. आणि आता, जर तुम्ही मॉस्को DevOps पगार बाजार पाहिला तर, एका कनिष्ठाला X ते 3X पर्यंत आणि वरिष्ठांना X ते 3X पर्यंत हवे आहेत.

त्याची किंमत किती आहे हे कोणालाच माहीत नाही. पगाराची पातळी तुमच्या आत्मविश्वासाने मोजली जाते - एक संपूर्ण वेडहाउस, खरे सांगायचे तर, खूप गरम झालेले बाजार.

अर्थात, ही परिस्थिती लवकरच बदलेल - काही संपृक्तता आली पाहिजे. सॉफ्टवेअर डेव्हलपमेंटच्या बाबतीत असे होत नाही - प्रत्येकाला डेव्हलपर्सची गरज असते आणि प्रत्येकाला चांगल्या डेव्हलपरची गरज असते हे असूनही, मार्केटला समजते की कोणाची किंमत आहे - उद्योग स्थिर झाला आहे. आजकाल DevOps च्या बाबतीत असे नाही.

- मी जे ऐकले त्यावरून, मी असा निष्कर्ष काढला की सध्याच्या सिस्टम प्रशासकाने जास्त काळजी करू नये, परंतु त्याची कौशल्ये सुधारण्याची आणि उद्या आणखी काम होईल, परंतु ते अधिक पात्र असेल या वस्तुस्थितीसाठी तयारी करण्याची वेळ आली आहे.

दिमित्री: शंभर टक्के. सर्वसाधारणपणे, आम्ही 2019 मध्ये जगतो आणि जीवनाचा नियम असा आहे: आजीवन शिक्षण - आपण आयुष्यभर शिकतो. मला असे दिसते की आता प्रत्येकाला हे आधीच माहित आहे आणि जाणवते, परंतु हे जाणून घेणे पुरेसे नाही - आपल्याला ते करावे लागेल. दररोज आपण बदलले पाहिजे. जर आपण हे केले नाही तर आज ना उद्या आपल्याला व्यवसायाच्या बाजूला टाकले जाईल.

तीक्ष्ण 180-डिग्री वळणांसाठी तयार रहा. मी अशी परिस्थिती नाकारत नाही जिथे काहीतरी आमूलाग्र बदलते, काहीतरी नवीन शोधले जाते - ते घडते. हॉप! - आणि आम्ही आता वेगळ्या पद्धतीने वागतो. यासाठी तयार राहणे आणि काळजी न करणे महत्त्वाचे आहे. असे होऊ शकते की उद्या मी जे काही करतो ते अनावश्यक ठरेल - काहीही नाही, मी आयुष्यभर अभ्यास केला आहे आणि काहीतरी शिकण्यास तयार आहे. तो एक समस्या नाही. नोकरीच्या सुरक्षिततेची भीती बाळगण्याची गरज नाही, परंतु सतत काहीतरी नवीन शिकण्याची तयारी हवी.

शुभेच्छा आणि जाहिरात एक मिनिट

- तुमची काही इच्छा आहे का?

दिमित्री: होय, माझ्या अनेक इच्छा आहेत.

प्रथम आणि व्यापारी - याची सदस्यता घ्या YouTube वर. प्रिय वाचकांनो, YouTube वर जा आणि आमच्या चॅनेलची सदस्यता घ्या. सुमारे एका महिन्यात आम्ही व्हिडिओ सेवेचा सक्रिय विस्तार सुरू करू. आमच्याकडे कुबर्नेट्सबद्दल भरपूर शैक्षणिक सामग्री असेल, खुली आणि वैविध्यपूर्ण: व्यावहारिक गोष्टींपासून ते अगदी प्रयोगशाळांपर्यंत, सखोल मूलभूत सैद्धांतिक गोष्टींपर्यंत आणि कुबर्नेट्सचा वापर कसा करावा. तत्त्वे आणि नमुन्यांची पातळी.

दुसरी व्यापारी इच्छा - जा GitHub आणि तारे लावा कारण आम्ही त्यांना खातो. जर तुम्ही आम्हाला तारे दिले नाहीत तर आमच्याकडे खायला काही नसेल. हे कॉम्प्युटर गेममधील मानासारखे आहे. आम्ही काहीतरी करतो, आम्ही करतो, आम्ही प्रयत्न करतो, कोणीतरी म्हणतो की या भयानक सायकली आहेत, कोणीतरी म्हणतो की सर्वकाही पूर्णपणे चुकीचे आहे, परंतु आम्ही सुरू ठेवतो आणि अगदी प्रामाणिकपणे वागतो. आम्ही समस्या पाहतो, ती सोडवतो आणि आमचे अनुभव शेअर करतो. म्हणून, आम्हाला एक तारा द्या, तो तुमच्यापासून दूर जाणार नाही, परंतु तो आमच्याकडे येईल, कारण आम्ही त्यांना खातो.

तिसरी, महत्त्वाची आणि यापुढे व्यापारी इच्छा - परीकथांवर विश्वास ठेवणे थांबवा. तुम्ही व्यावसायिक आहात. DevOps हा एक अतिशय गंभीर आणि जबाबदार व्यवसाय आहे. कामाच्या ठिकाणी खेळणे थांबवा. ते तुमच्यासाठी क्लिक करू द्या आणि तुम्हाला ते समजेल. कल्पना करा की तुम्ही हॉस्पिटलमध्ये आलात आणि तिथे डॉक्टर तुमच्यावर प्रयोग करत आहेत. मला समजले आहे की हे एखाद्यासाठी आक्षेपार्ह असू शकते, परंतु, बहुधा, हे आपल्याबद्दल नाही, परंतु इतर कोणाबद्दल आहे. इतरांनाही थांबायला सांगा. यामुळे खरोखरच आपल्या सर्वांचे आयुष्य उद्ध्वस्त होते - बरेच जण ऑपरेशन्स, अॅडमिन आणि DevOps यांना पुन्हा काहीतरी तोडलेले मित्र मानू लागतात. आम्ही खेळायला गेलो होतो या वस्तुस्थितीमुळे हे "तुटलेले" होते, आणि हे असे आहे आणि ते असेच आहे असे थंड जाणीवेने पाहिले नाही.

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

- खूप खूप धन्यवाद!

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

मुलाखतीत दिमित्रीने वेर्फच्या मुद्द्याला स्पर्श केला. आता हे एक सार्वत्रिक स्विस चाकू आहे जे जवळजवळ सर्व समस्यांचे निराकरण करते. पण नेहमीच असे नव्हते. चालू DevOpsConf  उत्सवात RIT++ दिमित्री स्टोल्यारोव्ह तुम्हाला या साधनाबद्दल तपशीलवार सांगतील. अहवालात "werf हे Kubernetes मधील CI/CD साठी आमचे साधन आहे" तेथे सर्वकाही असेल: कुबर्नेट्सच्या समस्या आणि लपलेल्या बारकावे, या अडचणी सोडवण्याचे पर्याय आणि वेर्फची ​​सद्य अंमलबजावणी तपशीलवार. 27 आणि 28 मे रोजी आमच्यात सामील व्हा, आम्ही परिपूर्ण साधने तयार करू.

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