टेराफॉर्म नुकसान

आइए कुछ कमियों पर प्रकाश डालें, जिनमें लूप, इफ स्टेटमेंट और परिनियोजन तकनीकों से संबंधित, साथ ही अधिक सामान्य मुद्दे भी शामिल हैं जो सामान्य रूप से टेराफॉर्म को प्रभावित करते हैं:

• गिनती और प्रत्येक पैरामीटर की सीमाएं हैं;
• शून्य डाउनटाइम परिनियोजन सीमित करें;
• एक अच्छी योजना भी विफल हो सकती है;
• रिफैक्टरिंग के अपने नुकसान हो सकते हैं;
• आस्थगित सुसंगति सुसंगत है... स्थगन के साथ।

गिनती और for_each पैरामीटर की सीमाएँ हैं

इस अध्याय के उदाहरण लूप और सशर्त तर्क में गिनती पैरामीटर और for_each अभिव्यक्ति का व्यापक उपयोग करते हैं। वे अच्छा प्रदर्शन करते हैं, लेकिन उनकी दो महत्वपूर्ण सीमाएँ हैं जिनके बारे में आपको अवगत होना आवश्यक है।

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

count और for_each किसी भी संसाधन आउटपुट चर का संदर्भ नहीं दे सकते

कल्पना करें कि आपको कई EC2 सर्वर तैनात करने की आवश्यकता है और किसी कारण से आप ASG का उपयोग नहीं करना चाहते हैं। आपका कोड इस प्रकार हो सकता है:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

आइए उन पर एक-एक करके नजर डालें।

चूंकि गिनती पैरामीटर एक स्थिर मान पर सेट है, यह कोड बिना किसी समस्या के काम करेगा: जब आप लागू कमांड चलाएंगे, तो यह तीन EC2 सर्वर बनाएगा। लेकिन क्या होगा यदि आप अपने वर्तमान AWS क्षेत्र के भीतर प्रत्येक उपलब्धता क्षेत्र (AZ) में एक सर्वर तैनात करना चाहते हैं? आप अपने कोड को aws_available_zones डेटा स्रोत से ज़ोन की एक सूची लोड कर सकते हैं और फिर प्रत्येक के माध्यम से लूप कर सकते हैं और गिनती पैरामीटर और सरणी इंडेक्स एक्सेस का उपयोग करके इसमें एक EC2 सर्वर बना सकते हैं:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

यह कोड भी ठीक काम करेगा, क्योंकि गिनती पैरामीटर बिना किसी समस्या के डेटा स्रोतों को संदर्भित कर सकता है। लेकिन क्या होगा यदि आपके द्वारा बनाए जाने वाले सर्वरों की संख्या किसी संसाधन के आउटपुट पर निर्भर करती है? इसे प्रदर्शित करने के लिए, सबसे आसान तरीका है यादृच्छिक_पूर्णांक संसाधन का उपयोग करना, जो, जैसा कि नाम से पता चलता है, एक यादृच्छिक पूर्णांक देता है:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

यह कोड 1 और 3 के बीच एक यादृच्छिक संख्या उत्पन्न करता है। आइए देखें कि यदि हम aws_instance संसाधन के गिनती पैरामीटर में इस संसाधन के आउटपुट का उपयोग करने का प्रयास करते हैं तो क्या होता है:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

यदि आप इस कोड पर टेराफ़ॉर्म योजना चलाते हैं, तो आपको निम्न त्रुटि मिलेगी:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

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

मॉड्यूल कॉन्फ़िगरेशन में गिनती और for_each का उपयोग नहीं किया जा सकता है

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

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

यह कोड वेबसर्वर-क्लस्टर संसाधन की तीन प्रतियां बनाने के लिए मॉड्यूल के अंदर गिनती का उपयोग करने का प्रयास करता है। या हो सकता है कि आप किसी मॉड्यूल को उसके गिनती पैरामीटर को 0 पर सेट करके कुछ बूलियन स्थिति के आधार पर कनेक्ट करना वैकल्पिक बनाना चाहें। यह उचित कोड की तरह लग सकता है, लेकिन टेराफॉर्म योजना चलाते समय आपको यह त्रुटि मिलेगी:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

