लिखित DevOps प्रशिक्षण

प्रोडक्शन में कम जोखिम के साथ DevOps कोड कैसे डिप्लॉय करें?

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

आपकी DevOps टीम में नियंत्रण और जोखिम कम करने के उपाय शामिल हैं

आम IT संगठन में डेवलपमेंट टीम सॉफ़्टवेयर बनाती और ऑपरेशंस टीम डिप्लॉय करती है। DevOps में आपकी अपनी सक्षम और आत्मनिर्भर टीम नियंत्रण और जोखिम कम करने की ज़िम्मेदारी लेती है। वह अपने भीतर ऑटोमेटेड डिप्लॉयमेंट और सहकर्मी समीक्षा पर निर्भर रहती है।

प्रोडक्शन और अन्य परिवेश टीम के बनाए सॉफ़्टवेयर जितने ही महत्वपूर्ण हैं। इसलिए टीम तीन अहम सिद्धांत अपनाती है:

1. ऑपरेटिंग सिस्टम, कंपोनेंट, इंटरफ़ेस, पैच स्तर, बाकी निर्भरताओं और अपने सॉफ़्टवेयर व कॉन्फ़िगरेशन में सभी परिवेश एक जैसे रखें।
2. परिवेश की एकरूपता बिगाड़ने वाली बाधा ठीक करना पहली प्राथमिकता है।
3. सभी परिवेशों में एक ही डिप्लॉयमेंट तकनीक अपनाएँ, ताकि प्रोडक्शन डिप्लॉयमेंट का पूर्वाभ्यास रोज़ का काम बने।

डिप्लॉयमेंट की अपनी सेल्फ़-सर्विस प्रणाली

ऑटोमेटेड सेल्फ़-सर्विस डिप्लॉयमेंट का क्रम इस तरह है।

1. कोड लिखें और ट्रंक में चेक इन करें।
2. डिप्लॉय किए जा सकने वाले पैकेज बनाएँ।
3. पैकेज, निर्भरता और कॉन्फ़िगरेशन की तैयारी जाँचें।
4. परिवेश की तैयारी की पुष्टि करें।
5. ऑटोमेटेड टेस्ट चलाएँ।
6. ऑडिट और अनुपालन के लिए सभी जाँच और टेस्ट के नतीजे दर्ज करें।
7. लक्ष्य परिवेश में पैकेज डिप्लॉय करें।
8. डिप्लॉयमेंट की पुष्टि के लिए लक्ष्य परिवेश में ऑटोमेटेड टेस्ट चलाएँ।
9. लक्ष्य परिवेश के सिस्टम, प्रदर्शन और गतिविधि मेट्रिक्स की निगरानी करें।
10. तेज़ फ़ीडबैक दें और कुछ गलत हो तो डिप्लॉयमेंट ठीक करें या रोलबैक करें।

आपके डिप्लॉयमेंट और रिलीज़ अलग हैं

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

ब्लू-ग्रीन डिप्लॉयमेंट पैटर्न

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

कैनरी डिप्लॉयमेंट पैटर्न
(जिसे डार्क लॉन्च भी कहते हैं)

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

इसी से प्रेरित कैनरी डिप्लॉयमेंट में रिलीज़ पहले कुछ उपयोगकर्ताओं या सर्वरों तक जाती है। बदलाव पहले कुछ सर्वरों पर डिप्लॉय करके टेस्ट करें, फिर बाकी सर्वरों पर भेजें। इससे कम डाउनटाइम के साथ जल्दी चेतावनी मिलती है। कैनरी डिप्लॉयमेंट विफल हो जाए, तो बाकी सर्वर प्रभावित नहीं होते।

Facebook, Google और कई बड़ी तकनीकी कंपनियाँ «डार्क लॉन्च» नाम का कैनरी तरीका इस्तेमाल करती हैं। नए फ़ीचर सबको देने से पहले छोटे समूह में धीरे-धीरे रिलीज़ और टेस्ट होते हैं। इससे पता चलता है कि लोगों को फ़ीचर पसंद है या नहीं और प्रदर्शन पर क्या असर होता है। Facebook अपने डार्क लॉन्च टूल को «Gatekeeper» कहता है, क्योंकि वह नए फ़ीचर तक उपयोगकर्ताओं की पहुँच नियंत्रित करता है।

इसे डार्क लॉन्च कहते हैं क्योंकि फ़ीचर की घोषणा नहीं होती। वह चुपचाप पहले 1%, फिर 5%, फिर 30% उपयोगकर्ताओं तक जाता है। कभी फ़ीचर कुछ दिन दिखकर फिर गायब हो जाता है। शायद उसने अच्छा काम नहीं किया या कंपनी डेवलपमेंट को दिशा देने के लिए शुरुआती फ़ीडबैक ही चाहती थी।

