हेलम सुरक्षा

Kubernetes को लागि सबैभन्दा लोकप्रिय प्याकेज प्रबन्धकको बारेमा कथाको सार इमोजी प्रयोग गरेर चित्रण गर्न सकिन्छ:

• बक्स हेल्म हो (जुन पछिल्लो इमोजी रिलीजको सबैभन्दा नजिकको कुरा हो);
• ताला - सुरक्षा;
• सानो मान्छे समस्याको समाधान हो।

वास्तवमा, सबै कुरा अलि बढी जटिल हुनेछ, र कथा बारे प्राविधिक विवरणहरू भरिएको छ हेल्मलाई कसरी सुरक्षित बनाउने.

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

यस लेखमा भएका सबै कुरा हेल्म २ मा लागू हुन्छ। यो संस्करण हाल उत्पादनमा छ र सम्भवतः तपाईंले हाल प्रयोग गरिरहनुभएको संस्करण हो, र यो सुरक्षा जोखिमहरू समावेश गर्ने संस्करण हो।

वक्ताको बारेमा: अलेक्जेन्डर खयोरोभ (alexxx) 10 वर्षको लागि विकास भइरहेको छ, सामग्री सुधार गर्न मद्दत गर्दै मस्को पाइथन कन्फ++ र समितिमा सामेल भए हेलम शिखर सम्मेलन। अब उहाँ चेनस्ट्याकमा विकास नेतृत्वको रूपमा काम गर्नुहुन्छ - यो विकास प्रबन्धक र अन्तिम रिलीजहरू डेलिभर गर्न जिम्मेवार व्यक्ति बीचको हाइब्रिड हो। त्यो हो, यो युद्धको मैदानमा अवस्थित छ, जहाँ उत्पादनको निर्माणदेखि यसको सञ्चालनसम्म सबै हुन्छ।

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

हेलमेट

यो Kubernetes को लागि प्याकेज (चार्ट) प्रबन्धक हो। Kubernetes क्लस्टरमा अनुप्रयोगहरू ल्याउने सबैभन्दा सहज र विश्वव्यापी तरिका।

हामी निस्सन्देह, तपाइँको आफ्नै YAML प्रकटीकरण र साना उपयोगिताहरू लेख्नु भन्दा बढी संरचनात्मक र औद्योगिक दृष्टिकोणको बारेमा कुरा गर्दैछौं।

हेल्म सबैभन्दा राम्रो हो जुन हाल उपलब्ध र लोकप्रिय छ।

किन हेलम? मुख्य रूपमा किनभने यो CNCF द्वारा समर्थित छ। क्लाउड नेटिभ एउटा ठूलो संस्था हो र Kubernetes, etcd, Fluentd र अन्य परियोजनाहरूको लागि मूल कम्पनी हो।

अर्को महत्त्वपूर्ण तथ्य यो हो कि हेलम एक धेरै लोकप्रिय परियोजना हो। जब मैले जनवरी 2019 मा हेल्मलाई कसरी सुरक्षित बनाउने भन्ने बारे कुरा गर्न थालेँ, परियोजनाको GitHub मा हजार ताराहरू थिए। मे सम्म त्यहाँ 12 हजार थिए।

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

कोर हेल्म टोली Microsoft Azure द्वारा समर्थित छ र यसैले धेरै अन्य भन्दा फरक, एक पर्याप्त स्थिर परियोजना हो। जुलाईको मध्यमा Helm 3 Alpha 2 को रिलिजले यो परियोजनामा ​​काम गर्ने धेरै व्यक्तिहरू छन्, र तिनीहरूसँग हेल्मको विकास र सुधार गर्ने इच्छा र ऊर्जा छ भनी सङ्केत गर्छ।

हेल्मले Kubernetes मा अनुप्रयोग व्यवस्थापनको धेरै मूल समस्याहरू समाधान गर्दछ।

