အားလုံးမင်္ဂလာပါ! ကျွန်တော့်နာမည် Pavel Agaletsky ပါ။ ကျွန်ုပ်သည် Lamoda ပို့ဆောင်မှုစနစ်အား ဖော်ဆောင်သည့် အဖွဲ့တွင် အဖွဲ့ခေါင်းဆောင်အဖြစ် လုပ်ဆောင်ပါသည်။ 2018 တွင်၊ HighLoad++ ကွန်ဖရင့်တွင် ကျွန်ုပ်ပြောခဲ့ပြီး၊ ယနေ့ ကျွန်ုပ်၏အစီရင်ခံစာ၏ စာသားမှတ်တမ်းကို တင်ပြလိုပါသည်။

ကျွန်ုပ်၏ ခေါင်းစဉ်သည် မတူညီသော ပတ်ဝန်းကျင်များတွင် စနစ်များနှင့် ဝန်ဆောင်မှုများ ဖြန့်ကျက်ရာတွင် ကျွန်ုပ်တို့၏ ကုမ္ပဏီ၏ အတွေ့အကြုံအတွက် ရည်ရွယ်ပါသည်။ ကျွန်ုပ်တို့၏ သမိုင်းမတင်မီအချိန်များမှစတင်၍ စနစ်အားလုံးကို သာမန် virtual ဆာဗာများသို့ ဖြန့်ကျက်လိုက်သောအခါ Nomad မှ Kubernetes တွင် ဖြန့်ကျက်ခြင်းသို့ တဖြည်းဖြည်း ကူးပြောင်းသွားခြင်းဖြင့် အဆုံးသတ်ပါသည်။ အဲဒါကို ဘာကြောင့်လုပ်ခဲ့သလဲ နဲ့ လုပ်ငန်းစဉ်မှာ ဘယ်လိုအခက်အခဲတွေရှိခဲ့လဲ ပြောပြမယ်။

အပလီကေးရှင်းများကို VM သို့ ဖြန့်ကျက်နေသည်။

လွန်ခဲ့သော 3 နှစ်က ကုမ္ပဏီ၏ စနစ်များနှင့် ဝန်ဆောင်မှုများအားလုံးကို ပုံမှန် virtual server များပေါ်တွင် ဖြန့်ကျက်ချထားကြောင်းကို စတင်ကြပါစို့။ နည်းပညာအရ၊ ကျွန်ုပ်တို့၏စနစ်များအတွက် ကုဒ်အားလုံးကို jenkins ကိုအသုံးပြု၍ အလိုအလျောက် တပ်ဆင်ခြင်းကိရိယာများကို အသုံးပြု၍ စုစည်းကာ စုစည်းထားခြင်းဖြစ်ပါသည်။ Ansible ကို အသုံးပြု၍ ၎င်းကို ကျွန်ုပ်တို့၏ဗားရှင်းထိန်းချုပ်မှုစနစ်မှ virtual ဆာဗာများထံ ဖြန့်ကျက်ခဲ့သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင်ရှိသော စနစ်တစ်ခုစီကို အနည်းဆုံး ဆာဗာ 2 ခုတွင် ဖြန့်ကျက်ထားပါသည်- ၎င်းတို့ထဲမှ တစ်ခုကို ဦးခေါင်းပေါ်၊ ဒုတိယတစ်ခုသည် အမြီးတွင် ရှိနေသည်။ ဤစနစ်နှစ်ခုသည် ၎င်းတို့၏ ဆက်တင်များ၊ ပါဝါ၊ ဖွဲ့စည်းမှုစသည်ဖြင့် အားလုံးတွင် တစ်ခုနှင့်တစ်ခု လုံးဝတူညီပါသည်။ ၎င်းတို့ကြားရှိ တစ်ခုတည်းသော ခြားနားချက်မှာ ဦးခေါင်းသည် အသုံးပြုသူအသွားအလာကို လက်ခံရရှိခဲ့ပြီး အမြီးသည် သုံးစွဲသူအသွားအလာကို မည်သည့်အခါမျှ မရရှိခဲ့ပေ။

ဘာအတွက်လဲ။

ကျွန်ုပ်တို့၏ အပလီကေးရှင်းအသစ်များကို ဖြန့်ကျက်အသုံးပြုသောအခါ၊ သုံးစွဲသူများအတွက် သိသာထင်ရှားသော အကျိုးဆက်များမရှိဘဲ ချောမွေ့စွာ အသုံးပြုနိုင်စေရန် သေချာစေလိုပါသည်။ Ansible ကို အသုံးပြု၍ နောက်တကြိမ် စုစည်းထားသော ထုတ်ဝေမှုအား အမြီးပိုင်းအထိ လွှင့်တင်ခဲ့ခြင်းကြောင့် ၎င်းကို အောင်မြင်ခဲ့ခြင်းဖြစ်သည်။ ထိုနေရာတွင်၊ ဖြန့်ကျက်မှုတွင် ပါဝင်ပတ်သက်သူများသည် အရာအားလုံး ကောင်းမွန်ကြောင်း သေချာအောင် စစ်ဆေးနိုင်သည်- မက်ထရစ်များ၊ ကဏ္ဍများနှင့် အပလီကေးရှင်းများအားလုံး အလုပ်လုပ်နေပါသည်။ လိုအပ်သော scripts များကို စတင်လိုက်ပါပြီ။ အားလုံးအဆင်ပြေကြောင်း သူတို့ယုံကြည်ပြီးမှသာ ယာဉ်အသွားအလာပြောင်းသွားပါပြီ။ ၎င်းသည် ယခင်က အမြီးပါသော ဆာဗာသို့ စတင်သွားခဲ့သည်။ ယခင်က ကျွန်ုပ်တို့၏ အက်ပ်လီကေးရှင်း၏ ယခင်ဗားရှင်းကို ထားရှိဆဲဖြစ်ပြီး၊ ယခင်က ဦးခေါင်းသည် အသုံးပြုသူအသွားအလာမရှိဘဲ ရှိနေခဲ့သည်။

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

ဤအရာအားလုံးတွင် ကျွန်ုပ်တို့ အဘယ်အကျိုးကျေးဇူးများ တွေ့ခဲ့သနည်း။

1. ပထမဆုံးအနေနဲ့ လုံလောက်ပါပြီ။ အလုပ်ဖြစ်ရုံပါပဲ။ လူအများစုသည် ပုံမှန် virtual ဆာဗာများတွင် အသုံးပြုဖူးကြသောကြောင့် ဤကဲ့သို့ ဖြန့်ကျက်မှုအစီအစဉ် မည်သို့အလုပ်လုပ်သည်ကို လူတိုင်းနားလည်ပါသည်။
2. ဒါက လုံလောက်ပါတယ်။ ယုံကြည်စိတ်ချရသောဖြန့်ကျက်နည်းပညာသည် ရိုးရှင်းသောကြောင့် ကုမ္ပဏီထောင်ပေါင်းများစွာက စမ်းသပ်သည်။ ဤနည်းဖြင့် ဆာဗာသန်းပေါင်းများစွာကို အသုံးချသည်။ တစ်ခုခုကို ချိုးဖျက်ဖို့ ခက်တယ်။
3. နောက်ဆုံးတော့ ကျွန်တော်တို့ ရနိုင်ခဲ့တယ်။ အဏုမြူဗုံး ဖြန့်ကျက်မှု. ဗားရှင်းအဟောင်းနှင့် အသစ်ကြားသိသာထင်ရှားသောအဆင့်သို့ ကူးပြောင်းခြင်းမရှိဘဲ သုံးစွဲသူများအတွက် တပြိုင်နက်တည်း ဖြစ်ပေါ်လာသော ဖြန့်ကျက်မှုများ။

သို့သော် ဤအရာအားလုံးတွင် ချို့ယွင်းချက်များစွာကိုလည်း ကျွန်ုပ်တို့တွေ့ခဲ့ရသည်-

