शुरुआती मार्गदर्शिका: एक DevOps पाइपलाइन बनाना

यदि आप DevOps में नए हैं, तो अपनी पहली पाइपलाइन बनाने के लिए इस पाँच-चरणीय मार्गदर्शिका पर एक नज़र डालें।

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

मेरी डेवऑप्स यात्रा

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

पुस्तक के पीछे की तालिका दर्शाती है कि विभिन्न कंपनियाँ कितनी बार अपने सिस्टम को रिलीज़ परिवेश में तैनात करती हैं:

अमेज़न: 23 प्रति दिन
गूगल: 5 प्रति दिन
नेटफ्लिक्स: 500 प्रति दिन
फेसबुक: दिन में एक बार
ट्विटर: सप्ताह में 3 बार
विशिष्ट कंपनी: हर 9 महीने में एक बार

Amazon, Google और Netflix की फ़्रीक्वेंसी कैसे संभव है? ऐसा इसलिए है क्योंकि इन कंपनियों ने यह पता लगा लिया है कि लगभग संपूर्ण DevOps पाइपलाइन कैसे बनाई जाए।

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

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

अब मुझे समझ में आया कि हमारी DevOps पाइपलाइन कितनी सरल थी: हमने जेनकिंस फ़ाइलें या Ansible जैसे एक्सटेंशन का उपयोग नहीं किया। हालाँकि, इस सरल पाइपलाइन ने अच्छा काम किया, शायद पेरेटो सिद्धांत (जिसे 80/20 नियम के रूप में भी जाना जाता है) के कारण।

DevOps और CI/CD पाइपलाइन का संक्षिप्त परिचय

यदि आप कई लोगों से पूछते हैं, "DevOps क्या है?", तो आपको संभवतः कई अलग-अलग उत्तर मिलेंगे। DevOps, Agile की तरह, कई अलग-अलग विषयों में विकसित हुआ है, लेकिन अधिकांश लोग कुछ बातों पर सहमत होंगे: DevOps एक सॉफ्टवेयर विकास अभ्यास या सॉफ्टवेयर विकास जीवन चक्र (SDLC) है जिसका केंद्रीय सिद्धांत उस संस्कृति को बदलना है जिसमें डेवलपर्स और गैर- डेवलपर्स ऐसे वातावरण में मौजूद हैं जिसमें:

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

हालाँकि DevOps वातावरण बनाने के लिए केवल सही सॉफ़्टवेयर टूल का होना ही आवश्यक नहीं है, कुछ टूल भी आवश्यक हैं। एक प्रमुख उपकरण निरंतर एकीकरण और निरंतर तैनाती (सीआई/सीडी) है। इस पाइपलाइन में, वातावरण के विभिन्न चरण होते हैं (उदाहरण के लिए DEV, INT, TST, QA, UAT, STG, PROD), कई ऑपरेशन स्वचालित होते हैं, और डेवलपर्स उच्च गुणवत्ता वाले कोड लिख सकते हैं, विकास चपलता और उच्च तैनाती दर प्राप्त कर सकते हैं।

यह आलेख एक DevOps पाइपलाइन बनाने के लिए पांच-चरणीय दृष्टिकोण का वर्णन करता है जैसा कि ओपन सोर्स टूल का उपयोग करके निम्नलिखित चित्र में दिखाया गया है।

चरण 1: सीआई/सीडी विधियाँ

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

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

जेनकिंस कई ओपन सोर्स सीआई/सीडी टूल्स में से एक है जिसका उपयोग आप अपनी DevOps पाइपलाइन बनाने के लिए कर सकते हैं।

जेनकिंस: क्रिएटिव कॉमन्स और एमआईटी
ट्रैविस सीआई: एमआईटी
क्रूज़कंट्रोल:बीएसडी
बिल्डबॉट: जीपीएल
अपाचे गंप: अपाचे 2.0
कैबी: जीएनयू

यहां बताया गया है कि CI/CD टूल के साथ DevOps प्रक्रियाएं कैसी दिखती हैं:

आपके लोकलहोस्ट पर एक सीआई/सीडी टूल चल रहा है, लेकिन इस समय आप बहुत कुछ नहीं कर सकते हैं। आइए DevOps यात्रा के अगले चरण पर आगे बढ़ें।

चरण 2: स्रोत नियंत्रण प्रणाली प्रबंधित करें

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

