भाग 1: वेब/एंड्रॉइड

नोट: यह लेख मूल लेख का रूसी में अनुवाद है “DevOps उपकरण केवल DevOps के लिए नहीं हैं। "शुरुआत से परीक्षण स्वचालन बुनियादी ढांचे का निर्माण।" हालाँकि, रूसी में अनुवादित होने पर अर्थ की विकृति से बचने के लिए सभी चित्र, लिंक, उद्धरण और शब्द मूल भाषा में संरक्षित हैं। मैं कामना करता हूँ कि आप पढ़ाई में प्रसन्न हों!

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

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

स्रोत: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

यहां हम संभवतः परिचयात्मक भाग के साथ समाप्त करेंगे और इस लेख के उद्देश्य पर ध्यान केंद्रित करेंगे। 

यह लेख किस बारे में है?

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

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

इस आर्टिकल में क्या नहीं है

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

ऐसा इसलिए किया जाता है क्योंकि: 

• यह सामग्री विभिन्न स्रोतों (दस्तावेज़ीकरण, किताबें, वीडियो पाठ्यक्रम) में ढूंढना बहुत आसान है;
• यदि हम गहराई में जाना शुरू करें तो हमें इस लेख के 10, 20, 30 भाग लिखने होंगे (जबकि योजनाएँ 2-3 हैं);
• मैं आपका समय बर्बाद नहीं करना चाहता क्योंकि आप समान लक्ष्य प्राप्त करने के लिए अन्य उपकरणों का उपयोग करना चाह सकते हैं।

अभ्यास

मैं सचमुच चाहूंगा कि यह सामग्री प्रत्येक पाठक के लिए उपयोगी हो, न कि केवल पढ़कर भूल जाए। किसी भी अध्ययन में अभ्यास एक बहुत ही महत्वपूर्ण घटक है। इसके लिए मैंने तैयारी कर ली है स्क्रैच से सब कुछ कैसे करें, इस पर चरण-दर-चरण निर्देशों के साथ GitHub रिपॉजिटरी. यह सुनिश्चित करने के लिए होमवर्क भी आपका इंतजार कर रहा है कि आप बिना सोचे-समझे उन आदेशों की पंक्तियों की नकल न करें जिन्हें आप निष्पादित कर रहे हैं।

योजना

कदम
टेक्नोलॉजी
टूल्स

1
स्थानीय रनिंग (वेब/एंड्रॉइड डेमो परीक्षण तैयार करें और इसे स्थानीय रूप से चलाएं) 
नोड.जेएस, सेलेनियम, एपियम

2
संस्करण नियंत्रण प्रणाली 
जाना

3
कन्टेनरीकरण
डॉकर, सेलेनियम ग्रिड, सेलेनॉइड (वेब, एंड्रॉइड)

4
सीआई/सीडी
गिटलैब सीआई

5
बादल मंच
Google Cloud Platform

6
वाद्य-स्थान
Kubernetes

7
एक कोड के रूप में इन्फ्रास्ट्रक्चर (IaC)
टेराफॉर्म, अन्सिबल

प्रत्येक अनुभाग की संरचना

कथा को स्पष्ट रखने के लिए, प्रत्येक अनुभाग का वर्णन निम्नलिखित रूपरेखा के अनुसार किया गया है:

• प्रौद्योगिकी का संक्षिप्त विवरण,
• स्वचालन बुनियादी ढांचे के लिए मूल्य,
• बुनियादी ढांचे की वर्तमान स्थिति का चित्रण,
• अध्ययन के लिए लिंक,
• समान उपकरण.

1. स्थानीय स्तर पर परीक्षण चलाएँ

प्रौद्योगिकी का संक्षिप्त विवरण

यह स्थानीय स्तर पर डेमो परीक्षण चलाने और यह सत्यापित करने के लिए एक प्रारंभिक कदम है कि वे पास हो गए हैं। व्यावहारिक भाग में, Node.js का उपयोग किया जाता है, लेकिन प्रोग्रामिंग भाषा और प्लेटफ़ॉर्म भी महत्वपूर्ण नहीं हैं और आप उनका उपयोग कर सकते हैं जो आपकी कंपनी में उपयोग किए जाते हैं। 

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

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

बुनियादी ढांचे के नजरिए से, स्थानीय स्तर पर चलने से कोई मूल्य नहीं मिलता है। आप केवल यह जांचें कि परीक्षण स्थानीय ब्राउज़र और सिमुलेटर में स्थानीय मशीन पर चलते हैं या नहीं। लेकिन किसी भी मामले में, यह एक आवश्यक प्रारंभिक बिंदु है।

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

तलाशने के लिए लिंक

• सेलेनियम
• Appium
• एंड्रॉइड एमुलेटर
• सेलेनियम जेएस गिटहब उदाहरण
• एपियम जेएस गिटहब उदाहरण

समान उपकरण