1. ထုတ်လုပ်မှုပတ်ဝန်းကျင်၊ ဖွံ့ဖြိုးတိုးတက်ရေးပတ်ဝန်းကျင်အပြင် အခြားပတ်ဝန်းကျင်များလည်း ရှိသေးသည်။ ဥပမာ qa နှင့် preproduction။ ထိုအချိန်တွင် ကျွန်ုပ်တို့တွင် ဆာဗာများစွာရှိပြီး ဝန်ဆောင်မှု 60 ခန့်ရှိသည်။ ဤအကြောင်းကြောင့် လိုအပ်ပါသည်။ ဝန်ဆောင်မှုတစ်ခုစီအတွက်၊ ၎င်းအတွက် နောက်ဆုံးထွက်ဗားရှင်းကို ထိန်းသိမ်းပါ။ virtual စက်။ ထို့အပြင်၊ သင်သည် စာကြည့်တိုက်များကို အပ်ဒိတ်လုပ်ရန် သို့မဟုတ် မှီခိုမှုအသစ်များကို ထည့်သွင်းလိုပါက၊ ပတ်ဝန်းကျင်အားလုံးတွင် ၎င်းကို လုပ်ဆောင်ရန် လိုအပ်သည်။ devops သည် လိုအပ်သော ပတ်ဝန်းကျင်ဆက်တင်များကို လုပ်ဆောင်သည့်အချိန်နှင့် သင့်အပလီကေးရှင်း၏နောက်ထပ်ဗားရှင်းအသစ်ကို အသုံးချမည့်အချိန်ကို ထပ်တူပြုရန်လည်း လိုအပ်ပါသည်။ ဤအခြေအနေမျိုးတွင်၊ ကျွန်ုပ်တို့၏ပတ်ဝန်းကျင်သည် ပတ်ဝန်းကျင်အားလုံးတွင် အနည်းငယ်ကွဲပြားသွားမည့် အခြေအနေတစ်ခုသို့ တစ်ပြိုင်နက်ရောက်ရှိရန် လွယ်ကူပါသည်။ ဥပမာအားဖြင့်၊ QA ပတ်ဝန်းကျင်တွင် စာကြည့်တိုက်များ၏ ဗားရှင်းအချို့ရှိမည်ဖြစ်ပြီး ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် ပြဿနာများဖြစ်ပေါ်စေမည့် ကွဲပြားသည့်အရာများ ရှိလိမ့်မည်။
2. မှီခိုမှုကို အပ်ဒိတ်လုပ်ရာတွင် ခက်ခဲခြင်း။ သင်၏လျှောက်လွှာ။ အဲဒါက မင်းအပေါ်မှာမမူတည်ဘဲ တခြားအသင်းအပေါ်မှာမူတည်တယ်။ ပြောရရင်၊ ဆာဗာတွေကို ထိန်းသိမ်းတဲ့ devops အဖွဲ့ကနေ။ သင်သည် ၎င်းတို့အား သင့်လျော်သော အလုပ်တစ်ခုနှင့် သင်ပြုလုပ်လိုသည့် အကြောင်းအရာကို ဖော်ပြချက်ပေးရမည်။
3. ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် ၎င်းတို့ထဲမှ ပိုများလာမည်ကို ကျွန်ုပ်တို့ နားလည်ထားသောကြောင့် ကျွန်ုပ်တို့၏ ကြီးမားသော ကြီးမားသော ဝန်ဆောင်ကြီးများကို သီးခြားအသေးစားအဖြစ် ပိုင်းခြားလိုပါသည်။ ထိုအချိန်တွင်၊ ၎င်းတို့ထဲမှ 100 ကျော်ရှိနေပြီဖြစ်သည်။ ဝန်ဆောင်မှုအသစ်တစ်ခုစီအတွက်၊ ထိန်းသိမ်းရန်နှင့် အသုံးပြုရန် လိုအပ်သည့် သီးခြား virtual machine အသစ်တစ်ခုကို ဖန်တီးရန် လိုအပ်ပါသည်။ ထို့အပြင်၊ သင်ကားတစ်စီးတည်းမလိုအပ်ပါ၊ အနည်းဆုံးနှစ်စီး။ ဤအရာအားလုံးကို QA ပတ်ဝန်းကျင်တွင် ပေါင်းထည့်ထားသည်။ ၎င်းသည် ပြဿနာများကို ဖြစ်စေပြီး စနစ်အသစ်များကို တည်ဆောက်ပြီး လုပ်ဆောင်ရန် သင့်အတွက် ပိုမိုခက်ခဲစေသည်။ ရှုပ်ထွေး၊ ဈေးကြီးပြီး ရှည်လျားသော လုပ်ငန်းစဉ်။

ထို့ကြောင့်၊ ပုံမှန် virtual machines များကို အသုံးပြုခြင်းမှ ကျွန်ုပ်တို့၏ application များကို docker container တွင် အသုံးပြုခြင်းသို့ ရွှေ့ရန် ပိုမိုအဆင်ပြေမည်ဟု ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ သင့်တွင် docker ရှိပါက၊ သင်သည် ကွန်တိန်နာကိုတင်ရုံဖြင့် မဆောင်ရွက်နိုင်သောကြောင့် အစုအဖွဲ့တစ်ခုအတွင်း အပလီကေးရှင်းကိုလည်ပတ်နိုင်သည့်စနစ်တစ်ခု လိုအပ်ပါသည်။ အများအားဖြင့် သင်သည် ကွန်တိန်နာ မည်မျှ ရုတ်သိမ်းကြောင်းကို ခြေရာခံရန် အလိုအလျောက် လွှင့်တင်ရန် လိုသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ထိန်းချုပ်မှုစနစ်ကို ရွေးချယ်ရန် လိုအပ်ပါသည်။

ဘယ်ဟာယူလို့ရမလဲ ဆိုတာကို အချိန်အတော်ကြာအောင် စဉ်းစားခဲ့ပါတယ်။ အမှန်မှာ ထိုအချိန်က ပုံမှန် virtual server များပေါ်တွင် ဤဖြန့်ကျက်မှု stack သည် အတန်ငယ် ခေတ်နောက်ကျနေပြီဖြစ်သောကြောင့် ၎င်းတို့တွင် operating system ၏နောက်ဆုံးထွက်ဗားရှင်းများမရှိသောကြောင့်ဖြစ်သည်။ တစ်ချိန်ချိန်တွင်၊ ပံ့ပိုးရန်အလွန်အဆင်ပြေသော FreeBSD ပင်ရှိခဲ့သည်။ Docker သို့ တတ်နိုင်သမျှ မြန်မြန် ပြောင်းရွှေ့ရန် လိုအပ်ကြောင်း ကျွန်ုပ်တို့ နားလည်ပါသည်။ ကျွန်ုပ်တို့၏အဖွဲ့သားများသည် ၎င်းတို့၏လက်ရှိအတွေ့အကြုံကို မတူညီသောဖြေရှင်းနည်းများဖြင့် ကြည့်ရှုပြီး Nomad ကဲ့သို့သော စနစ်တစ်ခုကို ရွေးချယ်ခဲ့သည်။

Nomad သို့ပြောင်းပါ။

Nomad သည် HashiCorp ၏ ထုတ်ကုန်တစ်ခုဖြစ်သည်။ ၎င်းတို့သည် ၎င်းတို့၏ အခြားသော ဖြေရှင်းနည်းများအတွက်လည်း လူသိများသည်။

"ကောင်စစ်ဝန်" ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုအတွက် ကိရိယာတစ်ခုဖြစ်သည်။

"မြေပြင်" - ဖွဲ့စည်းမှုစနစ်ဖြင့် ၎င်းတို့ကို configure လုပ်ခွင့်ပြုသော ဆာဗာများကို စီမံခန့်ခွဲရန် စနစ်တစ်ခု၊ ဟုခေါ်သော infrastructure-as-a-code။

"လေလွင့်" သီးသန့်ဖွဲ့စည်းပုံဖိုင်များမှတစ်ဆင့် virtual machines များကို စက်တွင်း သို့မဟုတ် cloud တွင် အသုံးချနိုင်စေပါသည်။

ထိုအချိန်က Nomad သည် အခြေခံအဆောက်အအုံတစ်ခုလုံးကို မပြောင်းလဲဘဲ လျင်မြန်စွာပြောင်းလဲနိုင်သော ရိုးရှင်းသောဖြေရှင်းချက်တစ်ခုလိုပုံရသည်။ ထို့အပြင်၎င်းသည်သင်ယူရန်အတော်လေးလွယ်ကူသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ၎င်းကို ကျွန်ုပ်တို့၏ကွန်တိန်နာအတွက် စစ်ထုတ်သည့်စနစ်အဖြစ် ရွေးချယ်ခဲ့သည်။

သင့်စနစ်ကို Nomad သို့ အသုံးချရန် သင်ဘာလိုအပ်သနည်း။

1. ပထမဆုံးအနေနဲ့ သင်လိုအပ်ပါတယ်။ docker ပုံ သင်၏လျှောက်လွှာ။ ၎င်းကိုတည်ဆောက်ပြီး docker image repository တွင်ထားရန်လိုအပ်သည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ဤအရာသည် အမျိုးမျိုးသော ရှေးဟောင်းပစ္စည်းများကို ၎င်းထဲသို့ တွန်းပို့နိုင်သည့် စနစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် မော်ကွန်းတိုက်များ၊ docker ပုံများ၊ ရေးဖွဲ့သူ PHP ပက်ကေ့ခ်ျများ၊ NPM ပက်ကေ့ဂျ်များနှင့် အခြားအရာများကို သိမ်းဆည်းနိုင်သည်။
2. လိုအပ်သည်များလည်းရှိသည်။ configuration ဖိုင်Nomad သည် မည်သည့်နေရာ၊ မည်သည့်ပမာဏတွင် သင်အသုံးပြုလိုသည်ကို ပြောပြပါမည်။

