Kubernetes ले संसारलाई कब्जा गर्नेछ। कहिले र कसरी?

प्रत्याशा मा DevOpsConf Vitaly Khabarov अन्तर्वार्ता गरे दिमित्री Stolyarov (डिस्टोल), प्राविधिक निर्देशक र फ्ल्यान्ट कम्पनीको सह-संस्थापक। भिटालीले दिमित्रीलाई फ्ल्यान्टले के गर्छ, कुबर्नेट्स, इकोसिस्टम विकास, समर्थनको बारेमा सोधे। Kubernetes किन आवश्यक छ र यो आवश्यक छ कि छैन भनेर हामीले छलफल गर्यौं। र माइक्रोसर्भिसेसको बारेमा, Amazon AWS, DevOps को लागी "म भाग्यशाली हुनेछु" दृष्टिकोण, कुबेरनेट आफैंको भविष्य, किन, कहिले र कसरी यसले संसारलाई ओगटेको छ, DevOps को सम्भावनाहरू र ईन्जिनियरहरूले केको लागि तयारी गर्नुपर्छ। सरलीकरण र तंत्रिका नेटवर्क संग उज्ज्वल र निकट भविष्य।

मौलिक अन्तर्वार्ता DevOps Deflop मा पोडकास्टको रूपमा सुन्नुहोस् - DevOps बारे रूसी भाषाको पोडकास्ट, र तल पाठ संस्करण छ।

यहाँ र तल उसले प्रश्न सोध्छ Vitaly Khabarov एक्सप्रेस 42 बाट इन्जिनियर।

"Flant" को बारेमा

- नमस्ते दिमा। तपाईं प्राविधिक निर्देशक हुनुहुन्छ "फ्ल्यान्ट"र यसको संस्थापक पनि। कृपया हामीलाई भन्नुहोस् कि कम्पनी के गर्छ र तपाई यसमा के हुनुहुन्छ?

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




म, प्राविधिक निर्देशक र कम्पनीको संस्थापक मध्ये एकको रूपमा, उत्पादनको पहुँच कसरी बढाउने, यसको सञ्चालनलाई सरल बनाउने, प्रशासकहरूको जीवनलाई सजिलो बनाउने र विकासकर्ताहरूको जीवनलाई अझ रमाइलो बनाउने प्रयासमा दिनरात खर्च गर्छु। ।

Kubernetes को बारेमा

- हालै मैले फ्ल्यान्ट र बाट धेरै रिपोर्टहरू हेर्दै छु लेखहरू Kubernetes को बारेमा यसमा कसरी आयो ?

दिमित्री: मैले यसबारे धेरै पटक कुरा गरिसकेको छु, तर दोहोर्‍याउन मलाई कुनै आपत्ति छैन। कारण र प्रभाव बीचको भ्रम रहेकोले यो विषय दोहोर्‍याउनु उचित हो जस्तो मलाई लाग्छ।

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

Kubernetes संग कथा समान छ। जब सम्म यसले गति लिन थाल्यो - हाम्रो लागि यो संस्करण १.२ हो - हामीसँग शेल र शेफ दुबैमा बैसाखीको गुच्छा थियो, जसलाई हामीले कुनै न कुनै रूपमा डकरसँग अर्केस्ट्रेट गर्ने प्रयास गर्यौं। हामी गम्भीरताका साथ Rancher र अन्य विभिन्न समाधानहरू तर्फ हेरिरहेका थियौं, तर त्यसपछि Kubernetes देखा पर्‍यो, जसमा सबै कुरा ठ्याक्कै लागू गरिएको छ जसरी हामीले यो गरेको हुन्छौं वा अझ राम्रो हुन्छ। गुनासो गर्नुपर्ने केही छैन ।

हो, यहाँ केहि प्रकारको अपूर्णता छ, त्यहाँ केहि प्रकारको अपूर्णता छ - त्यहाँ धेरै त्रुटिहरू छन्, र 1.2 सामान्यतया डरलाग्दो छ, तर... Kubernetes निर्माणाधीन भवन जस्तै हो - तपाईं परियोजना हेर्नुहुन्छ र बुझ्नुहुन्छ। कि यो चिसो हुनेछ। यदि भवनमा अहिले जग र दुई तलाहरू छन् भने, त्यसोभए तपाईंले बुझ्नुहुन्छ कि यो अझै भित्र न सर्नु राम्रो हो, तर सफ्टवेयरमा त्यस्ता समस्याहरू छैनन् - तपाइँ पहिले नै यसलाई प्रयोग गर्न सक्नुहुन्छ।

हामीसँग कुनै पल थिएन जहाँ हामीले कुबर्नेट्स प्रयोग गर्ने वा नगर्ने बारे सोच्यौं। हामी यो देखा पर्नु भन्दा पहिले यसको लागि पर्खिरहेका थियौं, र आफैले एनालॉगहरू सिर्जना गर्ने प्रयास गर्यौं।

