အနာဂတ်အတွက် Terraform ရှိ အခြေခံအဆောက်အဦ၏ ရှင်းလင်းချက်။ Anton Babenko (2018)

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

သင်၏အခြေခံအဆောက်အအုံသည် ရိုးရှင်းသလောက်သေချာသည်- အရင်းအမြစ်အနည်းငယ် + developer အနည်းငယ်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ လမ်းကြောင်းအမျိုးမျိုးတွင် ကြီးထွားလာသည်။ Terraform modules များတွင် အရင်းအမြစ်များကို အုပ်စုဖွဲ့ရန်၊ ကုဒ်များကို ဖိုဒါများအဖြစ် စုစည်းရန် နည်းလမ်းများကို သင်ရှာတွေ့ပါသလား၊ အခြားဘာများ မှားသွားနိုင်ပါသလဲ။ (နာမည်ကြီး နောက်ဆုံးစကား)

အချိန်တွေကုန်လွန်သွားပြီး မင်းရဲ့အခြေခံအဆောက်အအုံက မင်းအိမ်မွေးတိရစ္ဆာန်အသစ်လိုခံစားရပေမယ့် ဘာကြောင့်လဲ။ အခြေခံအဆောက်အဦများတွင် နားမလည်နိုင်သော ပြောင်းလဲမှုများအတွက် သင်စိုးရိမ်နေရသည်၊ အခြေခံအဆောက်အဦနှင့် ကုဒ်ကို ထိရန်ကြောက်နေပါသည် - ရလဒ်အနေဖြင့် သင်သည် လုပ်ဆောင်ချက်အသစ်များကို နှောင့်နှေးစေသည် သို့မဟုတ် အရည်အသွေးကို လျှော့ချလိုက်သည်...

Github ရှိ AWS အတွက် Terraform community modules အစုအဝေးကို သုံးနှစ်ကြာ စီမံခန့်ခွဲပြီးနောက်၊ ထုတ်လုပ်ရေးတွင် Terraform ကို ရေရှည်ထိန်းသိမ်းမှုပြုလုပ်ပြီးနောက် Anton Babenko သည် ၎င်း၏အတွေ့အကြုံကို မျှဝေရန် အသင့်ရှိနေပါသည်- အနာဂတ်တွင် မထိခိုက်စေရန် TF module များကို မည်သို့ရေးရမည်နည်း။

ဟောပြောချက်အပြီးတွင် ပါဝင်သူများသည် Terraform ရှိ အရင်းအမြစ်စီမံခန့်ခွဲမှုမူများ၊ Terraform ရှိ module များနှင့်ဆက်စပ်သော အကောင်းဆုံးအလေ့အကျင့်များနှင့် အခြေခံအဆောက်အအုံစီမံခန့်ခွဲမှုနှင့်ဆက်စပ်သော စဉ်ဆက်မပြတ်ပေါင်းစပ်မှုအချို့နှင့် အခြေခံမူများကို ပိုမိုရင်းနှီးလာမည်ဖြစ်ပါသည်။

မသက်ဆိုင်ကြောင်းရှင်းလင်းချက်: ဤအစီရင်ခံစာသည် 2018 ခုနှစ် နိုဝင်ဘာလ ရက်စွဲပါ — 2 နှစ်ကျော်သွားပြီဖြစ်ကြောင်း ကျွန်ုပ် သတိပြုမိပါသည်။ အစီရင်ခံစာတွင် ဆွေးနွေးထားသော Terraform 0.11 ဗားရှင်းကို ပံ့ပိုးမပေးတော့ပါ။ ပြီးခဲ့သော 2 နှစ်အတွင်း ဖြန့်ချိမှုအသစ် 2 ခုကို ထုတ်ဝေခဲ့ပြီး၊ ဆန်းသစ်မှု၊ မြှင့်တင်မှုများနှင့် အပြောင်းအလဲများစွာ ပါဝင်ပါသည်။ ဒါကို အာရုံစိုက်ပြီး စာရွက်စာတမ်းတွေကို စစ်ဆေးပါ။

လင့်ခ်များ

• terraform-community-modules + terraform-aws-modules
• antonbabenko/pre-commit-terraform — အလိုအလျောက်ဖော်မတ်ကုဒ်နှင့် စာရွက်စာတမ်းများ
• antonbabenko/terrapin - Terraform modules (WIP) ၏ generator
• antonbabenko/modules.tf-lambda - ရုပ်ပုံကားချပ်များ (WIP) မှ Terraform ကုဒ်မီးစက်
• www.terraform-best-practices.com
• medium.com/@anton.babenko (ပို့စ်အသစ်များသည် ကျွန်ုပ်၏ကိုယ်ပိုင်ဝဘ်ဆိုဒ် www.antonbabenko.com/ တွင်ဖြစ်သည်)
• @antonbabenko - Twitter နှင့် မတူညီသော Slacks များ

ကျွန်တော့်နာမည်က Anton Babenko ပါ။ တစ်ချို့က ကျွန်တော်ရေးထားတဲ့ ကုဒ်ကို သုံးဖူးတယ်။ ကျွန်ုပ်သည် ကိန်းဂဏန်းစာရင်းအင်းများကို တတ်နိုင်သောကြောင့် ယခု ဤအကြောင်းကို ယခင်ကထက် ပိုမိုယုံကြည်စွာ ပြောဆိုပါမည်။

ကျွန်ုပ်သည် Terraform တွင်အလုပ်လုပ်ပြီး Terraform နှင့် Amazon နှင့် ဆက်စပ်သော open source ပရောဂျက်အများအပြားတွင် တက်ကြွစွာပါဝင်သူဖြစ်ပြီး 2015 ခုနှစ်ကတည်းက ပါဝင်ခဲ့ပါသည်။

အဲဒီကတည်းက စိတ်ဝင်စားစရာကောင်းတဲ့ နည်းလမ်းနဲ့ ထည့်ဖို့ လုံလောက်တဲ့ ကုဒ်ကို ငါရေးခဲ့တယ်။ ပြီးတော့ ဒီအကြောင်းကို အခုပြောပြဖို့ ကြိုးစားပါ့မယ်။

Terraform နှင့်အလုပ်လုပ်ခြင်း၏ရှုပ်ထွေးပွေလီသောအသေးစိတ်အချက်များအကြောင်းပြောပါမည်။ ဒါပေမယ့် အဲဒါက HighLoad ရဲ့အကြောင်းအရာမဟုတ်ပါဘူး။ ယခုမူ သင်သည် အဘယ့်ကြောင့်ဆိုသည်ကို နားလည်လိမ့်မည်။

အချိန်ကြာလာသည်နှင့်အမျှ ကျွန်ုပ်သည် Terraform modules များကို စတင်ရေးသားခဲ့သည်။ သုံးစွဲသူတွေက မေးခွန်းတွေ ရေးတယ်၊ ကျွန်တော်က သူတို့ကို ပြန်ရေးတယ်။ ထို့နောက် pre-commit hook စသည်တို့ကို အသုံးပြု၍ code ကို format လုပ်ရန် utilities အမျိုးမျိုးကို ရေးသားခဲ့သည်။

စိတ်ဝင်စားစရာကောင်းတဲ့ ပရောဂျက်တွေ အများကြီးရှိခဲ့တယ်။ ကျွန်ုပ်နှင့် ပရိုဂရမ်မာများအတွက် ကွန်ပြူတာအား ပို၍ပို၍ အလုပ်ပိုလုပ်ရသည်ကို နှစ်သက်သောကြောင့် ကုဒ်ထုတ်လုပ်ခြင်းကို နှစ်သက်သည်၊ ထို့ကြောင့် လက်ရှိတွင် မြင်သာသည့်ပုံချပ်များမှ Terraform code generator တွင် အလုပ်လုပ်နေပါသည်။ သင်တို့တွင် အချို့သောသူတို့ကို မြင်ဖူးကြလိမ့်မည်။ ဤအရာများသည် မြှားများဖြင့် လှပသောသေတ္တာများဖြစ်သည်။ “Export” ခလုတ်ကို နှိပ်ပြီး ကုဒ်အဖြစ် အားလုံးယူနိုင်ရင် ကောင်းမယ်ထင်တယ်။

ကျွန်တော်က ယူကရိန်းကပါ။ နော်ဝေးမှာ နှစ်အတော်ကြာနေခဲ့တယ်။

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

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

ကျွန်ုပ်ဖော်ပြခဲ့သည့်အတိုင်း၊ ကျွန်ုပ်သည် အသုံးအများဆုံးအလုပ်များအတွက် GitHub တွင်အကြီးဆုံးသိုလှောင်ရာတစ်ခုဖြစ်သည့် Terraform AWS modules ၏အဓိကထိန်းသိမ်းသူဖြစ်သည်- VPC၊ Autoscaling၊ RDS။

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

Terraform သည် သင့်အား ကုဒ်အဖြစ် ရေးသားရန်၊ စီစဉ်စီမံရန်နှင့် စီမံရန်ခွင့်ပြုသည့် အသုံးဝင်မှုတစ်ခုအဖြစ် 2014 ခုနှစ်တွင် ပေါ်လာခဲ့သည်။ ဤနေရာတွင် အဓိက အယူအဆမှာ “အခြေခံအဆောက်အအုံကို ကုဒ်အဖြစ်” ဖြစ်သည်။

ကျွန်တော်ပြောခဲ့သလိုပဲ စာရွက်စာတမ်းတွေအားလုံးကို ရေးထားတယ်။ terraform.io. လူအများစုက ဒီဆိုက်အကြောင်း သိပြီး စာရွက်စာတမ်းတွေကို ဖတ်ဖူးမယ်လို့ မျှော်လင့်ပါတယ်။ သို့ဆိုလျှင် သင်သည် မှန်ကန်သောနေရာ၌ ရှိနေပါသည်။

ဤသည်မှာ ပုံမှန် Terraform configuration file နှင့်တူသည်၊ အချို့သော variable များကို ဦးစွာသတ်မှတ်ပါသည်။

ဤကိစ္စတွင်ကျွန်ုပ်တို့သည် "aws_region" ကိုသတ်မှတ်သည်။

ထို့နောက် ကျွန်ုပ်တို့ ဖန်တီးလိုသော အရင်းအမြစ်များကို ဖော်ပြပါ။

