खोज में परीक्षण के बुनियादी ढांचे का स्वचालन

यह कोई रहस्य नहीं है कि परीक्षण कार्यों, दोनों मैनुअल और स्वचालित, लगातार नए परीक्षण बेंचों के निर्माण की आवश्यकता होती है।
Mail.Ru के लिए खोज ऑटोटैस्ट्स को जल्दी और सभी आवश्यक वातावरणों में ले जाने के लिए, हमें यह जानने की जरूरत है कि एक विशिष्ट कॉन्फ़िगरेशन के साथ नई वर्चुअल मशीनों को जल्दी से कैसे तैनात किया जाए।
हमारे क्लाउड में बड़ी संख्या में वर्चुअल मशीनें WebDriver ब्राउज़र फ़ार्म द्वारा उपयोग की जाती हैं, इसे स्केल करते हुए, हम खोज वेब-इंटरफ़ेस के परीक्षणों को गति देते हैं।
इसके अलावा, आभासी मशीनों पर, हम कोड गुणवत्ता मैट्रिक्स और कवरेज माप एकत्र करने के लिए उपकरण लॉन्च करते हैं, साथ ही हमारे द्वारा विकसित खोज परीक्षण उपकरण भी।

प्रागितिहास

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

1. प्रबंधन और इसे लागू करने वाले पुस्तकालयों के लिए एक एपीआई की उपलब्धता
2. वर्चुअल मशीन स्थिति प्रबंधन
3. वर्चुअल मशीन प्रोफ़ाइल प्रबंधन (मेमोरी / सीपीयू / डिस्क)
4. विभिन्न उपयोगकर्ताओं के लिए कोटा प्रबंधित करना (हम वास्तव में ऐसी स्थिति नहीं चाहते थे जहां एक उपयोगकर्ता अन्य आभासी वातावरण के प्रदर्शन को प्रभावित कर सके)
5. डिस्क सबसिस्टम प्रबंधन (बैकअप / स्नैपशॉट)
6. नेटवर्क प्रबंधन
7. क्षैतिज स्केलिंग क्षमताओं और गलती सहिष्णुता का आवश्यक स्तर
8. जीवित समुदाय
9. विकास की संभावनाएं

निर्णय लेना

Buzzwords के साथ आवश्यकताओं को व्यक्त करते हुए, हम एक निजी क्लाउड के आयोजन के लिए IaaS समाधान की तलाश कर रहे थे। आज तक, बहुत सारे प्लेटफ़ॉर्म इन आवश्यकताओं के अनुरूप हैं। हमने अपना ध्यान निम्नलिखित OpenSource समाधानों की ओर दिया:

• Proxmox VE www.proxmox.com/proxmox-ve
• Xen www.xenproject.org
• OpenStack www.openstack.org
• नीलगिरी www.eucalyptus.com
• Opennebula Opennebula.org

संभावनाओं के संदर्भ में इन परियोजनाओं का मूल्यांकन करने के बाद, विक्रेता के ताले और सामुदायिक गतिविधि की कमी, हमने ओपनस्टैक के पक्ष में फैसला किया।

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

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

परिनियोजन चरण में, हमें कुछ कठिनाइयों का सामना करना पड़ा: 2012 के अंत में, ओपनस्टैक को इतनी आसानी से CentOS पर तैनात नहीं किया गया था, और सामान्य तौर पर ओपनस्टैक एक जटिल इंजीनियरिंग-गहन उत्पाद है, इसलिए हम, एक साथ प्रवेशकर्ताओं को तैनात करने और इसे कॉन्फ़िगर करने के लिए बहुत प्रयास किया।
यदि आप इस तरह के समाधान के कार्यान्वयन में लगे हुए हैं, तो बेहतर है यदि आपके पास एक समर्पित व्यक्ति है जो इसकी सभी बारीकियों का पता लगा सकता है और यदि आवश्यक हो, तो कुछ सेवाओं के कार्यान्वयन के विवरण में तल्लीनता से।

घटकों के संपर्क की योजना, हम इस तरह दिखते हैं:

कॉन्फ़िगरेशन प्रबंधन

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

• साल्टस्टैक नमकीन
• ऑप्सकोड शेफ www.getchef.com
• कठपुतली puppetlabs.com

हमारे लिए महत्वपूर्ण चयन मानदंडों में से एक विंडोज एक्सपी के साथ काम करने की क्षमता थी, क्योंकि हमारे आंकड़ों के अनुसार, यह रूसी बाजार में डेस्कटॉप सिस्टम के बीच दूसरे स्थान पर मजबूती से खड़ा है। कठपुतली तुरंत इस मानदंड से गिरा दिया - उस समय XP को आधिकारिक दस्तावेज में सूचीबद्ध नहीं किया गया था।
साल्टस्टैक, अपने वादे और मेरी व्यक्तिगत सहानुभूति (परियोजना पायथन में लिखी गई है) के बावजूद, काफी हद तक कच्चा है, और कई चीजों को स्वतंत्र रूप से लागू करना होगा (नए नोड्स के बूटस्ट्रैप, क्लाउड-इनिट के साथ एकीकरण, वेब एपीआई की उपलब्धता, आदि) या तो। विकास के उन तक पहुंचने के लिए परियोजना की प्रतीक्षा करें।
अंत में, चुनाव बावर्ची पर गिर गया: यह हमारे लिए सबसे उपयुक्त है
आवश्यकताओं, साथ ही इसके विकास और सामुदायिक गतिविधि की गतिशीलता अपने प्रतिद्वंद्वी (नमक) से काफी आगे है।

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