Kubernetes को बारेमा

- के तपाईं कुबेरनेटको विकासमा प्रत्यक्ष संलग्न हुनुहुन्छ?

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

- एकै समयमा, के तपाइँ Kubernetes वरपर तपाइँका धेरै उपकरणहरू विकास गर्नुहुन्छ?

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

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

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

बाटो सधैं यस्तो हुन्छ: हामी धेरै सावधानीपूर्वक खोज्छौं र, यदि हामीले रोटीको रोटीबाट ट्रलीबस कसरी बनाउने भन्ने बारे कुनै समाधान फेला पारेनौं भने, हामी आफ्नै रोटी र आफ्नै ट्रलीबस बनाउँछौं।

फ्लान्टा उपकरणहरू

— मलाई थाहा छ कि फ्ल्यान्टसँग अब एडन अपरेटरहरू, शेल अपरेटरहरू, र ड्याप/वेर्फ उपकरणहरू छन्। मैले बुझे अनुसार, यो विभिन्न अवतारहरूमा एउटै उपकरण हो। म यो पनि बुझ्छु कि Flaunt भित्र धेरै धेरै फरक उपकरणहरू छन्। यो सत्य हो?

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

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

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

"मलाई लाग्छ कि यो उपकरणको विकास र यसको प्रयोग विधिहरूको लागि यो धेरै ठूलो योगदान हो।" इकोसिस्टमको विकासमा अरू कसले योगदान पुर्‍याउँछ भनेर लगभग अनुमान लगाउन सक्नुहुन्छ?

दिमित्री: रूसमा, हाम्रो बजारमा काम गर्ने कम्पनीहरू मध्ये, कोही पनि नजिक छैन। निस्सन्देह, यो एक ठूलो कथन हो, किनकि त्यहाँ मेल र यान्डेक्स जस्ता प्रमुख खेलाडीहरू छन् - तिनीहरू पनि Kubernetes सँग केहि गर्दैछन्, तर तिनीहरू पनि हामी भन्दा धेरै काम गर्ने सम्पूर्ण संसारमा कम्पनीहरूको योगदानको नजिक आउँदैनन्। ८० जना कर्मचारी भएको फ्ल्यान्ट र प्रति कुबेरनेटमा ३०० इन्जिनियरहरू भएको रेड ह्याटसँग तुलना गर्न गाह्रो छ, यदि म गलत छैन भने। तुलना गर्न गाह्रो छ। हामीसँग RnD विभागमा 80 जना छन्, म सहित, जसले हाम्रा सबै उपकरणहरू काटिदिए। 300 Red Hat इन्जिनियरहरू विरुद्ध 6 व्यक्तिहरू - यो तुलना गर्न कुनै न कुनै रूपमा गाह्रो छ।

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

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

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

यो dapp/werf सँग हाम्रो ठूलो रणनीतिको अंश हो। हामीले यसलाई कहिले बनाउन थालेको मलाई याद छैन, यो 3 वर्ष पहिले जस्तो देखिन्छ। सुरुमा, यो सामान्यतया खोल मा थियो। यो अवधारणाको एक सुपर प्रमाण थियो, हामीले हाम्रा केही विशेष समस्याहरू समाधान गर्यौं - यसले काम गर्‍यो! तर शेलमा समस्याहरू छन्, यसलाई विस्तार गर्न असम्भव छ, शेलमा प्रोग्रामिङ अर्को कार्य हो। हामीलाई रुबीमा लेख्ने बानी थियो, त्यसैअनुरूप रुबीमा केही न केही रिमेक गर्‍यौं, बिकास गर्‍यौं, विकास गर्‍यौं, विकास गर्‍यौं र “हामीलाई यो चाहियो वा नचाहेको” भन्ने समुदाय, भीड भन्ने तथ्यमा दौडियो। रुबीमा नाक घुमाउँछ, यो कसरी हास्यास्पद छैन? हामीले चेकलिस्टको पहिलो बिन्दु भेट्नको लागि Go मा यी सबै सामानहरू लेख्नुपर्छ भनेर हामीले महसुस गर्यौं: DevOps उपकरण स्थिर बाइनरी हुनुपर्छ। Go हुनु वा नहुनु त्यति महत्त्वपूर्ण छैन, तर Go मा लेखिएको स्थिर बाइनरी राम्रो छ।

हामीले हाम्रो ऊर्जा खर्च गर्यौं, गो मा ड्यापलाई पुन: लेख्यौं र यसलाई werf भनियो। Dapp अब समर्थित छैन, विकसित गरिएको छैन, केहि नवीनतम संस्करणमा चलिरहेको छ, तर शीर्षमा एक निरपेक्ष स्तरवृद्धि मार्ग छ, र तपाइँ यसलाई पछ्याउन सक्नुहुन्छ।

