DomClick मा Kubernetes: 1000 microservices को क्लस्टर प्रबन्ध गर्दै शान्तिपूर्वक सुत्ने तरिका

मेरो नाम Viktor Yagofarov हो, र म Ops (संचालन) टोलीमा प्राविधिक विकास प्रबन्धकको रूपमा DomClick मा Kubernetes प्लेटफर्मको विकास गर्दैछु। म हाम्रो Dev <-> Ops प्रक्रियाहरूको संरचना, रूसको सबैभन्दा ठूलो k8s क्लस्टरहरू मध्ये एक सञ्चालन गर्ने सुविधाहरू, साथै हाम्रो टोलीले लागू हुने DevOps/SRE अभ्यासहरूको बारेमा कुरा गर्न चाहन्छु।

Ops टोली

Ops टोलीमा हाल १५ जना छन्। तीमध्ये तीनजना कार्यालयका लागि जिम्मेवार छन्, दुईजना फरक समय क्षेत्रमा काम गर्छन् र राती समेत उपलब्ध छन्। यसैले, Ops को कोही सधैं मनिटरमा हुन्छ र कुनै पनि जटिलताको घटनालाई प्रतिक्रिया दिन तयार हुन्छ। हामीसँग नाइट शिफ्टहरू छैनन्, जसले हाम्रो मानसिकतालाई जोगाउँछ र सबैलाई पर्याप्त निन्द्रा लिन र कम्प्युटरमा मात्र होइन फुर्सदको समय बिताउने अवसर दिन्छ।

सबैसँग फरक-फरक दक्षताहरू छन्: नेटवर्करहरू, DBAs, ELK स्ट्याक विशेषज्ञहरू, Kubernetes प्रशासकहरू/विकासकर्ताहरू, निगरानी, ​​भर्चुअलाइजेशन, हार्डवेयर विशेषज्ञहरू, आदि। एउटा कुराले सबैलाई एकताबद्ध गर्छ - सबैले केही हदसम्म हामी मध्ये कुनैलाई प्रतिस्थापन गर्न सक्छन्: उदाहरणका लागि, k8s क्लस्टरमा नयाँ नोडहरू प्रस्तुत गर्नुहोस्, PostgreSQL अपडेट गर्नुहोस्, CI/CD + Ansible पाइपलाइन लेख्नुहोस्, Python/Bash/Go मा केही स्वचालित गर्नुहोस्, हार्डवेयर जडान गर्नुहोस्। डाटा सेन्टर। कुनै पनि क्षेत्रमा बलियो दक्षताहरूले तपाइँलाई तपाइँको गतिविधिको दिशा परिवर्तन गर्न र केहि अन्य क्षेत्रमा सुधार गर्न सुरु गर्नबाट रोक्दैन। उदाहरणका लागि, म PostgreSQL विशेषज्ञको रूपमा एउटा कम्पनीमा सामेल भएँ, र अब मेरो जिम्मेवारीको मुख्य क्षेत्र Kubernetes क्लस्टरहरू हो। टोलीमा, कुनै पनि उचाइ स्वागत छ र लाभ उठाउने भावना धेरै विकसित छ।

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

टोली उपकरणहरू

उपकरण टोलीले स्वचालनमा महत्त्वपूर्ण भूमिका खेल्छ। तिनीहरूको मुख्य कार्य विकासकर्ताहरूको लागि सुविधाजनक ग्राफिकल र CLI उपकरणहरू सिर्जना गर्नु हो। उदाहरणका लागि, हाम्रो आन्तरिक विकास सम्मेलनले तपाईलाई केही माउस क्लिकको साथ कुबेरनेटमा एप्लिकेसन रोल आउट गर्न, यसको स्रोतहरू कन्फिगर गर्न, भल्टबाट कुञ्जीहरू, इत्यादि गर्न अनुमति दिन्छ। पहिले, त्यहाँ Jenkins + Helm 2 थियो, तर मैले प्रतिलिपि-पेस्ट हटाउन र सफ्टवेयर जीवनचक्रमा एकरूपता ल्याउन मेरो आफ्नै उपकरण विकास गर्नुपर्‍यो।

Ops टोलीले विकासकर्ताहरूको लागि पाइपलाइनहरू लेख्दैन, तर तिनीहरूको लेखनमा कुनै पनि मुद्दाहरूमा सल्लाह दिन सक्छ (केही मानिसहरूसँग अझै पनि हेल्म 3 छ)।

DevOps

DevOps को लागी, हामी यसलाई यो जस्तै देख्छौं:

देव टोलीहरूले कोड लेख्छन्, यसलाई कन्फर टु dev -> qa/stage -> prod मार्फत रोल आउट गर्नुहोस्। कोड सुस्त नहुने र त्रुटिहरू समावेश नगर्ने सुनिश्चित गर्ने जिम्मेवारी Dev र Ops टोलीहरूको हो। दिनको समयमा, Ops टोलीबाट ड्यूटीमा रहेको व्यक्तिले सबैभन्दा पहिले आफ्नो आवेदनको साथ घटनाको जवाफ दिनुपर्छ, र साँझ र रातमा, ड्यूटीमा रहेको प्रशासक (Ops) ले विकासकर्तालाई थाहा छ भने ब्यूँझाउनुपर्छ। पूर्वाधारमा समस्या नआउने पक्का छ । निगरानीमा सबै मेट्रिक्स र अलर्टहरू स्वचालित वा अर्ध-स्वचालित रूपमा देखा पर्दछ।

ओप्सको उत्तरदायित्वको क्षेत्र एप्लिकेसन उत्पादनमा रोल आउट भएको क्षणबाट सुरु हुन्छ, तर देवको जिम्मेवारी त्यहाँ समाप्त हुँदैन - हामी उही काम गर्छौं र एउटै डुङ्गामा छौं।

विकासकर्ताहरूले प्रशासकहरूलाई सल्लाह दिन्छन् यदि उनीहरूलाई प्रशासक माइक्रोसेवा (उदाहरणका लागि, गो ब्याकएन्ड + HTML5) लेख्न मद्दत चाहिन्छ, र प्रशासकहरूले विकासकर्ताहरूलाई कुनै पनि पूर्वाधार समस्याहरू वा k8s सँग सम्बन्धित मुद्दाहरूमा सल्लाह दिन्छन्।

वैसे, हामीसँग कुनै पनि मोनोलिथ छैन, केवल माइक्रोसर्भिसेसहरू। तिनीहरूको संख्या हालसम्म prod k900s क्लस्टरमा 1000 र 8 को बीचमा उतार-चढाव हुन्छ, यदि संख्याद्वारा मापन गरियो भने तैनाती। पोडहरूको संख्या 1700 र 2000 को बीचमा उतार-चढाव हुन्छ। हाल उत्पादन क्लस्टरमा लगभग 2000 पोडहरू छन्।

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

स्रोत व्यवस्थापन

निगरानी गर्दै

राम्रोसँग संरचित र जानकारीमूलक अनुगमन ठूलो क्लस्टरको सञ्चालनको आधारशिला बन्छ। हामीले अहिलेसम्म सबै अनुगमन आवश्यकताहरूको 100% कभर गर्ने विश्वव्यापी समाधान फेला पारेका छैनौं, त्यसैले हामी आवधिक रूपमा यस वातावरणमा विभिन्न अनुकूलन समाधानहरू सिर्जना गर्छौं।

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

हाम्रो लागि अर्को उपयोगी उपकरण थियो सूची प्रवेश। हामीले यो लेखेका थियौं धेरै पटक हामीले एउटा परिस्थितिको सामना गर्‍यौं जहाँ एउटा टोलीले अर्को टोलीको प्रवेश मार्गहरू ओभरल्याप गर्‍यो, परिणामस्वरूप 50x त्रुटिहरू। अब उत्पादनमा डिप्लोइ गर्नु अघि, विकासकर्ताहरूले जाँच गर्छन् कि कोही पनि प्रभावित हुनेछैन, र मेरो टोलीको लागि यो Ingresses सँग समस्याहरूको प्रारम्भिक निदानको लागि राम्रो उपकरण हो। यो हास्यास्पद छ कि सुरुमा यो प्रशासकहरु को लागी लेखिएको थियो र यो बरु "अनाड़ी" देखिन्थ्यो, तर dev टोलीहरु उपकरण संग प्रेममा परे पछि, यो धेरै परिवर्तन भयो र "एडमिन को लागी एक वेब अनुहार बनाएको जस्तो देखिन थाल्यो। " चाँडै हामी यो उपकरण त्याग्नेछौं र पाइपलाइन रोल आउट हुनु अघि नै त्यस्ता अवस्थाहरू मान्य हुनेछ।

क्यूबमा टोली स्रोतहरू

हामी उदाहरणहरूमा प्रवेश गर्नु अघि, हामीले स्रोतहरू कसरी बाँडफाँड गर्छौं भनेर व्याख्या गर्न लायक छ सूक्ष्म सेवाहरू.