• आवेदन प्याकेजिङ। WordPress मा "Hello, World" जस्तै एप्लिकेसन पनि पहिले नै धेरै सेवाहरू समावेश गर्दछ, र तपाइँ तिनीहरूलाई सँगै प्याकेज गर्न चाहनुहुन्छ।
• जटिलता प्रबन्ध गर्दै जुन यी अनुप्रयोगहरू प्रबन्ध गर्न आउँछ।
• एप्लिकेसन इन्स्टल वा डिप्लोय गरिसकेपछि अन्त्य नहुने जीवन चक्र। यो बाँच्न जारी छ, यसलाई अद्यावधिक गर्न आवश्यक छ, र हेल्मले यसमा मद्दत गर्दछ र यसको लागि सही उपाय र नीतिहरू ल्याउन प्रयास गर्दछ।

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

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

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

हेल्मले तपाईंलाई अनुमति दिन्छ:

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

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

हेलम तीन मुख्य अवधारणाहरूमा आधारित छ:

• चार्ट रिपो - तपाईंको manifest को लागि सम्भव प्यारामिटराइजेसनको विवरण र एरे। 
• कन्फिगर गर्नुहोस् -अर्थात, लागू गरिने मानहरू (पाठ, संख्यात्मक मानहरू, आदि)।
• जारी दुई माथिल्लो कम्पोनेन्टहरू सङ्कलन गर्दछ, र तिनीहरू सँगै रिलीजमा परिणत हुन्छन्। रिलिजहरू संस्करण गर्न सकिन्छ, यसरी संगठित जीवन चक्र प्राप्त गर्न सकिन्छ: स्थापनाको समयमा सानो र अपग्रेड, डाउनग्रेड वा रोलब्याकको समयमा ठूलो।

हेल्म वास्तुकला

रेखाचित्रले हेल्मको उच्च-स्तरीय वास्तुकलालाई अवधारणात्मक रूपमा चित्रण गर्दछ।

मलाई तपाईलाई सम्झाउन दिनुहोस् कि हेल्म कुबेरनेटसँग सम्बन्धित चीज हो। त्यसकारण, हामी Kubernetes क्लस्टर (आयत) बिना गर्न सक्दैनौं। कुबे-एपिसर्भर कम्पोनेन्ट मास्टरमा रहन्छ। हेल्म बिना हामीसँग Kubeconfig छ। हेल्मले एउटा सानो बाइनरी ल्याउँछ, यदि तपाइँ यसलाई कल गर्न सक्नुहुन्छ भने, हेल्म CLI उपयोगिता, जुन कम्प्युटर, ल्यापटप, मेनफ्रेम - कुनै पनि कुरामा स्थापित छ।

तर यो पर्याप्त छैन। हेल्मसँग टिलर भनिने सर्भर कम्पोनेन्ट छ। यसले क्लस्टर भित्र हेल्मको हितलाई प्रतिनिधित्व गर्दछ; यो कुबर्नेट्स क्लस्टर भित्रको एउटा अनुप्रयोग हो, जस्तै कुनै पनि अन्य।

चार्ट रेपोको अर्को कम्पोनेन्ट चार्टहरू भएको भण्डार हो। त्यहाँ एक आधिकारिक भण्डार छ, र त्यहाँ एक कम्पनी वा परियोजना को एक निजी भण्डार हुन सक्छ।

अन्तरक्रिया

हेल्म प्रयोग गरेर एप्लिकेसन स्थापना गर्न चाहँदा आर्किटेक्चर कम्पोनेन्टहरूले कसरी अन्तरक्रिया गर्छ भनेर हेरौं।

• हामी बोलिरहेका छौं Helm install, भण्डारमा पहुँच गर्नुहोस् (चार्ट रेपो) र हेल्म चार्ट प्राप्त गर्नुहोस्।

• हेल्म उपयोगिता (हेल्म CLI) कुन क्लस्टरलाई सम्पर्क गर्ने भनेर पत्ता लगाउन Kubeconfig सँग अन्तरक्रिया गर्छ। 
• यो जानकारी प्राप्त गरिसकेपछि, उपयोगिताले टिलरलाई बुझाउँछ, जुन हाम्रो क्लस्टरमा अवस्थित छ, अनुप्रयोगको रूपमा। 
• टिलरले Kube-apiserver लाई Kubernetes मा कार्यहरू गर्न, केही वस्तुहरू (सेवाहरू, पोडहरू, प्रतिकृतिहरू, रहस्यहरू, आदि) सिर्जना गर्न कल गर्दछ।

