Hola Terraform !

ပထမဆုံး Terraform ကို အသုံးပြုပြီး infrastructure ကို provisioning လုပ်တော့မယ်ဆိုရင် Hashicorp configuration language နဲ့ code ဘယ်လို ရေးရသလဲ၊ Terraform ဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာသိဖို့ အရေးကြီးပါတယ်။ ဒါမှ ကျွန်တော်တို့ infrastructure ကို လိုချင်တဲ့ပုံစံ ရေးသားတဲ့အခါမှာ၊ တည်ဆောက်တဲ့အခါမှာ၊ ပိုမိုနားလည်သဘောပေါက်ပြီး ပြသနာတစ်ခုခုဖြစ်တဲ့အခါ တွေးတောဖြေရှင်းနိုင်မှာ ဖြစ်ပါတယ်။ Terraform ကို အလွယ်ဆုံး ဘယ်လိုအလုပ်လုပ်လဲ ဆိုတာကို နားလည်ဖို့ အကောင်းဆုံးနည်းလမ်းကတော့ cloud (AWS, GCP, Azure) ဒါမှမဟုတ် Vsphere အပေါ်မှာ VM တစ်ခုခု စမ်းဆောက်ကြည့်တာပါပဲ။ အခုပြောမယ့်ထဲမှာတော့ AWS ပေါ်မှာ VM တစ်ခု ဆောက်ပြပြီး step တွေကို အသေးစိတ် ပြောသွားမှာ ဖြစ်ပါတယ်။ တကယ်တော့ အကုန်လုံးကတော့ သဘောတရားချင်းတူပါတယ်။ ဘာလို့ AWS နဲ့လဲဆိုတော့ ကျွန်တော်ရှိမှာ အလွယ်တကူ AWS နဲ့ အဆင်သင့်ဖြစ်နေလို့ပါဘဲ။ အဲတော့ အခုပြောမဲ့ scenarios မှာ terraform ရဲ့ AWS provider ကို အသုံးပြုသွားမှာ ဖြစ်ပါတယ်။ Terraform ရဲ့ AWS provider ကတော့ လိုအပ်တဲ့ API calls တွေကို ပြုလုပ်ပြီး VM (EC2) ကို တည်ဆောက်ပေးသွားမှာ ဖြစ်ပါတယ်။ ပြီးသွားရင်တော့ ပြန်ဖျက်သွားမှာပါ။ AWS အပေါ်မှာ တည်ဆောက်မှာဖြစ်တဲ့အတွက် AWS credential လိုပါတယ်။ ပြီးတော့ ကိုယ်သုံးမယ့် credential ရဲ့ access key, secret key တွေက AWS ရဲ့ IAM မှာ အနည်းဆုံး EC2 ကို create delete လုပ်လို့ရတဲ့ permission လိုပါတယ်။

Using Terraform to provision an EC2 instance to AWS

ဒီ scenario အတွက် prerequisite တွေကတော့ - terraform 0.12.X ကို စက်ထဲထည့်ထားရမှာဖြစ်ပါ တယ်။ aws cli လိုအပ်ပါတယ်။ ဒါပြီးသွားရင် VM deploy ပြုလုပ်မယ့် operation တွေကတော့ -

• vm ကို တည်ဆောက်မယ့် terrafrom configuration files ကို ရေးရပါမယ်

• AWS provider ကို configure ပြုလုပ်ရပါမယ်

• ပြီးရင် terraform ကို initializing ပြုလုပ်ရပါမယ်

• Initialization ပြုလုပ်ပြီးရင်တော့ vm ကို deploy ပြုလုပ်ပါမယ်

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

visualized the sequence of operations

အခုအချိန်မှာ terraform 0.12.x ကို laptop ထဲမှာ ထည့်သွင်းပြီး aws cli ကိုပါ configure ပြုလုပ်ပြီးပြီ ဟုယူဆပါမယ်။ ပထမဆုံး ကျွန်တော်တို့ HCL ကို ရေးဖို့ main.tf ဆိုတဲ့ file ကို တည်ဆောက်ပါမယ်။ .tf extension ကတော့ terraform ရဲ့ configuration ဖြစ်တယ်လို့ terraform run တဲ့ အချိန်မှာ အချက်ပြလိုက်သလိုပါဘဲ၊ main ကတော့ convention၊ terraform ရဲ့ entry point ပေါ့၊ ဒါပေမဲ့ ဒီ main နေရာမှာ ကြိုက်တဲ့နာမည် ထားလို့ရပါတယ်။ ကျွန်တော်ကတော့ ပုံမှန် main နဲ့ဘဲ အသုံးများတယ်။ terraform တကယ် ဂရုစိုက်တာကတော့ သူ run သွားတဲ့ directory အောက်က .tf file ပါဘဲ။

Terraform