Nomad အကြောင်းပြောသောအခါ၊ ၎င်းသည် HCL ဘာသာစကားကို ၎င်း၏ အချက်အလက်ဖိုင်ဖော်မတ်အဖြစ် အသုံးပြုသည်။ HashiCorp ဖွဲ့စည်းမှုဘာသာစကား. ၎င်းသည် သင့်ဝန်ဆောင်မှုကို Nomad ဝေါဟာရများဖြင့် ဖော်ပြနိုင်စေမည့် Yaml ၏ superset တစ်ခုဖြစ်သည်။

၎င်းသည် သင်အသုံးပြုလိုသည့် ကွန်တိန်နာ မည်မျှရှိသည်ကို ပြောကြားနိုင်စေကာ၊ အသုံးချမှုအတွင်း ၎င်းတို့ထံ အမျိုးမျိုးသော ဘောင်များကို ဖြတ်သန်းရန် ပုံများမှ ခွင့်ပြုသည်။ ထို့ကြောင့် သင်သည် ဤဖိုင်ကို Nomad သို့ ကျွေးမွေးပြီး ၎င်းသည် ၎င်းနှင့်အညီ ကွန်တိန်နာများကို ထုတ်လုပ်မှုသို့ စတင်စေသည်။

ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ဝန်ဆောင်မှုတစ်ခုစီအတွက် လုံးဝတူညီသော HCL ဖိုင်များကိုရေးရုံမျှဖြင့် ဝန်ဆောင်မှုများစွာရှိပြီး တစ်ခါတစ်ရံတွင် ၎င်းတို့ကို သင်မွမ်းမံလိုသောကြောင့် အလွန်အဆင်ပြေမည်မဟုတ်ကြောင်း ကျွန်ုပ်တို့သဘောပေါက်ပါသည်။ ဝန်ဆောင်မှုတစ်ခုသည် ဥပမာတစ်ခုတွင်မဟုတ်ဘဲ မတူညီသော အမျိုးမျိုးသောဝန်ဆောင်မှုများတွင် အသုံးပြုခြင်းဖြစ်ပေသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင်ရှိသော ထုတ်လုပ်မှုစနစ်တစ်ခုသည် ထုတ်လုပ်မှုတွင် သာဓက 100 ကျော်ရှိသည်။ ၎င်းတို့သည် တူညီသောပုံများမှ လုပ်ဆောင်နေသော်လည်း ဖွဲ့စည်းမှုဆက်တင်များနှင့် ဖွဲ့စည်းမှုဖိုင်များတွင် ကွဲပြားသည်။

ထို့ကြောင့်၊ ဘုံသိုလှောင်မှုတစ်ခုတွင် ဖြန့်ကျက်ခြင်းအတွက် ကျွန်ုပ်တို့၏ configuration ဖိုင်များအားလုံးကို သိမ်းဆည်းရန် အဆင်ပြေမည်ဟု ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ ဤနည်းဖြင့် ၎င်းတို့ကို မြင်နိုင်သည်- ၎င်းတို့ကို ထိန်းသိမ်းရန် လွယ်ကူပြီး ကျွန်ုပ်တို့တွင် မည်သည့်စနစ်များ ရှိသည်ကို ကျွန်ုပ်တို့ မြင်တွေ့နိုင်သည်။ လိုအပ်ပါက တစ်ခုခုကို အပ်ဒိတ်လုပ်ရန် သို့မဟုတ် ပြောင်းလဲရန်လည်း လွယ်ကူပါသည်။ စနစ်အသစ်တစ်ခုထည့်ခြင်းသည်လည်း မခက်ခဲပါ - သင်သည် လမ်းညွှန်အသစ်အတွင်းတွင် ဖွဲ့စည်းမှုဖိုင်တစ်ခုကို ဖန်တီးရန်သာလိုသည်။ ၎င်း၏အတွင်းတွင် အောက်ပါဖိုင်များပါရှိသည်- service.hcl၊ ကျွန်ုပ်တို့၏ဝန်ဆောင်မှု၏ဖော်ပြချက်ပါရှိသော၊ နှင့် ဤဝန်ဆောင်မှုကို ထုတ်လုပ်ရာတွင် ဖြန့်ကျက်ချထားခြင်းကို ခွင့်ပြုထားသည့် အချို့သော env ဖိုင်များပါရှိသည်။

သို့သော်၊ ကျွန်ုပ်တို့၏စနစ်အချို့ကို ကော်ပီတစ်ခုတည်းတွင်မဟုတ်ဘဲ အများအပြားထုတ်လုပ်ရာတွင် တစ်ကြိမ်တည်းတွင် အသုံးပြုထားသည်။ ထို့ကြောင့်၊ configs များကို ၎င်းတို့၏ သန့်စင်သောပုံစံတွင်မဟုတ်ဘဲ ၎င်းတို့၏ ပုံစံခွက်ပုံစံဖြင့် သိမ်းဆည်းရန် အဆင်ပြေမည်ဟု ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ ပြီးတော့ ငါတို့ ရွေးတယ်။ ဂျင်း ၂. ဤဖော်မတ်တွင်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကိုယ်တိုင်နှင့် ၎င်းအတွက် လိုအပ်သော env ဖိုင်နှစ်ခုလုံးကို သိမ်းဆည်းထားသည်။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ပရောဂျက်အားလုံးအတွက် အသုံးများသည့် ဖြန့်ကျက်မှု script ကို သိုလှောင်ရုံတွင် ထားရှိထားပြီး၊ သင့်ဝန်ဆောင်မှုကို ထုတ်လုပ်ခြင်း၊ လိုချင်သောပတ်ဝန်းကျင်သို့ လိုချင်သောပစ်မှတ်သို့ စတင်အသုံးပြုနိုင်စေရန်နှင့် အသုံးချနိုင်စေပါသည်။ ကျွန်ုပ်တို့၏ HCL config ကို template အဖြစ်ပြောင်းသောအခါတွင်၊ ယခင်က ပုံမှန် Nomad config ဖြစ်ခဲ့သည့် HCL ဖိုင်သည် ဤကိစ္စတွင် အနည်းငယ်ကွဲပြားသွားပါသည်။

ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် env ဖိုင်များ သို့မဟုတ် အခြားရင်းမြစ်များမှ ယူဆောင်သွားသော ပြောင်းလဲနိုင်သော ထည့်သွင်းမှုများဖြင့် အချို့သော config တည်နေရာ variable များကို အစားထိုးခဲ့သည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် HCL ဖိုင်များကို ဒိုင်းနမစ်ဖြင့် စုဆောင်းရန် အခွင့်အရေးရခဲ့သည်၊ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် သာမန်မပြောင်းလဲနိုင်သော ထည့်သွင်းမှုများကိုသာ အသုံးပြုနိုင်သည်။ jinja သည် loops နှင့် condition များကို ပံ့ပိုးပေးသောကြောင့်၊ သင်သည် သင်၏ application အတိအကျကို နေရာချထားမှုအပေါ် မူတည်၍ ပြောင်းလဲနိုင်သော configuration files များကို ဖန်တီးနိုင်သည်။

ဥပမာအားဖြင့်၊ သင်သည် သင်၏ဝန်ဆောင်မှုကို မထုတ်လုပ်မီနှင့် ထုတ်လုပ်ရေးတွင် အသုံးချလိုသည်။ ထုတ်လုပ်ရေးမတိုင်မီတွင် သင်သည် cron scripts များကိုမလုပ်ဆောင်ချင်သော်လည်း ၎င်းသည်အလုပ်လုပ်ကြောင်းသေချာစေရန် သီးခြားဒိုမိန်းတွင် ဝန်ဆောင်မှုကိုမြင်လိုသည်ဆိုကြပါစို့။ ဝန်ဆောင်မှုကို အသုံးပြုသူတိုင်းအတွက်၊ လုပ်ငန်းစဉ်သည် အလွန်ရိုးရှင်းပြီး ပွင့်လင်းမြင်သာမှုရှိသည်။ သင်လုပ်ဆောင်ရန် လိုအပ်သည်မှာ deploy.sh ဖိုင်ကို execute ဖြစ်ပြီး သင်အသုံးပြုလိုသော ဝန်ဆောင်မှုနှင့် မည်သည့်ပစ်မှတ်ကို သတ်မှတ်ပါ။ ဥပမာအားဖြင့်၊ သင်သည် ရုရှား၊ ဘီလာရုစ် သို့မဟုတ် ကာဇက်စတန်တွင် အချို့သောစနစ်တစ်ခုကို အသုံးချလိုသည်။ ၎င်းကိုပြုလုပ်ရန်၊ ကန့်သတ်ချက်များထဲမှတစ်ခုကိုပြောင်းပါ၊ မှန်ကန်သောဖွဲ့စည်းမှုဖိုင်ကိုသင်ရလိမ့်မည်။

