Terraform Architecture

ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်

Configuration (`.tf` file တွေ) က 'ငါလိုချင်တဲ့ infrastructure ဘယ်လိုပုံစံ ဖြစ်စေချင်တယ်' ဆိုတဲ့ desired state ကို HCL နဲ့ ရေးထားတာပါ။ State (`terraform.tfstate` file) က Terraform ကိုယ်တိုင် 'ငါ ဘာတွေ create ပြီးသွားပြီလဲ' ဆိုတာကို မှတ်ထားတဲ့ database ပါ — Terraform run တိုင်း state ကို configuration နဲ့ နှိုင်းယှဉ်ပြီး ဘာပြောင်းရမလဲ ဆုံးဖြတ်ပါတယ်။ Provider (`aws`, `azurerm`, `google`, `kubernetes` စသည်) က Terraform ရဲ့ configuration ကို actual API call (AWS API, Azure API) အဖြစ် ပြောင်းပေးတဲ့ plugin ပါ — provider မရှိရင် Terraform က ဘယ် service ကိုမှ ချိတ်ဆက်လို့ မရပါဘူး။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Configuration ထဲမှာ 'AWS EC2 server တစ်လုံး လိုချင်တယ်' လို့ ရေးထားရင် — Terraform က state file ကို ဖွင့်ကြည့်ပါတယ် (server ရှိပြီးလား), မရှိသေးရင် AWS provider ကနေတစ်ဆင့် AWS API ကို 'server အသစ်ဖန်တီးပါ' ဆိုတဲ့ request ပို့ပါတယ်, ပြီးရင် state file ထဲ 'ဒီ server ဖန်တီးပြီးပြီ' လို့ မှတ်ထားပါတယ် — နောက်တစ်ခါ `terraform apply` ထပ်run ရင် state ထဲမှာ ရှိပြီးသားမို့ ထပ်ဖန်တီးမပေးတော့ပါ (idempotent)။

• Configuration (.tf) = desired state ကို HCL နဲ့ ရေးထားခြင်း
• State (terraform.tfstate) = 'ဘာတွေ create ပြီးသွားပြီလဲ' Terraform ကိုယ်တိုင် မှတ်ထားသော database
• Provider = configuration ကို actual API call ဖြစ်အောင် ပြောင်းပေးသော plugin

အတူတူ ကြည့်မယ်

Terraform Core Concepts
=========================

.tf files (Configuration)
  "I want 1 server, 1 database" — desired state, written in HCL

terraform.tfstate (State)
  "Here's what actually exists right now" — Terraform's own record

Provider (e.g. aws, azurerm, google)
  Translates configuration into real API calls to the cloud

apply = compare Configuration vs State -> make API calls to close the gap

Configuration/State/Provider ၃ ခုရဲ့ ဆက်စပ်ပုံကို ရှင်းပြနိုင်မည်။