अर्को, हामी आक्रमण भेक्टर हेर्नको लागि रेखाचित्रलाई जटिल बनाउनेछौं जुन सम्पूर्ण हेल्म वास्तुकलालाई समग्र रूपमा उजागर गर्न सकिन्छ। र त्यसपछि हामी उनको रक्षा गर्न प्रयास गर्नेछौं।

आक्रमण वेक्टर

पहिलो सम्भावित कमजोर बिन्दु हो विशेषाधिकार प्राप्त API-प्रयोगकर्ता। योजनाको एक भागको रूपमा, यो एक ह्याकर हो जसले हेल्म CLI मा प्रशासक पहुँच प्राप्त गरेको छ।

विशेषाधिकाररहित API प्रयोगकर्ता यदि यो नजिकै छ भने खतरा पनि हुन सक्छ। यस्तो प्रयोगकर्ताको फरक सन्दर्भ हुनेछ, उदाहरणका लागि, उसलाई Kubeconfig सेटिङहरूमा एउटा क्लस्टर नेमस्पेसमा फिक्स गर्न सकिन्छ।

सबैभन्दा चाखलाग्दो आक्रमण भेक्टर एउटा प्रक्रिया हुन सक्छ जुन टिलर नजिकैको क्लस्टर भित्र रहन्छ र यसलाई पहुँच गर्न सक्छ। यो क्लस्टरको नेटवर्क वातावरण देख्ने वेब सर्भर वा माइक्रोसर्भिस हुन सक्छ।

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

यी सबै चार पक्षहरूबाट आक्रमणहरू रोक्न प्रयास गरौं र हेल्म वास्तुकलामा कहाँ समस्याहरू छन्, र कहाँ, सम्भवतः, त्यहाँ कुनै पनि छैनन् भनेर पत्ता लगाउनुहोस्।

रेखाचित्रलाई ठूलो बनाउनुहोस्, थप तत्वहरू थप्नुहोस्, तर सबै आधारभूत घटकहरू राख्नुहोस्।

हेल्म CLI ले चार्ट रेपोसँग सञ्चार गर्छ, कुबेकन्फिगसँग अन्तरक्रिया गर्छ, र काम क्लस्टरमा टिलर कम्पोनेन्टमा हस्तान्तरण गरिन्छ।

टिलर दुई वस्तुहरू द्वारा प्रतिनिधित्व गरिएको छ:

• Tiller-deploy svc, जसले निश्चित सेवालाई उजागर गर्दछ;
• टिलर-डिप्लोय पोड (एउटा प्रतिकृतिमा एकल प्रतिलिपिमा रेखाचित्रमा), जसमा सम्पूर्ण लोड चल्छ, जसले क्लस्टरमा पहुँच गर्दछ।

अन्तरक्रियाका लागि विभिन्न प्रोटोकल र योजनाहरू प्रयोग गरिन्छ। सुरक्षा दृष्टिकोणबाट, हामी सबैभन्दा बढी चासो राख्छौं:

• हेल्म CLI ले चार्ट रिपोमा पहुँच गर्ने संयन्त्र: कुन प्रोटोकल, त्यहाँ प्रमाणीकरण छ र यसको साथ के गर्न सकिन्छ।
• प्रोटोकल जसद्वारा हेल्म CLI, kubectl प्रयोग गरेर, टिलरसँग सञ्चार गर्दछ। यो क्लस्टर भित्र स्थापित RPC सर्भर हो।
• टिलर क्लस्टरमा बस्ने र कुबे-एपिसर्भरसँग अन्तरक्रिया गर्ने माइक्रोसर्भिसेसहरूमा पहुँचयोग्य छ।

यी सबै क्षेत्रहरूलाई क्रमबद्ध रूपमा छलफल गरौं।

RBAC

RBAC सक्षम नभएसम्म हेल्म वा क्लस्टर भित्रको कुनै अन्य सेवाको लागि कुनै सुरक्षाको बारेमा कुरा गर्नुको कुनै अर्थ छैन।

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