ကျွန်ုပ်တို့သည် မှီခိုမှုနှင့် ပံ့ပိုးပေးသူများကို တင်ရန်အတွက် အထူးသဖြင့် "terraform init" တွင် အချို့သော command များကို လုပ်ဆောင်ပါသည်။

ကျွန်ုပ်တို့သည် သတ်မှတ်ထားသောဖွဲ့စည်းပုံဖွဲ့စည်းပုံသည် ကျွန်ုပ်တို့ဖန်တီးထားသောအရင်းအမြစ်များနှင့်ကိုက်ညီမှုရှိမရှိစစ်ဆေးရန်အတွက် "terraform apply" command ကိုလုပ်ဆောင်ပါသည်။ ကျွန်ုပ်တို့သည် ယခင်က မည်သည့်အရာကိုမျှ မဖန်တီးရသေးသောကြောင့်၊ Terraform သည် ဤအရင်းအမြစ်များကို ဖန်တီးရန် ကျွန်ုပ်တို့အား တိုက်တွန်းပါသည်။

ဒါကို ကျနော်တို့ အတည်ပြုပါတယ်။ ဒါကြောင့် seasnail လို့ ခေါ်တဲ့ ပုံးကို ဖန်တီးတယ်။

အလားတူ အသုံးဝင်မှုများစွာလည်း ရှိပါသည်။ Amazon ကိုအသုံးပြုသူတော်တော်များများဟာ AWS CloudFormation သို့မဟုတ် Google Cloud Deployment Manager သို့မဟုတ် Azure Resource Manager ကို သိကြပါတယ်။ ၎င်းတို့တစ်ခုစီသည် အများသူငှာ cloud ဝန်ဆောင်မှုပေးသူတိုင်းအတွင်း အရင်းအမြစ်များကို စီမံခန့်ခွဲရန်အတွက် တစ်မျိုးမျိုးသော ကိုယ်ပိုင်အကောင်အထည်ဖော်မှုတစ်ခုစီရှိကြသည်။ Terraform သည် သင့်အား ပံ့ပိုးပေးသူ 100 ကျော်ကို စီမံခန့်ခွဲနိုင်သောကြောင့် အထူးအသုံးဝင်ပါသည်။ (အသေးစိတ်အချက်များ ဒီမှာ)

Terraform အစကတည်းက လိုက်လုပ်ခဲ့တဲ့ ပန်းတိုင်တွေ

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

2014 ခုနှစ်တွင် "ကြိုတင်ခန့်မှန်းနိုင်သော" ဟူသောစကားလုံးသည်ဤအခြေအနေတွင်အလွန်ပုံမှန်မဟုတ်သောအသံထွက်ခဲ့သည်။

Terraform သည် universal utility တစ်ခုဖြစ်သည်။ သင့်တွင် API တစ်ခုရှိပါက၊ အရာအားလုံးကို လုံးဝထိန်းချုပ်နိုင်သည်-

• သင်အလိုရှိသော အရာအားလုံးကို စီမံခန့်ခွဲရန် ဝန်ဆောင်မှုပေးသူ 120 ကျော်ကို သင်အသုံးပြုနိုင်ပါသည်။
• ဥပမာအားဖြင့်၊ သင်သည် GitHub repositories သို့ဝင်ရောက်ခွင့်ကိုဖော်ပြရန် Terraform ကိုသုံးနိုင်သည်။
• Jira တွင် bug များကို ဖန်တီးပြီး ပိတ်နိုင်သည်။
• New Relic မက်ထရစ်များကို သင် စီမံနိုင်သည်။
• သင်အမှန်တကယ်လုပ်ချင်ပါက dropbox တွင်ဖိုင်များကိုပင်ဖန်တီးနိုင်သည်။

Go တွင် ဖော်ပြနိုင်သည့် အဖွင့် API ပါရှိသော Terraform ဝန်ဆောင်မှုပေးသူများကို အသုံးပြု၍ ဤအရာအားလုံးကို အောင်မြင်သည်။

ကျွန်ုပ်တို့သည် Terraform ကိုစတင်အသုံးပြုခဲ့ပြီး၊ ဆိုက်ပေါ်ရှိ စာရွက်စာတမ်းအချို့ကိုဖတ်ကာ၊ ဗီဒီယိုအချို့ကိုကြည့်ရှုခဲ့ပြီး ယခင်ဆလိုက်များတွင် ကျွန်တော်ပြသထားသည့်အတိုင်း main.tf ကိုစတင်ရေးသားခဲ့သည်ဆိုကြပါစို့။

ပြီးတော့ အရာအားလုံးက ကောင်းတယ်၊ မင်းမှာ VPC ကိုဖန်တီးတဲ့ ဖိုင်တစ်ခုရှိတယ်။

အကယ်၍ သင်သည် VPC တစ်ခုကို ဖန်တီးလိုပါက၊ ခန့်မှန်းခြေအားဖြင့် ဤ 12 ကြောင်းကို သင်သတ်မှတ်ပါ။ မည်သည့်ဒေသတွင် သင်ဖန်တီးလိုသည်၊ မည်သည့် IP လိပ်စာများ၏ cidr_block ကို အသုံးပြုရမည်ကို ဖော်ပြပါ။ ဒါပါပဲ။

ထုံးစံအတိုင်း ပရောဂျက်က တဖြည်းဖြည်း ကြီးလာမယ်။

၎င်းတွင် သင်သည် ပစ္စည်းအသစ်အမြောက်အများကို ပေါင်းထည့်ပါမည်- အရင်းအမြစ်များ၊ ဒေတာရင်းမြစ်များ၊ ဝန်ဆောင်မှုပေးသူအသစ်များနှင့် ပေါင်းစည်းမည်၊ သင်၏ GitHub အကောင့်ရှိ သုံးစွဲသူများကို စီမံခန့်ခွဲရန် Terraform ကို ရုတ်တရက် အသုံးပြုလိုလိမ့်မည်၊ စသည်ဖြင့် သင်သည် မတူညီသောအသုံးပြုမှုများကို အသုံးပြုလိုပေမည်။ DNS ဝန်ဆောင်မှုပေးသူများ၊ အရာအားလုံးကိုဖြတ်ကျော်ပါ။ Terraform သည် ၎င်းကို လွယ်ကူစေသည်။

အောက်ပါဥပမာကိုကြည့်ကြပါစို့။

သင်၏ VPC မှ အရင်းအမြစ်များကို အင်တာနက် အသုံးပြုခွင့် ရလိုသောကြောင့် သင်သည် internet_gateway ကို တဖြည်းဖြည်း ထည့်သွင်းပါသည်။ ဒါက အကြံကောင်းပဲ။

ရလဒ်မှာ ဤ main.tf ဖြစ်သည်။

ဤသည်မှာ main.tf ၏ ထိပ်ပိုင်းဖြစ်သည်။

၎င်းသည် main.tf ၏ အောက်ဆုံးအပိုင်းဖြစ်သည်။

ထို့နောက်သင် subnet ကိုထည့်ပါ။ NAT ဂိတ်ဝေးများ၊ လမ်းကြောင်းများ၊ လမ်းကြောင်းဇယားများနှင့် အခြားသော subnets အများအပြားကို ထည့်သွင်းလိုသည့်အခါတွင် လိုင်း 38 လိုင်းရှိမည်မဟုတ်သော်လည်း ခန့်မှန်းခြေအားဖြင့် 200-300 လိုင်းများရှိပါသည်။

ဆိုလိုသည်မှာ သင်၏ main.tf ဖိုင်သည် တဖြည်းဖြည်း ကြီးထွားလာသည်။ မကြာခဏဆိုသလို လူတွေက အရာအားလုံးကို ဖိုင်တစ်ခုထဲမှာ ထည့်ထားတယ်။ 10-20 Kb သည် main.tf တွင် ပေါ်လာသည်။ 10-20 Kb သည် စာသားအကြောင်းအရာဖြစ်သည်ဟု မြင်ယောင်ကြည့်ပါ။ ပြီးတော့ အရာအားလုံးက အရာအားလုံးနဲ့ ဆက်စပ်နေတယ်။ ဒါကတဖြည်းဖြည်းနဲ့ အလုပ်လုပ်ရခက်လာတယ်။ 10-20 Kb သည် ကောင်းမွန်သော အသုံးပြုသူကိစ္စဖြစ်ပြီး တစ်ခါတစ်ရံ ပိုပါသည်။ ပြီးတော့ လူတွေက ဒါကို မကောင်းဘူးလို့ အမြဲမထင်ဘူး။

ပုံမှန်ပရိုဂရမ်ရေးခြင်းတွင်၊ ဆိုလိုသည်မှာ ကုဒ်ကဲ့သို့ အခြေခံအဆောက်အဦမဟုတ်ပါ၊ ကျွန်ုပ်တို့သည် မတူညီသော အတန်းများ၊ ပက်ကေ့ဂျ်များ၊ မော်ဂျူးများ၊ အုပ်စုခွဲခြင်းများစွာကို အသုံးပြုလေ့ရှိပါသည်။ Terraform သည် သင့်အား တူညီသောအရာများစွာပြုလုပ်နိုင်စေပါသည်။

• ကုဒ်တွေ များလာတယ်။
• အရင်းအမြစ်များကြားတွင် မှီခိုမှုများလည်း တိုးပွားလာပါသည်။

ပြီးတော့ ငါတို့မှာ ကြီးကြီးမားမား လိုအပ်ချက်တစ်ခုရှိတယ်။ ဒီလိုမျိုး ဆက်မနေနိုင်တော့ဘူးဆိုတာ နားလည်ပါတယ်။ ကျွန်ုပ်တို့၏ကုဒ်သည် ကြီးမားလာသည်။ 10-20 Kb သည် ကျယ်ပြောလှသည်မဟုတ်ပါ၊ သို့သော် ကျွန်ုပ်တို့သည် network stack အကြောင်းသာပြောနေသည်၊ ဆိုလိုသည်မှာ သင့်တွင် ကွန်ရက်အရင်းအမြစ်များသာ ရှိပါသည်။ ကျွန်ုပ်တို့သည် 100 Kb ကို အလွယ်တကူ ယက်လုပ်နိုင်သည့် Application Load Balancer၊ deployment ES အစုအဝေး၊ Kubernetes စသည်တို့အကြောင်း ကျွန်ုပ်တို့ မပြောပါ။ ဤအရာအားလုံးကို သင်ချရေးပါက၊ Terraform သည် Terraform modules များကို ပံ့ပိုးပေးကြောင်း မကြာမီ သင်သိရှိလာမည်ဖြစ်သည်။

