Terraform Day 2: Essential IaC Principles You Must Know

မနေ့ကတော့ Terraform အကြောင်း အကြမ်းဖျင်း Concept ကို ပြောပြခဲ့ပြီးပြီဆိုတော့ ဒီနေ့မှာတော့ Terraform ကို Professional ကျကျ အသုံးချနိုင်ဖို့ သိထားရမယ့် Core Principles တွေအကြောင်း ပြောပြသွားမှာပါ။

ဒီအချက်တွေကို နားလည်ထားမှသာ Terraform ဟာ တခြား Tool တွေထက် ဘာလို့ ပိုသာနေလဲ၊ Automation လုပ်တဲ့အခါ ဘာလို့ ပိုပြီး Reliable ဖြစ်တာလဲဆိုတာ သဘောပေါက်မှာပါ။

Idempotence

ဒါက Terraform ရဲ့ အမိုက်ဆုံး Feature ထဲက တစ်ခုပါ။ Idempotence ဆိုတာက သင့်ရဲ့ Code ကို တစ်ခါပဲ Run Run၊ အခါတစ်ရာပဲ Run Run ရလဒ် က အမြဲတမ်း အတူတူပဲ ဖြစ်နေတာကို ပြောတာပါ။

Terraform က သင်ရေးထားတဲ့ Code (Desired State) နဲ့ Cloud ပေါ်မှာ တကယ်ရှိနေတဲ့ အခြေအနေ (Actual State) ကို အမြဲတမ်း တိုက်စစ်ပါတယ်။ ဥပမာ - သင်က Server ၃ လုံးဆောက်ဖို့ Code ရေးထားတယ်ဆိုပါစို့။

• ပထမတစ်ခါ Run ရင် Terraform က Server ၃ လုံး ဆောက်ပေးမယ်။
• ဒုတိယတစ်ခါ ထပ် Run ရင် Terraform က State ကို အရင်စစ်တယ်။ "Server ၃ လုံး ရှိနေပြီးသားပဲ" ဆိုတာ သိတဲ့အတွက် ဘာမှ ထပ်မလုပ်တော့ပါဘူး။

ဒါကြောင့် CI/CD Pipeline တွေမှာ အကြိမ်ကြိမ် Re-run လုပ်ဖို့အတွက် အရမ်း Safe ဖြစ်ပြီး Duplicate Resource တွေ (မလိုလားအပ်ဘဲ ပွားလာတာမျိုး) ထွက်မလာအောင် တားဆီးပေးပါတယ်။

Immutability

IaC ကို လေ့လာတဲ့အခါမှာ Immutability ဆိုတာ အရမ်းအရေးကြီးပါတယ်။ ဒါကို နားလည်ဖို့ အရင်ကသုံးခဲ့တဲ့ Mutable နဲ့ အခု Terraform သုံးတဲ့ Immutable Infrastructure ဘာကွာလဲဆိုတာ ကြည့်ရအောင်။

1. Mutable Infrastructure - အရင်တုန်းကတော့ Server တစ်လုံးကို Version မြှင့်ချင်ရင် အဲဒီစက်ထဲကို SSH နဲ့ဝင်၊ Setting တွေလိုက်ပြင်ကြပါတယ်။ ဒါကို Mutable (ပြင်ဆင်ပြောင်းလဲလို့ရသော) လို့ ခေါ်ပါတယ်။ ပြဿနာက ကြာလာတဲ့အခါ Server တစ်လုံးချင်းစီရဲ့ Setting တွေဟာ ကိုယ်မသိဘဲ တစ်ခုနဲ့တစ်ခု လွဲချော်ကုန်တာမျိုး ဖြစ်တတ်ပါတယ်။

2. Immutable Infrastructure (Terraform ရဲ့ပုံစံ) - Terraform ကတော့ Immutability လမ်းစဉ်ကို သုံးပါတယ်။ Setting တစ်ခုပြောင်းချင်ရင် ရှိပြီးသား Server ကို လိုက်ပြင်မနေတော့ဘဲ ဖျက်လိုက်ပြီး အသစ်တစ်လုံးနဲ့ အစားထိုး (Replace) လိုက်တာပါ။ ဒါကို "ပြောင်းလဲလို့မရတဲ့ Infrastructure" လို့ သတ်မှတ်နိုင်ပါတယ်။

