Docker and CoreOS

လွန်ခဲ့တဲ့ ၂ နှစ်လောက်က Infrastructure ကနေ စပြီးတော့ Software တွေအထိ Service အနေနဲ့ ပုံစံအမျိုးမျိုး ပြောင်းလာတာတဲ့ အကြောင်းကို X as a Service ဆိုပြီးတော့ ရေးခဲ့ဖူးတယ်။ IaaS ကို အကျိုးရှိရှိ အပြည့်အဝ အသုံးချဖို့ဟာ ကိုယ် Design လုပ်ထားတဲ့ Software ရဲ့ Architecture အပေါ်မှာ အများကြီး မူတည်ပါတယ်။ Cloud Computing ကို စနစ်တကျ အသုံးချတဲ့ Software ဆိုတာက Service ကို ကုန်ကျစရိတ် အနည်းဆုံးနဲ့ Quality ကို အမြင့်ဆုံးအနေနဲ့ ပေးနိုင်အောင် Computing နဲ့ Data Storage တွေကို လိုအပ်ချက်အရ လိုတိုးပိုလျှော့ လုပ်နိုင်ဖို့အတွက် Design လုပ်ထားရပါတယ်။ Legacy Architecture နဲ့ Software ကို IaaS ပေါ်မှာ ထားလိုက်ရုံနဲ့ Cloud Computing ကို အသုံးချနိုင်တဲ့ Software ဖြစ်မသွားပါဘူး Physical Server ပေါ်မှာ အလုပ်လုပ်တာနဲ့ Virtualized Server ပေါ်မှာ အလုပ်လုပ်တာပဲ ကွာခြားတယ်လို့ပဲ ပြောလို့ရပါလိမ့်မယ်။

Cloud-Enabled Architecture မှာ အရာအားလုံးဟာ Variable ဖြစ်ပါတယ် ကိုယ့်ရဲ့ Software ဟာ လိုအပ်ချက်အရ Node (Machine) အရေအတွက် အတိုးအလျှော့ ဖြစ်နေမယ့် Cluster ပေါ်မှာ အလုပ်လုပ်ရမယ် အမြဲတမ်းတွေ့ကြုံရတဲ့ အခက်အခဲတွေက ကုန်ကျစရိတ်အတွက် Cluster ထဲက Node တွေမှာ Multiple Services ပေးဖို့ လိုအပ်တဲ့အခါ Dependency ပြဿနာတွေရှင်းရမယ်။ Cluster ထဲကို Node အတိုးအလျှော့ လုပ်တဲ့အခါ Application Software Deployment တွေ Data Sync တွေ စသည်ဖြင့် Initialization ပြဿနာတွေရှိမယ်။ Service ကို Manage လုပ်ဖို့အတွက်လည်း Cluster ထဲက ဘယ် Node ဟာ အလုပ်လုပ်နေသလဲ အဆင်သင့်ဖြစ်ပြီလဲ စသည်ဖြင့် Service Management ကလည်း Cluster ကြီးတာနဲ့ ပြဿနာလည်း အင်မတန်ကြီးပါတယ်။ Node တွေပေါ်မှာ Deploy လုပ်ထားတဲ့ ကိုယ့်ရဲ့ Application ကို Update လုပ်မယ်ဆိုရင်လည်း Cluster ထဲမှာရှိတဲ့ Node အားလုံးကို Update လုပ်ရတာလည်း အမြဲတမ်းခေါင်းခဲရတယ်။

ကိုယ့်တယောက်ထဲ ကြုံတွေ့ရတဲ့ ပြဿနာမဟုတ်တော့ ကိုယ့်နည်းကိုယ့်ဟန်နဲ့ ရှင်းနေကြရာက ၁ နှစ် ၂ နှစ်အတွင်း Tools တွေလည်း တခုပြီးတခုထွက်လာတယ်။ ပထမဆုံး သတိထားမိတာက Docker ဖြစ်မယ် Cloud Server တွေမှာ Single Node မှာ Multiple Services ကို Run မယ်ဆိုရင် Single Machine ဖြစ်နေတော့ Software Dependencies ပြဿနာရှိတတ်ပါတယ် တကယ်တော့ Service တခုဟာ Machine ၁ ခုပဲဖြစ်သင့်တယ် Isolation မှာ အလွယ်ဆုံးက Virtual Machine ပဲ ဒါပေမယ့် Cloud Server တွေက VM တွေဖြစ်တော့ အဲဒီ့အပေါ်မှာ VM ထပ်ပြီးတော့ Run ရင် Overhead က အရမ်းများပါတယ်။ Docker ကတော့ VM တခုအနေနဲ့ မဟုတ်ပဲနဲ့ Underlying Kernel ပေါ်မှာပဲ Container တခုအနေနဲ့ Virtualized လုပ်ထားတဲ့အတွက် VM တခုလို Overhead မများသလို VM လိုပဲ Container တခုဟာ Isolated System တခုအနေနဲ့ သုံးလို့ရတဲ့အတွက် Cloud Server တွေအတွက် အဆင်ပြေပါတယ်။

