Terraform 0.11 - Module Usage

मॉड्यूल उपयोग




terraform

मॉड्यूल उपयोग

Terraform में बाल मॉड्यूल का उपयोग संसाधनों को परिभाषित करने के समान है:

module "consul" {
  source  = "hashicorp/consul/aws"
  servers = 3
}

आप मॉड्यूल कॉन्फ़िगरेशन अनुभाग में मॉड्यूल को कॉन्फ़िगर करने के लिए पूर्ण दस्तावेज़ देख सकते हैं।

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

स्रोत टेराफॉर्म को बताता है कि क्या बनाना है। इस उदाहरण में, हम Terraform रजिस्ट्री से AWS के लिए कौंसल मॉड्यूल को तुरंत भेजते हैं । अन्य स्रोत प्रकार समर्थित हैं, जैसा कि निम्नलिखित अनुभाग में वर्णित है।

एक संसाधन की तरह, मॉड्यूल से संबंधित संसाधनों को नष्ट करने के लिए एक मॉड्यूल का कॉन्फ़िगरेशन हटाया जा सकता है।

स्रोत

एक मॉड्यूल के लिए केवल आवश्यक कॉन्फ़िगरेशन कुंजी source पैरामीटर है। इसका मान टेराफॉर्म को बताता है कि मॉड्यूल के स्रोत कोड को कहां से डाउनलोड करना है। टेराफॉर्म विभिन्न प्रकार के मॉड्यूल स्रोतों के समर्थन के साथ आता है।

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

उपर्युक्त उदाहरण में उपयोग किए गए hashicorp/consul/aws पथ जैसे सरल स्लैश-पृथक पथ का उपयोग करके रजिस्ट्री मॉड्यूल निर्दिष्ट किए जाते हैं। प्रत्येक रजिस्ट्री मॉड्यूल के लिए पूर्ण स्रोत स्ट्रिंग को रजिस्ट्री वेबसाइट से पाया जा सकता है।

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

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

जब कोई कॉन्फ़िगरेशन मॉड्यूल का उपयोग करता है, तो उन्हें पहले terraform init चलाकर स्थापित किया जाना चाहिए:

$ terraform init

यह कमांड किसी भी मॉड्यूल को डाउनलोड करेगा जिसे पहले से अपडेट नहीं किया गया है, साथ ही अन्य टेराफॉर्म वर्किंग डायरेक्टरी इनिशियलाइज़ेशन जैसे कि प्रोवाइडर्स इंस्टॉल करना।

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

मॉड्यूल संस्करण

हम अप्रत्याशित या अवांछित परिवर्तनों से बचने के लिए प्रत्येक बाहरी मॉड्यूल के लिए स्वीकार्य संस्करण संख्याओं को स्पष्ट रूप से विवश करने की सलाह देते हैं।

version को निर्दिष्ट करने के लिए module ब्लॉक में version विशेषता का उपयोग करें:

module "consul" {
  source  = "hashicorp/consul/aws"
  version = "0.0.5"

  servers = 3
}

version विशेषता मूल्य या तो एक स्पष्ट संस्करण या एक संस्करण बाधा अभिव्यक्ति हो सकता है। विभिन्न अभिव्यक्तियाँ निम्नलिखित सिंटैक्स का उपयोग उन संस्करणों की एक श्रृंखला को निर्दिष्ट करने के लिए करती हैं जो स्वीकार्य हैं:

  • >= 1.2.0 : संस्करण 1.2.0 या नया
  • <= 1.2.0 : संस्करण 1.2.0 या पुराने
  • ~> 1.2.0 : कोई भी गैर-बीटा संस्करण >= 1.2.0 और < 1.3.0 , जैसे 1.2.X
  • ~> 1.2 : कोई भी गैर-बीटा संस्करण >= 1.2.0 और < 2.0.0 , जैसे 1.XY
  • >= 1.0.0, <= 2.0.0 : 1.0.0 और 2.0.0 के बीच कोई भी संस्करण शामिल नहीं है

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

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

