Terraform पिटफल्स

लूपहरू, इफ स्टेटमेन्ट र डिप्लोइमेन्ट प्रविधिहरू, साथै सामान्य रूपमा टेराफर्मलाई असर गर्ने थप सामान्य मुद्दाहरू सहित केही समस्याहरू हाइलाइट गरौं:

• गणना र for_each मापदण्डहरूको सीमाहरू छन्;
• शून्य डाउनटाइम परिनियोजनहरू सीमित गर्नुहोस्;
• राम्रो योजना पनि असफल हुन सक्छ;
• रिफ्याक्टरिङमा यसको कमजोरी हुन सक्छ;
• स्थगित सुसंगतता संगत छ ... स्थगित संग।

गणना र for_each प्यारामिटरहरूको सीमाहरू छन्

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

• गणना र for_each ले कुनै पनि स्रोत आउटपुट चर सन्दर्भ गर्न सक्दैन।
• गणना र for_each मोड्युल कन्फिगरेसनमा प्रयोग गर्न सकिँदैन।

गणना र for_each ले कुनै पनि स्रोत आउटपुट चर सन्दर्भ गर्न सक्दैन

कल्पना गर्नुहोस् कि तपाईंले धेरै EC2 सर्भरहरू प्रयोग गर्न आवश्यक छ र केही कारणका लागि तपाईं ASG प्रयोग गर्न चाहनुहुन्न। तपाईंको कोड यस्तो हुन सक्छ:

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

तिनीहरूलाई एक एक गरेर हेरौं।

काउन्ट प्यारामिटर स्थिर मानमा सेट गरिएको हुनाले, यो कोडले समस्या बिना काम गर्नेछ: जब तपाइँ लागू आदेश चलाउनुहुन्छ, यसले तीन EC2 सर्भरहरू सिर्जना गर्नेछ। तर के यदि तपाइँ तपाइँको वर्तमान AWS क्षेत्र भित्र प्रत्येक उपलब्धता क्षेत्र (AZ) मा एक सर्भर तैनात गर्न चाहनुहुन्छ भने? तपाईंले आफ्नो कोडलाई aws_availability_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" {}

यो कोडले पनि राम्रो काम गर्नेछ, किनकि गणना प्यारामिटरले कुनै पनि समस्या बिना डेटा स्रोतहरू सन्दर्भ गर्न सक्छ। तर के हुन्छ यदि तपाईले सिर्जना गर्न आवश्यक सर्भरहरूको संख्या केहि स्रोतको आउटपुटमा निर्भर गर्दछ? यो देखाउनको लागि, सबैभन्दा सजिलो तरिका random_integer स्रोत प्रयोग गर्नु हो, जुन नामले सुझाव दिन्छ, अनियमित पूर्णांक फर्काउँछ:

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.

Terraform लाई कुनै पनि स्रोतहरू सिर्जना वा परिमार्जन गर्नु अघि योजना चरणको अवधिमा गणना र for_each गणना गर्न आवश्यक छ। यसको मतलब यो हो कि गणना र 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"
}

यो कोडले वेबसर्भर-क्लस्टर स्रोतको तीन प्रतिलिपिहरू सिर्जना गर्न मोड्युल भित्र गणना प्रयोग गर्ने प्रयास गर्दछ। वा तपाइँ केहि बुलियन अवस्थाको आधारमा मोड्युललाई ० मा सेट गरेर वैकल्पिक रूपमा जडान गर्न चाहन सक्नुहुन्छ। यो व्यावहारिक कोड जस्तो देखिन सक्छ, तर टेराफर्म योजना चलाउँदा तपाइँले यो त्रुटि पाउनुहुनेछ:

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.

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

शून्य डाउनटाइम डिप्लोइमेन्टहरूको सीमाहरू

ASG सँग संयोजनमा create_before_destroy ब्लक प्रयोग गर्नु भनेको शून्य-डाउनटाइम डिप्लोयमेन्टहरू सिर्जना गर्नको लागि उत्कृष्ट समाधान हो, एउटा चेतावनी बाहेक: स्वत: स्केलिंग नियमहरू समर्थित छैनन्। वा थप सटीक हुनको लागि, यसले प्रत्येक डिप्लोइमेन्टमा ASG साइजलाई min_size मा रिसेट गर्छ, जुन तपाईले चलिरहेको सर्भरहरूको संख्या बढाउन स्वत: स्केलिङ नियमहरू प्रयोग गरिरहनुभएको भए समस्या हुन सक्छ।

