Terraform ၏အခက်အခဲများ

ထုတ်ပြန်ချက်များနှင့် အသုံးချမှုနည်းပညာများအပြင် ယေဘုယျအားဖြင့် Terraform ကို သက်ရောက်မှုရှိသော နောက်ထပ် ယေဘူယျပြဿနာများရှိလျှင် ကွင်းဆက်များနှင့်သက်ဆိုင်သည့်အရာများအပါအဝင် ချို့ယွင်းချက်အချို့ကို မီးမောင်းထိုးပြကြပါစို့။

• အရေအတွက်နှင့် ကန့်သတ်ချက်တစ်ခုစီတွင် ကန့်သတ်ချက်များရှိသည်။
• စက်ရပ်ချိန်ကို လုံးဝ ကန့်သတ်ပါ။
• အစီအစဥ်ကောင်းတစ်ခုပင် မအောင်မြင်နိုင်ပါ။
• refactoring သည် ၎င်း၏ ချို့ယွင်းချက်များ ရှိနိုင်သည်။
• deferred coherence သည်... ရွှေ့ဆိုင်းခြင်းနှင့် ကိုက်ညီသည်။

အရေအတွက်နှင့် ကန့်သတ်ချက်တစ်ခုစီတွင် ကန့်သတ်ချက်များရှိသည်။

ဤအခန်းရှိ နမူနာများသည် count parameter နှင့် loops နှင့် conditional logic တို့တွင် for_each expression ကို ကျယ်ကျယ်ပြန့်ပြန့် အသုံးပြုစေသည်။ ၎င်းတို့သည် ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်သော်လည်း ၎င်းတို့တွင် သင်သတိထားရန်လိုအပ်သည့် အရေးကြီးသော ကန့်သတ်ချက်နှစ်ခုရှိသည်။

• Count နှင့် for_each သည် မည်သည့် အရင်းအမြစ် ထုတ်ပေးသည့် ကိန်းရှင်များကိုမျှ ကိုးကား၍ မရပါ။
• count နှင့် for_each ကို module configuration တွင် အသုံးမပြုနိုင်ပါ။

count နှင့် for_each သည် မည်သည့်အရင်းအမြစ်မှထွက်ရှိမည့်ကိန်းရှင်များကို ကိုးကား၍မရပါ။

သင်သည် EC2 ဆာဗာများစွာကို အသုံးပြုရန် လိုအပ်ပြီး ASG ကို အသုံးမပြုလိုသော အကြောင်းပြချက်အချို့ကြောင့် တွေးကြည့်ပါ။ သင့်ကုဒ်သည် ဤကဲ့သို့ ဖြစ်နိုင်သည်-

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

အဲဒါတွေကို တစ်ပုံချင်းကြည့်ရအောင်။

count parameter ကို static value တစ်ခုအဖြစ်သတ်မှတ်ထားသောကြောင့်၊ ဤကုဒ်သည် ပြဿနာမရှိဘဲ အလုပ်ဖြစ်လိမ့်မည်- သင်အသုံးပြုသည့်အမိန့်ကို run သောအခါ၊ ၎င်းသည် EC2 ဆာဗာသုံးခုကိုဖန်တီးလိမ့်မည်။ ဒါပေမယ့် မင်းရဲ့ လက်ရှိ AWS ဒေသအတွင်း Availability Zone (AZ) တစ်ခုစီမှာ ဆာဗာတစ်ခုကို အသုံးချချင်တယ်ဆိုရင်ကော။ သင့်ကုဒ်သည် aws_availability_zones ဒေတာရင်းမြစ်မှ ဇုန်များစာရင်းကို တင်နိုင်ပြီး တစ်ခုချင်းစီကို လှည့်ပတ်ကာ အရေအတွက်ကန့်သတ်ချက်နှင့် array အညွှန်းကို အသုံးပြု၍ ၎င်းတွင် 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 အရင်းအမြစ်၏ count parameter တွင် ဤအရင်းအမြစ်၏ output ကိုအသုံးပြုရန်ကြိုးစားပါက ဘာဖြစ်သွားသည်ကို ကြည့်ကြပါစို့။

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

သင်သည် ဤကုဒ်တွင် terraform အစီအစဉ်ကို လုပ်ဆောင်ပါက၊ သင်သည် အောက်ပါ အမှားကို ရရှိလိမ့်မည်-

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 သည် စာသားများ၊ ကိန်းရှင်များ၊ ဒေတာရင်းမြစ်များနှင့် အရင်းအမြစ်စာရင်းများကိုပင် ရည်ညွှန်းနိုင်သည် (အချိန်ဇယားဆွဲထားသည့်အချိန်၌ ၎င်းတို့၏အရှည်ကို ဆုံးဖြတ်နိုင်သရွေ့)၊ သို့သော် တွက်ချက်ထားသော အရင်းအမြစ်အထွက်ကိန်းရှင်များသို့ မဟုတ်ပါ။