Terraform modules များသည် အုပ်စုတစ်ခုအနေဖြင့် စီမံခန့်ခွဲသည့် ကိုယ်တိုင်ပါရှိသော Terraform ဖွဲ့စည်းမှုပုံစံတစ်ခုဖြစ်သည်။ Terraform modules များအကြောင်း သင်သိလိုသည်မှာ ဒါပါပဲ။ သူတို့ဟာ ဉာဏ်မမီဘူး၊ တစ်ခုခုပေါ် မူတည်ပြီး ရှုပ်ထွေးတဲ့ ဆက်သွယ်မှုတွေ လုပ်ခွင့်မပေးဘူး။ ဤအရာအားလုံးသည် developer များ၏ပခုံးပေါ်တွင်ကျရောက်သည်။ ဆိုလိုသည်မှာ၊ ဤသည်မှာ သင်ရေးသားပြီးသော Terraform ဖွဲ့စည်းမှုပုံစံတစ်မျိုးမျှသာဖြစ်သည်။ ပြီးတော့ ဒါကို အုပ်စုတစ်ခုအနေနဲ့ ရိုးရိုးရှင်းရှင်း ခေါ်ဆိုနိုင်ပါတယ်။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ 10-20-30 Kb ၏ကုဒ်ကို အကောင်းဆုံးဖြစ်အောင် မည်သို့ပြုလုပ်မည်ကို နားလည်ရန် ကြိုးစားနေပါသည်။ ကျွန်ုပ်တို့သည် အချို့သော module များကိုအသုံးပြုရန် လိုအပ်ကြောင်း တဖြည်းဖြည်းနားလည်လာပါသည်။

သင်ကြုံတွေ့ရသော မော်ဂျူးများ၏ ပထမအမျိုးအစားမှာ အရင်းအမြစ် မော်ဂျူးများဖြစ်သည်။ မင်းရဲ့အခြေခံအဆောက်အအုံက ဘာအကြောင်း၊ မင်းရဲ့လုပ်ငန်းက ဘာအကြောင်း၊ ဘယ်နေရာနဲ့ ဘယ်လိုအခြေအနေတွေလဲဆိုတာ သူတို့က နားမလည်ဘူး။ ဤရွေ့ကားများသည် ကျွန်ုပ်နှင့်အတူ open source အသိုင်းအဝိုင်းနှင့်အတူ စီမံခန့်ခွဲပေးသော အတိအကျဖြစ်ပြီး၊ သင်၏အခြေခံအဆောက်အဦအတွက် ကနဦးတည်ဆောက်ရေးလုပ်ကွက်များအဖြစ် ကျွန်ုပ်တို့တင်ပြပေးသော အတိအကျဖြစ်သည်။

အရင်းအမြစ် module တစ်ခု၏ဥပမာ။

အရင်းအမြစ် module တစ်ခုကို ကျွန်ုပ်တို့ခေါ်ဆိုသောအခါ၊ ကျွန်ုပ်တို့သည် ၎င်း၏အကြောင်းအရာများကို တင်သင့်သည့်လမ်းကြောင်းမှ သတ်မှတ်ပေးပါသည်။

ကျွန်ုပ်တို့ ဒေါင်းလုဒ်လုပ်လိုသော ဗားရှင်းကို ဖော်ပြပါသည်။

အဲဒီမှာ ငြင်းခုံမှု အများအပြားကို ကျွန်တော်တို့ ကျော်ဖြတ်ပါတယ်။ ဒါပါပဲ။ ဤ module ကိုအသုံးပြုသောအခါကျွန်ုပ်တို့သိရန်လိုအပ်သည်မှာဒါပါပဲ။

နောက်ဆုံးထွက်ဗားရှင်းကို အသုံးပြုပါက အရာအားလုံးတည်ငြိမ်မည်ဟု လူအများက ယူဆကြသည်။ ဒါပေမယ့် မဟုတ်ဘူး။ အခြေခံအဆောက်အအုံကို ဗားရှင်းပြောင်းရပါမည်၊ မည်သည့်ဗားရှင်း သို့မဟုတ် ၎င်းအစိတ်အပိုင်းကို အသုံးပြုထားသည်ကို ကျွန်ုပ်တို့ ရှင်းရှင်းလင်းလင်းဖြေကြားရပါမည်။

ဤသည်မှာ ဤ module အတွင်းရှိ ကုဒ်ဖြစ်သည်။ လုံခြုံရေးအုပ်စု သင်ခန်းစာ။ ဤနေရာတွင် စာလိပ်သည် 640 မျဉ်းသို့သွားပါသည်။ ဖြစ်နိုင်ချေရှိသော ဖွဲ့စည်းမှုတိုင်းတွင် Amazon ရှိ လုံခြုံရေး-croup အရင်းအမြစ်ကို ဖန်တီးခြင်းသည် အလွန်အသေးအဖွဲမဟုတ်သော အလုပ်တစ်ခုဖြစ်သည်။ လုံခြုံရေးအဖွဲ့တစ်ခုကို ဖန်တီးပြီး ၎င်းကို ဖြတ်သန်းရမည့် စည်းကမ်းများကို ပြောပြရုံဖြင့် မလုံလောက်ပါ။ အလွန်ရိုးရှင်းပါသည်။ Amazon တွင် ကန့်သတ်ချက်ပေါင်း တစ်သန်းကျော်ရှိသည်။ ဥပမာအားဖြင့် သင်အသုံးပြုလျှင် VPC အဆုံးမှတ်၊ ရှေ့ထွက်စာရင်း၊ အမျိုးမျိုးသော APIs ဤအရာအားလုံးကို အခြားအရာအားလုံးနှင့် ပေါင်းစပ်ရန်ကြိုးစားသည်၊ ထို့နောက် Terraform သည် သင့်အား ဤသို့လုပ်ဆောင်ရန် ခွင့်မပြုပါ။ Amazon API ကလည်း ဒါကို ခွင့်မပြုပါဘူး။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဤဆိုးရွားလှသော ယုတ္တိဗေဒအားလုံးကို module တစ်ခုတွင် ဝှက်ထားရန် လိုအပ်ပြီး ဤကဲ့သို့သော ပုံသဏ္ဌာန်ရှိသော အသုံးပြုသူကုဒ်ကို ပေးရန်လိုအပ်ပါသည်။

အသုံးပြုသူသည် အတွင်းတွင် မည်သို့ပြုလုပ်ထားသည်ကို သိရန်မလိုအပ်ပါ။

အရင်းအမြစ် မော်ဂျူးများပါ၀င်သည့် ဒုတိယအမျိုးအစား မော်ဂျူးများသည် သင့်လုပ်ငန်းနှင့် ပိုမိုသက်ဆိုင်သည့် ပြဿနာများကို ဖြေရှင်းပြီးသားဖြစ်သည်။ မကြာခဏဆိုသလို ဤနေရာသည် Terraform အတွက် တိုးချဲ့မှုတစ်ခုဖြစ်ပြီး ကုမ္ပဏီစံချိန်စံညွှန်းများအတွက် တဂ်များအတွက် တင်းကျပ်သောတန်ဖိုးအချို့ကို သတ်မှတ်ပေးပါသည်။ Terraform သည် လက်ရှိတွင် သင့်အား အသုံးပြုရန် ခွင့်မပြုသော လုပ်ဆောင်ချက်များကိုလည်း ထည့်သွင်းနိုင်သည်။ ဒါက အခုချက်ချင်းပဲ။ ယခု ဗားရှင်း 0.11 သည် အတိတ်၏ အရာတစ်ခု ဖြစ်လာတော့မည်ဖြစ်သည်။ သို့သော်လည်း၊ ကြိုတင်ပရိုဆက်ဆာများ၊ jsonnet၊ cookiecutter နှင့် အခြားအရာများစွာသည် ပြီးပြည့်စုံသောအလုပ်အတွက် အသုံးပြုရမည့် အရန်ယန္တရားဖြစ်သည်။

နောက်တစ်ခုကတော့ ဒီဥပမာအချို့ကို ပြပါမယ်။

အခြေခံအဆောက်အအုံ module ကိုအတိအကျတူညီသောနည်းဖြင့်ခေါ်သည်။

အကြောင်းအရာကို ဒေါင်းလုဒ်လုပ်ရမည့် အရင်းအမြစ်ကို ညွှန်ပြထားသည်။

တန်ဖိုးများစွာကို ဖြတ်သန်းပြီး ဤ module ထဲသို့ ဖြတ်သွားပါသည်။

ထို့နောက်၊ ဤ module အတွင်းတွင်၊ VPC သို့မဟုတ် Application Load Balancer ဖန်တီးရန် သို့မဟုတ် လုံခြုံရေးအဖွဲ့ သို့မဟုတ် Elastic Container Service အစုအဝေးအတွက် အရင်းအမြစ် module အများအပြားကို ခေါ်သည်။

Module နှစ်မျိုးရှိသည်။ ဤအစီရင်ခံစာတွင် ကျွန်ုပ်အုပ်စုဖွဲ့ထားသော အချက်အလက်အများစုကို စာရွက်စာတမ်းတွင် မရေးထားသောကြောင့် နားလည်ရန် အရေးကြီးပါသည်။

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

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

Terraform Registry - https://registry.terraform.io/

အကြံပြုချက် #0 သည် အရင်းအမြစ် module များကို မရေးပါနှင့်။ ဤ module အများစုသည် သင့်အတွက် ရေးထားပြီးဖြစ်သည်။ ငါပြောခဲ့သည့်အတိုင်း၊ ၎င်းတို့သည် open source ဖြစ်သည်၊ ၎င်းတို့သည် သင့်လုပ်ငန်းဆိုင်ရာ ယုတ္တိတစ်ခုမျှမပါဝင်ပါ၊ ၎င်းတို့တွင် IP လိပ်စာများ၊ စကားဝှက်များစသည်တို့အတွက် hardcoded တန်ဖိုးများ မရှိပါ။ module သည် အလွန်ပြောင်းလွယ်ပြင်လွယ်ဖြစ်သည်။ နောက်ပြီးတော့ ဖြစ်နိုင်ချေ များပါတယ်။ Amazon မှအရင်းအမြစ်များအတွက် module များစွာရှိသည်။ 650 လောက်ရှိပြီး အများစုက အရည်အသွေးကောင်းတယ်။