ड्याप किन बनाइयो ?

— ड्याप किन सिर्जना गरियो, यसले कस्ता समस्याहरू समाधान गर्छ भनी छोटकरीमा भन्न सक्नुहुन्छ?

दिमित्री: पहिलो कारण सभामा छ। प्रारम्भमा, डकरसँग बहु-चरण क्षमताहरू नभएको बेला हामीलाई निर्माणमा गम्भीर समस्याहरू थिए, त्यसैले हामीले आफ्नै रूपमा बहु-चरण बनायौं। त्यसोभए हामीसँग छवि सफा गर्ने धेरै समस्याहरू थिए। CI/CD गर्ने सबैजनाले चाँडो भन्दा चाँडो, सङ्कलन गरिएका तस्बिरहरूको गुच्छा रहेको समस्याको सामना गर्नुपरेको छ, तपाईंले कुनै न कुनै रूपमा सफा गर्न आवश्यक छ र के आवश्यक छ छोड्नुपर्छ।

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

यो चाखलाग्दो छ कि हामी भन्छौं: "हेल्म, प्याकेज स्थापना गर्नुहोस्," र जब उसले जवाफ दियो कि उसले यसलाई स्थापना गर्यो, यो बाहिर जान्छ कि उसले भर्खर स्थापना सुरु गर्यो - उसले कुबर्नेट्सलाई संकेत गर्यो: "यो चीज सुरु गर्नुहोस्!", र यो सुरु भयो वा भएन। , यसले काम गर्छ वा गर्दैन, हेलमले यो समस्या समाधान गर्दैन।

यो बाहिर जान्छ कि हेलम केवल एक पाठ प्रिप्रोसेसर हो जसले डेटा Kubernetes मा लोड गर्दछ।

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

योजनाहरु

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

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

तर dapp/werf को बाटो सधैं सुरुमा Kubernetes सँग जस्तै भएको छ। हामीले समस्याहरूको सामना गर्यौं, तिनीहरूलाई समाधानका साथ समाधान गर्‍यौं - हामी शेलमा, कुनै पनि कुरामा आफ्नै लागि केही समाधानहरू लिएर आएका छौं। त्यसपछि तिनीहरूले कुनै न कुनै रूपमा यी समाधानहरू सीधा गर्ने प्रयास गरे, सामान्यीकरण र तिनीहरूलाई यस अवस्थामा बाइनरीहरूमा एकीकृत गर्नुहोस्, जुन हामी केवल साझा गर्छौं।

यस सम्पूर्ण कथालाई समानतासहित हेर्ने अर्को तरिका छ।

Kubernetes एउटा इन्जिन भएको कार फ्रेम हो। त्यहाँ कुनै ढोका, गिलास, रेडियो, क्रिसमस रूख छैन - केहि पनि छैन। केवल फ्रेम र इन्जिन। र त्यहाँ हेल्म छ - यो स्टीयरिंग व्हील हो। कूल - त्यहाँ एक स्टीयरिंग व्हील छ, तर तपाइँलाई स्टीयरिंग पिन, स्टीयरिंग र्याक, गियरबक्स र पाङ्ग्राहरू पनि चाहिन्छ, र तपाइँ ती बिना गर्न सक्नुहुन्न।

werf को मामला मा, यो Kubernetes को अर्को घटक हो। अब मात्र werf को अल्फा संस्करण मा, उदाहरण को लागी, Helm werf भित्र कम्पाइल गरिएको छ, किनकि हामी आफैं यो गर्न थाकेका छौं। यसो गर्नका लागि धेरै कारणहरू छन्, म तपाइँलाई विस्तृत रूपमा बताउनेछु किन हामीले सम्पूर्ण हेल्मलाई टिलर भित्र werf संग कम्पाइल गर्यौं। RIT++ को रिपोर्टमा.

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

के Kubernetes को मर्मत गर्न गाह्रो छ?

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

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

— जहाँसम्म मलाई थाहा छ र मैले देखेको छु, अब धेरै टोलीहरू कुबर्नेट्स प्रयास गर्न चाहन्छन्। सबैजना आफैले यसलाई प्रयोग गर्छन्, यसलाई आफ्नो घुँडामा राख्छन्। मलाई एउटा अनुभूति छ कि मानिसहरूले सधैं यस प्रणालीको जटिलता बुझ्दैनन्।

दिमित्री: यस्तै हो ।

- यो उत्पादन तयार छ भनेर स्क्र्याचबाट Kubernetes लिन र स्थापना गर्न कति गाह्रो छ?

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

Kubernetes स्थापना गर्न र यसलाई काम गर्न सजिलो छ: कुखुरा! - स्थापित, त्यहाँ धेरै स्थापना विधिहरू छन्। तर समस्या उत्पन्न हुँदा के हुन्छ?