परीक्षण

अलग से, यह बात करने योग्य है कि हम कुकबुक का परीक्षण और डिबग कैसे करते हैं। कुकी का परीक्षण किए बिना, हम भंडार को धक्का नहीं देते हैं और कुकी को बावर्ची को अपलोड नहीं करते हैं। इन उद्देश्यों के लिए हम www.vagrantup.com का उपयोग करते हैं
- यह आपको एक वर्चुअल मशीन बनाने और उसमें शेफ कुकीज लगाने की प्रक्रिया को स्वचालित करने की अनुमति देता है। वैसे, योनि न केवल शेफ के साथ एकीकृत करता है; इसे अन्य सीएमएस नमक / कठपुतली / कोफीन / अनसिबेल के साथ एकीकृत करना भी संभव है।
ऐसा होता है कि सामान्य पहुंच में हमारे लिए कोई आवारा बक्से नहीं होते हैं (यह अक्सर विंडोज़ पर लागू होता है - लाइसेंसिंग नीति की प्रकृति के कारण), या बक्से को पहले इकट्ठा करने की आवश्यकता होती है। ऐसे मामलों में, हम veewee का उपयोग करते हैं। Veewee आवारा पेटियों को तैयार करने का एक उपकरण है, यह टारगेट ऑपरेटिंग सिस्टमों के लिए आवारा बॉक्स फाइलों की असेंबली को स्वचालित करता है। हम सक्रिय रूप से विंडोज बॉक्स की तैयारी का परीक्षण करने के लिए, साथ ही विंडोज की अप्राप्य स्थापना का परीक्षण करने के लिए veewee का उपयोग करते हैं।

मामलों का उपयोग करें

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

1. सबसे पहले, हम इन प्रणालियों के लिए योनि बक्से तैयार करते हैं (यदि पहले से कोई नहीं हैं)।
2. फिर हम कुकबुक (चाकू कुकबुक क्रिएट ...) बनाते हैं, जो इनमें से प्रत्येक सिस्टम पर अमीगो की स्थापना का वर्णन करते हैं (कुछ मामलों में प्रक्रिया को एकीकृत किया जाएगा, कुछ में ऑपरेटिंग सिस्टम पर पूर्व शर्त और निर्भरता जोड़ना आवश्यक होगा)।
3. अगला कदम यह जांचना है कि क्या हमारे द्वारा बनाई गई कुकी को लक्ष्य ऑपरेटिंग सिस्टम (योनि) में से प्रत्येक के लिए सही ढंग से रोल किया गया है, धारणा को सरल बनाने के लिए एक आंकड़ा:
4. परीक्षण करने के बाद, हम बावर्ची और उसके आश्रितों को शेफ सर्वर (चाकू स्पार्क अपलोड ...) पर अपलोड करते हैं।
5. हम भूमिकाएं बनाते हैं, वर्णन करते हैं और लोड करते हैं (फ़ाइल से चाकू की भूमिका ...)।
6. और अंतिम चरण लक्ष्य ओएस के साथ आभासी मशीनें बना रहा है, उन्हें भूमिकाएं सौंप रहा है (चाकू ओपनस्टैक सर्वर क्रिएट ...)। एक और व्याख्यात्मक ड्राइंग:

कुछ मिनटों के बाद, हमने अपने निपटान में आभासी मशीनों को कॉन्फ़िगर किया है, जिस पर आप आगे के परीक्षण चरण (मैन्युअल और स्वचालित दोनों) कर सकते हैं।

हमें क्या मिला

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

1. हमारे डेस्कटॉप उत्पादों के परीक्षण को गति दें
2. हमारे कस्टम रिपोर्टिंग / परीक्षण निगरानी उपकरणों के लेआउट को स्वचालित करें (हम सक्रिय रूप से निरंतर वितरण प्रथाओं को लागू करते हैं)
3. परीक्षण विभाग (नेक्सस / सोनार, आदि) द्वारा आवश्यक बुनियादी ढांचे के समाधान के सेटअप / लेआउट को गति दें।
4. वातावरण बनाने और कॉन्फ़िगर करने के लिए सिस्टम प्रशासकों के एक विचार-समाधान मैनुअल कार्य श्रृंखला को छोड़कर

यह निस्संदेह फायदे की सूची में जोड़ना संभव है कि यह समाधान ओपनसोर्स घटकों पर आधारित है (विंडोज वर्चुअल मशीनों के अपवाद के साथ, लाइसेंस जिनके लिए हम MSDN सदस्यता प्राप्त करते हैं)।

भविष्य के लिए योजनाएं विंडोज के निर्माण के लिए शेफ और वीवी टेम्पलेट के लिए हमारी रसोई की किताबों का अनावरण करने के लिए हैं (हमारे पास उन्हें मानक से थोड़ा अलग है)। यदि यह विषय समुदाय के लिए रुचि रखता है, तो हम ओपनस्टैक (रैकस्पेस / hpcloud) के लिए विंडोज छवियों को तैयार करने की सुविधाओं के बारे में एक लेख लिखने की योजना भी बनाते हैं।