Nomad ဝန်ဆောင်မှုကို သင့်အစုအဝေးတွင် ဖြန့်ကျက်ထားပြီးသောအခါ၊ ၎င်းသည် ဤကဲ့သို့ ဖြစ်ပုံရသည်။

ပထမဦးစွာ user traffic အားလုံးကို ကိုင်တွယ်ပေးမယ့် external load balancer တစ်မျိုးမျိုး လိုအပ်ပါတယ်။ ၎င်းသည် Consul နှင့် အလုပ်လုပ်ပြီး မည်သည့် node ပေါ်တွင်၊ မည်သည့်နေရာတွင် သင်ယူမည်ဖြစ်သည်။ IP လိပ်စာ သတ်မှတ်ထားသော domain name နှင့် ကိုက်ညီသော သီးခြားဝန်ဆောင်မှုတစ်ခုကို တွေ့ရှိရသည်။ Consul ရှိ ဝန်ဆောင်မှုများသည် Nomad ကိုယ်တိုင်မှ ဆင်းသက်လာသည်။ ၎င်းတို့သည် တူညီသောကုမ္ပဏီမှ ထုတ်ကုန်များဖြစ်သောကြောင့် ၎င်းတို့သည် ကောင်းစွာပေါင်းစပ်ထားသည်။ Nomad သည် Consul အတွင်း စတင်လိုက်သော ဝန်ဆောင်မှုအားလုံးကို အလိုအလျောက် မှတ်ပုံတင်နိုင်သည်ဟု ပြောနိုင်ပါသည်။

သင်၏ front-end load balancer မှ မည်သည့်ဝန်ဆောင်မှုသို့ traffic ပေးပို့ရမည်ကို သိရှိပြီးသည်နှင့် ၎င်းသည် ၎င်းကို သင့်အပလီကေးရှင်းနှင့်ကိုက်ညီသော သင့်လျော်သောကွန်တိန်နာ သို့မဟုတ် ကွန်တိန်နာများစွာသို့ ပေးပို့ပါသည်။ သဘာဝအတိုင်း၊ ဘေးကင်းရေးကိုလည်း စဉ်းစားဖို့ လိုပါတယ်။ ဝန်ဆောင်မှုအားလုံးသည် ကွန်တိန်နာအတွင်းရှိ တူညီသော virtual machines များတွင် အလုပ်လုပ်သော်လည်း၊ ၎င်းသည် များသောအားဖြင့် အခြားမည်သည့်ဝန်ဆောင်မှုမှ အခမဲ့ဝင်ရောက်ခွင့်ကို တားဆီးရန် လိုအပ်ပါသည်။ ဒါကို အပိုင်းခွဲခြင်းအားဖြင့် ကျွန်တော်တို့ အောင်မြင်ခဲ့ပါတယ်။ ဝန်ဆောင်မှုတစ်ခုစီကို ၎င်း၏ကိုယ်ပိုင် virtual network တွင် စတင်လုပ်ဆောင်ခဲ့ပြီး၊ အခြားစနစ်များနှင့် ဝန်ဆောင်မှုများသို့ ဝင်ရောက်ခွင့်/ငြင်းပယ်ခြင်းအတွက် လမ်းကြောင်းစည်းမျဉ်းများနှင့် စည်းမျဉ်းများကို သတ်မှတ်ပေးထားသည်။ ၎င်းတို့သည် ဤအစုအဝေးအတွင်းတွင်ရော ၎င်းအပြင်ဘက်တွင်ပါ တည်ရှိနိုင်သည်။ ဥပမာအားဖြင့်၊ သင်သည် ဝန်ဆောင်မှုတစ်ခုအား သီးခြားဒေတာဘေ့စ်တစ်ခုသို့ ချိတ်ဆက်ခြင်းမှ တားဆီးလိုပါက၊ ၎င်းကို network-level segmentation မှတဆင့် လုပ်ဆောင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ အမှားကြောင့်ပင်၊ သင်သည် စမ်းသပ်မှုပတ်ဝန်းကျင်မှ သင်၏ထုတ်လုပ်မှုဒေတာဘေ့စ်သို့ မတော်တဆချိတ်ဆက်၍မရပါ။

အကူးအပြောင်းက လူသားအရင်းအမြစ်နဲ့ ပတ်သက်ပြီး ကျွန်တော်တို့ကို ဘယ်လောက်ကုန်ကျခဲ့လဲ။

ကုမ္ပဏီတစ်ခုလုံး၏ Nomad သို့ ကူးပြောင်းမှုသည် ခန့်မှန်းခြေအားဖြင့် 5-6 လကြာသည်။ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတစ်ခုချင်းအလိုက် ဝန်ဆောင်မှုတစ်ခုသို့ ပြောင်းရွှေ့သော်လည်း အရှိန်အဟုန်ဖြင့် ရွေ့လျားခဲ့ပါသည်။ အဖွဲ့တစ်ဖွဲ့စီသည် ဝန်ဆောင်မှုများအတွက် ၎င်းတို့၏ကိုယ်ပိုင်ကွန်တိန်နာများကို ဖန်တီးရမည်ဖြစ်သည်။

အဖွဲ့တစ်ဖွဲ့ချင်းစီသည် ၎င်းတို့၏ စနစ်များ၏ docker ပုံများကို လွတ်လပ်စွာ လုပ်ဆောင်ရန် တာဝန်ရှိသည်ဟူသော ချဉ်းကပ်မှုကို ကျွန်ုပ်တို့ လက်ခံကျင့်သုံးပါသည်။ DevOps သည် ဖြန့်ကျက်မှုအတွက် လိုအပ်သော ယေဘူယျအခြေခံအဆောက်အဦများဖြစ်သည့် အစုအဝေးအတွက် ပံ့ပိုးမှု၊ CI စနစ်အတွက် ပံ့ပိုးမှုစသည်ဖြင့် ပံ့ပိုးပေးပါသည်။ ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့တွင် ကွန်တိန်နာပေါင်း ၂ဝဝဝ ခန့်ရှိသော Nomad သို့ ပြောင်းရွှေ့စနစ် ၆၀ ကျော်ရှိသည်။

Devops သည် ဖြန့်ကျက်ခြင်းနှင့် ဆာဗာများနှင့် သက်ဆိုင်သည့်အရာအားလုံး၏ အထွေထွေအခြေခံအဆောက်အအုံအတွက် တာဝန်ရှိပါသည်။ တစ်ဖန် ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့တစ်ခုစီသည် ၎င်း၏ သီးခြားစနစ်အတွက် ကွန်တိန်နာများကို အကောင်အထည်ဖော်ရန် တာဝန်ရှိသည်၊ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် သီးခြားကွန်တိန်နာတစ်ခုတွင် ယေဘူယျလိုအပ်သည်များကို သိရှိသည့်အဖွဲ့ဖြစ်သောကြောင့် ဖြစ်သည်။

Nomad ကို စွန့်လွှတ်ရခြင်း အကြောင်းအရင်း

Nomad နှင့် docker တို့ကို အသုံးပြု၍ ဖြန့်ကျက်ခြင်းသို့ ပြောင်းခြင်းဖြင့် ကျွန်ုပ်တို့ ရရှိခဲ့သော အကျိုးကျေးဇူးများမှာ အဘယ်နည်း။