उदाहरणका लागि, वेबसर्भर-क्लस्टर मोड्युलले aws_autoscaling_schedule स्रोतहरूको जोडी समावेश गर्दछ, जसले बिहान 9 बजे क्लस्टरमा सर्भरहरूको संख्या दुई बाट १० सम्म बढाउँछ। यदि तपाईंले बिहान ११ बजे डिप्लोय गर्नुभयो भने, नयाँ ASG ले दस भन्दा दुईवटा सर्भरमा बुट अप गर्नेछ र अर्को दिन बिहान ९ बजेसम्म त्यही रूपमा रहनेछ।

यस सीमालाई धेरै तरिकामा हटाउन सकिन्छ।

• aws_autoscaling_schedule मा 0 9 * * * ("बिहान 9 बजे चलाउनुहोस्") बाट 0-59 9-17 * * * ("प्रत्येक मिनेट बिहान 9 बजे देखि 5 बजे सम्म चलाउनुहोस्") मा पुनरावृत्ति प्यारामिटर परिवर्तन गर्नुहोस्। यदि ASG पहिले नै दस वटा सर्भरहरू छन् भने, यो स्वत: स्केलिंग नियम फेरि चलाउँदा केही परिवर्तन हुनेछैन, जुन हामी चाहन्छौं। तर यदि ASG भर्खरै मात्र तैनात गरिएको छ भने, यो नियमले यो सुनिश्चित गर्नेछ कि एक मिनेटको अधिकतममा यसको सर्भरहरूको संख्या दस पुग्नेछ। यो पूर्णतया सुरुचिपूर्ण दृष्टिकोण होइन, र दस देखि दुई सर्भर र पछाडि ठूला जम्पहरूले प्रयोगकर्ताहरूको लागि समस्या निम्त्याउन सक्छ।
• ASG मा सक्रिय सर्भरहरूको संख्या निर्धारण गर्न AWS API प्रयोग गर्ने अनुकूलन स्क्रिप्ट सिर्जना गर्नुहोस्, यसलाई बाह्य डेटा स्रोत प्रयोग गरेर कल गर्नुहोस् (पृष्ठ 249 मा "बाह्य डेटा स्रोत" हेर्नुहोस्), र ASG को इच्छित_capacity प्यारामिटरलाई फिर्ता गरिएको मानमा सेट गर्नुहोस्। लिपि। यसरी, प्रत्येक नयाँ ASG उदाहरण सधैं अवस्थित Terraform कोड जस्तै क्षमतामा चल्नेछ र यसलाई कायम राख्न अझ गाह्रो बनाउँछ।

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

सही योजना असफल कार्यान्वयन हुन सक्छ

कहिलेकाहीँ योजना आदेशले पूर्ण रूपमा सही परिनियोजन योजना उत्पादन गर्दछ, तर लागू आदेशले त्रुटि फर्काउँछ। उदाहरणका लागि, तपाईंले अध्याय २ मा पहिले सिर्जना गर्नुभएको IAM प्रयोगकर्ताका लागि प्रयोग गर्नुभएको एउटै नामको aws_iam_user स्रोत थप्ने प्रयास गर्नुहोस्:

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

अब, यदि तपाइँ योजना आदेश चलाउनुहुन्छ भने, Terraform ले एक उचित परिनियोजन योजना आउटपुट गर्नेछ:

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 प्रयोगकर्ताहरूलाई मात्र होइन, तर लगभग कुनै पनि स्रोतमा हुन सक्छ। यो सम्भव छ कि कसैले म्यानुअल रूपमा वा कमाण्ड लाइन प्रयोग गरेर यो स्रोत सिर्जना गरेको हो, तर कुनै पनि तरिकाले, मिल्दो ID हरूले विवाद निम्त्याउँछ। यस त्रुटिको धेरै भिन्नताहरू छन् जुन प्रायः टेराफर्ममा नयाँ आउनेहरूलाई आश्चर्यचकित पार्छ।

