Application Deployment on AWS with Infrastructure as Code: Terragrunt, Atlantis & AWX - Part 1

Infrastructure-as-Code (IaC) ကို စတင်အသုံးပြုတဲ့အခါ Terraform က လူသုံးများတဲ့ ရွေးချယ်မှုတစ်ခုဖြစ်ပါတယ်။ Project နဲ့ Infrastructure အရွယ်အစား မကြီးသေးတဲ့အချိန်မှာ Terraform တစ်ခုတည်းနဲ့ Infrastructure တွေကို ထိရောက်စွာ Manage လုပ်နိုင်ပါတယ်။

ဒါပေမယ့် Organization ကြီးလာတာနဲ့အမျှ Team members တွေ ပိုများလာပြီး၊ AWS Accounts, Environments, Projects နဲ့ Infrastructure resources တွေလည်း တဖြည်းဖြည်း များပြားလာပါတယ်။ ဒီအချိန်မှာ Terraform ကို တစ်ဦးချင်း သို့မဟုတ် Team အတွင်းမှာသာ ရိုးရိုးအသုံးပြုတဲ့ပုံစံကနေ ကျော်လွန်ပြီး Infrastructure changes တွေကို ဘယ်လို Manage မလဲ၊ Review နဲ့ Approval ကို ဘယ်လို Control လုပ်မလဲ၊ Deployment ကို ဘယ်လို Automate လုပ်မလဲ ဆိုတဲ့ ပြဿနာတွေ ပေါ်လာနိုင်ပါတယ်။

Terraform ကိုယ်တိုင်မှာ environment များစွာအတွက် code reuse ကို ကောင်းကောင်း handle လုပ်ပေးတဲ့ native mechanism မရှိပါဘူး။ VPC module တစ်ခုကို dev, staging, prod သုံးခုစလုံးမှာ သုံးမယ်ဆိုပါစို့။ terraform workspace ဆိုတာ ရှိပေမယ့် ဒါက variable value ကိုပဲ ကွဲပြားစေတာမျိုးဖြစ်ပြီး၊ backend configuration၊ provider version၊ module source version စတာတွေကို environment အလိုက် သီးခြားစီမံဖို့ မလုံလောက်ပါဘူး။ လက်တွေ့မှာ team တွေက folder သုံးခုစီကို .tf file တွေ manually copy ချထားကြတယ်။ အကယ်၍များ VPC module ထဲမှာ bug fix တစ်ခု လိုအပ်လာရင် folder သုံးခုလုံးကို လိုက်ပြင်ရတယ်။ တစ်နေရာမှာသာမေ့သွားခဲ့ရင် environment တွေအကြား config drift တွေဖြစ်လာနိုင်ပါတယ်။

နောက်ထပ် Terraform CLI ကိုယ်တိုင်မှာ production ပြောင်းမယ်ဆိုရင် approval နှစ်ဆင့်လိုမယ် ဆိုတဲ့ governance concept မပါဝင်ပါဘူး။ ဥပမာ အနေနဲ့ Engineer တစ်ယောက်က production RDS instance ကို resize လုပ်ချင်လို့ သူ့ရဲ့laptop ကနေ terraform apply ဆိုပြီး run လိုက်ရုံနဲ့ production ချက်ချင်းပြောင်းသွားနိုင်တယ်။ code review, PR approval, second-person-sign-off ဘာမှကိုမလိုအပ်ဘူး။ ဘယ်သူကတော့ ဘယ်အချိန်မှာ ဘာပြောင်းခဲ့လဲ ဆိုတဲ့ audit trail ကို မသိနိုင်ဘူး။

ဒီလိုမျိုး Scale ကြီးလာတဲ့ Environment မှာ ကြုံတွေ့ရနိုင်တဲ့ Challenges တွေကို ဖြေရှင်းဖို့အတွက် Terragrunt, Atlantis နဲ့ AWX တို့ကို သုံးရခြင်းပဲဖြစ်ပါတယ်။

Terragrunt

Terragrunt က Terraform ကို replace လုပ်တာမဟုတ်ပါဘူး။ Terraform အပေါ်မှာ orchestration layer တစ်ခုအနေနဲ့ အသုံးပြုတယ့် configuration wrapper tool တစ်ခုပဲဖြစ်ပါတယ်။ သူရဲ့အဓိက ဖြေရှင်းပေးတဲ့ ပြဿနာက code duplication ပါ။ ဥပမာအနေနဲ့ - VPC module တစ်ခုကို dev, staging, prod သုံးခုစလုံးမှာ သုံးမယ်ဆိုပါစို့။ Terragrunt မပါဘဲဆိုရင် folder သုံးခုစီမှာ Terraform code တွေ တူတူထပ်ရေးရမှာပါ။ ဒါပေမယ့် Terragrunt ကတော့ VPC module ရဲ့ actual logic ကို modules repo တစ်ခုတည်းမှာပဲ ထားလိုက်ပြီး၊ terragrunt.hcl file တစ်ခုစီက ဒီ module ကို point လုပ်ပြီး variable တွေကိုပဲ ကွဲပြားအောင် ပေးလိုက်တာပါ။ Root level terragrunt.hcl တစ်ခုမှာ S3 backend, DynamoDB lock table, provider configuration စတာတွေကို တစ်ခါတည်း define လုပ်ထားလို့ရပါတယ်။ Environment အသစ်ထပ်ချင်ရင် folder အသစ်တစ်ခုဆောက်ပြီး variable ပဲ ချိန်ရုံပါပဲ။