https://rbac.dev/ - RBAC को लागि वेबसाइट वकील। यसमा धेरै मात्रामा रोचक सामग्रीहरू छन् जसले तपाईंलाई RBAC सेटअप गर्न मद्दत गर्दछ, यो किन राम्रो छ र कसरी उत्पादनमा मूल रूपमा यसको साथ बाँच्ने भनेर देखाउनुहोस्।

म टिलर र RBAC कसरी काम गर्छ भनेर व्याख्या गर्ने प्रयास गर्नेछु। टिलरले निश्चित सेवा खाता अन्तर्गत क्लस्टर भित्र काम गर्दछ। सामान्यतया, यदि RBAC कन्फिगर गरिएको छैन भने, यो सुपर प्रयोगकर्ता हुनेछ। आधारभूत कन्फिगरेसनमा, टिलर प्रशासक हुनेछन्। यसैले यो प्रायः भनिन्छ कि टिलर तपाईको क्लस्टरको लागि SSH सुरुङ हो। वास्तवमा, यो सत्य हो, त्यसैले तपाईंले माथिको रेखाचित्रमा पूर्वनिर्धारित सेवा खाताको सट्टा छुट्टै समर्पित सेवा खाता प्रयोग गर्न सक्नुहुन्छ।

जब तपाइँ हेल्म सुरु गर्नुहुन्छ र यसलाई पहिलो पटक सर्भरमा स्थापना गर्नुहुन्छ, तपाइँ सेवा खाता प्रयोग गरेर सेट गर्न सक्नुहुन्छ --service-account। यसले तपाइँलाई अधिकारको न्यूनतम आवश्यक सेटको साथ प्रयोगकर्ता प्रयोग गर्न अनुमति दिनेछ। साँचो, तपाईंले यस्तो "माला" सिर्जना गर्नुपर्नेछ: भूमिका र रोलबाइन्डिङ।

दुर्भाग्यवश, हेलमले तपाईंको लागि यो गर्दैन। हेल्म पास गर्नको लागि तपाइँ वा तपाइँको Kubernetes क्लस्टर प्रशासकले सेवा-खाताको लागि भूमिका र रोलबाइन्डिङको सेट तयार गर्न आवश्यक छ।

प्रश्न उठ्छ - रोल र क्लस्टररोल बीच के भिन्नता छ? भिन्नता यो हो कि ClusterRole ले सबै नेमस्पेसहरूको लागि काम गर्दछ, नियमित भूमिकाहरू र रोलबाइन्डिङहरूको विपरीत, जसले केवल विशेष नाम स्थानको लागि काम गर्दछ। तपाइँ सम्पूर्ण क्लस्टर र सबै नेमस्पेसहरूको लागि नीतिहरू कन्फिगर गर्न सक्नुहुन्छ, वा प्रत्येक नेमस्पेसको लागि व्यक्तिगत रूपमा व्यक्तिगत रूपमा।

यो उल्लेखनीय छ कि RBAC ले अर्को ठूलो समस्या समाधान गर्दछ। धेरै मानिसहरूले गुनासो गर्छन् कि हेल्म, दुर्भाग्यवश, बहु-टेनेन्सी होइन (बहु टेनेन्सीलाई समर्थन गर्दैन)। यदि धेरै टोलीहरूले क्लस्टर उपभोग गर्छन् र हेल्म प्रयोग गर्छन् भने, यो मूलतया नीतिहरू सेटअप गर्न र यो क्लस्टर भित्र तिनीहरूको पहुँच सीमित गर्न असम्भव छ, किनभने त्यहाँ एक निश्चित सेवा खाता छ जस अन्तर्गत हेल्म चल्छ, र यसले क्लस्टरमा सबै स्रोतहरू यसको मुनिबाट सिर्जना गर्दछ। , जुन कहिलेकाहीँ धेरै असुविधाजनक हुन्छ। यो सत्य हो - बाइनरी फाइल जस्तै, प्रक्रिया जस्तै, हेल्म टिलरसँग मल्टीटेनेन्सीको कुनै अवधारणा छैन.