• सेलेनियम/एपियम परीक्षणों के संयोजन में कोई भी प्रोग्रामिंग भाषा जो आपको पसंद हो;
• कोई परीक्षण;
• कोई भी परीक्षण धावक।

2. संस्करण नियंत्रण प्रणाली (Git)

प्रौद्योगिकी का संक्षिप्त विवरण

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

और यहाँ आप एक उचित प्रश्न पूछ सकते हैं: “वह हमें Git के बारे में क्यों बता रहा है? हर कोई इसे जानता है और इसका उपयोग विकास कोड और ऑटो-टेस्ट कोड दोनों के लिए करता है। आप बिल्कुल सही होंगे, लेकिन इस लेख में हम बुनियादी ढांचे के बारे में बात कर रहे हैं और यह खंड धारा 7 के पूर्वावलोकन के रूप में कार्य करता है: "इन्फ्रास्ट्रक्चर एज़ कोड (IaC)"। हमारे लिए, इसका मतलब है कि परीक्षण सहित संपूर्ण बुनियादी ढांचे को कोड के रूप में वर्णित किया गया है, इसलिए हम इसमें वर्जनिंग सिस्टम भी लागू कर सकते हैं और विकास और स्वचालन कोड के समान लाभ प्राप्त कर सकते हैं।

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

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

तलाशने के लिए लिंक

• संस्करण नियंत्रण क्या है
• जाना
• आरंभ करना - संस्करण नियंत्रण के बारे में

समान उपकरण

• SVN
• अस्थिर 
• Microsoft TFS (अब Azure DevOps Services का हिस्सा है)

3. कंटेनरीकरण (डॉकर)

प्रौद्योगिकी का संक्षिप्त विवरण

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

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

और अब हम कंटेनरीकरण पर आते हैं। एक बार फिर, यह तकनीक पिछली समस्या को हल करती है, क्योंकि कंटेनर पूर्ण ओएस का उपयोग नहीं करते हैं, जो बड़ी मात्रा में संसाधनों को मुक्त करता है और पोर्टेबिलिटी के लिए तेज़ और लचीला समाधान प्रदान करता है।

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

हमें पता चला कि कंटेनरीकरण और डॉकर अच्छे हैं। आइए इसे स्वचालन के संदर्भ में देखें, क्योंकि प्रत्येक उपकरण या तकनीक को एक समस्या को हल करने की आवश्यकता होती है। आइए हम यूआई परीक्षणों के संदर्भ में परीक्षण स्वचालन की स्पष्ट समस्याओं की रूपरेखा तैयार करें:

• सेलेनियम और विशेष रूप से एपियम को स्थापित करते समय बड़ी संख्या में निर्भरताएँ;
• ब्राउज़र, सिमुलेटर और ड्राइवरों के संस्करणों के बीच संगतता समस्याएं;
• ब्राउज़र/सिम्युलेटर के लिए पृथक स्थान की कमी, जो समानांतर रूप से चलने के लिए विशेष रूप से महत्वपूर्ण है;
• यदि आपको एक ही समय में 10, 50, 100 या यहाँ तक कि 1000 ब्राउज़र चलाने की आवश्यकता हो तो इसे प्रबंधित करना और बनाए रखना मुश्किल है।

लेकिन चूंकि सेलेनियम सबसे लोकप्रिय स्वचालन उपकरण है और डॉकर सबसे लोकप्रिय कंटेनरीकरण उपकरण है, इसलिए इसमें कोई आश्चर्य नहीं होना चाहिए कि किसी ने उपर्युक्त समस्याओं को हल करने के लिए एक शक्तिशाली उपकरण बनाने के लिए उन्हें संयोजित करने का प्रयास किया है। आइए ऐसे समाधानों पर अधिक विस्तार से विचार करें। 

डॉकर में सेलेनियम ग्रिड

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

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

वेब के लिए सेलेनॉइड

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

लेकिन, अफसोस, सेलेनॉइड अभी भी चांदी की गोली नहीं है। हमें 'मांग पर ब्राउज़र' सुविधा तो मिल गई, लेकिन 'मांग पर संसाधन' सुविधा अभी भी उपलब्ध नहीं है। सेलेनॉइड का उपयोग करने के लिए, हमें इसे भौतिक हार्डवेयर या वीएम पर तैनात करना होगा, जिसका अर्थ है कि हमें पहले से पता होना चाहिए कि कितने संसाधनों को आवंटित करने की आवश्यकता है। मुझे लगता है कि यह उन छोटी परियोजनाओं के लिए कोई समस्या नहीं है जो समानांतर में 10, 20 या 30 ब्राउज़र चलाते हैं। लेकिन अगर हमें 100, 500, 1000 या अधिक की आवश्यकता हो तो क्या होगा? हर समय इतने सारे संसाधनों का रखरखाव और भुगतान करने का कोई मतलब नहीं है। इस लेख के खंड 5 और 6 में, हम उन समाधानों पर चर्चा करेंगे जो आपको बड़े पैमाने पर काम करने की अनुमति देते हैं, जिससे कंपनी की लागत में काफी कमी आती है।

