ဒီနေ့ Blog လေးမှာတော့ ကျွန်တော် လူသုံးများတဲ့ Deployment Method တွေနဲ့ AWS မှာရော ဘယ် Services တွေနဲ့ အသုံးချလဲဆိုတာကု ပြောပြပေးသွားမှာ ဖြစ်ပါတယ်။
အောက်ပါ Deployment Strategies တွေအကြောင်းကိုပြောပြသွားမှာ ဖြစ်ပါတယ်။
- In-Place Deployments
- Blue/Green Deployments
- Canary Deployments
- Linear Deployments
- All-at-once Deployments
(၁)။ ပထမဦးစွာ In-Place Deployments အကြောင်းကို ပြောပြပါမယ်။ ဒီ
ဖြစ်စဥ်အတွင်းမှာတော့ ကျွန်တော်တို့ရဲ့ လက်ရှိ Run နေတဲ့ server ထဲမှာပဲ update ဖြစ်တဲ့ အရာတွေကို deploy လုပ်ခြင်းပဲဖြစ်ပါတယ်။ ဆိုလိုတာကတော့ server အသစ် infra အသစ်တွေမလုပ်ပဲနဲ့ လက်ရှိရှိနေပြီးသားဖြစ်တဲ့ server မှာပဲ update လုပ်ခြင်းဖြစ်ပါတယ်။ သူရဲ့ အားနည်းချက်ကတော့ ကျွန်တော့်တို့ရဲ့ app, website တွေက downtime ရှိပါတယ်။ ဒါကြောင့်မို့ zero downtime ဖြစ်ဖို့ လိုအပ်တဲ့ infra တွေအတွက်တော့ သုံးဖို့တော့မသင့်တော်ဘူးလို့ ယူဆမိပါတယ်။ Testing server, UAT server လိုမျိုးတွေအတွက်တော့ သုံးလို့ အဆင်ပြေမယ်လို့ ထင်ပါတယ်ခဗျာ။
AWS မှာတော့ အထက်ပါ In-Place Deployment ကို AWS CodeDeploy services နဲ့ AWS Elastic Beanstalk တို့မှာ ပြုလုပ်လို့ရပါတယ်ခဗျာ၊ အထူးသဖြင့်တော့ EC2 သို့မဟုတ် on-premise server တွေမှာ ပြုလုပ်ကြပါတယ်ခဗျာ။
(၂)။ နောက်တခုကတော့ တော်တော်များများ ရင်းနီးပြီးသားဖြစ်မယ့် Blue/Green Deployments ပဲဖြစ်ပါတယ်။ ဒီ deployment ကတော့ အပေါ်မှာ ပြောခဲ့တဲ့ In-Place မှာ ရှိနေတဲ့ challenges တချို့ကို ဖြေရှင်းပေးနိုင်လာပါတယ်။
အထက်ပါပုံကို ကြည့်လိုက်ရင်တော့ နားလည်သွားမယ်လို့ထင်ပါတယ်။ Blue Environment ဆိုတာက ကျွန်တော်တို့ရဲ့ လက်ရှိ Version 1 run နေတဲ့ Environment ဖြစ်ပြီးတော့ Green env ကတော့ ကျွန်တော်တို့ update လုပ်မယ့် Version 2 ကို run မယ့် Env ပဲဖြစ်ပါတယ်။ ဆိုလိုတာကတော့ deployment စလုပ်တာနဲ့ code အသစ် Version အသစ်က အသစ်ဖြစ်တဲ့ Green env မှာသွားပြီး Deploy လုပ်ပါလိမ့်မယ် Deploy လုပ်လို့ အားလုံးပြီးဆုံးသွားပြီ application လည်းကောင်းကောင်း run နေပြီဆိုတဲ့အခါကြရင်တော့ များသော အားဖြင့် ကျွန်တော်တို့ရဲ့ Load Balancer ကနေ point လုပ်ထားတာကို Blue Env ကနေ Green Env ကို ချိန်းလိုက်တဲ့ သဘောပါပဲခဗျ။ Production env ဖြစ်တဲ့ Green Env မှာ issues ရှိလာခဲ့ရင်လည်း အလွယ်တကူ Blue Envကို rollback လုပ်လို့လဲရနိုင်ပါတယ်ခဗျာ။ တကယ်လို့နောက်ထပ် update ရှိလာခဲ့ရင်တော့ Blue Env မှာ Deploy လုပ် အစစအရာရာ အဆင်ပြေရင် လက်ရှိ နောက်ဆုံး run နေတဲ့ Green Env ကနေ Blue Env ကို ချိန်းပေးလိုက်ရုံပေါ့ဗျာ။ ဒီ strategy ကိုတော့ Blue/Green deployment လို့ ကျွန်တော်တို့ မှတ်ယူနိုင်ပါတယ်ခဗျာ။ AWS BeanStalk မှာ ဒီ deployment ကို စမ်းကြည့်လို့ရပါတယ်ခဗျာ။ နောက်အခွင့်အခါသင့်ရင် tutorial ရေးပေးပါအုံးမယ်ခဗျာ။
(၃)။ အခုထပ်မံဆွေးနွေးမှာကတော့ Canary Deployments အကြောင်းပဲဖြစ်ပါတယ်။ Canary ကတော့ အပေါ်က ပြောခဲ့တဲ့ Blue/Green လို public မလုပ်ခင် Green env ကို အပြည့်အဝ internally စမ်းသပ်စစ်ဆေးတာမျိုးတော့မဟုတ်ပါဘူး။ သူအလုပ်လုပ်ပုံကတော့ အောက်ပါပုံလေးကို တချက်ကြည့်ပေးပါ။
အပေါ်က ပုံထဲကကို အရှင်းဆုံးပြောရမယ်ဆို ကျွန်တော်တို့ရဲ့ အသစ်ဖြစ်တဲ့ version ကို live user (production users) အနည်းငယ်ကို စမ်းသပ်အသုံးပြုခိုင်းခြင်းပဲဖြစ်ပါတယ်။ တကယ်လို့ အဆင်မပြေတာတွေရှိရင်တော့ ပြန်ပြီး roll back လုပ်ပေါ့ (ဥပမာ- apple ရဲ့ developer beta program) လိုမျိုးနဲ့ ဆင်တူနိုင်မယ်ထင်ပါတယ်။ Version အသစ်ကို တကယ့်လက်တွေ့အသုံးပြုနေတဲ့ public users တွေကနေ သုံးကြည့်မယ် feedback တွေတောင်းမယ် တကယ်လို့ အားလုံးအဆင်ပြေသွားပြီဆိုရင်တော့ ကျွန်တော်တို့ရဲ့ Version အသစ်ကြီးကို server တိုင်းမှာ roll out လုပ်လိုက်မယ်ဆိုတဲ့ အနေအထားပေါ့ဗျာ။ ဒီversion အသစ်မှာပါတဲ့ feature က customer တွေကြိုက်လား မကြိုက်လား စမ်းစစ်ကြည့်တာမျိုးပေါ့။ တချို့လည်း သတိထားမိတာမျိုးတွေရှိလောက်ပါတယ် "ကျွန်တော်တို့ facebook acc မှာဆိုရင်တောင်မှာ တချို့အကောင့်မှာ dark mode ရပြီး တချို့တွေမရသေးတာမျိုးတွေဆိုရင် ဒီ deployment strategy ကိုသုံးထားတယ်လို့ ထင်မိတာပါပဲ" ။
(၄)။ နောက်ထပ်တခုကတော့ Linear Deployment ပဲဖြစ်ပါတယ်။ ဒီတခုကတော့ အပေါ်က ပြောထားတဲ့ Canary နဲ့ နည်းနည်းဆင်တူပါတယ်။ သူကလည်း production users traffic % တခုကို version အသစ်ဖြစ်တဲ့ environment ကို ပို့ဆောင်ပေးတာမျိုးပါပဲ ကွဲသွားတဲ့တချက်ကတော့ ကျွန်တော်တို့အနေနဲ့ updated env ကို တူညီတဲ့ ဆတိုး ပမာဏ ဘယ်ချိန်မှာ ဘယ်လောက် ရွေ့မယ်ဆိုတာမျိုးဖြစ်သွားပါတယ်။ မြင်အောင်ပြောမယ်ဆိုရင် user 100 ရှိတယ်ဆိုပါစို့ env အသစ်ကို ၅ မိနစ်တခါ ၁၀ရာခိုင်းနှုန်းပို့နေတာမျိုးပေါ့ ၁၀ မိနစ်ဖြစ်သွားတဲ့အခါ ၂၀ ရာခိုင်နှုန်းသော users တွေက updated env ကို ရောက်ရှိနေပြီဖြစ်တယ်ဆိုတာမျိုးပေါ့ဗျာ။ AWS Lambda မှာဒီ options တွေ အသုံးပြုကြတာ များပါတယ်။
(၅)။ နောက်ဆုံးတခုအနေနဲ့ကတော့ *All-at-once Deployments ပဲဖြစ်ပါတယ်။
ဒီတခုကတော့ ခေါင်းစဥ်လိုပဲ တကြိမ်ထဲမှာပဲ လက်ရှိ run နေတဲ့ env တွေကို updated ဖြစ်သွားအောင် တခါထဲလုပ်လိုက်တာမျိုးဖြစ်ပါတယ်။ တကယ်လို့ သာ deployment failed ဖြစ်သွားခဲ့ရင်တော့ သေချာပါတယ် ကျွန်တော်တို့ရဲ့ SLA ကတော့ တိုင်ပတ်ပြီပဲဖြစ်ပါတယ်။ တော်တော်များများမှာတော့ သိပ်မသုံးကြတဲ့ deployment တခုပဲဖြစ်ပါတယ်ခဗျာ။
ဒီနေ့ကတော့ ဒီအကြောင်းအရာတွေကို ပြောပြခဲ့ပြီးဖြစ်လို့ နောက်ထပ် Rolling update, Immutable infrastructure, Pet & Cattle အစရှိသော deployment strategy ကိုလည်းနောက်ထပ် blog post တခုမှာ ဖော်ပြနိုင်ဖို့ ကြိုးစားနေပါအုံးမယ်ခဗျာ။
သဘောကြနှစ်သက်ရင်တော့ follow, like ပြုလုပ်ပြီး share လေးပါ လုပ်ပေးလို့ပါတယ်ခဗျာ။
အမှားပါပါ က ထောက်ပြပြီး နားလည်ပေးပါခဗျာ...
လေးစားစွာဖြင့်
Kaung Thant Lwin || DevKTOps
AWS Community Builder
Myanmar
Ref: https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/deployment-strategies.html
Latest comments (3)
Thanks for your sharing! I will be waiting for next
Thanks for sharing brother!
Thanks for your sharing my bro....!