ဤဥပမာတွင်၊ တစ်စုံတစ်ဦးသည် သင့်ထံလာပြီး “ကျွန်တော် ဒေတာဘေ့စ်တစ်ခုကို စီမံခန့်ခွဲနိုင်ချင်ပါသည်။ ဒေတာဘေ့စ်တစ်ခုဖန်တီးနိုင်စေရန် မော်ဂျူးတစ်ခုဖန်တီးပါ။" Amazon သို့မဟုတ် Terraform ၏ အကောင်အထည်ဖော်မှုအသေးစိတ်အချက်အလက်များကို အဆိုပါပုဂ္ဂိုလ်မှ မသိပါ။ သူက ရိုးရိုးရှင်းရှင်းပြောတယ် "ကျွန်တော် MSSQL ကို စီမံခန့်ခွဲချင်ပါတယ်" ဆိုလိုသည်မှာ၊ ၎င်းသည် ကျွန်ုပ်တို့၏ module ကိုခေါ်ဆိုပြီး၊ ထိုနေရာတွင် အင်ဂျင်အမျိုးအစားကို ကျော်ဖြတ်ကာ အချိန်ဇုန်ကိုညွှန်ပြမည်ဟု ဆိုလိုပါသည်။

ပြီးတော့ ဒီ module ထဲမှာ မတူညီတဲ့ အရင်းအမြစ်နှစ်ခုကို ဖန်တီးမယ်ဆိုတာကို လူတစ်ယောက်က မသိသင့်ပါဘူး။ တစ်ခုက MSSQL အတွက်၊ ဒုတိယတစ်ခုက အခြားအရာအားလုံးအတွက်ဖြစ်ပြီး Terraform 0.11 မှာ စိတ်ကြိုက်အချိန်ဇုန်တန်ဖိုးတွေကို သင်မသတ်မှတ်နိုင်တာကြောင့်ပါ။

ဤ module မှထွက်ပေါက်တွင်လူတစ်ဦးသည်ရိုးရှင်းစွာလိပ်စာတစ်ခုလက်ခံရရှိလိမ့်မည်။ မည်သည့်ဒေတာဘေ့စ်မှ ကျွန်ုပ်တို့ ဤအရာအားလုံးကို အတွင်းပိုင်း၌ ဖန်တီးနေသည်မှာ မည်သည့်အရင်းအမြစ်မှ သိရှိမည်မဟုတ်ပါ။ ဤအရာသည် ဖုံးကွယ်ခြင်း၏ အလွန်အရေးကြီးသော အချက်ဖြစ်သည်။ ၎င်းသည် open source တွင် အများသူငှာအသုံးပြုနိုင်သော အဆိုပါ module များနှင့်သာမက သင့်ပရောဂျက်များနှင့် အဖွဲ့များအတွင်း သင်ရေးမည့် အဆိုပါ module များနှင့်လည်း သက်ဆိုင်ပါသည်။

ဤသည်မှာ Terraform ကိုခဏကြာအသုံးပြုနေပါက၊ ၎င်းသည် ဒုတိယအငြင်းအခုံဖြစ်သည်။ သင့်ကုမ္ပဏီအတွက် သင်၏ Terraform modules အားလုံးကို သင်ထည့်သွင်းထားသည့် သိုလှောင်ရုံတစ်ခုရှိသည်။ အချိန်ကြာလာသည်နှင့်အမျှ ဤပရောဂျက်သည် တစ်မီဂါဘိုက် သို့မဟုတ် နှစ်မီဂါဘိုက်အထိ ကြီးထွားလာသည်မှာ ပုံမှန်ဖြစ်သည်။ ဒါကအဆင်ပြေပါတယ်။

ဒါပေမယ့် ပြဿနာက Terraform က ဒီ module တွေကို ဘယ်လိုခေါ်လဲ။ ဥပမာအားဖြင့်၊ သုံးစွဲသူတစ်ဦးချင်းစီကို ဖန်တီးရန် မော်ဂျူးတစ်ခုကို သင်ခေါ်ဆိုပါက Terraform သည် သိုလှောင်မှုတစ်ခုလုံးကို ဦးစွာတင်ပြီးနောက် ၎င်းသတ်မှတ်ထားသော module တည်ရှိသည့် ဖိုင်တွဲသို့ လမ်းညွှန်သွားမည်ဖြစ်သည်။ ဤနည်းဖြင့် သင်သည် တစ်ကြိမ်လျှင် တစ်မီဂါဘိုက်ကို ဒေါင်းလုဒ်လုပ်မည်ဖြစ်သည်။ အကယ်၍ သင်သည် အသုံးပြုသူ 100 သို့မဟုတ် 200 ကို စီမံခန့်ခွဲပါက 100 သို့မဟုတ် 200 megabytes ကို ဒေါင်းလုဒ်လုပ်ကာ ထိုဖိုင်တွဲသို့ သွားပါမည်။ ထို့ကြောင့် သင်သည် "Terraform init" ကိုနှိပ်လိုက်တိုင်း အရာများစွာကို ဒေါင်းလုဒ်မလုပ်ချင်တော့သည်မှာ သဘာဝကျပါသည်။

https://github.com/mbtproject/mbt

ဤပြဿနာအတွက် ဖြေရှင်းနည်းနှစ်ခုရှိသည်။ ပထမအချက်မှာ ဆွေမျိုးလမ်းကြောင်းများကို အသုံးပြုရန်ဖြစ်သည်။ ဤနည်းဖြင့် သင်သည် ဖိုင်တွဲသည် ဒေသန္တရ (./) ဖြစ်ကြောင်း ကုဒ်တွင် ဖော်ပြသည်။ သင် မည်သည့်အရာကိုမျှ မဖွင့်မီ၊ သင်သည် ဤသိုလှောင်မှု၏ Git ကိုလိုနီကို စက်တွင်း၌ ပြုလုပ်ပါ။ ဒီနည်းကို တစ်ခါလုပ်ပါ။

အားနည်းချက်တွေ အများကြီးရှိတယ်။ ဥပမာအားဖြင့်၊ သင်သည် ဗားရှင်းတင်ခြင်းကို အသုံးမပြုနိုင်ပါ။ ပြီးတော့ ဒါက တစ်ခါတလေ အတူနေဖို့ ခက်တယ်။

ဒုတိယဖြေရှင်းချက်။ အကယ်၍ သင့်တွင် submodule အများအပြားရှိပြီး သင့်တွင်တည်ဆောက်ထားသောပိုက်လိုင်းအချို့ရှိနေပြီဆိုလျှင်၊ သင်သည် monorepository တစ်ခုမှ မတူညီသော package အများအပြားကိုစုဆောင်းနိုင်ပြီး ၎င်းတို့ကို S3 သို့ အပ်လုဒ်လုပ်နိုင်သည့် MBT ပရောဂျက်ရှိပါသည်။ ဒါက အရမ်းကောင်းတဲ့နည်းလမ်းပါ။ ထို့ကြောင့်၊ ဤအရင်းအမြစ်ကိုဖန်တီးရန်ကုဒ်သည် အလွန်သေးငယ်သောကြောင့် iam-user-1.0.0.zip ဖိုင်သည် 1 Kb သာ အလေးချိန်ရှိပါမည်။ ပြီးတော့ အလုပ်ပိုမြန်ပါလိမ့်မယ်။

Module များတွင် အသုံးမပြုနိုင်သော အရာများကို ဆွေးနွေးကြပါစို့။

၎င်းသည် မော်ဂျူးများတွင် အဘယ်ကြောင့် မကောင်းသနည်း။ အဆိုးဆုံးကတော့ သုံးစွဲသူလို့ ယူဆဖို့ပါပဲ။ အသုံးပြုသူသည် မတူညီသောလူများအသုံးပြုနိုင်သည့် ပံ့ပိုးပေးသူအထောက်အထားစိစစ်ခြင်းရွေးချယ်မှုတစ်ခုဟု ယူဆပါ။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့အားလုံးသည် အခန်းကဏ္ဍကို ကျေညက်အောင် လုပ်ဆောင်ပါမည်။ ဆိုလိုသည်မှာ Terraform သည် ဤအခန်းကဏ္ဍတွင် ပါဝင်မည်ဖြစ်သည်။ ထို့နောက် ဤအခန်းကဏ္ဍဖြင့် အခြားလုပ်ဆောင်ချက်များကို လုပ်ဆောင်မည်ဖြစ်သည်။

ဆိုးတာက Vasya က ဥပမာအားဖြင့် default environment variable ကိုအသုံးပြုပြီး Vasya က Amazon ကို တစ်ဖက်တစ်လမ်းကနေ ချိတ်ဆက်ရတာကို နှစ်သက်ပြီး Petya က သူ့ရဲ့ လျှို့ဝှက်နေရာတစ်ခုမှာ ရှိတဲ့ သူ့ရဲ့ shared key ကို သုံးရတာကို နှစ်သက်တယ်ဆိုရင် နှစ်ခုစလုံးကို သတ်မှတ်လို့ မရပါဘူး။ Terraform ထို့ကြောင့် ၎င်းတို့သည် ဆင်းရဲဒုက္ခမခံစားရစေရန်၊ သင်ခန်းစာတွင် ဤဘလောက်ကို ညွှန်ပြရန်မလိုအပ်ပါ။ ဒါကို ပိုမြင့်တဲ့အဆင့်မှာ ညွှန်ပြရမယ်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့တွင် အရင်းအမြစ် module တစ်ခု၊ အခြေခံအဆောက်အအုံ module တစ်ခုနှင့် ထိပ်တွင် ဖွဲ့စည်းမှုတစ်ခုရှိသည်။ ပြီးတော့ ဒါကို အမြင့်တစ်နေရာမှာ ညွှန်ပြရမယ်။