एंड्रॉइड के लिए सेलेनॉइड

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

मैं वास्तव में इस टूल के नकारात्मक पहलुओं के बारे में बात नहीं करना चाहूंगा, क्योंकि मुझे यह वास्तव में पसंद है। लेकिन फिर भी, वही नुकसान हैं जो वेब ऑटोमेशन पर लागू होते हैं और स्केलिंग से जुड़े होते हैं। इसके अलावा, हमें एक और सीमा के बारे में बात करने की ज़रूरत है जो आश्चर्यचकित कर सकती है अगर हम पहली बार टूल सेट कर रहे हैं। एंड्रॉइड छवियों को चलाने के लिए, हमें नेस्टेड वर्चुअलाइजेशन समर्थन के साथ एक भौतिक मशीन या वीएम की आवश्यकता है। कैसे करें मार्गदर्शिका में, मैं प्रदर्शित करता हूं कि लिनक्स वीएम पर इसे कैसे सक्षम किया जाए। हालाँकि, यदि आप एक macOS उपयोगकर्ता हैं और सेलेनॉइड को स्थानीय रूप से तैनात करना चाहते हैं, तो Android परीक्षण चलाना संभव नहीं होगा। लेकिन आप हमेशा 'नेस्टेड वर्चुअलाइजेशन' कॉन्फ़िगर के साथ स्थानीय रूप से लिनक्स वीएम चला सकते हैं और सेलेनॉइड को अंदर तैनात कर सकते हैं।

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

इस लेख के संदर्भ में, हम बुनियादी ढांचे को चित्रित करने के लिए 2 टूल जोड़ेंगे। ये वेब परीक्षणों के लिए सेलेनियम ग्रिड और एंड्रॉइड परीक्षणों के लिए सेलेनॉइड हैं। GitHub ट्यूटोरियल में, मैं आपको यह भी दिखाऊंगा कि वेब परीक्षण चलाने के लिए सेलेनॉइड का उपयोग कैसे करें। 

तलाशने के लिए लिंक

• डॉकर: कंटेनर क्या है
• डॉकर: आरंभ करें
• डॉकर के लिए 5 कंटेनर विकल्प
• सेलेनियम ग्रिड
• सेलेनियम डोकर
• सेलेनॉइड
• सेलेनॉइड जीथब
• एंड्रॉइड एमुलेटर के लिए KVM सेटअप
• डॉकर डीप डाइव पुस्तक

समान उपकरण

• अन्य कंटेनरीकरण उपकरण हैं, लेकिन डॉकर सबसे लोकप्रिय है। यदि आप कुछ और आज़माना चाहते हैं, तो ध्यान रखें कि सेलेनियम परीक्षणों को समानांतर में चलाने के लिए हमने जिन उपकरणों को कवर किया है, वे बॉक्स से बाहर काम नहीं करेंगे।  
• जैसा कि पहले ही कहा गया है, सेलेनियम ग्रिड के कई संशोधन हैं, उदाहरण के लिए, ज़ेलेनियम.

4.सीआई/सीडी

प्रौद्योगिकी का संक्षिप्त विवरण

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

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

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

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

और इससे पहले कि हम आर्किटेक्चर परिवर्तन का चित्रण देखें, मैं GitLab CI के बारे में कुछ शब्द कहना चाहता हूं। अन्य CI/CD टूल के विपरीत, GitLab एक रिमोट रिपॉजिटरी और कई अन्य अतिरिक्त सुविधाएँ प्रदान करता है। इस प्रकार, GitLab CI से अधिक है। इसमें सोर्स कोड प्रबंधन, एजाइल प्रबंधन, सीआई/सीडी पाइपलाइन, लॉगिंग टूल और मेट्रिक्स संग्रह शामिल हैं। GitLab आर्किटेक्चर में Gitlab CI/CD और GitLab Runner शामिल हैं। यहां आधिकारिक वेबसाइट से एक संक्षिप्त विवरण दिया गया है:

Gitlab CI/CD एक एपीआई के साथ एक वेब एप्लिकेशन है जो अपने राज्य को डेटाबेस में संग्रहीत करता है, परियोजनाओं/निर्माण का प्रबंधन करता है और एक यूजर इंटरफेस प्रदान करता है। GitLab Runner एक एप्लिकेशन है जो बिल्ड को प्रोसेस करता है। इसे अलग से तैनात किया जा सकता है और एक एपीआई के माध्यम से GitLab CI/CD के साथ काम करता है। परीक्षण चलाने के लिए आपको Gitlab इंस्टेंस और रनर दोनों की आवश्यकता होगी।

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

तलाशने के लिए लिंक

