नमस्ते सबै! मेरो नाम पावेल Agaletsky हो। म Lamoda डेलिभरी प्रणाली विकास गर्ने टोलीमा टोली नेतृत्वको रूपमा काम गर्छु। 2018 मा, मैले HighLoad++ सम्मेलनमा बोलें, र आज म मेरो रिपोर्टको ट्रान्सक्रिप्ट प्रस्तुत गर्न चाहन्छु।

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

VM मा अनुप्रयोगहरू प्रयोग गर्दै

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

यो के को लागि थियो?

जब हामीले हाम्रो एप्लिकेसनको नयाँ रिलिजहरू डिप्लोय गर्‍यौं, हामी सिमलेस रोलआउट सुनिश्चित गर्न चाहन्थ्यौं, अर्थात् प्रयोगकर्ताहरूका लागि उल्लेखनीय परिणामहरू बिना। Ansible को प्रयोग गरेर अर्को कम्पाइल गरिएको रिलीज टेलमा रोल आउट भएको तथ्यको कारणले यो प्राप्त भयो। त्यहाँ, तैनातीमा संलग्न व्यक्तिहरूले जाँच गर्न र सबै कुरा ठीक छ भनेर सुनिश्चित गर्न सक्थे: सबै मेट्रिक्स, खण्डहरू र अनुप्रयोगहरू काम गरिरहेका थिए; आवश्यक स्क्रिप्टहरू सुरू गरिएको छ। सबै ठिकठाक छ भनी ढुक्क भएपछि मात्रै यातायात सुचारु भएको थियो । यो पहिले टेल भएको सर्भरमा जान थाल्यो। र एक जुन पहिले टाउको थियो प्रयोगकर्ता ट्राफिक बिना नै रह्यो, जबकि अझै यसमा हाम्रो अनुप्रयोगको अघिल्लो संस्करण छ।

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

यी सबैमा हामीले के फाइदाहरू देख्यौं?

1. सबै भन्दा पहिले, यो पर्याप्त छ यो मात्र काम गर्दछ। सबैले बुझ्दछन् कि यस्तो डिप्लोइमेन्ट योजना कसरी काम गर्दछ, किनकि अधिकांश मानिसहरूले नियमित भर्चुअल सर्भरहरूमा तैनाथ गरेका छन्।
2. यो पर्याप्त छ भरपर्दो, किनकि डिप्लोइमेन्ट टेक्नोलोजी सरल छ, हजारौं कम्पनीहरूले परीक्षण गरेका छन्। लाखौं सर्भरहरू यस तरिकामा तैनात छन्। केहि तोड्न गाह्रो छ।
3. र अन्तमा हामीले प्राप्त गर्न सक्छौं आणविक परिनियोजनहरू। डिप्लोयमेन्टहरू जुन प्रयोगकर्ताहरूका लागि पुरानो संस्करण र नयाँ संस्करण बीच स्विच गर्ने उल्लेखनीय चरण बिना नै हुन्छन्।

तर हामीले यी सबैमा धेरै कमजोरीहरू पनि देख्यौं:

