​ကိုယ့်မှာ AWS Infra တွေရှိတယ်ဆို တွေ့သမျှ metric တွေကို alarms တွေလုပ်ပြီး notification ယူမနေဘဲ တကယ် effective ဖြစ်တဲ့ metric တွေကိုမှ CloudWatch ရဲ့ alarm feature တွေနဲ့ ပေါင်းပြီး ပို့စေချင်ပါတယ်။

​ဥပမာ product တွေ ကြေညာတဲ့ website အတွက် instance တလုံးရှိတယ်ဆိုပါစို့

100 မှာ 70 ရာခိုင်နှုန်းက လွယ်လွယ်ကူကူ CMS တမျိုးမျိုး အများဆုံးက WordPress နဲ့ လုပ်ကြတာများတယ်။ ဒီတော့ site ကို ဝင်ကြည့်တဲ့သူ များလာရင် Request Count တက်မယ်၊ လွယ်လွယ်ကူကူ ပြောရရင် CPU, Memory တက်လာမယ်ပေါ့။

သတ်မှတ်ထားတဲ့ Threshold ထက် ကျော်တာနဲ့ user ကြောင့် spike တာ ဖြစ်ရင်ဖြစ်၊ မဖြစ်ရင် အိန္ဒိယက အနဲ တို့ ကလိနေပြီ.... စတာ...

​ဒီတော့ ဒီအခြေအနေတွေသိဖို့ alarms တွေ လုပ်ရပါတော့မယ်။

​Instance ကနေ CloudWatch metric ကို 5 min တစ်ကြိမ် update တွေ ပေးပါတယ်။ ဒါပေမဲ့ CPU Utilization တစ်မျိုးပဲ များများ အထောက်အကူပြုနိုင်ပါတယ်၊ ကျန်တာက တစ်ခုခုကြောင့် debug လုပ်မှသာ ဝင်ကြည့်တာများပါတယ်။ Memory နဲ့ Disk ရဲ့ metric လိုချင်ရင်လည်း Unified Agent ကနေ သွင်းယူရမှာပါ။

​ဒီတော့ ဘယ် metric တွေနဲ့ အလုပ်လုပ်သင့်လဲဆိုတာ မပြောခင် alarm ရဲ့ state ကို ခွဲထားဖို့ ပြောချင်ပါတယ်။ ဒီလိုခွဲဖို့အတွက် ကျွန်တော်ကတော့ critical နဲ့ high ဆိုတဲ့ SNS topic 2ခု AWS မှာ ကြိုဆောက်ထားလိုက်ပါတယ်။CW မှာ alarms create ရင် ဘယ် metric ကို ဘယ် topic ဆီပို့မလဲ ရွေးပေးသွားမှာပါ။

​နောက်တစ်ခုက ဒီ alarms တွေ ဖန်တီးပြီးရင်တော့ ဘယ်ကို notification ပို့မလဲ ဆိုတာပါပဲ။

​များသောအားဖြင့် email ကို ပို့ကြပါတယ်။ ကျွန်တော့်အမြင်ကတော့ ကိုယ့်ကိုယ်ကိုယ် ပြန်စိတ်ဒုက္ခမပေးသင့်ပါဘူး။

Email ကလည်း Office ကိစ္စ အရေးကြီးတဲ့နေရာ၊ မတူညီတဲ့ အဖွဲ့တွေကြားမှာ record ယူဖို့ သုံးကြတာပါ။ Infra Noti တွေကို လက်ခံဖို့ အတွက်သုံးခဲ့ရင် သေချာ manage လုပ်မထားရင် alarm email တွေနဲ့ရောပြီး တချို့ email တွေ ပျောက်သွားနိုင်ပါတယ်။

Team က Channel ကိုလည်း ပို့လို့ရပါတယ်။ ဒါပေမဲ့ Team အသံကလည်း လုံးဝကို ကင်ဆာပေးပါတယ်။ Team Channel တစ်ခုမှာ Alarm Noti တွေပါ ထပ်ထည့်ထားလို့ အသံကြားတိုင်း ကြည့်နေရရင် ဟုန်သွားပြီး တချို့အရေးကြီးတဲ့ message တွေ၊ conversation တွေ နောက်ကျသွားနိုင်ပါတယ်။

ဒီအချိန်မှာ Slack ဖြစ်ဖြစ် Discord ဖြစ်ဖြစ် သုံးသင့်တယ်လို့ မြင်ပါတယ်။ ကျွန်တော်ကတော့ Slack ကို ရွေးပါတယ်။ Setup လုပ်ရတာ လွယ်ပါတယ်။ Channel ဆောက်၊ Slack API ကနေ webhook ထုတ်ပြီး ဒီ webhook ထည့်ဖို့ Lambda function မှာ code လေး နည်းနည်းရေးပြီး trigger မှာ SNS ရွေးလိုက်ရင် Slack ကနေ message တွေကို ဖတ်နိုင်ပါပြီ။ AWS ရဲ့ message body ကို ဖတ်ရလွယ်အောင် Lambda မှာပဲ transform ဖို့ ရေးလို့ရပါတယ်။

​CW metric နဲ့ alarm ဆီ ပြန်သွားပါမယ်။

​Critical Channel ထဲ ဘာပို့မလဲ။ ကျွန်တော်ကတော့ instance အတွက်ဆို တစ်ခုပဲ ပို့ပါမယ် metric name က StatusCheckFailed ပါ။

StatusCheckFailed က instance ရဲ့ health ကို စစ်ပေးတဲ့ metric ပါ။ System Check (AWS hardware ပိုင်း) နှင့် Instance Check (OS သို့မဟုတ် Software ပိုင်း) ကိုစစ်ပေးပြီး တခု့ခု့ fail တာနဲ့ server down သွားနိုင်ပါတယ်။ CW မှာ status check fail ရင် alarm ထိပြီး instance reboot ပါ တစ်ခါတည်း ချလို့ရပါတယ်။

​နောက် ဘယ် metric တွေကို high ထဲ ပို့မလဲ။

​CPU Utilization, Memory used percent နဲ့ Disk usage တို့ကို High ထဲ ပို့ပါမယ်။ Application Load Balancer သုံးထားတယ်ဆိုရင် Request metric နဲ့ 5xx error ကိုပါ ပို့ပါမယ်။

​ဒီမှာ အဓိကပြောချင်တာက CW မှာ alarms ဘယ်လို create လုပ်မလဲဆိုတာပါ။ ပုံမှန်ဆို metric ရွေးမယ်၊ max နဲ့ တိုင်းမလား AVG နဲ့ တိုင်းမလား ရွေးမယ်။ Interval ကတော့ 5 min ပဲ ထားကြတာများတယ်၊ 1 min ထားရင်လည်း instance ဘက်က detailed monitoring ဖွင့်ပေးမှ metric တွေ 1 min တစ်ခါ ပို့နိုင်မှာဖြစ်ပြီး ဈေးကလည်း ပုံမှန်ထက်ပိုကြီးပါတယ်။ ပြီးရင် Threshold မှာ 80 လောက် ထားမယ်။ high ထဲ ပို့ပေမဲ့ 80 လောက်တော့ ထားသင့်တယ်လို့ မြင်တယ်။ ပြီးရင် SNS topic ရွေး၊ ပြီးပြီ။

​အဲ့မှာ သတိမထားမိရင် ကျော်သွားမှာရှိတယ်၊ ဘာလဲဆိုတော့ datapoint ပါ။ ဒီဟာလေးက တအား အသုံးဝင်ပါတယ်။ Default က 1 out of 1 ပါ။ ဘယ်လိုအလုပ်လုပ်လဲဆိုရင် ဥပမာအနေနဲ့ CPU Utilization ရဲ့ AVG 5 min interval အတွင်းမှာ သတ်မှတ်ထားတဲ့ Threshold ထက် တစ်ကြိမ်ကျော်ခဲ့ရင် alarm ထိပြီး Noti ပို့ပါမယ်။ ဒီ 5 min အတွင်း 1 ကြိမ်၊ အလွယ်ပြောရရင် 1 min သာ CPU တက်ပြီး ပြန်ကျသွားလည်း Noti ပို့မှာပါ။ ပြောရရင် မလိုအပ်ပါဘူး၊ False positive alarm လို့တောင် ပြောလို့ရပါတယ်။

ဒီလိုမျိုး မဖြစ်စေချင်ဘူးဆိုရင် 3 out of 3 ထားလို့ရပါတယ်။ 5min တိုင်းမှာ 1 ကြိမ်စစ်တာ 3 ကြိမ်လုံး ( စု့စု့ပေါင်း 15 min ) Threshold ထက် ကျော်နေမှ ပို့မှာပါ။ Noise တော်တော် လျော့သွားမှာပါ။ ဒီ data point ကစားတာက CPU Utilization နဲ့ Memory used percent အတွက်ပါ။ ကျန်တဲ့ဟာတွေ မလိုပါဘူး default ထားလို့ရပါတယ်။

​အကယ်၍ AWS Auto Scaling Group သုံးခဲ့ရင် CPU ရော Memory ရော alarm မယူတော့သင့်ပါဘူး။ ASG မှာ Unified Agent ထည့်ထားတာကလည်း CW မှာ metric တွေကို များ‌လာစေပြီး မျက်စိနောက်ပါတယ်။

များသောအားဖြင့် API server တွေ ဖြစ်နိုင်တဲ့အတွက် Open source tools တမျိုးမျိုးနဲ့ဖြစ်စေ New relic ဖြစ်စေ ထည့်တာက ပိုအဆင်ပြေပါလိမ့်မယ်။ ASG မှာလည်း Scaling policy တစ်မျိုးမျိုး ရှိနေမှာဖြစ်တဲ့အတွက် သတ်မှတ်ထားတဲ့ Threshold ဆိုရင် scale မှာပါ။ Metric တစ်မျိုးကိုပဲ ထပ်တိုးပြီး Critical Channel ထဲ ထည့်ထားသင့်ပါတယ်။ အဲ့ဒါကတော့ UnhealthyHostCount ပါ။ Application Load Balancer နဲ့ တွဲထားတဲ့ Target Group ကနေ ယူရမှာပါ။ ဒီ metric ကြောင့် ASG ထဲက instance လစ်သွားရင် သိပါလိမ့်မယ်။

RDS ကတော့ နည်းနည်း ပိုလုပ်ရပါမယ်။ Critical ထဲထည့်မှာပါ DB ဖြစ်တဲ့အတွက်။Critical Channel ထဲ ထည့်ဖို့အတွက် သေချာလေး စဉ်းစားပြီး ရေးပါမယ်။ ပုံမှန် CPU Utilization ရှိပါမယ်၊ သူက ၁ မိနစ် တစ်ခါ metric update ပါတယ်။ ဒီတော့ interval ကို 1 min ထားပြီး datapoint ကိုတော့ အနည်းဆုံး 10 out of 10 ထားသင့်ပါတယ်။ ဒါတောင် user spike ရှိရင် ခဏခဏ တံခါးလာခေါက်နေမှာပါ။ ဒီတော့ Read Latency နဲ့ Write Latency လေးပါ alarm လုပ်၊ ဒါကို CW ရဲ့ Composite Alarm နဲ့ ဒီ metric တွေကို ပြန်အုပ်ကာ Noti ယူသင့်ပါတယ်။ Aurora Serverless ဆိုရင် ACU Utilization လေးကိုပါ 10 out of 10 datapoint အနည်းဆုံးလေးနဲ့ ထားသင့်ပါတယ်။

​ဒါကတော့ Alarm Noti တွေရဲ့ နှိပ်စက်မှုကနေ ဝေးအောင် လက်ရှိ သုံးကြည့်နေတာလေးပါ။

အပိုင်း (၁) Site-to-site VPN အကြောင်းကို လေ့လာချင်ရင်တော့ အောက်ပါ link မှာ လေ့လာနိုင်ပါတယ်။

https://kalaung.org/how-to-connect-on-premises-network-and-cloud-aws-part-1

Direct connect

• Direct connect ဆိုတာ ကိုယ့်ရဲ့ data center (on-prem) network နဲ့ AWS ကို သီးသန့်ချိတ်ဆက်ထား တဲ့ private connection တစ်ခုဘဲ ဖြစ်ပါတယ်။

Physical Connection

Direct connect ချိတ်ဆက်မယ်ဆိုရင် အရင် ဆုံး ကိုယ့်ရဲ့ on-prem network နဲ့ Direct connect location ကို physical connection ရှိရပါမည်။ Direct connect location ဆိုတာ AWS direct connect router ရှိတဲ့ ‌ နေရာတစ်ခုဖြစ် သလို customer/partner ဘက်က router ရှိတဲ့ နေရာလည်း ဖြစ်ပါတယ်။ AWS direct connect router နဲ့ customer/partner ရဲ့ router ကို cross-connect ချိတ် ထား တဲ့နေရာ လည်းဖြစ်ပါသည်။ Direct connect location မှာ ကိုယ် ကိုယ်တိုင် router မထားနိုင်ဘူးဆိုရင် Direct connect location နဲ့ physical connection ရှိထားပြီးသားဖြစ်တဲ့ AWS Direct connect Partner မှ တ ဆင့် connect လုပ်လို့ရပါတယ်။ Direct Connect Partner မှ တစ်ဆင့်မသွားဘူးဆိုရင် Direct connect location နဲ့ physical connection ရဖို့ colocation facility provider ကို ဆက်သွယ်ပြီး ‌ဆောင််ရွက် ရ မှာ ဖြစ်ပါတယ်။

Direct Connect location နဲ့ physical connection ရဖို့ကို နည်း (၂) နည်း ဖြင့် ချိတ်ဆက်နိုင်ပါသည်။

• Dedicated connections

• Hosted connections

Dedicated connections

Dedicated connections ဆိုတာ physical connection တစ်ခုကို single customer နဲ့ဘဲ သီးသန့်ချိတ်ဆက်ထားတာ ဖြစ်ပါတယ်။ Dedicated connections create လုပ်ရန် ‌‌အောက်ပါ steps များအတိုင်းပြုလုပ်ရပါမည်။

1. Decide on an AWS Direct Connect location and connection size

2. Create your connection request(s) on the AWS management console

3. Download Letter of Authorization (LoA) from the AWS Management console

4. Provide LoA to an APN Partner and ask them to establish the connection on your behalf

5. Configure virtual interfaces to establish network connectivity

You can check the following link details of Direct Connect location , Associated AWS Region and available speed

https://aws.amazon.com/directconnect/locations/

Port speed ကို 1, 10, or 100 Gbps and 400 Gbps ထိ‌ရွေးချယ်နိုင်ပါတယ်။ Direct connect location မတူလျှင် support လုပ်တဲ့ port speeds ‌တွေ မတူညီနိုင်ပါ။

Direct connect location, port speed ‌တွေရွေးချယ် သတ်မှတ်ပြီးပြီ ဆိုလျှင် AWS management console မှာ connection request create လုပ်လို့ရပါပြီ။ Connection request create လုပ်တဲ့အချိန်မှာ AWS direct connect partner တဆင့် connect လုပ်မှာလား/မလုပ်ဘူးလား ဆိုပြီး ‌ရွေးချယ်‌ပေး ရတဲ့ check box ‌ လေးတွေ့ရ ပါလိမ့်မည်။

Check box လေး မှာ tick လုပ်ခဲ့ရင် AWS Direct connect partner မှတဆင့် AWS Direct connect location နဲ့ ကိုယ့်ရဲ့ Data Center ကို Physical connection ရအောင် ဆောင်ရွက်မှာ ဆိုတဲ့ အဓိပ္ပါတယ် ဖြစ်ပါတယ်။ Connection request create လုပ်ပြီးတဲ့ နောက် မှာ AWS က review လုပ် ပြီး 72 business hours အတွင်း မှာ Letter of Authorization - Connecting Facility Assignment (LOA-CFA) ကို provides လုပ်ပေးပါတယ်။ LOA-CFA ကို download လုပ်ပြီး ကိုယ့် ရဲ့ AWS Direct connect partner ဆီကို ပို့ပေးရပါမည်။ Partner က Physical connection ရဖို့ ဆက်လက်ဆောင်ရွက်သွားပါလိမ့်မည်။

Check box လေး မှာ tick မလုပ်ခဲ့ဘူးဆိုရင် AWS Direct connect location နဲ့ ကိုယ့်ရဲ့ Data Center ကို Physical connection ရဖို့ ကို third-party service provider မပါဘဲ AWS ကို direct request လုပ်လိုက်တာဖြစ်ပါတယ်။

Connection request create လုပ်ပြီးတဲ့ နောက် မှာ AWS ဘက်က LOA-CFA ကို provides လုပ်ပေးပါတယ်။ LOA-CFA ကို colocation facility provider ဆီကို ပို့ပေး ပြီး Physical connection ရဖို့ ဆက်လက်ဆောင်ရွက်ရပါမယ်။ AWS Direct Connect endpoint ရှိတဲ့ Data center မှာ ဘဲ ကိုယ့်ရဲ့ physical network equipment တေ ရှိထားပြီးသား သူတွေ အတွက် ပိုသင့်တော်ပါတယ်။ Direct connect partner မှ တဆင့်သွားတာနဲ့ ယှဉ်ရင် cost ပိုကုန်ပါတယ်။