प्रश्नहरू सधैं उठ्छन् - हामीले अहिलेसम्म केलाई ध्यानमा राखेका छैनौं? हामीले अहिलेसम्म के गरेका छैनौं? कुन लिनक्स कर्नेल प्यारामिटरहरू गलत रूपमा निर्दिष्ट गरिएको थियो? प्रभु, हामीले तिनीहरूलाई उल्लेख पनि गरे?! कुन Kubernetes कम्पोनेन्टहरू हामीले डेलिभर गरेका छौं र कुन छैन? हजारौं प्रश्नहरू उठ्छन्, र तिनीहरूको जवाफ पाउन, तपाईंले यस उद्योगमा 15-20 वर्ष बिताउनु पर्छ।

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

मलाई Cilium के हो भनेर व्याख्या गरौं। Kubernetes को नेटवर्किंग उपप्रणाली को धेरै फरक कार्यान्वयन छ, र ती मध्ये एक धेरै राम्रो छ - Cilium। यसको अर्थ के हो? कर्नेलमा, केही समय पहिले कर्नेलका लागि हुकहरू लेख्न सम्भव भएको थियो, जसले कुनै न कुनै रूपमा सञ्जाल उपप्रणाली र अन्य विभिन्न उपप्रणालीहरूमा आक्रमण गर्छ, र तपाईंलाई कर्नेलमा ठूला टुक्राहरू बाइपास गर्न अनुमति दिन्छ।

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

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

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

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

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

र अद्भुत चिसो Cilium 30 वर्ष पुरानो छैन, यो अझै पुरानो छैन। Kubernetes को समान समस्या छ, प्रतिलिपि। त्यो Cilium पूर्ण रूपमा स्थापित छ, त्यो Kubernetes पूर्ण रूपमा स्थापित छ, तर जब उत्पादनमा केहि गल्ती हुन्छ, के तपाई गम्भीर परिस्थितिमा के गल्ती भयो भनेर तुरुन्तै बुझ्न सक्षम हुनुहुन्छ?

जब हामी भन्छौं कि यो Kubernetes कायम गर्न गाह्रो छ - होइन, यो धेरै सजिलो छ, र हो, यो अविश्वसनीय रूपमा गाह्रो छ। Kubernetes आफैमा राम्रो काम गर्दछ, तर एक अरब बारीकियों संग।

"म भाग्यमानी हुनेछु" दृष्टिकोणको बारेमा

- के त्यहाँ कम्पनीहरू छन् जहाँ यी सूक्ष्मताहरू देखा पर्ने लगभग ग्यारेन्टी छन्? मानौं Yandex ले अचानक सबै सेवाहरू Kubernetes मा स्थानान्तरण गर्छ, त्यहाँ ठूलो भार हुनेछ।

दिमित्री: होइन, यो भारको बारेमा कुराकानी होइन, तर सरल चीजहरूको बारेमा हो। उदाहरणका लागि, हामीसँग Kubernetes छ, हामीले त्यहाँ अनुप्रयोग तैनात गर्यौं। यो काम गरिरहेको छ भनेर कसरी थाहा छ? अनुप्रयोग क्र्यास भइरहेको छैन भनेर बुझ्नको लागि त्यहाँ कुनै तयार-निर्मित उपकरण छैन। त्यहाँ अलर्टहरू पठाउने कुनै तयार प्रणाली छैन; तपाईंले यी अलर्टहरू र प्रत्येक तालिका कन्फिगर गर्न आवश्यक छ। र हामी Kubernetes अद्यावधिक गर्दैछौं।

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

मानौं उसले कुनै न कुनै तरिकाले systemd वा अरू केहि अपडेट गर्छ, तर लिनक्स कर्नेलमा 4.16 सम्म यो अझ रमाइलो छ - जब तपाइँ C-समूहहरू मेटाउनुहुन्छ, तिनीहरू कर्नेलमा चुहावट हुन्छन् र वास्तवमा मेटिएका छैनन्। त्यसकारण, यो मेसिनमा काम गरेको एक महिना पछि, चूल्हाहरूको लागि मेमोरी तथ्याङ्कहरू हेर्न असम्भव हुनेछ। हामी एउटा फाइल निकाल्छौं, यसलाई प्रोग्राममा रोल गर्छौं, र एउटा फाइल 15 सेकेन्डको लागि रोल गर्छौं, किनभने कर्नेलले आफैंमा लाखौं सी-समूहहरू गणना गर्न धेरै समय लिन्छ, जुन मेटिएको जस्तो देखिन्छ, तर होइन - तिनीहरू लीक हुँदैछन्। ।

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