जे होस्, त्यहाँ एक राम्रो तरिका हो जसले तपाईंलाई क्लस्टरमा धेरै पटक टिलर चलाउन अनुमति दिन्छ। यसमा कुनै समस्या छैन, टिलर हरेक नेमस्पेसमा सुरू गर्न सकिन्छ। यसरी, तपाईंले RBAC, Kubeconfig सन्दर्भको रूपमा प्रयोग गर्न सक्नुहुन्छ, र विशेष हेलममा पहुँच सीमित गर्न सक्नुहुन्छ।

यो यस्तो देखिनेछ।

उदाहरणका लागि, त्यहाँ दुईवटा कुबेकन्फिगहरू छन् जसमा विभिन्न टोलीहरू (दुई नेमस्पेसहरू) सन्दर्भ छन्: विकास टोली र प्रशासक क्लस्टरका लागि X टोली। प्रशासक क्लस्टरको आफ्नै फराकिलो टिलर छ, जुन कुबे-प्रणाली नेमस्पेसमा अवस्थित छ, समान रूपमा उन्नत सेवा-खाता। र विकास टोलीका लागि छुट्टै नेमस्पेस, तिनीहरूले विशेष नेमस्पेसमा आफ्ना सेवाहरू तैनाथ गर्न सक्षम हुनेछन्।

यो एक व्यावहारिक दृष्टिकोण हो, टिलर यति शक्ति भोको छैन कि यसले तपाईंको बजेटलाई धेरै असर गर्छ। यो द्रुत समाधान मध्ये एक हो।

टिलरलाई छुट्टै कन्फिगर गर्न स्वतन्त्र महसुस गर्नुहोस् र टोलीको लागि, विशिष्ट विकासकर्ता वा वातावरणको लागि कुबेकन्फिगलाई सन्दर्भ प्रदान गर्नुहोस्: देव, स्टेजिङ, उत्पादन (यो शंका छ कि सबै कुरा एउटै क्लस्टरमा हुनेछ, तथापि, यो गर्न सकिन्छ)।

हाम्रो कथा जारी राख्दै, RBAC बाट स्विच गरौं र ConfigMaps को बारेमा कुरा गरौं।

कन्फिगम्याप्स

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

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

यो धेरै सरल रूपमा गरिन्छ। टिलर सेटिङ ओभरराइड गर्नुहोस् र भण्डारण गोप्य हुनेछ भनी निर्दिष्ट गर्नुहोस्। त्यसपछि प्रत्येक डिप्लोइमेन्टको लागि तपाईंले कन्फिगम्याप प्राप्त गर्नुहुनेछैन, तर गोप्य।

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

भण्डारण हेलमलाई गोप्यमा स्थानान्तरण गर्न राम्रो छ, र तिनीहरू, बारीमा, केन्द्रीय रूपमा सुरक्षित छन्।

अवश्य पनि रहनेछ 1 MB को डाटा भण्डारण सीमा। Helm यहाँ कन्फिगम्याप्सको लागि वितरित भण्डारणको रूपमा etcd प्रयोग गर्दछ। र त्यहाँ तिनीहरूले यो प्रतिकृति, इत्यादिको लागि उपयुक्त डेटा खण्ड हो भनेर विचार गरे। त्यहाँ Reddit मा यसको बारेमा एक रोचक छलफल छ, म सप्ताहन्तको लागि यो हास्यास्पद पढाइ खोज्न वा उद्धरण पढ्न सिफारिस गर्दछु। यहाँ.

चार्ट रिपो

चार्टहरू सबैभन्दा सामाजिक रूपमा कमजोर छन् र "मध्यमा मानिस" को स्रोत बन्न सक्छ, विशेष गरी यदि तपाइँ स्टक समाधान प्रयोग गर्नुहुन्छ। सबैभन्दा पहिले, हामी रिपोजिटरीहरूको बारेमा कुरा गर्दैछौं जुन HTTP मार्फत खुलासा गरिन्छ।

तपाईंले निश्चित रूपमा HTTPS मा हेल्म रिपोलाई उजागर गर्न आवश्यक छ - यो उत्तम विकल्प हो र सस्तो छ।