1. ကျွန်တော်တို့ တန်းတူညီတူအခြေအနေများပေးထားသည်။ ပတ်ဝန်းကျင်အားလုံးအတွက်။ ဖွံ့ဖြိုးတိုးတက်မှုတွင်၊ QA ပတ်၀န်းကျင်၊ မထုတ်လုပ်မီ၊ ထုတ်လုပ်မှု၊ တူညီသော ကွန်တိန်နာပုံများကို တူညီသောမှီခိုမှုများဖြင့် အသုံးပြုပါသည်။ ထို့ကြောင့်၊ ထုတ်လုပ်မှုတွင် ပြီးဆုံးမည့်အရာသည် သင်ယခင်က ပြည်တွင်း၌ စမ်းသပ်ခဲ့သော သို့မဟုတ် သင့်စမ်းသပ်မှုပတ်ဝန်းကျင်တွင် မဟုတ်ကြောင်း သင့်တွင် အခွင့်အလမ်းမရှိသလောက်ပင်ဖြစ်သည်။
2. လုံလောက်တယ်လို့လည်း ကျွန်တော်တို့ တွေ့ရှိခဲ့ပါတယ်။ ဝန်ဆောင်မှုအသစ်တစ်ခုထည့်ရန် လွယ်ကူသည်။. ဖြန့်ကျက်ခြင်းရှုထောင့်မှကြည့်လျှင် မည်သည့်စနစ်အသစ်ကိုမဆို အလွန်ရိုးရှင်းပါသည်။ configs များကိုသိမ်းဆည်းသည့် repository သို့သွားပါ၊ သင့်စနစ်အတွက် နောက်ထပ် config တစ်ခုကိုထည့်ပါ၊ အားလုံးအဆင်သင့်ဖြစ်ပါပြီ။ devops များထံမှ ထပ်မံအားထုတ်စရာမလိုဘဲ သင့်စနစ်ကို ထုတ်လုပ်ရေးသို့ အသုံးချနိုင်သည်။
3. အားလုံး configuration ဖိုင်များ ဘုံသိုလှောင်မှုတစ်ခုတွင် ပြန်လည်သုံးသပ်ခြင်းခံနေရပါသည်။အဲဒီအချိန်တုန်းက ကျွန်တော်တို့ရဲ့ စနစ်တွေကို အသုံးပြုပြီး ဖြန့်ကျက်ခဲ့တာက virtual ဆာဗာများကျွန်တော်တို့ Ansible ကိုသုံးခဲ့ပြီး config အားလုံးကို repository တစ်ခုတည်းမှာ သိမ်းဆည်းထားပါတယ်။ ဒါပေမယ့် developer အများစုအတွက် ဒါက အလုပ်လုပ်ရတာ နည်းနည်းပိုခက်ခဲပါတယ်။ service တစ်ခုကို deploy လုပ်ဖို့ ထည့်သွင်းရမယ့် config နဲ့ code ပမာဏကို သိသိသာသာ လျှော့ချထားပါတယ်။ ဒါ့အပြင် DevOps အနေနဲ့ ချိန်ညှိဖို့ ဒါမှမဟုတ် ပြောင်းလဲဖို့ အရမ်းလွယ်ကူပါတယ်။ ဥပမာအားဖြင့် Nomad ရဲ့ version အသစ်နဲ့ migration တစ်ခုလုပ်တဲ့အခါ တစ်နေရာတည်းမှာ သိမ်းဆည်းထားတဲ့ operational files အားလုံးကို bulk update လုပ်နိုင်ပါတယ်။

သို့သော် ကျွန်ုပ်တို့သည် အားနည်းချက်များစွာကို ကြုံတွေ့ခဲ့ရသည်-

ငါတို့က ထွက်လာတယ်။ ချောမွေ့စွာ ဖြန့်ကျက်မှု မအောင်မြင်နိုင်ပါ။ Nomad ၏အမှု၌။ မတူညီသောအခြေအနေများအောက်တွင် ကွန်တိန်နာများကို လှိမ့်ထုတ်သည့်အခါ၊ ၎င်းသည် လည်ပတ်နေပုံရပြီး Nomad သည် ၎င်းအား လမ်းကြောင်းလက်ခံရန် အဆင်သင့်ရှိသော ကွန်တိန်နာတစ်ခုအဖြစ် ရိပ်မိခဲ့သည်။ ၎င်းအတွင်းရှိ အက်ပ်လီကေးရှင်းကို စတင်ရန် အခွင့်အရေးမရရှိမီတွင် ၎င်းသည် ဖြစ်ပျက်ခဲ့သည်။ ဤအကြောင်းကြောင့်၊ စနစ်သည် အချိန်တိုအတွင်း အမှားအယွင်း 500 ကို စတင်ထုတ်လုပ်ခဲ့ပြီး၊ လမ်းကြောင်းသည် ၎င်းကို လက်ခံရန်အဆင်သင့်မဖြစ်သေးသော ကွန်တိန်နာဆီသို့ စတင်ရောက်ရှိသွားသောကြောင့် ဖြစ်သည်။

ကြုံခဲ့ရတာတွေရှိတယ်။ ပိုးကောင်များ. အထင်ရှားဆုံးသော ချို့ယွင်းချက်မှာ Nomad သည် စနစ်များနှင့် ကွန်တိန်နာများစွာရှိလျှင် ကြီးမားသောအစုအဝေးကြီးကို ကောင်းစွာမကိုင်တွယ်နိုင်ခြင်းကြောင့်ဖြစ်သည်။ ပြုပြင်ထိန်းသိမ်းရန်အတွက် Nomad cluster တွင်ပါရှိသော ဆာဗာများထဲမှ တစ်ခုကို ထုတ်ယူလိုသောအခါ၊ cluster သည် အလွန်ကောင်းမွန်ပြီး ကွဲသွားလိမ့်မည်မဟုတ်ကြောင်း အတော်လေး မြင့်မားသော ဖြစ်နိုင်ခြေရှိပါသည်။ ဥပမာအားဖြင့် အချို့သော ကွန်တိန်နာများသည် ပြုတ်ကျပြီး မတက်လာနိုင်သည် - သင့်ထုတ်လုပ်မှုစနစ်အားလုံးကို Nomad မှ စီမံခန့်ခွဲသည့် အစုအဝေးတွင် တည်ရှိပါက ၎င်းသည် နောက်ပိုင်းတွင် သင့်အတွက် များစွာကုန်ကျမည်ဖြစ်သည်။

ဒါကြောင့် ဘယ်ကိုသွားရမလဲ စဉ်းစားဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့ လိုချင်သောအရာကို ပိုမိုသိရှိနားလည်လာခဲ့သည်။ ဆိုလိုသည်မှာ- ကျွန်ုပ်တို့သည် ယုံကြည်စိတ်ချရမှု၊ Nomad ပေးဆောင်သည်ထက် အနည်းငယ်ပိုသောလုပ်ဆောင်ချက်များနှင့် ပိုမိုရင့်ကျက်ပြီး တည်ငြိမ်သောစနစ်ကို လိုချင်ပါသည်။

ဤကိစ္စနှင့်စပ်လျဉ်း၍ ကျွန်ုပ်တို့ရွေးချယ်မှုသည် အစုအဝေးများကိုဖွင့်ရန်အတွက် ရေပန်းအစားဆုံးပလပ်ဖောင်းအဖြစ် Kubernetes တွင် အကျုံးဝင်ပါသည်။ အထူးသဖြင့် ကျွန်ုပ်တို့၏ ကွန်တိန်နာများ၏ အရွယ်အစားနှင့် အရေအတွက်သည် လုံလောက်စွာ ကြီးမားသောကြောင့် ဖြစ်သည်။ ထိုသို့သောရည်ရွယ်ချက်များအတွက် Kubernetes သည် ကျွန်ုပ်တို့ကြည့်ရှုနိုင်သည့် အသင့်တော်ဆုံးစနစ်ဖြစ်ပုံရသည်။

Kubernetes သို့ ကူးပြောင်းခြင်း။

Kubernetes ၏ အခြေခံသဘောတရားများနှင့် ၎င်းတို့သည် Nomad နှင့် မည်သို့ကွာခြားကြောင်း အနည်းငယ်ပြောပြပါမည်။

ပထမဆုံးအနေဖြင့် Kubernetes တွင်အခြေခံအကျဆုံးအယူအဆမှာ pod ၏သဘောတရားဖြစ်သည်။ Pod တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ကွန်တိန်နာအုပ်စုတစ်စုသည် အမြဲအတူတကွလည်ပတ်နေပါသည်။ ပြီးတော့ သူတို့က အမြဲတမ်း virtual machine တစ်ခုပေါ်မှာ တင်းကြပ်စွာ အလုပ်လုပ်တယ်။ ၎င်းတို့သည် မတူညီသော port များပေါ်တွင် IP 127.0.0.1 မှတဆင့် အချင်းချင်း ချိတ်ဆက်အသုံးပြုနိုင်ပါသည်။

သင့်တွင် nginx နှင့် php-fpm - classic scheme ပါ၀င်သော PHP အပလီကေးရှင်းတစ်ခုရှိသည်ဟု ယူဆကြပါစို့။ ဖြစ်နိုင်သည်မှာ၊ သင်သည် nginx နှင့် php-fpm ကွန်တိန်နာများကို အချိန်တိုင်း အတူတကွ ထားရှိလိုမည်ဖြစ်သည်။ Kubernetes သည် ၎င်းတို့ကို ဘုံ pod တစ်ခုအဖြစ် ဖော်ပြခြင်းဖြင့် ၎င်းကို အောင်မြင်နိုင်စေပါသည်။ ဤသည်မှာ Nomad နှင့် မရနိုင်ပါ။

ဒုတိယ သဘောတရားကတော့ ဖြန့်ကျက်. အမှန်မှာ စပါးစေ့ကိုယ်တိုင်သည် ပေါ်ပင်အရာဖြစ်သည်၊ ၎င်းသည် စတင်၍ ပျောက်ကွယ်သွားခြင်း ဖြစ်သည်။ သင်၏ယခင်ကွန်တိန်နာအားလုံးကို ဦးစွာသတ်ပစ်ပြီးနောက် ဗားရှင်းအသစ်များကို တစ်ကြိမ်တည်းဖွင့်လိုပါသလား သို့မဟုတ် ၎င်းတို့ကို ဖြည်းဖြည်းချင်း ထုတ်ပစ်လိုပါသလား။ ဤလုပ်ငန်းစဉ်သည် ဖြန့်ကျက်ခြင်းသဘောတရားတွင် တာဝန်ရှိပါသည်။ ၎င်းသည် သင်၏ pods များကို မည်သို့အသုံးပြုပုံ၊ မည်သည့်ပမာဏနှင့် ၎င်းတို့ကို အပ်ဒိတ်လုပ်ရမည်ကို ဖော်ပြသည်။

