Terraform state कैसे काम करता है, और एक टीम में आप उसे कैसे संभालते हैं?

state Terraform का वह रिकॉर्ड है जो बताता है कि कौन सा असली resource किस configuration address से जुड़ा है, साथ में cached attributes जिनसे वह plan निकालता है। टीम के लिए इसे locking वाले remote backend में रहना ही पड़ेगा, जैसे native lockfile सपोर्ट वाला S3 या कोई managed backend, ताकि दो apply एक साथ न चल सकें। इसे कभी git में commit न करें, क्योंकि इसमें secrets सादे टेक्स्ट में होते हैं, और एक विशाल फाइल रखने की जगह इसे blast radius के हिसाब से बांटें।

state वह नक्शा है जो मेरे लिखे कोड और provider में सच में मौजूद चीज़ों को resource address से जोड़ता है, साथ में attributes का cache ताकि plan को हर बार सब कुछ नए सिरे से पढ़ना न पड़े। टीम में यह locking वाले remote backend में जाता है, ताकि दो लोग एक ही वक्त apply चलाकर उसे खराब न कर सकें। जो बात लोगों को चौंकाती है वह यह कि state में resource attributes ज्यों के त्यों होते हैं, तो डेटाबेस पासवर्ड और generated keys वहां सादे टेक्स्ट में पड़े रहते हैं; इसका मतलब bucket encrypted हो, versioned हो, और सिर्फ पाइपलाइन role तक सीमित हो, सबके पढ़ने लायक नहीं। लेआउट पर, मैं blast radius और बदलाव की रफ्तार से बांटता हूं। networking और accounts कम बदलते हैं और उनका अपना state होता है, हर सर्विस या एनवायरनमेंट का अपना, और वे data sources या published outputs से एक दूसरे को पढ़ते हैं, न कि एक root module में सब कुछ ठूंसकर। व्यावहारिक वजह यह है कि पांच सौ resources वाली state फाइल हर plan को धीमा और हर गलती को विशाल बना देती है। रिकवरी के लिए मैं फाइल हाथ से एडिट करने की जगह bucket versioning के साथ state mv और import पर भरोसा करता हूं।