count နှင့် for_each ကို module configuration တွင် အသုံးမပြုနိုင်ပါ။

တစ်နေ့နေ့တွင် သင့် module configuration တွင် count parameter တစ်ခုထည့်ရန် သွေးဆောင်ခံရနိုင်သည်-

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

     count = 3

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

ဤကုဒ်သည် webserver-cluster ရင်းမြစ်၏မိတ္တူသုံးမျိုးဖန်တီးရန် module တစ်ခုအတွင်း၌ count ကိုအသုံးပြုရန် ကြိုးစားသည်။ သို့မဟုတ် ၎င်း၏ count parameter ကို 0 သို့ သတ်မှတ်ခြင်းဖြင့် Boolean အခြေအနေအချို့အပေါ် မူတည်၍ module တစ်ခုကို စိတ်ကြိုက်ရွေးချယ်၍ ချိတ်ဆက်ခြင်းကို ပြုလုပ်လိုပေမည်။ ၎င်းသည် ကျိုးကြောင်းဆီလျော်သော ကုဒ်ကဲ့သို့ ဖြစ်ကောင်းဖြစ်နိုင်သော်လည်း terraform အစီအစဉ်ကို လုပ်ဆောင်သည့်အခါတွင် သင်သည် ဤအမှားကို ရရှိလိမ့်မည်-

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 အရ၊ module အရင်းအမြစ်တစ်ခုရှိ count သို့မဟုတ် for_each ကိုအသုံးပြုခြင်းကို ပံ့ပိုးမထားပါ။ Terraform 0.12 ထုတ်ဝေမှုမှတ်စုများ (http://bit.ly/3257bv4) အရ HashiCorp သည် ဤစွမ်းရည်ကို အနာဂတ်တွင် ထည့်သွင်းရန် စီစဉ်ထားသည်၊ ထို့ကြောင့် ဤစာအုပ်ကို သင်ဖတ်သည့်အချိန်ပေါ်မူတည်၍ ၎င်းကို ရနိုင်နေပြီဖြစ်သည်။ သေချာသိဖို့၊ Terraform changelog ကို ဒီမှာ ဖတ်ပါ။.

Zero Downtime Deployments ၏ ကန့်သတ်ချက်များ

ASG နှင့် ပေါင်းစပ်ထားသော create_before_destroy ဘလောက်ကို အသုံးပြုခြင်းသည် သတိပေးချက်တစ်ခုမှလွဲ၍ လုံးဝစက်ရပ်သွားခြင်းများကို ဖန်တီးခြင်းအတွက် အကောင်းဆုံးဖြေရှင်းချက်တစ်ခုဖြစ်သည်- အလိုအလျောက် အရွယ်အစားသတ်မှတ်ခြင်းစည်းမျဉ်းများကို ပံ့ပိုးမထားပါ။ သို့မဟုတ် ပိုမိုတိကျစေရန်၊ ၎င်းသည် ဖြန့်ကျက်မှုတိုင်းတွင် ASG အရွယ်အစားကို min_size သို့ ပြန်လည်သတ်မှတ်ပေးသည်၊ ၎င်းသည် အသုံးပြုနေသည့် ဆာဗာအရေအတွက်ကို တိုးမြှင့်ရန်အတွက် အလိုအလျောက်အတိုင်းအတာစည်းမျဉ်းများကို အသုံးပြုနေပါက ပြဿနာရှိနိုင်သည်။

ဥပမာအားဖြင့်၊ webserver-cluster module တွင် aws_autoscaling_schedule ရင်းမြစ်တစ်စုံပါရှိသည်၊ နံနက် 9 နာရီတွင် cluster ရှိ server အရေအတွက်ကို နှစ်ခုမှ ဆယ်ခုအထိတိုးစေသည်။ အကယ်၍ သင်သည် နံနက် ၁၁ နာရီတွင် ဖြန့်ကျက်မည်ဆိုပါက၊ ASG အသစ်သည် ဆယ်ခုထက် ဆာဗာနှစ်ခုသာ စတင်ဖွင့်မည်ဖြစ်ပြီး နောက်တစ်နေ့ နံနက် ၉ နာရီအထိ ယင်းပုံစံအတိုင်း ရှိနေမည်ဖြစ်သည်။

ဤကန့်သတ်ချက်ကို နည်းလမ်းများစွာဖြင့် ကျော်လွှားနိုင်သည်။

• aws_autoscaling_schedule တွင် 0 9 * * * ("မနက် 9 နာရီတွင် လည်ပတ်သည်") မှ 0-59 9-17 * * * ("မိနစ်တိုင်း 9 နံနက် 5 နာရီမှ ညနေ XNUMX နာရီအထိ") သို့ ပြန်ဖြစ်ခြင်း ကန့်သတ်ဘောင်ကို ပြောင်းပါ။ ASG တွင် ဆာဗာဆယ်ခုရှိပြီးဖြစ်ပါက၊ ဤအလိုအလျောက်စကေးချဲ့ခြင်းစည်းမျဉ်းကို ထပ်မံလုပ်ဆောင်ခြင်းသည် ကျွန်ုပ်တို့လိုချင်သည့်အရာဖြစ်ပြီး မည်သည့်အရာကိုမျှ ပြောင်းလဲမည်မဟုတ်ပါ။ သို့သော် ASG ကို မကြာသေးမီကမှ ဖြန့်ကျက်ထားပါက၊ ဤစည်းမျဉ်းသည် ၎င်း၏ဆာဗာများ၏ အများဆုံးတစ်မိနစ်အတွင်း အရေအတွက် ဆယ်ခုသို့ရောက်ရှိရန် သေချာစေမည်ဖြစ်သည်။ ဤသည်မှာ လုံးဝကို အံဝင်ခွင်ကျ ချဉ်းကပ်မှုမဟုတ်ပါ၊ ဆယ်ခုမှ ဆာဗာနှစ်ခုနှင့် နောက်သို့ ကြီးမားသော ခုန်ခြင်းများသည်လည်း သုံးစွဲသူများအတွက် ပြဿနာဖြစ်စေနိုင်သည်။
• ASG တွင်တက်ကြွသောဆာဗာအရေအတွက်ကိုဆုံးဖြတ်ရန် AWS API ကိုအသုံးပြုသည့်စိတ်ကြိုက် script တစ်ခုကိုဖန်တီးပါ၊ ၎င်းကိုပြင်ပဒေတာအရင်းအမြစ်ကိုအသုံးပြု၍ခေါ်ဆိုပါ (စာမျက်နှာ 249 တွင် "ပြင်ပဒေတာအရင်းအမြစ်" ကိုကြည့်ပါ) နှင့် ASG ၏အလိုရှိသော_capacity ကန့်သတ်ဘောင်ကို ပြန်ပေးသည့်တန်ဖိုးအဖြစ် သတ်မှတ်ပါ။ ဇာတ်ညွှန်း။ ဤနည်းအားဖြင့်၊ ASG အသစ်တစ်ခုစီသည် လက်ရှိ Terraform ကုဒ်ကဲ့သို့ တူညီသောစွမ်းရည်ဖြင့် အမြဲလည်ပတ်နေမည်ဖြစ်ပြီး ထိန်းသိမ်းရန် ပိုမိုခက်ခဲစေသည်။

ဟုတ်ပါတယ်၊ Terraform သည် လုံးဝစက်ရပ်သွားခြင်းများအတွက် စံပြအားဖြင့် Built-in ပံ့ပိုးမှုရှိပြီး၊ သို့သော် 2019 ခုနှစ် မေလတွင် HashiCorp အဖွဲ့သည် ဤလုပ်ဆောင်ချက်ကို ထည့်သွင်းရန် အစီအစဉ်မရှိပါ (အသေးစိတ် - ဒီမှာ).

မှန်ကန်သောအစီအစဥ်ကို မအောင်မြင်နိုင်ပါ။

တစ်ခါတစ်ရံတွင် plan command သည် ပြီးပြည့်စုံသော မှန်ကန်သော ဖြန့်ကျက်မှု အစီအစဉ်ကို ဖန်တီးပေးသော်လည်း အသုံးချသည့် command သည် error တစ်ခု ပြန်ပေးသည်။ ဥပမာအားဖြင့်၊ အခန်း 2 တွင် အစောပိုင်းက သင်ဖန်တီးခဲ့သော 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.

အကယ်၍ သင်သည် apply command ကို run ပါက အောက်ပါ error ကို ရရှိလိမ့်မည် ။

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 တွင် အသစ်ဝင်လာသူများကို အံ့အားသင့်စေသည့် ဤအမှားမျိုးကွဲများစွာရှိသည်။

အဓိကအချက်မှာ terraform plan command သည် Terraform state file တွင် သတ်မှတ်ထားသည့် အရင်းအမြစ်များကိုသာ ထည့်သွင်းတွက်ချက်ခြင်းဖြစ်သည်။ အရင်းအမြစ်များကို တစ်နည်းတစ်ဖုံ ဖန်တီးထားလျှင် (ဥပမာ၊ AWS ကွန်ဆိုးလ်တွင် ကိုယ်တိုင်ကလစ်နှိပ်ခြင်းဖြင့်) ၎င်းတို့သည် ပြည်နယ်ဖိုင်တွင် အကျုံးဝင်မည်မဟုတ်သောကြောင့် Terraform သည် အစီအစဉ်အမိန့်ကို လုပ်ဆောင်သည့်အခါ ၎င်းတို့ကို ထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ။ ရလဒ်အနေဖြင့်၊ ပထမတစ်ချက်တွင် မှန်ကန်သည်ဟုထင်ရသော အစီအစဉ်သည် မအောင်မြင်တော့ပါ။

ဒီကနေ သင်ခန်းစာယူစရာ နှစ်ခုရှိတယ်။

• သင် Terraform နှင့် စတင်လုပ်ဆောင်နေပြီဆိုလျှင်၊ အခြားမည်သည့်အရာကိုမျှ မသုံးပါနှင့်။ သင်၏အခြေခံအဆောက်အအုံ၏အစိတ်အပိုင်းကို Terraform ကိုအသုံးပြု၍ စီမံခန့်ခွဲပါက၊ ၎င်းကို သင်ကိုယ်တိုင်မွမ်းမံနိုင်တော့မည်မဟုတ်ပါ။ မဟုတ်ပါက၊ သင်သည် ထူးဆန်းသော Terraform အမှားများကို စွန့်စားရုံသာမက IaC ၏ အကျိုးကျေးဇူးများစွာကိုလည်း ငြင်းဆိုထားသောကြောင့် ကုဒ်သည် သင်၏အခြေခံအဆောက်အဦ၏ တိကျသောကိုယ်စားပြုမှုမဟုတ်တော့ပါ။
• သင့်တွင် အခြေခံအဆောက်အအုံအချို့ရှိနေပြီဆိုလျှင်၊ တင်သွင်းသည့်အမိန့်ကို အသုံးပြုပါ။ လက်ရှိအခြေခံအဆောက်အအုံဖြင့် Terraform ကို စတင်အသုံးပြုနေပါက၊ Terraform တင်သွင်းမှုအမိန့်ကို အသုံးပြု၍ ၎င်းကို ပြည်နယ်ဖိုင်တွင် ထည့်သွင်းနိုင်သည်။ ဤနည်းဖြင့် Terraform သည် မည်သည့်အခြေခံအဆောက်အအုံကို စီမံခန့်ခွဲရန် လိုအပ်သည်ကို သိရှိမည်ဖြစ်သည်။ တင်သွင်းသည့်အမိန့်သည် အငြင်းအခုံနှစ်ခုကို ယူသည်။ ပထမအချက်မှာ သင်၏ဖွဲ့စည်းပုံဖိုင်များတွင် ရင်းမြစ်လိပ်စာဖြစ်သည်။ ဤနေရာတွင် syntax သည် အရင်းအမြစ်လင့်ခ်များအတွက် တူညီသည်- _. (aws_iam_user.existing_user ကဲ့သို့)။ ဒုတိယအငြင်းအခုံသည် တင်သွင်းရမည့် အရင်းအမြစ်၏ ID ဖြစ်သည်။ အရင်းအမြစ် ID aws_iam_user သည် အသုံးပြုသူအမည် (ဥပမာ၊ yevgeniy.brikman) ဖြစ်ပြီး အရင်းအမြစ် ID aws_instance သည် EC2 ဆာဗာ ID (i-190e22e5 ကဲ့သို့) ဆိုကြပါစို့။ အရင်းအမြစ်တစ်ခုအား တင်သွင်းပုံအား ၎င်း၏စာမျက်နှာအောက်ခြေရှိ စာရွက်စာတမ်းများတွင် ညွှန်ပြတတ်သည်။

  အောက်တွင် သင်အခန်း 2 ရှိ IAM အသုံးပြုသူနှင့်အတူ သင်၏ Terraform ဖွဲ့စည်းမှုပုံစံတွင် သင်ထည့်သွင်းထားသည့် aws_iam_user ရင်းမြစ်ကို ထပ်တူပြုသော သွင်းကုန်အမိန့်တစ်ခုဖြစ်သည် (အမှန်ပင် သင့်အမည်ကို yevgeniy.brikman ဖြင့် အစားထိုးနေသည်)။

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform သည် သင်၏ IAM အသုံးပြုသူကို ရှာရန် AWS API ကို ခေါ်ပြီး ၎င်းနှင့် သင်၏ Terraform ဖွဲ့စည်းမှုစနစ်တွင် aws_iam_user.existing_user ရင်းမြစ်ကြားရှိ ပြည်နယ်ဖိုင်ချိတ်ဆက်မှုတစ်ခုကို ဖန်တီးပါမည်။ ယခုအချိန်မှစ၍၊ အစီအစဉ်အမိန့်ကို သင်လုပ်ဆောင်သည့်အခါ၊ Terraform သည် IAM အသုံးပြုသူရှိနှင့်ပြီးဖြစ်ကြောင်းနှင့် ၎င်းကို ထပ်မံဖန်တီးရန် ကြိုးစားမည်မဟုတ်ကြောင်း Terraform မှ သိရှိမည်ဖြစ်သည်။

  Terraform တွင် သင်ထည့်သွင်းလိုသည့် အရင်းအမြစ်များစွာရှိနေပြီဆိုလျှင်၊ ကုဒ်ကို ကိုယ်တိုင်ရေးပြီး တစ်ခုချင်းစီကို တစ်ကြိမ်စီ တင်သွင်းရာတွင် အခက်အခဲဖြစ်နိုင်သည်ကို သတိပြုသင့်သည်။ ထို့ကြောင့် Terraforming (http://terraforming.dtan4.net/) ကဲ့သို့ သင်၏ AWS အကောင့်မှ ကုဒ်နှင့် ပြည်နယ်များကို အလိုအလျောက် တင်သွင်းနိုင်သည့် ကိရိယာတစ်ခုကို ရှာဖွေရကျိုးနပ်ပါသည်။

  ပြန်လည်ပြုပြင်ခြင်းသည် ၎င်း၏ ချို့ယွင်းချက်များ ရှိနိုင်သည်။

  ပြန်လည်ပြုပြင်ခြင်း။ ပြင်ပအပြုအမူကို မပြောင်းလဲဘဲ ထားခဲ့စဉ်တွင် သင်သည် code ၏အတွင်းပိုင်းတည်ဆောက်ပုံအား ပြောင်းလဲသည့် ပရိုဂရမ်ရေးသားခြင်းတွင် လုပ်ရိုးလုပ်စဉ်တစ်ခုဖြစ်သည်။ ၎င်းသည် ကုဒ်ကို ပိုမိုရှင်းလင်းစေရန်၊ သပ်ရပ်ပြီး ထိန်းသိမ်းရလွယ်ကူစေရန်ဖြစ်သည်။ ပြန်လည်ပြုပြင်ခြင်းသည် မရှိမဖြစ်လိုအပ်သော နည်းပညာတစ်ခုဖြစ်ပြီး ပုံမှန်အသုံးပြုသင့်သည်။ Terraform သို့မဟုတ် အခြားသော IaC tool တစ်ခုခုနှင့် ပတ်သက်လာသောအခါ၊ သင်သည် ကုဒ်အပိုင်းအစ၏ "ပြင်ပအပြုအမူ" ၏ ဆိုလိုရင်းကို အလွန်သတိထားရမည်၊ မဟုတ်ပါက မမျှော်လင့်ထားသော ပြဿနာများ ပေါ်ပေါက်လာမည်ဖြစ်သည်။

  ဥပမာအားဖြင့်၊ အများအားဖြင့် refactoring အမျိုးအစားသည် ပိုမိုနားလည်နိုင်သော ကိန်းရှင်များ သို့မဟုတ် လုပ်ဆောင်ချက်များ၏ အမည်များကို အစားထိုးခြင်းဖြစ်သည်။ IDE အများအပြားတွင် ပြန်လည်ပြုပြင်ခြင်းအတွက် built-in ပံ့ပိုးမှုရှိပြီး ပရောဂျက်တစ်လျှောက်လုံးတွင် ပြောင်းလဲနိုင်သော ကိန်းရှင်များနှင့် လုပ်ဆောင်ချက်များကို အလိုအလျောက် အမည်ပြောင်းနိုင်ပါသည်။ ယေဘူယျအားဖြင့် ရည်ရွယ်ထားသော ပရိုဂရမ်းမင်းဘာသာစကားများတွင်၊ ၎င်းသည် သင်မစဉ်းစားနိုင်သော အသေးအဖွဲလုပ်ငန်းစဉ်တစ်ခုဖြစ်သော်လည်း Terraform တွင် သင်သည် ၎င်းကို အလွန်သတိထားရမည်ဖြစ်ပြီး သို့မဟုတ်ပါက သင်သည် ပြတ်တောက်မှုများကြုံတွေ့ရနိုင်သည်။

  ဥပမာအားဖြင့်၊ webserver-cluster module တွင် input variable cluster_name ရှိသည်-

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

  foo ဟုခေါ်သော မိုက်ခရိုဆားဗစ်ကို အသုံးပြုရန်အတွက် သင်သည် ဤ module ကို စတင်အသုံးပြုသည်ဟု မြင်ယောင်ကြည့်ပါ။ နောက်ပိုင်းတွင်၊ သင်သည် သင်၏ဝန်ဆောင်မှုကို ဘားအဖြစ် အမည်ပြောင်းလိုပါသည်။ ဤပြောင်းလဲမှုသည် အသေးအဖွဲဟု ထင်ရသော်လည်း လက်တွေ့တွင် ၎င်းသည် ဝန်ဆောင်မှုကို အနှောင့်အယှက်ဖြစ်စေနိုင်သည်။

  အမှန်မှာ webserver-cluster module သည် လုံခြုံရေးအုပ်စုနှစ်စုနှင့် ALB ၏ name parameter အပါအဝင် အရင်းအမြစ်အများအပြားတွင် cluster_name variable ကိုအသုံးပြုသည်-

  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 ကိုပြောင်းလဲခြင်းပင်ဖြစ်သည်။ နမူနာအဖြစ် webserver-cluster module ရှိ aws_security_group အရင်းအမြစ်ကို ယူကြပါစို့။

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

  ဤရင်းမြစ်၏ ခွဲခြားသတ်မှတ်ခြင်းကို instance ဟုခေါ်သည်။ ပြန်လည်ပြုပြင်ခြင်းတွင် သင်သည် ၎င်းအား ပိုမိုနားလည်နိုင်သော (သင့်ထင်မြင်ယူဆချက်) အမည် cluster_instance သို့ ပြောင်းလဲရန် ဆုံးဖြတ်ခဲ့သည်ကို စိတ်ကူးကြည့်ပါ-

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

  အဆုံးမှာ ဘာဖြစ်မလဲ။ မှန်တယ်- အနှောင့်အယှက်တစ်ခု။

  Terraform သည် အရင်းအမြစ် ID တစ်ခုစီကို cloud ဝန်ဆောင်မှုပေးသူ ID နှင့် ဆက်စပ်သည်။ ဥပမာအားဖြင့်၊ iam_user သည် AWS IAM အသုံးပြုသူ ID နှင့် ဆက်စပ်နေပြီး aws_instance သည် AWS EC2 ဆာဗာ ID နှင့် ဆက်စပ်နေသည်။ အကယ်၍ သင်သည် အရင်းအမြစ် ID (instance မှ cluster_instance သို့၊ aws_security_group ကဲ့သို့) Terraform သို့ ပြောင်းပါက၊ သင်သည် အရင်းအမြစ်ဟောင်းကို ဖျက်ပြီး အသစ်တစ်ခု ထပ်ထည့်လိုက်ခြင်းကဲ့သို့ ပေါ်လာလိမ့်မည်။ ဤအပြောင်းအလဲများကို သင်အသုံးပြုပါက၊ Terraform သည် လုံခြုံရေးအဖွဲ့ဟောင်းကို ဖျက်ပြီး အသစ်တစ်ခုဖန်တီးမည်ဖြစ်ပြီး၊ သင်၏ဆာဗာများသည် ကွန်ရက်အသွားအလာကို စတင်ပယ်ချနေချိန်တွင် Terraform မှ လုပ်ဆောင်ပေးမည်ဖြစ်သည်။

  ဤသည်မှာ ဤဆွေးနွေးမှုမှ သင်ယူသင့်သည့် အဓိကသင်ခန်းစာလေးခုဖြစ်သည်။

  • အစီအစဉ်အမိန့်ကို အမြဲသုံးပါ။ ဤအရာများအားလုံးကို ဖော်ထုတ်ပြသနိုင်သည်။ ၎င်း၏ထွက်ရှိမှုကို ဂရုတစိုက်ပြန်လည်သုံးသပ်ပြီး Terraform သည် မဖျက်သင့်သော အရင်းအမြစ်များကို ဖျက်ပစ်မည့် အခြေအနေများကို အာရုံစိုက်ပါ။
  • မဖျက်ခင် ဖန်တီးပါ။ ရင်းမြစ်တစ်ခုအား အစားထိုးလိုပါက မူရင်းကိုမဖျက်မီ အစားထိုးတစ်ခုဖန်တီးရန် လိုအပ်သည်ဆိုသည်ကို သေချာစဉ်းစားပါ။ အဖြေက ဟုတ်တယ်ဆိုရင် create_before_destroy က ကူညီနိုင်ပါတယ်။ အဆင့်နှစ်ဆင့်ကို လုပ်ဆောင်ခြင်းဖြင့် တူညီသောရလဒ်ကို ကိုယ်တိုင်ရရှိနိုင်သည်- ပထမဦးစွာ ရင်းမြစ်အသစ်တစ်ခုကို ဖွဲ့စည်းမှုပုံစံတွင် ထည့်သွင်းပြီး သက်ဆိုင်သည့်အမိန့်ကို လုပ်ဆောင်ကာ၊ ထို့နောက် အရင်းအမြစ်ဟောင်းကို ဖွဲ့စည်းမှုစနစ်မှ ဖယ်ရှားပြီး လျှောက်ထားသည့်အမိန့်ကို ထပ်မံအသုံးပြုပါ။
  • ခွဲခြားသတ်မှတ်မှုများကို ပြောင်းလဲခြင်းသည် အခြေအနေကို ပြောင်းလဲရန် လိုအပ်သည်။ ရင်းမြစ်တစ်ခုနှင့်ဆက်စပ်နေသော ID ကိုပြောင်းလဲလိုပါက (ဥပမာ၊ aws_security_group အား instance မှ cluster_instance သို့) အမည်ပြောင်းလိုပါက၊ ၎င်း၏ဗားရှင်းအသစ်ကိုဖန်တီးလိုပါက Terraform ပြည်နယ်ဖိုင်ကို အပ်ဒိတ်လုပ်ရပါမည်။ ဒါကို ဘယ်တော့မှ ကိုယ်တိုင်မလုပ်ပါနဲ့ - အဲဒီအစား terraform state command ကိုသုံးပါ။ identifier များကို အမည်ပြောင်းသည့်အခါ၊ အောက်ပါ syntax ပါရှိသော terraform state mv command ကို run ရပါမည်။

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE သည် ၎င်း၏ လက်ရှိပုံစံရှိ အရင်းအမြစ်ကို ရည်ညွှန်းသည့် စကားရပ်ဖြစ်ပြီး NEW_REFERENCE သည် ၎င်းကို သင်ရွှေ့လိုသည့် နေရာဖြစ်သည်။ ဥပမာအားဖြင့်၊ aws_security_group အဖွဲ့အား instance မှ cluster_instance သို့ အမည်ပြောင်းသည့်အခါ၊ သင်သည် အောက်ပါ command ကို လုပ်ဆောင်ရန် လိုအပ်သည်-

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    ၎င်းသည် ယခင်က aws_security_group.instance နှင့် ယခင်က ဆက်စပ်ခဲ့သည့် အခြေအနေသည် aws_security_group.cluster_instance နှင့် ဆက်စပ်သင့်သည်ဟု Terraform အား ပြောပြသည်။ ဤ command terraform အစီအစဥ်ကို အမည်ပြောင်းပြီး လုပ်ဆောင်ပြီးနောက်တွင် မည်သည့်ပြောင်းလဲမှုမှ မပြပါက၊ သင်သည် အရာအားလုံးကို မှန်ကန်စွာ လုပ်ဆောင်ခဲ့သည်။

  • အချို့ဆက်တင်များကို ပြောင်းလဲ၍မရပါ။ အရင်းအမြစ်များစွာ၏ ကန့်သတ်ချက်များသည် ပြောင်းလဲ၍မရပါ။ ၎င်းတို့ကို ပြောင်းလဲရန် ကြိုးစားပါက Terraform သည် အရင်းအမြစ်ဟောင်းကို ဖျက်ပြီး ၎င်း၏နေရာတွင် အသစ်တစ်ခု ဖန်တီးမည်ဖြစ်သည်။ ရင်းမြစ်စာမျက်နှာတစ်ခုစီသည် အများအားဖြင့် သတ်မှတ်ဆက်တင်တစ်ခုကို သင်ပြောင်းလဲသောအခါ ဘာဖြစ်သွားသည်ကို ညွှန်ပြပေးမည်ဖြစ်သောကြောင့် စာရွက်စာတမ်းများကို သေချာစစ်ဆေးပါ။ အစီအစဉ်အမိန့်ကို အမြဲတမ်းအသုံးပြုပြီး create_before_destroy နည်းဗျူဟာကို အသုံးပြုရန် စဉ်းစားပါ။

  Deferred ညီညွတ်မှုသည်... ရွှေ့ဆိုင်းခြင်းနှင့် တသမတ်တည်းဖြစ်သည်။

  AWS ကဲ့သို့ အချို့သော cloud ဝန်ဆောင်မှုပေးသူများ၏ API များသည် တစ်ပြိုင်နက်တည်း နှောင့်နှေးကြန့်ကြာမှုရှိသည်။ Asynchrony ဆိုသည်မှာ အင်တာဖေ့စ်သည် တောင်းဆိုထားသောလုပ်ဆောင်ချက်ကို ပြီးမြောက်အောင်မစောင့်ဘဲ တုံ့ပြန်မှုကို ချက်ချင်းပြန်ပေးနိုင်သည်ဟု ဆိုလိုသည်။ နှောင့်နှေးနေသော တစ်သမတ်တည်းဖြစ်သော အပြောင်းအလဲများသည် စနစ်တစ်ခုလုံးတွင် ပြန့်ပွားရန် အချိန်ယူရနိုင်သည်၊ ထိုသို့ဖြစ်နေချိန်တွင် သင်၏တုံ့ပြန်မှုများသည် ကွဲလွဲနေပြီး မည်သည့်ဒေတာရင်းမြစ်ပုံတူသည် သင်၏ API ခေါ်ဆိုမှုများကို တုံ့ပြန်သည့်အပေါ် မူတည်ပါသည်။

  ဥပမာအားဖြင့်၊ သင်သည် EC2 ဆာဗာတစ်ခုဖန်တီးရန် AWS သို့ API ခေါ်ဆိုမှုကို ပြုလုပ်သည်ဟု မြင်ယောင်ကြည့်ပါ။ API သည် ဆာဗာကိုယ်တိုင်ဖန်တီးရန် မစောင့်ဆိုင်းဘဲ "အောင်မြင်သော" တုံ့ပြန်မှု (201 Created) ကို ချက်ချင်းပြန်ပေးပါမည်။ ၎င်းကိုချက်ချင်းချိတ်ဆက်ရန်ကြိုးစားပါက၊ ထိုအချိန်တွင် AWS သည် အရင်းအမြစ်များကို စတင်လုပ်ဆောင်နေသေးသည် သို့မဟုတ် တစ်နည်းအားဖြင့် ဆာဗာသည် မဖွင့်ရသေးသောကြောင့် သေချာပေါက်နီးပါးပျက်သွားမည်ဖြစ်သည်။ ထို့အပြင်၊ သင်သည် ဤဆာဗာနှင့်ပတ်သက်သည့် အချက်အလက်ကိုရယူရန် နောက်ထပ်ခေါ်ဆိုပါက၊ သင်သည် အမှားအယွင်း (404 Not Found) ကို ရရှိနိုင်ပါသည်။ ဤအရာသည် ဤ 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

  တစ်နည်းဆိုရသော် သင်သည် ရင်းမြစ်တစ်ခု (subnet တစ်ခုကဲ့သို့) ဖန်တီးပြီး ၎င်းနှင့်ပတ်သက်သည့် အချက်အလက်အချို့ (အသစ်ဖန်တီးထားသော subnet ၏ ID ကဲ့သို့) ကိုရယူရန်ကြိုးစားပြီး Terraform သည် ၎င်းကို ရှာမတွေ့ပါ။ ဤချို့ယွင်းချက်အများစု (6813 အပါအဝင်) ကို ပြင်ဆင်ပြီးသော်လည်း၊ အထူးသဖြင့် Terraform သည် အရင်းအမြစ်အမျိုးအစားအသစ်အတွက် ပံ့ပိုးမှုထည့်သည့်အခါတွင် ၎င်းတို့သည် အခါအားလျော်စွာ ဖြတ်တောက်ဆဲဖြစ်သည်။ ဒါက စိတ်အနှောက်အယှက်ဖြစ်ပေမဲ့ ကိစ္စတော်တော်များများမှာ ဘာအန္တရာယ်မှ မဖြစ်စေပါဘူး။ သင် terraform ကိုထပ်မံအသုံးပြုသောအခါ၊ အရာအားလုံးသည်အလုပ်လုပ်သင့်သည်၊ အဘယ်ကြောင့်ဆိုသော်ဤအချိန်တွင်အချက်အလက်များသည်စနစ်တစ်ခုလုံးပျံ့နှံ့သွားလိမ့်မည်။

  ဤကောက်နုတ်ချက်ကို Evgeniy Brikman ၏ စာအုပ်မှ တင်ပြထားပါသည်။ "Terraform- ကုဒ်အဆင့်ရှိ အခြေခံအဆောက်အဦ".

source: www.habr.com