🗄️ 🚟 👨‍👨‍👦 छह महीने में या उससे भी तेजी से देवओप्स इंजीनियर कैसे बनें। भाग 5. परिनियोजन 🌬️ 👩‍🎤 💞

छह महीने में या उससे भी तेजी से DevOps इंजीनियर कैसे बनें। भाग 1. परिचय
छह महीने या उससे भी अधिक तेजी से एक DevOps इंजीनियर बनने के लिए। भाग 2. विन्यास
छह महीने में या उससे भी अधिक तेजी से एक DevOps इंजीनियर बनने के लिए। भाग 3. संस्करण
छह महीने या उससे भी अधिक तेजी से एक DevOps इंजीनियर बनने के लिए। भाग 4. सॉफ्टवेयर पैकेजिंग

स्मृति को ताज़ा करें

ऊपर दी गई छवि से पता चलता है कि एक विशिष्ट कोड परिनियोजन कैसा दिखना चाहिए। मुझे याद दिलाएं कि अब हम रोडमैप के अनुसार कहां हैं:

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

कोड परिनियोजन

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

इन अंतरों को कम से कम करना सबसे अच्छी बात है जो आप न केवल तैनाती प्रक्रिया के दौरान कर सकते हैं, बल्कि तैनाती के बाद इसके निष्पादन के दौरान भी कर सकते हैं। तो, हम अपने ठेस और गैर-ठेस वातावरण के बीच अंतर को कैसे कम और / या खत्म करते हैं?

और यह मेरी कार पर काम करता है!

यदि आपका देव अवसंरचना ऐसा दिखता है:

और ठेस अवसंरचना इस तरह दिखती है :

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

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

यह सब मानते हुए, मैं यह स्वीकार करने की स्वतंत्रता लूंगा कि कोड को तैनात करने का सबसे अच्छा तरीका यह है कि इसे बिल्कुल भी लागू न किया जाए।

आधुनिक तैनाती का दृष्टिकोण

यह सच है कि मशीनों पर कोड की तैनाती 1990 के दशक की एक प्रतिध्वनि है। उत्पादन मशीनों के एक सेट में कोड को तैनात करते समय सबसे बड़ी समस्या यह है कि, परिभाषा के अनुसार, आपके ठेस सर्वर (जिस पर कोड निष्पादित होता है) आपके देव सर्वर (जहां यह कोड लिखा गया है) से अलग हैं। यह आश्चर्य की बात नहीं है कि तैनाती के तुरंत बाद बहुत सारी समस्याएं हैं जो पहले कभी नहीं देखी गईं, क्योंकि अब स्थितियां बदल गई हैं!

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

इसे "अपरिवर्तनीय परिनियोजन" कहा जाता है और यह एक बहुत शक्तिशाली टेम्पलेट है जो आपको परिनियोजन के बाद कई घंटों के सिरदर्द से बचाएगा। बेशक, यदि आप कंटेनर चलाते हैं, तो एक ही विचार लागू होता है: आप हर जगह एक ही कंटेनर को तैनात करते हैं। आप कह सकते हैं: “रुक जाओ! मेरी ठेस देव से अलग है! ”और यह सही है, क्योंकि डेटाबेस उपयोगकर्ता नाम / पासवर्ड, कनेक्शन तार, S3 डंपस्टर स्थान सभी अलग-अलग चीजें हैं! हां, वे बहुत अलग चीजें हैं।

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

उदाहरण के लिए, यदि आप एडब्ल्यूएस में हैं, तो एसएसएम को मापदंडों के बाहरी भंडार के रूप में उपयोग करें - यह क्लाउडफार्मेशन के साथ पूरी तरह से एकीकृत होता है। AWS ssm cli कमांड से सीधे पर्यावरण चर सेट करना भी बहुत आसान है। बेशक, अन्य क्लाउड प्रदाताओं में समान तंत्र होते हैं।

इसके अलावा, कुछ गलत होने पर अपनी ठेस मशीनों को "ठीक" करने के आग्रह का विरोध करें। मशीनें अपरिवर्तनीय होनी चाहिए, जिसका अर्थ है कि आपके द्वारा किए गए सभी सुधार देव से आने चाहिए। आपका लक्ष्य ठेस मशीनों तक पहुंच को रोकना होना चाहिए। न तो एसएसएच, न ही एससीपी, न ही ठेस पहुंच - कभी किसी को नहीं, खुद को नहीं, न ही हैकर्स को नौसिखिया बनाने के लिए।

लेकिन क्या होगा अगर मुझे समस्या को ठीक करने के लिए लॉग की आवश्यकता है? आपने यह अनुमान लगाया - आपकी पत्रिकाओं को भी बाहरी रूप दिया जाना चाहिए, आदर्श रूप से किसी अन्य स्थान पर भेजा गया, या तो ElasticSearch / Logstash / Kibana (ELK) स्टैक का उपयोग करते हुए, या SumoLogic या Datadog जैसे व्यावसायिक सॉफ़्टवेयर का उपयोग करके।

जो कुछ भी आप करते हैं, आपकी ठेस मशीनें एक "काम करने वाले मवेशी" हैं जो कि बीमार स्वास्थ्य के मामूली संकेत पर प्रतिस्थापित हैं। वे "पालतू जानवर" नहीं हैं जिनकी देखभाल के लिए घंटों की समस्या निवारण के लिए ठीक होने की आवश्यकता है।

