Docker မိတ်ဆက် အပိုင်း(၂)
Last updated
Last updated
အရှေ့ post မှာ Docker နဲ့ ပတ်သတ်ပြီး စိတ်ဝင်စားဖို့ ကောင်းတဲ့ အကြောင်းအရာလေး တွေကိုမိတ်ဆက်ပေးခဲ့ပါတယ်။ အခုဒီတစ်ခုမှာတော့ Docker ရဲ့ အလုပ်လုပ်ပုံနဲ့ virtualization နည်းပညာနဲ့ ကွာခြားချက်လေးတွေကို ဆက်ပြီးတော့ ဆွေးနွေးချင်ပါတယ်။ တခါတခါ Docker ကို Hypervisor virtualization နဲ့ အထင်မှားတတ်ပါတယ်။ ဆိုကြပါတော့… Hyper-V တို့ VMware ESXi တို့လို Hypervisor virtualization ဟာ Docker နဲ့ သဘောတရားအရ ဆင်တူပေမယ့် တကယ်တော့ backend အလုပ်လုပ်ပုံကွားခြားသလို၊ မတူနဲ့ container နည်းပညာနောက်တစ်ခုကို အသုံးပြုထားတာပါ။ နောက်တစ်ခုက Docker ဟာ Linux kernel ပေါ်မှာပဲ အလုပ်လုပ်တယ်ဆိုကို ရှင်းရှင်းလင်းလင်းသိထားဖို့လိုပါတယ်။ တခြား kernel မှာဆိုရင် Linux kernel subsystem သို့မဟုတ် Linux Virtual Machine တစ်ခုကို ကြားခံ အနေနဲ့ အသုံးပြုရမှာပါ။
Microsoft က Docker ကို adopt လုပ်တယ်လို့ အရှေ့မှာ ပြောခဲ့ပါတယ်။ တကယ်တန်းတော့ Microsoft က Linux kernel တစ်ခုလုံးကို သူ့ OS မှာ adopt လုပ်ဖို့ ကြိုးစားနေတာ ၂၀၁၆ ခုနှစ်လောက်ထဲပါ။ စာဖတ်သူတို့လည်း Microsoft Loves Linux ဆိုတဲ့ဟာ banner တွေကို ဟိုနားတစ ဒီနားတစ တွေ့လိုက်မိမယ်လို့ ထင်ပါတယ်။ တချိန်တုန်းကလည်း Novell ကို Microsoft က သူ့ရဲ့ အောက်မှာ ထားဖို့ကိုလည်း ကြိုးစားလိုက်သေးပါတယ်။ အကြောင်းအမျိုးမျိုး ကြောင့် Novell deal ပျက်သွားခဲ့ပါတယ်။ အခုနောက်ပိုင်းမှာတော့ Microsoft ရဲ့ ချင်းကပ်ပုံ ပိုပြီးတော့ သိမ်မွေ့တယ်လို့ စာရေးသူ တကိုယ်ရေး မြင်ပါတယ်။ Linux kernel နဲ့ တချို့ Linux open source project တွေမှာ Microsoft က ဝင်ပြီးတော့ contributor လုပ်ပါတယ်။ တချို့ project တွေမှာဆို Microsoft က main contributor အနေနဲ့တောင် ဖြစ်လို့နေပါတယ်။ Open source community ကတော့ Microsoft ရဲ့ contribution လက်ခံပါတယ်။ အဲ့ဒါကြောင့်လည်း နောက်ပိုင်းမှာ Microsoft ဟာ Linux kernel ကို သူ့ရဲ့ OS မှာ ပေါ်ပေါ်တင်တင် အခုဆိုယူသုံးပါတယ်။ တနည်းက Windows 10 မှာ Linux ကို subsystem နဲ့ သုံးလို့ ရအောင် ထည့်ထားပေးပါတယ်။ စာရေးသူ အသုံးပြုကြည့်သလောက်တော့ အဆင်ပြေလှတယ်တော့ မဟုတ်ပါဘူး။ Experimental add-on feature အနေနဲ့ Windows 10 မှာပါလာတာပါ။ နောက်တစ်နည်းက Docker ကို Microsoft မှာ run လို့ရအောင်လို့ Windows ရဲ့ Hyper-V hypervisor သုံးပြီးတော့ Molly Linux VM ဆိုတာကို run လိုက်ပါတယ်။ အဲ့ဒီ VM ပေါ်မှာ ထပ်ပြီးတော့ Docker Engine တင်လိုက်ပြီးကာမှ Docker Containers တွေကို အပေါ်မှာ ထပ်ပြီး တင်လိုက်ပါတယ်။ မေးစရာရှိတာက VM မသုံးချင်လို့ Docker သုံးတာကို VM ပေါ်မှာ Docker တင်တော့ overhead မရှိဘူးလားဆိုတာပါ။ Overhead ရှိပါတယ်။ သုံးလို့လည်း အဆင်မပြေပါဘူး။ ဆိုလိုရင်းက Docker သုံးမယ်ဆိုရင် Linux distro တစ်ခုကို ကိုယ့်ရဲ့ စက်ပေါ်မှာ OS အနေနဲ့သုံးသင့်ပါတယ်။ ကိုယ်က Windows လည်းသုံးချင်သေးတယ်ဆိုရင်တော့ Ubuntu နဲ့ dual boot တင်ပြီးတော့ Docker ကို Linux ဘက်မှာ အသုံးပြုသင့်ပါတယ်။ နောက်ဆုံး လုံးဝ အဆင်မပြေဘူးဆိုမှ VM မှာ ကိုယ်ကြိုက်တဲ့ distro ကို install လုပ်ပြီးတော့၊ အဲ့ဒီ VM မှာ Docker တင်ပြီးတော့သုံးသင့်ပါတယ်။ Docker အတွက် Microsoft ရဲ့ implementation ကို တတ်နိုင်သလောက် ရှောင်ဖို့ကို တိုက်တွန်းချင်ပါတယ်။
အထက်မှာလည်း နည်းနည်းတော့ရှင်းထားပြီးပါပြီ။ ဒါပေမယ့်လည်း အသေးစိတ်ရှင်းပြရင် အကျိုးရှိမယ်ထင်လို့ ထပ်ပြီးတော့ သပ်သပ်ခေါင်းစဉ်တစ်ခုမှာ ထက်ပြီးတော့ရှင်းရတာပါ။ လက်ရှိအသုံးပြုတဲ့ virtualization နည်းပညာမှာ အောက်မှာ ပြထားတဲ အတိုင်း Docker ထက် layer တွေအဆင့်ဆင့် ရှိတာကို တွေ့ရမှာဖြစ် ပါတယ်။ ဥပမာ Hypervisor နဲ့ Guest OS ဆိုတာတွေက Docker ထက် သိသိသာသာ ပိုတဲ့ အပိုင်းလေး တွေပါ။ တကယ်တန်း implement လုပ်တဲ့အခါမှာလည်း virtualization နည်းပညာမှာ အဆင့်တွေအများကြီးပါဝင်ပါတယ်။ ပထမ အပိုင်းမှာလည်း VM တစ်လုံးကို application တစ်ခုအတွက် ပြင်ဆင်ရပုံကို ရှင်းပြထားပြီးပါပြီ။ ဘယ်လိုပဲ VM တစ်လုံးရဖို့ အဆင့်တွေများများ နောက်ဆုံးတော့လိုရင်းက application တစ်ခုကို develop လုပ်ဖို့၊ အသုံးပြုဖို့ပါပဲ။ လက်တွေ့မှာတော့ အဆုံးသတ်ရတာက application ဆီပဲရောက်ရတာပါ။ Application centric ဖြစ်တဲ့ ခေတ်လို့ပဲ ဆိုရတော့မှာပါ။ ဒါဆိုရင် Virtualization ဆိုတဲ့ backend infrastructure က အချိန်လည်းကုန်၊ layer တွေလည်းများတာကြောင့် overhead လည်းများပါတယ်။ ဥပမာ storage အပိုင်းမှာပဲကြည့်လိုက်ရအောင်… physical server ရဲ့ I/O rate ဟာ physical hard drive မှာ ပိုပြီး ထိရောက်မှုရှိပြီး ပိုလည်းသွက်ပါတယ်။ VM level ရောက်တဲ့ အခါမှာတော့ Layer အဆင့်ဆင့်ကို ဖြတ်သန်းလိုက်ရတဲ့အတွက် Latency အနည်းနဲ့ အများတော့ရှိပါတယ်။ ဒါဟာ storage တစ်ခုတည်းပဲရှိပါသေးတယ်။ VM ကိုသုံးမယ်ဆို အဲ့ဒီ VM မှာ install လုပ်ထားတဲ့ OS ရဲ့ kernel ကိုသာ သုံးရတာဖြစ်တဲ့ အတွက် performance အပိုင်းမှာလည်း သိသိသာသာကွာနိုင်ပါတယ်။ အရှေ့မှာ ပြောတဲ့ resource intensive ဖြစ်တယ်ဆိုတာ ဒါကိုပြောတာပါ။ VM တစ်လုံးစီ အတွက် dedicated virtual hardware နဲ့ kernel အတွက် host machine ပေါ်မှာတော်တော်လည်း ဝန်ရှိပါတယ်။
Docker ဟာအဲ့ဒီမှာ တော်တော်လေးကွာသွားပါတယ်။ VM မှာလိုမျိုး virtual disk ကိုဖြတ်ပြီးတဲ့ အခါ latency ရတာမျိုးမရှိပါဘူး။ Docker Engine နဲ့ Linux kernel တို့ စွမ်းဆောင်ရည်ကြောင့် physical hard disk မှာရတဲ့ I/O rate နည်းတူရလာပါတယ်။ နောက်ပြီး Docker ဟာ Linux Host ရဲ့ kernel ကိုသာ အချိုးကျ share သုံးတဲ့အတွက် physical host မှာရနိုင်တဲ့ performance မျိုးကိုရပါတယ်။ ဆိုလိုချင်တာက Docker ကိုသုံးလိုက်ခြင်းအားဖြင့် overhead နည်းသွားတဲ့ အတွက် Docker application container ဟာ VM ထက် performance ပိုင်းမှာ အကျိုးများပါတယ်။ Libraries file တွေ binary file တွေနဲ့ dependencies မှာလည်း VM တုန်းကလိုမျိုး Guest OS level အထဲသွားပြီး လိုတိုးပိုလျှော့ လုပ်စရာမလိုတော့ပဲ ကိုယ်သုံးမယ့် Docker container ပေါ်မှာ မူတည်ပြီးတော့ ကိုယ့်စိတ်ကြိုက် libs/bins/denpendencies တွေကို အဆင်ပြေသလိုယူသုံးသွားလို့ရပါတယ်။
နောက်တစ်ခုက physical servers တွေကနေပြီး VMs အသွင်ပြောင်းလိုက်တုန်းရတဲ့ အကျိုးအမြတ်မျိုးလည်း VMs ကနေ Docker container အသွင်ပြောင်းလိုက်တဲ့ အခါမှာလည်းရပါတယ်။ အဲ့ဒါဘာလဲဆိုတော့ Squeezability တက်လာပါတယ်။ ဥပမာ physical servers တွေအသုံးပြုတုန်းက application တစ်ခုအတွက် dedicated physical server တစ်လုံး setup လုပ်ရပါတယ်။ ထားပါတော့ MySQL အတွက် MySQL server ဆိုပြီးတော့ထားရပါတယ်။ Load များလို့ ထပ်ပြီးတော့ နောက်ထပ် server တွေ ထည့်ချင်ရင် အလုပ်ကများပါပြီ။ ဒါကိုကြည့်မယ်ဆိုရင် scalable သိပ်မဖြစ်ခဲ့ပါဘူး။ Power consumption များလို့ energy efficient မဖြစ်ဘူးလို့လည်းဆိုရမှာပါ။ VM တွေဖြစ်လာတော့ physical hypervisor host တစ်ခုပေါ်မှာ VM အလုံးရေ အများကြီးကို squeeze လုပ်လိုက်ပြီးတော့ တင်လို့ရလာပါတယ်။ Scalability လည်း အများကြီးတက်လာပါတယ်။ Downtime လည်းနည်းသွားပါတယ်။ Energy efficient လည်းပိုဖြစ်လာပါတယ်။ ကဲ… Docker containers တွေ ကိုသုံးလိုက်ခြင်းအားဖြင့် ရနိုင်တဲ့ အကျိုးအမြတ်တွေက ပြောပြစရာတောင် မလိုတော့ပါဘူး။ Docker ကို သုံးခြင်းအားဖြင့် application တစ်ခုကို deploy လုပ်ဖို့ လိုအပ်တဲ့ platform ရှိမယ်ဆိုရင် ပိုပြီးတော့ မြန်လည်းမြန် လွယ်လည်းလွယ်သွားပါတော့တယ်။ အဲ့ဒါကြောင့်လည်း Docker ဟာ အနာဂတ်အတွက် တွင်တွင်ကျယ်ကျယ် အသုံးဝင်လာ အသုံးပြုလာမယ့် နည်းပညာတစ်ခုဖြစ်လာလိမ့်မယ်လို့ စာရေးသူထင်ပါတယ်။
Docker ကို စပြီးအသုံးပြုတော့မယ်ဆို ပါဝင်အစိတ်အပိုင်းလေးတွေကို သိထားရင်တော့ ပိုကောင်းပါတယ်။ အဲ့ဒါမှ မဟုတ်ရင်တော့ video tutorial တွေတော့လိုက်လုပ်လို့ ရပါတယ်၊ သို့သော် ကိုယ်က ဘယ်အပိုင်းကို download ဆွဲပြီးတော့၊ ဘယ်အပိုင်းကို တော့ဖြင့် run လိုက်တယ်ဆိုတာကို မသိပဲနဲ့ မျက်စိတော့ နည်းနည်း လည်နိုင်ပါတယ်။ ဒါ့အပြင် Docker ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာလည်း ရှင်းရှင်းလင်းလင်း သိသွားအောင်လို့လဲ ရည်ရွယ်ပါတယ်။ အဲဒီတော့ အစိတ်အပိုင်းလေးနဲ့ သူ့ရဲ့ အခေါ်အဝေါ်လေးတွေတော့ သိထားရအောင် နည်းနည်းလေး ဆွေးနွေးကြည့်လိုက်ရအောင်။
ဒီမှာ ၂ ပိုင်းရှိပါတယ်။ Docker client ကတစ်ခု၊ Docker Daemon ကတစ်ခု ပါ။ Docker client လို့ ဆိုတဲ့နေရာမှာ တော့ရှင်းပါတယ်။ Docker ကိုအသုံးပြုဖို့ User Interface တစ်ခုလိုပါတယ်။ အဲ့ဒီ UI က CLI လည်းဖြစ်နိုင်သလို၊ GUI လည်းဖြစ်နိုင်ပါတယ်။ Official အနေနဲ့တော့ Docker ဟာ CLI သို့မဟုတ် REST API တစ်ခုကို default အနေနဲ့ ပေးပါတယ်။ Docker command တွေဟာလည်း self-descriptive ဖြစ်လို့ သူ့ဟာနဲ့သူ ရှင်းပါတယ်။ ဆိုပါတော့ docker run က docker container တစ်ခုကို run လုပ်ဖို့ပါ။ docker pull ဆိုတာ docker image ကို Docker Hub ပေါ်ကနေ ဆွဲယူလိုက်ဖို့ပါ။ docker command တော်တော်များများက docker <verb> ဆိုတဲ့ ပုံစံမျိုးနဲ့ တည်ဆောက်ထားပါတယ်။ Git ကို သုံးတဲ့လူတိုင်း သိပါတယ်။ အဲ့ဒါမျိုး Git မှာလည်း သုံးတယ်ဆိုတာကို။ Docker ဟာလည်း Git ရဲ့ ရိုးရှင်းတဲ့ command structure ကို ယူသုံးတဲ့ ပုံရပါတယ်။ ကိုယ်က GUI သုံးချင်တယ်ဆိုရင်လည်း Kitematic တို့ ၊ Portainer တို့လို GUI tool တွေရှိပါတယ်။ သို့သော် စာရေးသူရဲ့ တကိုယ်ရေ အမြင်ကတော့ CLI ကိုသာ ဦးစားပေးပြီးတော့ သုံးသင့်ပါတယ်။ Docker လိုမျိုး Linux ကမ္ဘာက နည်းပညာတစ်ခုကို ကိုယ်ကအသုံးပြုနေတဲ့နောက်တော့ CLI လို UI နဲ့ ကိုယ်က အကျွမ်းဝင် သင့်ပါတယ်။ Linux ကမ္ဘာမှာ CLI command တွေကသာ အလုပ်ဖြစ်ပြီးတော့ GUI tool တွေဟာ တနည်းနည်းနဲ့တော့ broken ဖြစ်တတ်တဲ့ သဘောရှိပါတယ်။ အဲ့ဒီတော့ နောက်ပိုင်းမှာ Docker အကြောင်းဆက်ရေးဖြစ်တဲ့အခါမှာ CLI command တွေကိုသာ ထည့်သွင်း ရှင်းပြသွားမှာဖြစ်ပါတယ်။ မူရင်းဆိုလိုရင်းက Docker client ဆိုတာ Docker ရဲ့ management UI လို့ပြောချင်တာပါ။
နောက်တစ်ပိုင်းက Docker daemon ပါ။ Linux မှာ daemon ဆိုတာပြောလိုက်ရင်သိပါပြီ။ Daemon ဆိုတာ process ကိုပြောတာပါ။ နောက်တစ်ခုသိထားရမှာက Docker daemon ကို တချို့က Docker engine လို့လည်း သမုတ်ကြပါတယ်။ Linux ကမ္ဘာမှာတော့ background မှာ daemon တွေ active ဖြစ်မှသာ ကိုယ်သုံးချင်တဲ့ program ကိုအသုံးပြုနိုင်ပါတယ်။ ဒီလိုပါပဲ… Docker ကို အသုံးပြုဖို့ Docker engine အရင် run ရပါတယ်။ အဲ့ဒါမှသာ ကိုယ်က Docker client မှာ စပြီးတော့ command တွေရိုက်ထည့်ပြီးတော့ အသုံးပြုနိုင်မှာပါ။ Docker ကို install လုပ်ပြီဆိုတာနဲ့ Docker client နဲ့ daemon က တပေါင်းတည်း ပါလာတဲ့ အတွက် သီးခြား သပ်သပ် ထပ်ပြီးတော့ install လုပ်စရာမလိုပါဘူး။ တခါတလေလည်း production မှာသုံးတဲ့ အခါ Docker Client နဲ့ Docker Engine ကိုမတူတဲ့ host ပေါ်မှာ ထားပြီးတော့ run တတ်ကြပါတယ်။ ပုံမှန် Docker ကို ကိုယ်ရဲ့ စက်မှာ တင်ပြီးတော့ဖို့ install လုပ်တဲ့ အခါမှာတော့ Docker client နဲ့ Docker engine ဟာ တစ်ပေါင်းတည်းပါလာပါတယ်။
အရှေ့တပိုင်းမှာ ပြောသလိုပဲ… conventional container နည်းပညာ ကနေ Docker နည်းပညာ ကွာခြားချက်က Docker image ဆိုတဲ့ missing piece ကို အချိုးကျကျ အသုံးချပြီးတော့ စမ်းသစ်လိုက်တာပါပဲ။ Docker images ဆိုတာကတော့ ကိုယ်လိုချင်တဲ့အတိုင်းတည်ဆောက်ထားတဲ့ template တစ်ခုပါပဲ။ ဆိုပါတော့ ကိုယ်က Docker image တစ်ခု build လုပ်တဲ့အခါမှာ Ubuntu 16.04 ကို base image အနေနဲ့ယူထားပြီးတော့၊ အဲ့ဒီပေါ်ကနေမှ Nginx ဆိုတဲ့ web server ကို ပေါင်းထည့်လိုက်တယ်ဆိုကြပါတော့။ အဲ့ဒီထိကို Docker image အနေနဲ့ သိမ်းဆည်းထားလို့ ရပါတယ်။ အနည်းဆုံးတော့ template တစ်ခုရပြီးတော့ နောက်အခါကိုယ်က အဲ့ဒီ Docker image ပေါ်မှာကိုယ်ကြိုက်တဲ့ Nginx ရဲ့ add-on feature တွေကိုထပ်ပေါင်းထည့်ပြီးတော့ ကိုယ်လိုသလောက် containers တွေကို တည်ဆောက်လို့ရပါတယ်။ အဲ့ဒီတော့ container တစ်ခုကို အကြိမ်ကြိမ် ပြန်လည်တည်ဆောက်ဖို့မလိုတော့ပါဘူး။ ဒီတစ်ခုကတော့ Docker ရဲ့ သိသိသာသာ အားသာချက်တစ်ခုပါ။ Docker images ဆိုတဲ့ template တွေရှိလာတဲ့အတွက် အဲ့ဒီ image တွေကို Docker Eocsystem ထဲမှာ reuse သို့မဟုတ် recycle လုပ်ဖို့ အတွက် platform တစ်ခုလိုအပ်လာပါတယ်။ Docker image တွေတော့ ရှိပါရဲ့ တခြားလူတွေ ပြန်သုံးချင်ရင် ပြန် share ရတဲ့ အခါ ပုံစံအမျိုးမျိုးနဲ့ share ရင် ပြဿနာရှိနိုင်ပါတယ်။ ဒါမျိုးမဖြစ်အောင်လို့ Docker ဟာ အစိတ်အပိုင်းနောက်တစ်ခု ထပ်ပြီးတော့ ထည့်ပေါင်းရပါတယ်။ အဲ့ဒီ အစိတ်အပိုင်းကတော့ Docker registries ပါ။
Docker registries ဆိုတာ နားလည်ဖို့ က သိပ်မခက်ပါဘူး။ GitHub ဆိုတာကို သိရင် Docker registries ဆိုတာကို ချက်ချင်းသိပါတယ်။ အလုပ်လုပ်ပုံလည်း တပုံစံတည်းပါ။ Public domain မှာ အသုံးပြုတဲ့ Docker registry ကိုတော့ Docker Hub လို့ ခေါ်ကြပါတယ်။ Docker registries မှာ ကိုယ့် ကုမ္ပဏီအတွက် သီးသန့်သုံးချင်တယ်ဆိုရင် private လုပ်လို့ရပါတယ်။ ဒါမှမဟုတ်ပဲ access level ပေါ်မှာ အခြေခံထားပြီးတော့ ရှိပြီးသား registry ကို ထိမ်းချုပ်နိုင်တဲ့ restricted လုပ်ချင်လည်း လုပ်လို့ရပါတယ်။ ရှင်းရှင်းပြောရရင် Docker registries ဆိုတာ Docker images တွေကို သိမ်းဆည်းပြီး၊ ပြန်လည် မျှဝေလို့ရတဲ့ cloud based repository လို့ပဲ ဆိုကြပါတော့။ Docker registries တွေရှိလို့ build နဲ့ deployment process မှာ အချိန်တော်တော်လေးကို save ဖြစ်သွားပါတယ်။ အဲ့ဒီတော့… Docker registries ဟာ Docker images ကို ဖန်တီးပြီးနောက် ဆင့်ပွားဖန်တီးလိုက်ရတဲ့ repository တစ်ခုပါ။ Docker client၊ Docker daemon နဲ့ Docker registries တွေအလုပ်လုပ်ပုံဟာ GitHub နဲ့ Git client အလုပ်လုပ်ပုံနဲ့ တော်တော်လေး ဆင်တူပါတယ်။ တူတယ်လို့ပဲဆိုကြပါတော့။ နောက်ပိုင်းမှာ Docker Hub လို့သုံးတဲ့အခါမှာ စာရေးသူဟာ public မှာ သုံးဖို့အတွက် လုပ်ထားတဲ့ Docker registry ကို ဆိုလိုရင်းဖြစ်တယ်ဆိုတာကို သိစေချင်ပါတယ်။
ဟုတ်ပြီ… ပြောသွားတဲ့ အစိတ်အပိုင်း တွေတော်တော်လည်းစုံသွားပြီ။ နောက်ဆုံးတစ်ခုပဲ ပြောစရာရှိတော့ တယ်။ အဲ့ဒါ Docker containers ဆိုတဲ့ အစိတ်အပိုင်းပါ။ Docker container ဆိုတာ အရှေ့မှာလည်း စကားစပ်လို့ ပြောဘူးပါတယ်။ Docker container ဟာ application container အမျိုးအစား တစ်ခုဖြစ်ပါတယ်။ ထပ်ပြီးတော့ ပြောပါ့မယ်… container ဆိုတာ VM မဟုတ်ပါဘူး။ အထက်မှာ ဘာကွာခြားချက်တွေရှိလည်း ဆိုတာ ထိုက်သင့်သလောက် ဆွေးနွေးပြီးသွားပါပြီ။ container ကို run တဲ့အခါမှာ လိုအပ်တဲ့ base image နဲ့ ထပ်ပေါင်းထည့်ထားတဲ့ bins/libs တွေပေါင်းပြီး isolated လည်းလုပ်ထား၊ တခြား cgroups နဲ့ namespaces တွေပေါ်မှာ depend မလုပ်တဲ့ lightweight အထုပ်လေးတစ်ခုပါ။ VM လိုဘာ virtual hardware နဲ့ guest OS တခုလုံး install လုပ်စရာမလိုပါဘူး။ နောက်အပိုင်းတွေမှာ Docker containers တွေကို Dockerfile နဲ့ ဘယ်လိုတည်ဆောက်သလဲဆိုတာ ရှင်းတန်သလောက် ဆက်ရှင်းပါ့မယ်။ ဒါတွေကတော့ Docker သုံးတော့မယ်ဆိုရင်သိထားသင့်တဲ့ အစိတ်အပိုင်းလေးတွေပါပဲ။ အခု ရှင်းရှင်းလင်းလင်း သိထားတော့ နောက်ပိုင်း လက်တွေကို ရှင်းတဲ့အခါမှာ မရှုပ်တော့ဘူးလို့ယူဆပါတယ်။
Docker ရဲ့ အစိတ်အပိုင်းလေးတွေကိုတော့ သိပါပြီ။ Docker ဟာ အဲ့ဒီ အစိတ်အပိုင်းတွေကို အသုံးချပြီးတော့ ဘယ်လို အလုပ်လုပ်သလဲ ဆိုတာလည်း အကြမ်းအားဖြင့်တော့ သိဖို့လိုပြန်ပါတယ်။ Docker ဟာ client-server architecture တစ်ခုပါ။ အောက်မှာပြထားတဲ့ ပုံအတိုင်း Docker client ကနေပြီးတော့ Docker command တွေကိုရိုက်ထည့်လိုက်တဲ့အခါမှာ Docker engine ဟာ လိုအပ်တဲ့ လုပ်ဆောင်ချက်တွေကို လုပ်ပါတယ်။ ပုံထဲမှာပြထားတဲ့ အတိုင်း Docker client ရဲ့ CLI မှာ docker command ဖြစ်တဲ့ docker pull တို့ docker runတို့ ရိုက်ထည့်လိုက်တဲ့အခါမှာ Docker engine က Docker containers တွေကို ဘယ်လို လုပ်ဆောင်ချက်တွေလုပ်စေဆိုပြီး drive လုပ်ပါတယ်။ ဥပမာ docker run -d -it centos ကို Docker client ရဲ့ CLI မှာရိုက်ထည့်လိုက်ရင် Docker engine ဟာ သူ့ရဲ့ host ပေါ်မှာ အဲ့ဒီ centos ဆို Docker image ရှိမရှိကို အရင်ကြည့်လိုက်ပါတယ်။ ရှိတယ် ဆိုရင် အဲ့ဒီ image ကိုယူသုံးပြီးတော့ Docker container တစ်ခုကိုတည်ဆောက်လိုက်ပါတယ်။ -d ဆိုတဲ့ parameter ဟာ daemon အနေနဲ့ background မှာ runလို့ဆိုပြီးတော့၊ -it ဆိုတာကတော့ interactive terminal တခုပေးဖို့ကို ပြောတာပါ။ တကယ်လို့များ host ပေါ်မှာ centos ဆိုတဲ့ image မရှိဘူးဆိုရင်တော့ Docker engine ဟာသူနဲ့ ချိတ်ဆက်ထားတဲ့ Docker registry ကနေ နောက်ဆုံး up-to-date ဖြစ်တဲ့ Docker centos image ကို pull လုပ်ပါတယ်။ ပြီးတော့မှ အဲ့ဒီ Docker container ကို ဖော်ပြပြီးဖြစ်တဲ့ parameter တွေနဲ့ run ပါတယ်။ ကိုယ်က ဘယ် Docker registry နဲ့ မချိတ်ထားရင်တော့ Docker engine ဟာ Docker Hub ကို default registry အနေနဲ့ အသုံးပြုပါတယ်။ ဒါတွေအားလုံးဟာ Docker engine ရဲ့ စွမ်းဆောင်ရည်တွေပဲဖြစ်ပါတယ်။ Usability မှာ အဲ့ဒီလို အသုံးပြုရတာရိုးရှင်းတဲ့အတွက် အခက်အခဲမရှိပဲနဲ့ adopt လုပ်နိုင်ပါတယ်။
နောက်တစ်ချက်က Docker container တစ်ခုချင်းစီရှိ တည်ဆောက်ထားပုံပါ။ Docker containers တွေဟာ immutable ဖြစ်တယ်လို့ ပြောပါတယ်။ ဘာကိုဆိုလိုသလဲ ဆိုရင် Docker container ကို run ထားပြီးရင် သူ့ကိုအခြေခံပြီး တည်ဆောက်ထားတဲ့ base image ကို real-time မှာ သွားပြီး အပြောင်းအလဲ လုပ်ချင်လို့မရပါဘူး။ base image အတွက် update ရှိလို့ ကိုယ့် container မှာ apply လုပ်ချင်ရင် Docker image နောက်တစ်ခုကို အစကနေပြန်ပြီးတော့ build လုပ်ရပါတယ်။ အဲ့လို immutability ရှိတဲ့အတွက် ရလာတဲ့ အကျိုးအမြတ်တွေကတော့ image တွေကို version control လုပ်တဲ့အခါမှာ ပိုပြီးတော့ ထိရောက်မှုရှိပါတယ်။ နောက်တစ်ခုက updates management အတွက် ပိုပြီးတော့ dependencies တွေနည်းသွားပါတယ်။ ဆိုပါတော့ VM တစ်ခုမှာ ကိုယ်က application သို့မဟုတ် service တစ်ခုထက်ပိုပြီးတော့ run ထားတယ်ဆိုရင်၊ အဲ့ဒီ VM ရဲ့ Guest OS ကို update လုပ်ဖို့လိုတယ်ဆိုရင် run ထားတဲ့ application တွေနဲ့ service တွေ အကုန်လုံးကို သက်ရောက်မူရှိပါတယ်။ update လုပ်လိုက်လို့ အဆင်မပြေလို့ အခပ်မသင့်ရင် VM တစ်ခုလုံးကို recovery လုပ်ရ၊ application တွေအားလုံးကို ပြန်ပြီးတော့ configure လုပ်ရနဲ့ အရမ်းသတိထားရပါတယ်။ Docker container မှာတော့ immutability ရှိတဲ့အတွက် စိတ်ပူစရာ မလိုပါဘူး။ ကိုယ်က host ကို update တဲ့အခါမှာလည်း Docker container ကို တိုက်ရိုက် မှီခိုရတာမျိုးမရှိပါဘူး။ Docker containers တွေဟာ host ကနေလည်း isolated လုပ်ထားတာမို့ တစ်ခုနဲ့ တစ်ခု dependency မရှိပါဘူး။
ဒီလောက်ဆိုရင်တော့ ဒီ အပိုင်းအတွက် လုံလောက်ပြီလို့ထင်ပါတယ်။ နောက် တစ်ပိုင်းမှာတော့ Docker container အပေါ်မှာ လူတွေ အထင်မှား အမြင်မှားနေတဲ့ misconception လေးတွေနဲ့ Docker ကို ကိုယ့်ရဲ့ စက်မှာ ဘယ်လို လက်တွေ့ အသုံးချ စမ်းသပ်ကြည့်မလဲဆိုတာကို ဆက်ချင်ပါတယ်။