संस्करण की कमी केवल एक मॉड्यूल रजिस्ट्री से स्थापित मॉड्यूल के लिए समर्थित है, जैसे कि टेराफॉर्म रजिस्ट्री या टेराफॉर्म एंटरप्राइज की निजी मॉड्यूल रजिस्ट्री । अन्य मॉड्यूल स्रोत स्रोत स्ट्रिंग के भीतर अपने स्वयं के संस्करण तंत्र प्रदान कर सकते हैं, या बिल्कुल भी संस्करणों का समर्थन नहीं कर सकते हैं। विशेष रूप से, स्थानीय फ़ाइल पथों से प्राप्त मॉड्यूल version समर्थन नहीं करते हैं; चूँकि वे एक ही स्रोत रिपॉजिटरी से लोड होते हैं, वे हमेशा अपने कॉलर के समान संस्करण साझा करते हैं।

विन्यास

एक module ब्लॉक में उपयोग किए गए तर्क, जैसे ऊपर servers पैरामीटर, मॉड्यूल के भीतर variables अनुरूप हैं। इसलिए आप इसके स्रोत का निरीक्षण करके एक मॉड्यूल के लिए सभी उपलब्ध चर की खोज कर सकते हैं।

विशेष तर्क source , version और providers अपवाद हैं। ये टेराफॉर्म द्वारा विशेष प्रयोजनों के लिए उपयोग किए जाते हैं और इसलिए इसे किसी मॉड्यूल के भीतर चर नामों के रूप में उपयोग नहीं किया जाना चाहिए।

आउटपुट

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

resource "aws_instance" "client" {
  ami               = "ami-408c7f28"
  instance_type     = "t1.micro"
  availability_zone = "${module.consul.server_availability_zone}"
}

यह जानबूझकर संसाधन विशेषताओं तक पहुंचने के समान है। एक संसाधन विशेषता को संदर्भित करने के बजाय, हालांकि, इस मामले में अभिव्यक्ति मॉड्यूल के आउटपुट का संदर्भ देती है।

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

मॉड्यूल के भीतर प्रदाता

कई मॉड्यूल के साथ एक कॉन्फ़िगरेशन में, प्रदाता कॉन्फ़िगरेशन के साथ संसाधन कैसे जुड़े हैं, इसके लिए कुछ विशेष विचार हैं।

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

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

सभी मामलों में यह केवल रूट मॉड्यूल में स्पष्ट प्रदाता कॉन्फ़िगरेशन रखने और उन्हें (चाहे अंतर्निहित या स्पष्ट रूप से) नीचे उतरने वाले मॉड्यूल को रखने की सिफारिश की जाती है। यह प्रदाता के विन्यास को "लुप्त" होने से बचाता है जब वंशज मॉड्यूल को विन्यास से हटा दिया जाता है। यह एक कॉन्फ़िगरेशन के उपयोगकर्ता को यह निर्धारित करने की अनुमति देता है कि कौन से प्रदाताओं को केवल रूट मॉड्यूल का निरीक्षण करके क्रेडेंशियल्स की आवश्यकता है।

प्रदाता कॉन्फ़िगरेशन संबंधित संसाधनों पर सभी कार्यों के लिए उपयोग किया जाता है, जिसमें दूरस्थ वस्तुओं को नष्ट करना और ताज़ा स्थिति शामिल है। टेराफॉर्म अपने राज्य के हिस्से के रूप में, प्रदाता कॉन्फ़िगरेशन का संदर्भ रखता है, जिसका उपयोग हाल ही में प्रत्येक संसाधन में परिवर्तन लागू करने के लिए किया गया था। जब कॉन्फ़िगरेशन से एक resource ब्लॉक निकाल दिया जाता है, तो राज्य में इस रिकॉर्ड का उपयोग उपयुक्त कॉन्फ़िगरेशन का पता लगाने के लिए किया जाता है क्योंकि संसाधन का provider तर्क (यदि कोई हो) अब कॉन्फ़िगरेशन में मौजूद नहीं है।

परिणामस्वरूप, यह आवश्यक है कि किसी विशेष प्रदाता कॉन्फ़िगरेशन के लिए बनाए गए सभी संसाधनों को तब तक नष्ट कर दिया जाए जब तक कि प्रदाता कॉन्फ़िगरेशन को हटा नहीं दिया जाता है, जब तक कि संबंधित संसाधनों को पहले एक अलग प्रदाता कॉन्फ़िगरेशन का उपयोग करने के लिए पुनः कॉन्फ़िगर नहीं किया जाता है।

