Terraform 0.11 - Provider Configuration

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




terraform

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

resource के जीवनचक्र के प्रबंधन के लिए टेराफॉर्म में प्रदाता जिम्मेदार हैं: बनाना, पढ़ना, अपडेट करना, हटाना।

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

डिफ़ॉल्ट रूप से, संसाधनों को संसाधन नाम की शुरुआत से मेल करके प्रदाता कॉन्फ़िगरेशन के साथ मिलान किया जाता है। उदाहरण के लिए, vsphere_virtual_machine प्रकार का संसाधन vsphere_virtual_machine नामक प्रदाता से जुड़ा होता है।

यह पृष्ठ मानता है कि आप पहले से ही विन्यास वाक्य रचना से परिचित हैं।

उदाहरण

एक प्रदाता कॉन्फ़िगरेशन निम्न की तरह दिखता है:

provider "aws" {
  access_key = "foo"
  secret_key = "bar"
  region     = "us-east-1"
}

विवरण

एक provider ब्लॉक अपने हेडर में नामित प्रदाता के लिए एक कॉन्फ़िगरेशन का प्रतिनिधित्व करता है। उदाहरण के लिए, provider "aws" ऊपर aws प्रदाता के लिए एक विन्यास है।

ब्लॉक बॉडी ( { } बीच) प्रदाता के लिए कॉन्फ़िगरेशन है। कॉन्फ़िगरेशन प्रकार पर निर्भर है, और प्रत्येक प्रदाता के लिए प्रलेखित है।

तर्क alias और version , यदि मौजूद है, तो ऊपर वर्णित उनकी संबंधित सुविधाओं के लिए टेराफॉर्म कोर द्वारा नियंत्रित विशेष तर्क हैं। अन्य सभी तर्कों को प्रदाता द्वारा ही परिभाषित किया जाता है।

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

प्रारंभ

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

प्रदाता आरंभीकरण terraform init की क्रियाओं में से एक है। इस कमांड को चलाने से उन सभी प्रदाताओं को डाउनलोड और इनिशियलाइज़ किया जा सकेगा जो पहले से इनिशियलाइज़ नहीं हैं।

अधिक जानकारी के लिए, terraform init कमांड देखें

प्रदाता संस्करण

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

जब terraform init प्रदाता संस्करण की बाधाओं के बिना चलाया जाता है, तो यह प्रत्येक प्रदाता के लिए सुझाए गए संस्करण बाधा स्ट्रिंग को प्रिंट करता है:

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.aws: version = "~> 1.0"

सुझाव के अनुसार प्रदाता संस्करण को बाधित करने के लिए, प्रदाता कॉन्फ़िगरेशन ब्लॉक में एक version तर्क जोड़ें:

provider "aws" {
  version = "~> 1.0"

  access_key = "foo"
  secret_key = "bar"
  region     = "us-east-1"
}

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

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 के बीच कोई भी संस्करण शामिल नहीं है

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

कई प्रदाता उदाहरण

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

किसी दिए गए प्रदाता के लिए कई कॉन्फ़िगरेशन शामिल करने के लिए, एक ही प्रदाता के नाम के साथ कई provider ब्लॉक शामिल करें, लेकिन प्रत्येक अतिरिक्त उदाहरण के लिए उपयोग करने के लिए अन्य नाम के लिए alias फ़ील्ड सेट करें। उदाहरण के लिए:

# The default provider configuration
provider "aws" {
  # ...
}

# Additional provider configuration for west coast region
provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

alias सेट के साथ एक provider ब्लॉक को डिफ़ॉल्ट प्रदाता कॉन्फ़िगरेशन के रूप में जाना जाता है। जब alias सेट किया जाता है, तो यह एक अतिरिक्त प्रदाता कॉन्फ़िगरेशन बनाता है। उन प्रदाताओं के लिए जिनके पास आवश्यक कॉन्फ़िगरेशन तर्क नहीं हैं, निहित खाली कॉन्फ़िगरेशन को डिफ़ॉल्ट प्रदाता कॉन्फ़िगरेशन भी माना जाता है।

संसाधन सामान्य रूप से संसाधन प्रकार के नाम से अनुमानित डिफ़ॉल्ट प्रदाता कॉन्फ़िगरेशन से जुड़े होते हैं। उदाहरण के लिए, टाइप aws_instance का एक संसाधन डिफ़ॉल्ट (अन- aws_instance ) aws प्रदाता कॉन्फ़िगरेशन का उपयोग करता है जब तक कि अन्यथा न कहा जाए।

किसी भी resource या data ब्लॉक के भीतर provider तर्क इस डिफ़ॉल्ट व्यवहार को ओवरराइड करता है और एक अतिरिक्त प्रदाता कॉन्फ़िगरेशन को इसके उपनाम का उपयोग करके चयनित करने की अनुमति देता है:

resource "aws_instance" "foo" {
  provider = "aws.west"

  # ...
}

provider तर्क का मूल्य हमेशा प्रदाता नाम और एक उपनाम अवधि से अलग होता है, जैसे कि "aws.west" ऊपर।

