Terraform ဘာလဲ

Terraform အကြောင်း မပြောခင် Cloud Platform တွေကနေ စပြောမှဖြစ်မယ်။ ဒါမှ သမိုင်းကိုသိမှာ။ သမိုင်းကို မသိရင် Terraform ဆိုတာက IaC - IaC ဆိုတာ Infrastructure as Code နဲ့တင် ပြီးနေမှာပဲ။

Cloud provider တွေဖြစ်တဲ့ AWS, GCP နဲ့ Azure platform တွေက internet ပေါ်က တခြား web program တွေနည်းတူ backend server တွေပဲဖြစ်တယ်။ ကျွန်တော်တို့ VM တလုံး ဆောက်ချင်၊ ဖျက်ချင်၊ နာမည်တွေ ချိန်းချင်တဲ့အခါတွေမှာ အဲဒီ backend server တွေရဲ့ /instances, /instances/{id} လိုမျိုး endpoint တွေဆီ API request တွေပို့ရပါတယ်။ အဲဒီ API တွေကို team တခုချင်းစီက တာဝန်ယူပြီး develop နဲ့ maintain လုပ်နေကြတယ်။ ဥပမာ AWS မှာဆိုရင် Virtual Machine, VM Templates, Load Balancer စတဲ့ endpoint တွေပါတဲ့ backend service အတွက် EC2 unit မှာ တာဝန်ရှိတယ်။

ဒါပေမယ့် အစောပိုင်းကာလမှာ unit တွေအကြား standard မရှိသလို API တွေကလည်း architecture မျိုးစုံရောထွေးနေတယ်။ အဲဒါကြောင့် သုံးရတဲ့အခါ အခက်အခဲရှိတယ်။ AWS အနေနဲ့ ဒီပြဿနာကို ဖြေရှင်းဖို့အတွက် high level module တွေထုတ်ပေးခဲ့တယ်။ အဲဒီ module တွေက backbone API တွေကို တိုတိုရှင်းရှင်း အလွယ်ခေါ်သုံးနိုင်အောင် language အမျိုးမျိုးနဲ့ အုပ်ပေးထားတာဖြစ်ပြီး AWS SDK လို့ခေါ်ကြတယ်။

ဒီ SDK တွေကြောင့် အရင်ကနဲ့စာရင် Cloud service တွေကို ကိုယ့် application ထဲကနေ interact လုပ်ရတာ အများကြီးပိုလွယ်လာတယ်။ တခုမေးစရာရှိတာက ဘယ်သူတွေက အဲလိုလုပ်ချင်တာလဲပေါ့။ console UI ကနေ ဘာလိုလို နှိပ်လို့ရနေတာပဲ၊ ဘာလို့ AWS backend ဆီတိုက်ရိုက် API request တွေပို့နေဦးမှာလဲ။

Cloud computing ခေတ်စားမလာခင်ကတည်းက ကုမ္ပဏီတွေက သူတို့ရဲ့ ကိုယ်ပိုင် management portal တွေက တဆင့်ပဲ infrastructure ကိုစီမံကြတယ်။ private cloud ပေါ့။ နောက် cloud ခေတ်စားလာတဲ့အခါမှာလည်း ရှိနှင့်ပြီးသား portal သူတို့နဲ့ရင်းနှီးပြီးသား workflow တွေကိုပဲ ဆက်သုံးချင်တဲ့အတွက် စောစောကပြောတဲ့ management portal တွေကနေ cloud environment ကိုပါ လှမ်းထိန်းနိုင်အောင် ပြင်လာကြတယ်။ AWS, GCP, Azure စသဖြင့် vendor တွေတိုင်း standard specification တခုထားပြီး API ထုတ်ပေးရေး ဘာညာတောင် ခေတ်စားလိုက်သေးပေမယ့် ဖြစ်တော့ မလာခဲ့ပါဘူး။

ပြန်ဆက်ရရင် Portal developer တွေရဲ့ဘဝကိုဒီ SDK တွေက အများကြီး လွယ်ကူစေခဲ့တယ်။ ကြုံတုန်း တခုပြောပြရရင် အဲဒီ SDK တွေက resource management လုပ်ဖို့ချည်းသက်သက် မဟုတ်ဘူး။ resource consumer တွေအတွက်လည်း code တွေပါတယ်။ ဥပမာ S3 Bucket ဆောက်ဖို့၊ ဖျက်ဖို့၊ policy ရေးဖို့လောက် Java နဲ့ JavaScript library တွေ ရှိတာမဟုတ်ပဲ media file တွေ upload လုပ်ဖို့၊ encrypt လုပ်ဖို့ function နဲ့ class တွေပါ ပါပြီးသား ဖြစ်တာမျိုး။ Java SDK နဲ့ဆိုရင် SQS Virtual Queue တွေဆောက်လို့ရတာမျိုး စသဖြင့်။ ပြီးတော့ အရင်က AWS CLI binary ဆိုတာလည်း Python SDK ကိုအုပ်ထားတာပါပဲ။ အခုတော့ အဲလိုဟုတ်သေးလား မသိဘူး။