मुझे पता है कि इस सादृश्य का उपयोग अक्सर किया जाता है, और मैं ऐसे लोगों से सुनता हूं जो वास्तव में मवेशियों की परवाह करते हैं कि यह पूरी तरह से सच नहीं है, लेकिन सार एक ही है - अपने ठेस मशीनों को "मरम्मत" न करें, बस अपने विकास को ठीक करें और इसे फिर से परिभाषित करें ।

कोड तैनाती यांत्रिकी

तो, आप जानते हैं कि क्या करना है, लेकिन आप नहीं जानते कि कैसे। दुर्भाग्य से, यह वह जगह है जहां जेनकिंस प्रकट होता है। यदि आप नहीं जानते हैं, तो जेनकिंस सबसे लोकप्रिय ओपन सोर्स परिनियोजन ऑटोमेशन सर्वरों में से एक है।

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

मैं आपको जेनकींस से शुरू करने की सलाह क्यों देता हूं? क्योंकि, अपनी सभी कमियों के बावजूद, यह अभी भी आईटी क्षेत्र में बेहद लोकप्रिय और व्यापक रूप से उपयोग किया जाता है। जेनकिंस को जानना, विशेष रूप से जेनकिंसफाइल कैसे संरचित है , नौकरी की संभावनाओं के लिए एक बड़ा लाभ है और इसे नजरअंदाज नहीं किया जा सकता है। जेनकिंस की खोज करते समय, सुनिश्चित करें कि आप नई पाइपलाइन ब्लूऑन प्लगइन पर ले जाएं , न कि अप्रचलित जेनकींस जॉब पाइपलाइन पर। यह महत्वपूर्ण है यदि आप अपने CI / CD पाइपलाइन को अपने GitHub / GitLab रेपो कोड के ठीक अंदर रहना चाहते हैं। इस प्रकार, पाइपलाइन स्वयं एक कोडित संस्करण है!

वास्तव में, यह इतना महत्वपूर्ण है कि यह फिर से दोहराने के लायक है: सब कुछ कोड है! आपका आवेदन, यह कैसे तैनात किया जाता है, इसे कैसे ट्रैक किया जाता है, इसे कैसे कॉन्फ़िगर किया जाता है, इत्यादि सभी उचित संस्करण वाले कोड स्निपेट हैं जिन्हें GitHub / GitLab / Anywhere में संग्रहीत किया गया है। इसका लक्ष्य मुख्य डेवलपर्स (सॉफ्टवेयर इंजीनियर जो कार्यात्मक कोड लिखते हैं) के लिए विसंगतियों से मुक्त वातावरण बनाना है।

उदाहरण के लिए, मुझे इसमें सक्षम होना चाहिए:

अपने खुद के छोटे microservice लिखें;
कोई भी परीक्षण जोड़ें जिसे मैं आवश्यक मानता हूं;
जेनकिंसफाइल जोड़ें
मॉनिटरिंग-अस-कोड कॉन्फ़िगरेशन जोड़ें;
env.yaml फ़ाइल में मेरे पैरामीटर निर्दिष्ट करें;
एक भंडार में यह सब बचाओ;
Jenkins स्वचालित रूप से निर्दिष्ट रिपॉजिटरी का पता लगाएं;
अपने माइक्रोसेवा का निर्माण करें;
झसे आज़माओ;
विस्तार करें (कैनरी या ब्लू-ग्रीन विधि का उपयोग करके);
ऐसा होने पर अपने ई-मेल पर एक संदेश भेजने की व्यवस्था करें!

यह लक्ष्य है, जिसकी उपलब्धि DevOps इंजीनियरों के मुख्य मिशन का सार है।

जेनकिंस के लिए विकल्प

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

दूसरा विकल्प GitLab CI का निरंतर एकीकरण मॉड्यूल है। यदि आपका संगठन GitLab चला रहा है, तो आपको संभवतः इसके साथ काम करना शुरू कर देना चाहिए, क्योंकि यह बहुत करीने से GitLab के साथ एकीकृत है।

अंत में, GitHub की तैनाती के लिए अपने स्वयं के उपकरण की घोषणा की है क्रिया अनुप्रयोगों जो अपने ही स्वचालन द्वारा समर्थित है।

वास्तव में, मुझे नहीं लगता कि उपकरण यहां बहुत महत्वपूर्ण हैं। यह जानना महत्वपूर्ण है कि कोड परिनियोजन पाइपलाइनों सहित सब कुछ, संस्करणित कलाकृतियाँ हैं, और जब तक यह देव से नहीं आती है तब तक कुछ भी नहीं जाता है।

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

बहुत जल्द जारी रखने के लिए ...

विज्ञापन का एक सा :)

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक ऑर्डर देकर या $ 4.99 से डेवलपर्स के लिए अपने दोस्तों के क्लाउड-आधारित VPS की अनुशंसा करके हमें समर्थन दें, आपके द्वारा आविष्कार किया गया एंट्री-लेवल सर्वर का एक अनूठा एनालॉग: VPS (KVM) E5-2697 3 (6 करोड़) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $ 19 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता है? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?

छह महीने में या उससे भी तेजी से देवओप्स इंजीनियर कैसे बनें। भाग 5. परिनियोजन