ध्यान दिनुहोस् चार्ट हस्ताक्षर संयन्त्र। प्रविधि नरक जस्तै सरल छ। यो तपाईले GitHub मा प्रयोग गर्नुहुने कुरा हो, सार्वजनिक र निजी कुञ्जीहरू भएको नियमित PGP मेसिन। सेट अप गर्नुहोस् र निश्चित हुनुहोस्, आवश्यक कुञ्जीहरू र सबै कुरामा हस्ताक्षर गर्दै, यो वास्तवमै तपाईंको चार्ट हो।

यसबाहेक, हेल्म ग्राहकले TLS समर्थन गर्दछ (सर्भर-साइड HTTP अर्थमा होइन, तर पारस्परिक TLS)। तपाइँ संचार गर्न सर्भर र ग्राहक कुञ्जीहरू प्रयोग गर्न सक्नुहुन्छ। इमानदार हुन, म यस्तो संयन्त्र प्रयोग गर्दिन किनभने मलाई पारस्परिक प्रमाणपत्रहरू मन पर्दैन। मूलतः, चार्ट संग्रहालय - Helm 2 को लागि Helm Repo सेटअप गर्ने मुख्य उपकरण - आधारभूत प्रमाणीकरणलाई पनि समर्थन गर्दछ। तपाईं आधारभूत प्रमाणीकरण प्रयोग गर्न सक्नुहुन्छ यदि यो अधिक सुविधाजनक र शान्त छ।

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

यदि तपाईंले HTTPS वा TLS सक्षम गर्नुभयो भने, mTLS प्रयोग गर्नुहोस्, र थप जोखिमहरू कम गर्न आधारभूत प्रमाणीकरण सक्षम गर्नुभयो भने, तपाईंले Helm CLI र चार्ट रेपोसँग सुरक्षित सञ्चार च्यानल पाउनुहुनेछ।

gRPC API

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

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

उत्पादन र स्टेजिङको लागि, म gRPC मा TLS सक्षम गर्न सिफारिस गर्छु।

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

यस तरिकाले तपाईले आफूलाई क्लस्टर बाहिरबाट टिलरलाई सबै अनुरोधहरूबाट जोगाउनुहुनेछ।

त्यसोभए, हामीले टिलरमा जडान च्यानल सुरक्षित गरेका छौं, हामीले पहिले नै RBAC छलफल गरिसकेका छौं र Kubernetes apiserver को अधिकारहरू समायोजन गरिसकेका छौं, यसले अन्तरक्रिया गर्न सक्ने डोमेनलाई कम गर्दै।

संरक्षित हेलम

अन्तिम रेखाचित्र हेरौं। यो एउटै तीर संग एउटै वास्तुकला हो।

सबै जडानहरू अब सुरक्षित रूपमा हरियोमा कोर्न सकिन्छ:

• चार्ट रेपोको लागि हामी TLS वा mTLS र आधारभूत प्रमाणीकरण प्रयोग गर्छौं;
• टिलरको लागि mTLS, र यो TLS सँग gRPC सेवाको रूपमा उजागर गरिएको छ, हामी प्रमाणपत्रहरू प्रयोग गर्छौं;
• क्लस्टरले रोल र रोलबाइन्डिङको साथ विशेष सेवा खाता प्रयोग गर्दछ। 

हामीले क्लस्टरलाई महत्त्वपूर्ण रूपमा सुरक्षित गरेका छौं, तर कसैले स्मार्ट भने:

"त्यहाँ एउटा मात्र पूर्ण सुरक्षित समाधान हुन सक्छ - एक स्विच अफ कम्प्युटर, जो एक कंक्रीट बक्स मा स्थित छ र सैनिकहरु द्वारा संरक्षित छ।"

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

बोनस

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

भण्डारमा github.com/helm/charts अब त्यहाँ लगभग 300 चार्ट र दुई स्ट्रिमहरू छन्: स्थिर र इनक्यूबेटर। योगदान गर्ने जो कोहीलाई राम्रोसँग थाहा छ कि इन्क्यूबेटरबाट स्थिरमा पुग्न कत्ति गाह्रो छ, र स्थिरबाट बाहिर उड्न कति सजिलो छ। जे होस्, यो प्रोमिथियसका लागि चार्टहरू खोज्नको लागि उत्तम उपकरण होईन र तपाईंलाई मनपर्ने अरू जुनसुकै कारणले गर्दा - यो एउटा पोर्टल होइन जहाँ तपाईं प्याकेजहरू खोज्न सक्नुहुन्छ।