Hosted connections

Hosted connections ဆိုတာ Physical port (1) ခုကို logical port ‌တွေ ခွဲပြီး သုံးရတာဘဲဖြစ်ပါတယ်။ Physical port သည် Partner နဲ့ဘဲ သက်ဆိုင်ပါတယ်။ Customer ‌တွေက logical port နဲ့ဘဲ သက်ဆိုင်တာဖြစ်ပါတယ်။ Hosted connections create လုပ်မယ်ဆိုရင် AWS management console ကနေ ကိုယ်တိုင် create လုပ်ရတာ မဟုတ်ပါဘူး။ AWS Direct connect delivery partner ကို အရင်ဆက်သွယ်ရပါမည်။ AWS Direct connect delivery partner က connection ကို create လုပ်ပေးတာပါ။ Partner က create လုပ်ပြီးလျှင် Direct connect console> Connections Pane မှာ ‌ပေါ်လာမှာ ဖြစ်ပါတယ်။ အဲ့တာကို accept လုပ်ပေးရမှာပါ။ Port speeds အနေနဲ့ 50 Mbps up to 25 Gbps ထိ ရပါတယ်။

အခုပြောခဲ့တာတွေကတော့ Physical connection ရဖို့ အပိုင်းဖြစ်ပါတယ်။ Physical connection ရသွားပြီ ဆိုရင်‌ ‌တော့ virtual interfaces ‌တွေအကြောင်း ဆက် ‌ပြောပါမယ်။

Virtual Interfaces (VIF)

Physical Connection တွေ ရသွားပြီ ဆိုရင်တော့ နောက်တဆင့် က Virtual Interfaces (VIF) တွေ create လုပ်ဖို့ ဖြစ်ပါတယ်။ Virtual interfaces (VIF) 3 မျိုး ရှိပါတယ်။

1. Private VIF

2. Public VIF

3. Transit VIF

Private VIF - Private IP address ကို အသုံးပြုပြီး single VPC နဲ့ connect လုပ်ဖို့ အသုံးပြုပါတယ်။

Public VIF - Public IP address ကို အသုံးပြုပြီး AWS public services (like S3, DynamoDB) တွေ ကို access လုပ်ဖို့ သုံးပါတယ်။

Transit VIF - VPC တွေ တစ်ခုထက် မက များလာပြီဆိုရင် Transit Gateway ကို သုံးပေးရပါမယ်။ အဲ့ဒီ Transit Gateway ကို connect လုပ်ဖို့ အတွက် create လုပ်ပေးရတဲ့ virtual interface သည် Transit VIF ဖြစ်ပါတယ်။

Photo reference from : AWS Documentation

1. Site-to-Site VPN (Virtual Private Network)

2. Direct connect

Site-to-Site VPN

- On-prem network နဲ့ AWS resources တွေ ချိတ်ဆက်တဲ့ အခါမှာ VPN ကို သုံးပြီး ချိတ်ဆက် တယ်ဆိုတာ on-prem network နဲ့ ‌AWS VPC ကို internet ပေါ်က နေ tunnel ထိုးပြီးချိတ်ဆက်တာဖြစ်ပါတယ်။ (Site-to-Site VPN လို့လည်း ‌‌ခေါ်ပါတယ်။)

- Routing အနေနဲ့ Static route or Dynamic route (BGP) ကို သုံးပါတယ်။

- VPN connections တစ်ခု create လုပ်တာနဲ့ AWS ဘက်ကနေ tunnel 2 ခု support လုပ်ပါတယ်။ Redundancy ရဖို့ အတွက်ဖြစ်ပါတယ်။ Tunnel တစ်ခုက active အနေနဲ့ အလုပ်လုပ်နေရင် ကျန် tunnel တစ်ခုက standby အနေနဲ့ အလုပ်လုပ်ပါတယ်။

- Maximum bandwidth အနေနဲ့ tunnel တစ် ခုကို 1.25 Gbps support လုပ်ပါတယ် ။ Tunnel 2 ခု ကို auto ‌‌‌ပေါင်းပြီး double speed ဖြစ်သွားမလားဆိုရင် မဖြစ်သွားပါဘူး။ ဘာလို့လဲဆိုရင် tunnel တစ်ခုက active အနေ နဲ့ အလုပ်လုပ်‌နေချိန်မှာ ‌နောက် tunnel တစ်ခုက standby အနေနဲ့ဘဲ ရှိနေလို့ ဖြစ်ပါတယ်။ ECMP (Equal-Cost Multi-Path) ကို သုံးမယ်ဆိုရင်‌ ‌‌တော့ tunnel 2 ခုလုံးက တပြိုင်နက်တည်း active ဖြစ်နိုင်ပါတယ်

- ECMP ကို သုံးဖို့ဆိုရင် VPN connection သည် TGW ကို atttached လုပ်ထားတာဖြစ်ရပါမည်။ Dynamic routing (BGP) ကို သုံးရပါမည်။ On-prem router သည် လည်း ECMP ကို support လုပ်ရပါမည်။

VPN Endpoint

- AWS ဘက် မှာ VPC တစ်ခုတည်းနဲ့ ချိတ်ဆက်မယ်ဆိုရင် VGW (Virtual private Gateway) create လုပ်ပေးရပါမယ်။ VPC အရေအတွက် များလာတာနဲ့ VGW အရေအတွက် ‌တွေလည်း များလာမှာပါ။

- တစ်ခုထက်မက ပို များတဲ့ VPC တွေ နဲ့ ချိတ်မယ်ဆိုရင် TGW (Transit Gateway) ကို create လုပ်ပေး သင့် ပါတယ်။ TGW သုံးတဲ့ VPN connections မှာဆိုရင် Tunnel bandwidth ကို standard (or) large ရွေးချယ်လို့ရပါတယ်။ Standard သည် 1.25 Gbps ကို support လုပ်ပြီး Large သည် 5Gbps ကို support လုပ်ပါတယ်။

Customer Gateway device and Customer Gateway

Site-to-site VPN ကို ‌လေ့လာတဲ့ အခါမှာ confuse ဖြစ်တတ်တဲ့ အသုံး အနှုန်းလေးဖြစ်ပါတယ်။

- Customer Gateway device ဆိုတာ VPN connection အတွက် on-prem ဘက် မှာ ရှိ ရမယ့် physical device ဖြစ်ပါတယ်။

- Customer Gateway ဆိုတာ ကိုယ့်ရဲ့ on-prem device (customer gateway device) ရဲ့ infomation ‌တွေကို AWS ဘက် က သိအောင် ပြောပြပေးရတဲ့ နေရာ ဖြစ်ပါတယ်။

- Customer Gateway create လုပ်တဲ့ အချိန်မှာ ဖြည့်ပေးရတဲ့ infomation ‌‌တွေက ဘာတွေလဲဆိုရင် on-prem device ရဲ့ Public IP, ASN, .. အစရှိတာတို့ ဖြစ်ပါတယ်။

ဒီလောက်ဆိုရင် ‌တော့ AWS ရဲ့ site-to-site VPN အ ကြောင်းလေးအခြေခံလောက် သိသွားမယ်ထင်ပါတယ်။

Part -2 မှာ Direct connect အကြောင်းလေး ထပ် ဆွေးနွေးသွားမှာ ဖြစ်ပါတယ်။ Direct Connect အကြောင်း အောက်ပါ link မှာ ဝင်ရောက် လေ့လာနိုင်ပါတယ်။

https://kalaung.org/how-to-connect-on-premises-network-and-cloud-aws-part-2

Accessiblity လို့ပြောရင် topic ကအကျယ်ကြီးလို့ပြောရမယ်။ အဲ့ထဲမှာမှ Web Engineer တွေ Frontend သမားတွေအနေနဲ့ လုပ်ရမယ့်အပိုင်းတွေက တော်တော်ကိုများတယ်။ Designer ဆီက Design တင်မက တခြားသော accessibility နဲ့ပတ်သတ်တဲ့ techniques တွေကို apply လုပ်ပေးရတယ်။ ဒါမှ disabled person တွေအတွက် User Experience ကောင်းစေမှာပါ။ Desiger တွေအတွက်ကတော့ Design နဲ့ပတ်သတ်တဲ့ Accessibility techniques တွေကို လေ့လာထားရင်ကို လုံလောက်ပါပြီ။

Accessibility ဆိုတာဘာလဲလို့ပြောရင်တော့ ရုပ်ပိုင်း/စိတ်ပိုင်းဆိုင်ရာ ချို့ယွင်းနေတဲ့လူတွေ (Disabled People) တွေအနေနဲ့ သာမန်လူတွေကဲ့သို့ နားလည်အသုံးပြုလုပ်ဆောင်နိုင်တာလို့ပြောရမယ်။ ဒီနေရာမှာ technology ပိုင်းမဟုတ်ပဲ အပြင် society မှာဆိုရင် လမ်းမလျှောက်နိုင်တဲ့သူက wheel chair သုံးပြီး သာမန်လူတွေလို သွားလာနိုင်တာမျိုးပေ့ါ။​ ထိုင်းက ရထားဘူတာတွေမှာဆို wheel chair person တွေအတွက် ရထားဝန်ထမ်းကနေ ဓာတ်လှေကားနဲ့ လာခေါ်တာ ပြီးရင် wheel chair အတွက် နေရာသီးသန့်ထားပေးထားတာမျိုးထိ Accessbility နဲ့ပတ်သတ်ပြီး လုပ်ဆောင်ပေးထားတယ်။​ ထိုနည်းတူ နည်းပညာပိုင်းမှာဆိုရင်လည်း ကိုယ့်ရဲ့ software ကို သူတို့တွေအတွက် သာမန်လူတွေကဲ့သို့ သုံးစွဲနိုင်အောင် လုပ်ပေးဖို့လိုပါတယ်။ ဒါ့အတွက် WCAG ကနေ Perceivable, Operable, Understandable, Robust ဆိုတဲ့ POUR Principles ထုတ်ပြီး standard guidlines တွေချပေးထားပါတယ်။

Accessibility နဲ့ပတ်သတ်ပြီးပြောရင် Conformance နဲ့ Compliance အကြောင်းကထည့်ပြောရတယ်။​ သူ့မှာ Conformance အတွက် level သုံးခုရှိတယ်။

- A (lowest, minimum level)
- AA (recommended, minimum legal requirement)
- AAA (highest)

ဒီ level 3 ခုကို Engineer တွေက ဆိုင်ရာ Compliance ပေါ်မူတည်ပြီး လုပ်ဆောင်ပေးရတယ်။​လက်ရှိလုပ်ဖူးသမျှ အတွေ့အကြုံအထိတော့ ASIA ဘက်မှာ Accessibility နဲ့ပတ်သတ်ပြီး Government ဘက်ကနေ enforce လုပ်ထားတာတော့မတွေ့ဖူးသေးဘူး (ကိုယ်တိုင်လည်းမကြုံသေးတာဖြစ်နိုင်ပါတယ်)။​ ဒါပေမယ့် အနောက်နိုင်ငံတွေဖြစ်တဲ့ UK, US စတဲ့နိုင်ငံတွေမှာတော့ Government ကနေကို Disability Act (ADA) လိုမျိုး Law တွေထုတ်ပြီး Enforce လုပ်ထားတယ်။​ သူတို့နိုင်ငံတွေမှာ software တစ်ခုရေးမယ်ဆို Accessibility အတွက် Conformance level AA ကို minimun requirement အနေနဲ့သတ်မှတ်ထားတယ်။​တကယ်လို့ ကိုယ့် App က minimun requirement ကိုမမှီဘူးဆိုရင် တရားစွဲခံရနိုင်တယ်။ ဒီတော့ Designer တွေအနေ့နဲ့ ကိုယ့် ဆွဲပေးရမယ့် client က Accessbility နဲ့ပတ်သတ်ပြီးပြောလာရင် ဘာတွေလိုက်နာရမလဲ သိအောင် လေ့လာထားသင့်ပါတယ်။ Standards အနေနဲ့ WCAG ဘက်ကထုတ်တာတဲ့ Guidelines တွေလိုက်နာပေးရင်ရပါတယ်။ အကြမ်းအားဖြင့်ဆိုရင်

1. Color Contrast

Designer တွေအနေနဲ့ Design စပြီးဆွဲရတော့မယ်ဆို color palette ကို အရင်စဥ်းစားကြတယ်။​အဲ့အချိန်မှာ ကိုယ်ရဲ့ palette က color တွေက contrst မှန်ဖို့လိုတယ်။​ Color theory ပိုင်းကတော့ Designer တွေက ပိုသိမှာပါ။ ဥပမာ background/foreground color, button တွေ input တွေရဲ့ different state colors စတဲ့ color တွေ၊ ​နောက်တစ်ခုက light/dark theme switch လို့ရတာမျိုးဆိုရင်လည်း နှစ်ခုလုံးအတွက် color system ကို သေချာလည်းရွေးထားရမယ်။ AA requirement အရကတော့ဒီလိုရှိမယ်။​ font size 24px နဲ့ အောက်ဆို contrast ratio က at least 4.5:1, 24 px ရဲ့ အထက်ဆို contrast ratio က at least 3:1 ဖြစ်မယ်။ Non-text content တွေအတွက်ဆိုလည်း 3:1 ဖြစ်မယ်။ ကိုယ်တိုင်က Engineer မလို့ အသေးစိတ်ကိုတော့ research လုပ်ကြည့်ဖို့ တိုက်တွန်းပါတယ်။

2. Layout

နောက်တစ်ခုက screen layout design နဲ့ information architecture ပါ။​သူက သာမန်လူတွေအတွက်တင်မက screen reader, keyboard navigation or swtich device သုံးတဲ့ user တွေအတွက်အရမ်းအရေးကြီးတယ်။​လိုအပ်တဲ့ information ကိုအလွယ်တကူ ရနိုင်လား၊ action တစ်ခု လုပ်နိုင်ဖို့ menu/button/breadcrumbs စတာတွေဆီ focus ရောက်အောင် tab navigation နဲ့ ဘယ်နှချက်နှိပ်ရလဲ၊ content hierarchy ကရော headings, lists တွေက scannable ဖြစ်နိုင်လား စသည်ဖြင့် layout ချတာကိုလည်း သူတို့အတွက်ပါ စဥ်းစားပေးနိုင်ရင် ပိုကောင်းတယ်။​နောက်ဆုံး responsive layout ကို support လုပ်တာထိပါတယ်။ မဟုတ်ရင် mobile/desktop only user တွေအတွက်ကတော်တော်အခက်အခဲရှိနိုင်တယ်။

3. Animation

Website မှာပါတဲ့ Motion တွေ animation တွေကလည်း accessibility မှာစဥ်းစားစရာ topic တစ်ခုပါပဲ။​သာမန်user တွေအတွက်တောင် animation ကိုသေချာမလုပ်ထားတာနဲ့ လုပ်တာပေါ်မူတည်ပြီး user experience ကောင်းမကောင်း အလွယ်တကူသိနိုင်တယ်။ element level animation (focus/hover state), component level animation (popup/menu transition) တွေအပြင် page level animation တွေဖြစ်တဲ့ Parallax နဲ့ scroll-based effects တွေအထိ smooth ဖြစ်အောင်လုပ်ထားသင့်တယ်။​ ဒါပေမယ့် screen reader သမားတွေအတွက်ကြ တစ်ခုခုလုပ်ရင် instant feedback ရဖို့အဓိကဖြစ်တဲ့အတွက်​ prefers-reduced-motion ဆိုတာကို device settings မှာ on ထားကြတယ်။​ ဆိုတော့ website ထဲက animation တွေက အသုံးမဝင်တော့တဲ့အတွက် animation မပါပဲ navigation လုပ်နိုင်အောင် page loading ဖြစ်နေတယ်ဆိုလည်း screen readers တွေသိအောင် စတာတွေအတွက် alternative solution တွေစဥ်းစားပေးနိုင်လေ ပိုကောင်းလေလို့ပြောလို့ရပါတယ်။

Tools တွေအနေနဲ့ဆိုရင် Axe DevTools, Lighthouse, WebAIM Contrast Checker တွေအပြင် Figma plugin တွေလည်းရှိပါတယ်။ တခြား Design နဲ့မဆိုင်တဲ့ topic တွေနဲ့ ပိုပြီးအသေးစိတ်တဲ့ WCAG, WebAIM အပိုင်းတွေတော့ချန်ထားခဲ့ပါတယ်။ အရမ်းရှည်သွားမှာဆိုးလို့ပါ။