दुर्भाग्य से, टेराफॉर्म 0.12.6 के अनुसार, मॉड्यूल संसाधन में गिनती या for_each का उपयोग समर्थित नहीं है। टेराफ़ॉर्म 0.12 रिलीज़ नोट्स (http://bit.ly/3257bv4) के अनुसार, HashiCorp भविष्य में इस क्षमता को जोड़ने की योजना बना रहा है, इसलिए जब आप इस पुस्तक को पढ़ते हैं तो उसके आधार पर, यह पहले से ही उपलब्ध हो सकता है। निश्चित रूप से पता लगाने के लिए, टेराफॉर्म चेंजलॉग यहां पढ़ें.

शून्य डाउनटाइम परिनियोजन की सीमाएँ

ASG के साथ संयोजन में create_before_destroy ब्लॉक का उपयोग शून्य-डाउनटाइम परिनियोजन बनाने के लिए एक बढ़िया समाधान है, एक चेतावनी को छोड़कर: ऑटोस्केलिंग नियम समर्थित नहीं हैं। या अधिक सटीक होने के लिए, यह प्रत्येक परिनियोजन पर ASG आकार को वापस min_size पर रीसेट कर देता है, जो एक समस्या हो सकती है यदि आप चल रहे सर्वरों की संख्या बढ़ाने के लिए ऑटोस्केलिंग नियमों का उपयोग कर रहे थे।

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

इस सीमा को कई तरीकों से टाला जा सकता है।

• aws_autoscaleing_schedule में पुनरावृत्ति पैरामीटर को 0 9 * * * ("सुबह 9 बजे चलाएं") से 0-59 9-17 * * * ("सुबह 9 बजे से शाम 5 बजे तक हर मिनट चलाएं") में बदलें। यदि एएसजी के पास पहले से ही दस सर्वर हैं, तो इस ऑटोस्केलिंग नियम को दोबारा चलाने से कुछ भी नहीं बदलेगा, जो हम चाहते हैं। लेकिन यदि एएसजी को हाल ही में तैनात किया गया है, तो यह नियम सुनिश्चित करेगा कि अधिकतम एक मिनट में इसके सर्वर की संख्या दस तक पहुंच जाएगी। यह पूरी तरह से सुरुचिपूर्ण दृष्टिकोण नहीं है, और दस से दो सर्वर और पीछे की बड़ी छलांग भी उपयोगकर्ताओं के लिए समस्याएं पैदा कर सकती है।
• एक कस्टम स्क्रिप्ट बनाएं जो एएसजी में सक्रिय सर्वरों की संख्या निर्धारित करने के लिए एडब्ल्यूएस एपीआई का उपयोग करती है, इसे बाहरी डेटा स्रोत का उपयोग करके कॉल करें (पृष्ठ 249 पर "बाहरी डेटा स्रोत" देखें), और एएसजी के वांछित_क्षमता पैरामीटर को दिए गए मान पर सेट करें लिपि। इस तरह, प्रत्येक नया एएसजी इंस्टेंस हमेशा मौजूदा टेराफॉर्म कोड की समान क्षमता पर चलेगा और इसे बनाए रखना अधिक कठिन हो जाएगा।

बेशक, टेराफॉर्म में आदर्श रूप से शून्य-डाउनटाइम तैनाती के लिए अंतर्निहित समर्थन होगा, लेकिन मई 2019 तक, हाशीकॉर्प टीम की इस कार्यक्षमता को जोड़ने की कोई योजना नहीं थी (विवरण - यहाँ).

सही योजना असफल रूप से क्रियान्वित हो सकती है

कभी-कभी प्लान कमांड बिल्कुल सही परिनियोजन योजना तैयार करता है, लेकिन अप्लाई कमांड एक त्रुटि देता है। उदाहरण के लिए, aws_iam_user संसाधन को उसी नाम से जोड़ने का प्रयास करें जिसका उपयोग आपने पहले अध्याय 2 में बनाए गए IAM उपयोगकर्ता के लिए किया था:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

अब, यदि आप योजना कमांड चलाते हैं, तो टेराफॉर्म एक उचित रूप से उचित तैनाती योजना का उत्पादन करेगा:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

यदि आप अप्लाई कमांड चलाते हैं तो आपको निम्न त्रुटि मिलेगी:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

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

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

इससे दो सबक सीखने को मिलते हैं।

• यदि आपने पहले ही टेराफ़ॉर्म के साथ काम करना शुरू कर दिया है, तो किसी और चीज़ का उपयोग न करें। यदि आपके बुनियादी ढांचे का कुछ हिस्सा टेराफॉर्म का उपयोग करके प्रबंधित किया जाता है, तो आप इसे अब मैन्युअल रूप से संशोधित नहीं कर सकते हैं। अन्यथा, आप न केवल अजीब टेराफॉर्म त्रुटियों का जोखिम उठाते हैं, बल्कि आप IaC के कई लाभों को भी नकार देते हैं क्योंकि कोड अब आपके बुनियादी ढांचे का सटीक प्रतिनिधित्व नहीं करेगा।
• यदि आपके पास पहले से ही कुछ बुनियादी ढांचा है, तो आयात कमांड का उपयोग करें। यदि आप मौजूदा बुनियादी ढांचे के साथ टेराफॉर्म का उपयोग शुरू कर रहे हैं, तो आप टेराफॉर्म आयात कमांड का उपयोग करके इसे राज्य फ़ाइल में जोड़ सकते हैं। इस तरह टेराफॉर्म को पता चल जाएगा कि किस बुनियादी ढांचे को प्रबंधित करने की आवश्यकता है। आयात आदेश दो तर्क लेता है। पहला आपकी कॉन्फ़िगरेशन फ़ाइलों में संसाधन पता है। यहां सिंटैक्स संसाधन लिंक के समान ही है: _। (जैसे aws_iam_user.मौजूदा_user)। दूसरा तर्क आयात किए जाने वाले संसाधन की आईडी है। मान लें कि संसाधन आईडी aws_iam_user उपयोगकर्ता नाम है (उदाहरण के लिए, yevgeniy.brikman), और संसाधन आईडी aws_instance EC2 सर्वर आईडी है (जैसे i-190e22e5)। किसी संसाधन को कैसे आयात किया जाए यह आमतौर पर उसके पृष्ठ के नीचे दस्तावेज़ में दर्शाया गया है।

  नीचे एक आयात कमांड है जो aws_iam_user संसाधन को सिंक्रनाइज़ करता है जिसे आपने अध्याय 2 में IAM उपयोगकर्ता के साथ अपने टेराफॉर्म कॉन्फ़िगरेशन में जोड़ा है (निश्चित रूप से yevgeniy.brikman के लिए अपना नाम प्रतिस्थापित करते हुए):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  टेराफ़ॉर्म आपके IAM उपयोगकर्ता को ढूंढने के लिए AWS API को कॉल करेगा और उसके और आपके टेराफ़ॉर्म कॉन्फ़िगरेशन में aws_iam_user.मौजूदा_user संसाधन के बीच एक राज्य फ़ाइल एसोसिएशन बनाएगा। अब से, जब आप प्लान कमांड चलाएंगे, तो टेराफॉर्म को पता चल जाएगा कि IAM उपयोगकर्ता पहले से मौजूद है और इसे दोबारा बनाने का प्रयास नहीं करेगा।

  यह ध्यान देने योग्य है कि यदि आपके पास पहले से ही बहुत सारे संसाधन हैं जिन्हें आप टेराफॉर्म में आयात करना चाहते हैं, तो मैन्युअल रूप से कोड लिखना और एक समय में प्रत्येक को आयात करना परेशानी भरा हो सकता है। इसलिए टेराफॉर्मिंग (http://terraforming.dtan4.net/) जैसे टूल पर गौर करना उचित है, जो स्वचालित रूप से आपके AWS खाते से कोड और स्थिति आयात कर सकता है।

  रिफैक्टरिंग के अपने नुकसान हो सकते हैं

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

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

  उदाहरण के लिए, वेबसर्वर-क्लस्टर मॉड्यूल में एक इनपुट वेरिएबल क्लस्टर_नाम है:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

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

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

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

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

  एक अन्य प्रकार की रीफैक्टरिंग जिसमें आपकी रुचि हो सकती है वह टेराफॉर्म आईडी को बदलना है। आइए एक उदाहरण के रूप में वेबसर्वर-क्लस्टर मॉड्यूल में aws_security_group संसाधन लें:

  resource "aws_security_group" "instance" {
    # (...)
  }

  इस संसाधन के पहचानकर्ता को उदाहरण कहा जाता है। कल्पना करें कि रीफैक्टरिंग के दौरान आपने इसे अधिक समझने योग्य (आपकी राय में) क्लस्टर_इंस्टेंस नाम में बदलने का निर्णय लिया है:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  आख़िर में क्या होगा? यह सही है: एक व्यवधान.

  टेराफॉर्म प्रत्येक संसाधन आईडी को क्लाउड प्रदाता आईडी के साथ जोड़ता है। उदाहरण के लिए, iam_user AWS IAM उपयोगकर्ता आईडी से संबद्ध है, और aws_instance AWS EC2 सर्वर आईडी से संबद्ध है। यदि आप संसाधन आईडी (उदाहरण से क्लस्टर_इंस्टेंस, जैसा कि aws_security_group के मामले में है) को टेराफॉर्म में बदलते हैं, तो ऐसा प्रतीत होगा जैसे आपने पुराना संसाधन हटा दिया है और एक नया जोड़ा है। यदि आप इन परिवर्तनों को लागू करते हैं, तो टेराफ़ॉर्म पुराने सुरक्षा समूह को हटा देगा और एक नया समूह बनाएगा, जबकि आपके सर्वर किसी भी नेटवर्क ट्रैफ़िक को अस्वीकार करना शुरू कर देंगे।

  यहां चार प्रमुख सबक हैं जिन्हें आपको इस चर्चा से लेना चाहिए।

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

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE एक अभिव्यक्ति है जो संसाधन को उसके वर्तमान स्वरूप में संदर्भित करती है, और NEW_REFERENCE वह जगह है जहां आप इसे स्थानांतरित करना चाहते हैं। उदाहरण के लिए, aws_security_group समूह का नाम इंस्टेंस से क्लस्टर_इंस्टेंस में बदलते समय, आपको निम्नलिखित कमांड चलाने की आवश्यकता है:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    यह टेराफ़ॉर्म को बताता है कि जो राज्य पहले aws_security_group.instance से संबद्ध था, उसे अब aws_security_group.cluster_instance से संबद्ध किया जाना चाहिए। यदि नाम बदलने और इस कमांड को चलाने के बाद टेराफॉर्म योजना में कोई बदलाव नहीं दिखता है, तो आपने सब कुछ सही ढंग से किया है।

  • कुछ सेटिंग्स बदली नहीं जा सकतीं. कई संसाधनों के पैरामीटर अपरिवर्तनीय हैं। यदि आप उन्हें बदलने का प्रयास करते हैं, तो टेराफ़ॉर्म पुराने संसाधन को हटा देगा और उसके स्थान पर एक नया संसाधन बनाएगा। प्रत्येक संसाधन पृष्ठ आम तौर पर इंगित करेगा कि जब आप किसी विशेष सेटिंग को बदलते हैं तो क्या होता है, इसलिए दस्तावेज़ीकरण की जांच करना सुनिश्चित करें। हमेशा प्लान कमांड का उपयोग करें और create_before_destroy रणनीति का उपयोग करने पर विचार करें।

  आस्थगित संगति सुसंगत है... आस्थगित के साथ

  कुछ क्लाउड प्रदाताओं के एपीआई, जैसे एडब्ल्यूएस, अतुल्यकालिक हैं और उनमें विलंबित स्थिरता है। एसिंक्रोनी का मतलब है कि इंटरफ़ेस अनुरोधित कार्रवाई के पूरा होने की प्रतीक्षा किए बिना तुरंत प्रतिक्रिया दे सकता है। विलंबित स्थिरता का मतलब है कि परिवर्तनों को पूरे सिस्टम में फैलने में समय लग सकता है; जबकि ऐसा हो रहा है, आपकी प्रतिक्रियाएँ असंगत हो सकती हैं और इस पर निर्भर हो सकती हैं कि कौन सा डेटा स्रोत प्रतिकृति आपके एपीआई कॉल का जवाब दे रहा है।

  उदाहरण के लिए, कल्पना करें कि आप AWS को एक API कॉल करते हैं और उससे EC2 सर्वर बनाने के लिए कहते हैं। एपीआई सर्वर के बनने की प्रतीक्षा किए बिना, लगभग तुरंत ही "सफल" प्रतिक्रिया (201 निर्मित) लौटा देगा। यदि आप इसे तुरंत कनेक्ट करने का प्रयास करते हैं, तो यह लगभग निश्चित रूप से विफल हो जाएगा क्योंकि उस समय AWS अभी भी संसाधनों को आरंभ कर रहा है या, वैकल्पिक रूप से, सर्वर अभी तक बूट नहीं हुआ है। इसके अलावा, यदि आप इस सर्वर के बारे में जानकारी प्राप्त करने के लिए दोबारा कॉल करते हैं, तो आपको एक त्रुटि (404 नहीं मिला) प्राप्त हो सकती है। बात यह है कि इस EC2 सर्वर के बारे में जानकारी हर जगह उपलब्ध होने से पहले अभी भी पूरे AWS में प्रसारित की जा सकती है, आपको कुछ सेकंड इंतजार करना होगा।

  जब भी आप आलसी स्थिरता के साथ एक एसिंक्रोनस एपीआई का उपयोग करते हैं, तो आपको समय-समय पर अपने अनुरोध को तब तक पुनः प्रयास करना होगा जब तक कि कार्रवाई पूरी न हो जाए और सिस्टम के माध्यम से प्रसारित न हो जाए। दुर्भाग्य से, AWS SDK इसके लिए कोई अच्छा उपकरण प्रदान नहीं करता है, और टेराफ़ॉर्म प्रोजेक्ट 6813 (https://github.com/hashicorp/terraform/issues/6813) जैसे कई बग से ग्रस्त था:

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

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

  यह अंश एवगेनी ब्रिकमैन की पुस्तक से प्रस्तुत किया गया है "टेराफॉर्म: कोड स्तर पर बुनियादी ढांचा".

स्रोत: www.habr.com