तर त्यहाँ सेवा छ hub.helm.sh, जसले चार्टहरू फेला पार्न धेरै सुविधाजनक बनाउँछ। सबैभन्दा महत्त्वपूर्ण कुरा, त्यहाँ धेरै बाह्य भण्डारहरू छन् र लगभग 800 आकर्षणहरू उपलब्ध छन्। साथै, तपाइँ तपाइँको भण्डार जडान गर्न सक्नुहुन्छ यदि कुनै कारणले तपाइँ तपाइँको चार्टहरू स्थिरमा पठाउन चाहनुहुन्न भने।

hub.helm.sh प्रयास गर्नुहोस् र यसलाई सँगै विकास गरौं। यो सेवा हेल्म प्रोजेक्ट अन्तर्गत छ, र यदि तपाईं फ्रन्ट-एन्ड विकासकर्ता हुनुहुन्छ र केवल उपस्थिति सुधार गर्न चाहनुहुन्छ भने तपाईंले यसको UI मा योगदान गर्न सक्नुहुन्छ।

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

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

अरूहरू, हामी जस्तै Chainstack मा, तिनीहरूको सर्भरहरूको लागि MySQL वा PostgreSQL जस्ता व्यवस्थित डाटाबेसहरू प्रयोग गर्नुहोस्। त्यसकारण हाम्रा डाटाबेसहरू क्लाउडमा कतै अवस्थित छन्।

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

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

हामी भन्न सक्छौं कि हेल्मले ग्लुको रूपमा कार्य गर्दछ जुन, एकतर्फ, तपाईंलाई सेवाहरू प्रयोग गर्न अनुमति दिन्छ, र अर्कोमा, क्लाउड प्रदायकहरूको स्रोतहरू उपभोग गर्दछ।

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

मैले पहिले नै उल्लेख गरेको अर्को खोज हो helm-gcs प्लगइन, जसले तपाईंलाई हेल्म चार्टहरू भण्डारण गर्न गुगल-बकेटहरू (वस्तु भण्डारण) प्रयोग गर्न अनुमति दिन्छ।

तपाइँ यसलाई प्रयोग गर्न सुरु गर्न केवल चार आदेशहरू चाहिन्छ:

1. प्लगइन स्थापना गर्नुहोस्;
2. यसलाई सुरु गर्नुहोस्;
3. बाल्टीमा मार्ग सेट गर्नुहोस्, जुन gcp मा अवस्थित छ;
4. मानक तरिकामा चार्ट प्रकाशित गर्नुहोस्।

सुन्दरता यो हो कि नेटिभ जीसीपी विधि प्राधिकरणको लागि प्रयोग गरिनेछ। तपाईले सेवा खाता, विकासकर्ता खाता, जुन चाहानुहुन्छ प्रयोग गर्न सक्नुहुन्छ। यो धेरै सुविधाजनक छ र सञ्चालन गर्न कुनै पनि लागत छैन। यदि तपाइँ, म जस्तै, opsless दर्शन को प्रचार, तब यो धेरै सुविधाजनक हुनेछ, विशेष गरी साना टोलीहरु को लागी।

विकल्पहरू

हेलम मात्र सेवा व्यवस्थापन समाधान होइन। त्यहाँ यसको बारेमा धेरै प्रश्नहरू छन्, जुन सम्भवतः तेस्रो संस्करण यति चाँडै देखा पर्यो। अवश्य पनि त्यहाँ विकल्पहरू छन्।

यी विशेष समाधानहरू हुन सक्छन्, उदाहरणका लागि, Ksonnet वा Metaparticle। तपाईंले आफ्नो क्लासिक पूर्वाधार व्यवस्थापन उपकरणहरू (Ansible, Terraform, Chef, आदि) प्रयोग गर्न सक्नुहुन्छ जुन उद्देश्यका लागि मैले कुरा गरेको छु।