क्लस्टर इम्यून सिस्टम रिलीज़ पैटर्न

यह कैनरी डिप्लॉयमेंट का विस्तार है। इसमें प्रदर्शन और सॉफ़्टवेयर गतिविधि की निगरानी रिलीज़ प्रक्रिया के साथ गहराई से जुड़ी होनी चाहिए।

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

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

• टेस्ट ऑटोमेशन से छूट जाने वाली समस्याओं के खिलाफ़ अतिरिक्त सुरक्षा।
• प्रोडक्शन समस्याओं पर तेज़ फ़ीडबैक और ऑटोमेटेड रोलबैक।

फ़ीचर टॉगल

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

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

सर्विस-ओरिएंटेड आर्किटेक्चर में टीमें सेवाओं के अलग-अलग वर्शन बिना चालू किए डिप्लॉय कर सकती हैं। नए फ़ीचर या सेवा प्रवाह के लिए सभी वर्शन डिप्लॉय होने पर उनके टॉगल चालू करके नया प्रवाह शुरू करें।

सुरक्षित रिलीज़ के लिए आर्किटेक्चर बनाएँ

हर आकार के हर उत्पाद और सेवा के लिए कोई एक आदर्श आर्किटेक्चर नहीं है।

स्टार्टअप में पहला IT प्लैटफ़ॉर्म बनाने के लिए मोनोलिथिक आर्किटेक्चर अक्सर पहला चुनाव है, ताकि तेज़ और कम खर्च में बाज़ार में उतरकर बिज़नेस केस जाँचें। समस्या है कि मुख्य और सहायक फ़ंक्शन, यूज़र और सिस्टम इंटरफ़ेस तथा इंटीग्रेशन अलग कंपोनेंट होने की जगह आपस में उलझे रहते हैं। Amazon, Google, Facebook और Ebay जैसे कई बड़े संगठनों को तेज़ स्केलिंग और ग्राहकों के लिए कम जोखिम वाली रिलीज़ और फ़ीचर विस्तार के लिए मोनोलिथिक आर्किटेक्चर छोड़ना पड़ा। उन्होंने स्ट्रैंगलर ऐप्लिकेशन पैटर्न के साथ सेवा या माइक्रोसर्विस-केंद्रित आर्किटेक्चर अपनाया।

माइक्रोसर्विस में कम जोखिम वाले माइग्रेशन के लिए स्ट्रैंगलर ऐप्लिकेशन पैटर्न

जटिल सिस्टम पूरी तरह बदलना बहुत बड़ा काम हो सकता है। पुराने सिस्टम को बाकी फ़ीचर के लिए चलाते हुए अक्सर नए सिस्टम में धीरे-धीरे जाना पड़ता है। लेकिन दो वर्शन चलने पर क्लाइंट को पता होना चाहिए कि फ़ीचर कहाँ हैं। फ़ीचर या सेवा माइग्रेट हो तो क्लाइंट का पता भी बदलना पड़ता है।

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

Ebay उन शुरुआती संगठनों में था जिन्होंने इस पैटर्न से पुराने मोनोलिथ को माइक्रोसर्विस में बदला। उसने ऐप्लिकेशन को अपने इकोसिस्टम के स्पष्ट यूनिवर्सल API के पीछे रखा, ताकि सारा पुराना कोड एक बार में न लिखना पड़े। उसने 6 से 10 इंजीनियरों की छोटी टीमें बनाईं। अब 10 लोगों तक की एक टीम नीलामी प्लैटफ़ॉर्म का यूनिवर्सल API सँभाल सकती है, जो दुनिया में सबसे ज़्यादा इस्तेमाल होने वाला नीलामी API है।

निष्कर्ष

ज़्यादातर IT विभागों में टीमों को भविष्य के लिए तैयार, स्केलेबल और सुरक्षित डिप्लॉयमेंट पैटर्न और आर्किटेक्चर बनाने की ज़िम्मेदारी नहीं दी जाती। फिर भी तेज़ और सुरक्षित डिप्लॉयमेंट वाले आर्किटेक्चर और फ़ीचर बनाना DevOps की सफलता की मुख्य शर्त है।

जब टीमें रोज़ तेज़ और कम जोखिम वाले डिप्लॉयमेंट कर सकती हैं, तभी वे निरंतर डिप्लॉयमेंट और सुचारु रिलीज़ के लाभ पाती हैं।