တတိယ သဘောတရားကတော့ ဝန်ဆောင်မှု. သင့်ဝန်ဆောင်မှုသည် အမှန်တကယ်အားဖြင့် သင့်ဝန်ဆောင်မှုနှင့် သက်ဆိုင်သည့် အသွားအလာအချို့ကို လက်ခံရရှိပြီးနောက် ၎င်းကို သင့်ဝန်ဆောင်မှုနှင့် သက်ဆိုင်သည့် ပေါ့ဒ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော နေရာများသို့ ပေးပို့ခြင်းဖြစ်သည်။ ဆိုလိုသည်မှာ၊ ထိုသို့သောနှင့် ထိုကဲ့သို့သော ဝန်ဆောင်မှုတစ်ခုဆီသို့ အဝင်အထွက်များအားလုံးကို ဤကဲ့သို့သော သီးခြား pods များသို့ ပေးပို့ရမည်ဟု ဆိုလိုပါသည်။ တစ်ချိန်တည်းမှာပင် ၎င်းသည် သင့်အား traffic ချိန်ခွင်လျှာကို ထောက်ပံ့ပေးသည်။ ဆိုလိုသည်မှာ၊ သင်သည် သင်၏အပလီကေးရှင်း၏ pods နှစ်ခုကို စတင်နိုင်ပြီး၊ အဝင်လမ်းကြောင်းအားလုံးသည် ဤဝန်ဆောင်မှုနှင့်သက်ဆိုင်သည့် pods များကြားတွင် အညီအမျှ မျှတနေမည်ဖြစ်သည်။

စတုတ္ထအခြေခံသဘောတရားကတော့ Ingress. ၎င်းသည် Kubernetes အစုအဝေးတွင် လုပ်ဆောင်သည့် ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ ၎င်းသည် တောင်းဆိုမှုအားလုံးကို ကျော်လွှားနိုင်သော ပြင်ပဝန်ချိန်ခွင်လျှာအဖြစ် လုပ်ဆောင်သည်။ Kubernetes API ကို အသုံးပြု၍ Ingress သည် ဤတောင်းဆိုမှုများကို မည်သည့်နေရာတွင် ပေးပို့သင့်သည်ကို ဆုံးဖြတ်နိုင်ပါသည်။ ထို့အပြင်၊ သူသည်ဤသို့အလွန်လိုက်လျောညီထွေပြုသည်။ ဤအိမ်ရှင်ထံ တောင်းဆိုချက်အားလုံးကို ဤဝန်ဆောင်မှုသို့ ပေးပို့ထားကြောင်းနှင့် ထိုကဲ့သို့သော URL များကို ပေးပို့ထားကြောင်း သင်ပြောနိုင်ပါသည်။ ပြီးတော့ ဒီ host နဲ့ တခြား URL ဆီကို ရောက်လာတဲ့ ဒီတောင်းဆိုချက်တွေကို တခြားဝန်ဆောင်မှုတစ်ခုဆီ ပို့ပါတယ်။

အက်ပလီကေးရှင်းကို တီထွင်သူတစ်ယောက်၏ အမြင်တွင် အအေးဆုံးအချက်မှာ သင်ကိုယ်တိုင် စီမံခန့်ခွဲနိုင်ခြင်းဖြစ်သည်။ Ingress config ကို သတ်မှတ်ခြင်းဖြင့်၊ ဥပမာ၊ Go တွင် ရေးသားထားသော ကွန်တိန်နာများကို သီးခြားစီသို့ ပေးပို့နိုင်သည် ဒါပေမယ့် တူညီတဲ့ domain ဆီကို ရောက်လာတဲ့ ဒီ traffic ကို PHP နဲ့ရေးထားတဲ့ containers တွေဆီ ပို့သင့်ပါတယ်၊ ဒါပေမယ့် သူတို့က အရမ်းမြန်တာတော့ မဟုတ်ပါဘူး။

ဤသဘောတရားများအားလုံးကို Nomad နှင့် နှိုင်းယှဉ်ပါက၊ ပထမသဘောတရားသုံးခုလုံးသည် ဝန်ဆောင်မှုပေးသည်ဟု ဆိုနိုင်ပါသည်။ နောက်ဆုံးအယူအဆသည် Nomad ကိုယ်တိုင်၌ မရှိပါ။ ကျွန်ုပ်တို့သည် ၎င်းကို ပြင်ပချိန်ခွင်လျှာအဖြစ် အသုံးပြုခဲ့သည်- ၎င်းသည် haproxy၊ nginx၊ nginx+ စသည်တို့ ဖြစ်နိုင်သည်။ cube ၏ကိစ္စတွင်၊ သင်သည်ဤအပိုဆောင်းသဘောတရားကိုသီးခြားစီမိတ်ဆက်ရန်မလိုအပ်ပါ။ သို့သော်၊ Ingress အတွင်းပိုင်းကိုကြည့်လျှင်၎င်းသည် nginx၊ haproxy သို့မဟုတ် traefik သော်လည်းကောင်း Kubernetes တွင်တည်ဆောက်ထားသောအမျိုးအစားဖြစ်သည်။

ကျွန်ုပ်ဖော်ပြခဲ့သော သဘောတရားများအားလုံးသည် အမှန်တကယ်အားဖြင့် Kubernetes အစုအဝေးအတွင်း ရှိနေသော အရင်းအမြစ်များဖြစ်သည်။ ၎င်းတို့ကို cube တွင်ဖော်ပြရန်၊ Nomad ၏ကိစ္စတွင် HCL ဖိုင်များထက် ပိုမိုဖတ်ရှုနိုင်ပြီး ပိုမိုရင်းနှီးသည့် yaml ဖော်မတ်ကို အသုံးပြုထားသည်။ သို့သော်၊ ဥပမာ၊ pod ကိစ္စတွင် တူညီသောအရာကို ဖွဲ့စည်းတည်ဆောက်ပုံအရ ဖော်ပြကြသည်။ သူတို့ပြောသလို - ဒီလိုမျိုး ဘူးတွေကို အဲဒီနေရာမှာ ဒီလိုမျိုး ပုံတွေနဲ့ ဒီလိုမျိုး ပမာဏနဲ့ ဖြန့်ထားချင်တယ်။

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် တစ်ဦးချင်းစီ အရင်းအမြစ်တစ်ခုစီကို လက်ဖြင့် ဖန်တီးလိုခြင်းမဟုတ်ကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ထားသည်- ဖြန့်ကျက်မှု၊ ဝန်ဆောင်မှုများ၊ Ingress စသည်တို့ဖြစ်သည်။ ယင်းအစား၊ ကျွန်ုပ်တို့သည် ဖြန့်ကျက်စဉ်အတွင်း Kubernetes ၏ စည်းကမ်းချက်များဖြင့် ကျွန်ုပ်တို့၏စနစ်တစ်ခုစီကို ဖော်ပြလိုသည်၊ သို့မှသာ လိုအပ်သောအရင်းအမြစ်မှီခိုမှုအားလုံးကို မှန်ကန်သောအစီအစဉ်ဖြင့် လူကိုယ်တိုင်ပြန်လည်ဖန်တီးရန်မလိုအပ်ပါ။ ပဲ့စင်ကို ဒီလိုလုပ်ခွင့်ပေးတဲ့ စနစ်အဖြစ် ရွေးချယ်ခဲ့ပါတယ်။

Helm တွင် အခြေခံသဘောတရားများ