• मार्टिन फाउलर: सतत एकीकरण
• गिटलब सीआई / सीडी
• सतत एकीकरण पुस्तक
• सतत वितरण पुस्तक

समान उपकरण

• जेनकींस
• TeamCity
• ट्रेविस 
• गंभीर प्रयास

5. क्लाउड प्लेटफार्म

प्रौद्योगिकी का संक्षिप्त विवरण

इस अनुभाग में हम 'पब्लिक क्लाउड्स' नामक एक लोकप्रिय प्रवृत्ति के बारे में बात करेंगे। ऊपर वर्णित वर्चुअलाइजेशन और कंटेनरीकरण प्रौद्योगिकियों द्वारा प्रदान किए जाने वाले भारी लाभों के बावजूद, हमें अभी भी कंप्यूटिंग संसाधनों की आवश्यकता है। कंपनियां महंगे सर्वर खरीदती हैं या डेटा सेंटर किराए पर लेती हैं, लेकिन इस मामले में यह गणना करना आवश्यक है (कभी-कभी अवास्तविक) कि हमें कितने संसाधनों की आवश्यकता होगी, क्या हम उन्हें 24/7 और किस उद्देश्य के लिए उपयोग करेंगे। उदाहरण के लिए, उत्पादन के लिए XNUMX/XNUMX चलने वाले सर्वर की आवश्यकता होती है, लेकिन क्या हमें कार्य घंटों के बाहर परीक्षण के लिए समान संसाधनों की आवश्यकता है? यह किए जा रहे परीक्षण के प्रकार पर भी निर्भर करता है। एक उदाहरण भार/तनाव परीक्षण होगा जिसे हम अगले दिन परिणाम प्राप्त करने के लिए गैर-कार्य घंटों के दौरान चलाने की योजना बनाते हैं। लेकिन निश्चित रूप से एंड-टू-एंड स्वचालित परीक्षणों के लिए XNUMX/XNUMX सर्वर उपलब्धता की आवश्यकता नहीं है और विशेष रूप से मैन्युअल परीक्षण वातावरण के लिए नहीं। ऐसी स्थितियों के लिए, मांग पर जितने संसाधनों की आवश्यकता हो, उन्हें प्राप्त करना, उनका उपयोग करना और जब उनकी आवश्यकता न रह जाए तो भुगतान करना बंद कर देना अच्छा होगा। इसके अलावा, कुछ माउस क्लिक करके या कुछ स्क्रिप्ट चलाकर उन्हें तुरंत प्राप्त करना बहुत अच्छा होगा। सार्वजनिक बादलों का उपयोग इसी के लिए किया जाता है। आइए परिभाषा देखें:

“सार्वजनिक क्लाउड को सार्वजनिक इंटरनेट पर तीसरे पक्ष के प्रदाताओं द्वारा दी जाने वाली कंप्यूटिंग सेवाओं के रूप में परिभाषित किया गया है, जो उन्हें किसी भी व्यक्ति के लिए उपलब्ध कराता है जो उनका उपयोग करना या खरीदना चाहता है। वे मुफ़्त हो सकते हैं या ऑन-डिमांड बेचे जा सकते हैं, जिससे ग्राहकों को केवल उनके द्वारा उपभोग किए जाने वाले सीपीयू चक्र, भंडारण या बैंडविड्थ के लिए प्रति उपयोग भुगतान करने की अनुमति मिलती है।"

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

एंड-टू-एंड यूआई परीक्षणों के लिए हमें किन विशिष्ट संसाधनों की आवश्यकता है? मूल रूप से ये ब्राउज़र और एमुलेटर चलाने के लिए वर्चुअल मशीन या क्लस्टर हैं (हम अगले भाग में कुबेरनेट्स के बारे में बात करेंगे)। हम जितने अधिक ब्राउज़र और एमुलेटर एक साथ चलाना चाहते हैं, उतने अधिक सीपीयू और मेमोरी की आवश्यकता होती है और हमें इसके लिए उतने ही अधिक पैसे चुकाने पड़ते हैं। इस प्रकार, परीक्षण स्वचालन के संदर्भ में सार्वजनिक क्लाउड हमें मांग पर बड़ी संख्या में (100, 200, 1000...) ब्राउज़र/एमुलेटर चलाने, जितनी जल्दी हो सके परीक्षण परिणाम प्राप्त करने और ऐसे अत्यधिक संसाधन-गहन के लिए भुगतान करना बंद करने की अनुमति देते हैं। शक्ति। 