အခုချိန်ထိတော့ Accessibility နဲ့ပတ်သတ်ရင် legal requirement အရ မဖြစ်မနေလုပ်ဖို့လိုမှသာလျှင် business ဘက်က attention ပေးတာမျိုးပဲ တွေ့နေရပါသေးတယ်။ FAANG လို company ကြီးတွေမှာတော့ accessibility specialist တွေခန့်ထားပြီး dedicated team တစ်ခုအနေနဲ့ရှိတာတွေ့ရပါတယ်။ ဒါပေမယ့် ကိုယ့်အနေနဲ့ compliance ကြောင့်သာမက disabled people တွေအတွက် empathy ထားပြီး စဥ်းစားပေးမယ်ဆိုရင် ကိုယ်လုပ်လိုက်တဲ့ သေးငယ်တဲ့အရာလေးတစ်ခုက သူတို့အတွက် အထောက်အကူအများကြီးဖြစ်သွားစေမှာပါ။​ ဒီစာလေးဖတ်ပြီးသွားလို့ နောက်ပိုင်း Design တွေဆွဲတဲ့အခါ Accessbility နဲ့ပတ်သတ်ပြီးထည့်စဥ်းစားမိလာတယ်ဆိုရင် awareness ရှိလာတယ်လို့ ပြောရမှာပါ။​ ဒီလောက်ဆို Accessibilty နဲ့ပတ်သတ်တဲ့ မီးပွားလေးထွန်းညှိပေးနိုင်မယ်လို့ မျှော်လင့်မိပါတယ်။

VPC Endpoint ဆိုတာ VPC နဲ့ AWS services တွေ ကို public Internet ကို အသုံးမပြုဘဲနဲ့ Privately connect လုပ်ပေးတာ ဖြစ်ပါတယ်။ Internet Gateway, NAT Gateway နဲ့ Public IP တွေ မလိုအပ်ဘဲနဲ့ VPC နဲ့ AWS services တွေကို privately connect လုပ်နိုင်မှာဖြစ်ပါတယ်။ AWS backbone network ကို အသုံးပြုတာ ဖြစ်လို့ security and performance ပိုကောင်းမှာ ဖြစ်ပါတယ်။

ဥပမာ အနေနဲ့ - Private subnets ထဲမှာ ရှိနေတဲ့ EC2 instance သည် AWS service တစ်ခုဖြစ်တဲ့ S3 or Secrets Manager တစ်ခုခု ကို Access လုပ်ဖို့ လိုအပ်တဲ့ အခါမှာ ဆိုရင် ပုံမှန်အားဖြင့် NAT gateway ကို ဖြတ် ပြီး Public Internet ပေါ်ကသွားရပါတယ်။ NAT ကို အ သုံး ပြုရတာ ဖြစ်လို့ cost တွေရှိမယ်။ Public Internet

ပေါ်က ဖြတ်သွားရတာဖြစ်လို့ security ပိုင်း အားနည်းမယ်။ ဒီနေရာမှာ VPC Endpoint ကို သာ အ သုံးပြုလိုက်မယ်ဆိုရင် VPC နဲ့ AWS services ‌တွေကို public internet ကို အ သုံးပြုစရာမလို ‌တော့ဘဲ privately connect လုပ်နိုင်မှာ ဖြစ်ပါတယ်။

VPC Endpoint 2 မျိုးရှိပါတယ်။

1. Interface Endpoint (PrivateLink)

2. Gateway Endpoint

Interface Endpoint (PrivateLink)

AWS services တော်တော်များများ နဲ့ connect လုပ်ဖို့ ဆိုရင် Interface Endpoint ကို အသုံးပြုပါတယ်။

e.g

• Secrets Manager

• CloudWatch

• SSM

• KMS

• SNS, etc.

Interface Endpoint သည် PrivateLink ကို အသုံးပြုပါသည်။ PrivateLink ဆိုတာ AWS backbone network ပေါ် မှာ built လုပ်ထားတဲ့ service တစ်ခုဖြစ်ပါတယ်။ Interface Endpoint ကို အသုံးပြုတဲ့ အခါမှာ AWS သည် Elastic Network Interface (ENI) တစ်ခု auto create လုပ်လိုက်ပါတယ်။ ENI ကို private subnet or public subnet တစ်ခုခုထဲ မှာ create လုပ်ဖို့ ရွေးချယ်လို့ ရပါတယ်။ အများအားဖြင့် private subnets ထဲ မှာ create လုပ်ကြပါတယ်။ အဲ့ ENI မှတစ်ဆင့် privatelink ကို အသုံးပြုပြီး VPC နဲ့ AWS serivces တို့ connect လုပ်ကြပါတယ်။

Gateway Endpoint

Supports only two services:

• Amazon S3

• DynamoDB

  Gateway Endpoint ကို create လုပ်လိုက်တဲ့ အခါမှာ ကိုယ် ‌ သတ်မှတ်ထားတဲ့ VPC ရဲ့ Route table ထဲမှာ route တစ်ကြောင်း auto create ပြီးသား ဖြစ်သွားပါတယ်။

  နမူနာအနေနဲ့ Private subnets ထဲမှာ ရှိတဲ့ EC2 instance က S3 ကို Gateway Endpoint ကနေတဆင့် ဘယ်လို connect လုပ်လဲဆိုတာကို ပြောပြပေးသွားပါ့မယ်။

  Private Subnet ထဲ မှာ ရှိတဲ့ EC2 instance မှာ အောက်ပါ command ‌run လိုက်ပါမယ်။

    aws s3 ls s3://mybucket
  

  DNS resolves လုပ် ပြီး route table မှာ check လုပ်ပါတယ်။ route table ထဲမှာ အောက်ပါအတိုင်း ‌တွေ့ ရပါမယ်။

    Destination: pl-xxxxxx (S3 Prefix List)
    Target: vpce-xxxxxx (Gateway Endpoint)
  

  S3 ကို သွားဖို့ အတွက် Gateway endpoint ကနေတဆင့် သွားရမယ်ဆိုတာကို သိသွားပါတယ်။ EC2 ကနေ S3 ကို connect လုပ်ဖို့အတွက် public internet ကို ဖြတ်သွားစရာမလိုတော့ဘဲနဲ့ Gateway endpoint ကနေ တဆင့် AWS Backbone network ‌‌ပေါ်ကနေ privately connect လုပ်လို့ရသွားပါပြီ။

  ဒီလောက်ဆိုရင်တော့ VPC endpoint အ ကြောင်း လေး သိလောက်ပြီ ထင်ပါတယ်။ လိုအပ်တာများ ရှိခဲ့ ရင်လည်း comment မှာ ဝင်ရောက်ဆွေးနွေးလို့ ရပါတယ်။

• Transit Gateway Peering ဆိုတာ Transit Gateway အချင်းချင်း ချိတ်ဆက်တာ ဖြစ်ပါတယ်။

• Transit Gateway သည် Regional Resource ဖြစ်တဲ့ အတွက် Region မတူရင် share သုံးလို့ မရပါဘူး။

Transit Gateway peering use case 1 (Same Account, Different Region)

• ပုံမှာ ပြထားသလို Same Account but different regions အသီးသီး မှာ ရှိတဲ့ VPC ‌‌‌တွေ အချင်းချင်း ချိတ်ဆက်ဖို့ လိုလာပြီ ၊ အဲ့ VPC ‌ ‌တွေက လည််း သက်ဆိုင်ရာ TGW ကို ချိတ်ဆက်ထားကြမယ်ဆိုရင် အဲ့ VPC အချင်းချင်း ချိတ်ဆက်ရဖို့ အတွက် TGW peering ကို သုံးလို့ ရပါတယ်။

• Transit Gateway peering သည် Non Transitive ဖြစ် ပါတယ်။

  (TGW A - TGW B)

  (TGW B - TGW C) အဲ့ လိုချိတ်ထားမယ်ဆိုရင်‌ TGW A and TGW C က connection ရှိမှာ မဟုတ်ပါဘူး။

  TGW A and TGW C connection ရချင်ရင် A and C ကို peering လုပ်ပေးရမှာပါ။

  TGW peering သည်လည်း AWS Backbone network ကို အ သုံးပြုတာဖြစ်ပါတယ်။

Transit Gateway Peering Use Case 2 ( Different Account, Different Region)

ဒီလောက်ဆိုရင်တော့ Transit Gateway peering နဲ့ ပတ်သတ်ပြီး မျက်စိထဲ မြင်သွားမယ် ထင်ပါတယ်။ လိုအပ်တာများ ရှိရင်လည်း comment မှာ ဝင်ရောက်ဆွေးနွေးလို့ ရပါတယ်ရှင့်။

VPC တွေ တစ်ခုထက် မက များလာပြီ၊ VPC အချင်းချင်း connect လုပ်ဖို့ လည်း လိုအပ်လာပြီဆို ရင် VPC peering or Transit Gateway တစ်ခုမဟုတ်တစ်ခု သုံးပေးရပါမယ်။ VPC peering အကြောင်း အရင်ပြောပါ့မယ်။

VPC Peering

Account 1 ခု ၊ Same Region ထဲမှာ VPC 3 ခု ရှိတယ် ဆိုကြပါစို့ ။

VPC A, VPC B and VPC C (as shown in figure)

• ပုံမှာ ပြထားသလို VPC-A and VPC-B ကြားမှာ Peering connection တစ်ခု,VPC-B and VPC-C ကြားမှာ Peering connection တစ်ခု create လုပ်လိုက်မယ်ဆိုရင် VPC-A and VPC-B , VPC-B and VPC-C ဘဲ ချိတ်လို့ ရမှာ ပါ။

• VPC-A and VPC-C ချိတ်လို့ ရမှာ မဟုတ်ပါဘူး ။ VPC-A and VPC-C ချိတ်ချင်ရင် A and C ကြားမှာ လည်း peering connection တစ်ခု create လုပ်ပေးရမှာပါ။ အခုလို အခြေအနေ Non-transitive လို့ ‌ခေါ်ပါတယ်။ အဲ့တော့ VPC ‌တွေများ လာမယ်ဆိုရင် Peering connection ‌တွေလည်း များလာမှာ ပါ။

• VPC peering သည် AWS Backbone network ကို အ သုံးပြုတာဖြစ်ပါတယ်။

• Same region peering ကို Intra-region peering လို့ ‌‌ခေါ်ပြီး ၊ Different region peering ကို‌‌တော့ Inter-region peering လို့ ‌ခေါ်ပါတယ်။

• Cost အနေနဲ့ ကတော့ VPC peering connection creating and maintaining အတွက် charges မရှိပါဘူး။ Data transfer charges only ဘဲ ကျသင့်မှာ ဖြစ်ပါတယ်။ Data transfer charges သည် same region (same AZ) အတွက်ဆို လျှ င် free ဖြစ်ပါတယ်။ same region (different AZ) အတွက်ဆိုလျှင် GB အလိုက် cost အနည်းငယ် ကုန်ကျမှာဖြစ်ပါတယ်။ Different region အတွက်ဆိုလျှင်လည်း GB အလိုက် ကုန်ကျမှာ ဖြစ်ပါတယ်။ AWS region တွေကို ဖြတ်သွားရတာဖြစ်လို့ same region ထက်တော့ cost ပိုများမှာ ဖြစ်ပါတယ်။

• အချုပ်ဆိုရမယ်ဆိုရင် VPC အရေအတွက် နည်းမယ် ၊ Cost လည်း သက်သာချင်တယ် ဆိုရင် ‌‌‌တော့ VPC peering သုံးသင့်ပါတယ်။

Transit Gateway (TGW)

• VPC အရေအတွက်လည်း များလာပြီ (e.g 10-100 VPC) ၊ နောက်ထပ်လည်း VPC ထပ်တိုးဖို့ ရှိမယ်၊ Multi-account/ Multi-region setup လည်း ဖြစ်လာပြီ ၊ on-premises network နဲ့ ချိတ်ဆက်ဖို့ လည်း လိုအပ်လာပြီ ဒီ အခြအနေထဲက တစ်ခုခုနဲ့ ကိုက်ညီနေပြီ ဆိုရင်တော့ Transit Gateway( TGW) ကို သုံးသင့်ပါသည်။

• TGW သည်လည်း AWS backbone network ကို အ သုံးပြုတာဖြစ်ပါတယ်။

  ပထမဆုံး ဥပမာ အနေနဲ့ same Account, Same Region နဲ့ ဥပမာ ပြထားပါတယ်။

• Transit Gateway တစ်ခု create လုပ်ပါမယ်။

• သက်ဆိုင်ရာ VPC တွေမှာ Transit Gateway Attachment create လုပ်ပါမယ်။

• VPC (A,B,C) တွေရဲ့ Transit Gateway Attachment တွေက Transit Gateway ကို ချိတ်ဆက်ကြမယ်။ Route table တွေမှာ လည်း route တွေ ရေးပြီးပြီ ဆိုရင် VPC (A,B,C) တွေသည်TGW မှတဆင့် အချင်းချင်း connect လုပ်လို့ရပါပြီ။ အခုလို အခြေအနေကို Transitive ဖြစ်တယ်လို့ ခေါ်ပါတယ်။ Hub and spoke architecture ဖြစ်ပါတယ်။

• Cost အနေနဲ့ ဆိုရင်တော့ Data processing fees ကို GB အလိုက်ပေးဆောင်ရမည့် အပြင် TGW attahcment fees ကို attachment တစ်ခုချင်းစီအတွက် နာရီအလိုက် ကျသင့်မှာပါ။ VPC peering ထက် ပိုပြီး အကုန်အကျ များတယ်ဆိုပေမယ့် large network တွေအတွက် ပို အဆင်ပြေ ပါတယ်။

How to connect VPCs in different AWS accounts but in the same Region using a Transit Gateway (TGW) ?

နောက်ထပ် use case တစ်ခု အနေနဲ့ ပြောပြချင်တာကတော့ Transit Gateway ကို အသုံးပြုပြီး different account , same region မှာ ရှိနေတဲ့ VPC အချင်းချင်း ချိတ်ဆက်ချင်ရင် ဘယ်လို ချိတ်ဆက်ရမလဲ ကို ‌‌ ပြပေးသွားပါ့မယ်။

Transit Gateway (TGW) သည် regional resource ဖြစ်လို့ region တူရင် sharing လုပ်လို့ရပါတယ်။

Different account ဖြစ်ပေမယ့် same region ဖြစ်လို့ TGW ကို sharing လုပ်ပြီး VPC အချင်းချင်း ချိတ်ဆက်လို့ ရပါတယ်။

1. Create Transit Gateway (Account A)

2. Share TGW with Account B.

3. Accept the TGW Share (Account B)

4. Create a TGW Attachment (Account B)

5. Accept the Attachment (Account A)

6. Update TGW Route Tables

7. Update VPC Route Tables

How to connect VPCs in different Region using a Transit Gateway (TGW) ?

နောက်ထပ် sharing လုပ်ပေးချင်တဲ့ use case တစ်ခုကတော့ Transit Gateway ကို အသုံးပြုပြီး

same account ဖြစ်စေ different account ဖြစ်စေ different region မှာ ရှိနေတဲ့ VPC တွေ အချင်းချင်း ချိတ်ဆက်ချင်ရင်တော့ Transit Gateway peering ကို အသုံးပြုပေးရမှာပါ။

Transit Gateway (TGW) သည် regional resource ဖြစ်လို့ region မတူရင် sharing လုပ်လို့မရပါဘူး။

Transit Gateway peering နဲ့ ပတ်သတ်ပြီး နောက်ထပ် blog တစ်ခု မှာ အသေးစိတ် ထပ်ရေးထားပေးပါတယ်။

ဒီနေ့ sharing လုပ်ပေးချင်တာကတော့ AWS ရဲ့ Core Networking service ဖြစ်တဲ့ VPC အကြောင်းဘဲ ဖြစ်ပါတယ်။ AWS account create လုပ်လိုက်တာနဲ့ default ပါလာတဲ့ VPC အ ကြောင်းအရင်လေ့လာကြည့် ကြပါမယ်။

AWS account တစ်ခု create လုပ်လိုက်တာနဲ့ Region 1 ခုမှာ VPC 1 ခု default အနေနဲ့ ပါပါတယ်။

(Region 1 ခုမှာ အများဆုံး VPC 5 ခုထိ create လုပ်လို့ရပါတယ်။ Region 1 ခုမှာ VPC 5 ခုထပ် ပိုပြီး လိုချင်ရင်‌‌

တော့ AWS management console မှာ Service Quota Increase Request လုပ်ပေးရမှာပါ။ )

မတူညီတဲ့ Region ၊ မတူညီတဲ့ AZ အရေအတွက် ပေါ်မူတည်ပြီး ပါဝင်တဲ့ subnets အရေအတွက် ကွာသွားပါတယ်။ (e.g ap-southeast-1 region ဆိုရင် AZ 3 ခု ရှိလို့ subnets 3 ခု ပါဝင်ပါတယ်။ us-east-1 region ဆိုရင် AZ 6 ခု ရှိလို့ subnets 6 ခု ပါဝင်ပါတယ်။ )

Default VPC မှာ Route Table 1 ခု ၊ Internet Gateway 1 ခု ပါ ပါတယ်။

Default Route Table မှာ Route 2 ကြောင်း ပါ ပါတယ်။

Route Table မှာ ဘာ Route ‌‌‌ ‌တွေ ပါလဲ ဆိုရင် VPC ထဲမှာ ရှိတဲ့ subnets ‌ အချင်းချင်း connect လုပ်နိုင်အောင် local route ‌ရေးထားပါတယ်။

Destination: 172.31.0.0/16   (or your VPC’s CIDR block)
Target: local

