टेराफॉर्म तोटे

लूप, इफ स्टेटमेंट्स आणि डिप्लॉयमेंट तंत्र, तसेच टेराफॉर्मवर सर्वसाधारणपणे परिणाम करणाऱ्या अधिक सामान्य समस्यांसह काही तोटे हायलाइट करू या:

• संख्या आणि प्रत्येक पॅरामीटर्सना मर्यादा आहेत;
• शून्य डाउनटाइम उपयोजन मर्यादित करा;
• एक चांगली योजना देखील अयशस्वी होऊ शकते;
• रिफॅक्टरिंगमध्ये त्याचे तोटे असू शकतात;
• स्थगित सुसंगतता सुसंगत आहे... स्थगित सह.

गणना आणि प्रत्येक पॅरामीटर्सना मर्यादा आहेत

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

• Count आणि 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_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.

टेराफॉर्मसाठी आवश्यक आहे की कोणतीही संसाधने तयार किंवा सुधारित करण्यापूर्वी नियोजन टप्प्यात प्रत्येकासाठी मोजणी आणि गणना केली जावी. याचा अर्थ गणना आणि 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_autoscaling_schedule संसाधनांची जोडी असते, जे सकाळी 9 वाजता क्लस्टरमधील सर्व्हरची संख्या दोन ते दहा पर्यंत वाढवते. तुम्ही सकाळी 11 वाजता तैनात केल्यास, नवीन ASG दहा ऐवजी फक्त दोन सर्व्हरसह बूट होईल आणि दुसऱ्या दिवशी सकाळी 9 वाजेपर्यंत तसाच राहील.

ही मर्यादा अनेक प्रकारे दूर केली जाऊ शकते.

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

अर्थात, टेराफॉर्मला आदर्शपणे शून्य-डाउनटाइम उपयोजनांसाठी अंगभूत समर्थन असेल, परंतु मे 2019 पर्यंत, HashiCorp संघाची ही कार्यक्षमता जोडण्याची कोणतीही योजना नव्हती (तपशील - येथे).

योग्य योजना अयशस्वीपणे अंमलात आणली जाऊ शकते

काहीवेळा प्लॅन कमांड उत्तम प्रकारे योग्य डिप्लॉयमेंट प्लॅन तयार करते, परंतु लागू कमांड एरर परत करते. उदाहरणार्थ, तुम्ही अध्याय 2 मध्ये आधी तयार केलेल्या IAM वापरकर्त्यासाठी वापरलेल्या त्याच नावासह aws_iam_user संसाधन जोडण्याचा प्रयत्न करा:

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 कन्सोलमध्ये मॅन्युअली क्लिक करून), ते स्टेट फाइलमध्ये संपणार नाहीत आणि म्हणून प्लॅन कमांड कार्यान्वित करताना टेराफॉर्म त्यांना विचारात घेणार नाही. परिणामी, पहिल्या दृष्टीक्षेपात योग्य वाटणारी योजना अयशस्वी ठरेल.

यातून दोन धडे शिकायचे आहेत.

