Terraform Day 3: Benefits of Terraform State

Terraform ကိုလေ့လာ တဲ့အခါ ကျွန််တော်တို့ရဲ့ Project Folder ထဲမှာ terraform.tfstate ဆိုတဲ့ ဖိုင်လေးကို တွေ့ဖူးကြပါလိမ့်မယ်။ ဒီ state file လေးကို Terraform ရဲ့ မှတ်ဉာဏ် လို့ဆိုနိုင်ပါတယ်။ ဒီနေ့မှာတော့ State ရဲ့ အရေးပါပုံ နဲ့ secure ဖြစ်အောင်ဘယ်လို သုံးမလဲဆိုတာ ပြောပြပေးသွားပါမယ်။

Terraform State ဆိုတာ ဘာလဲ?

Terraform State ဆိုတာ ကျွန်တော်တို့ ရေးထားတဲ့ Code (Desired State) နဲ့ Cloud ပေါ်မှာ တကယ်ရှိနေတဲ့ Infrastructure (Actual State) တို့ကို ချိတ်ဆက်ပေးထားတဲ့ "မြေပုံ" တစ်ခု ဖြစ်ပါတယ်။

Code ထဲမှာ Resource တစ်ခုကို ဆောက်ခိုင်းလိုက်ရင် Terraform က အဲ့ဒီ Resource ရဲ့ ID၊ အသေးစိတ် Settings တွေနဲ့ လက်ရှိ အခြေအနေကို JSON format နဲ့ မှတ်ထားလိုက်ပါတယ်။ သင်က နောက်တစ်ခါ terraform plan ရိုက်တဲ့အခါ Terraform က Cloud ဆီ တန်းမသွားဘဲ ဒီ State ဖိုင်ကို အရင်ကြည့်ပြီး ဘာတွေပြောင်းလဲသွားသလဲဆိုတာကို နှိုင်းယှဉ်တာ ဖြစ်ပါတယ်။

ဒါကို ပိုပြီး မြင်သာအောင် ပြောရရင်— ဥပမာ ကျွန်တော်တို့က "Storage Account တစ်ခု ဆောက်မယ်" ဆိုပြီး Code ရေးပြီး Run လိုက်တယ် ဆိုပါစို့။ Terraform က အဲ့ဒီ Storage Account ကို ဆောက်ပေးရုံတင်မကဘဲ၊ သူ့ရဲ့ ID တွေ၊ Settings တွေအားလုံးကို JSON format နဲ့ State ဖိုင်ထဲမှာ မှတ်ထားလိုက်ပါတယ်။

ဒါက ဘာအတွက် အရေးကြီးတာလဲ?

1. Idempotency: ဆောက်ပြီးသားကို ထပ်မဆောက်မိဖို့ လို့ ဘာသာပြန်လို့ရပါတယ်။ ကျွန်တော်တို့ နောက်တစ်ခါ terraform apply ကို ထပ် run ပြီဆိုရင် Terraform က Cloud ဆီကို ချက်ချင်း ရောက်မသွားပါဘူး။ အရင်ဆုံး ဒီ State ဖိုင် ကို ကြည့်ပါတယ်။ "အော်... အရင်တစ်ခါက ငါ ဒီ ID နဲ့ Storage Account ဆောက်ထားပြီးသားပဲ" ဆိုတာ သိသွားတဲ့အတွက် ရှိပြီးသား Resource ကို အသစ်ထပ်မဆောက်တော့ဘဲ ကျော်သွားပေးတာပါ။

2. Drift Detection: အကယ်၍ တစ်ယောက်ယောက်က Azure or AWS Portal ပေါ်မှာ သင်ဆောက်ထားတဲ့ Resource ကို ဖျက်လိုက်တာပဲဖြစ်ဖြစ်၊ Settings သွားပြင်လိုက်တာပဲဖြစ်ဖြစ် လုပ်လိုက်ရင် Terraform က State ဖိုင်ထဲက မှတ်တမ်းနဲ့ တိုက်စစ်ပါတယ်။ cloud ပေါ်မှာတော့ ပြောင်းသွားပြီ၊ ငါ့ဆီက state ထဲမှာတော့ ဒီလိုမဟုတ်ဘူး" ဆိုတာကို သိသွားပြီး Code ထဲကအတိုင်း ပြန်ဖြစ်အောင် လုပ်ပေးနိုင်ပါတယ်။