मुख्य बिन्दु यो हो कि टेराफर्म योजना आदेशले केवल ती स्रोतहरूलाई ध्यानमा राख्छ जुन Terraform राज्य फाइलमा निर्दिष्ट गरिएको छ। यदि स्रोतहरू कुनै अन्य तरिकामा सिर्जना गरिएका छन् (उदाहरणका लागि, म्यानुअल रूपमा AWS कन्सोलमा क्लिक गरेर), तिनीहरू राज्य फाइलमा समाप्त हुनेछैनन् र त्यसैले Terraform ले योजना आदेश कार्यान्वयन गर्दा तिनीहरूलाई ध्यानमा राख्दैन। नतिजाको रूपमा, पहिलो नजरमा सही लाग्ने योजना असफल हुनेछ।

यसबाट सिक्नुपर्ने दुईवटा पाठ छन्।

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

  तल एउटा आयात आदेश छ जसले aws_iam_user स्रोतलाई सिङ्क्रोनाइज गर्दछ जुन तपाइँले तपाइँको Terraform कन्फिगरेसनमा IAM प्रयोगकर्तासँग अध्याय 2 मा थप्नुभएको छ (निश्चय नै yevgeniy.brikman को लागी तपाइँको नाम प्रतिस्थापन गर्दै):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform ले तपाईंको IAM प्रयोगकर्ता फेला पार्न AWS API लाई कल गर्नेछ र तपाईंको Terraform कन्फिगरेसनमा यो र aws_iam_user.existing_user स्रोत बीच राज्य फाइल सम्बन्ध सिर्जना गर्नेछ। अब देखि, जब तपाइँ योजना आदेश चलाउनुहुन्छ, Terraform थाहा हुनेछ कि IAM प्रयोगकर्ता पहिले नै अवस्थित छ र यसलाई फेरि सिर्जना गर्ने प्रयास गर्दैन।

  यो ध्यान दिन लायक छ कि यदि तपाईंसँग पहिले नै धेरै स्रोतहरू छन् जुन तपाईं Terraform मा आयात गर्न चाहनुहुन्छ भने, मैन्युअल रूपमा कोड लेख्नुहोस् र प्रत्येक एक एक पटकमा आयात गर्न एक झन्झट हुन सक्छ। त्यसैले यो Terraforming (http://terraforming.dtan4.net/) जस्तै उपकरणमा हेर्न लायक छ, जसले स्वचालित रूपमा तपाईंको AWS खाताबाट कोड र राज्य आयात गर्न सक्छ।

  रिफ्याक्टरिङमा यसको कमजोरी हुन सक्छ

  रिफ्याक्टरिङ प्रोग्रामिङमा एक सामान्य अभ्यास हो जहाँ तपाइँ बाह्य व्यवहार अपरिवर्तित छोडेर कोडको आन्तरिक संरचना परिवर्तन गर्नुहुन्छ। यो कोडलाई स्पष्ट, सफा र मर्मत गर्न सजिलो बनाउनको लागि हो। Refactoring एक अपरिहार्य प्रविधि हो जुन नियमित रूपमा प्रयोग गर्नुपर्छ। तर जब यो Terraform वा कुनै अन्य IaC उपकरणको कुरा आउँछ, तपाईले कोडको टुक्राको "बाह्य व्यवहार" को अर्थ के हो भन्ने बारे अत्यन्त सावधान रहनु पर्छ, अन्यथा अनपेक्षित समस्याहरू उत्पन्न हुनेछन्।

  उदाहरणका लागि, एक सामान्य प्रकारको रिफ्याक्टरिङले चर वा प्रकार्यहरूको नामहरू थप बुझ्न सकिने व्यक्तिहरूसँग प्रतिस्थापन गर्दैछ। धेरै IDE हरू रिफ्याक्टरिङका लागि निर्मित समर्थन छन् र स्वचालित रूपमा परियोजना भर चर र प्रकार्यहरू पुन: नामाकरण गर्न सक्छन्। सामान्य-उद्देश्य प्रोग्रामिङ भाषाहरूमा, यो एउटा मामूली प्रक्रिया हो जसको बारेमा तपाईंले सोच्न सक्नुहुन्न, तर Terraform मा तपाईंले यससँग धेरै सावधान रहनु पर्छ, अन्यथा तपाईंले आउटेज अनुभव गर्न सक्नुहुन्छ।

  उदाहरणका लागि, वेबसर्भर-क्लस्टर मोड्युलमा इनपुट चल cluster_name छ:

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

  कल्पना गर्नुहोस् कि तपाईंले यो मोड्युललाई foo भनिने माइक्रोसर्भिस प्रयोग गर्न सुरु गर्नुभयो। पछि, तपाइँ आफ्नो सेवालाई बारमा पुन: नामाकरण गर्न चाहनुहुन्छ। यो परिवर्तन मामूली लाग्न सक्छ, तर वास्तवमा यसले सेवा अवरोधहरू निम्त्याउन सक्छ।

  तथ्य यो हो कि वेबसर्भर-क्लस्टर मोड्युलले दुई सुरक्षा समूहहरूको नाम प्यारामिटर र ALB सहित धेरै स्रोतहरूमा cluster_name चर प्रयोग गर्दछ:

  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]
  }

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

  तपाईलाई रुचि हुन सक्ने अर्को प्रकारको रिफ्याक्टरिङ भनेको Terraform ID परिवर्तन गर्नु हो। उदाहरणको रूपमा वेबसर्भर-क्लस्टर मोड्युलमा aws_security_group स्रोत लिनुहोस्:

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

  यस स्रोतको पहिचानकर्तालाई उदाहरण भनिन्छ। कल्पना गर्नुहोस् कि refactoring को समयमा तपाईंले यसलाई थप बुझ्न योग्य (तपाईंको विचारमा) नाम cluster_instance मा परिवर्तन गर्ने निर्णय गर्नुभयो:

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

  आखिर के हुने हो ? त्यो सही छ: एक अवरोध।

  Terraform ले क्लाउड प्रदायक ID सँग प्रत्येक स्रोत ID सम्बद्ध गर्दछ। उदाहरणका लागि, iam_user AWS IAM प्रयोगकर्ता ID सँग सम्बन्धित छ, र aws_instance AWS EC2 सर्भर ID सँग सम्बन्धित छ। यदि तपाईंले स्रोत ID (उदाहरणबाट cluster_instance भन्नुहोस्, जस्तै aws_security_group को मामलामा) परिवर्तन गर्नुभयो भने, यो तपाईंले पुरानो स्रोत मेटाएर नयाँ थप्नुभएको जस्तो देखिनेछ। यदि तपाइँ यी परिवर्तनहरू लागू गर्नुहुन्छ भने, Terraform ले पुरानो सुरक्षा समूह मेटाउनेछ र नयाँ सिर्जना गर्नेछ, जबकि तपाइँको सर्भरहरूले कुनै पनि नेटवर्क ट्राफिक अस्वीकार गर्न थाल्छ।

  यहाँ चार मुख्य पाठहरू छन् जुन तपाईंले यस छलफलबाट टाढा लैजानुपर्छ।

  • सधैं योजना आदेश प्रयोग गर्नुहोस्। यसले यी सबै स्न्यागहरू प्रकट गर्न सक्छ। यसको आउटपुट सावधानीपूर्वक समीक्षा गर्नुहोस् र परिस्थितिहरूमा ध्यान दिनुहोस् जहाँ Terraform ले सम्भावित रूपमा मेटाउन नहुने स्रोतहरू मेटाउने योजना बनाउँछ।
  • तपाईंले मेटाउनु अघि सिर्जना गर्नुहोस्। यदि तपाइँ कुनै स्रोत प्रतिस्थापन गर्न चाहनुहुन्छ भने, मूल मेटाउनु अघि तपाइँलाई प्रतिस्थापन सिर्जना गर्न आवश्यक छ कि छैन भनेर सावधानीपूर्वक सोच्नुहोस्। यदि जवाफ हो भने, create_before_destroy ले मद्दत गर्न सक्छ। समान परिणाम दुई चरणहरू प्रदर्शन गरेर म्यानुअल रूपमा प्राप्त गर्न सकिन्छ: पहिले कन्फिगरेसनमा नयाँ स्रोत थप्नुहोस् र लागू आदेश चलाउनुहोस्, र त्यसपछि कन्फिगरेसनबाट पुरानो स्रोत हटाउनुहोस् र फेरि लागू आदेश प्रयोग गर्नुहोस्।
  • पहिचानकर्ताहरू परिवर्तन गर्न राज्य परिवर्तन आवश्यक छ। यदि तपाइँ स्रोतसँग सम्बन्धित ID लाई परिवर्तन गर्न चाहनुहुन्छ (उदाहरणका लागि, aws_security_group instance बाट cluster_instance मा पुन: नामाकरण गर्नुहोस्) स्रोत मेटाउन र यसको नयाँ संस्करण सिर्जना नगरी, तपाइँले Terraform राज्य फाइल तदनुसार अद्यावधिक गर्नुपर्छ। यसलाई म्यानुअल रूपमा कहिल्यै नगर्नुहोस् - यसको सट्टामा टेराफर्म स्टेट आदेश प्रयोग गर्नुहोस्। पहिचानकर्ताहरू पुन: नामाकरण गर्दा, तपाईंले टेराफॉर्म स्टेट mv आदेश चलाउनु पर्छ, जसमा निम्न वाक्य रचना छ:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE एउटा अभिव्यक्ति हो जसले यसको हालको फारममा स्रोतलाई जनाउँछ, र NEW_REFERENCE जहाँ तपाईं यसलाई सार्न चाहनुहुन्छ। उदाहरणका लागि, जब aws_security_group समूहलाई instance बाट cluster_instance मा पुन: नामाकरण गर्दा, तपाईंले निम्न आदेश चलाउन आवश्यक छ:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    यसले टेराफर्मलाई बताउँछ जुन राज्य पहिले aws_security_group.instance सँग सम्बन्धित थियो अब aws_security_group.cluster_instance सँग सम्बन्धित हुनुपर्छ। यदि यो आदेश टेराफर्म योजना पुन: नामाकरण र चलाउँदा कुनै परिवर्तनहरू देखाउँदैन भने, तपाईंले सबै कुरा सही रूपमा गर्नुभयो।

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

  स्थगित स्थिरता सुसंगत छ ... स्थगित संग

  AWS जस्ता केही क्लाउड प्रदायकहरूको API हरू एसिन्क्रोनस हुन् र स्थिरतामा ढिलाइ भएको छ। Asynchrony को अर्थ हो कि इन्टरफेसले अनुरोध गरिएको कार्य पूरा हुनको लागि प्रतीक्षा नगरी तुरुन्तै प्रतिक्रिया फर्काउन सक्छ। ढिलाइ भएको स्थिरता भनेको परिवर्तनहरू सम्पूर्ण प्रणालीमा प्रचार गर्न समय लाग्न सक्छ। यो भइरहेको बेला, तपाइँका प्रतिक्रियाहरू असंगत हुन सक्छन् र कुन डाटा स्रोत प्रतिकृतिले तपाइँको API कलहरूमा प्रतिक्रिया दिइरहेको छ भन्नेमा निर्भर हुन सक्छ।

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

  जब तपाइँ अल्छी स्थिरता संग एक एसिन्क्रोनस API प्रयोग गर्नुहुन्छ, तपाइँले आवधिक रूपमा तपाइँको अनुरोधलाई पुन: प्रयास गर्नुपर्छ जब सम्म कार्य पूरा हुँदैन र प्रणाली मार्फत प्रचार हुन्छ। दुर्भाग्यवश, AWS SDK ले यसका लागि कुनै राम्रो उपकरणहरू प्रदान गर्दैन, र Terraform परियोजनाले 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 सहित) फिक्स गरिएको छ, तर तिनीहरू अझै पनि समय-समयमा क्रप हुन्छन्, विशेष गरी जब Terraform नयाँ स्रोत प्रकारको लागि समर्थन थप्छ। यो कष्टप्रद छ, तर धेरै जसो अवस्थामा कुनै हानि गर्दैन। जब तपाइँ टेराफर्म लागू गर्नुहुन्छ पुन: चलाउनुहुन्छ, सबै कुराले काम गर्नुपर्छ, किनकि यस समय सम्म जानकारी पहिले नै प्रणालीमा फैलिएको हुन्छ।

  यो अंश Evgeniy Brikman द्वारा पुस्तकबाट प्रस्तुत गरिएको छ "टेराफार्म: कोड स्तरमा पूर्वाधार".

स्रोत: www.habr.com