प्रश्न यो हो कि जब हामी बरफमा हिंड्छौं, हामीले पहिले नै मापन नगरेसम्म यसको मोटाई कहिले थाहा हुँदैन। धेरै मानिसहरू हिँड्छन् र चिन्ता नगर्नुहोस्, किनभने तिनीहरू पहिले हिडेका छन्।

मेरो दृष्टिकोणबाट, कुनै पनि प्रणाली सञ्चालनको सूक्ष्मता र जटिलता भनेको हाम्रो समस्याहरू समाधान गर्न बरफको मोटाई ठ्याक्कै पर्याप्त छ भनेर सुनिश्चित गर्नु हो। यो हामी कुरा गर्दैछौं।

IT मा, मलाई लाग्छ, त्यहाँ धेरै "म भाग्यशाली हुनेछु" दृष्टिकोणहरू छन्। धेरै मानिसहरू सफ्टवेयर स्थापना गर्छन् र सफ्टवेयर पुस्तकालयहरू प्रयोग गर्छन् आशामा कि तिनीहरू भाग्यशाली हुनेछन्। सामान्यतया, धेरै मानिसहरू भाग्यशाली छन्। सायद यसैले काम गर्छ।

— मेरो निराशावादी मूल्याङ्कनबाट, यो यस्तो देखिन्छ: जब जोखिमहरू उच्च हुन्छन्, र अनुप्रयोगले काम गर्नुपर्छ, तब Flaunt बाट समर्थन चाहिन्छ, सायद Red Hat बाट, वा तपाइँलाई तपाइँको आफ्नै आन्तरिक टोली चाहिन्छ विशेष गरी Kubernetes को लागि समर्पित, जुन तयार छ। यसलाई तान्न।

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

के हामीलाई कन्टेनर चाहिन्छ?

- के तपाइँ हामीलाई बताउन सक्नुहुन्छ कि रूसमा कुबर्नेट्स कत्तिको व्यापक छ?

दिमित्री: मसँग यो डाटा छैन, र म पक्का छैन कि यो अरू कसैसँग छ। हामी भन्छौं: "कुबर्नेट्स, कुबर्नेट्स," तर यस मुद्दालाई हेर्ने अर्को तरिका छ। मलाई पनि थाहा छैन कन्टेनरहरू कत्तिको फराकिलो छन्, तर मलाई इन्टरनेटमा रिपोर्टहरूबाट एउटा आंकडा थाहा छ कि 70% कन्टेनरहरू Kubernetes द्वारा व्यवस्थित छन्। यो संसारभरि एकदम ठूलो नमूना को लागी एक भरपर्दो स्रोत थियो।

त्यसपछि अर्को प्रश्न - के हामीलाई कन्टेनर चाहिन्छ? मेरो व्यक्तिगत भावना र फ्ल्यान्ट कम्पनीको समग्र स्थिति यो हो कि Kubernetes एक वास्तविक मानक हो।

कुबेरनेट बाहेक केही हुनेछैन।

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

यो स्पष्ट छ कि कसैलाई यो महसुस गर्न एक-दुई वर्ष लाग्छ, र कसैलाई एक दुई दशक लाग्छ। मलाई कुनै शंका छैन कि त्यहाँ Kubernetes र यो नयाँ रूप बाहेक केहि हुनेछैन: हामी अब अपरेटिङ सिस्टमलाई हानि गर्दैनौं, तर प्रयोग गर्दछौं। कोडको रूपमा पूर्वाधार, कोडको साथ मात्र होइन, तर yml - एक घोषणात्मक रूपमा वर्णन गरिएको पूर्वाधार। यो सधैं यस्तै रहिरहने भावना छ।

- अर्थात्, ती कम्पनीहरू जसले अझै कुबेरनेटमा स्विच गरेका छैनन् निश्चित रूपमा यसमा स्विच हुनेछन् वा विस्मरणमा रहनेछन्। मैले तिमीलाई सहि बुझेको छु?

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

CI/CD सँग सम्बन्धित सबै कुराहरू - जहाँ पनि निरन्तर डेलिभरी आवश्यक छ, जहाँ तपाइँ संस्करणहरू अद्यावधिक गर्न आवश्यक छ, सक्रिय परिवर्तनहरू गर्नुहोस्, जहाँ तपाइँ त्रुटि सहनशीलता निर्माण गर्न आवश्यक छ - केवल Kubernetes।

माइक्रो सेवाहरूको बारेमा

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

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