सबसे लोकप्रिय क्लाउड प्रदाता Amazon Web Services (AWS), Microsoft Azure, Google Cloud प्लेटफ़ॉर्म (GCP) हैं। कैसे करें मार्गदर्शिका GCP का उपयोग कैसे करें के उदाहरण प्रदान करती है, लेकिन सामान्य तौर पर इससे कोई फर्क नहीं पड़ता कि आप स्वचालन कार्यों के लिए क्या उपयोग करते हैं। वे सभी लगभग समान कार्यक्षमता प्रदान करते हैं। आमतौर पर, एक प्रदाता का चयन करने के लिए, प्रबंधन कंपनी के समग्र बुनियादी ढांचे और व्यावसायिक आवश्यकताओं पर ध्यान केंद्रित करता है, जो इस लेख के दायरे से परे है। स्वचालन इंजीनियरों के लिए, क्लाउड प्रदाताओं के उपयोग की तुलना विशेष रूप से परीक्षण उद्देश्यों के लिए क्लाउड प्लेटफ़ॉर्म के उपयोग से करना अधिक दिलचस्प होगा, जैसे सॉस लैब्स, ब्राउज़रस्टैक, बिटबार, इत्यादि। तो चलिए हम भी ऐसा करते हैं! मेरी राय में, सॉस लैब्स सबसे प्रसिद्ध क्लाउड टेस्टिंग फ़ार्म है, यही कारण है कि मैंने तुलना के लिए इसका उपयोग किया। 

स्वचालन उद्देश्यों के लिए जीसीपी बनाम सॉस लैब्स:

आइए कल्पना करें कि हमें 8 वेब परीक्षण और 8 Android परीक्षण एक साथ चलाने की आवश्यकता है। इसके लिए हम GCP का उपयोग करेंगे और सेलेनॉइड के साथ 2 वर्चुअल मशीनें चलाएंगे। पहले वाले पर हम ब्राउज़रों के साथ 8 कंटेनर जुटाएंगे। दूसरे पर एमुलेटर वाले 8 कंटेनर हैं। आइए एक नजर डालते हैं कीमतों पर:  

Chrome के साथ एक कंटेनर चलाने के लिए, हमें इसकी आवश्यकता है n1-मानक-1 कार। एंड्रॉइड के मामले में यह होगा n1-मानक-4 एक एमुलेटर के लिए. वास्तव में, अधिक लचीला और सस्ता तरीका सीपीयू/मेमोरी के लिए विशिष्ट उपयोगकर्ता मान सेट करना है, लेकिन फिलहाल सॉस लैब्स के साथ तुलना के लिए यह महत्वपूर्ण नहीं है।

और यहां सॉस लैब्स का उपयोग करने के लिए टैरिफ हैं:

मेरा मानना ​​है कि आपने पहले ही अंतर देख लिया है, लेकिन मैं अभी भी हमारे कार्य के लिए गणनाओं के साथ एक तालिका प्रदान करूंगा:

स्रोतों की आवश्यकता
मासिक
काम करने के घंटे(सुबह 8 बजे - रात 8 बजे)
काम करने के घंटे+ प्रीमेप्टिबल

वेब के लिए जीसीपी
n1-मानक-1 x 8 = n1-मानक-8
$194.18
23 दिन * 12 घंटे * 0.38 = $104.88 
23 दिन * 12 घंटे * 0.08 = $22.08

वेब के लिए सॉस लैब्स
वर्चुअल Cloud8 समानांतर परीक्षण
$1.559
-
-

एंड्रॉइड के लिए जीसीपी
n1-मानक-4 x 8: n1-मानक-16
$776.72
23 दिन * 12 घंटे * 1.52 = $419.52 
23 दिन * 12 घंटे * 0.32 = $88.32

Android के लिए सॉस लैब्स
रियल डिवाइस क्लाउड 8 समानांतर परीक्षण
$1.999
-
-

जैसा कि आप देख सकते हैं, लागत में अंतर बहुत बड़ा है, खासकर यदि आप केवल बारह घंटे की कार्य अवधि के दौरान परीक्षण चलाते हैं। लेकिन यदि आप प्रीमेप्टेबल मशीनों का उपयोग करते हैं तो आप लागत में और भी कटौती कर सकते हैं। यह क्या है?

प्रीमेप्टेबल वीएम एक ऐसा उदाहरण है जिसे आप सामान्य उदाहरणों की तुलना में बहुत कम कीमत पर बना और चला सकते हैं। हालाँकि, यदि कंप्यूट इंजन को अन्य कार्यों के लिए उन संसाधनों तक पहुंच की आवश्यकता होती है, तो वह इन उदाहरणों को समाप्त (प्रीमेप्ट) कर सकता है। प्रीमेप्टेबल इंस्टेंसेस अतिरिक्त कंप्यूट इंजन क्षमता हैं, इसलिए उनकी उपलब्धता उपयोग के साथ बदलती रहती है।

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