1. उत्पादन वातावरण, विकास वातावरण, अन्य वातावरणहरू छन्। उदाहरणका लागि, qa र preproduction। त्यतिबेला हामीसँग धेरै सर्भरहरू र ६० वटा सेवाहरू थिए। यस कारण यो आवश्यक थियो प्रत्येक सेवाको लागि, यसको लागि नवीनतम संस्करण कायम राख्नुहोस् भर्चुअल मेसिन। यसबाहेक, यदि तपाइँ पुस्तकालयहरू अद्यावधिक गर्न वा नयाँ निर्भरताहरू स्थापना गर्न चाहनुहुन्छ भने, तपाइँले यो सबै वातावरणमा गर्न आवश्यक छ। तपाईंले आफ्नो अनुप्रयोगको अर्को नयाँ संस्करण डिप्लोय गर्न जाँदै हुनुहुन्छ समयलाई पनि सिङ्क्रोनाइज गर्न आवश्यक छ जब devops ले आवश्यक वातावरण सेटिङहरू प्रदर्शन गर्दछ। यस अवस्थामा, हाम्रो वातावरण एकैचोटि सबै वातावरणमा केही फरक हुने स्थितिमा पुग्न सजिलो छ। उदाहरणका लागि, QA वातावरणमा त्यहाँ पुस्तकालयहरूको केही संस्करणहरू हुनेछन्, र उत्पादन वातावरणमा त्यहाँ फरक हुनेछ, जसले समस्याहरू निम्त्याउँछ।
2. निर्भरताहरू अद्यावधिक गर्न कठिनाई तपाईंको आवेदन। यो तपाईंमा होइन, तर अर्को टोलीमा निर्भर गर्दछ। अर्थात्, सर्भरहरू मर्मत गर्ने devops टोलीबाट। तपाईंले तिनीहरूलाई उपयुक्त कार्य र तपाईंले के गर्न चाहनुहुन्छ भन्ने विवरण दिनुपर्छ।
3. त्यसबेला, हामीले आफूसँग भएका ठूला ठूला मोनोलिथहरूलाई पनि छुट्टाछुट्टै साना सेवाहरूमा विभाजन गर्न चाहन्थ्यौं, किनकि हामीले बुझेका थियौं कि तिनीहरूमध्ये धेरै हुनेछन्। त्यसबेला, हामीसँग पहिले नै ती मध्ये 100 भन्दा बढी थिए। प्रत्येक नयाँ सेवाको लागि, यो एक अलग नयाँ भर्चुअल मेसिन सिर्जना गर्न आवश्यक थियो, जसलाई मर्मत र प्रयोग गर्न पनि आवश्यक थियो। थप रूपमा, तपाईंलाई एउटा कार चाहिन्छ, तर कम्तिमा दुई। यी सबैमा थपिएको छ QA वातावरण। यसले समस्याहरू निम्त्याउँछ र तपाईंलाई नयाँ प्रणालीहरू निर्माण गर्न र चलाउन अझ गाह्रो बनाउँछ। जटिल, महँगो र लामो प्रक्रिया।

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

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

Nomad मा स्विच गर्नुहोस्

Nomad HashiCorp को उत्पादन हो। तिनीहरू तिनीहरूका अन्य समाधानहरूको लागि पनि चिनिन्छन्:

"कन्सल" सेवा खोज को लागि एक उपकरण हो।

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

"अवक्रान्ति" तपाइँलाई विशेष कन्फिगरेसन फाइलहरू मार्फत स्थानीय रूपमा वा क्लाउडमा भर्चुअल मेसिनहरू प्रयोग गर्न अनुमति दिन्छ।

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

तपाइँलाई Nomad मा तपाइँको प्रणाली तैनात गर्न के आवश्यक छ?

1. सबै भन्दा पहिले तपाईंलाई आवश्यक छ डकर छवि तपाईंको आवेदन। तपाईंले यसलाई निर्माण गर्न र डकर छवि भण्डारमा राख्नु पर्छ। हाम्रो केसमा, यो एक कलात्मक छ - एक प्रणाली जसले तपाईंलाई विभिन्न प्रकारका विभिन्न कलाकृतिहरूलाई यसमा धकेल्न अनुमति दिन्छ। यसले अभिलेखहरू, डकर छविहरू, कम्पोजर PHP प्याकेजहरू, NPM प्याकेजहरू, र यस्तै अन्य भण्डारण गर्न सक्छ।
2. पनि आवश्यक छ कन्फिगरेसन फाइल, जसले Nomad लाई के, कहाँ र कुन मात्रामा तपाइँ तैनात गर्न चाहानुहुन्छ भनेर बताउनेछ।

जब हामी Nomad को बारेमा कुरा गर्छौं, यसले HCL भाषालाई यसको जानकारी फाइल ढाँचाको रूपमा प्रयोग गर्दछ, जसको लागि खडा हुन्छ HashiCorp कन्फिगरेसन भाषा। यो Yaml को एक सुपरसेट हो जसले तपाईंलाई आफ्नो सेवालाई घुमन्ते सर्तहरूमा वर्णन गर्न अनुमति दिन्छ।

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

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

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

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

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

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

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

जब Nomad सेवा पहिले नै तपाइँको क्लस्टरमा तैनात गरिएको छ, यो यस्तो देखिन्छ।

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

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

मानव संसाधनको हिसाबले संक्रमणले हामीलाई कति खर्च गर्यो?

नोमाडमा सम्पूर्ण कम्पनीको संक्रमण लगभग 5-6 महिना लाग्यो। हामी सेवा-द्वारा-सेवा आधारमा सारियो, तर एकदम द्रुत गतिमा। प्रत्येक टोलीले सेवाहरूको लागि आफ्नै कन्टेनरहरू सिर्जना गर्नुपर्ने थियो।