3. Safe Boundary: Cloud Portal ပေါ်မှာ တစ်ခြား Team တွေက ဆောက်ထားတဲ့ Resource တွေ အများကြီး ရှိနေနိုင်ပါတယ်။ Terraform က apply လုပ်တဲ့အခါ သူ့ရဲ့ State ဖိုင်ထဲမှာ မပါတဲ့ Resource တွေကိုဆိုရင် "သူ့ပစ္စည်းမဟုတ်ဘူး" လို့ သတ်မှတ်တဲ့အတွက် သွားရောက် ပြင်ဆင်တာမျိုး၊ ဖျက်ဆီးတာမျိုး လုံးဝ မလုပ်ပါဘူး။ ဒါကြောင့် Terraform သုံးခြင်းက ကိုယ့် Infrastructure ဘောင်ထဲမှာပဲ ဘေးကင်းကင်းနဲ့ အလုပ်လုပ်နိုင်စေတာပါ။

State ဖိုင် ပျောက်သွားရင် ဘာဖြစ်မလဲ?

အကယ်၍ ကျွန်တော်တို့မှာ State ဖိုင် မရှိတော့ဘူးဆိုရင် Cloud ပေါ်မှာ ဆောက်ခဲ့တဲ့ Resource တွေ ရှိနေသေးရင်တောင် Terraform က အဲဒါတွေကို "သူ့ပစ္စည်း" လို့ မသိတော့ပါဘူး။ အဲဒီအခါမှာ သင်က apply ပြန်လုပ်ရင် Terraform က Cloud ပေါ်က ရှိပြီးသား Resource တွေကို လျစ်လျူရှုပြီး အသစ်တွေ ထပ်ဆောက်ဖို့ ကြိုးစားပါလိမ့်မယ်။ အဲဒီမှာ Name Conflict တွေတက်ပြီး Error တွေ တန်းစီတက်လာတော့တာပါပဲ။ ဒါကြောင့် state file ကိုမဖျက်မိအောင် သတိထားဖို့လိုပါမယ်။

State ၏ အဓိကတာဝန်နှင့် အကျိုးကျေးဇူးများ

HashiCorp ရဲ့ အဆိုအရ State မရှိရင် Terraform ဟာ အလုပ်မလုပ်နိုင်ပါဘူး။ ဘာကြောင့်လဲဆိုတော့ State ဆိုတာ Terraform အတွက် အောက်ပါ အဓိက တာဝန်ကြီးတွေကို ထမ်းဆောင်ပေးနေလို့ ဖြစ်ပါတယ်-

• Mapping to Real World: ကျွန်တော်တို့ Code ထဲမှာ ရေးထားတဲ့ Resource နာမည် နဲ့ Azure ပေါ်က တကယ့် Resource ID အရှည်ကြီးတွေကို State ဖိုင်ကပဲ တွဲပေးထားတာပါ။ ဒါမှသာ နောက်တစ်ခါပြန် run ရင် "အော်... ဒါ ငါဆောက်ထားတဲ့ ပစ္စည်းပဲ" ဆိုပြီး Terraform က မှတ်မိနေမှာ ဖြစ်ပါတယ်။

• Dependency Tracking: Infrastructure တစ်ခုမှာ ဘယ်အရာကို အရင်ဆောက်ရမလဲဆိုတာ အရမ်းအရေးကြီးပါတယ်။ ဥပမာ- Resource Group မရှိဘဲ Storage ဆောက်လို့ မရပါဘူး။ အဲဒီလို Resource တစ်ခုနဲ့တစ်ခုကြားက မှီခိုမှု (Dependency) တွေကို State ဖိုင်က မှတ်သားထားပေးတဲ့အတွက် Terraform က အမှားအယွင်းမရှိ အစီအစဉ်တကျ တည်ဆောက်ပေးနိုင်တာ ဖြစ်ပါတယ်။

• Performance: Cloud ပေါ်မှာ Resource တွေ အများကြီး ရှိလာတဲ့အခါ terraform plan ရိုက်တိုင်း Cloud API ကနေ တစ်ခုချင်း လိုက်မေးနေရင် အချိန်တွေ အများကြီး ကြာပါလိမ့်မယ်။ အဲဒီအစား State ဖိုင်ကို Cache တစ်ခုလို အသုံးပြုပြီး လက်ရှိ အခြေအနေကို နှိုင်းယှဉ်ပြနိုင်တဲ့အတွက် အလုပ်လုပ်ရတာ ပိုမြန်စေပါတယ်။

State နှင့် Sensitive Data