main.tf

resource "aws_instance" "k8smm" {
  ami           = "ami-0520e698dd500b1d1"
  instance_type = "t2.micro"
  }

AWSCloudFormation

{
  "Resources": {
    "k8smm": {
      "Type": "AWS::EC2::Instance",
        "Properties": {
          "ImageId": "ami-0520e698dd500b1d1",
          "InstanceType": "t2.micro"
         }
       }
     }
   }

Terraform က declarative (declare what we want) ဆိုတဲ့အတိုင်း main.tf file ထဲမှာ ကျွန်တော်တို့ တည်ဆောက်ချင်တဲ့ image ရဲ့ AMI ရယ်၊ instance type ရယ်ကို ထည့်ပေးရပါတယ်။ ami id ကိုတော့ Red Hat Enterprise Linux 8 ကိုသုံးထားပါတယ်။ instance type ကိုတော့ t2.micro ဆိုတဲ့ အသေးစားလေးဘဲ သုံးထားပါတယ်။ နောက်တစ် tab မှာရှိတဲ့ syntax တွေကတော့ အခု terraform ကို သုံးပြီး တည်ဆောက်မဲ့ HCL language ရဲ့ code တွေနဲ့ အဓိပ္ပါယ် တူညီတဲ့ AWS ရဲ့ CloudFormation json syntax ဖြစ်ပါတယ်။

ဒီ RHEL8 ami ကတော့ us-east-2 အတွက်ဘဲ valid ဖြစ်ဖို့ များပါတယ်။

Terraform syntax of AWS EC2 instance

အပေါ်ကပုံကတော့ အခု provision လုပ်တဲ့အခါမှာ သုံးသွားတဲ့ terraform ရဲ့ keyword တွေနဲ့ syntax ပုံစံတွေ ဖြစ်ပါတယ်။ Terraform ကို အသုံးပြုပြီး Infra Resources တွေကို တည်ဆောက်တဲ့ အခါမှာ type resource နဲ့ resource ရဲ့ name ဆိုတဲ့ label နှစ်ခု အတိအကျ ပါဝင်ရမှာ ဖြစ်ပါတယ်။ resource ဆိုတာကတော့ terraform ရဲ့ element ဖြစ်ပြီး အရေးပါပါတယ်။ terraform မှာ resource က အများဆုံးသုံးရတဲ့ element ဖြစ်တယ်။ ကျွန်တော်တို့ ဘယ် resource ကို သုံးပြီး ဘာလုပ်မယ်ဆိုတာကို ကြေငြာတဲ့ သဘောပါ။ variable, data, provider တို့ကတော့ resource လိုမျိုး တစ်ခြားသော terraform ရဲ့ element တွေ ဖြစ်ပါတယ်။ resource အနောက်မှာတော့ ဘာကို create လုပ်မယ်ဆိုတဲ့ resource type ကို ထည့်ပေးရပါတယ်။ အခုလက်ရှိ ဒီမှာတော့ ec2 instance ကို တည်ဆောက်မှာမို့ aws_instance ကိုထည့်ထားပါတယ်။ ဒါကတော့ ပထမ label ဖြစ်ပြီး ရှေ့က resource ရဲ့type ဖြစ်ပါတယ်။ အဲ့နောက်မှာ ဒုတိယ label ကတော့ resource ရဲ့ name ဖြစ်ပါတယ်။ name မှာတော့ ကိုယ်ကြိုက်တာ ပေးလို့ရပါတယ်။ အဓိက name ကတော့ resource တွေကို reference ပြုလုပ်ဖို့သုံးတာ ဖြစ်ပါတယ်။ ပြီးတော့ type နဲ့ name နှစ်ခု ပေါင်းကတော့ identifier ဖြစ်ပါတယ်။ ဒါကြောင့်မို့ identifier ဆိုတာက identified ပြုလုပ်နိုင်ဖို့ unique ဖြစ်ရပါမယ်။

resource တစ်ခုစီတိုင်းမှာ inputs တွေနဲ့ outputs တွေ ရှိကြပါတယ်။ inputs တွေကိုတော့ arguments တွေ ဖြစ်ကြပြီး outputs တွေကတော့ attributes တွေဖြစ်ကြပါတယ်။ arguments တွေကတော့ resource name နောက်က တွန့်ကွင်း အဖွင့်အပိတ်ထဲမှာ ရေးရပြီးတော့ output အနေနဲ့ attributes အနေနဲ့ ပြန်ရရှိနိုင်ပါတယ်။ ဒါပေမဲ့ attributes တိုင်းတော့ မဟုတ်ပါဘူး။ တခြားသော attributes တွေကတော့ ကျွန်တော်တို့ output အနေနဲ့ set လုပ်စရာမလိုဘဲ resource တည်ဆောက်ပြီးမှသာလျှင် ရရှိမှာဖြစ်ပါတယ်။ ဒါကိုတော့ computed attributes တွေလို့ခေါ်ပြီး အဲ့ computed attributes တွေက အမြဲတမ်း resource ရဲ့ information တွေနဲ့ metadata တွေကို တွက်ချက်ပါတယ်။