हामीले यस्तो दृष्टिकोण अपनाएका छौं कि प्रत्येक टोली स्वतन्त्र रूपमा तिनीहरूको प्रणालीको डकर छविहरूको लागि जिम्मेवार छ। Devops ले तैनातीका लागि आवश्यक सामान्य पूर्वाधार प्रदान गर्दछ, त्यो हो, क्लस्टरको लागि समर्थन, CI प्रणालीको लागि समर्थन, र यस्तै। र त्यस समयमा, हामीसँग 60० भन्दा बढी प्रणालीहरू नोमाडमा सारियो, जुन लगभग 2 हजार कन्टेनरहरू थिए।

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

घुमन्ते त्याग्ने कारणहरू

Nomad र docker प्रयोग गरेर डिप्लोयमेन्टमा स्विच गरेर हामीले अरू के फाइदाहरू पायौं?

1. हामी समान सर्तहरू प्रदान गरियो सबै वातावरण को लागी। विकासमा, QA वातावरण, पूर्व-उत्पादन, उत्पादन, समान कन्टेनर छविहरू प्रयोग गरिन्छ, उही निर्भरताका साथ। तदनुसार, तपाइँसँग वस्तुतः कुनै सम्भावना छैन कि उत्पादनमा के समाप्त हुनेछ जुन तपाइँले पहिले स्थानीय वा तपाइँको परीक्षण वातावरणमा परीक्षण गर्नुभएको होइन।
2. हामीले पनि पर्याप्त भएको पाएका छौं नयाँ सेवा थप्न सजिलो। परिनियोजनको दृष्टिकोणबाट, कुनै पनि नयाँ प्रणालीहरू धेरै सरल रूपमा सुरू गरिन्छ। कन्फिगहरू भण्डारण गर्ने भण्डारमा जानुहोस्, त्यहाँ तपाईंको प्रणालीको लागि अर्को कन्फिगरेसन थप्नुहोस्, र तपाईं पूर्ण रूपमा तयार हुनुहुन्छ। तपाईं devops बाट कुनै पनि अतिरिक्त प्रयास बिना उत्पादनमा आफ्नो प्रणाली तैनात गर्न सक्नुहुन्छ।
3. सबै कन्फिगरेसन फाइलहरू एउटा साझा भण्डारमा समीक्षा अन्तर्गत बाहिर निस्कियो। भर्चुअल सर्भरहरू प्रयोग गरेर हामीले हाम्रा प्रणालीहरू प्रयोग गर्ने समयमा, हामीले Ansible प्रयोग गर्यौं, जसमा कन्फिगहरू एउटै भण्डारमा थिए। यद्यपि, धेरै विकासकर्ताहरूको लागि यो काम गर्न अलि बढी गाह्रो थियो। यहाँ कन्फिगरेसन र कोडको भोल्युम जुन तपाईले सेवा प्रयोग गर्न थप्नु पर्छ धेरै सानो भएको छ। साथै, यसलाई ठीक गर्न वा परिवर्तन गर्न devops को लागि धेरै सजिलो छ। ट्रान्जिसनको अवस्थामा, उदाहरणका लागि, Nomad को नयाँ संस्करणमा, तिनीहरूले एकै ठाउँमा अवस्थित सबै अपरेटिङ फाइलहरू लिन र बल्क अपडेट गर्न सक्छन्।

तर हामीले धेरै बेफाइदाहरू पनि सामना गर्यौं:

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

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

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

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

Kubernetes मा संक्रमण

म तपाईलाई कुबेरनेटका आधारभूत अवधारणाहरू र तिनीहरू नोमाडबाट कसरी भिन्न छन् भन्ने बारे थोरै बताउनेछु।

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

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

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

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

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

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

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

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

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

हेल्ममा आधारभूत अवधारणाहरू

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

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

हेल्मले हाम्रो लागि केही थप अवधारणाहरू थप्छ।

चार्ट - यो तपाईंको सेवाको विवरण हो। अन्य प्याकेज प्रबन्धकहरूमा यसलाई प्याकेज, बन्डल वा यस्तै केहि भनिन्छ। यहाँ यसलाई चार्ट भनिन्छ।

मान टेम्प्लेटहरूबाट तपाइँको कन्फिगहरू निर्माण गर्न प्रयोग गर्न चाहनुहुने चरहरू हुन्।

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

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

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

यसले हामीलाई के दियो?

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

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

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

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

निष्कर्ष

Kubernetes सेवा Nomad भन्दा बढी जटिल देखिन्छ।

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

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

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

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

स्रोत: www.habr.com