ဒုတိယမကောင်းမှုမှာ စီမံပေးသူဖြစ်သည်။ ဤနေရာတွင် မကောင်းမှုမှာ အသေးအဖွဲမဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် သင်သည် ကုဒ်ရေးပြီး ၎င်းသည် သင့်အတွက် အဆင်ပြေမည်ဆိုပါက ၎င်းသည် အလုပ်လုပ်ပါက အဘယ်ကြောင့် ပြောင်းလဲမည်နည်းဟု သင်ထင်ပေမည်။

မကောင်းသည်မှာ ပထမဦးစွာ ဤစီမံပေးသူကို စတင်မည့်အချိန်ကို သင်အမြဲမထိန်းချုပ်နိုင်ခြင်းကြောင့်ဖြစ်သည်။ ဒုတိယအနေနဲ့၊ aws ec2 က ဘာကိုဆိုလိုသလဲဆိုတာကို သင်မထိန်းချုပ်နိုင်ပါဘူး၊ ဆိုလိုတာက Linux ဒါမှမဟုတ် Windows အကြောင်းကို အခုပြောနေတာလား။ ထို့ကြောင့် မတူညီသော လည်ပတ်မှုစနစ်များ သို့မဟုတ် မတူညီသော အသုံးပြုသူကိစ္စများအတွက် တူညီသောအလုပ်ဖြစ်မည့် တစ်ခုခုကို သင်ရေး၍မရပါ။

တရားဝင်စာရွက်စာတမ်းများတွင်လည်းဖော်ပြထားသည့်အသုံးအများဆုံးဥပမာမှာ၊ သင်သည် aws_instance ကိုရေးပြီး arguments အစုအဝေးကိုသတ်မှတ်ပါက၊ အကယ်၍ provisioner "local-exec" ကိုသတ်မှတ်ပြီး သင်၏ ansible- ကို run ပါက ၎င်းနှင့်ပတ်သတ်၍ အမှားအယွင်းမရှိပေ။ ကစားစာအုပ်

တကယ်တော့ ဟုတ်တယ်၊ အဲဒါနဲ့ ပတ်သက်ပြီး ဘာမှ မမှားပါဘူး။ သို့သော်၊ ဥပမာ၊ launch_configuration တွင် ဤ local-exec အရာမရှိသည်ကို မကြာမီ သင်သဘောပေါက်လာပါလိမ့်မည်။

သင် launch_configuration ကိုအသုံးပြုပြီး instance တစ်ခုမှ autoscaling group တစ်ခုကို ဖန်တီးလိုသောအခါ၊ launch_configuration တွင် "provisioner" ၏ concept မရှိပါ။ "အသုံးပြုသူဒေတာ" အယူအဆရှိပါတယ်။

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

အကယ်၍ သင်သည် provisioner ကို run ချင်သေးပါက၊ ၎င်းသည် gluing component တစ်ခုဖြစ်သောကြောင့်၊ resource တစ်ခုကို ဖန်တီးသောအခါ၊ ထိုအချိန်တွင် သင်သည် သင်၏ provisioner၊ သင်၏ command ကို run ရန်လိုအပ်ပါသည်။ အဲဒီလို အခြေအနေတွေ အများကြီးရှိတယ်။

၎င်းအတွက် အမှန်ကန်ဆုံးအရင်းအမြစ်ကို null_resource ဟုခေါ်သည်။ Null_resource သည် အမှန်တကယ် ဖန်တီး၍မရသော ကိန်းဂဏန်းအရင်းအမြစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် မည်သည့်အရာကိုမျှ မထိရ၊ API မရှိ၊ အလိုအလျောက် အတိုင်းအတာမရှိပေ။ သို့သော် ၎င်းသည် သင့်အား မည်သည့်အချိန်တွင် အမိန့်ပေးရမည်ကို ထိန်းချုပ်နိုင်သည်။ ဤကိစ္စတွင်၊ ဖန်တီးနေစဉ် command ကို run သည်။

link ကို http://bit.ly/common-traits-in-terraform-modules

လက္ခဏာများစွာရှိသည်။ နိမိတ်လက္ခဏာများအားလုံးကို ကြီးစွာသောအသေးစိတ်၌ ငါမဝင်။ ဒီအကြောင်း ဆောင်းပါးတစ်ပုဒ်ရှိတယ်။ သို့သော် သင်သည် Terraform နှင့်အလုပ်လုပ်ဖူးသည် သို့မဟုတ် အခြားသူများ၏ module များကိုအသုံးပြုပါက၊ ထို့နောက် open source မှ code အများစုကဲ့သို့ module အများအပြားကို ၎င်းတို့၏လိုအပ်ချက်အတွက် လူများကရေးသားကြသည်ကို သင်မကြာခဏသတိပြုမိပါသည်။ လူတစ်ယောက်က ရေးပြီး သူ့ပြဿနာကို ဖြေရှင်းတယ်။ ငါ GitHub မှာ ချိတ်ထားတယ်၊ အသက်ရှင်ပါစေ။ ၎င်းသည် အသက်ရှင်နေမည်ဖြစ်သော်လည်း ထိုနေရာတွင် စာရွက်စာတမ်းနှင့် ဥပမာများမရှိလျှင် ၎င်းကို မည်သူမျှ အသုံးပြုမည်မဟုတ်ပါ။ ၎င်းင်း၏သတ်မှတ်တာဝန်ထက် အနည်းငယ်ပို၍ ဖြေရှင်းနိုင်စေမည့် လုပ်ဆောင်နိုင်စွမ်းမရှိပါက၊ ၎င်းကို မည်သူမှ အသုံးပြုမည်မဟုတ်ပါ။ အသုံးပြုသူများကို ဆုံးရှုံးရန် နည်းလမ်းများစွာရှိသည်။

လူတွေအသုံးပြုလို့ရအောင် တစ်ခုခုရေးချင်တယ်ဆိုရင်တော့ ဒီလက္ခဏာတွေကို လိုက်နာဖို့ အကြံပြုချင်ပါတယ်။

သူတို့ဟာနေသောခေါင်းစဉ်:

• စာရွက်စာတမ်းများနှင့် ဥပမာများ။
• လုပ်ဆောင်ချက်အပြည့်အစုံ။
• ကျိုးကြောင်းဆီလျော်သော ပုံသေများ။
• ကုဒ်ကို သန့်ရှင်းပါ။
• စမ်းသပ်မှုများ။

စာမေးပွဲများသည် စာရေးရန်အလွန်ခက်ခဲသောကြောင့် အခြေအနေအမျိုးမျိုးရှိသည်။ စာရွက်စာတမ်းတွေနဲ့ ဥပမာတွေကို ပိုယုံကြည်တယ်။

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

ဤသည်မှာ စာရွက်စာတမ်း၏ မီးခိုးရောင်အပိုင်းဖြစ်သည်။ ယခု သင်တွေးနေနိုင်သည်– “တစ်ခုခုတော့ မသဲကွဲဘူး။ မယုံကြည်ဘူး။" ဒါပေမယ့် ခြောက်လအတွင်း တွေ့မယ်။

အခု ဒီ modules တွေကို ဘယ်လိုခေါ်ရမလဲဆိုတာ ပြောကြရအောင်။

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

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

ယခုမူ ၎င်းကို ငြင်းပယ်ပြီး ဖယ်ရှားလိုက်သည် ဟု ရေးသားထားသည်။ အချိန်ကြာလာသည်နှင့်အမျှ၊ လူများသည် ပရောဂျက်ကို ပုံစံအမျိုးမျိုးဖြင့် စတင်အသုံးပြုလာသောကြောင့် ၎င်းသည် အကောင်းဆုံးအလေ့အကျင့်နှင့် ဝေးကွာကြောင်း Terraform အသိုင်းအဝိုင်းမှ သိရှိလာသည်။ ပြီးတော့ ပြဿနာတွေရှိတယ်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် မှီခိုမှုအားလုံးကို တစ်နေရာတည်းတွင် စာရင်းပြုစုသောအခါ။ ကျွန်ုပ်တို့သည် “Terraform အစီအစဉ်” ကိုနှိပ်သည့်အခါ အခြေအနေများရှိပြီး Terraform သည် အရင်းအမြစ်အားလုံး၏ အခြေအနေများကို မွမ်းမံမွမ်းမံသည်အထိ အချိန်များစွာ ကုန်သွားနိုင်သည်။

ဥပမာအားဖြင့် 5 မိနစ် ကြာမြင့်သည်။ တစ်ချို့အတွက်တော့ ဒါက အချိန်တော်တော်ကြာတယ်။ 15 မိနစ်လောက်ကြာတဲ့ ကိစ္စတွေကို တွေ့ဖူးတယ်။ AWS API သည် အရင်းအမြစ်တစ်ခုစီ၏ အခြေအနေနှင့် ဖြစ်ပျက်နေသည်များကို အဖြေရှာရန် 15 မိနစ်ကြာ ကြိုးပမ်းခဲ့သည်။ ဤသည်မှာ အလွန်ကြီးမားသော ဧရိယာဖြစ်သည်။

သဘာဝအားဖြင့်၊ သင်သည် တစ်နေရာတည်းတွင် တစ်ခုခုကို ပြောင်းလဲလိုသည့်အခါတွင် ဆက်စပ်ပြဿနာတစ်ခု ပေါ်လာမည်ဖြစ်ပြီး၊ ထို့နောက် 15 မိနစ်စောင့်ပါ၊ ၎င်းသည် သင့်အား ပြောင်းလဲမှုအချို့ကို ကင်းဗတ်စတစ်ခုပေးသည်။ သင်သည် တံတွေးထွေးပြီး "Yes" ဟုရေးပြီး တစ်ခုခုမှားသွားပါသည်။ ဤသည်မှာ အလွန်မှန်ကန်သော ဥပမာတစ်ခုဖြစ်သည်။ Terraform သည် သင့်အား ပြဿနာများမှ ကာကွယ်ရန် မကြိုးစားပါ။ ဆိုလိုသည်မှာ သင်အလိုရှိသောအရာကို ရေးပါ။ ပြဿနာတွေ ရှိမယ်။ Terraform 0.11 သည် သင့်အား မည်သည့်နည်းဖြင့်မျှ ကူညီရန် မကြိုးစားသော်လည်း၊ 0.12 တွင် သင်ပြောနိုင်သော စိတ်ဝင်စားစရာနေရာအချို့ရှိသည်- "Vasya၊ မင်းဒါကိုတကယ်လိုချင်တယ်၊ မင်းသဘောပေါက်နိုင်မလား"