अन्तमा त्यहाँ समाधान छ अपरेटर फ्रेमवर्कजसको लोकप्रियता बढ्दै गएको छ ।

अपरेटर फ्रेमवर्क विचार गर्न शीर्ष हेल्म विकल्प हो।

यो CNCF र Kubernetes को अधिक मूल हो, तर प्रवेशमा बाधा धेरै छ, तपाईँले धेरै कार्यक्रम र कम manifests वर्णन गर्न आवश्यक छ।

त्यहाँ विभिन्न addons छन्, जस्तै ड्राफ्ट, Scaffold। तिनीहरूले जीवनलाई धेरै सजिलो बनाउँछन्, उदाहरणका लागि, तिनीहरूले हेल्म पठाउने र विकासकर्ताहरूलाई परीक्षण वातावरण प्रयोग गर्नको लागि सुरु गर्ने चक्रलाई सरल बनाउँछन्। म तिनीहरूलाई सशक्तिकरण भन्छु।

यहाँ सबै कुराको दृश्य चार्ट छ।

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

अपरेटर फ्रेमवर्क कुबेरनेटको मूल निवासी हो र यसले तपाईंलाई यसलाई अझ सुन्दर र सावधानीपूर्वक व्यवस्थापन गर्न अनुमति दिन्छ (तर प्रविष्टि स्तरको बारेमा सम्झनुहोस्)। बरु, यो हेल्म प्रयोग गरेर ठूलो संख्यामा एप्लिकेसनहरू प्याकेज गर्नको लागि मास हार्वेस्टरको सट्टा, विशेष अनुप्रयोग र यसको लागि व्यवस्थापनको सिर्जनाको लागि उपयुक्त छ।

एक्स्टेन्डरहरूले मात्र नियन्त्रणलाई थोरै सुधार गर्छन्, कार्यप्रवाहलाई पूरक बनाउँछन्, वा CI/CD पाइपलाइनहरूमा कुनाहरू काट्छन्।

हेलम को भविष्य

सुसमाचार यो हो कि Helm 3 आउँदैछ। Helm 3.0.0-alpha.2 को अल्फा संस्करण पहिले नै रिलीज भइसकेको छ, तपाईं यसलाई प्रयास गर्न सक्नुहुन्छ। यो एकदम स्थिर छ, तर कार्यक्षमता अझै सीमित छ।

तपाईलाई हेलम 3 किन चाहिन्छ? सबैभन्दा पहिले, यो एक कथा हो टिलर बेपत्ता, एक घटक को रूप मा। यो, तपाईले पहिले नै बुझ्नुभयो, यो एक ठूलो कदम हो, किनकि वास्तुकलाको सुरक्षाको दृष्टिकोणबाट, सबै कुरा सरलीकृत छ।

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

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

मेरो लागि विवादास्पद कथा हो लुआ समर्थन, स्क्रिप्ट लेख्नको लागि टेम्प्लेटिंग इन्जिनको रूपमा। म लुआको ठूलो प्रशंसक होइन, तर यो पूर्ण रूपमा वैकल्पिक सुविधा हुनेछ। मैले यसलाई ३ पटक जाँच गरें - Lua प्रयोग गर्नु आवश्यक पर्दैन। तसर्थ, लुआ प्रयोग गर्न सक्षम हुन चाहनेहरू, Go मन पराउनेहरू, हाम्रो विशाल क्याम्पमा सामेल हुनुहोस् र यसको लागि go-tmpl प्रयोग गर्नुहोस्।

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

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

Helm 3 सरल, सुरक्षित र थप रमाइलो हुनेछ, हामीलाई Helm 2 मन नपरेकोले होइन, तर Kubernetes अझ उन्नत हुँदै गएको कारणले। तदनुसार, हेल्मले Kubernetes को विकासहरू प्रयोग गर्न र यसमा Kubernetes को लागि उत्कृष्ट प्रबन्धकहरू सिर्जना गर्न सक्छ।

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

मा सम्मेलन चेकपोइन्ट र समाचार पालना गर्नुहोस् न्यूजलेटर и टेलिग्राम च्यानल.

स्रोत: www.habr.com