और यह अभी भी ख़त्म नहीं हुआ है! वास्तव में, मुझे यकीन है कि कोई भी बिना ब्रेक के 12 घंटे तक परीक्षण नहीं चलाता है। और यदि ऐसा है, तो आप आवश्यकता न होने पर वर्चुअल मशीनों को स्वचालित रूप से प्रारंभ और बंद कर सकते हैं। वास्तविक उपयोग का समय प्रतिदिन 6 घंटे तक कम किया जा सकता है। तब हमारे कार्य के संदर्भ में भुगतान 11 ब्राउज़रों के लिए घटकर $8 प्रति माह हो जाएगा। क्या यह अद्भुत नहीं है? लेकिन प्रीमेप्टेबल मशीनों के साथ हमें सावधान रहना चाहिए और रुकावटों और अस्थिरता के लिए तैयार रहना चाहिए, हालांकि इन स्थितियों को सॉफ्टवेयर में प्रदान और नियंत्रित किया जा सकता है। यह इसके लायक है!

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

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

तलाशने के लिए लिंक

• जीसीपी
• जीसीपी: प्रीमेप्टिबल
• जीसीपी: वीएम मूल्य निर्धारण
• सॉसलैब्स
• क्लाउड प्रदाताओं की तुलना करना

समान उपकरण:

• एडब्ल्यूएस 
• नीला

6. आर्केस्ट्रा

प्रौद्योगिकी का संक्षिप्त विवरण

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

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

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

स्वचालन बुनियादी ढांचे के लिए मूल्य

आइए K8s द्वारा प्रदान की जाने वाली कुछ महत्वपूर्ण विशेषताओं पर एक नज़र डालें:

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

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

स्केलिंग सुविधा महत्वपूर्ण है और इसे क्लस्टर नोड-पूल के भीतर दोनों नोड्स और नोड के भीतर पॉड्स पर लागू किया जा सकता है। स्केलिंग 2 प्रकार की होती है जो नोड्स और पॉड्स दोनों पर लागू होती है। पहला प्रकार क्षैतिज है - स्केलिंग नोड्स/पॉड्स की संख्या बढ़ाकर होती है। यह प्रकार अधिक बेहतर है. दूसरा प्रकार, तदनुसार, लंबवत है। स्केलिंग नोड्स/पॉड्स के आकार को बढ़ाकर की जाती है, न कि उनकी संख्या को बढ़ाकर।

आइए अब उपरोक्त शर्तों के संदर्भ में अपने टूल को देखें।

सेलेनियम ग्रिड

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

सेलेनॉइड:

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

चन्द्रमा:

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

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

तो, चंद्रमा एक महान समाधान है, लेकिन एक समस्या है: यह मुफ़्त नहीं है। कीमत सत्रों की संख्या पर निर्भर करती है. आप केवल 0-4 सत्र ही निःशुल्क चला सकते हैं, जो विशेष उपयोगी नहीं है। लेकिन, पांचवें सत्र से शुरू करके, आपको प्रत्येक के लिए $5 का भुगतान करना होगा। स्थिति कंपनी-दर-कंपनी भिन्न हो सकती है, लेकिन हमारे मामले में, चंद्रमा का उपयोग करना व्यर्थ है। जैसा कि मैंने ऊपर बताया है, हम मांग पर सेलेनियम ग्रिड के साथ वीएम चला सकते हैं या क्लस्टर में नोड्स की संख्या बढ़ा सकते हैं। लगभग एक पाइपलाइन के लिए, हम 500 ब्राउज़र लॉन्च करते हैं और परीक्षण पूरा होने के बाद सभी संसाधनों को रोक देते हैं। यदि हमने चंद्रमा का उपयोग किया, तो हमें अतिरिक्त 500 x 5 = $2500 प्रति माह का भुगतान करना होगा, चाहे हम कितनी भी बार परीक्षण चलाएँ। फिर, मैं यह नहीं कह रहा हूं कि चंद्रमा का उपयोग न करें। आपके कार्यों के लिए, यह एक अपरिहार्य समाधान हो सकता है, उदाहरण के लिए, यदि आपके संगठन में कई परियोजनाएं/टीम हैं और आपको सभी के लिए एक विशाल सामान्य क्लस्टर की आवश्यकता है। हमेशा की तरह, मैं अंत में एक लिंक छोड़ता हूं और आपके कार्य के संदर्भ में सभी आवश्यक गणना करने की अनुशंसा करता हूं।

कैलिस्टो: (ध्यान! यह मूल लेख में नहीं है और केवल रूसी अनुवाद में निहित है)

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

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

तलाशने के लिए लिंक

• कुबेरनेट्स: सेटअप
• कुबेरनेट्स: कठिन रास्ता
• कुबेरनेट्स: सेलेनियम
• जीसीपी: कुबेरनेट्स इंजन
• चन्द्रमा
• कुबेरनेट्स पुस्तक
• कुबेरनेट्स का उपयोग करके वितरित स्वचालन
• सेलेनियम ग्रिड 4
• कैलिस्टो गिटहब
• व्रीके टेकक्लब (कैलिस्टो)

समान उपकरण

• डोकर झुंड 
• मैराथन 

7. कोड के रूप में इन्फ्रास्ट्रक्चर (IaC)

प्रौद्योगिकी का संक्षिप्त विवरण

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

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

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