ဒုတိယနည်းလမ်းမှာ ဤဧရိယာကို လျှော့ချရန်ဖြစ်သည်၊ ဆိုလိုသည်မှာ တစ်နေရာမှ ဖုန်းခေါ်ဆိုမှုများသည် အခြားတစ်နေရာမှ ချိတ်ဆက်မှု နည်းပါးနိုင်သည်။

တစ်ခုတည်းသောပြဿနာမှာ သင်သည် ကုဒ်များများရေးရန် လိုအပ်သည်၊ ဆိုလိုသည်မှာ သင်သည် ဖိုင်အများအပြားတွင် variable များကို ဖော်ပြပြီး ၎င်းကို အပ်ဒိတ်လုပ်ရန် လိုအပ်ပါသည်။ တချို့လူတွေက မကြိုက်ဘူး။ ဒါက ကျွန်တော့်အတွက် ပုံမှန်ပါပဲ။ အချို့က “ဒါကို တစ်နေရာတည်းမှာ ဘာလို့ရေးထားလဲ၊ အားလုံးကို တစ်နေရာတည်းမှာ ထားမယ်” ဟု လူအချို့က ထင်ကြသည်။ ဒါက ဖြစ်နိုင်ပေမယ့် ဒါက ဒုတိယအစွန်း ရောက်မှုပါ။

ဤအရာများအားလုံးကို တစ်နေရာတည်းတွင် မည်သူရှိသနည်း။ တစ်၊ နှစ်၊ သုံး၊ ဆိုလိုတာက တစ်စုံတစ်ယောက်က သုံးနေတယ်။

သီးခြားအစိတ်အပိုင်းတစ်ခု၊ ဘလောက်တစ်ခု သို့မဟုတ် အခြေခံအဆောက်အအုံတစ်ခုအား မည်သူကခေါ်ဆိုသနည်း။ လူငါးယောက်မှ ခုနစ်ယောက်။ ဒါကအေးတယ်။

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

stack VPC မှာ တစ်ခုခုပြောင်းလဲသွားပြီး EC2 မှာ ဒီအပြောင်းအလဲတွေကို အသုံးချလိုတယ်ဆိုရင်၊ ဥပမာ သင့်မှာ subnet အသစ်တစ်ခုရှိလို့ autoscaling group ကို အပ်ဒိတ်လုပ်လိုတယ်ဆိုရင်တော့ ဒီ dependency orchestration လို့ခေါ်ပါတယ်။ ဖြေရှင်းနည်းအချို့ရှိပါတယ်- ဘယ်သူက ဘာကိုသုံးတာလဲ။

ဘယ်လိုဖြေရှင်းချက်တွေရှိလဲလို့ အကြံပြုနိုင်ပါတယ်။ မှော်ပညာကိုလုပ်ဆောင်ရန် Terraform ကိုသုံးနိုင်သည်၊ သို့မဟုတ် Terraform ကိုအသုံးပြုရန် makefiles ကိုသုံးနိုင်သည်။ အဲဒီမှာ တစ်ခုခု ပြောင်းလဲသွားသလားဆိုတာ ကြည့်ရင်း၊ ဒီမှာပဲ စတင်နိုင်ပါတယ်။

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

ဟုတ်ပါတယ်၊ ဒါကို အိမ်မှာ မစမ်းပါနဲ့။ Terraform သည် Terraform မှ လုပ်ဆောင်ရန် ဘယ်သောအခါမှ ဒီဇိုင်းမထုတ်ခဲ့ပါ။

အစီရင်ခံစာတစ်ခုတွင် သူတို့က “မဟုတ်ဘူး၊ ဒါက အလုပ်မဖြစ်ဘူး။” အဓိကကတော့ အလုပ်မဖြစ်သင့်ဘူး။ Terraform မှ Terraform ကိုသင်ဖွင့်နိုင်သောအခါတွင်၎င်းသည်အလွန်အထင်ကြီးပုံရသည်ဖြစ်သော်လည်း၊ ထို့နောက် Terraform ကိုသင်ထိုသို့မလုပ်သင့်ပါ။ Terraform သည် အမြဲတမ်း အလွန်လွယ်ကူစွာ စတင်သင့်သည်။

https://github.com/gruntwork-io/terragrunt/

တစ်နေရာတည်းတွင် တစ်စုံတစ်ခုပြောင်းလဲသွားသောအခါတွင် ဖုန်းခေါ်ဆိုမှုအား လိုအပ်ပါက၊ Terragrunt ရှိပါသည်။

Terragrunt သည် သင်အား အခြေခံအဆောက်အအုံ မော်ဂျူးများသို့ ခေါ်ဆိုမှုများကို ညှိနှိုင်းရန်နှင့် ကြိုးကိုင်နိုင်စေမည့် Terraform ၏ အပိုပရိုဂရမ်တစ်ခုဖြစ်သည်။

ပုံမှန် Terraform ဖွဲ့စည်းမှုပုံစံ ဖိုင်သည် ဤကဲ့သို့ ဖြစ်ပုံရသည်။

သင်ခေါ်ဆိုလိုသော သီးသန့် module တစ်ခုအား သင်သတ်မှတ်ပါ။

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

ပြီးတော့ ဒီ module က ဘာငြင်းချက်တွေကို လက်ခံပါသလဲ။ Terragrunt အကြောင်း သိဖို့ ဒီလောက်ပါပဲ။

စာရွက်စာတမ်းသည် ထိုနေရာတွင်ရှိပြီး GitHub တွင် ကြယ် 1 ရှိသည်။ ဒါပေမယ့် ကိစ္စတော်တော်များများမှာ ဒါကို သင်သိထားဖို့ လိုပါတယ်။ ၎င်းသည် Terraform နှင့်စတင်လုပ်ဆောင်သည့်ကုမ္ပဏီများတွင်အကောင်အထည်ဖော်ရန်အလွန်လွယ်ကူသည်။

ထို့ကြောင့် တီးမှုတ်ခြင်းသည် Terragrunt ဖြစ်သည်။ အခြားရွေးချယ်စရာများရှိပါသည်။

အခု code နဲ့ ဘယ်လိုအလုပ်လုပ်ရမလဲဆိုတာ ပြောကြည့်ရအောင်။

သင့်ကုဒ်တွင် အင်္ဂါရပ်အသစ်များထည့်ရန် လိုအပ်ပါက၊ ကိစ္စအများစုတွင် ၎င်းသည် လွယ်ကူသည်။ သင်သည် အရင်းအမြစ်အသစ်ကို ရေးသားနေသည်၊ အရာအားလုံးသည် ရိုးရှင်းပါသည်။

အကယ်၍ သင့်တွင် သင်ကြိုတင်ဖန်တီးထားသည့် အရင်းအမြစ်အချို့ရှိပါက၊ ဥပမာ၊ သင် AWS အကောင့်တစ်ခုဖွင့်ပြီးနောက် Terraform အကြောင်း လေ့လာပြီး သင့်တွင်ရှိပြီးသားအရင်းအမြစ်များကို အသုံးပြုလိုပါက၊ သို့မှသာ သင်၏ module ကို ဤနည်းဖြင့် တိုးချဲ့ခြင်းသည် သင့်လျော်လိမ့်မည်၊ ၎င်းသည် ရှိပြီးသားအရင်းအမြစ်များကို အသုံးပြုခြင်းကို ပံ့ပိုးပေးသည်။

block resource ကို အသုံးပြု၍ အရင်းအမြစ်အသစ်များ ဖန်တီးခြင်းကို ပံ့ပိုးခဲ့သည်။

အထွက်တွင် ကျွန်ုပ်တို့သည် အသုံးပြုခဲ့သည့်အပေါ်မူတည်၍ အထွက် ID ကို အမြဲတမ်း ပြန်ပေးသည်။

Terraform 0.11 တွင် ဒုတိယအလွန်သိသာထင်ရှားသောပြဿနာမှာ စာရင်းများနှင့် လုပ်ဆောင်ခြင်းဖြစ်သည်။

ဒီလိုမျိုး သုံးစွဲသူစာရင်းရှိရင် အခက်အခဲရှိတယ်။

block resource သုံးပြီး ဒီအသုံးပြုသူတွေကို ဖန်တီးတဲ့အခါ အားလုံးအဆင်ပြေပါတယ်။ ကျွန်ုပ်တို့သည် စာရင်းတစ်ခုလုံးကိုဖြတ်၍ တစ်ခုစီအတွက် ဖိုင်တစ်ခုဖန်တီးသည်။ အားလုံးအဆင်ပြေတယ်။ ဥပမာအားဖြင့်၊ အလယ်တွင်ရှိသော user3 ကို ဤနေရာမှ ဖယ်ရှားသင့်သည်၊ ထို့နောက် အညွှန်းသည် ပြောင်းလဲသွားသောကြောင့် သူ့နောက်မှ ဖန်တီးထားသော အရင်းအမြစ်အားလုံးကို ပြန်လည်ဖန်တီးမည်ဖြစ်သည်။

အခြေအနေရှိသော ပတ်ဝန်းကျင်တွင် စာရင်းများနှင့် အလုပ်လုပ်ခြင်း။ သာယာသောပတ်ဝန်းကျင်ဟူသည် အဘယ်နည်း။ ဤအရင်းအမြစ်ကို ဖန်တီးသည့်အခါ တန်ဖိုးအသစ်တစ်ခု ဖန်တီးသည့် အခြေအနေဖြစ်သည်။ ဥပမာအားဖြင့်၊ AWS Access Key သို့မဟုတ် AWS လျှို့ဝှက်ကီး၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် အသုံးပြုသူတစ်ဦးကို ဖန်တီးသောအခါ၊ ကျွန်ုပ်တို့သည် Access သို့မဟုတ် လျှို့ဝှက်သော့အသစ်ကို ရရှိသည်။ သုံးစွဲသူတစ်ဦးကို ဖျက်လိုက်တိုင်း၊ ဤအသုံးပြုသူတွင် သော့အသစ်တစ်ခု ရှိပါမည်။ ဒါပေမယ့် ဒါက Feng Shui မဟုတ်ပါဘူး၊ ဘာကြောင့်လဲဆိုတော့ သုံးစွဲသူက အဖွဲ့ကနေ ထွက်သွားတိုင်း သူ့အတွက် အသုံးပြုသူအသစ်ကို ဖန်တီးပေးရင် အသုံးပြုသူက ငါတို့နဲ့ သူငယ်ချင်းဖြစ်ချင်မှာ မဟုတ်ပါဘူး။