Atlantis

Terragrunt က code structure ကို ကောင်းအောင် စီစဉ်ပေးပေမယ့်၊ ဘယ်သူက ဘယ်အချိန် apply လုပ်လို့ရလဲ ဆိုတဲ့ ပြဿနာကို မဖြေရှင်းနိုင်သေးပါဘူး။ ဒါကို Atlantis က handle လုပ်ပေးတယ်။ example အနေနဲ့ Engineer တစ်ယောက်က production RDS instance size ကို db.t3.medium ကနေ db.r5.large ပြောင်းချင်တယ်ဆိုပါစို့။

• Git Repo ထဲကterragrunt.hcl ထဲက instance class ကို ပြောင်းပြီး Pull Request တင်မယ်။

• GitHub/GitLab webhook နဲ့ ချိတ်ဆက်ထားတဲ့ Atlantis က PR ကို auto-detect လုပ်ပြီး terraform plan ကို automatic run လုပ်ပေးတယ်။

• Plan output ကို PR comment အနေနဲ့ ပြန်တင်ပေးတယ် — DevOps or SRE က ဒီ plan ကို review လုပ်လို့ရတယ်။ Approve လုပ်လိုက်မှသာ atlantis apply ဆိုတဲ့ comment ရေးမှသာ actual apply ဖြစ်ပါတယ်။ Atlantis က state lock ကို automatic handle လုပ်ပေးလို့ engineer နှစ်ယောက် တစ်ပြိုင်တည်း run လုပ်လို့ conflict ဖြစ်စရာ မရှိတော့ဘူး။

ဒါကတော့ Terraform apply process ထဲကို code review + approval workflow + audit log ကို ထည့်ပေးလိုက်တာပါ။ Compliance အတွက်လည်း ဘယ်သူက ဘာပြောင်းခဲ့လဲ ဆိုတာကို Git history ထဲမှာပဲ တွေ့နိုင်ပါတယ်။

AWX

Terragrunt နဲ့ Atlantis ပေါင်းလိုက်ရင် infrastructure provisioning (VPC, EC2, RDS ဆောက်တာ) ကို ကောင်းကောင်းစီမံနိုင်ပါပြီ။ ဒါပေမယ့် infrastructure ဆောက်ပြီးတာနဲ့ အလုပ်မပြီးသေးပါဘူး — server တွေထဲမှာ ဆက်လက်လုပ်ဆောင်ရမယ့် operational tasks တွေ ရှိသေးတယ်။ Terraform ဆိုတာ declarative provisioning tool ဖြစ်တဲ့အတွက် ongoing config management၊ ad-hoc task execution တွေအတွက် design မလုပ်ထားပါဘူး။ ဒါကြောင့် ဒီနေရာမှာ AWX (Ansible Tower open-source version) ဝင်လာတာပါ။ Terragrunt/Atlantis က EC2 instances ၂၀ လုံးကို provision လုပ်ပြီးပြီဆိုပါစို့။ ခုနောက်ထပ် လိုအပ်တာတွေက:

• Application code deployment

• Nginx config update, SSL certificate renewal

• Security patch apply

• Database backup script run

စတာတွေကို AWX ကို web UI ကနေ Ansible playbooks တွေကို schedule/trigger လုပ်ပါတယ်။

အပေါ်မှာ tools အကြောင်းတွေကို ရှင်းပြပြီးပြီဆိုတော့ ဒီတစ်မှာ code repository structure ကိုပြောချင်ပါတယ်။ Infrastructure နဲ့ Application code အားလုံးကို Repository တစ်ခုတည်းထဲမှာ ထည့်ထားမယ့်အစား Responsibility အလိုက် Repository ခွဲထားတာ ပိုသင့်တော်ပါတယ်။ ကျွန်တော်ကတော့ ဒီမှာ iac-infra-repo, config-mgmt-repo နဲ့ app-code-repo ဆိုပြီး 3ခု ခွဲထားသင့်တယ်လို့ အကြံပေးချင်ပါတယ်။

Repository ခွဲရခြင်းရဲ့ အဓိကအကြောင်းရင်းကတော့ Separation of Concerns ကြောင့်ဖြစ်ပါတယ်။ Infrastructure changes နဲ့ Application release cycle ဟာမတူပါဘူး။ Repository သာခွဲထားရင် application release လုပ်တိုင်း Terraform pipeline ပြန် run စရာမလိုတော့ပါဘူး။ အကယ်၍များ repository တစ်ခုထဲမှာ Infrastructure + Ansible + Application အားလုံးရှိနေခဲ့ရင် accidental change တစ်ခုကြောင့် unrelated component တွေကိုပါ ထိခိုက်နိုင်ပါတယ်။ ဒါကြောင့် Infra IaC နဲ့ Ansible ကို Application code တစ်ခုနဲ့ tightly coupled မဖြစ်အောင်ထားဖို့အကြံပြုပါတယ်။ Part 1 ကို ဒီလောက်နဲ့ပဲ ခဏရပ်ထားပါမယ်။

Stay tuned for Part 2! 🚀