ဒီတစ်ချက်ကိုတော့ အထူးသတိထားစေချင်ပါတယ်။ Terraform နဲ့ အလုပ်လုပ်တဲ့အခါ အရေးကြီးဆုံးနဲ့ အန္တရာယ်အရှိဆုံးအပိုင်းက Security ပါပဲ။ ကျွန်တော်တို့ သိထားရမှာက Terraform State ဖိုင်ဟာ ပုံမှန်အားဖြင့် Secure မဖြစ်ပါဘူး။ အကြောင်းရင်းကတော့ Terraform ဟာ သူ့ရဲ့ State ဖိုင်ကို JSON format နဲ့ သိမ်းဆည်းတဲ့အခါ Plain Text အနေနဲ့ မှတ်သားလေ့ရှိလို့ပါ။ ဥပမာ- သင်က Database Password တွေ၊ Access Keys တွေကို Code ထဲမှာ သုံးထားရင် အဲဒီ Password တွေဟာ State ဖိုင်ကို ဖွင့်ကြည့်လိုက်တာနဲ့ ပေါ်နေမှာ ဖြစ်ပါတယ်။

ဒါကို ဘယ်လိုမျိုး စနစ်တကျ Mask လုပ်မလဲ၊ ဘယ်လို ကိုင်တွယ်မလဲဆိုတာ လေ့လာကြည့်ရအောင်ဗျာ။

• Output Masking: ကျွန်တော်တို့ Infrastructure ဆောက်ပြီးတဲ့အခါ ရလာတဲ့ Password တွေကို Output အနေနဲ့ ထုတ်ကြည့်လေ့ရှိပါတယ်။ အဲဒီအခါမှာ Screen ပေါ်မှာ အားလုံး မြင်မသွားအောင် sensitive = true ဆိုတဲ့ tag လေးကို သုံးပေးရပါတယ်။

1Terraform
2output "db_password" {
3  value     = azurerm_mssql_server.example.administrator_login_password
4  sensitive = true
5}

ဒီလိုလုပ်ခြင်းက terraform apply လုပ်တဲ့အခါ screen ပေါ်မှာ Password အစစ်ကို ပြမယ့်အစား (sensitive value) ဆိုပြီးပဲ ပေါ်နေမှာပါ။ ဒါဟာ ဘေးနားကလူတွေ ဒါမှမဟုတ် Log တွေထဲမှာ Password ပါမသွားအောင် ကာကွယ်ပေးတာ ဖြစ်ပါတယ်။ ဒါဟာ Screen ပေါ်မှာပဲ mask လုပ်ပေးတာပါ။ State ဖိုင်ထဲမှာတော့ Plain Text အတိုင်း ရှိနေဦးမှာဖြစ်လို့ နောက်ထပ် အဆင့်တွေ ဆက်လုပ်ဖို့ လိုပါသေးတယ်။

• Git Ignore: Local State ကို သုံးနေတဲ့ သူတွေအနေနဲ့ .tfstate ဖိုင်တွေကို Git ပေါ် ဘယ်တော့မှ မတင်ပါနဲ့။ အကယ်၍ မှားတင်မိလိုက်ရင် သင့်ရဲ့ Cloud Access Keys တွေနဲ့ Password တွေအားလုံးကို တစ်ခြားသူတွေ သိသွားနိုင်ပါတယ်။

• Remote Backend: တကယ့် Professional လုပ်ငန်းခွင်မှာတော့ State ဖိုင်ကို ကိုယ့်စက်ထဲမှာ မသိမ်းတော့ဘဲ Azure Blob Storage ဒါမှမဟုတ် AWS S3 လိုမျိုး Cloud ပေါ်မှာ သိမ်းဆည်းတဲ့ Remote Backend စနစ်ကို သုံးပါတယ်။

Remote State သုံးတာ ဘာကြောင့် ပိုကောင်းတာလဲ?

1. Cloud Provider တွေက သင့်ရဲ့ State ဖိုင်ကို သိမ်းဆည်းတဲ့အခါ အလိုအလျောက် Encrypt လုပ်ပေးထားပါတယ်။
2. State ဖိုင်ကို ဘယ်သူတွေ ကြည့်ခွင့်ရှိလဲဆိုတာကို Azure AD ဒါမှမဟုတ် IAM Role တွေနဲ့ တိတိကျကျ ကန့်သတ်ထားလို့ ရပါတယ်။
3. Password တွေဟာ သင့်စက်ထဲမှာ မရှိတော့ဘဲ Cloud မှာပဲ ရှိနေတော့မှာပါ။

အနှစ်ချုပ်ရရင်တော့