Internet Gateway မှ တစ်ဆင့် Internet ထွက်နိုင်အောင်လို့ route ‌ရေးထားပါတယ်။

Destination: 0.0.0.0/0
Target: igw-xxxxxxxx

Internet ထွက်နိုင်လို့ subnets ‌တွေသည် Public subnet ဖြစ်ပါသည်။

Security Components အနေနဲ့ Default Network ACL နဲ့ Default Security group ၁ ခုစီ ပါ ပါသည်။

Default NACL, Security Group ‌တွေ မ သုံး ဘဲနဲ့ စိတ်ကြိုက် ထပ်ပြီး create လုပ်လို့ရပါတယ်။

ဒီ‌ ‌လောက််ဆိုရင်‌ တော့ Default VPC မှာ ဘာတွေပါ လဲ ဆိုတာ သိလောက်ပြီ ထင်ပါတယ်။

ဒီနေ့ပြောပြသွားမယ့် Lab လေးကတော့ Roles တစ်ခု create လုပ်ပြီး သွားတဲ့ အခါမှာ အဲ့ roles ကို create လုပ်ခဲ့တဲ့ account မှာ ရှိနေတဲ့ user ကဘဲ သုံးလို့ ရတာမဟုတ်ဘဲ နဲ့ တခြား account တစ်ခုမှာ ရှိနေတဲ့ user ကပါ ယူသုံးလို့ ရတယ်ဆိုတာကို lab ‌လုပ်ပြသွားမှာ ဖြစ်ပါတယ်။

AWS Account B မှာ ရှိနေတဲ့ IAM user လေးက AWS Account A မှာ ရှိနေ တဲ့ IAM roles ကို သုံးပြီးAccount A မှာ ရှိနေတဲ့ S3 Bucket ကို fullaccess လုပ်လို့ရတာလေးကို ပြောပြသွားမှာ ဖြစ်ပါတယ်။

1. ပထမဆုံး အနေနဲ့ AWS account 2 ခု ရှိရပါမယ်။

2. Account A ထဲမှာ S3 bucket တစ်ခု create လုပ်ရပါမည်။ Objects ထည့်ထားချင်လည်းရပါတယ်။

3. Account A ထဲမှာ Roles create လုပ်ရပါမည်။

4. Account B ထဲ မှာ IAM user create လုပ်ရပါမည်။ အဲ့ IAM user မှာ Account A မှာ ရှိနေတဲ့ roles ကို assume role လုပ်ပါမယ်ဆိုတဲ့ permissions policy ‌attach လုပ်ပေးရပါမယ်။

Account 2 ခု ရှိထားပြီးသားဖြစ်တဲ့ အတွက် အခု Account A မှာ S3 bucket တစ်ခု create လုပ်ပါမယ်။

Bucket name - labbucket-3189 နာမည်နဲ့ bucket တစ်ခု create လုပ်ထားပါမည်။

Bucket ထဲမှာ object တစ်ခု ထည့် ထားလိုက်ပါ တယ်။

Roles create လုပ်ပါမည်။

IAM > Roles > Create role

Roles ကို create လုပ်တဲ့ အခါမှာ Trusted entity type ရွေးပေးရပါတယ်။ အခု lab အတွက် AWS Account ကို ရွေးပါမည်။

AWS Account ကို ‌ရွေးပြီးတဲ့ အခါမှာ ဘယ် account ID က ဒီ roles ကို သုံးမှာလဲ ဆိုပြီး Account ID သတ်မှတ်‌ ပေးရပါမည်။

Another AWS Account ကို ‌select လုပ်ပါမည်။ Account B ရဲ့ ID ကို ထည့်ပေး ရပါမည် ။

နောက် တ ဆင့် အနေ နဲ့ Roles မှာ တွဲမယ့် permissions ရွေးချယ်ပေး ရပါမည်။

ဒီ Lab အတွက် S3Fullaccess permission ‌ရွေးချယ်ပေးပါမည်။

Role name ‌ပေးပါမည် ။

Then Create role.

အခု ဆိုရင် Account A ဘက် မှာ S3 bucket and roles create လုပ်ပြီးသွားပါပြီ။

Roles ရဲ့ Trusted entity မှာ another account (Account B) ရဲ့ ID ကို ‌ရွေးချယ်ထားပါတယ်။

Roles မှာ S3Fullaccess permissions သတ်မှတ်ထားပါတယ်။

အခု နောက်တစ်ဆင့် အနေ နဲ့ Account B ထဲကို ဝင်ပြီး IAM user create လုပ်ပါမယ်။

IAM > user > create user

Next >

user ကို permission သတ်မှတ်ပေးရပါမည်။ Attach policies directly ကို ရွေးပါမည်။

အခု သတ်မှတ်ချင် ‌ သော policy ကို create လုပ်ရန် create policy ကို ‌ရွေးပါမည်။

Create policy > JSON ကို ‌ ရွေးပါမည်။

အောက်ပါ policy ကို ‌‌‌ ‌ရေးပါမည်။

Account B မှာ ရှိတဲ့ Hla_Hla ဆိုတဲ့ IAM user ‌သည် Account A မှာ ရှိနေတဲ့ roles ကို သုံးမှာ ဖြစ်လို့

Effect : Allow

Action : sts : AssumeRole

Resource မှာ Account A မှာ ရှိတဲ့ roles name ARN ကို copy သွားယူပြီး ထည့်ပေးရမှာ ဖြစ်ပါတယ်။

Next > Policy name ‌‌ပေးပါမည် ။

Create policy.

Create policy ကို နှိပ်ပြီး လျှင် user create လုပ်နေတဲ့ tab ဘက်ကို ပြန်လာရပါမည်။

Create policy ‌ရှေ့က refresh policies ကို နှိပ်မှ create လုပ်ခဲ့ ‌သော policy name ကို မြင်ရမည် ဖြစ်ပါသည်။

မိမိ create လုပ်ခဲ့ ‌သော policy ကို ‌ရွေးပါ။

Next > Create user.

အခု ဆိုရင်‌တော့ Account B ထဲမှာ IAM user create လုပ်ပြီးသွားပြီ ဖြစ်ပါတယ်။

အဲ့ IAM user ‌သည် Account A မှာ ရှိတဲ့ roles ကို သုံးပါမယ်ဆိုပြီး permissions လည်း သတ်မှတ်ပြီးပြီ ဖြစ်ပါသည်။

Account B ရဲ့ IAM user Hla_Hla နဲ့ login ဝင်ထားပါမည်။

S3 ကို ဝင်ကြည် ပါမည်။ ‌‌အောက််ပါအတိုင်း ‌တွေ့ရပါလိမ့်မည်။

Hla_Hla ဆိုတဲ့ user မှာ assume role policy ကလွဲလို့ တခြား ဘာ permissions policy မှ ‌attach လုပ်ထားတာ မရှိလို့ ‌ ဖြစ်ပါတယ်။

Switch role လုပ်ရန် အတွက် account id ရဲ့ arrow ကို နှိပ်ပြီး Add session > New role လုပ်ပါမည်။

အောက်ပါ အတိုင်း ‌ပေါ်လာပါမည်။

Account ID - role ရှိသော account ID or Alias (Account A ရဲ့ Account ID or alias ထည် ‌ပေးရပါမည်။ )

IAM role name - role name ထည့် ‌ပေးရပါမည်။

Switch role >

S3 bucket ကို ဝင် ကြည့်ပါမည်။

Objects ကို လည်း delete လုပ်လို့ရတာ တွေ့ရပါလိမ့်မယ်။

ဒီနေ့ sharing လုပ်ပေးချင်တာကတော့ IAM user တွေမှာ policy ကို directly attach လုပ်ပြီး သုံးတာနဲ့ Roles ကို assume လုပ်ပြီး သုံးတာ ဘာကွာခြားမှုရှိလဲ ဆိုတာကို ဆွေးနွေးသွားမှာ ဖြစ်ပါတယ်။

IAM user မှာ policy ကို directly attach လုပ်ပြီး သုံးတဲ့ အခါမှာ ဘယ်လို အလုပ်လုပ်သလဲ ဆိုတော့ user ‌ သည် long-term credentials (username/password or access key) ကို သုံးပြီး ဝင်ရောက်ပါတယ်။

Long-term credentials ဖြစ်တဲ့ (Username/password or access key )တို့သည် ‌leak ဖြစ်သွားနိုင်ပါသည်။ ထို့ကြောင့် security point of view အရ ကြည့်မယ်ဆိုရင် Risk ရှိနိုင်ပါတယ်။

ဘယ်လိုအခါမျိုးမှာ policy ကို direct attach လုပ်ပြီးသုံးသင့်လဲဆို ‌တော့ user သည် ဒီ permission ကို ဘဲ အမြဲသုံး ဖို့ လိုအပ်တဲ့ အခါမှာ မျိုးမှာ ဖြစ်စေ ၊ minimal permission ‌ ဖြစ်တဲ့ read-only access ကိုလိုအပ်တဲ့အခါမျိုးမှာဖြစ်‌စေ သုံးသင့်ပါတယ်။

E.g - Mg Mg ဆိုတဲ့ user ကို S3RealonlyAccess ‌‌policy ကို directly attach ပေးထားမယ်ဆို ရင် အဲ့ user login ဝင်တိုင်း S3 Bucket ‌တွေကို အမြဲ readonly access ရနေမှာ ဖြစ်ပါတယ်။

IAM user မှာ Roles ကို assume လုပ်ပြီး သုံးတဲ့ အခါမှာ ဘယ်လို အလုပ်လုပ်သလဲဆိုတော့ user သည် permission တစ်ခုကို ခဏ ငှားသုံး တဲ့ပုံစံနဲ့ အလုပ်လုပ်ပါတယ်။

Credentials အတွက်ကို AWS STS( Security Token Service) ကနေ temporary credentials ‌‌ တစ်ခု ထုတ်ပေးပါတယ်။ အဲ့ credentials သည် time limit ရှိပါသည်။ Temporary credentials ဖြစ်တဲ့ အတွက် security point of view အရ ကြည့်မယ်ဆိုရင် long-term credentials ထက် ပို ပြီး safe ‌ ဖြစ်ပါတယ်။

Cross-account access ကို လည်းSupport လုပ်ပေးတဲ့ အတွက် AWS multi-account setup ‌တွေ အတွက် လည်း အဆင်‌ပြေပါတယ်။

Roles ကို ဘယ်လိုနေရာမျိုးမှာ သုံးသင့်လဲဆိုရင် user တစ်‌ယောက်ကို permissions အမြဲ‌ ပေးမထားချင်ဘူး၊ လိုအပ်တဲ့ အခါမှ သာ အဲ့ permissions ကို သုံးစေချင်တယ်ဆိုရင် Roles ကို သုံးသင့်ပါတယ်။

e.g - Mg Mg ဆိုတဲ့ user ကို S3FullAccess ‌‌ ‌‌ပေးချင်တယ် အမြဲတမ်းလည်း မဟုတ်ဘူး လိုအပ်တဲ့အခါမှာ သာ S3Fullaccess ‌‌ပေးသုံးချင်တယ်ဆိုရင် roles ကို သုံးသင့်ပါတယ်။ ဒီ Roles ကို သုံးလိုက်တဲ့ အချိန်လေးမှာ AWS STS ကနေ ထုတ်ပေးတဲ့ Temporary credentials လေးတစ်ခုကို သုံးပြီး S3FullAccess ရနေမှာဘဲဖြစ်ပါတယ်။

IAM Users, User Groups and Roles အကြောင်းဘဲ ဖြစ်ပါတယ်။

IAM Users

• AWS ကို သုံးမယ် ဆိုရင် Daily work တွေ အတွက် Root user ကို မသုံးသင့် ဘူးဆိုတာ အားလုံးလည်း သိပြီးသားဖြစ်မှာပါ။ အဲ့ဒါကြောင့်မလို့ AWS ကို သုံးဖို့ အတွက် IAM users တွေ Create လုပ်ပေးရပါမယ်။

• IAM user ‌‌create လုပ်ပြီးပြီ ဆိုရင် အဲ့ user အတွက် သက်ဆိုင်ရာ permissions သတ်မှတ် ‌ ပေးရပါမည်။ IAM users တိုင်းကို မလိုအပ်ဘဲနဲ့ Admin permissions ပေးစရာမလိုပါ။

• Job Functions မတူတဲ့ user တွေ ကိုယ့် user ကိုယ့် permissions သတ်မှတ်ချက်နဲ့ သီးသန့် သုံးဖို့ အတွက် ဖြစ်ပါတယ်။ (e.g Admin, Developer, tester,….)

• IAM user နှင့် login ဝင်ရန် Username + password လိုအပ်ပါသည်။

• IAM user တစ်ယောက်ချင်းစီ ကို သီးခြားစီ Manage လုပ်နိုင်ပါသည်။

Figure - IAM users

User Groups

• User Groups ဆိုသည်မှာ အလွယ်ပြောရရင် permissions တူတဲ့ IAM users တွေကို စု ထားတဲ့ Group တစ်ခုဖြစ်ပါတယ်။