ဒါက ဖြေရှင်းချက်ပါ။ ဒါက Jsonnet မှာရေးထားတဲ့ကုဒ်ပါ။ Jsonnet သည် Google မှ နမူနာပုံစံဘာသာစကားတစ်ခုဖြစ်သည်။

ဤအမိန့်သည် သင့်အား ဤပုံစံပလိတ်ကို လက်ခံခွင့်ပြုပြီး အထွက်တွင် သင့်ပုံစံအတိုင်း ပြုလုပ်ထားသည့် json ဖိုင်ကို ပြန်ပေးသည်။

နမူနာပုံစံက ဒီလိုပါ။

Terraform သည် သင့်အား HCL နှင့် Json နှစ်မျိုးလုံးကို တူညီသောနည်းဖြင့် လုပ်ဆောင်နိုင်သည်၊ ထို့ကြောင့် သင့်တွင် Json ကို ထုတ်လုပ်နိုင်စွမ်းရှိပါက ၎င်းကို Terraform ထဲသို့ ဖြတ်သွားနိုင်သည်။ တိုးချဲ့မှု .tf.json ပါသော ဖိုင်ကို အောင်မြင်စွာ ဒေါင်းလုဒ်လုပ်ပါမည်။

ထို့နောက် ကျွန်ုပ်တို့သည် ၎င်းကို ပုံမှန်အတိုင်း လုပ်ဆောင်သည်- terraform init, terrorm သက်ရောက်သည်။ ပြီးတော့ ကျွန်တော်တို့က သုံးစွဲသူ နှစ်ယောက်ကို ဖန်တီးတယ်။

အခုဆို တစ်စုံတစ်ယောက် အသင်းက ထွက်သွားရင် ကျွန်တော်တို့ မကြောက်တော့ဘူး။ json ဖိုင်ကို တည်းဖြတ်ပါမည်။ Vasya Pupkin ကျန်ရစ်ခဲ့ပြီး Petya Pyatochkin ကျန်ရစ်ခဲ့သည်။ Petya Pyatochkin သည် သော့အသစ်ကို လက်ခံရရှိမည်မဟုတ်ပါ။

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

သို့သော် ကျွန်ုပ်တို့သည် Terraform ကို တိုးချဲ့ပြီး တစ်ခုခုပြီးမြောက်ပြီးနောက် အချို့သော command ကိုခေါ်ဆိုသည့်အခါ အခြေအနေများ ဖြစ်ပေါ်လာပါသည်။

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

ထို့နောက် shell terraform output မှဤ command ကိုခေါ်ပြီးကျွန်ုပ်တို့လိုချင်သောတန်ဖိုးကိုသတ်မှတ်ပါ။ ထို့ကြောင့်၊ command ကို အစားထိုးတန်ဖိုးများအားလုံးဖြင့် လုပ်ဆောင်သည်။ အရမ်းအဆင်ပြေတယ်။

ဒုတိယနည်း။ ဤသည်မှာ ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အအုံဆိုင်ရာ အပြောင်းအလဲများပေါ်မူတည်၍ null_resource ကို အသုံးပြုခြင်းဖြစ်သည်။ အရင်းအမြစ်ပြောင်းလဲမှုအချို့၏ ID ကို မကြာမီတွင် တူညီသော local-exe ဟုခေါ်နိုင်သည်။

Amazon သည် အခြားသော အများသူငှာ ပံ့ပိုးပေးသူများကဲ့သို့ပင် ၎င်း၏ကိုယ်ပိုင် အစွန်းအထင်းကိစ္စများ အများအပြားရှိသောကြောင့် ၎င်းသည် စာရွက်ပေါ်တွင် ချောမွေ့နေပါသည်။

အဖြစ်များဆုံးကိစ္စမှာ AWS အကောင့်တစ်ခုဖွင့်သောအခါ၊ သင်အသုံးပြုသည့်ဒေသများသည် အရေးကြီးသည်။ ဤအင်္ဂါရပ်ကို ထိုနေရာတွင် ဖွင့်ထားပါသလား။ ဒီဇင်ဘာလ 2013 နောက်ပိုင်းတွင် သင်ဖွင့်နိုင်မည်ဖြစ်သည်။ သင်သည် VPC တွင် ပုံသေအသုံးပြုနေသည် စသည်တို့ဖြစ်နိုင်သည်။ ကန့်သတ်ချက်များများစွာရှိသည်။ ပြီးတော့ Amazon က သူတို့ကို စာရွက်စာတမ်းတွေ တလျှောက်လုံး ပြန့်ကျဲသွားတယ်။

ရှောင်ကြဉ်ရန် အကြံပြုထားသော အချက်အချို့ရှိပါသည်။

စတင်ရန်၊ Terraform အစီအစဉ် သို့မဟုတ် Terraform CLI အတွင်းရှိ လျှို့ဝှက်မဟုတ်သော အကြောင်းပြချက်များအားလုံးကို ရှောင်ကြဉ်ပါ။ ဤအရာအားလုံးကို tfvars ဖိုင်တွင်ဖြစ်စေ သို့မဟုတ် ပတ်၀န်းကျင်ပြောင်းလဲမှုဖြစ်စေနိုင်သည်ဖြစ်စေ ထည့်နိုင်သည်။

သို့သော် သင်သည် ဤမှော်အမိန့်တစ်ခုလုံးကို အလွတ်ကျက်ရန် မလိုအပ်ပါ။ Terraform အစီအစဉ် - var နှင့် off ငါတို့သွားပါ။ ပထမ variable သည် var၊ ဒုတိယ variable သည် var၊ တတိယ၊ စတုတ္ထဖြစ်သည်။ ကျွန်တော် အများဆုံးသုံးတဲ့ ကုဒ်အဖြစ် အခြေခံအဆောက်အအုံရဲ့ အရေးအကြီးဆုံး နိယာမကတော့ ကုဒ်ကို ကြည့်ရုံနဲ့ အဲဒီနေရာမှာ ဖြန့်ကျက်ထားတဲ့ အရာကို ရှင်းရှင်းလင်းလင်း နားလည်ထားသင့်ပါတယ်၊ ဘယ်အခြေအနေနဲ့ ဘယ်တန်ဖိုးတွေ ရှိသင့်လဲ။ ထို့ကြောင့် ကျွန်ုပ်၏ အစုအဝေးကို ဖန်တီးရန် သူအသုံးပြုခဲ့သည့် ကန့်သတ်ချက်များကို Vasya အား မေးမြန်းရန် မလိုအပ်ပါ။ ပတ်ဝန်းကျင်နှင့် မကြာခဏ ကိုက်ညီသည့် tfvars extension ဖြင့် ဖိုင်တစ်ခုဖွင့်ရန် လိုအပ်ပြီး ထိုအရာအားလုံးကို ကြည့်ရှုပါ။

ထို့အပြင်၊ နယ်ပယ်ကိုလျှော့ချရန် ပစ်မှတ်ဆင်ခြေများကို မသုံးပါနှင့်။ ဤအတွက်ကြောင့် သေးငယ်သော အခြေခံအဆောက်အဦ module များကို အသုံးပြုရန် ပိုမိုလွယ်ကူသည်။

ထို့အပြင် ပြိုင်တူဝါဒကို ကန့်သတ်ရန် မလိုအပ်ပါ။ ကျွန်ုပ်တွင် ရင်းမြစ် 150 ရှိပြီး Amazon parallelism ကို မူရင်း 10 မှ 100 သို့ တိုးမြှင့်လိုပါက၊ တစ်ခုခု မှားသွားနိုင်သည်။ ဒါမှမဟုတ် အခုအဆင်ပြေနိုင်ပေမယ့် Amazon က မင်းဖုန်းခေါ်တာများလွန်းတယ်လို့ ပြောရင် ပြဿနာတက်လိမ့်မယ်။

Terraform သည် ဤပြဿနာအများစုကို ပြန်လည်စတင်ရန် ကြိုးစားမည်ဖြစ်သော်လည်း သင်ဘာမျှနီးပါးအောင်မြင်မည်မဟုတ်ပါ။ Parallelism=1 သည် AWS API အတွင်း သို့မဟုတ် Terraform ဝန်ဆောင်မှုပေးသူအတွင်း၌ ချို့ယွင်းချက်အချို့ကို တိုက်မိပါက အသုံးပြုရန် အရေးကြီးသောအရာဖြစ်သည်။ ထို့နောက်သင်သတ်မှတ်ရန်လိုအပ်သည်- parallelism=1 နှင့် Terraform ခေါ်ဆိုမှုတစ်ခုပြီးဆုံးသည်အထိစောင့်ပါ၊ ထို့နောက်ဒုတိယ၊ ထို့နောက်တတိယဖြစ်သည်။ သူတို့ကို တစ်လုံးပြီးတစ်လုံး လွှင့်ပစ်မယ်။

လူတွေက ကျွန်တော့်ကို “ဘာလို့ Terraform workspace က မကောင်းဘူးလို့ ထင်ရတာလဲ” ကုဒ်အဖြစ် အခြေခံအဆောက်အအုံ၏နိယာမသည် မည်သည့်အခြေခံအဆောက်အအုံကို ဖန်တီးထားသည်နှင့် မည်သည့်တန်ဖိုးများရှိသည်ကို ကြည့်ရန်ဖြစ်သည်ဟု ကျွန်ုပ်ယုံကြည်ပါသည်။

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

Code နဲ့ ဘယ်လိုအလုပ်လုပ်ရမလဲ။ တကယ်တော့ စာရင်းတွေနဲ့ အလုပ်လုပ်တာက တစ်ခုတည်းသော နာကျင်မှုပါပဲ။ Terraform ကိုပိုမိုလွယ်ကူစွာယူပါ။ ဤအရာသည် သင့်အတွက် ကောင်းသောအရာမှန်သမျှကို ပြုလုပ်ပေးမည့် အရာမဟုတ်ပါ။ အဲဒီမှာ စာရွက်စာတမ်းမှာ ရေးထားတဲ့အရာအားလုံးကို တွန်းချစရာ မလိုပါဘူး။