Security ဆိုတာ "ဖြစ်မှပြင်" ရမယ့် အရာမဟုတ်ဘဲ "မဖြစ်ခင်က တား" ရမယ့် အရာပါ။ Code ရေးတဲ့အခါ sensitive = true သုံးဖို့ မမေ့ပါနဲ့၊ Git ပေါ် မတင်မိအောင် သတိထားပါ၊ အမြဲတမ်း Remote Backend ကို သုံးတဲ့ အလေ့အကျင့် လုပ်ထားပါ

Remote State အလုပ်လုပ်ပုံ

တကယ့်လုပ်ငန်းခွင် မှာဆိုရင် လူတစ်ယောက်တည်း အလုပ်လုပ်တာ မဟုတ်တဲ့အတွက် State ဖိုင်ကို ကိုယ့်စက်ထဲမှာ သိမ်းထားလို့ မရတော့ပါဘူး။ team member အားလုံး တစ်နေရာတည်းကနေ စုပေါင်းပြီး Access ရဖို့နဲ့၊ အရေးကြီးဆုံးဖြစ်တဲ့ State Locking ရဖို့အတွက် Remote Backend ကို သုံးရပါတယ်။ state locking ဆိုတာ လူနှစ်ယောက်က ပြိုင်တူပြင်မိပြီး Infrastructure တွေ ရှုပ်ထွေးမသွားအောင် Lock ချတဲ့စနစ်ဖြစ်ပါတယ်။ တစ်ချိန်တည်းမှာ လူနှစ်ယောက်က ပြိုင်တူ apply မလုပ်မိအောင် lock ချထားတဲ့သဘောဖြစ်ပါတယ်။

Azure Remote Backend Setup ပြုလုပ်ပုံ

Azure သုံးတဲ့ သူတွေအတွက် Azure Blob Storage ကို Backend အဖြစ် အသုံးပြုပြီး ဘယ်လို Setup လုပ်ရမလဲဆိုတာ ရှင်းပြပါမယ်။

Azure မှာ State ဖိုင်ကို သိမ်းဖို့ဆိုရင် အရင်ဆုံး Azure Portal ပေါ်မှာ အောက်ပါ Resource (၃)ခု ရှိနေဖို့ လိုပါတယ်-

1. Resource Group
2. Storage Account
3. Blob Container

ဒီ Resource တွေ ရှိပြီဆိုရင် သင်တို့ရဲ့ Terraform Code (providers.tf သို့မဟုတ် main.tf) ထဲမှာ အောက်ပါအတိုင်း ရေးသားပေးရပါမယ်။

1terraform {
2  backend "azurerm" {
3    resource_group_name  = "tfstate-rg" 
4    storage_account_name = "tfstorage2026"
5    container_name       = "tfstate"
6    key                  = "prod.tfstate"
7  }
8}

ဒီ Setup ကို ရေးပြီးရင် terraform init ကို ပြန် run ပေးဖို့ မမေ့ပါနဲ့။ အဲဒီအခါမှာ Terraform က သင့်စက်ထဲက Local State ဖိုင်ကို Azure ပေါ် ရွှေ့မလား လို့ မေးပါလိမ့်မယ်။ အဲဒီမှာ yes လို့ ရိုက်ပေးလိုက်တာနဲ့ သင့်ရဲ့ State ဖိုင်ဟာ Cloud ပေါ်ကို လုံလုံခြုံခြုံ ရောက်ရှိသွားမှာ ဖြစ်ပါတယ်။

အနှစ်ချုပ်နှင့် သတိပြုရန်

Terraform State ဆိုတာ Terraform ရဲ့ အရေးကြီးဆုံး အစိတ်အပိုင်းပါ။ သိထားရမယ့် အချက်တွေကတော့-

• Manual Edit မလုပ်ပါနဲ့ State ဖိုင်ကို ကိုယ့်ဘာသာ ဝင်ပြင်တာမျိုး လုံးဝမလုပ်ပါနဲ့။
• Remote Backend ကို အမြဲသုံးပါ
• State ထဲမှာ password တွေ access keys တွေဟာ Plain text အတိုင်း ရှိနေနိုင်တာကို အမြဲသတိပြုပါ။

ဒီနေ့မှာတော့ သင်ဟာ Terraform State ရဲ့ Concept တွေအကြောင်းကို ပြည့်ပြည့်စုံစုံ လေ့လာခဲ့ပြီး ဖြစ်ပါတယ်။ နောက်နေ့မှာတော့ terraform အခြေခံတွေအကြောင်းကို ထပ်ပြီးရေးပေးပါဦးမယ်