https://www.docker.com/

Docker ကိုသုံးမယ်ဆိုရင် Linux တခုပေါ်မှာ Docker ကို Install လုပ်ပြီးတော့ Application Deployment အတွက် လိုအပ်တဲ့ Software တွေက Docker Container တခုစီမှာ လုပ်ရမှာဖြစ်တော့ Docker ကို Physically Install လုပ်ထားတဲ့ Linux မှာ Additional Software က Install လုပ်ဖို့ မလိုသလောက် ဖြစ်သွားတော့ တကယ်ကတော့ Light Weight ဖြစ်မယ့် Linux တခုဆိုရင် လုံလောက်ပါတယ်။ ဒီနှစ်အစောပိုင်းမှာ CoreOS ထွက်လာတယ် အခြားသော Linux တွေနဲ့ ကွဲပြားတာက CoreOS မှာ Software Package Management တခုမှမပါလာပဲ Software Installation အားလုံးဟာ လိုအပ်ရင် Docker နဲ့ပဲ Install လုပ်လို့ရပါတယ်။ CoreOS မှာ အဓိကအားဖြင့် Cloud Server တွေအတွက် Design လုပ်ထားတဲ့ OS ပါ။ ဘာ Software မှ Install လုပ်လို့မရပေမယ့် Cloud Computing အတွက်တော့ အသုံးဝင်တဲ့ Service တွေပါလာတယ်။ CoreOS ဟာ တခုချင်း သီးသန့်အနေနဲ့ Run ဖို့မရည်ရွယ်တဲ့အတွက် Cluster Management အတွက် Service တွေပါလာတယ်။

https://coreos.com

CoreOS မှာ etcd ဆိုတဲ့ Service တခုပါလာတယ် Distributed Key/Value Storage အနေနဲ့သုံးလို့ရတယ် CoreOS Cluster တခုထဲက Node တွေကနေ လှမ်းပြီးတော့ ရေးလို့ဖတ်လို့ရတယ် စက်တလုံးထဲမှာ သိမ်းထားတာ မဟုတ်တဲ့အတွက် Cluster ရှိနေသ၍ ရေးလို့ဖတ်လို့ ရတဲ့အတွက် Data သိမ်းထားတဲ့ Node ကို Down သွားမှာလည်း မစိုးရိမ်ရပါဘူး။ etcd ကိုသုံးတဲ့အတွက် Node တခုနဲ့တခု အလွယ်တကူ Message Passing လုပ်လို့ရပါတယ် အရေးကြီးတဲ့ Configuration တွေကိုလည်း သိမ်းထားပြီးတော့ Node တိုင်းက Share လုပ်လို့ရတယ်။ Service Discovery အတွက်ဆိုလည်း Node တခုတက်လာရင် etcd ထဲမှာ စာရင်းမှတ်ထား Down မယ်ဆိုရင်လည်း စာရင်းထဲကသွားဖျက် စသည်ဖြင့် အသုံးချလို့ရပါတယ်။

Linux မှာ Service Management ဆိုတာက Init Scripts တွေကအရင်ကတည်းက ရှိတာဆိုတော့ တကယ်ကတော့ မထူးဆန်းပါဘူး ဒါပေမယ့် အလွယ်တကူရေးနိုင်တဲ့ အခြေအနေမှာမရှိပါဘူး။ CoreOS မှာပါတဲ့ systemd ဆိုတဲ့ Service Management က သာမန် Linux Init Scripts တွေထက် High Level ဖြစ်ပြီးတော့ ပိုပြီးတော့ အသုံးတည့်ပါတယ်။ Service တခုမစခင် Pre Requirement အနေနဲ့ Run ရမယ့် Commands တွေ အခြားသော Service ကို Dependencies ရှိရင်လည်း Run ရမယ့် Order တွေ Service Start ပြီးသွားရင် လုပ်ရမယ့် Post Action တွေလည်း အဆင်ပြေပြေ ပေးလို့ရတဲ့အတွက် လွယ်လည်း လွယ်သလို Flexible ဖြစ်ပါတယ်။