Resource inputs and outputs for k8smm

အပေါ်က ပြောခဲ့တဲ့ operations အတိုင်း ec2 instance တည်ဆောက်ဖို့ terraform configuration file ကို ရေးပြီးတော့ aws provider အတွက် configure ထပ်လုပ်ပါမယ်။ AWS provider ကတော့ AWS ကို API Calls တွေခေါ်ပြီး authenticated ဖြစ်စေရန်အတွက် ဖြစ်ပါတယ်။ Terraform က သူရဲ့ configuration code တွေကို ဖတ်ပြီး evaluate လုပ်တဲ့အခါမှာ provider မှ လိုအပ်တဲ့ resource တွေကို dynamically ရှာဖွေပြီး လိုအပ်တာတွေကို လုပ်ပေးပါတယ်။ ဒီနေရာမှာ provider ကို auth ပြုလုပ်ဖို့ အရင် terrform version 0.11 အထိ aws credentials ကို file ကနေဖတ်ပြီး သုံးကြပါတယ်။ terraform version 0.12 မှစပြီး file မှ credentials တွေ ဖတ်တာ deprecated ဖြစ်သွားပါပြီ။ terraform version 0.12 မှာတော့ ~/.aws/credentials ကနေ သို့မဟုတ် environment variable မှတဆင့် credentials ကို ဖတ်ပါတယ်။

provider.tf

provider "aws" {
  version = "2.12.0"
  region = "us-east-2"
}

main.tf

provider "aws" {
  version = "2.12.0"
  region  = "us-east-2"
}

resource "aws_instance" "k8smm" {
  ami           = "ami-0520e698dd500b1d1"
  instance_type = "t2.micro"
}

အပေါ်မှာ ပြထားတဲ့အတိုင်း provider ကိုတော့ provider.tf ဆိုပြီး နောက်တစ် file ခွဲရေးလို့ရသလို main.tf file ထဲမှာလဲ တစ်ခါထဲ ပေါင်းရေးလို့ရပါတယ်။ provider မှာတော့ output မရှိပါဘူး။ code block ထဲမှာ ထည့်ပေးရမဲ့ inputs (configuration arguments) ဘဲ ရှိပါတယ်။ အခုဒီမှာ သုံးထားတဲ့ inputs configurations တွေကတော့ region နဲ့ provider version ဘဲဖြစ်ပါတယ်။ credentials တွေကို inputs configuration ထဲမထည့်တော့ပါဘူး။ အပေါ်မှာ ပြောခဲ့သလို ~/.aws/credentials ထဲကနေဘဲ အလိုအလျောက် ဖတ်ပါ့မယ်။ ဒါဆိုရင်တော့ ကျွန်တော်တို့ နောက်တဆင့်ဖြစ်တဲ့ terraform ကို Initialization ပြုလုပ်လို့ရပါပီ။ အခု terraform code တွေ ရေးထားတဲ့ folder က terraform အတွက် workspace အသစ်ဖြစ်နေပြီး workspace အသစ် တိုင်းအတွက် Initialization ပြုလုပ်ဖို့လိုအပ်ပါတယ်။ Initialization ပြုလုပ်ဖို့အတွက်ကတော့ terraform init command ကို run ရုံပါဘဲ။ terraform init လုပ်လိုက်တဲ့အခါမှာ လိုအပ်တဲ့ provider binary တွေကို .terraform/plugins အောက်ထဲကို ဒေါင်းလော့ဆွဲချပေးသွားမှာ ဖြစ်ပါတယ်။

Terraform Initialization

Initialization လုပ်ပြီးသွားရင်တော့ terraform apply command နဲ့ AWS အပေါ်မှာ ec2 instance ကို တည်ဆောက်သွားမှာ ဖြစ်ပါတယ်။ terraform apply ရိုက်ရိုက်ချင်း ec2 instance ကို တန်းပြီး create မလုပ်သေးပါဘူး။ terminal မှာ output အနေနဲ့ execution plan ကို ထုတ်ပြပြီး ဒါကို လုပ်ဆောင်မှာလား မလုပ်ဆောင်ဘူးလားဆိုတာ ကို yes နှိပ်ခိုင်းပြီး confirm ပြုလုပ်ခိုင်းပါတယ်။ terraform plan ဆိုတဲ့ command နဲ့ execution plan ကိုပဲ သီးသန့်ထုတ်ကြည့်လို့ ရပါတယ်။ ဒါကတော့ ကိုယ်တစ်ခုခု မလုပ်ခင်မှာ သေချာအောင် အရင် review လုပ်ဖို့ကောင်းတဲ့ idea ပါဘဲ။ Yes နှိပ်ပြီး အတည်ပြုပြီးတဲ့ အခါမှာတော့ အချိန်အနည်းငယ်အတွင်းမှာ ပြီးစီးသွားပြီး apply complete ဆိုပြီး ပြပါတယ်။ အဲနောက်မှာတော့ aws cli ကနေ create လုပ်သွားတဲ့ instance ကို verify ပြုလုပ်နိုင်ပါတယ်။

