अंतिम समीक्षा: मई 2026
TF-PRO परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक संसाधन को एक लिस्ट/मैप द्वारा संचालित समान नेस्टेड ब्लॉकों (जैसे इनग्रेस नियम) की परिवर्तनीय संख्या की आवश्यकता होती है।
`dynamic` ब्लॉक का उपयोग करें जिसका `for_each` कलेक्शन को दोहराता है; `content {}` के अंदर ब्लॉक इटरेटर (डिफ़ॉल्ट नाम = ब्लॉक लेबल) के माध्यम से प्रत्येक तत्व को संदर्भित करें।
क्यों: डायनामिक ब्लॉक कॉपी-पेस्ट के बिना दोहराए गए नेस्टेड ब्लॉक उत्पन्न करते हैं; इटरेटर प्रत्येक जनरेट किए गए ब्लॉक को उसके स्रोत तत्व से बांधे रखता है।
ऑब्जेक्ट के मैप में प्रत्येक प्रविष्टि के लिए एक संसाधन बनाएं, जिसे स्थिर रूप से कुंजीबद्ध किया गया हो ताकि पुनर्व्यवस्था कभी भी प्रतिस्थापन के लिए मजबूर न करे।
`for_each = var.objects` (एक मैप) सेट करें। स्थिर कुंजी के लिए `each.key` और फ़ील्ड के लिए `each.value.<attr>` का उपयोग करें। यहाँ `count` से बचें - इंडेक्स शिफ्ट से हलचल होती है।
क्यों: मैप कुंजियाँ स्टेट में स्थिर पहचान हैं; लिस्ट इंडेक्स स्थितिजन्य होते हैं और तत्वों को जोड़ने/हटाने पर शिफ्ट हो जाते हैं।
कई इंस्टेंस के लिए `count` और `for_each` के बीच निर्णय लें।
जब इंस्टेंस की अलग-अलग पहचान (एक सेट/मैप) हो तो `for_each` का उपयोग करें; `count` का उपयोग केवल N समान, क्रम-असंवेदनशील प्रतियों के लिए करें। किसी भी चीज़ के लिए `for_each` को प्राथमिकता दें जो बढ़ या घट सकती है।
क्यों: for_each कुंजी द्वारा पता करता है (resource["key"]); count इंडेक्स द्वारा पता करता है (resource[0]) जो इंसर्शन/डिलीशन पर पुनर्व्यवस्थित होता है।
एक इनपुट वेरिएबल एक ऑब्जेक्ट है जहाँ कुछ विशेषताएँ वैकल्पिक हैं और उन्हें डिफ़ॉल्ट की आवश्यकता है।
इसे `object({ name = string, size = optional(number, 10) })` के रूप में टाइप करें। जब कॉलर एट्रिब्यूट को छोड़ देता है तो `optional(type, default)` डिफ़ॉल्ट प्रदान करता है।
क्यों: एक डिफ़ॉल्ट के साथ `optional()` कॉलर्स को संक्षिप्त रखता है, जबकि डाउनस्ट्रीम में एक ठोस मान की गारंटी देता है - हर जगह नल-हैंडलिंग की आवश्यकता नहीं होती है।
लागू करने से पहले एक संसाधन के बारे में एक धारणा को मान्य करें, या बाद में परिणाम की गारंटी दें।
बनाने/अपडेट करने से पहले इनपुट को सत्यापित करने के लिए `lifecycle { precondition { ... } }` का उपयोग करें, और आउटपुट को सत्यापित करने के लिए `postcondition` का उपयोग करें। दोनों `condition` + `error_message` लेते हैं।
क्यों: कस्टम शर्तें एक स्पष्ट संदेश के साथ तेज़ी से विफल हो जाती हैं, बजाय इसके कि एक टूटा हुआ अप्लाई या एक भ्रमित करने वाली डाउनस्ट्रीम त्रुटि उत्पन्न हो।
एक संसाधन को तब फिर से बनाना होगा जब कोई अन्य संसाधन या विशेषता बदल जाए।
`lifecycle { replace_triggered_by = [aws_x.y.id] }` जोड़ें। जब संदर्भित मान बदलता है, तो Terraform इस संसाधन के प्रतिस्थापन को मजबूर करता है।
क्यों: एक प्रतिस्थापन निर्भरता को घोषणात्मक रूप से व्यक्त करता है, हर संबंधित परिवर्तन पर मैनुअल `-replace` से बचाता है।
एक संसाधन को बदलने से डाउनटाइम होता है क्योंकि नया बनने से पहले पुराना नष्ट हो जाता है।
`lifecycle { create_before_destroy = true }` सेट करें ताकि Terraform पहले प्रतिस्थापन को प्रोविजन करे, फिर पुराने को नष्ट करे। अद्वितीय नाम/कोई कठिन संघर्ष सुनिश्चित करें।
क्यों: ज़ीरो-डाउनटाइम प्रतिस्थापन; लेकिन नाम के टकराव और कोटा सीमाओं के लिए देखें जब दोनों संक्षेप में मौजूद हों।
अमान्य इनपुट मानों को जल्दी अस्वीकार करें (उदाहरण के लिए, एक वातावरण जो dev/stage/prod नहीं है)।
वेरिएबल में एक `validation { condition = contains(["dev","stage","prod"], var.env), error_message = "..." }` ब्लॉक जोड़ें।
क्यों: एक प्रदाता कॉल में गहराई से विफल होने के बजाय एक पठनीय संदेश के साथ प्लान समय पर खराब इनपुट को पकड़ता है।
एक ऐसे मान को संदर्भित करें जो प्लान को क्रैश किए बिना मौजूद न हो।
त्रुटियों पर वापस लौटने के लिए `try(local.maybe.value, "default")` का उपयोग करें, या यह जानने के लिए कि क्या कोई एक्सप्रेशन सफल होता है, एक बूलियन प्राप्त करने के लिए `can(expr)` का उपयोग करें।
क्यों: वैकल्पिक/परिवर्तनीय-आकार के डेटा का शालीनता से प्रबंधन; अनुपस्थित कुंजियों पर "Error: Unsupported attribute" से बचाता है।
एक लिस्ट को एक मैप में बदलें, या एक संसाधन तर्क के लिए एक कलेक्शन को फ़िल्टर/आकार दें।
एक `for` एक्सप्रेशन का उपयोग करें: `{ for u in var.users : u.name => u.role if u.active }` (मैप) या `[for x in list : upper(x)]` (लिस्ट)।
क्यों: for एक्सप्रेशन डेटा को नया आकार देने का मुहावरेदार तरीका है; `if` क्लॉज़ फ़िल्टर करता है, `k => v` फॉर्म मैप बनाता है।
एक वेरिएबल या आउटपुट में एक रहस्य होता है जिसे प्लान/अप्लाई आउटपुट में प्रिंट नहीं होना चाहिए।
वेरिएबल को `sensitive = true` के रूप में चिह्नित करें (और आउटपुट को भी)। Terraform इसे CLI आउटपुट में संशोधित करता है, हालांकि यह अभी भी स्टेट में संग्रहीत होता है।
क्यों: लॉग/CI आउटपुट में आकस्मिक प्रकटीकरण से बचाता है; स्टेट को अभी भी संरक्षित किया जाना चाहिए (एन्क्रिप्टेड बैकएंड, एक्सेस कंट्रोल)।
एक ही कॉन्फ़िगरेशन के भीतर दो क्षेत्रों/खातों में संसाधनों का प्रबंधन करें।
एलियास प्रदाताओं (`provider "aws" { alias = "west" region = "us-west-2" }`) को घोषित करें और संसाधनों पर `provider = aws.west` सेट करें या मॉड्यूल में पास करें।
क्यों: एलियास एक कॉन्फ़िग को कई प्रदाता इंस्टेंस को लक्षित करने देते हैं; मॉड्यूल उन्हें `providers` तर्क के माध्यम से स्पष्ट रूप से प्राप्त करते हैं।
एक छिपी हुई निर्भरता (संदर्भों के माध्यम से व्यक्त नहीं की गई) क्रम संबंधी समस्याएं पैदा करती है।
क्रम को लागू करने के लिए `depends_on = [aws_iam_role_policy.x]` जोड़ें। इसका उपयोग कम करें - विशेषता संदर्भों के माध्यम से निहित निर्भरताओं को प्राथमिकता दें।
क्यों: स्पष्ट `depends_on` उन निर्भरताओं को संभालता है जिनका ग्राफ़ अनुमान नहीं लगा सकता, लेकिन अत्यधिक उपयोग से रूढ़िवादी, धीमे प्लान बनते हैं।
संरचित वेरिएबल्स के साथ एक टेम्पलेट से एक कॉन्फ़िग फ़ाइल/यूज़र-डेटा प्रस्तुत करें।
`templatefile("${path.module}/tpl.tftpl", { items = local.items })` का उपयोग करें; टेम्पलेट `%{ for }` / `${}` इंटरपोलेशन का उपयोग करता है।
क्यों: templatefile रेंडरिंग को शुद्ध/प्लान समय पर रखता है (अप्रचलित टेम्पलेट प्रदाता के विपरीत) और लूप/कंडीशनल्स का समर्थन करता है।
एक `for_each` को फीड करने के लिए हर (सबनेट, नियम) संयोजन की एक फ्लैट लिस्ट बनाएं।
क्रॉस-प्रोडक्ट के लिए `setproduct(var.subnets, var.rules)` का उपयोग करें, या नेस्टेड लिस्ट को एक में संपीड़ित करने के लिए `flatten([for ...])` का उपयोग करें।
क्यों: ये फ़ंक्शन नेस्टेड डेटा को फ्लैट, अद्वितीय-कुंजीय संग्रह में बदल देते हैं जिनकी `for_each` को आवश्यकता होती है।
एक रजिस्ट्री मॉड्यूल बदल जाता है और अगले init पर अप्रत्याशित रूप से बुनियादी ढांचे को बदल देता है।
`version = "~> 4.2"` के साथ पिन करें (केवल रजिस्ट्री मॉड्यूल)। Git स्रोतों के लिए, `?ref=v4.2.0` टैग को पिन करें। पिन को जानबूझकर स्थानांतरित करने के लिए `terraform init -upgrade` चलाएँ।
क्यों: अनपिन किए गए मॉड्यूल नवीनतम पर तैरते हैं; पिनिंग अपग्रेड को जानबूझकर और समीक्षा योग्य बनाती है।
एक रूट मॉड्यूल को चाइल्ड मॉड्यूल के भीतर गहराई से उत्पन्न मान की आवश्यकता होती है।
इसे चाइल्ड में एक `output` के रूप में उजागर करें, फिर `module.child.output_name` को संदर्भित करें। जो मान आउटपुट नहीं होते हैं वे कॉलर्स के लिए सुलभ नहीं होते हैं।
क्यों: मॉड्यूल एनकैप्सुलेटेड होते हैं; आउटपुट ही एकमात्र तरीका है जिससे डेटा मॉड्यूल की सीमा को ऊपर की ओर पार करता है।
एक मैप से प्रति टीम/वातावरण में एक बार उसी मॉड्यूल को इंस्टेंसिएट करें।
मॉड्यूल ब्लॉक पर `for_each` सेट करें: `module "env" { for_each = var.envs; source = "./env"; name = each.key }`। `module.env["prod"]` को संदर्भित करें।
क्यों: मॉड्यूल पर `for_each` ब्लॉकों को कॉपी-पेस्ट किए बिना एक पैटर्न को स्केल करता है; कुंजियाँ स्थिर पते देती हैं।
एक चाइल्ड मॉड्यूल को एक गैर-डिफ़ॉल्ट (एलियास) प्रदाता में संसाधन बनाने होंगे।
प्रदाताओं को स्पष्ट रूप से पास करें: `module "x" { providers = { aws = aws.west } }`। चाइल्ड प्रदाता को `required_providers` में `configuration_aliases` के साथ घोषित करता है।
क्यों: मॉड्यूल निहित रूप से एलियास प्रदाताओं को इनहेरिट नहीं करते हैं; प्रदाता मैप पैरेंट एलियास को चाइल्ड से जोड़ता है।
किसी संसाधन का नाम बदलना या उसे एक मॉड्यूल में ले जाना सामान्यतः उसे नष्ट और फिर से बनाएगा।
एक `moved { from = aws_instance.old; to = module.compute.aws_instance.new }` ब्लॉक जोड़ें। Terraform बिना किसी विनाश के स्टेट पते को अपडेट करता है।
क्यों: moved ब्लॉक मैनुअल `terraform state mv` की जगह कोड में रिफैक्टर को सुरक्षित और समीक्षा योग्य बनाते हैं।
एक मोनोलिथिक मॉड्यूल अव्यवस्थित हो गया है और इसमें नेटवर्किंग, कंप्यूट और डेटा संबंधी चिंताएं मिश्रित हैं।
केंद्रित चाइल्ड मॉड्यूल में विघटित करें और उन्हें एक रूट में संयोजित करें, एक के आउटपुट को अगले के इनपुट के रूप में पास करें। मॉड्यूल को एकल-उद्देश्यीय रखें।
क्यों: कंपोजिशन पुन: उपयोग और परीक्षण क्षमता में सुधार करता है; कसकर स्कोप किए गए मॉड्यूल स्वतंत्र रूप से संस्करण और विकसित होते हैं।
उपभोक्ता एक साझा मॉड्यूल को इनपुट के अमान्य संयोजन पास करते हैं।
अनुबंधों को लागू करने के लिए मॉड्यूल के अंदर `validation` ब्लॉक और `precondition` जोड़ें, और `description` के साथ इनपुट को डॉक्यूमेंट करें।
क्यों: एक मॉड्यूल अपने अनुबंध का मालिक होता है; अंदर मान्य करना प्रत्येक कॉलर की रक्षा करता है, न कि केवल एक रूट कॉन्फ़िग की।
गहराई से नेस्टेड मॉड्यूल डेटा प्रवाह और प्रदाता पासिंग को समझना मुश्किल बनाते हैं।
नेस्टिंग को उथला रखें (1-2 स्तर)। प्रदाताओं और प्रमुख इनपुट को प्रत्येक स्तर पर स्पष्ट रूप से पास करें; गहरी निहित विरासत पर निर्भर रहने से बचें।
क्यों: उथले पेड़ तर्क करने में आसान होते हैं; गहरी नेस्टिंग प्रदाता-पासिंग और आउटपुट-प्लंबिंग की जटिलता को बढ़ाती है।
एक पुन: प्रयोज्य मॉड्यूल को निजी रजिस्ट्री में प्रकाशित करें और कॉलर्स को तोड़े बिना इसे विकसित करें।
semver (`v1.2.0`) के साथ रिलीज़ को टैग करें; इनपुट/आउटपुट में बड़े बदलाव प्रमुख संस्करण को आगे बढ़ाते हैं। कॉलर्स `~>` बाधाओं के साथ पिन करते हैं।
क्यों: सिमेंटिक वर्जनिंग उपभोक्ताओं को सुरक्षित रूप से सुधार/सुविधाएँ अपनाने और जानबूझकर ब्रेकिंग परिवर्तनों का विकल्प चुनने देती है।
एक दिए गए परिपक्वता स्तर के लिए मॉड्यूल को कहाँ से स्रोत करना है, यह चुनें।
इन-रेपो के लिए लोकल पाथ (`./modules/x`), साझा-लेकिन-अप्रकाशित के लिए Git (`git::...?ref=tag`), संस्करणित/प्रकाशित मॉड्यूल के लिए रजिस्ट्री (`namespace/name/provider`)।
क्यों: स्रोत प्रकार साझाकरण दायरे से मेल खाता है; केवल रजिस्ट्री स्रोत `version` तर्क और बाधा समाधान का समर्थन करते हैं।
एक मॉड्यूल आउटपुट एक रहस्य ले जाता है जिसका उपयोग रूट द्वारा किया जाता है।
मॉड्यूल आउटपुट को `sensitive = true` के रूप में चिह्नित करें। इसे एक गैर-संवेदनशील संदर्भ में उपभोग करने से त्रुटि होगी जब तक कि आप इसे भी संवेदनशील न मानें।
क्यों: संवेदनशीलता मॉड्यूल सीमा के पार फैलती है, रूट आउटपुट में आकस्मिक रिसाव को रोकती है।
एक मौजूदा `count`-आधारित संसाधन सेट को इंस्टेंस को नष्ट किए बिना `for_each` बनना है।
प्रत्येक `resource[0]` इंडेक्स को नए `resource["key"]` पते पर मैप करने वाले `moved` ब्लॉक जोड़ें, फिर `for_each` पर स्विच करें।
क्यों: moved ब्लॉक स्टेट को स्थितिजन्य से पहचान पते पर पुनः कुंजीबद्ध करते हैं, विनाश/पुनर्निर्माण से बचते हैं।
आपने कॉन्फ़िग में एक संसाधन का नाम बदल दिया; प्लान अब पुराने को नष्ट करना और एक नया बनाना चाहता है।
कॉन्फ़िग में एक `moved` ब्लॉक को प्राथमिकता दें। एड-हॉक/CLI सुधारों के लिए मौजूदा ऑब्जेक्ट को फिर से इंगित करने के लिए `terraform state mv aws_x.old aws_x.new` का उपयोग करें।
क्यों: दोनों स्टेट पते को अपडेट करते हैं ताकि Terraform मौजूदा ऑब्जेक्ट को पुनर्निरमित संसाधन के रूप में देखे - कोई विनाश नहीं।
मौजूदा, मैन्युअल रूप से बनाए गए संसाधन को Terraform प्रबंधन के तहत लाएँ।
एक `import { to = aws_x.y; id = "i-123" }` ब्लॉक जोड़ें और कॉन्फ़िग को स्केफोल्ड करने के लिए `terraform plan -generate-config-out=gen.tf` चलाएँ, फिर परिष्कृत करें और लागू करें।
क्यों: कॉन्फ़िग-चालित आयात समीक्षा योग्य है और एक प्रारंभिक कॉन्फ़िगरेशन उत्पन्न करता है, पुराने अनिवार्य `terraform import` के विपरीत।
Terraform के साथ एक संसाधन का प्रबंधन करना बंद करें लेकिन उसे क्लाउड में चालू रहने दें।
`terraform state rm aws_x.y` चलाएँ। Terraform ऑब्जेक्ट को भूल जाता है; यह नष्ट नहीं होता है। एक री-क्रिएट प्लान से बचने के लिए इसकी कॉन्फ़िग को भी हटा दें।
क्यों: state rm बिना डिलीट किए अलग हो जाता है - जब किसी संसाधन को किसी अन्य टूल/टीम को सौंपते हैं तो उपयोगी होता है।
स्टेट को लोकल बैकएंड से S3 (या HCP Terraform पर) में ले जाएँ।
`backend`/`cloud` ब्लॉक को जोड़ें/बदलें, `terraform init` चलाएँ - Terraform परिवर्तन का पता लगाता है और मौजूदा स्टेट को नए बैकएंड में माइग्रेट करने का संकेत देता है।
क्यों: init कॉपी का आयोजन करता है; हाँ कहने से स्टेट सुरक्षित रूप से माइग्रेट हो जाता है बजाय खाली शुरू करने के।
दो इंजीनियर एक ही रिमोट स्टेट के खिलाफ एक साथ अप्लाई चलाते हैं।
लॉकिंग का समर्थन करने वाले बैकएंड का उपयोग करें (S3+DynamoDB, HCP Terraform, आदि)। Terraform प्रति ऑपरेशन एक लॉक प्राप्त करता है; दूसरा रन प्रतीक्षा करता है या त्रुटि देता है।
क्यों: लॉकिंग समवर्ती राइट्स को रोकती है जो स्टेट को दूषित कर सकती हैं। इसे कभी भी लापरवाही से अक्षम न करें।
एक क्रैश हुए अप्लाई ने एक बासी लॉक छोड़ दिया और अब हर रन अवरुद्ध है।
पुष्टि करें कि कोई ऑपरेशन वास्तव में नहीं चल रहा है, फिर `terraform force-unlock <LOCK_ID>`। त्रुटि संदेश से आईडी का उपयोग करें।
क्यों: force-unlock एक अनाथ लॉक को साफ करता है; एक वास्तविक ऑपरेशन चलने के दौरान ऐसा करने से स्टेट भ्रष्टाचार का खतरा होता है।
परिवर्तनों का प्रस्ताव किए बिना कॉन्फ़िगरेशन/स्टेट और वास्तविक बुनियादी ढांचे के बीच के बदलाव का पता लगाएँ।
`terraform plan -refresh-only` (या स्टेट को अपडेट करने के लिए `apply -refresh-only`) चलाएँ। यह संसाधन परिवर्तनों की योजना बनाए बिना अंतर की रिपोर्ट करता है।
क्यों: ड्रिफ्ट डिटेक्शन को परिवर्तन नियोजन से अलग करता है - आप क्लाउड में क्या बदला है, इसे सुलझाने का निर्णय लेने से पहले देखते हैं।
एक संसाधन ठीक से काम नहीं कर रहा है और आप कॉन्फ़िग को संपादित किए बिना इसे फिर से बनाना चाहते हैं।
`terraform apply -replace="aws_instance.web"` चलाएँ। यह अप्रचलित `terraform taint` का आधुनिक प्रतिस्थापन है।
क्यों: -replace अगले अप्लाई पर एक संसाधन को नष्ट और फिर से बनाने के लिए मजबूर करता है, CLI पर घोषणात्मक रूप से।
आप अप्लाई को तेज़ करने के लिए नियमित रूप से `-target` का उपयोग करने के लिए प्रलोभित हैं।
`-target` का उपयोग केवल त्रुटियों से उबरने या सर्जिकल सुधारों के लिए करें। इसे एक सामान्य वर्कफ़्लो के रूप में टालें - यह आंशिक अप्लाई उत्पन्न करता है और निर्भरताओं को छोड़ सकता है।
क्यों: नियमित लक्ष्यीकरण निर्भरता समस्याओं को छुपाता है और अपूर्ण स्टेट उत्पन्न करता है; HashiCorp इसे एक असाधारण उपकरण के रूप में डॉक्यूमेंट करता है।
एक प्रदाता ने नेमस्पेस बदल दिए (जैसे hashicorp/aws एक फोर्क में) और स्टेट पुराने पते को संदर्भित करता है।
`terraform state replace-provider registry.terraform.io/hashicorp/aws registry.example.com/org/aws` चलाएँ।
क्यों: स्टेट में प्रदाता संदर्भों को फिर से लिखता है ताकि init/plan संसाधनों को फिर से बनाए बिना नए स्रोत को हल कर सके।
एक कॉन्फ़िगरेशन को किसी अन्य कॉन्फ़िगरेशन/वर्कस्पेस द्वारा उत्पादित आउटपुट की आवश्यकता होती है।
किसी अन्य स्टेट के आउटपुट को केवल पढ़ने के लिए `terraform_remote_state` डेटा स्रोत (या HCP Terraform रन आउटपुट) का उपयोग करें।
क्यों: संसाधनों को डुप्लिकेट किए बिना स्टेट सीमाओं के पार मान साझा करता है; केवल निर्यातित आउटपुट पठनीय हैं।
बैकएंड सेटिंग्स (बकेट, कुंजी) प्रति वातावरण भिन्न होती हैं और उन्हें हार्डकोड नहीं किया जाना चाहिए।
उन्हें `backend` ब्लॉक से बाहर छोड़ दें और init पर पास करें: `terraform init -backend-config=prod.hcl` (या `-backend-config="key=..."`)।
क्यों: आंशिक कॉन्फ़िगरेशन एक कॉन्फ़िग को वातावरणों में पुन: प्रयोज्य रखता है जबकि init पर वातावरण-विशिष्ट बैकएंड मान प्रदान करता है।
आपको एक कॉन्फ़िगरेशन से dev/stage/prod के लिए अलग स्टेट की आवश्यकता है।
हल्के आइसोलेशन के लिए CLI वर्कस्पेस (`terraform workspace new prod`) का उपयोग करें, या मजबूत अलगाव के लिए अलग रूट कॉन्फ़िग/HCP वर्कस्पेस का उपयोग करें।
क्यों: प्रत्येक वर्कस्पेस का अपना स्टेट होता है; नामकरण/आकार बदलने के लिए `terraform.workspace` को संदर्भित करें। मजबूत अलगाव के लिए, अलग बैकएंड/वर्कस्पेस को प्राथमिकता दें।
HCP Terraform वर्कस्पेस वेरिएबल्स में लंबे समय तक चलने वाली क्लाउड कुंजियों को संग्रहीत करने से बचें।
डायनामिक प्रदाता क्रेडेंशियल कॉन्फ़िगर करें: HCP Terraform प्रति रन AWS/Azure/GCP/Vault से अल्पकालिक क्रेडेंशियल प्राप्त करने के लिए OIDC/वर्कलोड पहचान का उपयोग करता है।
क्यों: स्थिर रहस्यों को समाप्त करता है; क्रेडेंशियल समय पर जारी किए जाते हैं और समाप्त हो जाते हैं, जिससे ब्लास्ट रेडियस सिकुड़ जाता है।
कई वर्कस्पेस में समान वेरिएबल (प्रदाता कॉन्फ़िग, टैग) की आवश्यकता होती है।
एक वेरिएबल सेट परिभाषित करें और इसे एक प्रोजेक्ट या चयनित वर्कस्पेस पर लागू करें। वर्कस्पेस-स्तरीय वेरिएबल वेरिएबल-सेट मानों को ओवरराइड करते हैं।
क्यों: वेरिएबल सेट साझा कॉन्फ़िग को डुप्लिकेट करने से बचते हैं; वरीयता (वर्कस्पेस > सेट) एक वर्कस्पेस को आवश्यकता पड़ने पर ओवरराइड करने देती है।
प्रत्येक रन पर गार्डरेल (कोई सार्वजनिक S3 नहीं, आवश्यक टैग) लागू करें।
एक Sentinel या OPA पॉलिसी सेट संलग्न करें। प्रवर्तन स्तर सेट करें: सलाहकार (चेतावनी), सॉफ्ट-अनिवार्य (अनुमति के साथ ओवरराइड), या हार्ड-अनिवार्य (ब्लॉक)।
क्यों: पॉलिसी-एज़-कोड रन को केंद्रीय रूप से नियंत्रित करता है; प्रवर्तन स्तर परिचालन लचीलेपन के खिलाफ कठोरता को संतुलित करते हैं।
एक बाहरी जांच (लागत अनुमान, सुरक्षा स्कैन) को रन पाइपलाइन में एकीकृत करें।
एक चरण (प्री-प्लान, पोस्ट-प्लान, प्री-अप्लाई) पर एक रन टास्क कॉन्फ़िगर करें। HCP Terraform बाहरी सेवा को कॉल करता है और उसके परिणाम पर रन को नियंत्रित करता है।
क्यों: रन टास्क कस्टम CI प्लंबिंग के बिना तीसरे पक्ष की जांच के साथ पाइपलाइन का विस्तार करते हैं।
चुनें कि एक वर्कस्पेस के लिए रन कैसे ट्रिगर होते हैं।
VCS-चालित (कमिट/PR ट्रिगर प्लान), CLI-चालित (रिमोट के खिलाफ `terraform plan/apply`), या API-चालित (अपलोड की गई कॉन्फ़िग)। प्रति टीम वर्कफ़्लो चुनें।
क्यों: VCS-चालित GitOps के अनुकूल है; CLI-चालित लोकल इटिरेशन के अनुकूल है; API-चालित कस्टम पाइपलाइन के अनुकूल है। वे प्रति वर्कस्पेस परस्पर अनन्य हैं।
एक टीम को स्टेजिंग वर्कस्पेस पर राइट एक्सेस दें लेकिन प्रोडक्शन पर केवल रीड-ओनली एक्सेस।
ऑर्ग/प्रोजेक्ट/वर्कस्पेस स्तर पर अनुमतियों का दायरा तय करें: प्रति प्रोजेक्ट या वर्कस्पेस टीम एक्सेस (रीड/प्लान/राइट/एडमिन) असाइन करें; बड़े पैमाने पर प्रबंधन के लिए प्रोजेक्ट ग्रुपिंग का उपयोग करें।
क्यों: दानेदार, स्कोप वाली अनुमतियाँ कम से कम विशेषाधिकार लागू करती हैं; प्रोजेक्ट-स्तरीय अनुदान प्रति-वर्कस्पेस प्रबंधन को कम करते हैं।
एक नेटवर्किंग वर्कस्पेस अप्लाई को स्वचालित रूप से निर्भर ऐप वर्कस्पेस में एक रन कतारबद्ध करना चाहिए।
एक रन ट्रिगर कॉन्फ़िगर करें: डाउनस्ट्रीम वर्कस्पेस अपस्ट्रीम को सब्सक्राइब करता है; एक सफल अप्लाई डाउनस्ट्रीम रन को कतारबद्ध करता है।
क्यों: रन ट्रिगर निर्भर वर्कस्पेस को श्रृंखला में जोड़ते हैं ताकि साझा बुनियादी ढांचे के परिवर्तन क्रम में फैलें।
गैर-Terraform उपयोगकर्ताओं को एक फॉर्म के माध्यम से मानकीकृत बुनियादी ढांचे को प्रोविजन करने दें।
निजी रजिस्ट्री में एक नो-कोड मॉड्यूल प्रकाशित करें; उपयोगकर्ता इसे UI के माध्यम से इंस्टेंसिएट करते हैं, केवल इनपुट प्रदान करते हैं - कोई HCL लेखक नहीं।
क्यों: नो-कोड मॉड्यूल स्व-सेवा प्रोविजनिंग को लोकतांत्रिक बनाते हैं जबकि अंतर्निहित कॉन्फ़िग को शासित और संस्करणित रखते हैं।
संगठन भर में जांचे गए मॉड्यूल और प्रदाताओं को साझा करें।
HCP Terraform निजी रजिस्ट्री में प्रकाशित करें; उपभोक्ता संस्करण बाधाओं के साथ `app.terraform.io/org/name/provider` को संदर्भित करते हैं।
क्यों: एक निजी रजिस्ट्री आंतरिक मॉड्यूल की खोज, संस्करण और शासन को केंद्रीकृत करती है।
अनुमतियों और वेरिएबल सेट के लिए दर्जनों वर्कस्पेस को टीम/एप्लिकेशन द्वारा व्यवस्थित करें।
वर्कस्पेस को परियोजनाओं में समूहित करें; प्रोजेक्ट स्तर पर टीम अनुमतियां और वेरिएबल सेट लागू करें।
क्यों: परियोजनाएँ शासन को स्केल करती हैं - आप प्रति वर्कस्पेस के बजाय प्रति प्रोजेक्ट एक्सेस और साझा कॉन्फ़िग का प्रबंधन करते हैं।
लगातार पता लगाएँ कि उत्पादन कॉन्फ़िगर किए गए स्टेट से कब भटकता है।
वर्कस्पेस पर स्वास्थ्य मूल्यांकन (ड्रिफ्ट डिटेक्शन / निरंतर सत्यापन) सक्षम करें; HCP Terraform समय-समय पर रीफ़्रेश करता है और ड्रिफ्ट और विफल अभिकथन की रिपोर्ट करता है।
क्यों: स्वचालित मूल्यांकन अप्लाई के बीच ड्रिफ्ट और टूटे हुए पोस्टकंडीशन को सतह पर लाते हैं, इससे पहले कि वे घटनाएँ पैदा करें।
HCP Terraform को एक निजी नेटवर्क के अंदर बुनियादी ढांचे तक पहुंचना होगा जिसमें कोई सार्वजनिक प्रवेश नहीं है।
निजी नेटवर्क में HCP Terraform एजेंटों को तैनात करें और वर्कस्पेस को एक एजेंट पूल में असाइन करें; रन एजेंट के माध्यम से निष्पादित होते हैं।
क्यों: एजेंट HCP Terraform को निजी/एयर-गैप्ड वातावरणों के खिलाफ काम करने देते हैं बिना उन्हें सार्वजनिक रूप से उजागर किए।
एक खराब अप्लाई ने स्टेट को दूषित कर दिया और आपको पुनर्प्राप्त करने की आवश्यकता है।
HCP Terraform संस्करणित स्टेट रखता है; वर्कस्पेस UI/API से पिछली स्टेट संस्करण पर वापस जाएँ और फिर से प्लान करें।
क्यों: बिल्ट-इन स्टेट वर्जनिंग स्वयं बैकएंड स्नैपशॉट का प्रबंधन किए बिना रिकवरी पॉइंट प्रदान करती है।