उदाहरणका लागि, त्यहाँ एक मोनोलिथ छ जुन 300 व्यक्तिहरूद्वारा लेखिएको छ, र विकासमा भाग लिने सबैले त्यहाँ समस्याहरू छन् भनी बुझ्दछन्, र यसलाई माइक्रो-टुक्राहरूमा तोड्नुपर्दछ - लगभग 10 टुक्राहरू, जसमध्ये प्रत्येक 30 व्यक्तिहरूले लेखेका छन्। न्यूनतम संस्करणमा। यो महत्त्वपूर्ण, आवश्यक र राम्रो छ। तर जब एउटा स्टार्टअप हामीकहाँ आउँछ, जहाँ ३ जना धेरै राम्रा र प्रतिभाशाली केटाहरूले आफ्नो घुँडामा ६० माइक्रोसर्विसेस लेखेका थिए, हरेक पटक म Corvalol खोज्छु।

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

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

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

Kubernetes स्थिर खडा छैन। फेरि प्रश्न: कुबर्नेट्स, एकातिर, 4-5 बाइनरीहरू छन्, अर्कोतर्फ, यो सम्पूर्ण इकोसिस्टम हो। यो हाम्रो मेसिनहरूमा रहेको अपरेटिङ सिस्टम हो। यो के हो? उबुन्टु वा क्युरियोस? यो लिनक्स कर्नेल हो, अतिरिक्त कम्पोनेन्टहरूको गुच्छा। यी सबै कुरा यहाँ, एउटा विषालु सर्पलाई बाटोबाट फालियो, त्यहाँ बार लगाइयो। Kubernetes धेरै छिटो र गतिशील रूपमा विकास भइरहेको छ, र जोखिम को मात्रा, अज्ञात को भोल्युम हरेक महिना घट्दै छ र, तदनुसार, यी तराजू पुन: सन्तुलनमा छन्।

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

म दृढताका साथ स्टार्टअपहरू र स्थापित व्यवसायहरूमा आउटसोर्सिङको लागि सिफारिस गर्दछु जहाँ तपाईं 10 व्यक्तिहरूको टोलीलाई सञ्चालनमा समर्पित गर्न सक्नुहुन्छ, किनभने अन्यथा त्यहाँ कुनै मतलब छैन। यो निश्चित रूपमा यो आउटसोर्स गर्न अर्थ बनाउँछ।

Amazon र Google को बारेमा

- अमेजन वा गुगलबाट समाधानबाट होस्टलाई आउटसोर्सको रूपमा मान्न सकिन्छ?

दिमित्री: हो, अवश्य पनि, यसले धेरै समस्याहरूको समाधान गर्छ। तर फेरि त्यहाँ nuances छन्। तपाईंले अझै पनि यसलाई कसरी प्रयोग गर्ने भनेर बुझ्न आवश्यक छ। उदाहरण को लागी, Amazon AWS को काम मा एक हजार साना चीजहरु छन्: लोड ब्यालेन्सर वार्म अप गर्न आवश्यक छ वा एक अनुरोध अग्रिम लेखिनु पर्छ कि "साथीहरु, हामी ट्राफिक प्राप्त गर्नेछौं, हाम्रो लागि लोड ब्यालेन्सरलाई न्यानो पार्नुहोस्!" तपाईंले यी सूक्ष्मताहरू जान्न आवश्यक छ।

जब तपाईं यसमा विशेषज्ञ व्यक्तिहरूतर्फ जानुहुन्छ, तपाईंले लगभग सबै सामान्य कुराहरू बन्द गर्नुहुन्छ। हामीसँग अहिले 40 इन्जिनियरहरू छन्, वर्षको अन्त्यमा त्यहाँ 60 हुन सक्छ - हामीले निश्चित रूपमा यी सबै चीजहरूको सामना गरेका छौं। यदि हामीले कुनै परियोजनामा ​​यो समस्या फेरि सामना गरे पनि, हामी तुरुन्तै एक अर्कालाई सोध्छौं र यसलाई कसरी समाधान गर्ने भनेर जान्दछौं।

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

त्यसकारण, जवाफ हो हो, तर, वास्तवमा, त्यहाँ धेरै परिपक्व होस्ट समाधानहरू छैनन्।

कसलाई Kubernetes चाहिन्छ?

- र अझै, कसलाई कुबर्नेट्स चाहिन्छ? कसले पहिले नै Kubernetes मा स्विच गर्नुपर्छ, को विशिष्ट Flaunt ग्राहक हो जो Kubernetes को लागि विशेष रूपमा आउँछ?

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

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

जब त्यस्ता मानिसहरू हामीकहाँ आउँछन्, हामी भन्छौं: "माफ गर्नुहोस्, तर त्यहाँ चमत्कार जस्तो कुनै चीज छैन।" स्वस्थ रहनका लागि राम्रोसँग खान र व्यायाम गर्नुपर्छ । भरपर्दो उत्पादनको लागि, यसलाई भरपर्दो बनाउन आवश्यक छ। सुविधाजनक CI/CD हुनको लागि, तपाईंले यसलाई यसरी बनाउनु पर्छ। यो धेरै काम गर्न आवश्यक छ।

