8.2 इन्फ्रास्ट्रक्चर ऐज़ कोड और कॉन्फ़िगरेशन

अवलोकन और प्रेरणा

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

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

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

मुख्य सिद्धांत

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

सिफ़ारिशें

डिक्लेरेटिव टूलिंग चुनें और इसे मॉड्यूल के इर्द-गिर्द संरचित करें

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

स्थिति को जानबूझकर प्रबंधित करें

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

गोल्डन इमेज के साथ अपरिवर्तनीय इन्फ्रास्ट्रक्चर बनाएँ

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

कॉन्फ़िगरेशन बहाव को पहचानें और सुलझाएँ

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

GitOps और पुल-आधारित डिप्लॉयमेंट अपनाएँ

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

पॉलिसी ऐज़ कोड के साथ गार्डरेल लागू करें

अनुमत क्षेत्र, अनिवार्य एन्क्रिप्शन, आवश्यक टैग, और निषिद्ध सार्वजनिक एक्सपोज़र जैसे संगठनात्मक नियमों को Open Policy Agent (OPA) जैसे टूल या Sentinel जैसे प्लेटफ़ॉर्म-नेटिव पॉलिसी इंजन का इस्तेमाल करके मशीन-जाँचने योग्य नीतियों के रूप में व्यक्त करें। इन जाँचों को प्रोविज़निंग से पहले पाइपलाइन में चलाएँ, ताकि उल्लंघनों को स्वचालित रूप से रोका जाए। पॉलिसी ऐज़ कोड एक सुरक्षा टीम के इरादे को एक निष्पादन योग्य, समान रूप से लागू नियंत्रण में बदल देता है, और यह हज़ारों बदलावों तक इस तरह पैमाना पाता है जैसे मैन्युअल समीक्षा कभी नहीं कर सकती।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

विकल्प	फ़ायदे	नुकसान	सबसे अच्छा फ़िट
डिक्लेरेटिव IaC (Terraform/Pulumi)	पुनरुत्पादनीय, समीक्षा योग्य, बहाव-पहचान योग्य	सीखने की अवस्था; स्टेट प्रबंधन जटिलता	पैमाने पर लगभग सभी टीमें
इम्पेरेटिव स्क्रिप्ट	परिचित; एक-बारगी कामों के लिए लचीली	आइडेम्पोटेंट नहीं; ऑडिट और दोहराना कठिन	संकीर्ण, संक्रमणकालीन मामले
अपरिवर्तनीय + गोल्डन इमेज	कोई बहाव नहीं; मामूली रोलबैक	इमेज बिल्ड पाइपलाइन का बोझ	संगति चाहने वाले फ्लीट
परिवर्तनीय कॉन्फ़िग प्रबंधन	सूक्ष्म-स्तरीय निरंतर नियंत्रण	बहाव जोखिम; धीमी अभिसरण	लेगेसी या दीर्घकालिक होस्ट
GitOps (पुल-आधारित)	मज़बूत ऑडिट ट्रेल; स्व-उपचार	इन-क्लस्टर एजेंट और Git अनुशासन चाहिए	Kubernetes और क्लाउड-नेटिव
पॉलिसी ऐज़ कोड	स्वचालित, समान गार्डरेल	अग्रिम नीति लेखन प्रयास	विनियमित वातावरण

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

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

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

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

5. जब एक वास्तविक आपातकाल एक मैन्युअल बदलाव की माँग करता है, तो अनुमोदित ब्रेक-ग्लास पथ क्या है, और वह बदलाव कोड में वापस कैसे मुड़ता है? हर परिपक्व IaC अभ्यास अंततः उस रात 3 बजे की घटना से मिलता है जहाँ एक पाइपलाइन की प्रतीक्षा करना स्वीकार्य नहीं है, और ईमानदार सवाल यह नहीं है कि क्या मैन्युअल बदलाव कभी होते हैं बल्कि यह है कि आप उन्हें कैसे नियंत्रित करते हैं। पहले से तय करें कि पाइपलाइन को कौन बाईपास कर सकता है, उन्हें क्या छूने की अनुमति है, कार्रवाई को कैसे लॉग किया जाता है, और वह समयसीमा जिसके भीतर बदलाव को कोड में सुलझाया जाना चाहिए या वापस लिया जाना चाहिए। इस सहमति के बिना, आपातकालीन अपवाद चुपचाप रोज़मर्रा की आदत बन जाता है और ClickOps पिछले दरवाज़े से लौट आता है। प्रमाण लाएँ: पिछली तिमाही में कितने आउट-ऑफ़-बैंड बदलाव हुए, हर एक कितनी देर तक असुलझा रहा, और क्या बहाव पहचान ने वास्तव में उन्हें पकड़ा। विनियमित और सार्वजनिक निकायों के लिए, स्वचालित लॉगिंग के साथ एक दस्तावेज़ीकृत ब्रेक-ग्लास प्रक्रिया अक्सर एक नियंत्रण आवश्यकता होती है, क्योंकि ऑडिटर उम्मीद करते हैं कि आपातकाल संभव हैं और हर एक एक निशान छोड़ता है और सिस्टम को उसकी घोषित स्थिति में लौटाता है।

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

क्षेत्र-विशेष दृष्टिकोण

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

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

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

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

उदाहरण

स्टार्टअप। पाँच-व्यक्ति की एक स्टार्टअप अपना पूरा AWS सेटअप, यानी VPC, डेटाबेस, और कंटेनर सेवा, एक एकल Terraform रिपॉज़िटरी में परिभाषित करती है जिसमें स्टेट एक एन्क्रिप्टेड S3 बैकएंड में रखा जाता है और DynamoDB के ज़रिए लॉकिंग होती है। हर बदलाव एक पुल रिक्वेस्ट से गुज़रता है, इसलिए एक अकेला ऑन-कॉल इंजीनियर भी apply चलाने से पहले ठीक-ठीक देख सकता है कि क्या बदलेगा। जब उन्हें एक बड़े डेमो के लिए एक ताज़ा स्टेजिंग वातावरण चाहिए, तो वे एक छोटा मॉड्यूल कॉपी करते हैं और इसे मिनटों में खड़ा करते हैं, और क्लाउड बिल को कम रखने के लिए उतनी ही तेज़ी से ध्वस्त कर देते हैं।

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

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

व्यवसाय मामला: प्रेरणाएँ, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

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

स्तर 3: मानकीकरण। डिक्लेरेटिव IaC पूरे संगठन में दस्तावेज़ीकृत मानक है, जो मैनेज्ड, दूरस्थ, लॉक किए गए स्टेट के साथ साझा वर्ज़न किए गए मॉड्यूल से बना है। पॉलिसी ऐज़ कोड पाइपलाइन में गार्डरेल लागू करती है, सीक्रेट एक समर्पित मैनेजर से संदर्भित होते हैं, और बहाव पहचान एक नियमित अंतराल पर चलती है।

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

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

• Kief Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age.
• Yevgeniy Brikman, Terraform: Up & Running.
• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering.
• Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
• Weaveworks, “GitOps” foundational writings (Alexis Richardson et al.).
• Open Policy Agent documentation and the Rego policy language.
• NIST Special Publication 800-53, security and privacy controls (configuration management family).