• (e.g - Developers 3 ယောက်အတွက် Group တစ်ခု create လုပ်ပြီး အဲ့ Group ထဲကို IAM user 3 ယောက် ထည့်ထားခြင်းဘဲ ဖြစ်ပါတယ်။ Group ကို permission ပေးလိုက်တာနဲ့ group ထဲ မှာ ရှိတဲ့ user တိုင်းကို အဲ့ permission သက်ရောက်သွားမှာ ဖြစ်ပါတယ်။

  

Figure - IAM User Groups

Roles

• Roles ဆိုတာ သတ်မှတ်ထားတဲ့ permissions တွေပါတဲ့ temporary identity တစ်ခုဖြစ်ပါတယ်။

• အဲ့ဒီRoles ကို AWS services (E.g EC2) , users ‌‌တွေက ယူသုံးလို့ရပါတယ်။

• Roles တစ်ခု create လုပ်တဲ့ အခါမှာ AWS Services ‌‌ တွေ က ဒီroles ကိုသုံးမှာလား ၊ AWS Account က ဒီ roles ကို သုံးမှာလားဆိုပြီး Trusted entity ‌ရွေးချယ်ပေးရပါတယ်။ ရွေးချယ်စရာ Trusted entity 5 မျိုးရှိပါတယ်။

1. AWS Service

2. AWS Account

3. Web Identity

4. SAML 2.0 federation

5. Custom Trust Policy

ဒီလောက်ဆိုရင် IAM Users, User Groups and Roles အကြောင်းလေး သိလောက်ပြီ ထင်ပါတယ်။

အားလုံးကို ကျေးဇူးတင်ပါတယ်။

Scroll down, you will see the “IAM user and role access to Billing information” is “Deactivated”.

So, you need to activated. Go to Edit.

Check “Activated IAM access” and click update.

After Activated, login with IAM user and check Billing Preferences. You can access Billing Preferences page like that.

About Billing Preferences

Billing Preferences မှာ ဘာ တွေ လုပ်လို့ ရလဲဆိုရင်

1. AWS မှာ ကိုယ်သုံးထားတဲ့service တွေက ဘယ်လောက်ကျလဲ ၊ ဘာservice တွေသုံးထားလဲဆိုတဲ့ Monthly invoice တွေကို PDF format နဲ့ကိုယ့် ဆီemail ပို့အောင် Invoice Delivery Preferences ကိုActivated လုပ်ပေးလို့ရပါတယ်။

2. Free Tier Alerts နဲ့ ပတ်သတ်တဲ့ usage တွေကို ကိုယ့်ဆီEmail ပို့အောင် သတ်မှတ်ထားပေးလို့ရပါတယ်။

3. CloudWatch billing alerts ‌‌‌တွေ လက်ခံလို့ ရအောင် enable လုပ်ပေးလို့ရပါတယ်။

   

Click “Edit”.

Check “PDF invoices delivered by email” and then click Update.

Setting up CloudWatch billing alarms

• CloudWatch billing alarms ဘာလို့ သတ်မှတ်သလဲဆိုရင် ကိုယ့်ရဲ့ AWS total bill သည် ကိုယ်သတ်မှတ်ထားသော ပမာ ဏ(e.g - 5$) ထက်ကျော် ခဲ့ မယ်ဆိုရင် ကိုယ့်ဆီ Noti ပို့အောင် လို့ သတ်မှတ်ခြင်းဖြစ်ပါတယ်။

• CloudWatch မှာ Billing Alarms သတ်မှတ်မယ်ဆိုရင် Region သည် N.Virginia (us-east-1) ဖြစ်မှ Billing Alarms သတ်မှတ်လို့ရပါမည်။

  Go to CloudWatch > Alarms > Create alarm

  

  

  Conditions မှာ

  Threshold type > Static

  Greater than 5 USD သတ်မှတ်ပါမည်။ (မိမိလိုအပ်‌သော amount သတ်မှတ်နိုင်ပါသည်။)

  Next.

  

  Select “ Create new Topic” Topic name ပေးပါ။ Email ထည့်ပါ။ Click Create Topic.

  

  

  ကိုယ့်ရဲ့ Email ထဲ ကို Confirm လုပ်ဖို့ mail ရောက်လာပါလိမ့်မယ်။ Confirm Subscription ကိုနှိပ်ပါ။

  

  

  Alarm name ‌‌‌‌ ‌သတ်မှတ်‌ရပါမည်။

  

  

  

• AWS ကို အသုံးပြုရန် AWS account တစ်ခု create လုပ်ရပါမည်။

• AWS account တစ်ခု create လုပ်ရန် JCB, Visa, Master, တစ်ခုခုရှိရပါမည်။ မိမိ၏ Bank card ထဲတွင်

  1 US$ နှင့် ညီမျှ‌‌သော ငွေ amount ရှိရပါမည်။

• AWS account တစ်ခု create လုပ်ရန် email address တစ်ခုကို အသုံးပြုပြီး sing up လုပ်ရပါမည်။

• Email address တစ်ခုကို အသုံးပြုပြီး ရလာသော user သည် root user ဖြစ်ပါသည်။

• Root user ကို ဖြစ်နိုင်ရင် မသုံးသင့်ပါဘူး။ ဘယ်လိုအခါမျိုးမှားသုံးသင့်လဲဆိုတာကို အောက်ပါ link မှာ လေ့လာနိုင်ပါတယ်။ (https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html)

AWS account create လုပ်ရန် ‌www. aws.amazon.com ထဲသို့ ဝင်ပါ။ Create account ကို နှိပ်ပါ။

Email address နှင့်Account name ထည့် ပါ။ Verify email address ကို နှိပ်ပါ။ မိမိEmail တွင်‌‌ ရောက်လာ‌သော verification code ကို ရိုက်ပါ။

‌Root user password သတ်မှတ်‌‌ရပါမည်။

Free plan ကို ရွေးပေးပါ။

Choose your plan Business or Personal plan. And then fill your information.

Fill your bank card information.

Confirm your identity.

မိမိ ဖုန်းထဲသို့‌ ရောက်လာသော code ကိုထည့်ပါ။

Choose “Basic support - Free”. And then click “Complete Sing up:.

Now you got your AWS Account. Go to the AWS Management Console.

You will see your Console Home page. ညာဘက် အပေါ်ထောင့်လေးမှာ Account ID နှင့် မိမိသတ်မှတ်ခဲ့သော Account name လေးပါရှိပါတယ်။

• အခု ဆိုရင်တော့ Email address တစ်ခုကို သုံးပြီး လုပ်ထားတဲ့ root user လေးရသွားပါပြီ။

• Root user ကို ဖြစ်နိုင်ရင် မသုံးသင့်ပါဘူး။ ဘယ်လိုအခါမျိုးမှားသုံးသင့်လဲဆိုတာကို အောက်ပါ link မှာ လေ့လာနိုင်ပါတယ်။ (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)

• AWS account ကို အသုံးပြုရန် IAM user ကို create လုပ်ထားသင့်ပါသည်။

• Root user create လုပ်ပြီးတဲ့ အခါမှာ ဘာတွေ ဆက်လုပ်သင့်လဲ ဆိုတာကို နောက် Blogs တွေမှာ ထပ်ရေးပေးပါ့မယ်။

အားလုံးကို ကျေးဇူးတင်ပါတယ်။

KodeKloud's 100 Days of DevOps မှာပါဝင်တဲ့ Labs တွေရဲ့ sloution တွေကို နေ့စဉ် တစ်နေ့တစ်ခု တင်ပေးသွားပါမယ်။

လိုအပ်တာတွေရှိရင်လည်း မှတ်ချက်ပေးသွားလို့ရပါတယ်။

Big thanks to KodeKloud for great free DevOps practice and letting me share the solutions!

Playlist URL: https://www.youtube.com/playlist?list=PLxTojPvLKeYdxwCGa63wT6gGY7L6bpHrx

KodeKloud Lab URL: https://kodekloud.com/100-days-of-devops

ဒီဆောင်းပါးမှာ Container တွေ အောက်ခြေမှာ ဘယ်လိုအလုပ်လုပ်လဲ၊ Container တွေ တခုနဲ့တခု Network Layer မှာ ဘယ်လိုဆက်သွယ်လဲဆိုတာ အခြေခံသဘောတရားတွေကို လက်တွေ့ကျကျ လေ့လာရမှာ ဖြစ်ပါတယ်။ လက်တွေ့စမ်းကြည့်လို့လည်း ရနိုင်ပါတယ်။ Linux မှာ အလွယ်တကူရတဲ့ Command-line Tools နဲ့ စမ်းသပ်ထားပါတယ်။ ဒီဆောင်းပါကို ဖက်ပြီး စမ်းကြည့်ပြီးရင်တော့ Docker ရဲ့ Bridge Networking ကို ကောင်းကောင်းနားလည်သွားပါလိမ့်မယ်။

Summary: Key Points

• ခေတ်သစ် Containerization နည်းပညာရဲ့ အခြေခံအုတ်မြစ်ဖြစ်သော Linux Namespaces အကြောင်း။

• Linux Namespaces ဘယ်လိုအလုပ်လုပ်ပြီး Container တွေ Host Machine ကနေ ဘယ်လို သီးခြားခွဲထုတ်ပြီး တည်ဆောက်လို့ရသလဲ။

• Virtual Ethernet (VETH) နှင့် Bridge Networking ဘယ်လို အလုပ်လုပ်သလဲ။

• Containers နှင့် Container Networking ရဲ့ အခြေခံအဆင့် (low level) တွင် မည်သို့အလုပ်လုပ်သလဲဆိုတာ ဒီဆောင်းပါးမှာ အဓိကလေ့လာရမှာ ဖြစ်ပါတယ်။

Prerequisities

• Linux Host (e.g., Ubuntu, Fedora, etc..)

• Linux Namespaces

• Command-Line Tools chroot, unshare, ip

Setup Project Structure

ပထမဦးဆုံးအနေနဲ့ Container တွေ ဘယ်လိုအလုပ်လုပ်လဲ ဆိုတာကို နားလည်နိုင်ဖို့အတွက် chroot နှင့် unshare CLI tools များကို အသုံးပြုပြီး Container များကို အစကနေ တည်ဆောက်ပြီး run ကြည့်ပါမယ်။

Project Structure သည် အောက်ပါအတိုင်း ဖြစ်ပါလိမ့်မယ်။

/home/zawzaw/containers
        ├── alpine-linux
        │   ├── bin
        │   ├── dev
        │   ├── etc
        │   ├── home
        │   ├── lib
        │   ├── media
        │   ├── mnt
        │   ├── opt
        │   ├── proc
        │   ├── root
        │   ├── run
        │   ├── sbin
        │   ├── srv
        │   ├── sys
        │   ├── tmp
        │   ├── usr
        │   └── var
        └── tiny-linux
            ├── bin
            ├── dev
            ├── proc
            ├── sbin
            ├── sys
            └── usr

Containers လို့ အမည်ပေးထားတဲ့ Project directory တစ်ခုဆောက်လိုက်ပါမယ်။ အဲဒီနောက် Alpine Linux Root Filesystem image ကို အဲဒီ directory ထဲကို ထည့်လိုက်မှာ ဖြစ်ပါတယ်။

$ mkdir -p containers/alpine-linux

ဒီဆောင်းပါးမှာ Alpine Linux Mini root filesystem ကို အသုံးပြုမှာ ဖြစ်ပါတယ်။ Alpine Linux ရဲ့ Official website ဖြစ်တဲ့ https://alpinelinux.org/downloads သို့သွားရောက်ပြီး Alpine Linux Mini root filesystem ကို download လုပ်လိုက်ပါ။ Alpine Linux က Container များနှင့် Minimal chroots များမှာ အသုံးပြုဖို့အတွက် Alpine Mini root filesystem ကို ထောက်ပံ့ပေးထးပါတယ်။ aarch64, armv7, riscv64, x86, x86_64 စသည်ဖြင့် မတူညီသော System architectures များကို ထောက်ပံ့ပေးပါတယ်။

(သို့မဟုတ်)

curl command line tool ဖြင့် download လုပ်နိုင်ပါတယ်။ ဥပမာ - x86_64 architecture အတွက်။

$ curl -LO https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-minirootfs-3.21.3-x86_64.tar.gz

Download လုပ်ထားသော Alpine Linux Mini rootfs file ကို containers/alpine-linux directory အောက်သို့ထည့်ပြီးနောက် mini rootfs tar file ကို ဖြည်ပါ။

$ cp alpine-minirootfs-3.21.3-x86_64.tar.gz ~/containers/alpine-linux
$ cd ~/containers/alpine-linux
$ tar -xzvf alpine-minirootfs-3.21.3-x86_64.tar.gz

ဖြည်ပြီးရင်တော့ alpine-minirootfs-3.21.3-x86_64.tar.gz tar file ကို ဖျတ်လိုက်လို့ ရပါပြီ။

$ rm alpine-minirootfs-3.20.2-x86_64.tar.gz

Project တည်ဆောက်ပုံက အောက်ပါပုံစံအတိုင်း ဖြစ်ပါလိမ့်မယ်။

/home/zawzaw/containers
        ├── alpine-linux
        │   ├── bin
        │   ├── dev
        │   ├── etc
        │   ├── home
        │   ├── lib
        │   ├── media
        │   ├── mnt
        │   ├── opt
        │   ├── proc
        │   ├── root
        │   ├── run
        │   ├── sbin
        │   ├── srv
        │   ├── sys
        │   ├── tmp
        │   ├── usr
        │   └── var

Running Containers from Scratch

Introduction to Chroot

/ (Host Root Filesystem)
├── bin
├── dev
├── etc
├── home
│   └── zawzaw/
│        └── containers/
│            ├── alpine-linux/
│            │    ├── bin
│            │    ├── dev
│            │    ├── etc
│            │    ├── home
│            │    ├── lib
│            │    ├── proc
│            │    ├── sbin
│            │    └── var
│            └── tiny-linux/
│                 ├── bin
│                 ├── dev
│                 ├── init.sh
│                 ├── linuxrc -> bin/busybox
│                 ├── proc
│                 ├── sbin
│                 ├── sys
│                 ├── sbin
│                 └── usr
├── proc
├── sbin
├── sys
├── usr
└── var

Change Root (chroot) က Unix နဲ့ Linux မှာ အလွယ်တကူ အသုံးပြုနိုင်တယ်။ Container တခုကို Host OS ကနေ ဘယ်လိုခွဲထုတ်ပြီး တည်ဆောက်တာမလဲဆိုတာ မလေ့လာခင် chroot ကို အရင်လေ့လာကြည့်ပါမယ်။

chroot က Container တွေရဲ့ အခြေခံသဘောတရားတခုလို့လည်း ဆိုနိုင်တယ်။ သမိုင်းကြောင်းအရ မူရင်း chroot system call က ၁၉၇၉ ခုနှစ်မှာ ထွက်ရှိခဲ့တဲ့ Unix Seventh Edition (Version 7) မှာ စတင်မိတ်ဆက်ခဲ့တာ ဖြစ်ပါတယ်။ Linux system တခုမှာ အဓိက Root filesystem တခုရှိပြီး၊ လက်ရှိအလုပ်လုပ်နေတဲ့ process နဲ့ သူ့ရဲ့ child process တွေအတွက် Root directory ကို ပြောင်းလဲပေးတဲ့ လုပ်ဆောင်ချက်တစ်မျိုး ဖြစ်ပါတယ်။ အဲဒီသီးခြား Root filesystem ထဲမှာ ကိုယ်စမ်းသပ်ချင်တာတွေ လုပ်ဆောင်လို့ရနိုင်တယ်။

ဒါပေမယ့် chroot client tool က Linux kernel ကနေ ထောက်ပံ့တဲ့ chroot(2) system call ကို ခေါ်ယူပြီး အသုံးပြုတာ ဖြစ်ပါတယ်။ ဒါကြောင့် chroot က နောက်ဘက်က Linux kernel ရဲ့ ထောက်ပံ့မှုပေါ်မှာ မူတည်ပါတယ်။

chroot ကို ဘယ်နေရာတွေမှာ သုံးနိုင်မလဲ ဆိုရင်

• Sandboxing: Program တစ်ခုကို သတ်မှတ်ထားတဲ့ environment မှာပဲ အလုပ်လုပ်စေပြီး System တစ်ခုလုံးကို ထိခိုက်မှုမရှိအောင် ကာကွယ်ပေးပါတယ်။

• Recovery and Testing: System တစ်ခု ပျက်သွားတဲ့အခါ ပြန်လည်ပြင်ဆင်ဖို့ ဒါမှမဟုတ် Software အသစ်တွေ စမ်းသပ်ဖို့အတွက် လိုအပ်တဲ့ environment တစ်ခုကို ဖန်တီးပေးပါတယ်။

Using the chroot User-space Tool

chroot client tool ကို စပြီး စမ်းသုံးကြည့်ပါမယ်။ အပေါ်မှာပြောခဲ့သလိုပဲ chroot က User-space tool ဖြစ်ပြီး၊ သူက chroot(2) system call ကို ခေါ်ယူပြီး အသုံးပြုတာဖြစ်ပါတယ်။

အပေါ်ဆုံးအဆင့်မှာ ဆောက်ထားတဲ့ ${HOME}/containers/alpine-linux အောက်ကို သွားပြီး chroot command ကို စသုံးပါမယ်။

$ cd $HOME/containers/alpine-linux
$ sudo chroot . /bin/sh

အဒီနောက် Linux commands တွေနဲ့ စပြီးစမ်းသပ်ကြည့်နိုင်ပါတယ်။

/ # ls -l
total 0
drwxr-xr-x    1 1000     1000           858 Jul 22 14:34 bin
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 dev
drwxr-xr-x    1 1000     1000           540 Jul 22 14:34 etc
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 home
drwxr-xr-x    1 1000     1000           272 Jul 22 14:34 lib
drwxr-xr-x    1 1000     1000            28 Jul 22 14:34 media
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 mnt
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 opt
dr-xr-xr-x    1 1000     1000             0 Jul 22 14:34 proc
drwx------    1 1000     1000            24 Jul 30 04:26 root
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 run
drwxr-xr-x    1 1000     1000           790 Jul 22 14:34 sbin
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 srv
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 sys
drwxr-xr-x    1 1000     1000             0 Jul 22 14:34 tmp
drwxr-xr-x    1 1000     1000            40 Jul 22 14:34 usr
drwxr-xr-x    1 1000     1000            86 Jul 22 14:34 var

/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.21.3
PRETTY_NAME="Alpine Linux v3.21"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

The /proc Virutal Filesystem

ပြီးတဲ့နောက် proc Virtual filesystem ကို ကိုယ့်ရဲ့ chroot environment ထဲမှာ Mount လုပ်ဖို့ လိုအပ်ပါလိမ့်မယ်။ ဒီ command က chroot environment မှာ proc Virtual filesystem ကို /proc directory ထဲကို Mount လုပ်လိုက်တာ ဖြစ်ပါတယ်။

$ mount -t proc proc /proc

ဒီနေရာမှာ proc Virtual filesystem ဆိုတာ ဘယ်လိုမျိူးလဲ။ ဘာကြောင့် Mount လုပ်ဖို့ လိုအပ်တာလဲလို့ မေးစရာရှိပါတယ်။

Linux မှာ proc က Virtual Filesystem (VFS) တနည်းအားဖြင့် Special filesystem တခုဖြစ်ပါတယ်။ proc က Linux kernel ရဲ့ နောက်ဘက်ကနေ ထောက်ပံ့ပေးထားတဲ့ VFS တခုဖြစ်ပြီး Hardware(System) နဲ့ Process အချက်လက်တွေကို In-Memory သိမ်းတာ ဖြစ်ပါတယ်။ ဒီနေရာမှာ ရှင်းရှင်းလင်းလင်းသိရမှာက /proc အောက်က files တော့ Linux kernel ကနေ Boot တတ်လာချိန်မှာ Dynamically တည်ဆောက်ပေးတာ ဖြစ်ပြီး၊ Disk ပေါ်မှာ တကယ်သိမ်းတာ မဟုတ်ဘဲ In-Memory ပဲ သိမ်းထားဖြစ်ပါတယ်။

ဥပမာ

• cat /proc/version က လက်ရှိ Linux kernel version ကို စစ်ကြည့်ဖို့သုံးနိုင်တယ်။

• cat /proc/cpuinfo က လက်ရှိ Linux system ရဲ့ CPU နဲ့ ပတ်သက်တဲ့ အသေးစိတ်အချက်လက်ကို အသေးစိတ် ကြည့်နိုင်တယ်။

ဒါကြောင့် chroot environment ထဲမှာ process နဲ့ ပတ်သက်တဲ့ အသေးစိတ်အချက်လက်ကို သိနိုင်ဖို့၊ သုံးနိုင်ဖို့ proc Virtual Filesystem ကို မဖြစ်နေ Mount လုပ်ဖို့လိုအပ်တာ ဖြစ်ပါတယ်။ အဲဒီလို Mount မလုပ်ရင် chroot environment ထဲမှာ ps လိုမျိုး command က ကောင်းကောင်း အလုပ်မလုပ်နိုင်ပါဘူး။

ဥပမာ

$ ps aux
# Error: Could not read /proc/stat

ဘာကြောင့်လဲဆိုတော့ ps က client tool ဖြစ်ပြီး တကယ့်လုပ်ဆောင်ချက်က နောက်ဘက်က /proc ကနေ ထောက်ပံ့ပေးတာကြောင့် ဖြစ်ပါတယ်။

အပေါ်က mount -t proc proc /proc ကို ကိုယ့်ရဲ့ chroot environment ထဲမှာ Run ပြီးရင်တော့ အောက်က Linux system နဲ့ process နဲ့ ပတ်သက်တဲ့ commands တွေကို စမ်းကြည့်နိုင်တယ်။

• cat /proc/cpuinfo

• ps aux

• ip addr

/ # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 142
model name      : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping        : 12
microcode       : 0xfc
cpu MHz         : 2900.231
cache size      : 8192 KB
...

/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize=51 rhgb
    2 root      0:00 [kthreadd]
    3 root      0:00 [pool_workqueue_]
    4 root      0:00 [kworker/R-rcu_g]
    5 root      0:00 [kworker/R-sync_]
    6 root      0:00 [kworker/R-slub_]
    7 root      0:00 [kworker/R-netns]
    9 root      0:00 [kworker/0:0H-ev]
   12 root      0:00 [kworker/R-mm_pe]
   14 root      0:00 [rcu_tasks_kthre]
   15 root      0:00 [rcu_tasks_rude_]
   16 root      0:00 [rcu_tasks_trace]
   17 root      0:16 [ksoftirqd/0]
   18 root      0:10 [rcu_preempt]
   19 root      0:00 [rcu_exp_par_gp_]
   20 root      0:00 [rcu_exp_gp_kthr]
...

/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether fa:8b:5b:09:59:51 brd ff:ff:ff:ff:ff:ff
    inet 192.168.55.129/24 brd 192.168.55.255 scope global dynamic noprefixroute wlo1
       valid_lft 75600sec preferred_lft 75600sec
    inet6 fe80::fa24:a316:4e60:c881/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
...

ဒီနေရာမှာ သတိထားမိပါလိမ့်မယ်။ chroot environment ထဲမှာ Host OS ရဲ့ Process / Network နဲ့ ပတ်သက်တာတွေအားလုံးကို မြင်နေရတာကို တွေ့ရပါလိမ့်မယ်။ နောက်အပိုင်းမှာ ဘယ်လို Isolate လုပ်လို့ရမလဲဆိုတာ အသေးစိတ်လေ့လာကြည့်ပါမယ်။

Isolating from the Host Machine

Linux Namespaces

Linux Namespaces က Linux kernel ရဲ့ feature တခုဖြစ်ပြီး ခေတ်သစ် Containerization နည်းပညာရဲ့ အခြေခံအုတ်မြစ်တခုလည်း ဖြစ်ပါတယ်။

အဓိက သဘောတရားကတော့ Process အစု၀ေးတခုအတွက် မတူညီတဲ့ System resources တွေကို Host Machine ကနေ သီးခြားခွဲထုတ်ပြီး Virtualize လုပ်တောကို လုပ်ဆောင်ပေးတယ်။ Namespaces ကို ၂၀၀၂ ခုနှစ် Linux kernel version 2.4.19 တည်းက စတင်သုံးခဲ့ပါတယ်။

System resources ဆိုတဲ့နေရာမှာ အောက်ပါအရာတွေပါ၀င်ပါတယ်

• PID (Process ID)

• Mount

• UTS (UNIX Timesharing System)

• IPC (Inter-process Communication)

• Network

• User

• Control Groups (CGroups)

Documentation: https://man7.org/linux/man-pages/man7/namespaces.7.html

ဥပမာ - Linux Host Machine တခုပေါ်မှာ Container တခု လည်ပတ်နေတယ် ဆိုပါစို့။

• Container မှာ သီးခြားကိုယ်ပိုင် Root Filesystem ရှိနိုင်တယ်။ အကြောင်းက သူက Host Machine ကနေ Mount Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။

• Container မှာ သီးခြားကိုယ်ပိုင် Hostname ရှိနိုင်တယ်။ အကြောင်းက သူက Host Machine ကနေ UTS Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။

• Container မှာ သီးခြားကိုယ်ပိုင် PIDs များ ရှိနိုင်ပါတယ်။ အကြောင်းကတော့ သူမှာ Host Machine ကနေ PID (Process ID) Namespaces ကို ခွဲထုတ်လိုက်လို့ ဖြစ်ပါတယ်။

Using the unshare User-space Tool

Linux Namespaces က Linux kernel ကနေ နောက်ဘက်ကနေ ထောက်ပံ့ပေးသူဖြစ်ပြီး သူနဲ့ ဆက်သွယ်ဆောင်ရွတ်ဖို့က unshare client tool ကို သုံးနိုင်ပါတယ်။

unshare က Client tool ဖြစ်ပြီး Linux Namespaces က Backend service လို့ မြင်လို့ရပါတယ်။ ushare CLI tool က unshare(2) system call ကို ခေါ်ပြီး Namespace အသစ်တခု ဆောက်တာ သို့မဟုတ် ရှိထားပြီးသား Namespace တခုကိုရွေ့တာ စသဖြင့် လုပ်ဆောင်နိုင်ပါတယ်။

အပေါ်က Linux Namespaces အပိုင်းမှာ ပြောခဲ့သလိုပဲ unshare CLI tool အောက်ပါ Namespaces တွေကို တည်ဆောက်နိုင်ပါတယ်။

• --mount: Create a new mount namespace.

• --uts: Create a new UTS namespace (isolates hostname and domain name).

• --ipc: Create a new IPC namespace.

• --net: Create a new network namespace.

• --pid: Create a new PID namespace.

• --user: Create a new user namespace.

• --cgroup: Create a new cgroup namespace.

• --fork: Fork a new process to run the command (required for PID namespaces).

စပြီး သုံးကြည့်ပါမယ်။ အပေါ်ဦးဆုံးအပိုင်းမှာ ဆောက်ခဲ့တဲ့ containers/alpine-linux အောက်ကို သွားပြီး unshare ကို Run ပါမယ်။ ဒီ command က PID / Mount / Network Namespaces တွေကို unshare ကို သုံးပြီး Host Machine ကနေ သီးခြားခွဲထုတ်လိုက်တာ ဖြစ်ပါတယ်။

$ cd containers/alpine-linux
$ sudo unshare --pid --mount --net -f chroot alpine-linux /bin/sh

/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.21.3
PRETTY_NAME="Alpine Linux v3.21"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

Change Root (chroot) အပိုင်းမှာ ပြောခဲ့သလိုပဲ System နဲ့ Process အချက်လက်ကို ရယူနိုင်ဖို့ /proc ကို Mount လုပ်ပေးဖို့ လိုအပ်ပါတယ်။

$ mount -t proc proc /proc

ပြီးတဲနောက်တော့ Chroot Container ထဲမှာ လက်ရှိလည်ပတ်နေတဲ့ Process ID (PID) နဲ့ Network interfaces တွေကို စစ်ကြည့်ပါမယ်။

/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 /bin/sh
    5 root      0:00 ps aux

/ # ip addr show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

ဒီနေရာမှာ သတိထားမိပါလိမ့်မယ်။ PID နဲ့ Network interfaces တွေက Host Machine ကနေ ခွဲထုတ်လိုက်ပြီး သီးခြားစီဖြစ်နေတာကို တွေ့ရပါလိမ့်မယ်။ နောက်အပိုင်းမှာ Network Layer မှာ Container တွေ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာ ဆက်လက်လေ့လာရမှာ ဖြစ်ပါတယ်။

Configuring Container Networks from Scratch

• Alpine Linux Container IP address: 172.19.35.3

• Tiny Linux Container IP address: 172.19.35.2

ဒီအပိုင်းမှာ Container နှစ်လုံးအတွက် အစကနေ VETH (Virtual Ethernet) နဲ့ Bridge Network တခု တည်ဆောက်ပြီး ဘယ်လိုအလုပ်လုပ်သလဲ လေ့လာရမှာ ဖြစ်ပါတယ်။ Virtual Ethernet (VETH) နဲ့ Bridge Networking က Linux Virtual Networking ရဲ့ အဓိကအစိတ်ပိုင်းတွေ ဖြစ်ပြီး Container နဲ့ Host Machine သို့မဟုတ် Container ကနေ Container ဆက်သွယ်ဖို့ အသုံးပြုပါတယ်။ Container Networking နည်းပညာဘက်မှာ အလွန်အသုံးများပါတယ်။

Virtual Ethernet (VETH)

Virtual Ethernet (VETH) ဆိုတာ ပိုက် (pipe) တစ်ခုလိုမျိုး လုပ်ဆောင်တဲ့ Virtual network interfaces နှစ်ခုတွဲ ဖြစ်ပါတယ်။ အဲဒီ Interface နှစ်ခုထဲက တစ်ခုကနေ ပို့လိုက်တဲ့ အချက်အလက် (packets) တွေဟာ ကျန်တစ်ခုကနေ လက်ခံရရှိမှာ ဖြစ်ပါတယ်။ VETH ကို ပုံမှန်အားဖြင့် Network namespaces များကို Host machine သို့မဟုတ် အခြား Network namespaces များနှင့် ချိတ်ဆက်ရန် အသုံးပြုပါတယ်။

VETH တွဲတစ်ခုမှာ Interfaces နှစ်ခု ပါဝင်ပါတယ်။

• တစ်ခုက Host machine ရဲ့ Network namespace ထဲမှာ ရှိပြီး

• ကျန်တစ်ခုက Container ရဲ့ Network namespace ထဲမှာ ရှိပါတယ်။

Interface တစ်ခုကနေ ပို့လိုက်တဲ့ packets တွေကို အခြား Interface ကနေ လက်ခံရရှိပါတယ်။ ဒါကြောင့် Container နဲ့ Host ဒါမှမဟုတ် အခြား Container တွေကြားမှာ အချင်းချင်း ချိတ်ဆက်ပြောဆိုနိုင်တာ ဖြစ်ပါတယ်။

Bridge Networking

Bridge Network ဆိုတာ Virtual network switch တစ်ခုဖြစ်ပြီး Network interfaces များစွာကို တစ်ခုနဲ့တစ်ခု ချိတ်ဆက်ပေးပါတယ်။ ဒါ့ကြောင့် Container တွေကို အချင်းချင်း ဆက်သွယ်နိုင်အောင် လုပ်ဆောင်ပေးပါတယ်။

• Bridge တစ်ခုဟာ Layer 2 device တစ်ခုလိုမျိုး လုပ်ဆောင်ပြီး ချိတ်ဆက်ထားတဲ့ Interfaces တွေကြားမှာ Ethernet frames တွေကို လက်ဆင့်ကမ်းပို့ဆောင်ပေးပါတယ်။

• Containers တွေ ဒါမှမဟုတ် Virtual Machines (VMs) တွေကို VETH pairs ကနေတဆင့် bridge နဲ့ ချိတ်ဆက်ပါတယ်။

Step (1): Setting up VETH Network for Container (A) — Alpine Linux Container

ဒီအပိုင်းမှာ Alpine Linux Container ပေါ်တွင် VETH ကွန်ရက်ကို ဘယ်လိုတည်ဆောက်မလဲဆိုတာ ဖော်ပြသွားပါမယ်။

အပေါ်မှာ စမ်းခဲ့တဲ့နည်းလမ်းအတိုင်းပါပဲ unshare နှင့် chroot Command-line tool များကို အသုံးပြုပြီး သီးခြားခွဲထားသော PID (Process ID)၊ Mount နှင့် Network namespaces များပါရှိတဲ့ Alpine Linux Container တခုကို တည်ဆောက်မှာ ဖြစ်ပါတယ်။

$ cd ${HOME}/containers/alpine-linux
$ sudo unshare --pid --mount --net \
  -f chroot . \
  env -i \
    HOME=/root \
    HOSTNAME=alpine-linux \
  /bin/sh
$ mount -t proc proc /proc

ထို့နောက် ကိုယ့်ရဲ့ Host Linux machine မှာ Container PID ကို ရယူပါ။ ဒီမှာတော့ ကျွန်တော့်ရဲ့ Alpine Linux Container PID သည် 25473 ဖြစ်ပါတယ်။

ဒီနေရာမှာ PID က စမ်းတဲ့သူပေါ်မှာ မူတည်ပြီး အပြောင်းလဲ ရှိနိုင်ပါတယ်။

[zawzaw@fedora-linux:~]$ ps -C sh
    PID TTY          TIME CMD
  25473 pts/6    00:00:00 sh

ပြီးရင်တော့ export command ဖြင့် ALPINE_CONTAINER_PID environment variable ကို သတ်မှတ်လိုက်ပါ။ VETH Network ကို တည်ဆောက်တဲ့အခါ ဒီ PID ကို လိုအပ်ပါတယ်။

[zawzaw@fedora-linux:~]$ export ALPINE_CONTAINER_PID=25473

Host Linux machine မှာ ip command-line tool ဖြင့် veth0, veth1 ဟုခေါ်သော VETH network pair တစ်ခုကို တည်ဆောက်လိုက်ပါမယ်။

ဒီနေရာမှာ သေချာနားလည်ရမှာက veth0 က Host machine မှာ ရှိမှာဖြစ်ပြီး၊ veth1 က Alpine Linux Container ဘက်မှာ ရှိမှာဖြစ်ပါတယ်။

[zawzaw@fedora-linux:~]$ sudo ip link add veth0 type veth peer name veth1
[zawzaw@fedora-linux:~]$ sudo ip link set veth1 netns "${ALPINE_CONTAINER_PID}"
[zawzaw@fedora-linux:~]$ sudo ip link set dev veth0 up

Alpine Linux Container ပေါ်တွင် veth1 Network interface ရဲ့ IP address ကို 172.19.35.3 လို့ သတ်မှတ်လိုက်ပါမယ်။

/ # ip addr add dev veth1 172.19.35.3/24
/ # ip link set lo up
/ # ip link set veth1 up

Host Linux machine ပေါ်တွင် Network interfaces များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။

[zawzaw@fedora-linux:~]$ ip addr show veth0
11: veth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c6:23:c1:27:62:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::c423:c1ff:fe27:62a8/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Alpine Linux Container ပေါ်တွင် Network interfaces နှင့် IP addresses များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။

/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
10: veth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 1e:c9:8c:80:fd:9a brd ff:ff:ff:ff:ff:ff
    inet 172.19.35.3/24 scope global veth1
       valid_lft forever preferred_lft forever
    inet6 fe80::1cc9:8cff:fe80:fd9a/64 scope link
       valid_lft forever preferred_lft forever

အခုအခြေနေမှာ veth0, veth1 VETH interfaces များ အလုပ်လုပ်နေပြီး ၎င်းတို့ရဲ့ IP address တွေကို 172.19.35.3 လို့ သတ်မှတ်ထားတာကို တွေ့ရပါလိမ့်မယ်။

Step (2): Setting up VETH Network for Container (B) — Tiny Linux Container

ဒီအပိုင်းမှာ အပေါ်ကဆင့်တွေအတိုင်းပဲ အတူတူပဲ ဖြစ်ပါတယ်။ နောက်ထပ် Container တလုံး တည်ဆောက်မှာ ဖြစ်ပါတယ်။ Container (B) အတွက် Linux kernel source code နဲ့ Busybox တို့ကို အသုံးပြုပြီး ကိုယ်တိုင် Compile လုပ်ထားတဲ့ Tiny Linux root filesystem image ကို အသုံးပြုပါမယ်။ Building a minimal Linux system from Scratch and Booting in QEMU Emulator မှာ အသေးစိတ် လေ့လာနိုင်ပါတယ်။

အောက်ပါ Tiny Linux root filesystem image ကို ဒေါင်းလုဒ်ဆွဲပြီး ~/containers/ project directory ထဲသို့ ထည့်လိုက်ပါ။

Download Link: Tiny Linux Root Filesystem Image

[zawzaw@fedora-linux:~/containers/tiny-linux]$ tree
.
├── bin
├── dev
├── linuxrc -> bin/busybox
├── proc
├── sbin
├── sys
└── usr

ဒီအပိုင်းမှာတော့ Tiny Linux Container ပေါ်မှာ VETH Network ကို တည်ဆောက်ပါမယ်။ ပထမအတိုင်းပဲ unshare နဲ့ chroot Command-line tool တွေကို အသုံးပြုပြီး Container (B)—Tiny Linux ကို PID (Process ID)၊ Mount နဲ့ Network namespaces တွေ သီးခြားခွဲထုတ်ပြီး တည်ဆောက်လိုက်ပါမယ်။

$ cd ${HOME}/containers/tiny-linux
$ sudo unshare --pid --mount --net \
  -f chroot . \
  env -i \
    HOME=/root \
    HOSTNAME=tiny-linux \
  /bin/sh
$ mount -t proc proc /proc

ပြီးရင် ကိုယ့်ရဲ့ Host Linux machine ကနေ Container PID ကို ရယူလိုက်ပါ။ ဒီနေရာမှာတော့ Tiny Linux Container PID က 29999 ဖြစ်ပါတယ်။

ဒီနေရာမှာ PID က စမ်းတဲ့သူပေါ်မှာ မူတည်ပြီး အပြောင်းလဲရှိနိုင်ပါတယ်။

[zawzaw@fedora-linux:~]$ ps -C sh
    PID TTY          TIME CMD
  25473 pts/6    00:00:00 sh
  29999 pts/9    00:00:00 sh

ထို့နောက် export command နဲ့ TINY_CONTAINER_PID environment variable ကို သတ်မှတ်လိုက်ပါမယ်။ ဒီ PID ကို VETH pair တည်ဆောက်တဲ့နေရာမှာ ပြန်သုံးမှာ ဖြစ်ပါတယ်။

[zawzaw@fedora-linux:~]$ export TINY_CONTAINER_PID=29999

Host Linux machine ပေါ်မှာ ip command-line tool နဲ့ veth2, veth3 ဆိုတဲ့ VETH network pair တစ်ခုကို တည်ဆောက်လိုက်ပါမယ်။

ဒီနေရာမှာ သေချာနားလည်ရမှာကတော့ veth2 က Host machine ဘက်မှာ ရှိမှာဖြစ်ပြီး၊ veth3 က Tiny Linux Container ဘက်မှာ ရှိမှာဖြစ်ပါတယ်။

[zawzaw@fedora-linux:~]$ sudo ip link add veth2 type veth peer name veth3
[zawzaw@fedora-linux:~]$ sudo ip link set veth3 netns "${TINY_CONTAINER_PID}"
[zawzaw@fedora-linux:~]$ sudo ip link set dev veth2 up

Tiny Linux Container ပေါ်တွင် veth3 Network interface ရဲ့ IP address ကို 172.19.35.2 လို့ သတ်မှတ်လိုက်ပါမယ်။

/ # ip addr add dev veth3 172.19.35.2/24
/ # ip link set lo up
/ # ip link set veth3 up

Host Linux machine ပေါ်တွင် Network interfaces များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။

[zawzaw@fedora-linux:~]$ ip addr show veth2
13: veth2@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:97:e6:1f:d4:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::497:e6ff:fe1f:d4b3/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Alpine Linux Container ပေါ်တွင် Network interfaces နှင့် IP addresses များကို စစ်ကြည့်လိုက်ရင် အောက်ကအတိုင်း တွေ့ရပါလိမ့်မယ်။

/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
12: veth3@if13: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
    link/ether 72:37:8b:a8:26:7e brd ff:ff:ff:ff:ff:ff
    inet 172.19.35.2/24 scope global veth3
       valid_lft forever preferred_lft forever
    inet6 fe80::7037:8bff:fea8:267e/64 scope link
       valid_lft forever preferred_lft forever

အခုဆိုရင် veth2, veth3 ဆိုတဲ့ VETH network interfaces တွေ အလုပ်လုပ်နေပြီး IP Address ကို 172.19.35.2 လို့ သတ်မှတ်ထားတာကို တွေ့ရပါလိမ့်မယ်။

ဒါပေမယ့် အခုချိန်မှာ Container A နဲ့ B က အချင်းချင်း ဆက်သွယ်လို့ရသေးမှာ မဟုတ်ပါဘူး။ ဒါကို ping command နဲ့ စမ်းသပ်ကြည့်နိုင်ပါတယ်။

• Container (A)—Alpine Linux IP Address: 172.19.35.3

• Container (B)—Tiny Linux IP address: 172.19.35.2

ဥပမာအားဖြင့် Tiny Linux Container ကနေ Alpine Linux (172.19.35.3) ကို ping လုပ်ကြည့်ပါ။ အလုပ်လုပ်မှာမဟုတ်ပါဘူး။ ဘာကြောင့်လဲဆိုတော့ ကျွန်တော်တို့ Bridge network ကို ထပ်ပြီးတည်ဆောက်ဖို့ လိုအပ်နေလို့ပါပဲ။

/ # ping -c 5 172.19.35.3
PING 172.19.35.3 (172.19.35.3): 56 data bytes

--- 172.19.35.3 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

နောက်တစ်ပိုင်းမှာတော့ Container နှစ်ခုကြားမှာ Network packets တွေကို ပို့ဆောင်ဖို့အတွက် Bridge network တစ်ခုကို ဘယ်လိုတည်ဆောက်ရမလဲဆိုတာကို လေ့လာရမှာ ဖြစ်ပါတယ်။

Step (3): Setting Up Bridge Network

အခုဆိုရင် ကျွန်တော်တို့မှာ Alpine Linux နဲ့ Tiny Linux ဆိုတဲ့ Container နှစ်ခုရှိနေပြီး၊ သူတို့ဟာ သီးခြားစီဖြစ်နေတဲ့ PID, Mount နဲ့ Network Linux namespaces တွေထဲမှာ အလုပ်လုပ်နေကြပါတယ်။ သူတို့မှာ Virtual Ethernet (VETH) pair ကိုလည်း တူညီတဲ့ Network Linux namespace ထဲမှာ ရှိပါတယ်။

ဒီအပိုင်းမှာတော့ Container နှစ်ခု ကြားက Network packets တွေကို လက်ဆင့်ကမ်းပို့ဆောင်ဖို့အတွက် Bridge network တစ်ခုကို ဆက်လက်တည်ဆောက်သွားပါမယ်။

Host Linux machine ပေါ်တွင် br0 လို့ခေါ်တဲ့ Bridge network တစ်ခုကို တည်ဆောက်လိုက်ပြီး၊ br0 Bridge network ကို veth0 နဲ့ veth2 Network interfaces တွေနဲ့ ချိတ်ဆက်လိုက်ပါမယ်။

[zawzaw@fedora-linux:~]$ sudo ip link add br0 type bridge
[zawzaw@fedora-linux:~]$ sudo ip link set veth0 master br0
[zawzaw@fedora-linux:~]$ sudo ip link set veth2 master br0

ထို့နောက် br0 Bridge network interface ရဲ့ IP Address ကို 172.19.35.1 လို့ သတ်မှတ်လိုက်ပါမယ်။ ပြီးရင်တော့ Up လိုက်ပြီး IP address ကို စစ်ကြည့်လို့ရပါပြီ။

[zawzaw@fedora-linux:~]$ sudo ip addr add dev br0 172.19.35.1/24
[zawzaw@fedora-linux:~]$ sudo ip link set br0 up

[zawzaw@fedora-linux:~]$ ip addr show br0
14: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:97:e6:1f:d4:b3 brd ff:ff:ff:ff:ff:ff
    inet 172.19.35.1/24 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::497:e6ff:fe1f:d4b3/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Testing Connectivity

ပြီးနောက် ping command-line tool ကို အသုံးပြုပြီး Container နှစ်ခုကြားက ကွန်ရက်ချိတ်ဆက်မှု ရှိ၊ မရှိကို စစ်ဆေးနိုင်ပါတယ်။

ဥပမာအားဖြင့် Tiny Linux Container ကနေ Alpine Linux Container (172.19.35.3)ကို ping လုပ်ကြည့်ပါမယ်။

/ # ping -c 5 172.19.35.3
PING 172.19.35.3 (172.19.35.3): 56 data bytes
64 bytes from 172.19.35.3: seq=0 ttl=64 time=0.070 ms
64 bytes from 172.19.35.3: seq=1 ttl=64 time=0.041 ms
64 bytes from 172.19.35.3: seq=2 ttl=64 time=0.059 ms
64 bytes from 172.19.35.3: seq=3 ttl=64 time=0.072 ms
64 bytes from 172.19.35.3: seq=4 ttl=64 time=0.050 ms

--- 172.19.35.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

ဥပမာအားဖြင့် Alpine Linux Container ကနေ Tiny Linux Container (172.19.35.2) ကို ping လုပ်ကြည့်ပါမယ်။

/ # ping -c 5 172.19.35.2
PING 172.19.35.2 (172.19.35.2): 56 data bytes
64 bytes from 172.19.35.2: seq=0 ttl=64 time=0.051 ms
64 bytes from 172.19.35.2: seq=1 ttl=64 time=0.105 ms
64 bytes from 172.19.35.2: seq=2 ttl=64 time=0.042 ms
64 bytes from 172.19.35.2: seq=3 ttl=64 time=0.053 ms
64 bytes from 172.19.35.2: seq=4 ttl=64 time=0.052 ms

--- 172.19.35.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

ယခုဆိုရင် Container နှစ်လုံးဟာ အချင်းချင်း ဆက်သွယ်နိုင်ပြီး ကောင်းမွန်စွာ အလုပ်လုပ်နေကြောင်း အတည်ပြုနိုင်ပါပြီ။

Reference Links

• https://blog.mbrt.dev/posts/container-network

• https://labs.iximiuz.com/tutorials/container-networking-from-scratch

• https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking

ဒီဆောင်းပါးမှာတော့ git history ထဲကို မတော်တဆ commit ထဲ ထည့်မိပြီးမှ ပြန်ဖျက်ထားခဲ့တဲ့ credentials ဖိုင်တွေနဲ့ file size ကြီးတဲ့ဖိုင်တွေကို အပြီးအပြတ် ဖယ်ရှားနိုင်မယ့်နည်းလမ်းတွေကို ဘယ်လို အသုံးပြုရမလဲ ပြောပြပေးသွားပါမယ်။

🤔 Why Just Deleting the File Isn’t Enough?

ဖိုင်တစ်ခုကို git rm path/to/secret.file နဲ့ ဖျက်ပြီး commit လုပ်လိုက်တာနဲ့ git history ထဲက ပျက်မသွားပါဘူး။ ဘယ်သူမဆို ဖိုင်မဖျက်ခင်အခြေအနေကို git checkout နဲ့ ပြန်သွားယူလို့ရပါတယ်။

git checkout <commit-hash> -- path/to/secret.file

ဒါကြောင့် ဒီဖိုင်ကို history ထဲက ဖျက်လိုက်ချင်ရင် ဒီဖိုင် စထည့်တဲ့ commit ကနေစပြီး git history တစ်ခုလုံးကို ပြန်ရေးဖို့လိုပါတယ်။

🛠️ Tools You Can Use

• git filter-repo

• bfg (Repo-Cleaner)

• git-sizer

📏 Git Repo Size ကို ကြည့်ဖို့ git-sizer အသုံးပြုနိုင်ပါတယ်။

🔧 Installation

# MacOS
brew install git-sizer

# Ubuntu
sudo apt install git-sizer

🧪 Run

git-sizer

Processing blobs: 41369                        
Processing trees: 89219                        
Processing commits: 3589                        
Matching commits to trees: 3589                        
Processing annotated tags: 5                        
Processing references: 39                        
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Biggest objects              |           |                                |
| * Blobs                      |           |                                |
|   * Maximum size         [1] | 962.0 MiB | ******                         |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Maximum path depth     [2] |    16     | *                              |
| * Maximum path length    [3] |   144 B   | *                              |

[1]  cabe5dd7cf7e0c275f789bd64cc5a943a7b79acb (refs/remotes/origin/example-branch:storage/path/large-file.ext)
[2]  9a7d193d8ea79aa0a21b0a8e13310c63cb54dc83 (refs/remotes/origin/example-branch^{tree})
[3]  600bc870aee0d3e4a97f592c8fd4b92edbf70ab4 (7ac90183211e4e4832650b03fa296773e5002ca8^{tree})

git-sizer ကို သုံးပြီး ဘယ် commits တွေကြီးနေတယ်၊ ဘယ်ဖိုင်အကြီးတွေ history ထဲပါနေတယ် ဆိုတာတွေကို သိရှိနိုင်ပါတယ်။ git repo size ကြီးအောင် ဘယ်ကောင်တွေက နေရာယူနေလဲ သိပြီဆိုရင်၊ အဲ့ဖိုင်တွေကို history ထဲကနေ အောက်ပါ နည်းလမ်းတွေသုံးပြီး ဖျက်လို့ရပါတယ်။

🧹 Step 2: Remove Files from Git History

Method 1: Using git filter-repo

✅ Install

brew install git-filter-repo
# or
pipx install git-filter-repo

filter-repo ကို install လုပ်ပြီးပြီဆိုရင်တော့ တစ်ဖိုင်ခြင်းဖြစ်စေ၊ တစ်ဖိုင်ထက် ပိုပြီးတော့ဖြစ်စေ ရှင်းနိုင်သလို။ extension နဲ့လည်း history ထဲက ရှင်းလိုက်လို့ရပါပြီ။

🧼 Remove Specific Files

git filter-repo --path .env --invert-paths

Multiple files:

git filter-repo --path .env --path secrets.json --invert-paths

By extension:

git filter-repo --path-glob '*.zip' --invert-paths

Method 2: Using BFG Repo-Cleaner

filter-repo ထက်စာရင် bfg က သုံးရတာ ပိုလွယ်ပါတယ်။ --delete-files option ကို သုံးပြီး ရှင်းကြသလို --strip-blobs-bigger-than option ကိုသုံးပြီးလည်း file size limit နဲ့လည်း ရှင်းလို့ရပါတယ်

✅ Install

brew install bfg

💥 Remove Files or Blobs

# Remove sensitive files
bfg --delete-files .env

# Remove blobs bigger than 100MB
bfg --strip-blobs-bigger-than 100M

History ထဲကနေ ဖျက်ပြီးပြီဆိုရင်တော့ မလိုတော့တဲ့ reflog တွေကို ဖျက်ပစ်ပြီး၊ မသုံးတော့တဲ့ object တွေကို ဖျက်ပစ်ဖို့ အောက်က command တွေ run ပေးဖို့လိုက်ရင်တော့ git history ထဲက ဖိုင်အကြီးတွေ မရှိတော့တဲ့အတွက် .git folder size က အများကြီး ကျသွားတာကို တွေ့ရပါလိမ့်မယ်။

🔄 Final Cleanup

git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force-with-lease

⚠️ Important Warnings

• ပြီးရင်တော့ force pushing နဲ့ပြန်တင်ပေးဖို့လိုသလို collaborators တွေကလည်း repo ကို ဖျက်ပြီး clone ပြန်လုပ်တာဖြစ်စေ hard reset လုပ်တာဖြစ်စေ လုပ်ပေးဖို့လိုပါတယ်။

• ဒါတွေကို မလုပ်ခင်မှာ repository backup လုပ်ထားသင့်ပါတယ်။

🔐 Prevent Future Leaks

• ဒီလိုမျိုးတွေ နောက်တစ်ခါ commit မလုပ်မိအောင် .gitignore ထဲမှာ ထည်ပေးထားသင့်ပါတယ်။

• file အကြီးတွေ history ထဲပါနေလား သိရအောင် weekly လောက်ဖြစ်ဖြစ် git-sizer နဲ့ ပုံမှန် စစ်ပေးသင့်ပါတယ်

အဆုံးအထိ ဖတ်ပေးလို့ ကျေးဇူးတင်ပါတယ်။

ကျွန်တော် ဒီနေ့မျှဝေပေးချင်တာကတော့ AWS ရဲ့ Certificates Exam တွေကို ဘယ်လိုမျိုး အခမဲ့ ဖြေဆိုနိုင်မလဲဆိုတာပဲ ဖြစ်ပါတယ်။ (စာရေးသားအချိန်ထိတော့ စာရေးသူကိုယ်တိုင် Voucher မရရှိသေးပါဘူး၊ အားလုံး ရဖို့တော့ မျှော်လင့်ပါတယ်)

၁။ AWS Educate မှာ Register ပြုလုပ်ပြီး Badge ရမည့် Course တခုခု ဥပမာ (Gen AI Course လိုမျိုး)ကို ပြီးဆုံးအောင် တက်ရောက်ဖို့ လိုအပ်ပါတယ် Register ပြုလုပ်ရန် လင့် - https://aws.amazon.com/education/awseducate/ Confirm ဖြစ်ဖို့ ခဏတော့ စောင့်ရပါလိမ့်မယ်။

၂။ Course ရဲ့ assessment ကိုပြီးဆုံးအောင် ဖြေဆိုပြီး ရက်ပိုင်းအတွင်း Credly Badge ရတဲ့ email အပြင် မကြာခင်မှာ Emerging Talent Community (ETC) ကို join ဖို့အတွက်လည်း အောက်ပါလို email ရပါလိမ့်မယ်။

၃။ ETC ကို join ပြီးတဲ့ နောက်မှာတော့ ETC က ချပေးတဲ့ activities တွေကို ပြုလုပ်ဖို့ လိုပါတယ်။ Activities တွေ လုပ်တာနှင့်အမျှ ပွိုင့်တွေ ရလာမှာ ဖြစ်ပါတယ်။ ပွိုင့်စုစုပေါင်း (၄၅၀၀) ရရင် Foundations Level Certificate Voucher ကို ရရှိနိုင်မှာဖြစ်ပြီး ပွိုင့်စုစုပေါင်း (၅၂၀၀) ရရင်တော့ Associate Level Certificate Voucher ကို ရရှိဖို့ အခွင့်အရေးရှိမှာ ဖြစ်ပါတယ်။ ပွိုင့်တွေရဖို့ activities တွေကိုတော့ ETC က ချပေးတဲ့ အပေါ်မှာ မူတည်တာမျိုးဖြစ်တဲ့အတွက် ဘယ်လောက်အတွင်း လိုအပ်တဲ့ ပွိုင့်တွေ ရမလဲဆိုတာကိုတော့ သေချာမပြောတတ်ပါဘူး။ ETC နှင့် ပတ်သတ်သည်တွေကိုတော့ အောက်ပါလင့်မှာ ဖတ်ရှူနိုင်ပါတယ်။ https://www.awseducate.com/registration/s/learner-faqs#emerging-talent-community

ETC မှာ ရှိတဲ့ activities တွေအလိုက် အောက်ပါလို ပွိုင့်တွေရမှာ ဖြစ်ပါတယ်။

၄။ အထက်ပါ အချက်တွေအပြင် AWS Skill Builder Platform ကနေ မိမိဖြေဆိုချင်တဲ့ exam preparation course တခုခုကိုလည်း ပြီးဆုံးအောင် တက်ဖို့လည်း လိုပါသေးတယ်။ အားလုံးပြီးမြောက်သွားရင်တော့ 100% free ရမည့် Voucher ကို request ပြုလုပ်နိုင်မှာ ဖြစ်ပါတယ်။ မိမိဖြေလိုတဲ့ Foundation or Associate Level Exam preparing ကို https://skillbuilder.aws မှာ သွားရောက် လေ့လာဖို့လိုပါတယ်။ (စာရေးသားအချိန်ထိတော့ စာရေးသူကိုယ်တိုင် Voucher မရရှိသေးပါဘူး၊ အားလုံး ရဖို့တော့ မျှော်လင့်ပါတယ်)

P.S Vouchers ရရှိနိုင်မှုအပေါ် မူတည်တာဖြစ်လို့ မြန်မြန်ဆန်ဆန်နဲ့ ယူထားမှ အဆင်ပြေမယ်နော်။

exam အတွက် ပြင်ဆင်တာကိုတော့ မိမိနှစ်သက်သည့် Platform တွေကနေ ပြင်ဆင်ဖို့လည်း အကြံပေးလိုပါတယ်။ အားလုံးပဲ အဆင်ပြေကြပါစေ။

ဒီ ဆောင်းပါးမှာတော့ Startup တွေ Smart Contract အသုံးပြူပြီး အရင်းနှီးရှာဖွေပြီး အကျိုးအမြတ်ခွဲဝေ ရာမှာအသုံးပြုပုံကိုပြောပြပေးမှာပါ။

Smart Contract Token အမျိုးစားများ နဲ့ အသုံးပြုပုံ

• Utility Tokens

  ICO (ICO အကြောင်းအောက်မှာဆက်ရှင်းထားပါတယ်) တို့လို ရင်းနှီးမြုတ်နှံမှု လုပ်ဖို့မဟုတ်ဘဲ သူရဲ့ blockchain ecosystem အတွင်းက Product or service အတွက် ငွေပေးချေရာတွင်အသုံးပြုတဲ့Token ဖြစ်ပါတယ်။ Cloud storage, Decentralized applications (dApps) တွေအတွက် ငွေပေးချေရာတွင်အသုံးပြုပါတယ်။

• Governance Tokens

  Token ပိုင်ဆိုင်သူကို ဗဟိုချုပ်ကိုင်မှုမရှိသော platform ဒါမှမဟုတ် protocol တစ်ခုထဲမ ဆုံးဖြတ်ချက်များတွင် ပါဝင်ခွင့်ပေးထားတဲ့ Token အမျိုးအစားတစ်ခုဖြစ်ပါတယ်။ ဥပမာ - Token ပိုင်ဆိုင်သူတွေက protocol အဆင့်မြှင့်တင်မှုတွေဒါမှမဟုတ် လုပ်ဆောင်ချက်အသစ်တွေကို မဲပေး ရွေးချယ် ဆုံးဖြတ်နိုင်ပါတယ်။

• Non-Fungible Tokens (NFTs)

  NFT တွေဟာ Token ဖြစ်လို့ Unique ဖြစ်ပြီး သူနဲ့ထပ်တူညီလဲလို့ရတာမရှိပါဘူး။ ဒီဂျစ်တယ်နည်းနဲ့ရောင်းလို့ရတာတွေဟာ NFT အဖြစ်လုပ်လို့ပါတယ်။ ပုံဖြစ်စေ၊ အသံဖိုင်ဖြစ်စေ ၊ ဗီဒီယိုဖိုင်ဖြစ်စေ အကုန်လုံးဟာ NFT ဒီဂျစ်တယ် မူပိုင်ခွင့် အဖြစ်နဲ့ ရောင်းချလို့ရပါတယ်။

ဒါတွေကတော့အသုံးများတဲ့ Token use case တွေပါ။

Startup တွေရဲ့ အရင်းနှီးရှာဖွေခြင်း ICO

ICO (Initial Coin Offering) ဆိုတာ ကနဦးအကြို ရှယ်ရာ ကို Block Chain တစ်ခုခုပေါ်မှာတည်ဆောက်ထားတဲ့ Digital token တွေကို ရောင်းချပြီး ရန်ပုံငွေရှာတယ်လို့ ပြောနိုင်ပါတယ်။ ICO ဆိုတာ သမားရိုးကျ ကုမ္ပဏီ လုပ်ငန်းတွေမှာ IPO ( Initial Public Offering ) လိုမျိုး ရင်းနှီးမြှုပ်နှံမယ့်သူများကို ရှယ်ယာပိုင်ဆိုင်ခွင့်ပေးပြီး လုပ်ငန်းဆိုင်ရာ ရံပုံငွေရှာဖွေခြင်းတစ်မျိုးပါဘဲ။

Token Development အတွက်ဘာတွေလိုမလဲ?

Developer တစ်ယောက်အနေနဲ့ Smart Contract ကိုရေးသားဖို့ဆိုရင် solidity language ကိုသုံးပြီးရေးနိုင်ပါတယ်။ JS, Rust တို့မှာလဲ Library တွေအဆင်သင့်ယူသုံးနိုင်ပါတယ်၊၊ ပထမဆုံး ကိုယ့် Token က ဘယ် Blockchain ပေါ်မှာ ထားမလဲဆို တာ ရွေးချယ်ရပါမယ် Startup တွေအသုံးများတဲ့ Blockchain တွေကတော့

• Ethereum

• Binance Smart Chain

• Solana

• Polygon

တို့ဘဲဖြစ်ပါတယ် တစ်ခုခြင်းဆီမှာ အားသာချက်အားနည်းချက်တွေရှိကြပါတယ် ဥပမာအနေနဲ့ Solana က Gas Fee cost သက်သာပြီး အမြန်နှုန်းမှာလဲ တစ်စက္ကန့်ကို Transaction ပေါင်း 65,000 အထိ လုပ်ဆောင်နိုင်ပြီး ကမ္ဘာ့အမြန်ဆုံး Blockchain ထဲမှာပါပါတယ်။ Solana က တစ်ခြား Blockchain ထက် မြန်တာတင်မဟုတ်ပါဘူး၊ ကျွန်တော်တို့ လက်ရှိ အသုံးပြုနေတဲ့ Visa, Master Transaction ထက် တောင်မြန်ပါတယ်။ သို့ပေမယ့် ကွန်ရက် ပြတ်တောက်ခြင်းနှင့် အခြား သော Blockchain များနဲ့ နှိုင်းယှဥ်ရင် Decentralized ဗဟိုချုပ်ကိုင်မှုကင်းလွတ်မှု အားနည်းချင်းတို့ ရှိတတ်ပါတယ်။ ဒါကြောင့် ကိုယ့် Project အတွက် Token တည်ဆောက်ဖို့ Blockchain ကိုရွေးချယ်စဥ်းစားရာမှာ Security, Gas Fee cost, Community and Support နဲ့ Scalability တို့ကိုထည့်သွင်းစဥ်းစားသင့်ပါတယ်။

Ref

https://medium.com/coinmonks/10-top-blockchain-platforms-for-crypto-token-development-5381f801028e

Type of token- https://hedera.com/learning/smart-contracts/types-of-smart-contracts

အဓိက အစိတ်အပိုင်းများမှာ-

1.Amazon SageMaker Lakehouse

• Lakehouse Architecture သည် S3, Redshift ကဲ့သို့သော Data Sources များမှ Structured နှင့် Unstructured Data များစွာကို တစ်စုတည်းပေါင်းစည်းပြီး Analytical Queries နှင့် Model Training အတွက် Data များကို လွယ်ကူစွာ အသုံးပြုပါတယ်။

2. Amazon SageMaker Data and Governance

• DataZone အပေါ်မှာ အခြေခံပြီး, SageMaker Catalog ကို အသုံးပြုကာ Data Search, Metadata Management, Model Cataloging, နှင့် Governance စနစ်တကျ ပြုလုပ်နိုင်ပါတယ်။

• Data Compliance, Access Control, နှင့် Data Lineage စနစ်များကို သုံးပြီး AI/ML Ecosystem ကို ယုံကြည်စိတ်ချစွာ လည်ပတ်စေနိုင်ပါတယ်။

3. SQL Analytics

• Price-to-Performance သင့်တော်သည့် SQL Engines (e.g., Amazon Athena) များကို အသုံးပြုပြီး Data Analysis နှင့် Insight Extraction များ ဆွဲထုတ်နိုင်ပါတယ်။

• Large-Scale Data Queries များကို Optimize လုပ်ပြီး Latency များကို လျှော့ချပေးပါတယ်။

4. Amazon SageMaker Data Processing

• Athena, Amazon EMR, နှင့် AWS Glue နှင့် ထိတွေ့၍

  • Data Preparation (ETL)

  • Data Cleansing

  • Feature Engineering

  • Advanced Data Transformation
    များကို လွယ်ကူစွာ ပြုလုပ်နိုင်ပါတယ်။

5. Amazon Bedrock

• Generative AI Applications တည်ဆောက်ရာတွင်အထောက်အကူပြုသော Bedrock သည် Pre-trained Foundation Models (e.g., Text, Vision, Audio) ကို အသုံးပြုနိုင်ပါတယ်။

• AWS Partner Model Library ကို အသုံးပြုကာ Custom Generative AI Solutions များကို Develop လုပ်နိုင်ပါတယ်။

Built-in Algorithms

SageMaker AI သည် Data Scientists နှင့် ML Practitioners များအတွက် Pre-built Algorithms များ ပါဝင်လာပြီး Model Training ကို လွယ်ကူစေပါတယ်။။ Algorithms များကို အောက်ပါအတိုင်း Category များခွဲထားပါတယ်-

Supervised Learning Algorithms

• Linear Learner

  • ရောင်းအားခန့်မှန်းခြင်း (Regression) နှင့် Binary Classification (e.g., Category သတ်မှတ်ခြင်း) တို့အတွက် အသုံးပြုနိုင်သည်။

• Factorization Machine

  • Movie Recommendation Systems နှင့် Shopping History အခြေခံ Recommendation Systems များတွင် အသုံးပြုနိုင်သည်။

Unsupervised Learning Algorithms

• K-Means

  • Unlabeled Data များကို အုပ်စုဖွဲ့ခြင်း (e.g., Customer Segmentation, Spam Detection) အတွက် အသုံးပြုပါတယ်။

• Principal Component Analysis (PCA)

  • Target Column နဲ့ Weak Correlation ရှိတဲ့ Columns များကို လျော့ချပေးရာတွင် အသုံးပြုပါတယ်။

• Random Cut Forest

  • IoT Sensor Data များမှ မူမမှန်သော Data များရှာဖွေရာတွင် အသုံးဝင်ပါတယ်။

• IP Insight

  • Unusual IP Address Patterns ရှာဖွေခြင်း (e.g., Unauthorized Access Attempts) အတွက် အသုံးပြုပါတယ်။

Specialized Algorithms

• Sequence to Sequence

  • Machine Translation, Text Summarization, Voice-to-Text Processing များတွင် အသုံးပြုပါတယ်။

• Semantic Segmentation

  • Image Pixels အဆင့်အထိ Data ရယူကာ High Precision Image Analysis (e.g., Object Detection) အတွက် အသုံးပြုပါတယ်။

Advanced Features in SageMaker AI

1. Edge Deployment with SageMaker Edge Manager

   • IoT Devices များအတွက် Models တင်နိုင်ပြီး Offline Predictions ဆောင်ရွက်နိုင်စေပါတယ်။

2. SageMaker Pipelines

   • Continuous Integration/Continuous Deployment (CI/CD)

     • ML Model များအတွက် CI/CD Processများကို အသုံးပြုပြီး ML Workflow များကို အလိုအလျောက်လည်ပတ်စေနိုင်ပါတယ်။

   • Automates ML Workflows with Reproducibility

     • စနစ်တကျဖန်တီးထားပြီးတဲ့ Workflowတွေကို နောက်pproject တွေမှာ ထပ်မံအသုံးပြုလို့ရအောင် စီမံနိုင်ပါတယ်။

3. Security and Governance

   IAM Role-based Access Control:

   • Amazon IAM ကို အသုံးပြုကာ User တစ်ဦးချင်းစီနှင့် Role အလိုက် Permission များကို ထိန်းချုပ်နိုင်ပါတယ်။

   • Encryption at Rest and In Transit:

     • Data များကို သိုလှောင်နေစဉ် (at rest) နှင့် လွှဲပြောင်းနေစဉ် (in transit) အချိန်များတွင် အချက်အလက်များကို AES-256 Encryption နှင့် TLS Encryption ဖြင့် လုံခြုံအောင် ပြုလုပ်ထားပါတယ်။

4. Custom Training Support

   • BYOC (Bring Your Own Container):

     • TensorFlow, PyTorch ကဲ့သို့သော Frameworks များသို့မဟုတ် Custom Containers များကို သုံးပြီး Training Jobs များကို သီးသန့် Configure လုပ်နိုင်ခြင်း။

     • အထူးလိုအပ်ချက်များနှင့်ကိုက်ညီအောင် Flexible Training Environment တည်ဆောက်နိုင်ခြင်း တို့ဖြစ်ပါတယ်။

နိဂုံးချုပ်အားဖြင့်

Amazon SageMaker AI သည် ML Model Development နှင့် Deployment အတွက် Comprehensive Service တခုဖြစ်ကာ၊ အခြေခံအဆင့်မှ အဆင့်မြင့် Use Cases များအထိ ML Workflow အားလုံးကို Handle ပြုလုပ်ပေးနိုင်ပြီး Built-in Algorithms, Flexible Deployment Options, Data Processing Tools, နှင့် Generative AI Support များကြောင့် Enterprise နှင့် SME တို့အတွက် ထိရောက်သော ML Platform တစ်ခုဖြစ်လာပါတယ်။

အားလုံးပဲ မင်္ဂလာပါခဗျာ အခွင့်အရေးလေးရတုန်းမှာ ယူထားလို့ရအောင်အတွက် မျှဝေပေးချင်တာလေး ရှိပါတယ်ခဗျာ။ Github Foundations Certificate ကို 0 USD ဖြင့် ဖြေဆိုခွင့်ရမှာဖြစ်ပါတယ်ခဗျာ။

ပထမဦးစွာ https://examregistration.github.com/overview ကိုသွားလိုက်ပါခဗျာ ပြီးရင်တော့ Github Foundations ဆိုတာလေးကို ရွေးချယ်ပေးပါခဗျာ။

ပြီးရင်တော့ Login with github ကိုရွေးချယ်ပြီး မိမိရဲ့ Github နှင့် Login ဝင်ပေးပါခဗျာ။

Github Foundation ကိုရွေးချယ်ထားရင်တော့ အောက်ပါအတိုင်းတွေ့ရပါလိမ့်မယ်ခဗျာ။

မြင်တဲ့အတိုင်းပဲ Checkout လုပ်မယ်ဆိုရင် 0 USD ဖြစ်သွားမယ်လို့ ပြောထားပါတယ်ခဗျာ။

“Schedule/TakeExam” ကို နှိပ်ပြီး Exam Registration ပြုလုပ်လို့ရပါတယ်ခဗျာ။

PSI Exam website ကိုရောက်သွားမှာဖြစ်ပြီး အောက်ပါအတိုင်း ပေါ်လာပါလိမ့်မယ်။

မိမိတို့ရဲ့ Information တွေသေချာဖြည့်ပေးပါ နောက်ပြီးမိမိတို့ရဲ့ ကုမဏီ email လည်းဖြည့်စွက်ထားပါခဗျာ။ ဖြည့်စရာဖြည့်ပြီးနောက် နောက်ဆုံး Checkout page ရောက်သွားတဲ့အခါမှာ 0 USD ဖြင့် Github Foundation Exam ကို ဖြေဆိုရပါပြီခဗျာ။ Non-proctored exam ဖြစ်လို့ မိမိဖြေချင်တဲ့အချိန်မှာ ဖြေမယ်ဆိုပြီး ဖြေလို့ရပါလိမ့်မယ် ( ကျွန်တော်မဖြေကြည့်ရသေးပါခဗျာ)။

အားလုံးအဆင်ပြေကြပါစေခဗျာ။

KT