इन उपकरणों की एक अन्य प्रमुख विशिष्ट विशेषता कोडिंग शैली है। बैश और एन्सिबल के विपरीत, टेराफॉर्म निष्पादन के परिणामस्वरूप प्राप्त की जाने वाली वांछित अंतिम स्थिति के विवरण के आधार पर एक घोषणात्मक शैली का उपयोग करता है। उदाहरण के लिए, यदि हम 10 वीएम बनाने जा रहे हैं और टेराफॉर्म के माध्यम से परिवर्तन लागू करते हैं, तो हमें 10 वीएम मिलेंगे। यदि हम स्क्रिप्ट को दोबारा चलाते हैं, तो कुछ नहीं होगा क्योंकि हमारे पास पहले से ही 10 वीएम हैं, और टेराफॉर्म को इसके बारे में पता है क्योंकि यह बुनियादी ढांचे की वर्तमान स्थिति को एक राज्य फ़ाइल में संग्रहीत करता है। लेकिन Ansible एक प्रक्रियात्मक दृष्टिकोण का उपयोग करता है और, यदि आप इसे 10 VMs बनाने के लिए कहते हैं, तो पहले लॉन्च पर हमें टेराफॉर्म के समान 10 VMs मिलेंगे। लेकिन पुनः आरंभ करने के बाद हमारे पास पहले से ही 20 वीएम होंगे। यही महत्वपूर्ण अंतर है. प्रक्रियात्मक शैली में, हम वर्तमान स्थिति को संग्रहीत नहीं करते हैं और केवल उन चरणों के अनुक्रम का वर्णन करते हैं जिन्हें निष्पादित किया जाना चाहिए। बेशक, हम विभिन्न स्थितियों को संभाल सकते हैं, संसाधनों के अस्तित्व और वर्तमान स्थिति के लिए कई जाँचें जोड़ सकते हैं, लेकिन इस तर्क को नियंत्रित करने में अपना समय बर्बाद करने और प्रयास करने का कोई मतलब नहीं है। इसके अलावा, इससे गलतियाँ होने का खतरा भी बढ़ जाता है। 

उपरोक्त सभी को सारांशित करते हुए, हम यह निष्कर्ष निकाल सकते हैं कि टेराफॉर्म और घोषणात्मक नोटेशन सर्वर प्रावधान के लिए अधिक उपयुक्त उपकरण हैं। लेकिन कॉन्फ़िगरेशन प्रबंधन का कार्य Ansible को सौंपना बेहतर है। इससे हटकर, आइए स्वचालन के संदर्भ में उपयोग के मामलों को देखें।

स्वचालन बुनियादी ढांचे के लिए मूल्य

यहां समझने वाली एकमात्र महत्वपूर्ण बात यह है कि परीक्षण स्वचालन बुनियादी ढांचे को संपूर्ण कंपनी बुनियादी ढांचे का हिस्सा माना जाना चाहिए। इसका मतलब यह है कि सभी IaC प्रथाओं को पूरे संगठन के संसाधनों पर विश्व स्तर पर लागू किया जाना चाहिए। इसके लिए कौन जिम्मेदार है यह आपकी प्रक्रियाओं पर निर्भर करता है। DevOps टीम इन मुद्दों में अधिक अनुभवी है, वे क्या हो रहा है इसकी पूरी तस्वीर देखते हैं। हालाँकि, QA इंजीनियर स्वचालन के निर्माण की प्रक्रिया और पाइपलाइन की संरचना में अधिक शामिल होते हैं, जो उन्हें सुधार के लिए सभी आवश्यक परिवर्तनों और अवसरों को बेहतर ढंग से देखने की अनुमति देता है। अपेक्षित परिणाम प्राप्त करने के लिए एक साथ काम करना, ज्ञान और विचारों का आदान-प्रदान करना सबसे अच्छा विकल्प है। 

परीक्षण स्वचालन और उन उपकरणों के संदर्भ में टेराफॉर्म और एन्सिबल का उपयोग करने के कुछ उदाहरण यहां दिए गए हैं जिनकी हमने पहले चर्चा की थी:

1. टेराफॉर्म का उपयोग करके वीएम और क्लस्टर की आवश्यक विशेषताओं और मापदंडों का वर्णन करें।

2. Ansible का उपयोग करके, परीक्षण के लिए आवश्यक उपकरण स्थापित करें: docker, Selenoid, Selenium Grid और ब्राउज़र/एमुलेटर के आवश्यक संस्करण डाउनलोड करें।

3. टेराफॉर्म का उपयोग करते हुए, उस वीएम की विशेषताओं का वर्णन करें जिसमें गिटलैब रनर लॉन्च किया जाएगा।

4. Ansible का उपयोग करके GitLab Runner और आवश्यक उपकरण स्थापित करें, सेटिंग्स और कॉन्फ़िगरेशन सेट करें।

