लेख

टीम में Terraform: स्टेट का बँटवारा, प्रभाव का दायरा और रिव्यू किए गए प्लान

Terraform स्टेट को कैसे बाँटें, CI में प्लान चलाएँ और केवल वही लागू करें जो रिव्यू हुआ है, ताकि इन्फ्रास्ट्रक्चर बदलाव जोखिम नहीं, सामान्य काम बन जाएँ।

उदाहरण सामान्य और व्याख्यात्मक हैं। वे किसी क्लाइंट के एनवायरनमेंट से नहीं लिए गए हैं: थ्रेशोल्ड और सेटिंग्स को अपने सिस्टम के अनुसार ढालें।

स्टेट फ़ाइल ही असली सीमा है

हर terraform apply उस स्टेट में कुछ भी बदल सकता है जिस पर वह काम करता है। इसलिए जोखिम की इकाई मॉड्यूल नहीं, स्टेट है। पूरे एनवायरनमेंट के लिए एक ही स्टेट हो, तो DNS रिकॉर्ड की एक टाइपो और प्रोडक्शन डेटाबेस का बदलाव एक ही प्लान से गुज़रते हैं — और उस प्लान की गणना में मिनट लगते हैं।

जीवनचक्र और प्रभाव के दायरे के अनुसार बाँटें

उन संसाधनों को साथ रखें जो साथ बदलते हैं और साथ विफल होते हैं। एक आम बँटवारा हर एनवायरनमेंट में इन्हें अलग करता है:

  • आधार: अकाउंट, नेटवर्क, DNS ज़ोन — कभी-कभार बदलते हैं।
  • डेटा: डेटाबेस, बकेट, क्यू — सावधानी से बदलते हैं और डिलीट होने से सुरक्षित रहते हैं।
  • कंप्यूट और सर्विस: क्लस्टर, फ़ंक्शन, लोड बैलेंसर — अक्सर बदलते हैं।

हर परत नीचे वाली परत के आउटपुट पढ़ती है और कभी उसके संसाधनों का प्रबंधन नहीं करती। एनवायरनमेंट एक जैसे मॉड्यूल साझा करते हैं, पर उनके स्टेट और क्रेडेंशियल अलग होते हैं, ताकि staging में apply प्रोडक्शन को छू न सके।

रिमोट स्टेट, लॉकिंग और वर्ज़न

  • स्टेट को ऐसे रिमोट बैकएंड में रखें जिसमें लॉकिंग और वर्ज़निंग चालू हो — कभी Git में नहीं, कभी लैपटॉप पर नहीं।
  • डिपेंडेंसी लॉक फ़ाइल (.terraform.lock.hcl) कमिट करें और मॉड्यूल वर्ज़न पिन करें, ताकि आज का प्लान और अगले महीने का प्लान एक ही कोड चलाएँ।
  • स्टेटफ़ुल संसाधनों को prevent_destroy और प्रोवाइडर की अपनी डिलीशन सुरक्षा से बचाएँ।

हर पुल रिक्वेस्ट पर प्लान, रिव्यू हुए को apply

हर बदलाव के लिए CI में terraform plan चलाएँ और परिणाम पुल रिक्वेस्ट पर पोस्ट करें। मंज़ूरी के बाद दोबारा प्लान करने के बजाय सहेजा हुआ प्लान लागू करें, ताकि प्रोडक्शन को ठीक वही मिले जो रिव्यू करने वालों ने पढ़ा; अगर इस बीच स्टेट बदल गया, तो Terraform पुराने प्लान को अस्वीकार कर देता है। पाइपलाइन को OIDC फ़ेडरेशन के ज़रिए अल्पकालिक क्रेडेंशियल से प्रमाणित होना चाहिए, सीक्रेट में रखी लंबी अवधि की कुंजियों से नहीं।

terraform init -input=false
terraform plan -input=false -lock-timeout=5m -out=tfplan
terraform show -no-color tfplan > plan.txt   # attach to the pull request

# after approval, applying the same saved plan:
terraform apply -input=false tfplan

समय-समय पर ड्रिफ़्ट पकड़ें

कंसोल में बदलाव अब भी होते हैं, आमतौर पर इंसिडेंट के दौरान। terraform plan -detailed-exitcode चलाने वाला शेड्यूल्ड जॉब उन्हें पकड़ लेता है: एग्ज़िट कोड 0 का मतलब कोई बदलाव नहीं, 2 का मतलब असली इन्फ्रास्ट्रक्चर कोड से अलग है, और 1 का मतलब एरर। 2 को टिकट में बदलें, फिर बदलाव को कोड में शामिल करें या उसे वापस लें।

apply से पहले पॉलिसी

“कोई सार्वजनिक बकेट नहीं” या “हर संसाधन पर मालिक का टैग” जैसे नियम लंबे दिन के अंत में किसी रिव्यूअर के बजाय मशीन बेहतर जाँचती है। Conftest के ज़रिए Open Policy Agent जैसे पॉलिसी-एज़-कोड टूल CI में प्लान के JSON रूप (terraform show -json) का मूल्यांकन कर मर्ज रोक सकते हैं।

संपर्क

अपने सेटअप पर दूसरी राय चाहिए?

अपने सिस्टम का छोटा सा विवरण भेजें। एक सीनियर इंजीनियर एक कार्यदिवस में लिखित में जवाब देता है।

अपने इन्फ्रास्ट्रक्चर पर बात करें