कसलाई कुबर्नेट्स चाहिन्छ भन्ने प्रश्नको जवाफ दिँदै - कसैलाई कुबेरनेटको आवश्यकता पर्दैन।

केही मानिसहरूलाई कुबेरनेटहरू चाहिन्छ भन्ने गलत धारणा छ। मानिसहरूलाई आवश्यक छ, तिनीहरूले सोच्न, अध्ययन गर्न, र पूर्वाधारका सबै समस्याहरू र तिनीहरूका अनुप्रयोगहरू चलाउने समस्याहरूमा चासो राख्ने बन्द गर्न गहिरो आवश्यकता छ। तिनीहरू अनुप्रयोगहरू मात्र काम गर्न चाहन्छन् र मात्र प्रयोग गर्न चाहन्छन्। तिनीहरूका लागि, Kubernetes आशा हो कि उनीहरूले "हामी त्यहाँ लडिरहेका थियौं," वा "हामी रोल आउट गर्न सक्दैनौं," वा अरू केहि सुन्ने कथा सुन्न छोड्नेछन्।

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

हामी वा अरू कसैलाई कुबर्नेट्स चाहिन्छ भन्ने शब्द गलत छ।

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

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

अन्तिम जवाफ हो: तपाईंलाई Kubernetes को आवश्यकता छैन। तपाईका समस्याहरू समाधान गर्न आवश्यक छ।

तपाईले के हासिल गर्न सक्नुहुन्छ:

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

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

सर्भर रहित बारे

- यदि तपाइँ भविष्यमा अलि अगाडि हेर्नुभयो भने, त्यसपछि पूर्वाधारको साथ टाउको दुखाइको अभावको समस्या समाधान गर्ने प्रयास गर्दै, रोलआउटको गति र अनुप्रयोग परिवर्तनहरूको गतिको साथ, नयाँ समाधानहरू देखा पर्दछ, उदाहरणका लागि, सर्भरलेस। के तपाइँ यस दिशामा कुनै सम्भाव्यता महसुस गर्नुहुन्छ र, मानौं, Kubernetes र यस्तै समाधानहरूको लागि खतरा?

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

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

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

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

Kubernetes कसरी विकसित हुनेछ

— जब हामी यो सम्भावित अद्भुत टाढाको भविष्यतर्फ अघि बढ्छौं, तपाइँ कुबर्नेट्स र यसको वरपरको इकोसिस्टम कसरी विकास हुनेछ भन्ने सोच्नुहुन्छ?

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

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

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

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

मलाई लाग्छ प्रयोगको सहजता धेरै बढ्नुपर्छ - बक्स अधिक र अधिक कालो, अधिक र अधिक विश्वसनीय, अधिक र अधिक सरल knobs संग।

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

अब 2019 मा कुन रेडियो? कारमा, रेडियो रिसीभरले सबै छालहरू र स्टेशनहरूको नामहरू फेला पार्छ। प्रक्रियाको भौतिकी 100 वर्षमा परिवर्तन भएको छैन, तर प्रयोगको सजिलो छ। अब, र अहिले मात्र होइन, पहिले नै 1980 मा, जब Azimov संग एक अन्तर्वार्ता थियो, सबैले रेडियो प्रयोग गरे र यो कसरी काम गर्छ भनेर कसैले सोचेन। यो सधैं काम गर्यो - त्यो दिइएको छ।

अजिमोभले भने कि यो कम्प्युटरको साथ समान हुनेछ - प्रयोगमा सहजता बढ्नेछ। 1980 मा तपाईले कम्प्युटरमा बटन थिच्न तालिम लिनु परेको थियो, भविष्यमा त्यस्तो हुने छैन।

मलाई कुबर्नेट्स र पूर्वाधारको साथ प्रयोगको सहजतामा पनि ठूलो वृद्धि हुनेछ भन्ने भावना छ। यो, मेरो विचार मा, स्पष्ट छ - यो सतह मा छ।

इन्जिनियरहरुलाई के गर्ने?

— त्यसो भए कुबेरनेटलाई समर्थन गर्ने इन्जिनियरहरू र प्रणाली प्रशासकहरूलाई के हुन्छ?

दिमित्री1C को आगमन पछि लेखापाललाई के भयो? उस्तै बारे। यसअघि कागजमा गनिन्छन्–अहिले कार्यक्रममा । परिमाणको आदेशले श्रम उत्पादकता बढेको छ, तर श्रम आफै हराएको छैन। यदि पहिले बत्ती बल्बमा स्क्रू गर्न 10 इन्जिनियरहरू लाग्थ्यो भने, अब एक पर्याप्त हुनेछ।