बुनियादी ढांचे की वर्तमान स्थिति का चित्रण

अन्वेषण के लिए लिंक:

• terraform
• Ansible
• Ansible और टेराफ़ॉर्म एक साथ बेहतर हैं
• टेराफॉर्म के लिए एक व्यापक गाइड
• हम टेराफॉर्म का उपयोग क्यों करते हैं न कि शेफ, पपेट, एन्सिबल, साल्टस्टैक या क्लाउडफॉर्मेशन का
• जीसीपी: आईएसी

समान उपकरण

• महाराज
• कठपुतली
• SaltStack
• आवारा

आइए इसे संक्षेप में बताएं!

कदम
टेक्नोलॉजी
टूल्स
स्वचालन बुनियादी ढांचे के लिए मूल्य

1
स्थानीय चल रहा है
नोड.जेएस, सेलेनियम, एपियम

• वेब और मोबाइल के लिए सबसे लोकप्रिय उपकरण
• कई भाषाओं और प्लेटफार्मों का समर्थन करता है (Node.js सहित)

2
संस्करण नियंत्रण प्रणाली 
जाना

• विकास कोड के समान लाभ

3
कन्टेनरीकरण
डॉकर, सेलेनियम ग्रिड, सेलेनॉइड (वेब, एंड्रॉइड)

• समानांतर में परीक्षण चलाना
• पृथक वातावरण
• सरल, लचीला संस्करण उन्नयन
• अप्रयुक्त संसाधनों को गतिशील रूप से रोकना
• स्थापित करना आसान है

4
सीआई/सीडी
गिटलैब सीआई

• पाइपलाइन के भाग का परीक्षण
• त्वरित प्रतिक्रिया
• पूरी कंपनी/टीम के लिए दृश्यता

5
बादल मंच
Google Cloud Platform

• मांग पर संसाधन (हम केवल जरूरत पड़ने पर ही भुगतान करते हैं)
• प्रबंधन और अद्यतन करना आसान है
• सभी संसाधनों की दृश्यता और नियंत्रण

6
वाद्य-स्थान
Kubernetes
पॉड्स के अंदर ब्राउज़र/एमुलेटर वाले कंटेनरों के संदर्भ में:

• स्केलिंग/ऑटो स्केलिंग
• खुद से उपचार
• बिना किसी रुकावट के अपडेट और रोलबैक

7
एक कोड के रूप में इन्फ्रास्ट्रक्चर (IaC)
टेराफॉर्म, अन्सिबल

• विकास के बुनियादी ढांचे के साथ समान लाभ
• कोड संस्करणीकरण के सभी लाभ
• परिवर्तन करना और रखरखाव करना आसान है
• पूरी तरह से स्वचालित

माइंड मैप आरेख: बुनियादी ढांचे का विकास

चरण 1: स्थानीय

चरण 2: वीसीएस

चरण 3: कंटेनरीकरण 

चरण 4: सीआई/सीडी 

चरण 5: क्लाउड प्लेटफ़ॉर्म

चरण 6: आर्केस्ट्रा

चरण 7: IaC

आगे क्या है?

तो, यह लेख का अंत है। लेकिन अंत में, मैं आपके साथ कुछ समझौते स्थापित करना चाहूंगा।

आपके यहाँ से
जैसा कि मैंने शुरुआत में कहा था, मैं चाहूंगा कि लेख व्यावहारिक उपयोग का हो और आपको प्राप्त ज्ञान को वास्तविक कार्य में लागू करने में मदद मिले। मैं फिर से जोड़ता हूं व्यावहारिक मार्गदर्शिका से लिंक करें.

लेकिन उसके बाद भी, रुकें नहीं, अभ्यास करें, प्रासंगिक लिंक और पुस्तकों का अध्ययन करें, पता लगाएं कि यह आपकी कंपनी में कैसे काम करता है, उन स्थानों को ढूंढें जहां सुधार किया जा सकता है और इसमें भाग लें। आपको कामयाबी मिले!

मेरी तरफ से

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

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

और अंत में। भविष्य में, मैं परीक्षण बुनियादी ढांचे और लोकप्रिय उपकरणों के निर्माण पर एक वीडियो पाठ्यक्रम जारी करने की योजना बना रहा हूं। वर्तमान में, इंटरनेट पर DevOps पर काफी कुछ पाठ्यक्रम और व्याख्यान हैं, लेकिन सभी सामग्रियां विकास के संदर्भ में प्रस्तुत की जाती हैं, परीक्षण स्वचालन के लिए नहीं। इस मुद्दे पर, मुझे वास्तव में इस पर प्रतिक्रिया की आवश्यकता है कि क्या ऐसा पाठ्यक्रम परीक्षकों और स्वचालन इंजीनियरों के समुदाय के लिए दिलचस्प और मूल्यवान होगा। आपका अग्रिम में ही बहुत धन्यवाद!

स्रोत: www.habr.com