प्रदाता कॉन्फ़िगरेशन को मूल मॉड्यूल से एक बाल मॉड्यूल में भी पारित किया जा सकता है, जैसा कि मॉड्यूल के भीतर प्रदाताओं में वर्णित है।

प्रक्षेप

प्रदाता कॉन्फ़िगरेशन गतिशील कॉन्फ़िगरेशन की अनुमति देने के लिए प्रक्षेप सिंटैक्स का उपयोग कर सकते हैं:

provider "aws" {
  region = "${var.aws_region}"
}

प्रति-प्रदाता कॉन्फ़िगरेशन तर्क के लिए इंटरपोलेशन का समर्थन किया जाता है। यह विशेष alias और version तर्क के लिए समर्थित नहीं है।

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

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

तृतीय-पक्ष प्लगइन्स

वर्तमान में Terraform HashiCorp द्वारा वितरित किए गए केवल प्रदाताओं को स्वचालित रूप से स्थापित कर सकता है। मेजबान ऑपरेटिंग सिस्टम के आधार पर निम्नलिखित स्थानों में से एक में अपने प्लगइन निष्पादन योग्य को रखकर तीसरे पक्ष के प्रदाताओं को मैन्युअल रूप से स्थापित किया जा सकता है:

  • विंडोज पर, अपने उपयोगकर्ता के "एप्लिकेशन डेटा" निर्देशिका के नीचे उप-पथ terraform.d/plugins
  • अन्य सभी प्रणालियों पर, उप-पथ में .terraform.d/plugins आपके उपयोगकर्ता के घर निर्देशिका में।

terraform init इस निर्देशिका को प्लगइन इनिशियलाइज़ेशन के दौरान अतिरिक्त प्लग इन के लिए खोजेगा।

प्रदाता प्लगइन्स के लिए नामकरण योजना terraform-provider-NAME_vX.YZ , और Terraform किसी विशेष प्रदाता बाइनरी के नाम और संस्करण को समझने के लिए नाम का उपयोग करता है। तृतीय-पक्ष प्लगइन्स को अक्सर वितरण संग्रह में पहले से सेट एक उपयुक्त फ़ाइल नाम के साथ वितरित किया जाएगा ताकि इसे ऊपर वर्णित प्लगइन निर्देशिका में सीधे निकाला जा सके।

प्रदाता प्लगइन कैश

डिफ़ॉल्ट रूप से, terraform init डाउनलोड प्लग इन को वर्किंग डायरेक्टरी की उपनिर्देशिका में डाउनलोड करता है ताकि प्रत्येक वर्किंग डायरेक्टरी स्व-निहित हो। परिणामस्वरूप, यदि आपके पास कई कॉन्फ़िगरेशन हैं जो एक ही प्रदाता का उपयोग करते हैं तो प्रत्येक कॉन्फ़िगरेशन के लिए इसके प्लगइन की एक अलग प्रतिलिपि डाउनलोड की जाएगी।

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

प्लगइन कैश सक्षम करने के लिए, CLI कॉन्फ़िगरेशन फ़ाइल में plugin_cache_dir सेटिंग का उपयोग करें। उदाहरण के लिए:

# (Note that the CLI configuration file is _not_ the same as the .tf files
#  used to configure infrastructure.)

plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"

Terraform प्लग इन को कैश करने से पहले ही यह निर्देशिका मौजूद होनी चाहिए; Terraform निर्देशिका को स्वयं नहीं बनाएगा।

कृपया ध्यान दें कि विंडोज़ पर पारंपरिक बैकस्लैश ( \ ) के बजाय फ़ॉरवर्ड स्लैश सेपरेटर ( / ) का उपयोग करना आवश्यक है क्योंकि कॉन्फ़िगरेशन फ़ाइल पार्सर एक एस्केप अनुक्रम शुरू करने के लिए बैकस्लैश मानता है।

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

export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"

जब एक प्लगइन कैश डायरेक्टरी को सक्षम किया जाता है, तो terraform init कमांड, मेटाडेटा प्राप्त करने के लिए प्लगइन वितरण सर्वर का उपयोग करेगा, जिसके बारे में प्लगइन्स उपलब्ध हैं, लेकिन एक बार उपयुक्त संस्करण का चयन करने के बाद यह पहले यह देखने के लिए जांच करेगा कि चयनित प्लगइन पहले से उपलब्ध है या नहीं कैश निर्देशिका। यदि ऐसा है, तो पहले से डाउनलोड किए गए प्लगइन बाइनरी का उपयोग किया जाएगा।

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

जब संभव हो, तो Terraform कई निर्देशिकाओं में कैश्ड प्लगइन की एक अलग प्रतिलिपि को संग्रहीत करने से बचने के लिए हार्डलिंक या सिमिलिंक का उपयोग करेगा। वर्तमान में, यह विंडोज़ पर समर्थित नहीं है और इसके बजाय एक प्रति हमेशा बनाई जाती है।

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

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