सफ्टवेयरको मात्रा र कार्यहरूको संख्या, यो मलाई लाग्दछ, अब नयाँ DevOps देखा परेको भन्दा छिटो दरमा बढ्दै छ र दक्षता बढ्दै छ। बजारमा अहिले विशेष अभाव छ र यो लामो समयसम्म रहनेछ । पछि, सबै कुरा केहि प्रकारको सामान्यतामा फर्किनेछ, जसमा कामको दक्षता बढ्नेछ, त्यहाँ अधिक र अधिक सर्भरलेस हुनेछ, एक न्यूरोन Kubernetes मा संलग्न हुनेछ, जसले सबै स्रोतहरू ठ्याक्कै आवश्यकता अनुसार चयन गर्नेछ, र सामान्यतया हुनेछ। सबै कुरा आफै गर्नुहोस्, जस्तै यो हुनुपर्छ - व्यक्ति मात्र टाढा जानुहोस् र हस्तक्षेप नगर्नुहोस्।

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

सामान्यतया, यो सबै उद्योगहरूमा जाने बाटो हो। यो कारहरूमा पनि उस्तै छ: पहिले, एक कार मेकानिक र तीन ड्राइभरको साथ आएको थियो। आजकल, कार चलाउनु एक सरल प्रक्रिया हो जसमा हामी सबै दिनहुँ भाग लिन्छौं। कसैले सोच्दैन कि कार केहि जटिल छ।

DevOps वा प्रणाली ईन्जिनियरिङ् टाढा जानेछैन - उच्च-स्तरको काम र दक्षता बढ्नेछ।

- मैले पनि एउटा चाखलाग्दो विचार सुनेको छु कि काम वास्तवमा बढ्छ।

दिमित्री: अवश्य पनि, एक सय प्रतिशत! किनभने हामीले लेख्ने सफ्टवेयरको मात्रा निरन्तर बढिरहेको छ। हामीले सफ्टवेयरको साथ समाधान गर्ने समस्याहरूको संख्या निरन्तर बढिरहेको छ। कामको मात्रा बढ्दै गएको छ । अब DevOps बजार एकदमै तातो छ। यो तलब अपेक्षा मा देख्न सकिन्छ। राम्रो तरिकाले, विवरणहरूमा नजाइकन, त्यहाँ जुनियरहरू हुनुपर्दछ जसले X चाहन्छन्, मध्यहरू जसले 1,5X चाहन्छन्, र वरिष्ठहरू जसले 2X चाहन्छन्। र अब, यदि तपाइँ मस्को DevOps तलब बजारमा हेर्नुहुन्छ भने, एक जुनियरले X देखि 3X र एक वरिष्ठले X देखि 3X सम्म चाहन्छ।

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

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

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

दिमित्री: एक सय प्रतिशत। सामान्यतया, हामी 2019 मा बाँचिरहेका छौं र जीवनको नियम यो हो: जीवनभर सिक्ने - हामी हाम्रो जीवन भर सिक्छौं। यो मलाई लाग्छ कि अब सबैलाई पहिले नै थाहा छ र यो महसुस गर्दछ, तर यो जान्न पर्याप्त छैन - तपाईंले यो गर्नुपर्छ। हरेक दिन हामी परिवर्तन हुनुपर्छ। यदि हामीले यसो गरेनौं भने, ढिलो होस् वा ढिलो हामी पेशाको छेउमा झर्नेछौं।

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

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

- तपाइँको कुनै इच्छा छ?

दिमित्री: हो, मेरो धेरै इच्छाहरू छन्।

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

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

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

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

- मुरी मुरी धन्यवाद!

दिमित्री: धन्यवाद, Vitaly, समय र अन्तर्वार्ताको लागि। प्रिय पाठकहरू, यदि तपाईं अचानक यो बिन्दुमा पुग्नुभयो भने धेरै धेरै धन्यवाद। मलाई आशा छ कि हामीले तपाईलाई कम्तिमा केही विचारहरू ल्याएका छौं।

साक्षात्कार मा, दिमित्री werf को मुद्दा मा छोयो। अब यो एक विश्वव्यापी स्विस चक्कु हो जसले लगभग सबै समस्याहरू समाधान गर्दछ। तर सधैं यस्तो थिएन। अन DevOpsConf  महोत्सवमा RIT++ दिमित्री Stolyarov यस उपकरणको बारेमा विस्तृत रूपमा बताउनेछ। रिपोर्टमा "werf Kubernetes मा CI/CD को लागि हाम्रो उपकरण हो" त्यहाँ सबै कुरा हुनेछ: समस्याहरू र Kubernetes को लुकेका सूक्ष्मताहरू, यी कठिनाइहरू समाधान गर्न विकल्पहरू र विस्तृत रूपमा werf को हालको कार्यान्वयन। मे 27 र 28 मा हामीसँग सामेल हुनुहोस्, हामी उत्तम उपकरणहरू सिर्जना गर्नेछौं।

स्रोत: www.habr.com