• जर तुम्ही आधीच Terraform सह काम करण्यास सुरुवात केली असेल, तर दुसरे काहीही वापरू नका. जर तुमच्या पायाभूत सुविधांचा भाग Terraform वापरून व्यवस्थापित केला असेल, तर तुम्ही यापुढे ते व्यक्तिचलितपणे सुधारू शकणार नाही. अन्यथा, तुम्हाला केवळ विचित्र टेराफॉर्म त्रुटींचा धोका नाही तर तुम्ही IaC चे अनेक फायदे देखील नाकारता कारण कोड यापुढे तुमच्या पायाभूत सुविधांचे अचूक प्रतिनिधित्व करणार नाही.
• तुमच्याकडे आधीपासून काही पायाभूत सुविधा असल्यास, आयात आदेश वापरा. जर तुम्ही विद्यमान पायाभूत सुविधांसह टेराफॉर्म वापरण्यास सुरुवात करत असाल, तर तुम्ही ते टेराफॉर्म आयात कमांड वापरून स्टेट फाइलमध्ये जोडू शकता. अशा प्रकारे टेराफॉर्मला समजेल की कोणत्या पायाभूत सुविधांचे व्यवस्थापन करणे आवश्यक आहे. आयात आदेश दोन वितर्क घेते. प्रथम तुमच्या कॉन्फिगरेशन फाइल्समधील स्त्रोत पत्ता आहे. येथे वाक्यरचना संसाधन दुव्यांप्रमाणेच आहे: _. (जसे aws_iam_user.existing_user). दुसरा युक्तिवाद आयात करायच्या स्त्रोताचा आयडी आहे. समजा संसाधन आयडी aws_iam_user हे वापरकर्ता नाव आहे (उदाहरणार्थ, yevgeniy.brikman), आणि संसाधन आयडी aws_instance हा EC2 सर्व्हर आयडी आहे (जसे की i-190e22e5). संसाधन कसे आयात करावे हे सहसा त्याच्या पृष्ठाच्या तळाशी असलेल्या दस्तऐवजीकरणात सूचित केले जाते.

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

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  टेराफॉर्म तुमचा IAM वापरकर्ता शोधण्यासाठी AWS API ला कॉल करेल आणि तुमच्या Terraform कॉन्फिगरेशनमध्ये ते आणि aws_iam_user.existing_user संसाधन यांच्यामध्ये स्टेट फाइल असोसिएशन तयार करेल. आतापासून, जेव्हा तुम्ही प्लॅन कमांड रन कराल, तेव्हा टेराफॉर्मला कळेल की IAM वापरकर्ता आधीच अस्तित्वात आहे आणि तो पुन्हा तयार करण्याचा प्रयत्न करणार नाही.

  हे लक्षात घेण्यासारखे आहे की जर तुमच्याकडे आधीच भरपूर संसाधने असतील जी तुम्ही टेराफॉर्ममध्ये आयात करू इच्छित असाल तर, कोड मॅन्युअली लिहिणे आणि एकावेळी प्रत्येक एक आयात करणे त्रासदायक ठरू शकते. त्यामुळे टेराफॉर्मिंग (http://terraforming.dtan4.net/) सारख्या साधनाकडे पाहण्यासारखे आहे, जे तुमच्या AWS खात्यामधून आपोआप कोड आणि राज्य आयात करू शकते.

  रिफॅक्टरिंगमध्ये त्याचे तोटे असू शकतात

  रिफॅक्टरिंग प्रोग्रामिंगमध्ये एक सामान्य सराव आहे जिथे तुम्ही बाह्य वर्तन अपरिवर्तित ठेवताना कोडची अंतर्गत रचना बदलता. हे कोड अधिक स्पष्ट, स्वच्छ आणि देखरेख करणे सोपे करण्यासाठी आहे. रिफॅक्टरिंग हे एक अपरिहार्य तंत्र आहे जे नियमितपणे वापरले पाहिजे. परंतु जेव्हा टेराफॉर्म किंवा इतर कोणत्याही IaC साधनाचा विचार केला जातो, तेव्हा तुम्हाला कोडच्या तुकड्याच्या "बाह्य वर्तन" चा अर्थ काय आहे याबद्दल अत्यंत सावधगिरी बाळगावी लागेल, अन्यथा अनपेक्षित समस्या उद्भवतील.

  उदाहरणार्थ, रिफॅक्टरिंगचा एक सामान्य प्रकार म्हणजे व्हेरिएबल्स किंवा फंक्शन्सची नावे अधिक समजण्यायोग्य नावांनी बदलणे. अनेक IDE मध्ये रीफॅक्टरिंगसाठी अंगभूत समर्थन असते आणि संपूर्ण प्रोजेक्टमध्ये आपोआप व्हेरिएबल्स आणि फंक्शन्सचे नाव बदलू शकतात. सामान्य-उद्देशीय प्रोग्रामिंग भाषांमध्ये, ही एक क्षुल्लक प्रक्रिया आहे ज्याचा तुम्ही विचार करू शकत नाही, परंतु टेराफॉर्ममध्ये तुम्हाला याबद्दल अत्यंत सावधगिरी बाळगावी लागेल, अन्यथा तुम्हाला आउटेजचा अनुभव येऊ शकतो.

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

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

  कल्पना करा की तुम्ही foo नावाची मायक्रोसर्व्हिस तैनात करण्यासाठी हे मॉड्यूल वापरण्यास सुरुवात केली आहे. नंतर, तुम्हाला तुमच्या सेवेचे नाव बारमध्ये बदलायचे आहे. हा बदल क्षुल्लक वाटत असला तरी प्रत्यक्षात यामुळे सेवा विस्कळीत होऊ शकते.

  वस्तुस्थिती अशी आहे की वेबसर्व्हर-क्लस्टर मॉड्यूल अनेक संसाधनांमध्ये cluster_name व्हेरिएबल वापरते, ज्यामध्ये दोन सुरक्षा गटांचे नाव पॅरामीटर आणि ALB समाविष्ट आहे:

  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 असेल तर, ते हटवणे आणि नवीन आवृत्ती डाउनलोड करणे दरम्यान, तुमच्या वेब सर्व्हरवर रहदारी पुनर्निर्देशित करण्यासाठी तुमच्याकडे यंत्रणा नसेल. त्याचप्रमाणे, एखादा सुरक्षा गट हटवला गेल्यास, नवीन गट तयार होईपर्यंत तुमचे सर्व्हर कोणतेही नेटवर्क रहदारी नाकारण्यास सुरुवात करतील.

  रिफॅक्टरिंगचा आणखी एक प्रकार ज्यामध्ये तुम्हाला स्वारस्य असेल ते म्हणजे टेराफॉर्म आयडी बदलणे. वेबसर्व्हर-क्लस्टर मॉड्यूलमधील 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 च्या बाबतीत आहे), ते Terraform मध्ये तुम्ही जुने रिसोर्स हटवले आणि नवीन जोडल्यासारखे दिसेल. तुम्ही हे बदल लागू केल्यास, Terraform जुना सुरक्षा गट हटवेल आणि एक नवीन तयार करेल, जेव्हा तुमचे सर्व्हर कोणतेही नेटवर्क रहदारी नाकारू लागतात.

  या चर्चेतून तुम्ही चार महत्त्वाचे धडे घेतले पाहिजेत.

  • नेहमी प्लॅन कमांड वापरा. हे सर्व snags प्रकट करू शकता. त्‍याच्‍या आउटपुटचे काळजीपूर्वक पुनरावलोकन करा आणि टेराफॉर्म बहुधा हटवण्‍याची नसलेली संसाधने हटवण्‍याची योजना आखत असलेल्‍या परिस्थितींकडे लक्ष द्या.
  • तुम्ही हटवण्यापूर्वी तयार करा. तुम्हाला एखादे संसाधन पुनर्स्थित करायचे असल्यास, मूळ हटवण्यापूर्वी तुम्हाला पुनर्स्थित करणे आवश्यक आहे का याचा काळजीपूर्वक विचार करा. उत्तर होय असल्यास, create_before_destroy मदत करू शकते. समान परिणाम दोन पायऱ्या पार पाडून व्यक्तिचलितपणे प्राप्त केले जाऊ शकतात: प्रथम कॉन्फिगरेशनमध्ये नवीन संसाधन जोडा आणि लागू आदेश चालवा, आणि नंतर कॉन्फिगरेशनमधून जुने संसाधन काढून टाका आणि पुन्हा लागू आदेश वापरा.
  • अभिज्ञापक बदलण्यासाठी स्थिती बदलणे आवश्यक आहे. जर तुम्हाला रिसोर्सशी संबंधित आयडी बदलायचा असेल (उदाहरणार्थ, aws_security_group चे नाव बदलून instance वरून cluster_instance करा) रिसोर्स न हटवता आणि त्याची नवीन आवृत्ती तयार करा, तुम्ही त्यानुसार टेराफॉर्म स्टेट फाइल अपडेट करणे आवश्यक आहे. हे कधीही स्वहस्ते करू नका - त्याऐवजी टेराफॉर्म स्टेट कमांड वापरा. आयडेंटिफायर्सचे नाव बदलताना, तुम्ही टेराफॉर्म स्टेट एमव्ही कमांड चालवा, ज्यामध्ये खालील वाक्यरचना आहे:

    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 जुने संसाधन हटवेल आणि त्याच्या जागी एक नवीन तयार करेल. प्रत्येक संसाधन पृष्ठ सामान्यतः सूचित करेल की तुम्ही विशिष्ट सेटिंग बदलता तेव्हा काय होते, म्हणून दस्तऐवजीकरण तपासण्याचे सुनिश्चित करा. नेहमी योजना कमांड वापरा आणि create_before_destroy धोरण वापरण्याचा विचार करा.

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

  काही क्लाउड प्रदात्यांचे API, जसे की AWS, असिंक्रोनस आहेत आणि सुसंगतता विलंबित आहे. असिंक्रोनी म्हणजे विनंती केलेली क्रिया पूर्ण होण्याची वाट न पाहता इंटरफेस त्वरित प्रतिसाद देऊ शकतो. विलंबित सुसंगततेचा अर्थ असा आहे की बदल संपूर्ण प्रणालीमध्ये प्रसारित होण्यास वेळ लागू शकतो; हे घडत असताना, तुमचे प्रतिसाद विसंगत असू शकतात आणि तुमच्या API कॉलला कोणत्या डेटा स्रोत प्रतिकृती प्रतिसाद देत आहेत यावर अवलंबून असू शकतात.

  कल्पना करा, उदाहरणार्थ, तुम्ही AWS ला EC2 सर्व्हर तयार करण्यास सांगून API कॉल करता. सर्व्हर तयार होण्याची वाट न पाहता API जवळजवळ त्वरित "यशस्वी" प्रतिसाद (201 तयार) देईल. तुम्ही लगेच त्याच्याशी कनेक्ट करण्याचा प्रयत्न केल्यास, ते जवळजवळ निश्चितपणे अयशस्वी होईल कारण त्या वेळी AWS अजूनही संसाधने सुरू करत आहे किंवा पर्यायाने, सर्व्हर अद्याप बूट झालेला नाही. शिवाय, आपण या सर्व्हरबद्दल माहिती मिळविण्यासाठी दुसरा कॉल केल्यास, आपल्याला एक त्रुटी (404 सापडली नाही) प्राप्त होऊ शकते. गोष्ट अशी आहे की या EC2 सर्व्हरची माहिती सर्वत्र उपलब्ध होण्यापूर्वी AWS मध्ये अद्याप प्रसारित केली जाऊ शकते, तुम्हाला काही सेकंद प्रतीक्षा करावी लागेल.

  जेव्हाही तुम्ही आळशी सुसंगततेसह असिंक्रोनस API वापरता, तेव्हा क्रिया पूर्ण होईपर्यंत आणि सिस्टमद्वारे प्रसारित होईपर्यंत तुम्ही ठराविक काळाने तुमची विनंती पुन्हा प्रयत्न करणे आवश्यक आहे. दुर्दैवाने, 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 सह) निश्चित केले गेले आहेत, परंतु तरीही ते वेळोवेळी क्रॉप होतात, विशेषतः जेव्हा टेराफॉर्म नवीन संसाधन प्रकारासाठी समर्थन जोडते. हे त्रासदायक आहे, परंतु बहुतेक प्रकरणांमध्ये कोणतेही नुकसान होत नाही. तुम्ही टेराफॉर्म लागू पुन्हा चालवता तेव्हा, सर्वकाही कार्य केले पाहिजे, कारण यावेळेपर्यंत माहिती संपूर्ण सिस्टममध्ये पसरलेली असेल.

  Evgeniy Brikman यांच्या पुस्तकातून हा उतारा सादर केला आहे "टेराफॉर्म: कोड स्तरावर पायाभूत सुविधा".

स्त्रोत: www.habr.com