निहित प्रदाता विरासत

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

उदाहरण के लिए, रूट मॉड्यूल में केवल एक provider ब्लॉक और एक module ब्लॉक शामिल हो सकता है ताकि एक बच्चे के मॉड्यूल को त्वरित किया जा सके:

provider "aws" {
  region = "us-west-1"
}

module "child" {
  source = "./child"
}

बाल मॉड्यूल तब इस प्रदाता से किसी भी संसाधन का उपयोग कर सकता है जिसमें कोई और प्रदाता कॉन्फ़िगरेशन आवश्यक नहीं है:

resource "aws_s3_bucket" "example" {
  bucket = "provider-inherit-example"
}

इस दृष्टिकोण की सिफारिश आम मामले में की जाती है, जहां पूरे कॉन्फ़िगरेशन के लिए प्रत्येक प्रदाता के लिए केवल एकल कॉन्फ़िगरेशन की आवश्यकता होती है।

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

पासिंग प्रोस्पेडर्स स्पष्ट रूप से

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

# The default "aws" configuration is used for AWS resources in the root
# module where no explicit provider instance is selected.
provider "aws" {
  region = "us-west-1"
}

# A non-default, or "aliased" configuration is also defined for a different
# region.
provider "aws" {
  alias  = "usw2"
  region = "us-west-2"
}

# An example child module is instantiated with the _aliased_ configuration,
# so any AWS resources it defines will use the us-west-2 region.
module "example" {
  source    = "./example"
  providers = {
    aws = "aws.usw2"
  }
}

module ब्लॉक के भीतर provider तर्क एक संसाधन के भीतर provider तर्क के समान है, जैसा कि कई प्रदाता उदाहरणों के लिए वर्णित है, लेकिन एक एकल स्ट्रिंग के बजाय एक नक्शा है क्योंकि एक मॉड्यूल में कई अलग-अलग प्रदाताओं से संसाधन हो सकते हैं।

एक बार जब providers तर्क का उपयोग module ब्लॉक में किया जाता है, तो यह डिफ़ॉल्ट इनहेरिटेंस व्यवहार के सभी को ओवरराइड करता है, इसलिए सभी आवश्यक प्रदाताओं के लिए मैपिंग गणना करना आवश्यक है। यह भ्रम और आश्चर्य से बचने के लिए है जिसका परिणाम निहित और स्पष्ट प्रदाता के मिश्रण के रूप में हो सकता है।

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

provider "aws" {
  alias  = "usw1"
  region = "us-west-1"
}

provider "aws" {
  alias  = "usw2"
  region = "us-west-2"
}

module "tunnel" {
  source    = "./tunnel"
  providers = {
    aws.src = "aws.usw1"
    aws.dst = "aws.usw2"
  }
}

providers नक्शे में, चाबियाँ बच्चे मॉड्यूल द्वारा अपेक्षित प्रदाता नाम हैं, जबकि वर्तमान मॉड्यूल में संबंधित कॉन्फ़िगरेशन के नाम मान हैं। उपनिर्देशिका ./tunnel में निम्नलिखित की तरह प्रॉक्सी कॉन्फ़िगरेशन ब्लॉक होना चाहिए, यह घोषित करने के लिए कि इसके लिए इनको अभिभावकों के module ब्लॉक में providers ब्लॉक से पास करने के लिए कॉन्फ़िगरेशन की आवश्यकता होती है:

provider "aws" {
  alias = "src"
}

provider "aws" {
  alias = "dst"
}

प्रत्येक संसाधन को तब अपने provider विशेषता को "aws.src" या "aws.dst" दोनों में से किसी एक को चुनने के लिए सेट करना चाहिए।

इस समय डिफ़ॉल्ट (अन-एलाइड) प्रदाता कॉन्फ़िगरेशन के लिए भी एक स्पष्ट प्रॉक्सी कॉन्फ़िगरेशन ब्लॉक लिखना आवश्यक है, जब उन्हें एक स्पष्ट providers ब्लॉक के माध्यम से पारित किया जाएगा:

provider "aws" {
}

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

एक मॉड्यूल के कई उदाहरण

एक विशेष मॉड्यूल स्रोत को कई बार त्वरित किया जा सकता है:

# my_buckets.tf

module "assets_bucket" {
  source = "./publish_bucket"
  name   = "assets"
}

module "media_bucket" {
  source = "./publish_bucket"
  name   = "media"
}
# publish_bucket/bucket-and-cloudfront.tf

variable "name" {} # this is the input parameter of the module

resource "aws_s3_bucket" "example" {
  # ...
}

resource "aws_iam_user" "deploy_user" {
  # ...
}

यह उदाहरण ./publish_bucket उपनिर्देशिका में एक स्थानीय चाइल्ड मॉड्यूल को परिभाषित करता है। उस मॉड्यूल में S3 बाल्टी बनाने के लिए कॉन्फ़िगरेशन है। मॉड्यूल बाल्टी को लपेटता है और एक बाल्टी को कॉन्फ़िगर करने के लिए आवश्यक सभी अन्य कार्यान्वयन विवरण।

तब हम अपने कॉन्फ़िगरेशन में कई बार मॉड्यूल को एक अद्वितीय नाम - यहाँ module "assets_bucket" और module "media_bucket" - को एक ही source मान निर्दिष्ट करते हुए module "media_bucket"

चाइल्ड मॉड्यूल के संसाधन मॉड्यूल के साथ उपसर्ग किए जाते हैं module.<module-instance-name> जब योजना आउटपुट में और अन्यत्र यूआई में प्रदर्शित किया जाता है। उदाहरण के लिए, ./publish_bucket मॉड्यूल में aws_s3_bucket.example शामिल है, और इसलिए इस मॉड्यूल के दो उदाहरण संसाधन पते मॉड्यूल के साथ S3 बाल्टी संसाधनों का उत्पादन करते हैं module.assets_bucket.aws_s3_bucket.example और module.media_bucket.aws_s3_bucket.example . module.media_bucket.aws_s3_bucket.example । ये पूर्ण पते यूआई के भीतर और कमांड लाइन पर उपयोग किए जाते हैं, लेकिन ऊपर वर्णित एन्कैप्सुलेशन व्यवहार के कारण प्रक्षेप अभिव्यक्ति के भीतर मान्य नहीं हैं।

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

मॉड्यूल के प्रत्येक उदाहरण में वैकल्पिक रूप से अलग-अलग प्रदाता हो सकते हैं जो ऊपर वर्णित providers तर्क का उपयोग करते हैं। यह उन स्थितियों में उपयोगी हो सकता है, उदाहरण के लिए, कई क्षेत्रों या डेटासेन्टर्स में संसाधनों का एक डुप्लिकेट सेट बनाया जाना चाहिए।

UI में सारांश मॉड्यूल

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

उदाहरण के लिए, जो हमने ऊपर बनाया है, उसके समान कॉन्फ़िगरेशन के साथ, डिफ़ॉल्ट ग्राफ़ आउटपुट निम्न जैसा दिखता है:

टेराफॉर्म विस्तारित मॉड्यूल ग्राफ

यदि हम इसके बजाय सेट -module-depth=0 , तो ग्राफ इस तरह दिखेगा:

टेराफॉर्म मॉड्यूल ग्राफ

अन्य कमांड मॉड्यूल के साथ इसी तरह काम करते हैं। ध्यान दें कि -module-depth केवल प्रभावित करती है कि UI में मॉड्यूल कैसे प्रस्तुत किए जाते हैं; यह प्रभावित नहीं करता है कि टेराफ़ॉर्म संचालन द्वारा मॉड्यूल और उनके निहित संसाधन कैसे संसाधित होते हैं।

एक मॉड्यूल के भीतर संसाधनों का दोहन

एक मॉड्यूल के भीतर दागी आदेश का उपयोग विशिष्ट संसाधनों को दागने के लिए किया जा सकता है:

$ terraform taint -module=salt_master aws_instance.salt_master

एक पूरे मॉड्यूल को दागना संभव नहीं है। इसके बजाय, मॉड्यूल के भीतर प्रत्येक संसाधन को अलग से दागी जानी चाहिए।