သာမန်အားဖြင့် Cluster တခုမှာ Node တခုချင်းကို Manage လုပ်ရတာ အင်မတန်ခက်ပါတယ်။ ဥပမာဆိုရင် Amazon EC2 မှာ Auto Scaling နဲ့ Cluster တခုလို သဘောထားပြီး Run နေတယ်ဆိုကြပါစို့ အကယ်၍ Cluster ထဲက Node တွေမှာ Service တခု Start/Stop လုပ်ချင်တယ်ဆိုရင် Script တခုနဲ့ API နဲ့ Cluster ထဲက Nodes (Instances) တွေရဲ့ စာရင်းကို ယူပြီးတော့ Start/Stop လုပ်ရုံကလွဲရင် Manual လိုက်လုပ်ဖို့ပဲရှိတယ်။ CoreOS မှာက စက်တလုံးထဲလို မစဉ်းစားပဲနဲ့ Cluster တခုလို့လဲ စဉ်းစားလို့ရပါတယ်။

CoreOS မှာ စက်တလုံးထဲ အတွက်ဆိုရင် systemd script နဲ့ Service Management အလွယ်တကူ လုပ်လို့ရသလိုပဲ Cluster တခုလုံးအတွက် ဆိုရင်လည်း fleet ဆိုတဲ့ Distributed Init System တခုပါတယ် fleet က systemd script ကိုပဲသုံးပြီးတော့ Cluster ထဲမှာရှိတဲ့ Node တွေပေါ်မှာ Service တွေကို အလွယ်တကူပဲ Manage လုပ်လို့ရပါတယ်။ Fleet ဟာ etcd နဲ့ systemd ပေါ်မှာပဲ တည်ဆောက်ထားတာပါ။ Service Discovery ကို enable လုပ်ထားရင် Node တခုတက်လာတာနဲ့ etcd ထဲမှာ မှတ်ထားပြီးတော့ အဲဒီ့စာရင်းအပေါ် မူတည်ပြီးတော့ သက်ဆိုင်ရာ Node မှာ systemd နဲ့ပြန်ပြီးတော့ အလုပ်လုပ်တာပါ။ ဘယ်လိုလုပ်ထားလဲပဲ ပြောတာပါ တကယ်က ကိုယ်တိုင်လိုက်လုပ်စရာ မလိုအပ်ပါဘူး fleet က တာဝန်ယူပါလိမ့်မယ်။

ရေးရင်းရေးရင်းနဲ့ Introduction ဟာ အတော်ရှည်သွားပြီ စမ်းကြည့်တာကတော့ EC2 ပေါ်မှာ ကောင်းကောင်းမွန်မွန် အလုပ်လုပ်ပါတယ် Production အတွက် သုံးဖို့မဆုံးဖြတ်သေးပေမယ့် စမ်းကြည့်သလောက်ဟာ အတော်ကို Stable ဖြစ်တဲ့အတွက် Production မှာသုံးလို့ရပါတယ်။ နောက်တခုမှဆက်ပြီးတော့ CoreOS Cluster တခု ဘယ်လိုလုပ်မလဲ Example ကိုရေးတော့မယ် အခုခေတ်မှာ တခုကောင်းတာက EC2 လို Production သုံးလို့ရတဲ့ Environment ကို Access လုပ်လို့မရလည်း ကိုယ့်စက်မှာပဲ Simulate လုပ်ပြီး စမ်းလို့ရပါတယ်။ Simple Cluster ၁ ခုရယ် Actual Deployment Structure ၁ ခုရယ်ဆိုပြီး အနည်းဆုံးတော့ Example ၂ ခုလောက်တော့ ရေးပါဦးမယ်။ ဘယ်တော့လဲဆိုရင်တော့ အာရုံလည်းရ အချိန်လည်းရှိလို့ အကျိုးအကြောင်း တိုက်ဆိုင်ရင်ပေါ့။