कुन टोलीहरू र कुन मात्रामा प्रयोग गर्छन् भनेर बुझ्न स्रोतहरू (प्रोसेसर, मेमोरी, स्थानीय SSD), हामी प्रत्येक कमाण्डको आफ्नै आवंटन गर्छौं नामस्थान "क्यूब" मा र प्रोसेसर, मेमोरी र डिस्कको सर्तमा यसको अधिकतम क्षमताहरू सीमित गर्नुहोस्, पहिले टोलीहरूको आवश्यकताहरू छलफल गरिसकेपछि। तदनुसार, एक आदेश, सामान्यतया, तैनाती को लागी सम्पूर्ण क्लस्टर ब्लक गर्दैन, हजारौं कोर र टेराबाइट मेमोरी आवंटित गर्दै। नेमस्पेसमा पहुँच AD मार्फत दिइन्छ (हामी RBAC प्रयोग गर्छौं)। नेमस्पेसहरू र तिनीहरूको सीमाहरू GIT भण्डारमा पुल अनुरोध मार्फत थपिन्छन्, र त्यसपछि सबै कुरा स्वचालित रूपमा उत्तरदायी पाइपलाइन मार्फत रोल आउट हुन्छ।

टोलीलाई स्रोतहरू आवंटित गर्ने उदाहरण:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

अनुरोध र सीमाहरू

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

यस अवस्थाबाट बाहिरको सही तरिका भनेको वास्तविक स्रोत खपतलाई हेर्नु र अनुरोध गरिएको रकम (अनुरोध) सँग तुलना गर्नु हो।

माथिको स्क्रिनसटहरूमा तपाईंले "अनुरोध गरिएको" CPU हरू थ्रेडहरूको वास्तविक संख्यासँग मिल्दोजुल्दो देख्न सक्नुहुन्छ, र सीमाहरू CPU थ्रेडहरूको वास्तविक संख्याभन्दा बढी हुन सक्छन् =)

अब केही नेमस्पेसलाई विस्तृत रूपमा हेरौं (मैले नेमस्पेस क्युब-प्रणाली छनोट गरें - "क्यूब" को कम्पोनेन्टहरूको लागि प्रणाली नेमस्पेस) र अनुरोध गरिएकोमा वास्तवमा प्रयोग गरिएको प्रोसेसर समय र मेमोरीको अनुपात हेर्नुहोस्:

यो स्पष्ट छ कि धेरै मेमोरी र CPU वास्तवमा प्रयोग गरिएको भन्दा प्रणाली सेवाहरूको लागि आरक्षित छ। क्युबे-सिस्टमको मामलामा, यो जायज छ: यो भयो कि nginx प्रवेश नियन्त्रक वा nodelocaldns ले तिनीहरूको शिखरमा CPU मा हिट गर्यो र धेरै RAM खपत गर्यो, त्यसैले यहाँ यस्तो रिजर्भ जायज छ। थप रूपमा, हामी पछिल्लो 3 घण्टाको लागि चार्टहरूमा भर पर्न सक्दैनौं: यो ठूलो अवधिमा ऐतिहासिक मेट्रिक्स हेर्न वांछनीय छ।

"सिफारिसहरू" को एक प्रणाली विकसित भयो। उदाहरणका लागि, यहाँ तपाईंले "सीमाहरू" (माथिको अनुमति दिइएको पट्टी) बढाएर कुन स्रोतहरू राम्रो हुन्छ भनेर देख्न सक्नुहुन्छ ताकि "थ्रॉटलिंग" नहोस्: कुनै स्रोतले पहिले नै छुट्याइएको समयको टुक्रामा CPU वा मेमोरी खर्च गरेको क्षण र यो "अनफ्रिजन" नभएसम्म पर्खिरहेको छ:

र यहाँ पोडहरू छन् जसले तिनीहरूको भोक कम गर्नुपर्दछ:

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

नतिजाको रूपमा, विकासकर्ताहरूसँग क्यूबमा तिनीहरूको नेमस्पेसहरू निगरानी गर्न उपकरणहरू छन्, र तिनीहरू आफैले कहाँ र कुन समयमा कुन अनुप्रयोगहरूले तिनीहरूको स्रोतहरू "कट" गर्न सक्छन् र कुन सर्भरहरूलाई रातभर सम्पूर्ण CPU दिन सकिन्छ भनेर छनौट गर्न सक्षम छन्।

विधिहरू

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