အစီရင်ခံစာ၏ ခေါင်းစဉ်မှာ “အနာဂတ်အတွက်” ဟု ရေးသားထားသည်။ ဒီအကြောင်းကို အတိုချုံးပြောမယ်။ အနာဂတ်အတွက်၊ ဆိုလိုသည်မှာ 0.12 သည် မကြာမီထွက်ရှိလာတော့မည်ဖြစ်သည်။

0.12 သည် ပစ္စည်းအသစ်တစ်တန်ဖြစ်သည်။ ပုံမှန် ပရိုဂရမ်ရေးဆွဲခြင်းမှ ဆင်းသက်လာပါက၊ ဘယ်ဘက်နှင့် ညာဖက်များကို တပြိုင်နက်တည်း မတွက်ချက်သော်လည်း အခြေအနေပေါ်မူတည်၍ ပြောင်းလဲနေသော ပိတ်ဆို့ခြင်း၊ သင်အများကြီးလွတ်သွားတဲ့အတွက် 0.12 က သင့်အတွက် ဖြေရှင်းပေးပါလိမ့်မယ်။

ဒါပေမယ့်! အဆင်သင့်လုပ်ထားသော modules များနှင့် third-party solutions များကိုအသုံးပြု၍ တိုတိုနှင့်ပို၍ ရိုးရိုးရှင်းရှင်းရေးပါက 0.12 သည် သင့်အတွက် အရာအားလုံးကို ပြုပြင်ပေးမည်ဟု မျှော်လင့်နေစရာမလိုပါ။

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

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

ကျွန်ုပ်သည် ဤအကြောင်းအရာကို တက်ကြွစွာ သုတေသနပြုနေပါသည်၊ ဆိုလိုသည်မှာ သင်ရေးသားခဲ့သည့် အခြေခံအဆောက်အအုံအပေါ် အခြေခံ၍ စစ်ဆေးမှုများကို အလိုအလျောက်ထုတ်လုပ်နည်း။ ဆိုလိုသည်မှာ သင်သည် ဤကုဒ်ကို ရေးခဲ့ပါက ကျွန်ုပ်သည် စမ်းသပ်မှုများကို ဖန်တီးနိုင်သည်ဟူသည့်အချက်အပေါ် အခြေခံ၍ ၎င်းကို run ရန် လိုအပ်ပါသည်။

အကြောက်ဆုံး Terraform အတွက် ပေါင်းစပ်စစ်ဆေးမှုများကို ရေးသားခွင့်ပြုသည့် မကြာခဏ ဖော်ပြထားသော စာကြည့်တိုက်များထဲမှ တစ်ခုဖြစ်သည်။ ဒါက အသုံးအဆောင်တွေထဲက တစ်ခုပါ။ DSL အမျိုးအစား ဥပမာ rspec ကို ပိုကြိုက်တယ်။

Anton၊ အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါတယ်။ ကျွန်တော့်နာမည် Valery ပါ။ ဒဿနမေးခွန်းလေးတစ်ခုမေးပါရစေ။ အခြေအနေအရ နေရာချထားမှု၊ ဖြန့်ကျက်မှု ရှိတယ်။ စီမံဆောင်ရွက်ခြင်းသည် ကျွန်ုပ်၏အခြေခံအဆောက်အအုံကို ဖန်တီးပေးသည်၊ ဖြန့်ကျက်ရာတွင် အသုံးဝင်သောအရာတစ်ခုဖြစ်သည့် ဥပမာ၊ ဆာဗာများ၊ အပလီကေးရှင်းများစသည်ဖြင့် ဖြည့်ဆည်းပေးပါသည်။ ထို့အပြင် Terraform သည် စီမံဆောင်ရွက်ပေးရန်အတွက် ပိုမိုလုပ်ဆောင်ရန်ရှိပြီး Ansible သည် Ansible သည် ရုပ်ပိုင်းဆိုင်ရာအခြေခံအဆောက်အအုံအတွက်လည်းဖြစ်သောကြောင့်၊ nginx၊ Postgres ကို install လုပ်ခွင့်ပြုသည်။ သို့သော်တစ်ချိန်တည်းမှာပင် Ansible သည် ဥပမာအားဖြင့် Amazon သို့မဟုတ် Google အရင်းအမြစ်များကို စီမံဆောင်ရွက်ပေးခြင်းကို ခွင့်ပြုထားပုံရသည်။ သို့သော် Terraform သည် ၎င်း၏ module များကို အသုံးပြု၍ ဆော့ဖ်ဝဲလ်အချို့ကို အသုံးချနိုင်စေပါသည်။ သင့်အမြင်အရ၊ Terraform နှင့် Ansible အကြားတွင်ရှိသော နယ်စပ်မျဉ်းအချို့ရှိပါသလား၊ မည်သည့်နေရာတွင် အသုံးပြုရပိုကောင်းသနည်း။ သို့မဟုတ် ဥပမာအားဖြင့်၊ Ansible သည် အမှိုက်ဖြစ်နေပြီဟု သင်ထင်ပါသလား၊ အရာအားလုံးအတွက် Terraform ကို အသုံးပြုရန် သင်ကြိုးစားသင့်ပါသလား။

မေးခွန်းကောင်း၊ Valery။ Terraform သည် 2014 ခုနှစ်ကတည်းက ရည်ရွယ်ချက် သတ်မှတ်ချက်များတွင် ပြောင်းလဲခြင်းမရှိကြောင်း ကျွန်ုပ်ယုံကြည်ပါသည်။ အခြေခံအဆောက်အအုံအတွက် ဖန်တီးခဲ့ပြီး အခြေခံအဆောက်အအုံအတွက် သေဆုံးခဲ့သည်။ ကျွန်ုပ်တို့တွင် စီမံဖွဲ့စည်းမှု စီမံခန့်ခွဲမှု Ansible လိုအပ်နေသေးသည် ။ စိန်ခေါ်မှုမှာ launch_configuration အတွင်းတွင် သုံးစွဲသူဒေတာများ ရှိနေခြင်းပင်ဖြစ်သည်။ ပြီးတော့ သင် Ansible စသည်တို့ကို ဆွဲထုတ်ပါ။ ဤသည်မှာ ကျွန်ုပ်အနှစ်သက်ဆုံး စံသတ်မှတ်ချက်ဖြစ်သည်။

လှပသောအခြေခံအဆောက်အအုံအကြောင်းပြောလျှင် ဤပုံကိုစုဆောင်းသည့် Packer ကဲ့သို့သော အသုံးဝင်မှုများရှိပါသည်။ ထို့နောက် Terraform သည် ဤပုံကိုရှာဖွေရန်နှင့် ၎င်း၏ launch_configuration ကို အပ်ဒိတ်လုပ်ရန် ဒေတာအရင်းအမြစ်ကို အသုံးပြုသည်။ ဆိုလိုသည်မှာ၊ ဤနည်းအားဖြင့် ပိုက်လိုင်းသည် Tracker ကို ဦးစွာဆွဲထုတ်ပြီးနောက် Terraform ကိုဆွဲခြင်းဖြစ်သည်။ တည်ဆောက်မှု ဖြစ်ပေါ်လာပါက ပြောင်းလဲမှုအသစ် ဖြစ်ပေါ်လာသည်။

မင်္ဂလာပါ! အစီရင်ခံစာအတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်တော့်နာမည် Misha က RBS ကုမ္ပဏီပါ။ အရင်းအမြစ်တစ်ခုဖန်တီးသောအခါတွင် Ansible ကို စီမံပေးသူမှတစ်ဆင့် သင်ခေါ်ဆိုနိုင်ပါသည်။ Ansible တွင် dynamic inventory ဟုခေါ်သော အကြောင်းအရာတစ်ခုလည်း ရှိပါသည်။ Terraform ကို သင် ဦးစွာခေါ်ဆိုနိုင်ပြီး၊ ထို့နောက် ပြည်နယ်မှ အရင်းအမြစ်များကို ရယူပြီး ၎င်းကို လုပ်ဆောင်မည့် Ansible ကို ခေါ်နိုင်သည်။ ဘယ်အရာက ပိုကောင်းလဲ။

လူတွေက နှစ်ခုစလုံးကို ညီတူညီမျှ သုံးစွဲကြပါတယ်။ ကျွန်ုပ်တို့သည် autoscaling အုပ်စုအကြောင်း မပြောပါက Ansible ရှိ တက်ကြွသောစာရင်းအင်းသည် အဆင်ပြေသည့်အရာဟု ကျွန်ုပ်ထင်ပါသည်။ အဘယ်ကြောင့်ဆိုသော် autoscaling group တွင် launch_configuration ဟုခေါ်သော ကျွန်ုပ်တို့၏ကိုယ်ပိုင် toolkit ရှိပြီးဖြစ်သည်။ launch_configuration တွင် ကျွန်ုပ်တို့သည် ရင်းမြစ်အသစ်တစ်ခုကို ဖန်တီးသောအခါတွင် စတင်ရန် လိုအပ်သည့်အရာအားလုံးကို မှတ်တမ်းတင်ပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်၏အမြင်အရ Amazon သည် တက်ကြွသောစာရင်းအင်းကိုအသုံးပြု၍ Terraform ts ဖိုင်ကိုဖတ်ရှုခြင်းသည်အလွန်အကျွံဖြစ်သည်။ အကယ်၍ သင်သည် "autoscaling group" ၏ သဘောတရားမရှိသော အခြားကိရိယာများကို အသုံးပြုပါက၊ ဥပမာအားဖြင့်၊ သင်သည် DigitalOcean သို့မဟုတ် autoscaling group မရှိသော အခြားဝန်ဆောင်မှုပေးသူကို အသုံးပြုသည်၊ ထို့နောက် API ကို ကိုယ်တိုင်ဆွဲထုတ်ရန်၊ IP လိပ်စာများကို ရှာဖွေဖန်တီးရန် လိုအပ်ပါသည်။ တက်ကြွသောစာရင်းဖိုင်တစ်ခုဖြစ်ပြီး Ansible သည် ၎င်းကိုဖြတ်သန်းပြီးဖြစ်သည်။ ဆိုလိုသည်မှာ Amazon အတွက် launch_configuration ရှိပြီး အခြားအရာအားလုံးအတွက် dynamic inventory ရှိပါသည်။

source: www.habr.com