ပဲ့စင် ဖြစ်၏။ အထုပ်မန်နေဂျာ Kubernetes အတွက် ပရိုဂရမ်းမင်းဘာသာစကားများတွင် ပက်ကေ့ဂျ်မန်နေဂျာများ အလုပ်လုပ်ပုံနှင့် အလွန်ဆင်တူသည်။ ၎င်းတို့သည် သင့်အား ဥပမာအားဖြင့်၊ ဖြန့်ကျက်ခြင်း nginx၊ ဖြန့်ကျက်မှု php-fpm၊ Ingress အတွက် config၊ configmaps (၎င်းသည် သင့်စနစ်အတွက် env နှင့် အခြားသော parameters များကို သတ်မှတ်ရန်ခွင့်ပြုသည့် အရာတစ်ခု) ပါ၀င်သော ဝန်ဆောင်မှုကို သိမ်းဆည်းရန် ခွင့်ပြုထားသည်။ ဇယားဟုခေါ်သည်။ တစ်ချိန်တည်းမှာပင် ဟမ်း Kubernetes ထိပ်တွင် အလုပ်လုပ်သည်။. ဆိုလိုသည်မှာ၊ ၎င်းသည် ဘေးတွင်ရပ်နေသော စနစ်မျိုးမဟုတ်သော်လည်း cube အတွင်းရှိ အခြားဝန်ဆောင်မှုတစ်ခုသာဖြစ်သည်။ console command မှတစ်ဆင့် ၎င်း၏ API မှတစ်ဆင့် ၎င်းနှင့် အပြန်အလှန် တုံ့ပြန်နိုင်သည်။ ၎င်း၏အဆင်ပြေမှုနှင့် လှပမှုသည် ပဲ့စင်ကွဲသွားလျှင် သို့မဟုတ် ၎င်းကို အစုအဝေးမှ ဖယ်ရှားလိုက်လျှင်ပင်၊ ထို့နောက် Kubernetes ကိုယ်တိုင်က စွမ်းဆောင်ရည်နှင့် ဝန်ဆောင်မှုအခြေအနေများအတွက် တာဝန်ရှိပါသည်။

အဲဒါကိုလည်း ကျွန်တော်တို့ သဘောပေါက်တယ်။ ပုံစံထုတ်ခြင်းjinja ကိုကျွန်ုပ်တို့၏ configs တွင်ထည့်သွင်းခြင်းဖြင့်ကျွန်ုပ်တို့ယခင်ကကျွန်ုပ်တို့ကိုယ်တိုင်လုပ်ဆောင်ရန်အတင်းအကျပ်ခိုင်းစေခဲ့သော၊ သည်ပဲ့ပိုင်း၏အဓိကအင်္ဂါရပ်များထဲမှတစ်ခုဖြစ်သည်။ သင့်စနစ်များအတွက် သင်ဖန်တီးပေးသော configs အားလုံးကို jinja နှင့် အနည်းငယ်ဆင်တူသော templates ပုံစံများဖြင့် ပဲ့ခေါင်းတွင် သိမ်းဆည်းထားပါသည်၊ သို့သော် တကယ်တမ်းတွင်၊ Kubernetes ကဲ့သို့ ဦးခေါင်းပိုင်းကို ရေးသားထားသည့် Go language ၏ နမူနာပုံစံကို အသုံးပြုထားသည်။

Helm သည် ကျွန်ုပ်တို့အတွက် နောက်ထပ် သဘောတရားအချို့ကို ထပ်လောင်းပေးပါသည်။

ဇယား - ဤသည်မှာ သင့်ဝန်ဆောင်မှု၏ ဖော်ပြချက်ဖြစ်သည်။ အခြားသော ပက်ကေ့ဂျ်မန်နေဂျာများတွင် ၎င်းကို ပက်ကေ့ချ်၊ အစုအဝေး သို့မဟုတ် အလားတူအရာတစ်ခုဟု ခေါ်သည်။ ဒီမှာဇယားလို့ခေါ်တယ်။

တန်ဖိုးများ နမူနာပုံစံများမှ သင်၏ configs တည်ဆောက်ရန် သင်အသုံးပြုလိုသော ကိန်းရှင်များဖြစ်သည်။

လွှတ်ပေး. ဦးခေါင်းကိုအသုံးပြုထားသည့် ဝန်ဆောင်မှုတစ်ခုသည် ထုတ်ဝေမှု၏ တိုးမြင့်ဗားရှင်းကို လက်ခံရရှိသည့်အချိန်တိုင်း။ Helm သည် ယခင်ထုတ်လွှတ်မှုတွင် ဝန်ဆောင်မှု config ကို မှတ်မိသည်၊ ၎င်းမတိုင်မီ ထုတ်ဝေမှုနှင့် အခြားအရာများကို မှတ်မိသည်။ ထို့ကြောင့်၊ သင်သည် ပြန်လှည့်ရန် လိုအပ်ပါက၊ ၎င်းကို ယခင်ထွက်ရှိထားသော ဗားရှင်းသို့ ညွှန်ပြပြီး helm callback command ကိုဖွင့်လိုက်ပါ။ ပြန်သိမ်းသည့်အချိန်၌ သင့်သိုလှောင်ရာရှိ ဆက်စပ်ဖွဲ့စည်းမှုပုံစံကို မရရှိနိုင်သော်လည်း၊ ပဲ့ထိန်းသည် ၎င်းသည် မည်သည့်အရာဖြစ်သည်ကို မှတ်မိနေသေးပြီး သင့်စနစ်အား ယခင်ထုတ်လွှတ်မှုတွင်ရှိသည့် အခြေအနေသို့ ပြန်ပြောင်းပေးမည်ဖြစ်သည်။

ကျွန်ုပ်တို့သည် ဦးထုပ်ကို အသုံးပြုသောအခါတွင်၊ Kubernetes အတွက် ပုံမှန် configs များသည် ကိန်းရှင်များ၊ လုပ်ဆောင်ချက်များနှင့် အခြေအနေဆိုင်ရာ ထုတ်ပြန်ချက်များကို အသုံးပြုရန် ဖြစ်နိုင်သည့် ပုံစံများအဖြစ် ပြောင်းလဲပါသည်။ ဤနည်းဖြင့် ပတ်ဝန်းကျင်အပေါ်မူတည်၍ သင့်ဝန်ဆောင်မှု config ကို စုဆောင်းနိုင်ပါသည်။

လက်တွေ့တွင်၊ ကျွန်ုပ်တို့သည် Nomad နှင့် လုပ်ခဲ့သည်ထက် အနည်းငယ် ကွဲပြားသည့်အရာများကို လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။ Nomad တွင် ကျွန်ုပ်တို့၏ ဝန်ဆောင်မှုကို အသုံးပြုရန် လိုအပ်သော ဖြန့်ကျက်မှု configs နှင့် n-variable နှစ်ခုလုံးကို repository တစ်ခုတွင် သိမ်းဆည်းထားပါက၊ ဤနေရာတွင် ၎င်းတို့ကို သီးခြား repositories နှစ်ခုအဖြစ် ခွဲရန် ဆုံးဖြတ်ခဲ့သည်။ "deploy" repository သည် deployment အတွက် လိုအပ်သော n-variable များကိုသာ သိမ်းဆည်းထားပြီး "helm" repository သည် configs သို့မဟုတ် charts များကို သိမ်းဆည်းထားသည်။

ဒါက ငါတို့ကို ဘာပေးတာလဲ။

ကျွန်ုပ်တို့သည် စီစဉ်ဖွဲ့စည်းမှုဖိုင်များတွင် အမှန်တကယ် အရေးကြီးသောဒေတာကို ကျွန်ုပ်တို့ကိုယ်တိုင် မသိမ်းဆည်းထားသော်လည်း၊ ဥပမာအားဖြင့်၊ databases သို့ စကားဝှက်များ။ ၎င်းတို့ကို Kubernetes တွင် လျှို့ဝှက်ချက်များအဖြစ် သိမ်းဆည်းထားသော်လည်း၊ လူတိုင်းကို ဝင်ရောက်ကြည့်ရှုခွင့်မပေးလိုသော အချို့အရာများ ရှိနေသေးသည်။ ထို့ကြောင့်၊ "deploy" repository သို့ဝင်ရောက်ခွင့်သည် ပို၍ အကန့်အသတ်ရှိပြီး "ပဲ့စင်" repository တွင် ဝန်ဆောင်မှု၏ ဖော်ပြချက်ပါရှိပါသည်။ ဤအကြောင်းကြောင့်၊ ကျယ်ပြန့်သောလူများက ဘေးကင်းစွာ ဝင်ရောက်နိုင်သည်။

ကျွန်ုပ်တို့တွင် ထုတ်လုပ်မှုသာမက အခြားပတ်ဝန်းကျင်များပါရှိသောကြောင့်၊ ဤခွဲထွက်မှုကြောင့် ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုအတွက်သာမက ဥပမာအားဖြင့် QA ပတ်ဝန်းကျင်တွင် ဝန်ဆောင်မှုများကို အသုံးချရန်အတွက် ကျွန်ုပ်တို့၏ ဦးခေါင်းဇယားများကို ပြန်လည်အသုံးပြုနိုင်ပါသည်။ ဒေသအလိုက် အသုံးချရန်ပင် မီနီကူဘီ - ဤအရာသည် Kubernetes ကို စက်တွင်းတွင် အသုံးပြုရန်အတွက် ဖြစ်သည်။