Ops को रूपमा, हामी सेवा प्रतिक्रिया दर र त्रुटिहरूसँग सम्बन्धित विकासकर्ताहरूको लागि विभिन्न मेट्रिक्स र ड्यासबोर्डहरू प्रदान गर्दछौं।

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

मैले एक महिनादेखि ग्राफ कोरेको छैन। यो सायद एक राम्रो संकेत हो: यसको मतलब धेरै "चाहनाहरू" पहिले नै महसुस भइसकेका छन्। यस्तो भयो कि हप्ताको दौडान म दिनमा कम्तिमा एक पटक केहि नयाँ ग्राफ कोर्छु।

नतिजा नतिजा मूल्यवान छ किनभने अब विकासकर्ताहरू "कुनै किसिमको मेट्रिक कहाँ हेर्ने" भन्ने प्रश्नहरूका साथ प्रशासकहरूमा विरलै जान्छन्।

कार्यान्वयन सेवा जाल कुनाको वरिपरि छ र सबैको लागि जीवन धेरै सजिलो बनाउनु पर्छ, उपकरणका सहकर्मीहरू पहिले नै सार "स्वस्थ व्यक्तिको Istio" लागू गर्न नजिक छन्: प्रत्येक HTTP(हरू) अनुरोधको जीवन चक्र अनुगमनमा देखिनेछ, र यो अन्तर-सेवा (र मात्र होइन) अन्तरक्रियाको क्रममा "कुन चरणमा सबै बिग्रियो" बुझ्न सधैं सम्भव हुनेछ। DomClick हबबाट समाचारको सदस्यता लिनुहोस्। =)

Kubernetes पूर्वाधार समर्थन

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

सबै k8s क्लस्टरहरू अद्यावधिक गर्ने प्रक्रिया यस्तो देखिन्छ:

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

भविष्यमा यसलाई प्रतिस्थापन गर्ने योजना छ कुबेस्प्रे केहि छिटो र जानुहोस् kubeadm.

कुलमा हामीसँग तीनवटा "क्यूब्स" छन्: तनाव, देव र प्रोड। हामी अर्को सुरु गर्ने योजनामा ​​छौं (तातो स्ट्यान्डबाइ) प्रोड-"क्यूब" दोस्रो डाटा सेन्टरमा। तनाव и देव "भर्चुअल मेशिनहरू" मा रहनुहोस् (तनावका लागि oVirt र देवका लागि VMWare क्लाउड)। उत्पादन- "क्यूब" "बेयर मेटल" मा रहन्छ: यी 32 CPU थ्रेडहरू, 64-128 GB मेमोरी र 300 GB SSD RAID 10 भएका समान नोडहरू हुन् - त्यहाँ जम्मा 50 वटा छन्। तीन "पातलो" नोडहरू "मास्टरहरू" लाई समर्पित छन् उत्पादन- "क्युबा": 16 GB मेमोरी, 12 CPU थ्रेडहरू।

बिक्रीको लागि, हामी "बेयर मेटल" प्रयोग गर्न रुचाउँछौं र अनावश्यक तहहरू जस्तै बेवास्ता गर्छौं OpenStack: हामीलाई "शोर छिमेकीहरू" र CPU चाहिँदैन समय चोरी। र इन-हाउस ओपनस्ट्याकको मामलामा प्रशासनको जटिलता लगभग दोब्बर हुन्छ।

CI/CD "क्यूबिक" र अन्य पूर्वाधार घटकहरूको लागि हामी छुट्टै GIT सर्भर, हेल्म 3 प्रयोग गर्छौं (यो हेल्म 2 बाट एक बरु पीडादायी संक्रमण थियो, तर हामी विकल्पहरूसँग धेरै खुसी छौं। परमाणु), जेनकिन्स, उत्तरदायी र डकर। हामीलाई सुविधा शाखाहरू र एउटै भण्डारबाट विभिन्न वातावरणहरूमा तैनाती मनपर्छ।

निष्कर्षमा

यो, सामान्य सर्तहरूमा, एक अपरेसन इन्जिनियरको परिप्रेक्ष्यबाट DomClick मा DevOps प्रक्रिया कस्तो देखिन्छ। लेख मैले सोचे भन्दा कम प्राविधिक भएको देखियो: त्यसैले, Habré मा DomClick समाचारहरू पछ्याउनुहोस्: त्यहाँ Kubernetes र थपको बारेमा थप "कट्टर" लेखहरू हुनेछन्।

स्रोत: www.habr.com