Terraform apply

Aws အပေါ် resource တည်ဆောက်သွားသမျှ track လုပ်ထားတဲ့ stateful information အားလုံးကို terraform.tfstatefile ထဲမှာ json အနေနဲ့ သိမ်ဆည်းထားပါတယ်။ terraform.tfstate file ထဲမှာ metadata များစွာပါဝင်ပြီး json အနေနဲ့ ဖတ်ရတာ ခက်ခဲပါတယ်။ ဒါကို terraform show command ကို အသုံးပြုပြီး terraform state file မှ data များကို human readable ပုံစံပြန်ထုတ်ပြီး အလွယ်တကူ ဖတ်နိုင်ပါတယ်။ သတိထားမိလားတော့ မသိဘူး။ ကျွန်တော်တို့ ec2 instance တည်ဆောက်ဖို့ ami နဲ့ instance_type နှစ်ခုကိုပဲ inputs အနေနဲ့ ထည့်ခဲ့ပြီး state file ထဲမှာတော့ data တွေ အများကြီး ( ဥပမာ - security_groups, subnet_id, vpc_security_group_ids ) တွေကို တွေ့ရမှာပါ။ အဲ့ဒါတွေ အာလုံးက မထည့်လည်းရတဲ့ optional arguments တွေနဲ့ resource တည်ဆောက်ပြီးတဲ့အခါမှာ ထွက်လာတဲ့ computed attributes တွေဘဲ ဖြစ်ပါတယ်။ ဒါကြောင့်မို့လို့ optional attributes တွေကတော့ default values အနေနဲ့ တည်ဆောက်သွားပါတယ်။

Terraform show

ဖြစ်ပြီး ပျက်ဆိုတဲ့အတိုင်း😜 အခုကတော့ တည်ဆောက်ပြီးပြီဆိုတော့ ပြန်ဖျက်ဖို့ဘဲ ကျန်တော့တယ်။ တစ်ကယ်တော့ ကျွန်တော်တို့ တည်ဆောက်ခဲ့တာတွေဟာ တချိန်မှာ အသုံးမလိုတော့တဲ့ အခြေအနေမျိုးတွေ ဖြစ်လာတတ်ပါတယ်။ အဲလို အခြေအနေမျိုးအတွက် ခုနက terraform.tfstate file သာ ရှိတယ်ဆိုရင် terraform destroy command ကို အသုံးပြုပြီး တည်ဆောက်ခဲ့သမျှ resource အားလုံးကို ပြန်လည်ဖျက်ပစ်နိုင်ပါတယ်။

Terraform destroy

တကယ်တော့ terrafrom destroy ပြုလုပ်လိုက်တဲ့အခါမှာ ကျွန်တော်တို့ အမြင်မှာက တည်ဆောက်ခဲ့တာကို ပြန်လည်ဖျက်ပစ်တာဖြစ်ပြီး terraform အနေနဲ့တော့ destroy ပြုလုပ်တဲ့ plan တစ်ခုဖြစ်ပါတယ်။ အခုလိုဖျက်ပစ်တဲ့ action ပြုလုပ်လိုက်တာကို destroy plan လို့ ခေါ်ပါတယ်။ အခုလို မဖျက်ခင်မှာ တကယ်ဆိုရင် ဖျက်မလား မဖျက်ဘူးလားကို အတည်ပြုခိုင်းဦးမှာပါ။ terraform apply ပြုလုပ်တုန်းက plan executed မဖြစ်ခင် confirm ပြုလုပ်ခိုင်းတာနဲ့ တူညီပါတယ်။ ဒီတခါမှာတော့ ကိုယ့်ဘက်က သေချာနေတဲ့ အခြေအနေမို့ yes ရိုက်ထည့်မယ့်အစား -auto-approve ထည့်ပေးလိုက်တာပါ။ destroy လုံး၀အပြီးအစီး ပြုလုပ်ပြီးတဲ့ အခါမှာတော့ terraform apply ပြုလုပ်ခဲ့သမျှ အရာတွေ အားလုံးဟာ အတိအကျ ပျက်စီးသွားမှာ ဖြစ်ပါတယ်။ terraform show နဲ့ verify ပြုလုပ်နိုင်ပါတယ်။