उत्तरदायी: 120 महिनामा CoreOS बाट CentOS मा 18 VM कन्फिगरेसनको माइग्रेसन

यो भाषणको ट्रान्सक्रिप्ट हो DevopsConf 2019-10-01 и SPbLUG २०१९-०९-२५.

यो एउटा परियोजनाको कथा हो जसले स्व-लिखित कन्फिगरेसन व्यवस्थापन प्रणाली प्रयोग गर्‍यो र किन उत्तरदायीमा सार्न 18 महिना लाग्यो।

दिन नम्बर -ख्ख: सुरु हुनु अघि

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

अनुकूलन कन्फिगरेसन व्यवस्थापन समाधान

मूल विचार, मलाई शंका छ, IaC को रूपमा परिकल्पना गरिएको थियो: धेरै स्टेटलेस VM हरू जसले रिबुट गर्दा आफ्नो अवस्था शून्यमा रिसेट गर्दछ। VM कन्फिगरेसन व्यवस्थापन के थियो? योजनाबद्ध रूपमा यो सरल देखिन्छ:

1. VM को लागि एक स्थिर MAC कोल गरिएको थियो।
2. CoreOS भएको ISO र बुट डिस्क VM मा जडान गरिएको थियो।
3. CoreOS ले यसको IP मा आधारित WEB सर्भरबाट डाउनलोड गरेर अनुकूलन स्क्रिप्ट सुरु गर्छ।
4. स्क्रिप्टले IP ठेगानामा आधारित SCP मार्फत VM कन्फिगरेसन डाउनलोड गर्छ।
5. Systemd एकाइ फाइलहरूको फुटक्लोथ र bash स्क्रिप्टहरूको फुटक्लोथ सुरु गरियो।

यस समाधानमा धेरै स्पष्ट समस्याहरू थिए:

1. CoreOS ISO लाई बहिष्कार गरिएको छ।
2. VM हरू माइग्रेट/सिर्जना गर्दा धेरै जटिल स्वचालित कार्यहरू र जादू।
3. अद्यावधिक गर्न कठिनाई र जब सफ्टवेयर को एक निश्चित संस्करण आवश्यक छ। कर्नेल मोड्युलहरूसँग अझ रमाइलो।
4. VM हरू डाटा बिना प्राप्त भएन, अर्थात्। VMs अतिरिक्त प्रयोगकर्ता डेटा माउन्ट गरिएको डिस्कको साथ देखा पर्‍यो।
5. कसैले लगातार सिस्टमड इकाई निर्भरताहरू स्क्रू गर्दै थियो र CoreOS रिबुट गर्दा फ्रिज हुनेछ। CoreOS मा उपलब्ध उपकरणहरू प्रयोग गरेर यसलाई समात्न गाह्रो थियो।
6. गोप्य व्यवस्थापन।
7. मुख्यमन्त्री थिएनन् । त्यहाँ CoreOS को लागि bash र YML कन्फिगहरू थिए।

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

दिन #0: समस्या पहिचान गर्नुहोस्

यो सामान्य विकास पूर्वाधार थियो: जेन्किन्स, परीक्षण वातावरण, निगरानी, ​​रजिस्ट्री। CoreOS k8s क्लस्टरहरू होस्टिंगको लागि डिजाइन गरिएको थियो, अर्थात्। समस्या CoreOS कसरी प्रयोग गरिएको थियो। पहिलो चरण स्ट्याक चयन थियो। हामी बस्यौं:

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

दिन नम्बर 30: अवस्थित सम्झौताहरू फिक्स गर्दै - कोडको रूपमा सम्झौताहरू

स्ट्याक स्पष्ट भएपछि, सार्नको लागि तयारी सुरु भयो। कोडको रूपमा अवस्थित सम्झौताहरू फिक्स गर्दै (संहिताको रूपमा सम्झौताहरू!) संक्रमण शारीरिक श्रम -> यान्त्रिकीकरण -> स्वचालन.

1. VMs कन्फिगर गर्नुहोस्

Ansible यस को एक महान काम गर्दछ। शरीरको न्यूनतम आन्दोलनको साथ तपाईंले VM कन्फिगरेसनहरूको नियन्त्रण लिन सक्नुहुन्छ:

1. Git भण्डार सिर्जना गर्नुहोस्।
2. हामीले VM को सूची सूचीमा राख्छौं, प्लेबुकहरूमा कन्फिगरेसनहरू र भूमिकाहरू।
3. हामीले एउटा विशेष जेनकिन्स स्लेभ सेटअप गर्दैछौं जसबाट तपाईंले Ansible चलाउन सक्नुहुन्छ।
4. हामी एउटा काम सिर्जना गर्छौं र जेनकिन्स कन्फिगर गर्छौं।

पहिलो प्रक्रिया तयार छ। सम्झौताहरू निश्चित छन्।

2. नयाँ VM सिर्जना गर्नुहोस्

यहाँ सबै कुरा धेरै सुविधाजनक थिएन। Linux बाट Hyper-V मा VM हरू सिर्जना गर्न यो धेरै सुविधाजनक छैन। यस प्रक्रियालाई यान्त्रिकीकरण गर्ने प्रयासहरू मध्ये एक थियो:

1. Ansbile WinRM मार्फत विन्डोज होस्टमा जडान हुन्छ।
2. Ansible ले पावरशेल स्क्रिप्ट चलाउँछ।
3. Powershell स्क्रिप्टले नयाँ VM सिर्जना गर्दछ।
4. Hyper-V/ScVMM प्रयोग गरेर, अतिथि OS मा VM सिर्जना गर्दा, होस्टनाम कन्फिगर गरिएको छ।
5. DHCP लीज अपडेट गर्दा, VM ले आफ्नो होस्टनाम पठाउँछ।
6. डोमेन कन्ट्रोलर साइडमा मानक ddns र dhcp एकीकरणले DNS रेकर्ड कन्फिगर गर्दछ।
7. तपाईं आफ्नो सूचीमा VM थप्न सक्नुहुन्छ र यसलाई Ansible मार्फत कन्फिगर गर्न सक्नुहुन्छ।

3. VM टेम्प्लेट सिर्जना गर्नुहोस्

तिनीहरूले यहाँ केहि आविष्कार गरेनन् - तिनीहरूले प्याकर लिए।

1. git भण्डारमा प्याकर, किकस्टार्ट कन्फिगरेसन थप्नुहोस्।
2. हाइपर-वी र प्याकरको साथ एक विशेष जेनकिन्स दास सेटअप गर्दै।
3. हामी एउटा काम सिर्जना गर्छौं र जेनकिन्स कन्फिगर गर्छौं।

यो लिङ्क कसरी काम गर्दछ:

1. प्याकरले खाली VM सिर्जना गर्छ र ISO उठाउँछ।
2. VM बुट, प्याकरले फ्लपी डिस्क वा http बाट हाम्रो किकस्टार्ट फाइल प्रयोग गर्न बुटलोडरमा आदेश प्रविष्ट गर्दछ।
3. Anaconda हाम्रो कन्फिगरेसनको साथ सुरु गरिएको छ, र प्रारम्भिक OS कन्फिगरेसन सकियो।
4. प्याकर VM उपलब्ध हुनको लागि पर्खन्छ।
5. VM भित्रको प्याकर स्थानीय मोडमा ansible चल्छ।
6. Ansible ले ठ्याक्कै उही भूमिकाहरू प्रयोग गर्दछ जुन यसले चरण # 1 मा काम गर्दछ।
7. प्याकरले VM टेम्प्लेट निर्यात गर्छ।

दिन #75: बिना तोडेको सम्झौता रिफ्याक्टर = टेस्ट उत्तरदायी + टेस्टकिचेन

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

दिन #130: हुनसक्छ CentOS + ansible आवश्यक छैन? शायद ओपनशिफ्ट?

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

दिन #170: Openshift उपयुक्त छैन, आउनुहोस् Windows Azure Pack को साथ एक मौका लिनुहोस्?

Hyper-V धेरै अनुकूल छैन, SCVMM ले यसलाई धेरै राम्रो बनाउँदैन। तर त्यहाँ विन्डोज Azure प्याक जस्ता चीज छ, जुन SCVMM मा एक एड-अन हो र Azure को नक्कल गर्दछ। तर वास्तविकतामा, उत्पादन परित्याग गरिएको देखिन्छ: कागजातले लिङ्क तोडेको छ र धेरै विरल छ। तर हाम्रो क्लाउडको जीवनलाई सरल बनाउने विकल्पहरूको अध्ययनको भागको रूपमा, तिनीहरूले यसलाई पनि हेरे।

दिन #250: Windows Azure प्याक धेरै राम्रो छैन। हामी SCVMM मा रहन्छौं

Windows Azure Pack आशाजनक देखिन्थ्यो, तर अनावश्यक सुविधाहरूको खातिर WAP लाई यसको जटिलताहरू सहित प्रणालीमा ल्याउन नदिने निर्णय गरियो र SCVMM मा रह्यो।

दिन #360: हात्ती टुक्रा टुक्रा खाँदै

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

दिन #450: तपाईंले कस्तो प्रकारको प्रणाली पाउनुभयो?

प्रक्रिया आफैमा रोचक छैन। यो दिनचर्या हो, यो नोट गर्न सकिन्छ कि अधिकांश कन्फिगरेसनहरू अपेक्षाकृत सरल वा आइसोमोर्फिक थिए र Pareto सिद्धान्त अनुसार, VM कन्फिगरेसनहरूको 80% समयको 20% आवश्यक छ। उही सिद्धान्त अनुसार, 80% समय चालको तयारीमा र 20% मात्र चालमा खर्च भएको थियो।

दिन #540: फाइनल

१८ महिनामा के भयो ?

1. सम्झौताहरू संहिता बने।
2. शारीरिक श्रम -> यान्त्रिकीकरण -> स्वचालन.

लिंक

• अंग्रेजी संस्करण
• व्यक्तिगत ब्लगबाट क्रस पोस्ट
• स्लाइडहरू
• कसरी उत्तरदायी परीक्षण सुरु गर्ने, एक वर्षमा प्रोजेक्ट रिफ्याक्टर गर्नुहोस् र पागल नहुनुहोस्
• पूर्वाधार संहिताको 200 भन्दा बढी लाइनहरू परीक्षणबाट सिकेका पाठहरू
• ओपनशिफ्टमा तैनाथ गरौं
• तपाईको आफ्नै OS वितरण कसरी परीक्षण गर्ने
• यदि तपाईं सक्नुहुन्छ भने मलाई परीक्षण गर्नुहोस्। के YML विकासकर्ताहरूले परीक्षणको सपना देख्छन्?

स्रोत: www.habr.com