Terraform + Crossplane: Modern GitOps Platform
Cloud Native လောကမှာ Infrastructure as Code (IaC) လို့ပြောလိုက်ရင် လူတိုင်းပြေးမြင်ကြတာက Terraform ပါ။ ဒါပေမဲ့ အခုနောက်ပိုင်းမှာ Kubernetes-native ဖြစ်တဲ့ Crossplane ကလည်း အရမ်းကို ရေပန်းစားလာပါတယ်။
Engineer တော်တော်များများက Terraform နဲ့ Crossplane ဘယ်ဟာ ပိုကောင်းလဲ လို့ ယှဉ်လေ့ရှိကြပေမဲ့၊ တကယ့် လက်တွေ့ Industry ရဲ့ အကောင်းဆုံး Practice ကတော့ အဲ့ဒီနှစ်ခုကို ယှဉ်သုံးတာထက် Hybrid Approach ကတော့ အကောင်းဆုံးပဲ ဖြစ်ပါတယ်။ အရင်ဆုံးအနေနဲ့ ကျွန်တော်တို့ ဒီ Tools နှစ်ခုရဲ့ အားသာချက် အားနည်းချက်တွေကို သိဖို့လိုပါတယ်။
Terraform
Terraform ဟာ Infrastructure Provisioning အတွက် အသင့်တော်ဆုံးပါပဲ။ Multi-Cloud Provider ကို support ပေးပြီး၊ ကျယ်ပြန့်တဲ့ Infrastructure ကြီးတစ်ခုလုံးကို တည်ဆောက်တဲ့နေရာမှာ အရမ်းကို Mature ဖြစ်တဲ့ tool တစ်ခုပါ။ သို့သော် သူရဲ့ အားနည်းချက်က Maintenance မှာပါ။ ကျွန်တော်တို့က Terraform ကိုအသုံးပြုပြီး AWS ပေါ်မှာ Infrastructure တစ်ခုတည်ဆောက်ထားတယ်ပဲဆိုပါတော့ဗျာ။ တစ်ယောက်ယောက်ကများ AWS Console ထဲဝင်ပြီး Manual သွားပြင်လိုက်တယ်ထားပါတော့။ ဒီလိုမျိုး Configuration Drift မျိုးကို Terraform ကနေမှ ချက်ချင်းမသိနိုင်ပါဘူး။ Terraform က state ကို track လုပ်ပြီး plan/apply မှာ current state နဲ့ desired config ကို compare လုပ်ပါတယ်။ Drift ကိုလည်း refresh အဆင့်နဲ့ plan/apply အတွင်းမှာ detect လုပ်နိုင်ပေမဲ့၊ Crossplane လို always-on controller မဟုတ်နေပါဘူး။
Crossplane
Crossplane သည် open-source Kubernetes extension တစ်ခု ဖြစ်ပြီး Kubernetes cluster တစ်ခုကို universal control plane တစ်ခုအဖြစ် ပြောင်းလဲပေးနိုင်သော framework တစ်ခု ဖြစ်ပါတယ်။ သူရဲ့ အဓိက ရည်ရွယ်ချက်ကတော့ platform team များအနေဖြင့် cloud provider များ၏ Infrastructure များကို standard Kubernetes API များမှတစ်ဆင့် စီမံခန့်ခွဲနိုင်ရန်နှင့် application developer များအတွက် self-service အခြေအနေကို ဖန်တီးပေးရန် ဖြစ်သည် ။ သူရဲ့ အလုပ်လုပ်ပုံကတော့ Terraform လို တစ်ခါ run ပြီး ရပ်သွားတာမျိုး မဟုတ်ဘဲ၊ Kubernetes Controller တွေလိုပဲ 24/7 အမြဲတမ်း စောင့်ကြည့်နေတာပါ။ အကယ်၍ Console ကနေ manual သွားဖျက်လိုက်ရင်တောင် သူက ချက်ချင်းသိပြီး မူလအတိုင်း အလိုအလျောက် ပြန်တည်ဆောက်ပေးပါတယ်။ သို့သော် Crossplane ကို Run ဖို့အတွက် Kubernetes Cluster တစ်ခုတော့ အရင်ရှိနေဖို့ လိုအပ်ပါတယ်။
The Ultimate Combo
အိမ်တစ်လုံးဆောက်ပြီဆိုရင် foundation အရင်ချရသလိုပါပဲ။ ပထမဆုံးအနေနဲ့ Cloud Environment ရဲ့ Infrastructure တွေကိုတည်ဆောက်ပြီဆိုရင်လဲ Terraform နဲ့ တည်ဆောက်ပါမယ်။
VPC, Subnet, Route Tables တွေ ဖန်တီးမယ်။
IAM Roles တွေ၊ Security Groups တွေ သတ်မှတ်မယ်။
အရေးအကြီးဆုံးဖြစ်တဲ့ Kubernetes Cluster (EKS, GKE, or AKS) စတာတွေကို တည်ဆောက်ပါမယ်။ ဒီအဆင့်မှာတော့ Terraform ကို အသုံးပြုတာက အမြန်ဆုံးနဲ့ အစိတ်ချရဆုံး ဖြစ်ပါတယ်။
Terraform နဲ့ ဆောက်ထားတဲ့ Kubernetes Cluster လေး ရလာပြီဆိုရင်၊ အဲ့ဒီ Cluster ထဲမှာ Crossplane ကို Install လုပ်လိုက်ပါမယ်။ အဲ့ဒီအချိန်ကစပြီး ကိုယ့်ရဲ့ Application တွေအတွက် လိုအပ်တဲ့ ကျန်တဲ့ resource တွေကို Terraform နဲ့ ဆက်မဆောက်တော့ပါဘူး။
Application တစ်ခုက Database (ဥပမာ- AWS RDS) လိုချင်ရင် Crossplane ကနေတစ်ဆင့် ဆောက်ပါမယ်။
S3 Buckets တွေ၊ Message Queues (SQS) တွေ၊ Caching (ElastiCache) တွေကို Crossplane သုံးပြီး K8s YAML file လေးတွေနဲ့ပဲ request လုပ်ပါတော့မယ်။
GitOps (eg - ArgoCD, Flux) ကို အသုံးပြုတဲ့အခါ အရာအားလုံးအတွက် Single Source of Truth ကို Git Repository ထဲမှာပဲ ထားပါတယ်။ Terraform သီးသန့်ဆိုရင် App deployment က ArgoCD နဲ့သွားပြီး၊ Infrastructure က Terraform CI/CD pipeline နဲ့သွားနေတာမို့ Workflow နှစ်ခု ကွဲနေတတ်ပါတယ်။ ဒါပေမဲ့ Crossplane ကို သုံးလိုက်တဲ့အခါမှာ Database ဆောက်တဲ့ Code ရော၊ App ကို Deploy လုပ်တဲ့ Helm Chart ရော အကုန်လုံးက Kubernetes Manifest YAML တွေ ဖြစ်သွားပါတယ်။ Developer တွေက application code အသစ်ထည့်လိုက်တာနဲ့ တစ်ပြိုင်နက်၊ အဲ့ဒီ app အတွက် လိုအပ်မယ့် database အသစ်ကိုပါ git ထဲကနေ တစ်ခါတည်း commit လုပ်လိုက်လို့ ရပါတယ်။ ArgoCD က အဲ့ဒီ YAML တွေကို မြင်တာနဲ့ App ကို K8s ပေါ်မှာ Deploy လုပ်ပေးသလို၊ Crossplane ကနေတစ်ဆင့် AWS ပေါ်မှာ Database ကိုပါ အလိုအလျောက် သွားဆောက်ပေးသွားမှာပါ။ ဒါဟာ App ရော Infra ကိုပါ တစ်ပြိုင်နက်တည်း အပြောင်းအလဲလုပ်နိုင်တဲ့ True GitOps workflow ပဲဖြစ်ပါတယ်။