यहीं पर स्रोत कोड नियंत्रण लगभग एक आवश्यकता बन जाता है। यह टूल आपके कोड को रिपॉजिटरी में संग्रहीत करता है, संस्करणों का ट्रैक रखता है, और प्रोजेक्ट प्रतिभागियों के काम का समन्वय करता है।

हालाँकि वहाँ कई स्रोत नियंत्रण उपकरण हैं, Git मानक है, और यह सही भी है। मैं Git का उपयोग करने की अत्यधिक अनुशंसा करता हूं, हालांकि यदि आप चाहें तो अन्य ओपन सोर्स विकल्प भी हैं।

Git: GPLv2 और LGPL v2.1
तोड़फोड़: अपाचे 2.0
समवर्ती संस्करण प्रणाली (सीवीएस): जीएनयू
वेस्टा: एलजीपीएल
मर्क्यूरियल: जीएनयू जीपीएल वी2+

स्रोत कोड नियंत्रणों को जोड़ने के साथ DevOps पाइपलाइन इस तरह दिखती है।

एक सीआई/सीडी उपकरण समीक्षा, स्रोत कोड अधिग्रहण और सदस्यों के बीच सहयोग की प्रक्रियाओं को स्वचालित कर सकता है। इतना खराब भी नहीं? लेकिन आप इसे एक कार्यशील एप्लिकेशन में कैसे बदल सकते हैं ताकि अरबों लोग इसका उपयोग कर सकें और इसकी सराहना कर सकें?

चरण 3: एक बिल्ड ऑटोमेशन टूल बनाएं

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

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

नाम
लाइसेंस
प्रोग्रामिंग भाषा

Maven
अपाचे 2.0
जावा

चींटी
अपाचे 2.0
जावा

Gradle
अपाचे 2.0
जावा

Bazel
अपाचे 2.0
जावा

बनाना
जीएनयू
एन / ए

असंतोष का शब्द
एमआईटी
जावास्क्रिप्ट

घूंट
एमआईटी
जावास्क्रिप्ट

बिल्डर
अपाचे
माणिक

जेली
एमआईटी
माणिक

एएपी
जीएनयू
अजगर

स्कैन
एमआईटी
अजगर

बिटबेक
GPLv2
अजगर

केक
एमआईटी
C#

एएसडीएफ
प्रवासी (एमआईटी)
लिस्प

साज़िश
बीएसडी
हास्केल

महान! आप बिल्ड ऑटोमेशन टूल कॉन्फ़िगरेशन फ़ाइलों को अपने स्रोत नियंत्रण सिस्टम में डाल सकते हैं और अपने सीआई/सीडी टूल को सब कुछ एक साथ रखने दे सकते हैं।

सब ठीक तो है ना? लेकिन अपना एप्लिकेशन कहां तैनात करें?

चरण 4: वेब एप्लिकेशन सर्वर

अभी के लिए, आपके पास एक पैकेज्ड फ़ाइल है जो निष्पादन योग्य या इंस्टॉल करने योग्य हो सकती है। किसी भी एप्लिकेशन के वास्तव में उपयोगी होने के लिए, उसे किसी प्रकार की सेवा या इंटरफ़ेस प्रदान करना होगा, लेकिन आपको अपने एप्लिकेशन को होस्ट करने के लिए एक कंटेनर की आवश्यकता होती है।

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

कई ओपन सोर्स वेब एप्लिकेशन सर्वर हैं।

नाम
लाइसेंस
प्रोग्रामिंग भाषा

बिल्ला
अपाचे 2.0
जावा

घाट
अपाचे 2.0
जावा

जंगली मक्खी
जीएनयू लेसर पब्लिक
जावा

कांच की मछली
सीडीडीएल और जीएनयू कम सार्वजनिक
जावा

Django
3-खंड बीएसडी
अजगर

बवंडर
अपाचे 2.0
अजगर

अंगरखा
एमआईटी
अजगर

अजगर
एमआईटी
अजगर

रेल
एमआईटी
माणिक

Node.js
एमआईटी
जावास्क्रिप्ट

आपकी DevOps पाइपलाइन उपयोग के लिए लगभग तैयार है। अच्छा काम!