Encapsulation

ဒါကတော့ Terraform ရဲ့ Modules တွေအကြောင်းပါ။ Encapsulation ဆိုတာ အထဲက ရှုပ်ထွေးတဲ့ Implementation အသေးစိတ်တွေကို ဖုံးကွယ်ထားပြီး အပြင်က သုံးမယ့်သူအတွက် လိုအပ်တဲ့ Inputs နဲ့ Outputs လေးတွေပဲ ပေးထားတာပါ။

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

Cohesion

Cohesion ဆိုတာကတော့ Module တစ်ခုအတွင်းမှာ ဆက်စပ်မှုရှိတဲ့ Resource တွေကိုပဲ စုစည်းထားတာပါ။ Module တစ်ခုဟာ Single Responsibility ပဲ ရှိသင့်ပါတယ်။

ဥပမာ - Networking အတွက်ဆို Networking Module သက်သက်၊ Compute အတွက်ဆို Compute Module သက်သက် ခွဲရေးတာမျိုးပါ။ Networking ထဲမှာ Database ကြီး သွားဆောက်ထားတာမျိုး မလုပ်သင့်ပါဘူး။ ဒီလို ရှင်းလင်းတဲ့ Module Boundaries ရှိမှသာ Code က ဖတ်ရလွယ် (Readability) ပြီး Maintain လုပ်ရတာ ပိုကောင်းမှာပါ။

Declarative

Terraform က Declarative Approach ကို သုံးတဲ့အတွက် ဘယ် Resource က အရင်ဆောက်ရမလဲ၊ ဘယ်သူက ဘယ်သူ့အပေါ် မှီခိုနေလဲ (Automatic Dependency Handling) ဆိုတာကို သူ့ဘာသာ တွက်ချက်ပြီး လုပ်ပေးသွားပါတယ်။ ကျွန်တော်တို့က Step-by-step လိုက်ပြောနေစရာ မလိုတဲ့အတွက် လူကြောင့်ဖြစ်တဲ့ အမှား (Human Error) တွေ အများကြီး လျော့နည်းသွားပါတယ်။

What is DRY ?

Programming မှာလိုပဲ Terraform မှာလည်း DRY Principle က အခြေခံပါပဲ။ Environment ၃ ခု (Dev, Staging, Prod) အတွက် Code ၃ ခါ လိုက်ရေးနေစရာ မလိုပါဘူး။ Variables, Locals နဲ့ Modules တွေကို သုံးပြီး Code တစ်ခါပဲ ရေးမယ်၊ လိုအပ်တဲ့ Values လေးတွေပဲ ပြောင်းပြီး ပြန်ပြန်သုံးသွားမှာပါ။ ဒါမှသာ နောက်ပိုင်း Update လုပ်ချင်တဲ့အခါ တစ်နေရာမှာ ပြင်လိုက်တာနဲ့ အကုန်လိုက်ပြောင်းသွားမှာ ဖြစ်တဲ့အတွက် အလုပ်အရမ်းသက်သာပြီး Error ကင်းစေပါတယ်။

ဒီနေ့ရှင်းပြခဲ့တဲ့ Core Principles တွေကို နားလည်ထားမှသာ လက်တွေ့ Code ရေးတဲ့အခါ ပိုပြီး Professional ကျလာမှာပါ။

ဒီနေ့ကတော့ ဒီလောက်ပါပဲ။ မနက်ဖြန်ကျရင်တော့ လက်တွေ့စမ်းဖို့အတွက် Terraform Installation နဲ့ Azure Setup ကို တူတူလုပ်ကြပါမယ်။ အားလုံးပဲ ဆက်လက်ဖတ်ရှုပေးကြပါဦးဗျ!