अंतिम समीक्षा: मई 2026
004 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक टीम मैन्युअल रूप से क्लाउड कंसोल पर क्लिक करती है; कोई नहीं जानता कि प्रोडक्शन कैसा दिखना चाहिए था।
IaC अपनाएं। कॉन्फ़िगरेशन वर्ज़न-नियंत्रित फ़ाइलों में रहते हैं - फ़ाइलें सच्चाई का आधिकारिक स्रोत हैं, न कि क्लाउड कंसोल।
क्यों: ऑडिट ट्रेल, पीयर रिव्यू, रोलबैक और प्रतिकृति सभी वर्ज़न कंट्रोल से प्रवाहित होते हैं। मैन्युअल प्रोविज़निंग में इनमें से कोई भी नहीं होता।
वांछित अंतिम स्थिति का वर्णन करने और उस तक पहुंचने के लिए स्क्रिप्टिंग चरणों के बीच चयन करें।
Terraform डिक्लेरेटिव है। आप लक्ष्य का वर्णन करते हैं; Terraform API कॉल का पता लगाता है। Ansible, Bash स्क्रिप्ट, कस्टम SDKs इंपेरेटिव हैं।
क्यों: डिक्लेरेटिव कॉन्फ़िग्स आइडमपोटेंट होते हैं और शुरुआती स्थिति की परवाह किए बिना अभिसरित होते हैं। इंपेरेटिव स्क्रिप्ट को हर संक्रमण के बारे में तर्क करना चाहिए।
इंजीनियर चाहता है कि संसाधनों को दोगुना किए बिना उसी `terraform apply` को फिर से चलाना सुरक्षित हो।
डिज़ाइन द्वारा आइडमपोटेंट। एक ही कॉन्फ़िगरेशन को बार-बार लागू करने से वही स्थिति प्राप्त होती है - कोई डुप्लिकेट नहीं, कोई ड्रिफ्ट नहीं।
पता लगाएं कि वास्तविकता कॉन्फ़िगरेशन से कब अलग हुई (किसी ने कंसोल में क्लिक किया)।
`terraform plan -refresh-only` वर्तमान क्लाउड स्टेट को पढ़ता है और परिवर्तन प्रस्तावित किए बिना स्टेट के विरुद्ध अंतर की रिपोर्ट करता है।
प्रारंभिक प्रोविज़निंग को चल रहे ऑपरेशंस से अलग करें।
डे 0 = डिज़ाइन और प्लानिंग। डे 1 = प्रारंभिक प्रोविज़निंग (पहला apply)। डे 2 = चल रहे ऑपरेशंस: पैचिंग, स्केलिंग, सर्टिफिकेट रोटेशन, ड्रिफ्ट सुधार।
क्यों: अधिकांश प्रोडक्शन का काम डे 2 का होता है। IaC टूलिंग को केवल पहले-डिप्लॉय का ही नहीं, बल्कि पुनरावृत्ति का भी समर्थन करना चाहिए।
कंसोल ड्रिफ्ट के जोखिम को कम करें; सभी इंफ्रा परिवर्तनों को समीक्षा से गुजरना अनिवार्य करें।
IaC के साथ GitOps: git सच्चाई का स्रोत है, PRs प्लान को ट्रिगर करते हैं, मर्जेस अप्लाई को ट्रिगर करते हैं। SCP/IAM के माध्यम से सीधे कंसोल एक्सेस को ब्लॉक करें।
वर्कलोड AWS और GCP तक फैला है; टीम एक टूल, एक वर्कफ़्लो चाहती है।
एक कॉन्फ़िगरेशन में कई प्रोवाइडर्स के साथ Terraform: `hashicorp/aws` + `hashicorp/google`। एक प्रोवाइडर से आउटपुट दूसरे के इनपुट को फ़ीड करते हैं।
क्यों: प्रोवाइडर-अज्ञेय कोर; प्रति-क्लाउड SDKs प्लगेबल प्रोवाइडर्स में रहते हैं। CloudFormation/ARM सिंगल-क्लाउड हैं।
मानक Terraform लाइफ़साइकिल चरण।
`init` (प्रोवाइडर्स + बैकएंड डाउनलोड करें) → `plan` (पूर्वावलोकन) → `apply` (निष्पादित करें) → `destroy` (टियर डाउन करें)। `plan` केवल पढ़ने के लिए है और सुरक्षित है।
Terraform को हर बार चलने पर क्लाउड से क्वेरी करने के बजाय एक स्टेट फ़ाइल की आवश्यकता क्यों होती है?
स्टेट कॉन्फ़िगरेशन पतों (`aws_instance.web`) को वास्तविक संसाधन IDs से मैप करती है, निर्भरताओं को ट्रैक करती है, और मेटाडेटा को कैश करती है। इसके बिना, Terraform यह नहीं जान सकता कि वह कौन से क्लाउड संसाधनों का प्रबंधन करता है बनाम कौन से कहीं और बनाए गए थे।
ओपन-सोर्स CLI और HCP Terraform के बीच चयन करें।
सोलो / छोटी टीम / कोई नीति प्रवर्तन नहीं → रिमोट बैकएंड के साथ OSS CLI। कई टीमें / Sentinel/OPA नीतियां / VCS-संचालित रन / डायनामिक क्रेडेंशियल → HCP Terraform।
क्यों: दोनों एक ही Terraform बाइनरी चलाते हैं; HCP सहयोग, शासन और रिमोट-रनर इंफ्रास्ट्रक्चर जोड़ता है।
VMs को प्रोविज़न करना बनाम उनके अंदर सॉफ़्टवेयर कॉन्फ़िगर करना।
Terraform क्लाउड संसाधनों (VMs, नेटवर्क, IAM) को प्रोविज़न करता है। Ansible/Chef/Puppet VMs के अंदर सॉफ़्टवेयर कॉन्फ़िगर करते हैं। वे एक-दूसरे के पूरक हैं, प्रतिस्पर्धी नहीं।
AWS-ओनली शॉप CloudFormation बनाम Terraform पर बहस कर रही है।
CloudFormation में tighter AWS इंटीग्रेशन, नेटिव रोलबैक और शून्य स्टेट-फ़ाइल प्रबंधन है। Terraform मल्टी-क्लाउड, बड़े मॉड्यूल इकोसिस्टम और HCL एर्गोनॉमिक्स में जीतता है। यदि AWS-ओनली है और रोलबैक सबसे महत्वपूर्ण है तो CFN चुनें; अन्यथा Terraform।
पुनरुत्पादन योग्य इंस्टॉलेशन के लिए प्रोवाइडर स्रोत और वर्ज़न को पिन करें।
`terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }` में घोषित करें।
क्यों: स्पष्ट `required_providers` के बिना, Terraform लीगेसी रजिस्ट्री नेमस्पेस को मानता है और असंगत वर्ज़न चुन सकता है।
कॉन्फ़िगरेशन में AWS के लिए `required_providers` है लेकिन कोई `provider "aws"` ब्लॉक नहीं है।
Terraform एक डिफ़ॉल्ट खाली प्रोवाइडर कॉन्फ़िगरेशन बनाता है। AWS प्रोवाइडर फिर अपने मानक precedence में `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS पढ़ता है।
क्यों: एक स्पष्ट `provider` ब्लॉक वैकल्पिक है; इसकी आवश्यकता केवल डिफ़ॉल्ट को ओवरराइड करने या कई इंस्टेंसेस को उपनाम देने के लिए होती है।
किस वर्ज़न-कन्सट्रेंट ऑपरेटर का उपयोग करना है, तय करें।
`~> 5.0` `>= 5.0, < 6.0` (कोई भी 5.x) की अनुमति देता है। `~> 5.0.1` `>= 5.0.1, < 5.1.0` (केवल पैच अपडेट) की अनुमति देता है। `>= 5.0` कोई ऊपरी सीमा नहीं। `= 5.2.0` सटीक। `!= 5.3.0` बहिष्करण।
क्यों: निराशावादी ऑपरेटर `~>` केवल सबसे दाहिने वर्ज़न घटक को बढ़ने की अनुमति देता है।
`terraform init` वास्तव में क्या करता है?
`required_providers` के अनुसार प्रोवाइडर्स डाउनलोड करता है, बैकएंड को इनिशियलाइज़ करता है, मॉड्यूल स्रोत डाउनलोड करता है, और `.terraform/` के साथ `.terraform.lock.hcl` लिखता है। `plan` या `apply` से पहले आवश्यक है।
`init` के बाद एक `.terraform.lock.hcl` फ़ाइल दिखाई दी। इसे कमिट करें या gitignore करें?
इसे कमिट करें। लॉक फ़ाइल सटीक प्रोवाइडर वर्ज़न + क्रिप्टोग्राफ़िक चेकसम रिकॉर्ड करती है। यह सुनिश्चित करती है कि हर सहयोगी और CI रनर समान प्रोवाइडर्स को इंस्टॉल करे।
क्यों: इसके बिना, `terraform init` एक अलग मशीन पर एक नया संगत वर्ज़न चुन सकता है, जिससे आश्चर्यजनक अंतर आ सकते हैं।
`.tf` फ़ाइलों में व्हाइटस्पेस, अलाइनमेंट और इंडेंटेशन को मानकीकृत करें।
`terraform fmt` `.tf` फ़ाइलों को कैरॉनीकल स्टाइल में इन-प्लेस फिर से लिखता है। प्री-कमिट हुक्स और CI में चलाएं।
क्लाउड APIs को हिट किए बिना सिंटैक्स त्रुटियों और टाइप मिसमैच को पकड़ें।
`terraform validate` HCL सिंटैक्स, टाइप कंसिस्टेंसी, आवश्यक आर्गुमेंट्स और आंतरिक संदर्भों की जांच करता है। यह केवल लोकल है, प्रोवाइडर ऑथ की आवश्यकता नहीं है।
क्यों: यह प्रोवाइडर-साइड समस्याओं (ऑथ, लापता संसाधन) को नहीं पकड़ता है - वे केवल `plan` पर ही सामने आती हैं।
CI कई प्रोजेक्ट्स में बार-बार `terraform init` चलाता है, प्रत्येक स्क्रैच से वही प्रोवाइडर्स डाउनलोड करता है।
`TF_PLUGIN_CACHE_DIR` (या CLI कॉन्फ़िग में `plugin_cache_dir`) सेट करें। प्रोवाइडर्स एक बार डाउनलोड किए जाते हैं और प्रति-प्रोजेक्ट `.terraform/` डायरेक्ट्रीज में symlink किए जाते हैं।
प्रोवाइडर स्रोत पते किस प्रारूप का पालन करते हैं?
`<hostname>/<namespace>/<type>` - उदा. `registry.terraform.io/hashicorp/aws`। hostname छोड़े जाने पर पब्लिक Terraform Registry डिफ़ॉल्ट होता है। Namespace = वेंडर। Type = प्रोवाइडर का नाम।
सहयोगियों को असंगत Terraform CLI वर्ज़न चलाने से रोकें।
`terraform { required_version = ">= 1.5, < 2.0" }`। यदि चल रहा वर्ज़न मैच नहीं करता है तो CLI काम करने से इनकार करता है।
CI/CD रनर के लिए प्रोवाइडर प्रमाणीकरण चुनें।
सबसे अच्छा: कम-समय के डायनामिक क्रेडेंशियल (AWS/Azure/GCP पर OIDC ट्रस्ट, HCP Terraform डायनामिक प्रोवाइडर क्रेड्स)। स्वीकार्य: env vars (`AWS_ACCESS_KEY_ID`)। बचें: हार्डकोडेड `provider` ब्लॉक क्रेडेंशियल।
क्यों: कॉन्फ़िग में स्टैटिक लंबे समय तक रहने वाले सीक्रेट्स लीक हुए क्रेडेंशियल घटनाओं का प्रमुख कारण हैं।
शीर्ष-स्तरीय सेटिंग्स कहाँ रहती हैं?
एक `terraform { ... }` ब्लॉक में `required_version`, `required_providers`, `backend`, `cloud` और experiments होते हैं। फ़ाइलों में कई `terraform` ब्लॉक मर्ज किए जाते हैं।
संसाधन स्टेट में मौजूद है लेकिन अब Terraform-प्रबंधित नहीं होना चाहिए; क्लाउड संसाधन को चलना जारी रखना चाहिए।
`terraform state rm <addr>`। क्लाउड संसाधन को नष्ट किए बिना स्टेट से हटाता है।
एक संसाधन का नाम बदल दिया या उसे एक मॉड्यूल में ले जाया गया; नष्ट/पुनर्निर्माण से बचना चाहते हैं।
`terraform state mv <old> <new>`। क्लाउड संसाधनों को स्पर्श किए बिना स्टेट मैपिंग को अपडेट करता है।
क्यों: Terraform 1.1+ में, HCL में `moved` ब्लॉक को प्राथमिकता दें - यह समीक्ष्य योग्य है, वर्ज़न-नियंत्रित है, और PR योजनाओं में काम करता है।
आंतरिक प्रोवाइडर रजिस्ट्री URL बदल गया; मौजूदा स्टेट अभी भी पुराने स्रोत पते का संदर्भ देता है।
`terraform state replace-provider <old-source> <new-source>`। स्टेट में प्रोवाइडर संदर्भों को फिर से लिखता है।
मध्य-रन में अप्लाई क्रैश हो गया; DynamoDB लॉक अटक गया है और अन्य इंजीनियर ब्लॉक हैं।
`terraform force-unlock <LOCK_ID>` (लॉक ID त्रुटि संदेश में है)। अनलॉक करने से पहले सत्यापित करें कि कोई और नहीं चल रहा है।
क्यों: लॉक क्रैश होने पर स्वचालित रूप से जारी नहीं होते क्योंकि क्लीनअप चरण कभी निष्पादित नहीं हुआ।
मौजूदा मैन्युअल रूप से बनाया गया S3 बकेट पुनर्निर्माण के बिना Terraform प्रबंधन के तहत आने की आवश्यकता है।
संसाधन ब्लॉक लिखें, फिर `terraform import aws_s3_bucket.legacy legacy-bucket-name`। स्टेट अब मौजूदा बकेट को रिकॉर्ड करता है; बाद की योजनाएं केवल ड्रिफ्ट दिखाती हैं।
एड-हॉक CLI कमांड के बजाय CI के माध्यम से कई संसाधनों को पुनरुत्पादन योग्य रूप से आयात करने की आवश्यकता है।
`import` ब्लॉक (Terraform 1.5+) का उपयोग करें: `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`। इंपोर्ट `apply` के दौरान होते हैं, वर्ज़न-नियंत्रित होते हैं, और प्लान आउटपुट में काम करते हैं।
एक क्रिप्टिक प्रोवाइडर त्रुटि को डीबग करें; पूर्ण HTTP ट्रेस की आवश्यकता है।
`TF_LOG=TRACE` (सबसे वर्बोस)। `TF_LOG_PATH=./tf.log` एक फ़ाइल में लिखता है। अन्य स्तर: DEBUG, INFO, WARN, ERROR।
बिना लागू किए वर्तमान स्टेट के विरुद्ध `merge()` या `cidrsubnet()` जैसे एक्सप्रेशन का परीक्षण करें।
`terraform console` वर्तमान कॉन्फ़िगरेशन + स्टेट के दायरे में एक इंटरैक्टिव REPL खोलता है। स्थानीय और आउटपुट प्रोटोटाइप के लिए उपयोगी।
एक जटिल कॉन्फ़िगरेशन के डिपेंडेंसी DAG को विज़ुअलाइज़ करें।
`terraform graph | dot -Tsvg > graph.svg` संसाधन निर्भरताओं का एक Graphviz विज़ुअलाइज़ेशन उत्पन्न करता है।
एक CI स्क्रिप्ट से Terraform आउटपुट पढ़ें।
`terraform output -json <name>` `jq` पार्सिंग के लिए सुरक्षित JSON उत्सर्जित करता है। प्लेन `terraform output` मानव-स्वरूपित है और स्क्रिप्ट-सुरक्षित नहीं है।
अगले apply पर एक ही संसाधन को फिर से बनाने के लिए मजबूर करें।
`terraform apply -replace=aws_instance.web` (Terraform 1.x)। लीगेसी `terraform taint` पदावनत है।
क्यों: `-replace` प्लान आउटपुट में समीक्ष्य योग्य है; `taint` अगली योजना से पहले स्टेट को चुपचाप म्युटेट करता था।
जांचें कि स्टेट में वर्तमान में क्या ट्रैक किया गया है।
`terraform state list` सभी संसाधन पते दिखाता है। `terraform state show <addr>` एक संसाधन के लिए विशेषताओं को दिखाता है। अनुक्रमित संसाधनों के लिए उद्धरणों का उपयोग करें: `terraform state show 'aws_instance.web[0]'`।
एक मॉड्यूल स्रोत चुनें।
स्थानीय पथ → `./modules/vpc`। सार्वजनिक रजिस्ट्री → `terraform-aws-modules/vpc/aws`। Git → `git::https://github.com/org/repo.git//path?ref=v1.0`। S3/HTTP/Mercurial भी समर्थित हैं।
एक रजिस्ट्री मॉड्यूल को केवल पैच अपडेट की अनुमति देने के लिए पिन करें।
`version = "~> 3.5.2"` `>= 3.5.2, < 3.6.0` की अनुमति देता है। मामूली-अपडेट टॉलरेंस के लिए, `~> 3.0` (कोई भी 3.x) का उपयोग करें। स्थानीय पथ मॉड्यूल `version` का समर्थन नहीं करते हैं।
संगठन-व्यापी दृश्यता वाले केवल-आंतरिक मॉड्यूल।
HCP Terraform Private Module Registry। पता: `app.terraform.io/<org>/<name>/<provider>`। Git टैग से semver (`v1.2.0`) के बाद वर्ज़न का पता चला।
सार्वजनिक रजिस्ट्री और HCP Terraform प्राइवेट रजिस्ट्री दोनों किस तंत्र के माध्यम से मॉड्यूल वर्ज़न का पता लगाती हैं?
सिमेंटिक वर्ज़निंग (`v1.2.0` या `1.2.0`) के बाद Git टैग। एक नया टैग पुश करें → नया वर्ज़न उपलब्ध।
कॉलिंग कॉन्फ़िगरेशन के लिए बनाए गए बकेट के ARN को एक्सपोज़ करें।
मॉड्यूल के अंदर: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`। कॉलर इसे `module.<name>.bucket_arn` के रूप में पढ़ता है।
एक मॉड्यूल को पैरामीटर करें ताकि कॉलर CIDR, नाम, टैग्स प्रदान कर सकें।
मॉड्यूल रूट पर `variable` ब्लॉक इनपुट को परिभाषित करते हैं। कॉलर उन्हें इनलाइन पास करते हैं: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`।
मॉड्यूल इनपुट के रूप में एक डेटाबेस पासवर्ड प्राप्त करता है; मान CLI आउटपुट में कभी नहीं दिखना चाहिए।
`sensitive = true` के रूप में वेरिएबल को चिह्नित करें। अप्लाई/प्लान आउटपुट `(sensitive value)` दिखाता है। ध्यान दें: अभी भी स्टेट में प्लेनटेक्स्ट के रूप में संग्रहीत है।
एक "प्लेटफ़ॉर्म" मॉड्यूल बनाएं जो आंतरिक रूप से VPC + EKS + RDS मॉड्यूल को कॉल करता है।
एक मॉड्यूल अन्य मॉड्यूल को कॉल कर सकता है। एक से आउटपुट को अगले के इनपुट के रूप में वायर करें: `eks_subnet_ids = module.vpc.private_subnet_ids`।
एक ही मॉड्यूल को विभिन्न इनपुट के साथ N बार इंस्टेंशिएट करें (जैसे प्रति क्षेत्र एक)।
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`। `module.regional["us-east-1"].output_name` के माध्यम से संदर्भ।
मॉड्यूल को एक उपनामित प्रोवाइडर की आवश्यकता है (जैसे गैर-डिफ़ॉल्ट क्षेत्र के लिए)।
कॉलर `module` इनवोकेशन में `providers = { aws = aws.us_west }` ब्लॉक पास करता है। मॉड्यूल `required_providers` में `configuration_aliases = [aws.us_west]` घोषित करता है।
एक सार्वजनिक रजिस्ट्री मॉड्यूल को संबोधित करें।
`<NAMESPACE>/<NAME>/<PROVIDER>` - उदा. `terraform-aws-modules/vpc/aws`। Git टैग वर्ज़न को चलाते हैं।
dev/staging/prod में एक ही मॉड्यूल का पुन: उपयोग करें।
दो पैटर्न: (1) एक रूट कॉन्फ़िग + प्रति-कार्यस्थान `*.tfvars` के साथ वर्कस्पेस। (2) प्रति-पर्यावरण रूट कॉन्फ़िग (`envs/dev/main.tf`, `envs/prod/main.tf`) प्रत्येक साझा मॉड्यूल को कॉल करते हैं। पैटर्न 2 मल्टी-टीम अलगाव के लिए अधिक सामान्य है।
सुनिश्चित करें कि CI ठीक वही लागू करता है जिसकी प्लान में समीक्षा की गई थी, चरणों के बीच कोई ड्रिफ्ट नहीं।
`terraform plan -out=tfplan` प्लान को सहेजता है। फिर `terraform apply tfplan` उस सटीक प्लान को लागू करता है। फिर से प्लान करने से इनकार करने से टाइम-ऑफ़-चेक/टाइम-ऑफ़-यूज़ जोखिम समाप्त हो जाता है।
प्लान आउटपुट सिंबल को डीकोड करें: `+`, `-`, `~`, `-/+`, `<=`.
`+` बनाएं। `-` नष्ट करें। `~` इन-प्लेस अपडेट करें। `-/+` नष्ट करें फिर बनाएं (बदलें)। `<=` पढ़ें (डेटा स्रोत)। रिप्लेस सिंबल का मतलब है कि एक `forces replacement` विशेषता बदल गई है।
कॉन्फ़िग के बाकी हिस्सों को छुए बिना एक टूटे हुए संसाधन को जल्दी से ठीक करें।
`terraform apply -target=aws_instance.web`। कम उपयोग करें - यह डिपेंडेंसी ट्रैकिंग को बायपास करता है और स्टेट को असंगत छोड़ सकता है। दस्तावेज़ करें कि प्रत्येक `-target` का उपयोग क्यों किया गया था।
क्यों: HashiCorp स्पष्ट रूप से कहता है कि `-target` असाधारण समस्या निवारण के लिए है, न कि सामान्य वर्कफ़्लो के लिए।
एक विशिष्ट संसाधन को फिर से बनाने के लिए मजबूर करें।
`terraform apply -replace=aws_instance.web`। पदावनत `terraform taint` वर्कफ़्लो को बदलता है।
वर्तमान कॉन्फ़िगरेशन में सब कुछ टियर डाउन करें।
`terraform destroy` (या `terraform apply -destroy`)। कॉन्फ़िगरेशन के व्युत्क्रम की योजना बनाता है। `-auto-approve` के बिना पुष्टि की आवश्यकता है।
अन्य संसाधनों को प्रभावित किए बिना एक संसाधन को नष्ट करें।
`terraform destroy -target=aws_instance.web`। अप्लाई के समान `-target` सावधानियां - कम उपयोग करें।
परिवर्तन प्रस्तावित किए बिना ड्रिफ्ट का पता लगाएं।
`terraform plan -refresh-only`। वास्तविक संसाधनों से स्टेट को ताज़ा करता है और अंतर की रिपोर्ट करता है लेकिन कोई संसाधन-संशोधित योजना उत्पन्न नहीं करता है।
क्यों: यह पदावनत स्टैंडअलोन `terraform refresh` कमांड को बदलता है।
संसाधन A संसाधन B से पहले मौजूद होना चाहिए, लेकिन B संसाधन A की विशेषताओं का संदर्भ नहीं देता है।
B में `depends_on = [resource_a.name]` जोड़ें। इसका उपयोग केवल तभी करें जब स्पष्ट विशेषता संदर्भ निर्भरता को व्यक्त न कर सकें (उदाहरण के लिए IAM नीति को EC2 द्वारा उपयोग किए जाने से पहले प्रचारित करना होगा)।
बिना डाउनटाइम के एक संसाधन को बदलें।
`lifecycle { create_before_destroy = true }`। Terraform पहले नया संसाधन बनाता है, संदर्भों को पुनर्निर्देशित करता है, फिर पुराने को नष्ट करता है।
क्यों: डिफ़ॉल्ट नष्ट-फिर-बनाना है जिससे डाउनटाइम होता है। ध्यान दें: आश्रित संसाधनों को भी परिवर्तन का समर्थन करना चाहिए।
प्रोडक्शन डेटाबेस के आकस्मिक `terraform destroy` को रोकें।
`lifecycle { prevent_destroy = true }`। यदि उस संसाधन के लिए नष्ट प्रस्तावित किया जाता है तो `terraform plan` विफल हो जाता है।
क्यों: यह अंतिम-पंक्ति गार्डरेल है - यह `terraform state rm` के बाद नष्ट होने से रक्षा नहीं करता है।
एप्लिकेशन रनटाइम पर एक टैग सेट करता है जिसे Terraform बार-बार revert करता रहता है।
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`। Terraform उन विशेषताओं पर ड्रिफ्ट को अनदेखा करता है।
जब भी संबंधित लॉन्च टेम्प्लेट बदलता है (EC2 को सीधे संशोधित किए बिना) तो एक EC2 इंस्टेंस को बदलें।
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+)। जब भी कोई सूचीबद्ध मान बदलता है तो इंस्टेंस को बदला जाता है।
CI/CD पाइपलाइन एक सफल प्लान जॉब के बाद लागू होती है; कीबोर्ड पर कोई इंसान नहीं।
`terraform apply -auto-approve` इंटरैक्टिव पुष्टि को छोड़ देता है। CI को नियतात्मक बनाने के लिए एक सहेजी गई प्लान फ़ाइल (`terraform apply tfplan`) के साथ मिलाएं।
क्लाउड प्रोवाइडर Terraform को रेट-लिमिट करता है; कई संसाधन निर्माण रुक-रुक कर विफल हो रहे हैं।
`terraform apply -parallelism=5` (डिफ़ॉल्ट 10) समवर्ती संसाधन संचालन को सीमित करता है।
दो संसाधनों की एक-दूसरे पर कोई निर्भरता नहीं है।
Terraform उन्हें समानांतर में बनाता है। DAG केवल संदर्भ किनारों के साथ अनुक्रमण को लागू करता है।
क्यों: समान DAG गहराई पर संसाधन `-parallelism` तक समवर्ती रूप से चलते हैं।
`terraform.tfvars`, `TF_VAR_region` env, और `-var=region=...` CLI फ्लैग में परिभाषित वेरिएबल।
उच्चतम जीत: CLI `-var` / `-var-file` > `*.auto.tfvars` (लेक्सिकल ऑर्डर) > `terraform.tfvars` > `TF_VAR_*` env > वेरिएबल डिफ़ॉल्ट।
रहस्यों को git में चेक किए बिना पर्यावरण-विशिष्ट वेरिएबल मान पास करें।
`terraform apply -var-file=prod.tfvars`। `*.auto.tfvars` फ़ाइलें स्वचालित रूप से लोड होती हैं। `terraform.tfvars` भी स्वचालित रूप से लोड होता है।
नष्ट/पुनर्निर्माण के बिना HCL में एक संसाधन का नाम/पथ बदलें।
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+)। PR प्लान में समीक्ष्य योग्य; एड-हॉक `terraform state mv` को बदलता है।
क्यों: HCL में रहता है, वर्ज़न-नियंत्रित, सहयोगियों के बीच आइडमपोटेंट। `state mv` एक वन-शॉट CLI साइड इफेक्ट है।
एक संसाधन को नष्ट किए बिना कॉन्फ़िगरेशन से हटा दें।
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+)। एड-हॉक `terraform state rm` को बदलता है। नष्ट करने के लिए भी `destroy = true` सेट करें।
CI को यह जानने की आवश्यकता है कि प्लान में टेक्स्ट को पार्स किए बिना कोई बदलाव है या नहीं।
`terraform plan -detailed-exitcode`। 0 = कोई बदलाव नहीं, 1 = त्रुटि, 2 = बदलाव मौजूद। "प्लान-ओनली" PR जॉब्स को चलाता है।
स्टेट में वास्तव में क्या होता है?
संसाधन पता → क्लाउड संसाधन ID मैपिंग, विशेषता स्नैपशॉट, डिपेंडेंसी ग्राफ़ मेटाडेटा, और मॉड्यूल/प्रोवाइडर संदर्भ। डिफ्स की योजना बनाने और ड्रिफ्ट का पता लगाने के लिए उपयोग किया जाता है।
स्थानीय रूप से प्रोटोटाइप करने वाला एकल इंजीनियर - क्या स्थानीय स्टेट ठीक है?
एकल थ्रोअवे काम के लिए हाँ। Terraform कॉन्फ़िग के बगल में `terraform.tfstate` लिखता है। जैसे ही कोई दूसरा व्यक्ति, CI रनर, या प्रोडक्शन पर्यावरण शामिल होता है, रिमोट बैकएंड पर स्विच करें।
टीम को इंजीनियरों के बीच साझा स्टेट की आवश्यकता है, जिसमें लॉकिंग + वर्ज़निंग, AWS-होस्टेड हो।
S3 बैकएंड। `bucket`, `key`, `region` कॉन्फ़िगर करें। स्टेट लॉकिंग के लिए `dynamodb_table` जोड़ें। बकेट वर्ज़निंग + SSE-KMS सर्वर-साइड एन्क्रिप्शन सक्षम करें।
क्यों: S3 + DynamoDB कैनॉनिकल AWS-होस्टेड रिमोट बैकएंड है। वर्ज़निंग भ्रष्ट या गलती से ओवरराइट की गई स्टेट से ठीक हो जाती है।
CI में कोई स्टैटिक क्रेडेंशियल के साथ Azure-होस्टेड साझा स्टेट।
बैकएंड टाइप `azurerm`। `use_msi = true` (Managed Identity) या `use_oidc = true` सेट करें ताकि रनर अपनी पहचान के माध्यम से प्रमाणित हो सके। नेटिव ब्लब लीज लॉकिंग को संभालता है।
ऑब्जेक्ट वर्ज़निंग के साथ GCP-होस्टेड साझा स्टेट।
बैकएंड टाइप `gcs`। `bucket` + `prefix` कॉन्फ़िगर करें। GCS में बिल्ट-इन ऑब्जेक्ट जेनरेशन (वर्ज़निंग) है; GCS ऑब्जेक्ट लॉक के माध्यम से लॉकिंग।
दो इंजीनियर एक साथ एक ही S3-समर्थित स्टेट के विरुद्ध अप्लाई चलाते हैं।
DynamoDB लॉक टेबल समवर्ती राइट्स को रोकता है। पहला लॉक प्राप्त करता है, दूसरा `state lock failed` त्रुटि देखता है और यदि बासी है तो प्रतीक्षा करनी चाहिए या `force-unlock` करना चाहिए।
क्यों: DynamoDB के बिना, समवर्ती अप्लाई S3 स्टेट फ़ाइल को भ्रष्ट कर सकते हैं।
HCP Terraform - क्या मुझे DynamoDB कॉन्फ़िगर करना होगा?
नहीं। HCP Terraform स्टेट, लॉकिंग और एन्क्रिप्शन को नेटिव रूप से संभालता है। आप बस एक बैकएंड के बजाय `cloud { ... }` घोषित करते हैं।
स्थानीय स्टेट से S3 बैकएंड में माइग्रेट करें।
`backend "s3"` ब्लॉक जोड़ें। `terraform init -migrate-state` चलाएं। Terraform स्थानीय स्टेट को S3 में कॉपी करता है और पुष्टि के लिए प्रॉम्प्ट करता है।
बैकएंड कॉन्फ़िग बदल गया (जैसे नया बकेट) लेकिन आप मौजूदा स्टेट को माइग्रेट नहीं करना चाहते हैं।
`terraform init -reconfigure`। बैकएंड को फिर से इनिशियलाइज़ करता है और मौजूदा स्थानीय कैश को अनदेखा करता है। जब आप जानबूझकर नए सिरे से शुरू करते हैं तो उपयोग करें।
एक रूट कॉन्फ़िगरेशन के साथ dev / staging / prod का प्रबंधन करें।
वर्कस्पेस - `terraform workspace new staging`, `terraform workspace select prod`। प्रत्येक की अपनी स्टेट फ़ाइल होती है। HCL में `terraform.workspace` के माध्यम से संदर्भ।
क्यों: हल्का विकल्प। वास्तविक अलगाव (विभिन्न IAM, अलग खाते) के लिए, प्रति-पर्यावरण रूट कॉन्फ़िग को प्राथमिकता दें।
स्थानीय बैकएंड वर्कस्पेस स्टेट को कहाँ संग्रहीत करता है?
`default` वर्कस्पेस → प्रोजेक्ट रूट में `terraform.tfstate`। अन्य वर्कस्पेस → `terraform.tfstate.d/<NAME>/terraform.tfstate`।
staging संसाधन मौजूद होने पर `terraform workspace select prod` चलाएं।
staging संसाधनों पर कोई प्रभाव नहीं पड़ता है। वर्कस्पेस स्विच करने से केवल यह बदलता है कि Terraform अगली कौन सी स्टेट फ़ाइल पढ़ता है - यह एक स्थानीय पॉइंटर परिवर्तन है।
उपलब्ध वर्कस्पेस और सक्रिय वर्कस्पेस देखें।
`terraform workspace list` (एस्ट्रिस्क वर्तमान को चिह्नित करता है)। `terraform workspace show` केवल वर्तमान नाम प्रिंट करता है।
सुरक्षा टीम पूछती है कि Terraform स्टेट में RDS पासवर्ड को कैसे संभालता है।
संवेदनशील मान स्टेट में **प्लेनटेक्स्ट** के रूप में संग्रहीत होते हैं। शमन: बैकएंड को रेस्ट पर एन्क्रिप्ट करें (S3 SSE-KMS, HCP नेटिव), स्टेट बकेट तक IAM एक्सेस को प्रतिबंधित करें, और जब संभव हो तो Terraform में सीक्रेट्स डालने से बचें।
क्यों: `sensitive = true` फ्लैग केवल CLI आउटपुट से मानों को छुपाता है, स्टेट से नहीं।
अनुपालन के लिए स्टेट पर एन्क्रिप्शन-एट-रेस्ट की आवश्यकता होती है।
S3: बकेट पर SSE-KMS सक्षम करें। Azure: स्टोरेज अकाउंट एन्क्रिप्शन (डिफ़ॉल्ट ON)। GCS: ग्राहक-प्रबंधित एन्क्रिप्शन कुंजी। HCP Terraform: रेस्ट पर नेटिव रूप से एन्क्रिप्टेड।
इंजीनियर ने गलती से prod के विरुद्ध `terraform destroy` चलाया। स्टेट अब खाली है।
S3 वर्ज़निंग से स्टेट फ़ाइल के पिछले वर्ज़न को पुनर्स्थापित करें, फिर `terraform plan` चलाएं यह देखने के लिए कि Terraform अब क्या मानता है कि बनाने/आयात करने की आवश्यकता है। नष्ट किए गए संसाधनों के लिए क्लाउड-साइड पुनर्स्थापना (स्नैपशॉट, `aws backup`) के साथ मिलाएं।
स्टेट फ़ाइल गलत दिखती है; इसे सीधे संपादित करने का मन करता है।
न करें। `terraform state` सबकमांड (`mv`, `rm`, `replace-provider`, `pull`, `push`) का उपयोग करें। मैन्युअल JSON संपादन अखंडता जांच को छोड़ देते हैं और वंशावली को भ्रष्ट करते हैं।
कच्चे रिमोट स्टेट JSON का निरीक्षण करें, या एक पुनर्प्राप्त स्टेट फ़ाइल को पुश करें।
`terraform state pull` वर्तमान रिमोट स्टेट को stdout पर लिखता है। `terraform state push <file>` दिए गए फ़ाइल के साथ रिमोट को ओवरराइट करता है। पुश विनाशकारी है - पहले बैकअप लें।
स्टेट में उतरे बिना Terraform के माध्यम से एक अस्थायी API टोकन पास करें।
वेरिएबल को `ephemeral = true` (Terraform 1.10+) के रूप में चिह्नित करें। एपhemeral मान कभी भी स्टेट या प्लान फ़ाइलों में संग्रहीत नहीं होते हैं। एक मॉड्यूल आउटपुट के माध्यम से निर्यात करने के लिए, आउटपुट को भी `ephemeral = true` के रूप में चिह्नित करें।
क्यों: `sensitive` CLI में छिपा हुआ है लेकिन स्टेट प्लेनटेक्स्ट में संग्रहीत है। `ephemeral` वास्तव में कभी संग्रहीत नहीं होता है।
एक `sensitive` आर्गुमेंट और एक राइट-ओनली आर्गुमेंट (जैसे `password_wo`) के बीच अंतर।
`sensitive` स्टेट प्लेनटेक्स्ट में संग्रहीत है, केवल CLI में redacted है। राइट-ओनली स्टेट में **कभी नहीं** संग्रहीत होता है। राइट-ओनली विशेषताओं पर परिवर्तनों का पता लगाने के लिए, Terraform एक साथी वर्ज़न फ़ील्ड का उपयोग करता है (जैसे `password_wo_version`)।
स्टेट में एक `count` संसाधन का एक तत्व दिखाएं।
पते को उद्धृत करें: `terraform state show 'aws_instance.web[0]'`। उद्धरणों के बिना, शेल कोष्ठकों की व्याख्या कर सकता है।
विभिन्न टीमों को एक-दूसरे के स्टेट पर कदम रखे बिना स्वतंत्र रूप से काम करने की आवश्यकता है।
प्रति टीम एक स्टेट फ़ाइल (या प्रति टीम प्रति पर्यावरण)। अलग-अलग बैकएंड/बकेट। केवल पढ़ने के लिए दूसरे स्टेट को पढ़ने के लिए `terraform_remote_state` डेटा स्रोत का उपयोग करें।
नेटवर्क टीम VPC का प्रबंधन करती है; ऐप टीम को VPC ID की आवश्यकता है।
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`। आउटपुट को `data.terraform_remote_state.network.outputs.vpc_id` के रूप में संदर्भ दें।
क्यों: केवल पढ़ने के लिए - नेटवर्क टीम का स्टेट लॉक या संशोधित नहीं है।
Terraform 0.13 के विरुद्ध लिखा गया कॉन्फ़िगरेशन; 1.x का उपयोग करना चाहते हैं।
स्टेट फ़ाइलें फॉरवर्ड-संगत हैं: 1.x 0.13 स्टेट पढ़ता है। HashiCorp वृद्धिशील अपग्रेड (0.13 → 0.14 → … → 1.x) की सिफारिश करता है जो स्टेट के विरुद्ध प्रत्येक वर्ज़न को चलाता है।
किसी ने कंसोल के माध्यम से एक सुरक्षा समूह को संशोधित किया; Terraform को या तो फिर से पुष्टि करनी है या नई स्टेट को स्वीकार करना है।
पुनः पुष्टि: `terraform apply` - Terraform कॉन्फ़िगरेशन पर लौटता है। स्वीकार करें: HCL को वास्तविकता से मेल खाने के लिए अपडेट करें, फिर अप्लाई करें (कोई अंतर नहीं)। पहले `terraform plan -refresh-only` के माध्यम से पता लगाएं।
एक वेरिएबल को मजबूती से टाइप करें।
प्रिमिटिव: `string`, `number`, `bool`। संग्रह: `list(<type>)`, `set(<type>)`, `map(<type>)`। संरचनात्मक: `object({...})`, `tuple([...])`। `any` का उपयोग तभी करें जब वास्तव में पॉलीमोर्फिक हो।
`environment` को dev/staging/prod तक प्रतिबंधित करें।
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`। कई `validation` ब्लॉक की अनुमति है; सभी को पास होना चाहिए।
`terraform output` में दिखाई दिए बिना एक डेटाबेस पासवर्ड आउटपुट करें।
`output "db_password" { value = ...; sensitive = true }`। CLI `(sensitive value)` दिखाता है। अभी भी `terraform output db_password` या `-json` के माध्यम से पठनीय (जानबूझकर - स्क्रिप्ट के लिए)।
एक मान को एक बार कंप्यूट करें और इसे कई संसाधनों में पुन: उपयोग करें।
`locals { common_tags = merge(var.tags, { Project = var.project }) }`। `local.common_tags` के रूप में संदर्भ। मॉड्यूल के बाहर से ओवरराइड करने योग्य नहीं।
एक मौजूदा AMI को प्रबंधित किए बिना देखें।
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`। केवल पढ़ने के लिए। विशेषताओं को `data.aws_ami.ubuntu.id` के रूप में संदर्भ दें।
N समान संसाधन बनाएं - `count` या `for_each` चुनें।
`for_each` (मैप या सेट के साथ) जब आइटम की स्थिर पहचान होती है (क्षेत्र के नाम, पर्यावरण कुंजी)। `count` "मुझे N प्रतियां चाहिए, ऑर्डर मायने नहीं रखता, पहचान सिर्फ एक इंडेक्स है" के लिए। `count` के बीच में जोड़ना/हटाना नष्ट/पुनर्निर्माण का कारण बनता है; `for_each` पहचान को संरक्षित करता है।
स्ट्रिंग की सूची में प्रति आइटम एक संसाधन बनाएं।
`for_each = toset(["a", "b", "c"])`। `each.key` और `each.value` दोनों स्ट्रिंग देते हैं। मैप्स के लिए: `for_each = var.users` - `each.key` = मैप कुंजी, `each.value` = मैप मान।
एक परिवर्तनीय संख्या में नेस्टेड ब्लॉक उत्पन्न करें (जैसे ingress नियम)।
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`। `iterator` आर्गुमेंट यदि आवश्यक हो तो iterator का नाम बदल सकता है।
एक `count` संसाधन के सभी इंस्टेंसेस में विशेषताओं की एक सूची प्राप्त करें।
`aws_instance.web[*].id` IDs की एक सूची लौटाता है। `count` और `for_each` के साथ काम करता है (लेकिन `for_each` एक अनऑर्डर मैप उत्पन्न करता है, इसलिए `values(aws_instance.web)[*].id`)।
एक शर्त के आधार पर एक मान सेट करें।
टर्नरी: `var.is_prod ? 5 : 1`। दोनों शाखाओं को समान प्रकार का उत्पादन करना चाहिए।
दो मैप्स को मिलाएं; कुंजी टकराव पर दूसरे के मान जीतते हैं।
`merge(local.defaults, local.overrides)`। सबसे दाहिना मैप जीतता है। टैग कंपोज़िशन के लिए उपयोगी।
कुंजी गुम होने पर डिफ़ॉल्ट के साथ एक मैप मान पढ़ें।
`lookup(var.config, "region", "us-east-1")`। कुंजी मौजूद न होने पर डिफ़ॉल्ट लौटाता है। गहरी वैकल्पिक संरचनाओं के लिए, वैकल्पिक `try()` को प्राथमिकता दें।
नेस्टेड सूचियों को एक फ्लैट सूची में संपीड़ित करें।
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`। सूचियों को पुनरावर्ती रूप से फ्लैट करता है; ऑर्डर को संरक्षित करता है।
एक Terraform मैप को एक IAM नीति दस्तावेज़ में एम्बेड करें।
`jsonencode({Version = "2012-10-17", Statement = [...]})`। एक JSON स्ट्रिंग उत्पन्न करता है। व्युत्क्रम: `jsondecode()`।
वेरिएबल से मानों के साथ एक टेम्पलेटेड उपयोगकर्ता-डेटा स्क्रिप्ट रेंडर करें।
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`। टेम्पलेट `${region}` सिंटैक्स का उपयोग करता है। स्टैटिक रेंडरिंग के लिए नया विकल्प: `file()` + `format()`।
एक VPC रेंज से सबनेट CIDRs को निकालें।
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`। पहला तर्क = पैरेंट, दूसरा = विस्तार करने के लिए बिट्स, तीसरा = सबनेट संख्या।
एक मान पढ़ें जो मौजूद नहीं हो सकता है; डिफ़ॉल्ट पर वापस जाएं।
`try(yamldecode(file("config.yaml")), { defaults = true })`। बाएं से दाएं मूल्यांकन करता है; पहला गैर-त्रुटिपूर्ण एक्सप्रेशन लौटाता है।
एक ग्लोब से मेल खाने वाली फ़ाइलों पर पुनरावृति करें।
`fileset(path.module, "configs/*.json")` पथों का एक सेट लौटाता है। प्रति फ़ाइल एक संसाधन का प्रबंधन करने के लिए `for_each` के साथ मिलाएं।
दो क्षेत्रों में एक ही प्रोवाइडर (जैसे AWS us-east-1 + us-west-2)।
दो `provider "aws" { alias = "..." }` ब्लॉक। संसाधन `provider = aws.us_west` के माध्यम से ऑप्ट इन करते हैं। मॉड्यूल `configuration_aliases` के माध्यम से उपनाम स्वीकार करते हैं।
एक नए बनाए गए VM पर एक शेल कमांड चलाएं।
एक संसाधन के अंदर `remote-exec` प्रोविज़नर। अंतिम-उपाय उपकरण - क्लाउड-इनिट, उपयोगकर्ता डेटा, या कॉन्फ़िगरेशन प्रबंधन को प्राथमिकता दें। प्रोविज़नर स्टेट में ट्रैक नहीं किए जाते हैं और ड्रिफ्ट पर फिर से नहीं चलते हैं।
एक कमांड चलाएं जो क्लाउड संसाधन से संबंधित नहीं है (जैसे CLI इनवोकेशन)।
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`। `triggers` बदलने पर फिर से चलता है।
बिना अप्लाई को रोके रनटाइम इनवेरिएंट (जैसे स्वास्थ्य एंडपॉइंट 200 लौटाता है) को लगातार सत्यापित करें।
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`। प्लान/अप्लाई पर चलता है; विफलता एक चेतावनी है, कोई हार्ड त्रुटि नहीं।
क्यों: `check` स्कोप किए गए डेटा स्रोतों की अनुमति देता है जो केवल चेक के अंदर उपयोग करने योग्य हैं। `precondition`/`postcondition` प्लान/अप्लाई पर हार्ड त्रुटियां हैं।
यदि एक AMI बहुत पुराना है तो प्लान को विफल करें।
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`। हार्ड विफल, उपयुक्त के रूप में पहले/बाद में मूल्यांकन किया गया।
एक निश्चित-आकार के स्थितिगत मान के साथ वेरिएबल।
`type = tuple([string, number, bool])` को ठीक तीन तत्वों की आवश्यकता होती है। एक सूची से अलग (सजातीय, परिवर्तनीय लंबाई)।
एक संरचित इनपुट को मजबूती से टाइप करें (जैसे `database = { instance_class = string, allocated_storage = number }`)।
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`। `optional(<type>, <default>)` विशेषताओं को वैकल्पिक बनाता है।
`*.tfvars` फ़ाइलें कैसे लोड होती हैं?
`terraform.tfvars` और `*.auto.tfvars` स्वचालित रूप से लोड होते हैं (`auto` के लिए लेक्सिकल ऑर्डर)। अन्य नामों के लिए `-var-file=path.tfvars` की आवश्यकता होती है।
एक Terraform मॉड्यूल के लिए स्वचालित परीक्षण लिखें।
`.tftest.hcl` फ़ाइलें `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }` के साथ। `command = plan` में कोई साइड-इफेक्ट नहीं होता है; `command = apply` वास्तव में संसाधन बनाता है।
परीक्षण चलाने में वेरिएबल पास करें।
फ़ाइल-स्तर `variables { ... }` ब्लॉक सभी रन पर लागू होता है। प्रति-रन `variables { ... }` केवल उस रन के लिए ओवरराइड करता है।
HCP Terraform में एक वर्कस्पेस निष्पादन मोड चुनें।
VCS-संचालित (git पुश पर ऑटो-प्लान, सबसे आम)। CLI-संचालित (डेवलपर स्थानीय रूप से `terraform plan/apply` चलाता है, HCP स्टेट रखता है)। API-संचालित (API द्वारा ट्रिगर किए गए Terraform रन, ऑटोमेशन/CD सिस्टम द्वारा उपयोग किए जाते हैं)।
एक HCP Terraform रन में चरणों का क्रम।
प्लान → लागत अनुमान (यदि सक्षम हो) → नीति जांच (Sentinel/OPA) → मैन्युअल या ऑटो-अप्लाई। अनिवार्य नीति विफलताएं या रन-टास्क विफलताएं पाइपलाइन को रोक देती हैं।
यह सुनिश्चित करें कि सभी S3 बकेट एन्क्रिप्टेड हैं, उल्लंघन होने पर अप्लाई को ब्लॉक करें।
हार्ड-अनिवार्य प्रवर्तन के साथ Sentinel नीति। प्लान का निरीक्षण करता है; विफलता अप्लाई को ब्लॉक करती है। सॉफ्ट-अनिवार्य व्यवस्थापक ओवरराइड की अनुमति देता है। सलाहकारी लॉग लेकिन कभी ब्लॉक नहीं करता।
HCP Terraform रन पाइपलाइन में एक तृतीय-पक्ष सुरक्षा स्कैनर को एकीकृत करें।
पोस्ट-प्लान चरण में रन टास्क। HCP प्लान को आपके एंडपॉइंट पर POST करता है; एंडपॉइंट पास/फेल का जवाब देता है। अनिवार्य प्रवर्तन विफलता पर अप्लाई को ब्लॉक करता है; सलाहकारी केवल चेतावनी देता है।
मर्ज करने से पहले एक पुल रिक्वेस्ट के प्रभाव को दिखाएं।
speculative प्लान PRs (या शाखाओं) पर चलते हैं, परिणामों को PR पर वापस कमेंट करते हैं, और कभी लागू नहीं होते हैं। VCS इंटीग्रेशन सक्षम होने पर स्वचालित रूप से ट्रिगर होते हैं।
HCP Terraform वेरिएबल में AWS एक्सेस कीज़ को स्टैटिक सीक्रेट्स के रूप में संग्रहीत करने से बचें।
डायनामिक प्रोवाइडर क्रेडेंशियल। HCP Terraform OIDC ट्रस्ट के माध्यम से AWS/Azure/GCP से कम-समय के क्रेडेंशियल का अनुरोध करता है। कोई स्टैटिक कीज़ नहीं; प्रति-रन पहचान; ऑडिट-अनुकूल।
क्यों: स्टैटिक कीज़ लीक होती हैं। OIDC ट्रस्ट क्रेडेंशियल को वर्कस्पेस + रन से बांधता है, एक घंटे के भीतर समाप्त हो जाता है।
कई वर्कस्पेस में समान प्रोवाइडर क्रेडेंशियल साझा करें।
वेरिएबल सेट। संगठन/प्रोजेक्ट स्तर पर एक बार परिभाषित करें, कई वर्कस्पेस से संलग्न करें। प्रति-वर्कस्पेस संपादन के बिना अपडेट प्रसारित होते हैं।
HCP Terraform में डिफ़ॉल्ट प्रोजेक्ट क्या है?
एक बिल्ट-इन प्रोजेक्ट जो हर संगठन में मौजूद होता है और इसे हटाया नहीं जा सकता है (नाम बदलने की अनुमति है)। सभी वर्कस्पेस इसमें होते हैं जब तक कि उन्हें स्पष्ट रूप से किसी अन्य प्रोजेक्ट को असाइन न किया जाए।
जब भी एक अपस्ट्रीम वर्कस्पेस एक सफल अप्लाई पूरा करता है तो डाउनस्ट्रीम वर्कस्पेस को अप्लाई करें।
रन ट्रिगर्स। आश्रित वर्कस्पेस पर स्रोत वर्कस्पेस कॉन्फ़िगर करें; HCP प्रत्येक सफल अपस्ट्रीम अप्लाई के बाद आश्रित पर एक रन कतारबद्ध करता है।