ဆိုတော့ Terraform ရဲ့ဖလော်ဆော်ဖီကို ၃ ပုံပုံရင် ၁ ပုံက ဒီပြဿနာကို ကိုင်တွယ်ထားတာ။ AWS, Azure ဘယ် cloud provider ပဲလာလာ VM, Bucket ဘယ် resource ပဲလာလာ သူတို့ကို create, read, update, delete မယ့် CRUD တွေက တနည်းတည်း ရှိရမယ်။ ဒါက အခြေခံအကျဆုံးအပိုင်းပဲ။

ဘာလို့ ဒီလိုလုပ်နိုင်လဲဆိုရင် Terraform က HCL လို့ခေါ်တဲ့ HashiCorp Configuration Language ကိုအခြေခံပြီး DSL ပြန်ထုတ်ထားတယ်။ အဲဒီ DSL ကိုအခုချရေး၊ အခု parse လုပ်ပြီး ဘယ် resource တွေကို create မယ်၊ delete မယ်၊ update မယ်ဆိုတာ ချက်ချင်း map လုပ်နိုင်တယ်။ ပြီးရင် သက်ဆိုင်ရာ SDK နဲ့ API တွေကို သင့်သလို ခေါ်သွားမယ်။ ဥပမာ EC2 instance တခုလိုချင်တယ်ပြောရင် AWS SDK ထဲက ec2 module ကိုသုံးပြီး VM တခုဆောက်ပေးမယ် ဒီလိုပေါ့။

ဒါပေမယ့် Terraform user တယောက်က နောက်ကွယ်မှာ AWS SDK ကိုသုံးထားသလား သိဖို့မလိုသလို သုံးတတ်ဖို့လည်း မလိုဘူး။ လိုအပ်တာက Terraform language သုံးပြီး Terraform configuration code တွေဘယ်လိုရေးရမလဲဆိုတာကိုသာ နားလည်ထားဖို့ပါ။

ဒီလိုမျိုး DSL သုံးပြီး ကိုယ်လိုချင်တဲ့ resource ကိုဖော်ပြလို့ရခြင်းက Terraform ဖလော်ဆော်ဖီရဲ့ ဒုတိယ ထောက်တိုင်ပဲ။ ဒါကို codability လို့ခေါ်တယ်။ Infrastructure as Code ဆိုတဲ့ term က ဒါကို ဆိုလိုတာပေါ့။ ဒီတော့ infrastructure ကို code အဖြစ် ဖော်ပြလို့ရတော့ ဘာထူးသွားလဲ မေးမယ်။ Unit test တွေတိတိကျကျ စစ်လို့ရတယ်။ အင်္ဂလိပ်စာ၊ ဗမာစာကို Unit test စစ်လို့မရဘူး။ လွန်ရော၊ သဒ္ဒါလောက်ပဲ စစ်လို့ရမယ်။ နောက်တချက်က အဲဒီ Terraform configuration ဖိုင်တွေကို GitHub နဲ့ BitBucket စသဖြင့် VCS တွေမှာ သိမ်းပြီး version control လုပ်လို့ကောင်းမယ်။ အရေးအကြီးဆုံးက code ဖြစ်သွားတဲ့အတွက် infrastructure တည်ဆောက်တာ ဖျက်ဆီးတာတွေကို automation လုပ်လို့ရသွားတယ်။

ဥပမာ "ငါတို့ Team=Backend ဆိုတဲ့ tag ကိုသုံးပြီး VM တလုံးဆောက်ခဲ့ကြတယ်" ဆိုတဲ့စာသားကို ကွန်ပျူတာက ဘာမှ automate လုပ်ပေးလို့မရဘူး။ ဒီအဓိပ္ပါယ်ပေါက်အောင် နောက်တယောက်က နောက်တမျိုး ပြောင်းရေးမယ်ဆို ရေးလို့ရတယ်။ ကွန်ပျူတာ နားမလည်တာ နားမလည်တာပဲ။ ဒါပေမယ့် new VM(tags = {"Team": "Backend"}); ဆိုရင်တော့ program တခုခုက အောက်ခြေက သူနဲ့သက်ဆိုင်ရာ implementation ကိုခေါ်ပြီး VM တလုံး ဆောက်သွားပေးနိုင်တယ်။ ဘာလို့လဲဆိုတော့ VM() ဆိုတဲ့ constructor မှာ အဓိပ္ပါယ် အတိအကျ ရှိပြီးသား။ ဘယ် token ဟာ ဘာကိုဆိုလိုတယ်ဆိုတာမျိုး သတ်မှတ်ထားပြီးသားကိုး။

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

ဒီအချက်က infrastructure management ကို အရင်က လူကိုယ်တိုင် manual လုပ်ရာက CI/CD နဲ့တခြား system တွေကနေတဆင့် automated အလိုအလျောက် အလုပ်လုပ်လာနိုင်စေခဲ့တာပဲ။

Terraform ဖလော်ဆော်ဖီရဲ့ နောက်ဆုံး ၁ ပုံက declarative interface ပါ။ declarative design က Terraform ကိုတခြား tool တွေနဲ့ ကွဲထွက်သွားစေသလို Terraform ကိုအသုံးချတဲ့အခါမှာလည်း ကျွန်တော်တို့ မဖြစ်မနေ နားလည်ထားရမယ့်ဟာဖြစ်တယ်။