Kubernetes သို့ အသုံးချခြင်း၏ ပထမအဆင့်မှာ သင့်လျှောက်လွှာကို ကွန်တိန်နာတစ်ခုတွင် ထားခြင်းဖြစ်သည်။ ဤစီးရီးတွင်၊ သေးငယ်ပြီး လုံခြုံသောပုံးပုံတစ်ပုံကို သင်ဖန်တီးနိုင်ပုံကို ကြည့်ရှုပါမည်။
Docker ကြောင့် ကွန်တိန်နာပုံများကို ဖန်တီးခြင်းသည် ဘယ်သောအခါမှ မလွယ်ကူခဲ့ပါ။ အခြေခံပုံကိုသတ်မှတ်ပါ၊ သင်၏ပြောင်းလဲမှုများကိုထည့်ပါ၊ ကွန်တိန်နာတစ်ခုဖန်တီးပါ။
ဤနည်းပညာသည် စတင်ရန်အတွက် ကောင်းမွန်သော်လည်း၊ ပုံသေအခြေခံပုံများကို အသုံးပြုခြင်းဖြင့် အားနည်းချက်များပြည့်နေသော ပုံကြီးများဖြင့် မလုံခြုံသောအလုပ်သို့ ဦးတည်သွားနိုင်သည်။
ထို့အပြင်၊ Docker ရှိ ပုံအများစုသည် အခြေခံရုပ်ပုံအတွက် Debian သို့မဟုတ် Ubuntu ကို အသုံးပြုထားပြီး ၎င်းသည် အလွန်ကောင်းမွန်သော လိုက်ဖက်ညီမှုနှင့် လွယ်ကူသော စိတ်ကြိုက်ပြင်ဆင်မှုကို ပေးစွမ်းနိုင်သော်လည်း (Docker ဖိုင်တစ်ခုတွင် ကုဒ်နှစ်လိုင်းသာ ယူသည်)၊ အခြေခံပုံများသည် သင့်ကွန်တိန်နာသို့ ရာနှင့်ချီသော မက်ဂါဗိုက်များ ထပ်လောင်းထည့်နိုင်သည်။ ဥပမာအားဖြင့်၊ Go "hello-world" အက်ပလီကေးရှင်းအတွက် ရိုးရှင်းသော node.js ဖိုင်သည် 700 megabytes ခန့်ရှိပြီး သင်၏အမှန်တကယ်အပလီကေးရှင်းသည် အရွယ်အစားအနည်းငယ်မဂ္ဂါဘိုက်သာရှိသည်။
ထို့ကြောင့် ဤအပိုအလုပ်ဝန်အားလုံးသည် ဒစ်ဂျစ်တယ်နေရာလွတ်များ ဖြုန်းတီးနေပြီး လုံခြုံရေးအားနည်းချက်များနှင့် ချို့ယွင်းချက်များအတွက် ပုန်းအောင်းရာနေရာဖြစ်သည်။ ဒါဆို container ပုံရဲ့ အရွယ်အစားကို လျှော့ချဖို့ နည်းလမ်းနှစ်ခုကို ကြည့်ရအောင်။
ပထမတစ်ခုက အခြေခံပုံလေးတွေကို အသုံးပြုခြင်းဖြစ်ပြီး ဒုတိယတစ်ခုကတော့ Builder Pattern ကိုအသုံးပြုခြင်းဖြစ်ပါတယ်။ သေးငယ်သော အခြေခံပုံများကို အသုံးပြုခြင်းသည် သင့်ကွန်တိန်နာ၏ အရွယ်အစားကို လျှော့ချရန် အလွယ်ကူဆုံးနည်းလမ်း ဖြစ်နိုင်သည်။ ဖြစ်နိုင်သည်မှာ၊ သင်အသုံးပြုနေသည့် ဘာသာစကား သို့မဟုတ် အစုအဝေးသည် မူလပုံသေပုံထက် များစွာသေးငယ်သော အပလီကေးရှင်းပုံတစ်ပုံကို ပံ့ပိုးပေးပါသည်။ ကျွန်ုပ်တို့၏ node.js container ကို ကြည့်ကြပါစို့။
Docker တွင် မူရင်းအားဖြင့်၊ node:8 အခြေခံရုပ်ပုံအရွယ်အစားမှာ 670 MB ဖြစ်ပြီး node- 8-alpine ရုပ်ပုံအရွယ်အစားမှာ 65 MB သာရှိပြီး၊ ဆိုလိုသည်မှာ 10 ဆပိုသေးပါသည်။ သေးငယ်သော Alpine အောက်ခံပုံကို အသုံးပြုခြင်းဖြင့်၊ သင်သည် သင့်ကွန်တိန်နာ၏ အရွယ်အစားကို သိသာထင်ရှားစွာ လျှော့ချနိုင်မည်ဖြစ်သည်။ Alpine သည် သေးငယ်ပြီး ပေါ့ပါးသော Linux ဖြန့်ဖြူးမှုတစ်ခုဖြစ်ပြီး ၎င်းသည် ကွန်တိန်နာများကို သေးငယ်နေချိန်တွင် အပလီကေးရှင်းများစွာနှင့် တွဲဖက်အသုံးပြုနိုင်သောကြောင့် Docker အသုံးပြုသူများအကြား အလွန်ရေပန်းစားသည်။ ပုံမှန် Docker "node" ပုံနှင့် မတူဘဲ၊ "node:alpine" သည် ဝန်ဆောင်မှုဖိုင်များနှင့် ပရိုဂရမ်အများအပြားကို ဖယ်ရှားပေးကာ သင့်အက်ပ်လီကေးရှင်းကို လုပ်ဆောင်ရန် လုံလောက်သည့်အရာများကိုသာ ချန်ထားသည်။
သေးငယ်သော အခြေခံပုံသို့ ရွှေ့ရန်၊ အခြေခံပုံအသစ်နှင့် စတင်လုပ်ဆောင်ရန် Dockerfile ကို ရိုးရှင်းစွာ အပ်ဒိတ်လုပ်ပါ။
ယခု ပုံဟောင်းနှင့်မတူဘဲ၊ သင်သည် သင်၏ကုဒ်ကို ကွန်တိန်နာထဲသို့ ကူးယူပြီး မှီခိုမှုတစ်ခုခုကို ထည့်သွင်းရန် လိုအပ်ပါသည်။ Dockerfile အသစ်တွင်၊ ကွန်တိန်နာသည် node-alpine ပုံဖြင့် စတင်သည်၊ ထို့နောက် ကုဒ်အတွက် လမ်းညွှန်တစ်ခု ဖန်တီးကာ NPM ပက်ကေ့ဂျ်မန်နေဂျာကို အသုံးပြု၍ မှီခိုမှုကို ထည့်သွင်းကာ နောက်ဆုံးတွင် server.js ကို လုပ်ဆောင်သည်။
ဤအဆင့်မြှင့်တင်မှုသည် အရွယ်အစား ၁၀ ဆ ပိုသေးငယ်သော ကွန်တိန်နာကို ဖြစ်ပေါ်စေသည်။ သင့်ပရိုဂရမ်းမင်းဘာသာစကား သို့မဟုတ် စတက်ခ်တွင် အခြေခံရုပ်ပုံလျှော့ချရေး လုပ်ဆောင်နိုင်စွမ်းမရှိပါက Alpine Linux ကို အသုံးပြုပါ။ ၎င်းသည် ကွန်တိန်နာ၏ အကြောင်းအရာများကို အပြည့်အဝ စီမံခန့်ခွဲနိုင်စွမ်းကိုလည်း ပေးစွမ်းမည်ဖြစ်သည်။ သေးငယ်သော အခြေခံပုံများကို အသုံးပြုခြင်းသည် သေးငယ်သော ကွန်တိန်နာများကို လျင်မြန်စွာ ဖန်တီးရန် အကောင်းဆုံးနည်းလမ်းတစ်ခုဖြစ်သည်။ သို့သော် Builder Pattern ကို အသုံးပြု၍ ပိုမိုကြီးမားသောလျှော့ချမှုကို အောင်မြင်နိုင်သည်။
ဘာသာပြန်ထားသော ဘာသာစကားများဖြင့်၊ အရင်းအမြစ်ကုဒ်ကို စကားပြန်ထံ ဦးစွာပေးပို့ပြီးနောက် တိုက်ရိုက်လုပ်ဆောင်သည်။ စုစည်းထားသော ဘာသာစကားများတွင်၊ အရင်းအမြစ်ကုဒ်ကို ပထမဆုံး စုစည်းထားသောကုဒ်အဖြစ်သို့ ပြောင်းလဲသည်။ သို့သော်၊ စုစည်းမှုသည် ကုဒ်ကိုလည်ပတ်ရန် အမှန်တကယ်မလိုအပ်သောကိရိယာများကို အသုံးပြုလေ့ရှိသည်။ ဆိုလိုသည်မှာ ဤကိရိယာများကို နောက်ဆုံးပုံးမှ အပြီးအပိုင် ဖယ်ရှားနိုင်သည်ဟု ဆိုလိုသည်။ ဤအတွက် သင်သည် Builder Pattern ကိုသုံးနိုင်သည်။
ကုဒ်ကို ပထမကွန်တိန်နာတွင် ဖန်တီးပြီး ပြုစုထားသည်။ ထို့နောက် compiled code ကို compiler နှင့် tools များမလိုအပ်ဘဲ နောက်ဆုံး container ထဲသို့ ထုပ်ပိုးထားသည်။ ဤလုပ်ငန်းစဉ်မှတဆင့် Go အက်ပ်ကို အသုံးပြုကြပါစို့။ ဦးစွာ၊ ကျွန်ုပ်တို့သည် onbuild image မှ Alpine Linux သို့ ရွှေ့ပါမည်။
Dockerfile အသစ်တွင်၊ ကွန်တိန်နာသည် golang-alpine ပုံဖြင့် စတင်သည်။ ထို့နောက် ၎င်းသည် ကုဒ်အတွက် လမ်းညွှန်တစ်ခု ဖန်တီးကာ အရင်းအမြစ်ကုဒ်သို့ ကူးယူကာ အဆိုပါ အရင်းအမြစ်ကုဒ်ကို တည်ဆောက်ကာ အပလီကေးရှင်းကို လုပ်ဆောင်သည်။ ဤကွန်တိန်နာသည် onbuild container ထက် များစွာသေးငယ်သော်လည်း ၎င်းတွင် ကျွန်ုပ်တို့ အမှန်တကယ်မလိုအပ်သော compiler နှင့် အခြား Go tools များပါရှိသည်။ ဒီတော့ စုစည်းထားတဲ့ ပရိုဂရမ်ကို ထုတ်ယူပြီး ကိုယ်ပိုင်ပုံးထဲမှာ ထည့်လိုက်ကြရအောင်။
ဤ Docker ဖိုင်တွင် ထူးဆန်းသောအရာတစ်ခုကို သင်သတိထားမိနိုင်သည်- ၎င်းတွင် FROM လိုင်းနှစ်ခုပါရှိသည်။ ဤအဆင့်ကိုအမည်ပေးရန် AS သော့ချက်စာလုံးကိုအသုံးပြုထားမှလွဲ၍ ပထမစာကြောင်း 4 ကဏ္ဍသည် ယခင် Dockerfile နှင့် အတိအကျတူညီပါသည်။ နောက်အပိုင်းတွင် ပုံအသစ်တစ်ခုစတင်ရန် FROM မျဉ်းအသစ်တစ်ခုရှိပြီး golang:alpine ပုံအစား Raw alpine ကို အခြေခံပုံအဖြစ် အသုံးပြုပါမည်။
Raw Alpine Linux တွင် SSL လက်မှတ်များ ထည့်သွင်းထားခြင်း မရှိပါ၊ ၎င်းသည် HTTPS မှတဆင့် API ခေါ်ဆိုမှုအများစုကို ပျက်ကွက်စေသည်၊ ထို့ကြောင့် အချို့သော root CA လက်မှတ်များကို ထည့်သွင်းကြပါစို့။
ယခု ပျော်ရွှင်စရာအပိုင်းကို ရောက်ရှိလာသည်- ပထမကွန်တိန်နာမှ စုစည်းထားသောကုဒ်ကို ဒုတိယအပိုင်းသို့ ကူးယူရန်၊ ဒုတိယအပိုင်း၏ စာကြောင်း 5 တွင်ရှိသော COPY အမိန့်ကို ရိုးရိုးရှင်းရှင်း အသုံးပြုနိုင်သည်။ ၎င်းသည် အပလီကေးရှင်းဖိုင်တစ်ခုသာ ကူးယူမည်ဖြစ်ပြီး Go utility tools များကို သက်ရောက်မှုရှိမည်မဟုတ်ပါ။ Multi-stage Docker ဖိုင်အသစ်တွင် 12 megabytes ရှိ မူရင်းပုံးပုံနှင့် နှိုင်းယှဉ်ပါက အရွယ်အစား 700 megabytes သာရှိသော ကွန်တိန်နာပုံတစ်ပုံပါရှိမည်ဖြစ်ပြီး၊ ၎င်းမှာ ကြီးမားသောကွာခြားချက်ဖြစ်သည်။
ထို့ကြောင့် အသေးစားပုံများနှင့် Builder Pattern ကိုအသုံးပြုခြင်းသည် အလုပ်အများကြီးမလုပ်ဘဲ သေးငယ်သောကွန်တိန်နာများကို ဖန်တီးရန် အကောင်းဆုံးနည်းလမ်းများဖြစ်သည်။
အပလီကေးရှင်းအစုအစည်းအပေါ် မူတည်၍ ပုံနှင့် ကွန်တိန်နာအရွယ်အစားကို လျှော့ချရန် နောက်ထပ်နည်းလမ်းများ ရှိနိုင်သော်လည်း သေးငယ်သော ကွန်တိန်နာများသည် အမှန်တကယ် တိုင်းတာနိုင်သော အကျိုးကျေးဇူးများ ရှိပါသလား။ သေးငယ်သော ကွန်တိန်နာများသည် အလွန်ထိရောက်မှုရှိသော နယ်ပယ်နှစ်ခုဖြစ်သည့် စွမ်းဆောင်ရည်နှင့် လုံခြုံရေးကို ကြည့်ကြပါစို့။
စွမ်းဆောင်ရည် တိုးလာမှုကို အကဲဖြတ်ရန်၊ ကွန်တိန်နာကို ဖန်တီးသည့် လုပ်ငန်းစဉ်၏ ကြာချိန်ကို ထည့်သွင်းစဉ်းစားပြီး ၎င်းကို မှတ်ပုံတင်ခြင်း (push) တွင် ထည့်သွင်းပြီးနောက် ၎င်းမှ ပြန်လည်ရယူခြင်း (ဆွဲထုတ်ခြင်း)။ သေးငယ်သော ကွန်တိန်နာသည် ပိုကြီးသော ကွန်တိန်နာထက် ထူးခြားသော အားသာချက်ရှိကြောင်း သင်တွေ့မြင်နိုင်သည်။
Docker သည် အလွှာများကို ကက်ရှ်လုပ်မည်ဖြစ်သောကြောင့် နောက်ဆက်တွဲတည်ဆောက်မှုများသည် အလွန်မြန်ဆန်မည်ဖြစ်သည်။ သို့သော်၊ ကွန်တိန်နာများတည်ဆောက်ခြင်းနှင့်စမ်းသပ်ရန်အသုံးပြုသော CI စနစ်များစွာသည် ကက်ရှ်အလွှာများမပါဝင်သောကြောင့် အချိန်ကုန်သက်သာစေပါသည်။ သင်တွေ့မြင်ရသည့်အတိုင်း သင့်စက်၏ ပါဝါပေါ်မူတည်၍ ကွန်တိန်နာကြီးတစ်လုံးတည်ဆောက်ရန် အချိန်သည် ၃၄ မှ ၅၄ စက္ကန့်အထိဖြစ်ပြီး Builder Pattern ကိုအသုံးပြု၍ ကွန်တိန်နာကိုအသုံးပြုသည့်အခါ ၂၃ မှ ၂၈ စက္ကန့်အထိ လျှော့ချနိုင်သည်။ ဒီလိုမျိုးလုပ်ငန်းတွေအတွက် ကုန်ထုတ်စွမ်းအား 34-54% တိုးလာမယ်။ ဒါကြောင့် သင့်ကုဒ်ကို ဘယ်နှစ်ခါတည်ဆောက်ပြီး စမ်းသပ်သလဲဆိုတာကို စဉ်းစားပါ။
ကွန်တိန်နာကို တည်ဆောက်ပြီးနောက်၊ သင်သည် ၎င်းကို သင်၏ Kubernetes အစုအဝေးတွင် အသုံးပြုနိုင်ရန် ၎င်း၏ရုပ်ပုံ (ပုံးပုံအား ကွန်တိန်နာပုံ) ထဲသို့ တွန်းပို့ရန် လိုအပ်သည်။ Google Container Registry ကို အသုံးပြုရန် အကြံပြုပါသည်။
Google Container Registry (GCR) ဖြင့် သင်သည် ကုန်ကြမ်းသိုလှောင်မှုနှင့် ကွန်ရက်ချိတ်ဆက်မှုအတွက်သာ ပေးဆောင်ရပြီး အပိုကွန်တိန်နာ စီမံခန့်ခွဲမှု အခကြေးငွေများ မရှိပါ။ ၎င်းသည် သီးသန့်၊ လုံခြုံပြီး အလွန်မြန်ဆန်သည်။ GCR သည် ဆွဲထုတ်ခြင်းကို အရှိန်မြှင့်ရန် လှည့်ကွက်များစွာကို အသုံးပြုသည်။ သင်မြင်ရသည့်အတိုင်း go:onbuild ကိုအသုံးပြု၍ Docker Container Image container ကိုထည့်သွင်းခြင်းသည် ကွန်ပျူတာစွမ်းဆောင်ရည်ပေါ်မူတည်၍ 15 မှ 48 စက္ကန့်အထိကြာမြင့်မည်ဖြစ်ပြီး ပိုမိုသေးငယ်သောကွန်တိန်နာတစ်ခုနှင့်တူညီသောလုပ်ဆောင်ချက်သည် 14 မှ 16 စက္ကန့်အထိကြာမြင့်မည်ဖြစ်ပြီး ထုတ်လုပ်မှုနည်းသောစက်များအတွက် လုပ်ဆောင်ချက်အမြန်နှုန်း 3 ဆတိုးလာ၏အားသာချက်။ ပိုကြီးသောစက်များအတွက်၊ GCR သည် ပုံများ၏မျှဝေထားသောဒေတာဘေ့စ်အတွက် ကမ္ဘာလုံးဆိုင်ရာ ကက်ရှ်တစ်ခုကို အသုံးပြုသောကြောင့် အချိန်သည် အတူတူပင်ဖြစ်ပါသည်။ ပါဝါနည်းသောကွန်ပြူတာတွင် CPU သည် ပိတ်ဆို့မှုများဖြစ်သောကြောင့် သေးငယ်သောကွန်တိန်နာများကိုအသုံးပြုခြင်း၏အားသာချက်မှာ ဤနေရာတွင် ပို၍ကြီးမားပါသည်။
အကယ်၍ သင်သည် GCR ကိုအသုံးပြုနေပါက၊ သင်၏တည်ဆောက်မှုစနစ်၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် Google Container Builder (GCB) ကိုအသုံးပြုရန် အထူးအကြံပြုလိုပါသည်။
သင်တွေ့မြင်ရသည့်အတိုင်း၊ ၎င်း၏အသုံးပြုမှုသည် ဖြစ်ထွန်းသည့်စက်ထက်ပင် Build+Push လည်ပတ်မှုကြာချိန်ကို လျှော့ချရာတွင် များစွာပိုမိုကောင်းမွန်သောရလဒ်များရရှိစေနိုင်သည် - ဤကိစ္စတွင်၊ အိမ်ရှင်ထံသို့ ကွန်တိန်နာများတည်ဆောက်ခြင်းနှင့် ပေးပို့ခြင်းလုပ်ငန်းစဉ်သည် ၂ ဆနီးပါး အရှိန်မြှင့်လာသည်။ . ထို့အပြင်၊ သင်သည် နေ့စဉ် 2 အခမဲ့ တည်ဆောက်မှု မိနစ်ကို ရရှိပြီး ကိစ္စအများစုတွင် သင်၏ ကွန်တိန်နာ အဆောက်အဦ လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးပါသည်။
နောက်တစ်ခုတွင် အရေးကြီးဆုံးသော စွမ်းဆောင်ရည်မက်ထရစ်- ပြန်လည်ရယူခြင်း သို့မဟုတ် ဒေါင်းလုဒ်ဆွဲခြင်း ကွန်တိန်နာများကို ဆွဲထုတ်ခြင်း၏ အမြန်နှုန်း။ အကယ်၍ သင်သည် တွန်းအားတစ်ခုအတွက် အသုံးပြုသည့်အချိန်ကို သိပ်ဂရုမစိုက်ပါက၊ ဆွဲယူခြင်းလုပ်ငန်းစဉ်၏ကြာချိန်သည် စနစ်တစ်ခုလုံး၏စွမ်းဆောင်ရည်အပေါ် ဆိုးရွားစွာသက်ရောက်မှုရှိပါသည်။ သင့်တွင် node သုံးခုရှိသော အစုအဝေးတစ်ခုရှိပြီး ၎င်းတို့ထဲမှတစ်ခုသည် ပျက်ကွက်သည်ဆိုကြပါစို့။ အကယ်၍ သင်သည် Google Kubernetes Engine ကဲ့သို့သော စီမံခန့်ခွဲမှုစနစ်တစ်ခုကို အသုံးပြုနေပါက၊ ၎င်းသည် dead node အား အသစ်တစ်ခုနှင့် အလိုအလျောက် အစားထိုးမည်ဖြစ်သည်။ သို့သော်၊ ဤ node အသစ်သည် လုံးဝဗလာဖြစ်ကာ ၎င်းသည် စတင်အလုပ်လုပ်ရန်အတွက် သင်၏ container များအားလုံးကို ၎င်းထဲသို့ ဆွဲယူရမည်ဖြစ်သည်။ ဆွဲထုတ်မှု လုံလောက်စွာ ကြာပါက၊ သင်၏ အစုအဝေးသည် တစ်ချိန်လုံး စွမ်းဆောင်ရည် နိမ့်ကျနေမည်ဖြစ်သည်။
ထိုသို့ဖြစ်ပွားနိုင်သည့် အခြေအနေများစွာရှိသည်- အစုအဝေးတစ်ခုသို့ node အသစ်တစ်ခုထည့်ခြင်း၊ node အဆင့်မြှင့်တင်ခြင်း သို့မဟုတ် ဖြန့်ကျက်ခြင်းအတွက် ကွန်တိန်နာအသစ်တစ်ခုသို့ ပြောင်းခြင်းတို့ပင်။ ထို့ကြောင့် ဆွဲထုတ်ယူသည့်အချိန်ကို လျှော့ချခြင်းသည် အဓိကအချက်ဖြစ်လာသည်။ သေးငယ်သော ကွန်တိန်နာသည် အကြီးကြီးတစ်ခုထက် များစွာပိုမိုမြန်ဆန်စွာ ဒေါင်းလုဒ်လုပ်သည်ကို ငြင်းမရနိုင်ပါ။ Kubernetes အစုအဝေးတွင် ကွန်တိန်နာအများအပြားကို သင်အသုံးပြုနေပါက၊ အချိန်ကုန်သက်သာမှုသည် သိသာထင်ရှားပါသည်။
ဤနှိုင်းယှဉ်ချက်ကိုကြည့်ပါ- go:onbuild ကိုအသုံးပြုသည့် တူညီသောလည်ပတ်မှုထက် စက်၏ပါဝါပေါ်မူတည်၍ သေးငယ်သောကွန်တိန်နာများပေါ်တွင် ဆွဲထုတ်သည့်အချိန်သည် 4-9 ဆ ပိုနည်းသည်။ မျှဝေထားသော သေးငယ်သော ကွန်တိန်နာအခြေခံပုံများကို အသုံးပြုခြင်းဖြင့် Kubernetes node အသစ်များကို အသုံးပြုနိုင်ပြီး အွန်လိုင်းပေါ်ရောက်လာသည့် အချိန်နှင့် အမြန်နှုန်းကို သိသိသာသာ မြန်ဆန်စေသည်။
လုံခြုံရေးကိစ္စကို ကြည့်ရအောင်။ သေးငယ်သော ကွန်တိန်နာများသည် သေးငယ်သော တိုက်ခိုက်ရေး မျက်နှာပြင်ရှိသောကြောင့် ပိုကြီးသော ကွန်တိန်နာများထက် များစွာ ပိုလုံခြုံသည်ဟု ယူဆပါသည်။ တကယ်လား? Google Container Registry ၏ အသုံးဝင်ဆုံးသောအင်္ဂါရပ်များထဲမှတစ်ခုမှာ အားနည်းချက်များအတွက် သင့်ကွန်တိန်နာများကို အလိုအလျောက်စကင်န်လုပ်ခြင်းဖြစ်ပါသည်။ လွန်ခဲ့သည့်လအနည်းငယ်က ကျွန်ုပ်သည် onbuild နှင့် multistage containers နှစ်ခုလုံးကို ဖန်တီးခဲ့သည်၊ ထို့ကြောင့် ထိုနေရာတွင် အားနည်းချက်များ ရှိမရှိ ကြည့်ကြပါစို့။
ရလဒ်မှာ အံ့သြဖွယ်ဖြစ်သည်- သေးငယ်သော ကွန်တိန်နာတစ်ခုတွင် အလတ်စား အားနည်းချက် 3 ခုသာ တွေ့ရှိခဲ့ပြီး အရေးကြီးသော 16 ခုနှင့် အခြား အားနည်းချက် 376 ခုကို ကွန်တိန်နာကြီးတစ်ခုတွင် တွေ့ရှိခဲ့သည်။ ကွန်တိန်နာကြီးတစ်ခု၏ အကြောင်းအရာများကို ကြည့်လျှင် လုံခြုံရေးပြဿနာအများစုသည် ကျွန်ုပ်တို့၏ အပလီကေးရှင်းနှင့် ဘာမှမဆိုင်သော်လည်း ကျွန်ုပ်တို့အသုံးမပြုသော ပရိုဂရမ်များနှင့် ဆက်စပ်နေကြောင်း တွေ့နိုင်ပါသည်။ ဒါကြောင့် လူတွေက ကြီးမားတဲ့ တိုက်ခိုက်မှု မျက်နှာပြင်အကြောင်း ပြောကြတဲ့အခါ၊ အဲဒါကို ဆိုလိုတာပါ။
ယူဆောင်သွားခြင်းမှာ ရှင်းလင်းပါသည်- ၎င်းတို့သည် သင့်စနစ်အတွက် အမှန်တကယ်စွမ်းဆောင်ရည်နှင့် လုံခြုံရေးအကျိုးကျေးဇူးများကို ပေးစွမ်းသောကြောင့် သေးငယ်သော ကွန်တိန်နာများကို တည်ဆောက်ပါ။
ကြော်ငြာအချို့ 🙂
ကျွန်ုပ်တို့နှင့်အတူရှိနေသည့်အတွက် ကျေးဇူးတင်ပါသည်။ ကျွန်ုပ်တို့၏ဆောင်းပါးများကို သင်နှစ်သက်ပါသလား။ ပိုစိတ်ဝင်စားစရာကောင်းတဲ့ အကြောင်းအရာတွေကို ကြည့်ချင်ပါသလား။ မှာယူမှုတစ်ခုပြုလုပ်ခြင်း သို့မဟုတ် သူငယ်ချင်းများကို အကြံပြုခြင်းဖြင့် ကျွန်ုပ်တို့အား ပံ့ပိုးကူညီပါ၊ , မင်းအတွက် ငါတို့က တီထွင်ထားတဲ့ entry-level server တွေရဲ့ ထူးခြားတဲ့ analogue တစ်ခု။ (RAID1 နှင့် RAID10၊ 24 cores အထိနှင့် 40GB DDR4 အထိ)။
အမ်စတာဒမ်ရှိ Equinix Tier IV ဒေတာစင်တာတွင် Dell R730xd သည် ၂ ဆ စျေးသက်သာသည်။ ဒီမှာသာ နယ်သာလန်မှာ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 မှ။ အကြောင်းဖတ်ပါ။
source: www.habr.com