သိုလှောင်မှုတစ်ခုစီတွင် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတစ်ခုစီအတွက် သီးခြားလမ်းညွှန်များအဖြစ် ပိုင်းခြားထားခဲ့သည်။ ဆိုလိုသည်မှာ၊ လမ်းညွှန်တစ်ခုစီတွင် သက်ဆိုင်ရာဇယားနှင့် သက်ဆိုင်သည့် နမူနာပုံစံများ ပါရှိပြီး ကျွန်ုပ်တို့၏စနစ်လည်ပတ်ရန် လိုအပ်သည့် အရင်းအမြစ်များကို ဖော်ပြခြင်းဖြစ်ပါသည်။ ကျွန်ုပ်တို့သည် "deploy" repository တွင် envs များသာကျန်ခဲ့သည်။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် jinja ကိုအသုံးပြု၍ ပုံစံဆွဲခြင်းအား မသုံးထားဘဲ၊ ပဲ့ခေါင်းကိုယ်တိုင်က ပုံစံခွက်ပုံစံကို ဘောင်အတွင်းမှ ထုတ်ပေးသောကြောင့်ဖြစ်သည် - ၎င်းသည် ၎င်း၏အဓိကလုပ်ဆောင်ချက်များထဲမှတစ်ခုဖြစ်သည်။

ဦးထုပ်ကို အသုံးပြု၍ ဖြန့်ကျက်ခြင်းအတွက် စတင်ခြင်းအတွက် ရိုးရှင်းပြီး စံနှုန်းဖြစ်စေသော ဖြန့်ကျက်မှု script - deploy.sh ကို ချန်ထားခဲ့သည်။ ထို့ကြောင့်၊ အသုံးပြုလိုသူတိုင်းအတွက်၊ ဖြန့်ကျက်မှု အင်တာဖေ့စ်သည် Nomad မှတစ်ဆင့် ဖြန့်ကျက်ရာတွင် လုပ်ဆောင်ခဲ့သည့်အတိုင်း အတိအကျတူညီပါသည်။ တူညီသော deploy.sh၊ သင့်ဝန်ဆောင်မှုအမည်နှင့် သင်အသုံးပြုလိုသည့်နေရာ။ ၎င်းသည် ပဲ့ထိန်းစက်အတွင်းပိုင်းကို စတင်စေသည်။ ၎င်းသည် တမ်းပလိတ်များမှ configs များကို စုဆောင်းကာ လိုအပ်သော တန်ဖိုးများကို ၎င်းတို့ထဲသို့ ထည့်သွင်းကာ ၎င်းတို့ကို အသုံးချကာ Kubernetes အတွင်းသို့ စတင်သည်။

တွေ့ရှိချက်များ

Kubernetes ဝန်ဆောင်မှုသည် Nomad ထက် ပိုမိုရှုပ်ထွေးပုံပေါ်သည်။

ဤတွင် အထွက်လမ်းကြောင်းသည် Ingress သို့ ရောက်လာသည်။ ၎င်းသည် တောင်းဆိုချက်အားလုံးကို ကျော်ဖြတ်ကာ တောင်းဆိုချက်ဒေတာနှင့် သက်ဆိုင်သည့် ဝန်ဆောင်မှုများသို့ ပေးပို့ပေးသည့် ရှေ့ထိန်းချုပ်ကိရိယာသာဖြစ်သည်။ ၎င်းသည် သင်၏အပလီကေးရှင်း၏ ဦးခေါင်းပါရှိဖော်ပြချက်၏တစ်စိတ်တစ်ပိုင်းဖြစ်ပြီး ဆော့ဖ်ဝဲရေးသားသူများ ၎င်းတို့ကိုယ်တိုင်သတ်မှတ်ထားသည့် configs များအပေါ် အခြေခံ၍ ၎င်းတို့ကို ဆုံးဖြတ်သည်။ ဝန်ဆောင်မှုသည် ဤဝန်ဆောင်မှုနှင့်သက်ဆိုင်သည့် ကွန်တိန်နာများအားလုံးကြား အဝင်အထွက်လမ်းကြောင်းကို ချိန်ညှိပေးသည့် သီးသန့်ကွန်တိန်နာများဖြစ်သည့် ၎င်း၏ pods များထံ တောင်းဆိုမှုများ ပေးပို့ပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ကွန်ရက်အဆင့်ရှိ လုံခြုံရေးမှ မည်သည့်နေရာကိုမှ မသွားသင့်ကြောင်း မမေ့သင့်ပါ။ ထို့ကြောင့်၊ ခွဲခြားသတ်မှတ်ခြင်းသည် တဂ်လုပ်ခြင်းအပေါ် အခြေခံသည့် Kubernetes အစုအဝေးတွင် အလုပ်လုပ်သည်။ ဝန်ဆောင်မှုအားလုံးတွင် ဝန်ဆောင်မှုများ၏ ပြင်ပ/အတွင်းတွင်း အရင်းအမြစ်များ အစုအဝေးအတွင်း သို့မဟုတ် ပြင်ပတွင် ဆက်စပ်နေသည့် အချို့သော တဂ်များရှိသည်။

ကျွန်ုပ်တို့သည် အကူးအပြောင်းကို ပြုလုပ်သောအခါတွင်၊ Kubernetes တွင် ယခင်က ကျွန်ုပ်တို့အသုံးပြုခဲ့ဖူးသည့် Nomad ၏ စွမ်းရည်များအားလုံးကို သိမြင်ခဲ့ပြီး အသစ်အဆန်းများစွာကိုလည်း ထည့်သွင်းခဲ့သည်။ ၎င်းကို Plugins များမှတစ်ဆင့် ချဲ့ထွင်နိုင်ပြီး အမှန်တကယ်တွင် စိတ်ကြိုက်အရင်းအမြစ်အမျိုးအစားများမှတစ်ဆင့် ချဲ့ထွင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ သင်သေတ္တာထဲမှ Kubernetes နှင့်ပါလာသည့်အရာများကို အသုံးပြုရန်သာမက သင့်အရင်းအမြစ်ကိုဖတ်ရှုမည့် သင်၏ကိုယ်ပိုင်အရင်းအမြစ်နှင့် ဝန်ဆောင်မှုကိုဖန်တီးရန် အခွင့်အရေးရှိသည်။ ၎င်းက Kubernetes ကို ပြန်လည်ထည့်သွင်းရန်မလိုဘဲ ပြုပြင်မွမ်းမံမှုများ မလိုအပ်ဘဲ သင့်စနစ်ကို ချဲ့ထွင်ရန် နောက်ထပ်ရွေးချယ်စရာများကို ပေးသည်။

ထိုသို့သောအသုံးပြုမှု၏ဥပမာမှာ ကျွန်ုပ်တို့၏ Kubernetes အစုအဝေးအတွင်းတွင် လုပ်ဆောင်နေသော Prometheus ဖြစ်သည်။ ၎င်းသည် သီးခြားဝန်ဆောင်မှုတစ်ခုမှ မက်ထရစ်များကို စတင်စုဆောင်းရန်အတွက်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုဖော်ပြချက်တွင် နောက်ထပ်အရင်းအမြစ်အမျိုးအစားတစ်ခုဖြစ်သည့် ဝန်ဆောင်မှုမော်နီတာကို ပေါင်းထည့်ရန် လိုအပ်ပါသည်။ Prometheus သည် Kubernetes တွင် စတင်သောအခါ စိတ်ကြိုက်အရင်းအမြစ်အမျိုးအစားကို ဖတ်ရှုနိုင်သောကြောင့်၊ စနစ်အသစ်မှ မက်ထရစ်များကို အလိုအလျောက် စတင်စုဆောင်းပါသည်။ တော်တော်အဆင်ပြေပါတယ်။

Kubernetes သို့ ကျွန်ုပ်တို့ ပထမဆုံး ဖြန့်ကျက်မှုသည် မတ်လ 2018 တွင်ဖြစ်သည်။ ပြီးတော့ ဒီအချိန်အတောအတွင်းမှာတော့ ကျွန်တော်တို့ဟာ ဘယ်ပြဿနာမှ မကြုံဖူးပါဘူး။ ၎င်းသည် သိသာထင်ရှားသော ချို့ယွင်းချက်များမရှိဘဲ အတော်လေးတည်ငြိမ်စွာ အလုပ်လုပ်ပါသည်။ ထို့အပြင် ကျွန်ုပ်တို့သည် ၎င်းကို ပိုမိုချဲ့ထွင်နိုင်သည်။ ယနေ့ကျွန်ုပ်တို့၌၎င်း၏စွမ်းရည်များအလုံအလောက်ရှိပြီး Kubernetes ၏ဖွံ့ဖြိုးတိုးတက်မှုအရှိန်အဟုန်ကိုကျွန်ုပ်တို့တကယ်နှစ်သက်ပါသည်။ လက်ရှိတွင် Kubernetes တွင် ကွန်တိန်နာ 3000 ကျော်ရှိသည်။ အစုအဝေးသည် Nodes များစွာကို သိမ်းပိုက်သည်။ တစ်ချိန်တည်းမှာပင်၊ ၎င်းသည်ဝန်ဆောင်မှုပေးနိုင်သည်၊ တည်ငြိမ်ပြီးအလွန်ထိန်းချုပ်နိုင်သည်။

source: www.habr.com