हालाँकि आप वहां रुक सकते हैं और एकीकरण को स्वयं संभाल सकते हैं, लेकिन किसी ऐप डेवलपर के लिए चिंता करने के लिए कोड गुणवत्ता एक महत्वपूर्ण चीज़ है।

चरण 5: कोड परीक्षण कवरेज

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

कोड परीक्षण में दो भाग होते हैं: कोड परीक्षण ढाँचे जो आपको परीक्षण लिखने और चलाने में मदद करते हैं, और सुझाव उपकरण जो आपके कोड की गुणवत्ता में सुधार करने में आपकी सहायता करते हैं।

कोड परीक्षण प्रणाली

नाम
लाइसेंस
प्रोग्रामिंग भाषा

JUnit
एक्लिप्स पब्लिक लाइसेंस
जावा

ईज़ीमॉक
अपाचे
जावा

मॉकिटो
एमआईटी
जावा

पॉवरमॉक
अपाचे 2.0
जावा

पाइस्टेस्ट
एमआईटी
अजगर

परिकल्पना
मोज़िला
अजगर

विष
एमआईटी
अजगर

कोड सुधार के लिए अनुशंसा प्रणाली

नाम
लाइसेंस
प्रोग्रामिंग भाषा

व्याप्ति
जीएनयू
जावा

कोडकवर
एक्लिप्स पब्लिक (ईपीएल)
जावा

कवरेज.पी.ई
अपाचे 2.0
अजगर

एमा
सामान्य सार्वजनिक लाइसेंस
जावा

जाकोको
एक्लिप्स पब्लिक लाइसेंस
जावा

परिकल्पना
मोज़िला
अजगर

विष
एमआईटी
अजगर

चमेली
एमआईटी
जावास्क्रिप्ट

कर्मा
एमआईटी
जावास्क्रिप्ट

कहवा
एमआईटी
जावास्क्रिप्ट

है
एमआईटी
जावास्क्रिप्ट

ध्यान दें कि ऊपर उल्लिखित अधिकांश टूल और फ्रेमवर्क जावा, पायथन और जावास्क्रिप्ट के लिए लिखे गए हैं, क्योंकि C++ और C# मालिकाना प्रोग्रामिंग भाषाएं हैं (हालाँकि GCC खुला स्रोत है)।

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

अतिरिक्त कदम

कंटेनर

जैसा कि मैंने कहा, आप अपने सर्वर को वर्चुअल मशीन या सर्वर पर होस्ट कर सकते हैं, लेकिन कंटेनर एक लोकप्रिय समाधान है।

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

जबकि अन्य कंटेनर विकल्प हैं, सबसे लोकप्रिय डॉकर और कुबेरनेट्स हैं।

डॉकर: अपाचे 2.0
कुबेरनेट्स: अपाचे 2.0

मध्यवर्ती स्वचालन उपकरण

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

यहां कुछ ओपन सोर्स मिडलवेयर ऑटोमेशन टूल दिए गए हैं:

उत्तर देने योग्य: जीएनयू पब्लिक
साल्टस्टैक: अपाचे 2.0
शेफ: अपाचे 2.0
कठपुतली: अपाचे या जीपीएल

स्किलफैक्ट्री से भुगतान किए गए ऑनलाइन पाठ्यक्रम लेकर कौशल और वेतन के मामले में शुरू से या लेवल अप के बाद एक पसंदीदा पेशा कैसे प्राप्त करें, इसके बारे में विवरण प्राप्त करें:

• डेवऑप्स कोर्स (12 महीने)

अधिक पाठ्यक्रम

• मशीन लर्निंग कोर्स (12 सप्ताह)
• स्क्रैच से डेटा साइंस के पेशे को पढ़ाना (12 महीने)
• किसी भी शुरुआती स्तर पर विश्लेषक का पेशा (9 महीने)
• वेब डेवलपमेंट कोर्स के लिए पायथन (9 महीने)

उपयोगी

• 450 निःशुल्क आइवी लीग पाठ्यक्रम
• डेटा साइंस 2020 में रुझान
• डेटा साइंस मर चुका है. बिजनेस साइंस जिंदाबाद
• स्टेरॉयड पर डेटा साइंस: निर्णय इंटेलिजेंस का एक परिचय
• सबसे सफल और सबसे निंदनीय डेटा साइंस प्रोजेक्ट: कैम्ब्रिज एनालिटिका

स्रोत: www.habr.com