Quay.io တွင် Post Mortem မရရှိနိုင်ပါ။

မှတ်ချက်။ ဘာသာပြန်: ဩဂုတ်လအစောပိုင်းတွင် Red Hat သည် ၎င်း၏ဝန်ဆောင်မှုအသုံးပြုသူများ ကြုံတွေ့ခဲ့ရသည့် သုံးစွဲနိုင်မှုဆိုင်ရာ ပြဿနာများကို ဖြေရှင်းခြင်းအကြောင်း လူသိရှင်ကြားပြောခဲ့သည်။ Quay.io (၎င်းသည် CoreOS ဝယ်ယူမှုနှင့်အတူ ကုမ္ပဏီမှ လက်ခံရရှိသည့် ကွန်တိန်နာပုံများအတွက် မှတ်ပုံတင်မှုအပေါ် အခြေခံထားသည်။) ဤဝန်ဆောင်မှုကို သင်စိတ်ဝင်စားသည်ဖြစ်စေ ကုမ္ပဏီ၏ SRE အင်ဂျင်နီယာများက မတော်တဆမှုဖြစ်ရခြင်းအကြောင်းရင်းများကို ရှာဖွေဖော်ထုတ်ဖယ်ရှားပေးခဲ့သည့် လမ်းကြောင်းသည် လမ်းညွှန်ချက်ဖြစ်သည်။

မေလ 19 ရက်နေ့ နံနက်အစောပိုင်း (Eastern Daylight Time, EDT) တွင် quay.io ဝန်ဆောင်မှု ပျက်ကျသွားခဲ့သည်။ မတော်တဆမှုသည် quay.io အသုံးပြုသူများနှင့် ဆော့ဖ်ဝဲလ်တည်ဆောက်ခြင်းနှင့် ဖြန့်ဖြူးခြင်းအတွက် ပလပ်ဖောင်းတစ်ခုအဖြစ် quay.io ကို အသုံးပြုသည့် Open Source ပရောဂျက်များကို ထိခိုက်စေခဲ့သည်။ Red Hat သည် နှစ်ဦးစလုံး၏ ယုံကြည်မှုကို တန်ဖိုးထားပါသည်။

SRE အင်ဂျင်နီယာအဖွဲ့တစ်ဖွဲ့သည် ချက်ချင်းပါဝင်လာပြီး Quay ဝန်ဆောင်မှုကို အမြန်ဆုံးတည်ငြိမ်အောင် ကြိုးစားခဲ့သည်။ သို့သော် ၎င်းတို့လုပ်ဆောင်နေစဉ်တွင်၊ ဖောက်သည်များသည် ပုံအသစ်များကို တွန်းထုတ်နိုင်စွမ်း ဆုံးရှုံးသွားပြီး ရံဖန်ရံခါမှသာ ၎င်းတို့သည် ရှိပြီးသားပုံများကို ဆွဲထုတ်နိုင်ခဲ့ကြသည်။ အမည်မသိအကြောင်းပြချက်အချို့ကြောင့်၊ ဝန်ဆောင်မှုကို စွမ်းဆောင်ရည်အပြည့်အထိ ချဲ့ထွင်ပြီးနောက် quay.io ဒေတာဘေ့စ်ကို ပိတ်ဆို့ခဲ့သည်။

«အဘယ်အရာကိုပြောင်းလဲပစ်ခဲ့သလဲ" - ဒီလိုမျိုးကိစ္စတွေမှာ မေးလေ့ရှိတဲ့ ပထမဆုံးမေးခွန်းပါ။ ပြဿနာမဖြစ်မီ မကြာမီတွင်၊ OpenShift Dedicated အစုအဝေး (quay.io ကိုလည်ပတ်သည့်) ဗားရှင်း 4.3.19 သို့ အပ်ဒိတ်လုပ်လာသည်ကို ကျွန်ုပ်တို့သတိပြုမိပါသည်။ quay.io သည် Red Hat OpenShift Dedicated (OSD) တွင်အလုပ်လုပ်သောကြောင့်၊ ပုံမှန်မွမ်းမံမှုများသည် ပုံမှန်ဖြစ်ပြီး မည်သည့်ပြဿနာမျှမဖြစ်ပါ။ ထို့အပြင်၊ ပြီးခဲ့သောခြောက်လအတွင်း၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတွင် အနှောက်အယှက်မရှိဘဲ Quay အစုအဝေးများကို အကြိမ်ကြိမ် အဆင့်မြှင့်ထားသည်။

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

အမြစ်အကြောင်းရင်းကို ဆန်းစစ်ခြင်း။

ပျက်ကွက်ခြင်း၏ အဓိက လက္ခဏာမှာ သောင်းနှင့်ချီသော ဒေတာဘေ့စ်ချိတ်ဆက်မှုများ ပြိုပျက်သွားခြင်းဖြစ်ပြီး MySQL instance ကို ထိထိရောက်ရောက် လုပ်ဆောင်၍မရပေ။ ယင်းက ပြဿနာကို အဖြေရှာရန် ခက်ခဲစေသည်။ SRE အဖွဲ့မှ ပြဿနာကို အကဲဖြတ်ရာတွင် ကူညီရန် သုံးစွဲသူများထံမှ ချိတ်ဆက်မှု အများဆုံး အရေအတွက်အပေါ် ကန့်သတ်ချက်တစ်ခု သတ်မှတ်ထားပါသည်။ ဒေတာဘေ့စ်သို့ ပုံမှန်မဟုတ်သော အသွားအလာကို ကျွန်ုပ်တို့ သတိမပြုမိခဲ့ပါ။ အမှန်တကယ်တွင် တောင်းဆိုမှုအများစုကို ဖတ်ပြီး အနည်းငယ်သာ ရေးသားခဲ့သည်။

ဤ နှင်းပြိုကျခြင်းကို ဖြစ်စေနိုင်သော ဒေတာဘေ့စ်အသွားအလာတွင် ပုံစံတစ်ခုကိုလည်း ဖော်ထုတ်ရန် ကျွန်ုပ်တို့ ကြိုးစားခဲ့သည်။ သို့သော်၊ မှတ်တမ်းများတွင် မည်သည့်ပုံစံများကိုမျှ ရှာမတွေ့ပါ။ OSD 4.3.18 ပါသော အစုအသစ်ကို အဆင်သင့်ဖြစ်ရန် စောင့်ဆိုင်းနေစဉ်၊ ကျွန်ုပ်တို့သည် quay.io pods များကို စတင်ရန် ဆက်လက်ကြိုးစားနေပါသည်။ အစုအဖွဲ့သည် စွမ်းဆောင်ရည်ပြည့်မီသည့်အခါတိုင်း၊ ဒေတာဘေ့စ်သည် အေးခဲသွားမည်ဖြစ်သည်။ ဆိုလိုသည်မှာ quay.io pods များအားလုံးအပြင် RDS instance ကို ပြန်လည်စတင်ရန် လိုအပ်သည်ဟု ဆိုလိုသည်။

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

Quay.io သည် OSD အစုအဝေးအသစ်တွင် တည်ငြိမ်စွာ အလုပ်လုပ်သောကြောင့် ဒေတာဘေ့စ်မှတ်တမ်းများဆီသို့ ပြန်သွားသော်လည်း ပိတ်ဆို့မှုများကို ရှင်းပြမည့် ဆက်စပ်မှုကို ရှာမတွေ့ပါ။ Red Hat OpenShift 4.3.19 တွင် ပြောင်းလဲမှုများသည် Quay နှင့် ပြဿနာဖြစ်စေနိုင်သည်ဆိုသည်ကို နားလည်ရန် OpenShift အင်ဂျင်နီယာများသည် ကျွန်ုပ်တို့နှင့် လက်တွဲဆောင်ရွက်ခဲ့ပါသည်။ သို့သော် ဘာမျှမတွေ့၊ ဓာတ်ခွဲခန်းအခြေအနေများတွင် ပြဿနာကို မျိုးပွားရန် မဖြစ်နိုင်ပါ။.

ဒုတိယကျရှုံးမှု

မေလ 28 ရက်၊ နေ့လည် EDT မတိုင်မီလေးတွင်၊ quay.io သည် အလားတူလက္ခဏာဖြင့် ထပ်မံပျက်ကျသွားသည်- ဒေတာဘေ့စ်ကို ပိတ်ထားသည်။ နောက်တဖန် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ကြိုးစားအားထုတ်မှုအားလုံးကို စုံစမ်းစစ်ဆေးမှုထဲသို့ ပစ်ချခဲ့သည်။ ပထမဦးစွာ၊ ဝန်ဆောင်မှုကို ပြန်လည်ရယူရန် လိုအပ်ပါသည်။ သို့သော် ဤအချိန်သည် RDS ကိုပြန်လည်စတင်ပြီး quay.io pods များကိုပြန်လည်စတင်ခြင်းဘာမှမလုပ်ပါ။: နောက်ထပ် ချိတ်ဆက်မှု ပြိုကျမှုက အခြေစိုက်စခန်းကို လွှမ်းခြုံသွားပြီ။ ဒါနဲ့ဘာဖြစ်လို့လဲ?

Quay ကို Python ဖြင့်ရေးထားပြီး pod တစ်ခုချင်းစီသည် monolithic container တစ်ခုအဖြစ်လုပ်ဆောင်သည်။ ကွန်တိန်နာ runtime သည် အပြိုင်လုပ်ဆောင်စရာများစွာကို တစ်ပြိုင်နက် လုပ်ဆောင်သည်။ ကျွန်တော်တို့ စာကြည့်တိုက်ကို သုံးပါတယ်။ gevent အောက်တွင် gunicorn ဝဘ်တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်။ တောင်းဆိုချက်တစ်ခု Quay သို့ (ကျွန်ုပ်တို့၏ကိုယ်ပိုင် API မှတစ်ဆင့် သို့မဟုတ် Docker ၏ API မှတစ်ဆင့်) သို့ရောက်လာသောအခါ ၎င်းကို gevent လုပ်သားတစ်ဦးကို တာဝန်ပေးအပ်သည်။ ပုံမှန်အားဖြင့် ဤအလုပ်သမားသည် ဒေတာဘေ့စ်ကို ဆက်သွယ်သင့်သည်။ ပထမ ပျက်ကွက်ပြီးနောက်၊ gevent လုပ်သားများသည် ပုံသေဆက်တင်များကို အသုံးပြု၍ ဒေတာဘေ့စ်သို့ ချိတ်ဆက်နေကြောင်း တွေ့ရှိခဲ့သည်။

Quay pods များ၏ သိသာထင်ရှားသော အရေအတွက်နှင့် တစ်စက္ကန့်လျှင် ဝင်လာသော တောင်းဆိုချက် ထောင်ပေါင်းများစွာကို ပေးသောကြောင့်၊ ဒေတာဘေ့စ်ချိတ်ဆက်မှု အများအပြားသည် MySQL instance ကို သီအိုရီအရ လွှမ်းမိုးသွားနိုင်သည်။ စောင့်ကြည့်မှုကြောင့် Quay သည် တစ်စက္ကန့်လျှင် ပျမ်းမျှ တောင်းဆိုချက်ပေါင်း ၅ဝဝဝ ကို လုပ်ဆောင်ကြောင်း သိရှိရပါသည်။ ဒေတာဘေ့စ်သို့ ချိတ်ဆက်မှုအရေအတွက်သည် ခန့်မှန်းခြေအားဖြင့် တူညီပါသည်။ ချိတ်ဆက်မှု 5 သည် ကျွန်ုပ်တို့၏ RDS စံနမူနာတွင် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်သည် (သောင်းနှင့်ချီ၍မရနိုင်သော)။ အကြောင်းတစ်ခုခုကြောင့် ချိတ်ဆက်မှုအရေအတွက်တွင် မမျှော်လင့်ထားသော တိုးများလာခဲ့သည်။သို့သော်လည်း ဝင်လာသော တောင်းဆိုမှုများနှင့် ဆက်စပ်မှုကို ကျွန်ုပ်တို့ သတိမပြုမိပါ။

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

ကျွန်ုပ်တို့သည် ဤဗားရှင်းအသစ်ကို ထုတ်လုပ်ရန်အတွက် ချက်ချင်းအသုံးချပြီး ဒေတာဘေ့စ်ချိတ်ဆက်မှုအချိန်ဇယားကို စတင်စောင့်ကြည့်ခဲ့သည်။ အရင်တုန်းကတော့ စခန်းကို မိနစ် 20 လောက်ကြာအောင် ပိတ်ထားခဲ့ပါတယ်။ ပြဿနာကင်းစင်တဲ့ မိနစ် 30 အပြီးမှာ ကျွန်တော်တို့ မျှော်လင့်ချက်တွေ ရှိလာခဲ့ပြီး တစ်နာရီအကြာမှာတော့ ကျွန်တော်တို့ ယုံကြည်မှုရှိလာခဲ့ပါတယ်။ ကျွန်ုပ်တို့သည် ဝဘ်ဆိုက်သို့ အသွားအလာကို ပြန်လည်ရယူပြီး ရင်ခွဲစစ်ဆေးခြင်းကို စတင်ခဲ့သည်။

ပြဿနာကို ကျော်လွှားနိုင်စေပြီး ပိတ်ဆို့ခြင်း ၊ ၎င်း၏ အကြောင်းရင်း အစစ်အမှန်ကို ကျွန်ုပ်တို့ မတွေ့ရှိရပါ။. ယခင်က Quay နှင့်တွဲဖက်လုပ်ဆောင်ခဲ့သည့် ဗားရှင်း 4.3.19 တွင် အလားတူကိစ္စရပ်ကြောင့် ဖြစ်သည့်အတွက် OpenShift 4.3.18 တွင် မည်သည့်ပြောင်းလဲမှုများနှင့်မျှ မသက်ဆိုင်ကြောင်း အတည်ပြုထားသည်။

အစုအဝေးတွင် အခြားအရာတစ်ခု လျှို့ဝှက်စွာ ရှိနေသည်မှာ ထင်ရှားသည်။

အသေးစိတ်လေ့လာပါ။

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

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

Quay.io သည် ဇွန်လ ၉ ရက်အထိ ကောင်းမွန်စွာ အလုပ်လုပ်ခဲ့သည်။ ယနေ့နံနက် (EDT) ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်ချိတ်ဆက်မှု အရေအတွက် သိသိသာသာ တိုးလာသည်ကို ထပ်မံတွေ့မြင်ရပါသည်။ ဒီတစ်ခါတော့ စက်ရပ်တာမရှိဘူး။ကန့်သတ်ချက်အသစ်သည် ၎င်းတို့၏နံပါတ်ကို ကန့်သတ်ထားသောကြောင့် MySQL ဖြတ်သန်းမှုကို ကျော်လွန်ရန် ခွင့်မပြုသောကြောင့်ဖြစ်သည်။ သို့သော် နာရီဝက်ခန့်ကြာသောအခါ အသုံးပြုသူအများအပြားသည် quay.io ၏ စွမ်းဆောင်ရည် နှေးကွေးသည်ကို သတိပြုမိသည်။ ထပ်လောင်းစောင့်ကြည့်ရေးကိရိယာများကို အသုံးပြု၍ ဖြစ်နိုင်သမျှဒေတာအားလုံးကို ကျွန်ုပ်တို့ လျင်မြန်စွာစုဆောင်းခဲ့သည်။ ရုတ်တရက် ပုံစံတစ်ခု ထွက်ပေါ်လာသည်။

အချိတ်အဆက်များ မြင့်တက်မလာမီလေးတွင်၊ App Registry API သို့ တောင်းဆိုမှု အများအပြား ပြုလုပ်ခဲ့သည်။. App Registry သည် quay.io ၏ လူသိနည်းသော အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ ၎င်းသည် သင့်အား Helm ဇယားများနှင့် ကွန်တိန်နာများကဲ့သို့ အရာများကို ကြွယ်ဝသော မက်တာဒေတာများဖြင့် သိမ်းဆည်းနိုင်စေပါသည်။ quay.io အသုံးပြုသူအများစုသည် ဤအင်္ဂါရပ်နှင့် အလုပ်မလုပ်သော်လည်း Red Hat OpenShift သည် ၎င်းကိုတက်ကြွစွာအသုံးပြုသည်။ OpenShift ၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် OperatorHub သည် App Registry တွင် အော်ပရေတာအားလုံးကို သိမ်းဆည်းထားသည်။ ဤအော်ပရေတာများသည် OpenShift workload ecosystem နှင့် ပါတနာဗဟိုပြုလည်ပတ်မှုပုံစံ (Day 2 operations) အတွက် အခြေခံဖြစ်သည်။

OpenShift 4 အစုအဝေး တစ်ခုစီသည် တပ်ဆင်ရန်အတွက် ရရှိနိုင်သော အော်ပရေတာများ၏ ကတ်တလောက်ကို ထုတ်ဝေရန်နှင့် ထည့်သွင်းပြီးသော သူများအတွက် အပ်ဒိတ်များပေးရန်အတွက် တပ်ဆင်ထားသော OperatorHub မှ အော်ပရေတာများကို အသုံးပြုပါသည်။ OpenShift 4 ၏ရေပန်းစားလာမှုနှင့်အတူ၊ ၎င်းတွင်ကမ္ဘာတစ်ဝှမ်းရှိအစုအဝေးအရေအတွက်လည်းတိုးလာခဲ့သည်။ ဤအစုအဝေးတစ်ခုစီသည် quay.io အတွင်းရှိ App Registry ကို နောက်ခံအဖြစ်အသုံးပြု၍ built-in OperatorHub ကိုလည်ပတ်ရန်အတွက် အော်ပရေတာအကြောင်းအရာကို ဒေါင်းလုဒ်လုပ်ပါသည်။ ပြဿနာ၏ရင်းမြစ်ကို ရှာဖွေရာတွင် OpenShift သည် တဖြည်းဖြည်း လူကြိုက်များလာသည်နှင့်အမျှ အသုံးပြုခဲသော quay.io လုပ်ဆောင်ချက်များထဲမှ တစ်ခုကို ဝန်ထုပ်ဝန်ပိုးလည်း တိုးလာသည်ဟူသော အချက်ကို လွဲချော်ခဲ့ပါသည်။.

ကျွန်ုပ်တို့သည် App Registry တောင်းဆိုမှုလမ်းကြောင်းဆိုင်ရာ ခွဲခြမ်းစိတ်ဖြာမှုအချို့ကို ပြုလုပ်ခဲ့ပြီး မှတ်ပုံတင်ကုဒ်ကို ကြည့်ရှုခဲ့သည်။ ချက်ခြင်းတွင်၊ ဒေတာဘေ့စ်သို့ မေးမြန်းမှုများကို အကောင်းဆုံးဖြစ်အောင် မဖန်တီးနိုင်ခဲ့သောကြောင့် ချို့ယွင်းချက်များကို ချက်ချင်းဖော်ထုတ်ခဲ့သည်။ ဝန်နည်းသောအခါတွင် ပြဿနာတစ်စုံတစ်ရာမရှိသော်လည်း ဝန်တိုးလာသောအခါတွင် ပြဿနာများဖြစ်လာသည်။ App Registry တွင် load တိုးလာရန်အတွက် ကောင်းမွန်စွာတုံ့ပြန်ခြင်းမရှိသော ပြဿနာရှိသော endpoints နှစ်ခုရှိသည်- ပထမတစ်ခုက repository ရှိ ပက်ကေ့ဂျ်အားလုံး၏စာရင်းကို ပေးခဲ့ပြီး ဒုတိယမှာ package အတွက် blobs အားလုံးကို ပြန်ပေးပါသည်။

အကြောင်းတရားများပပျောက်ရေး

နောက်အပတ်တွင် ကျွန်ုပ်တို့သည် App Registry ၏ကုဒ်နှင့် ၎င်း၏ပတ်ဝန်းကျင်ကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်နေပါသည်။ သိသိသာသာ ထိရောက်မှုမရှိသော SQL မေးမြန်းမှုများကို ပြန်လည်လုပ်ဆောင်ခဲ့ပြီး မလိုအပ်သော အမိန့်ခေါ်ဆိုမှုများကို ဖယ်ရှားခဲ့သည်။ tar ( blobs များကို ထုတ်ယူသည့်အခါတိုင်း လုပ်ဆောင်သည် ) ကက်ရှ်ကို ဖြစ်နိုင်သမျှ ထည့်ထားသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် ကျယ်ပြန့်သော စွမ်းဆောင်ရည်စမ်းသပ်မှုကို ပြုလုပ်ခဲ့ပြီး အပြောင်းအလဲများမတိုင်မီနှင့် အပြီးတွင် အက်ပ်မှတ်ပုံတင်ခြင်း၏ အမြန်နှုန်းကို နှိုင်းယှဉ်ခဲ့သည်။

ယခင်က မိနစ်ဝက်အထိ အချိန်ယူခဲ့သော API တောင်းဆိုမှုများကို ယခုအခါ မီလီစက္ကန့်များဖြင့် ပြီးမြောက်သွားပါပြီ။. နောက်အပတ်တွင် ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုပြောင်းလဲမှုများကို အသုံးချခဲ့ပြီး ထိုအချိန်မှစ၍ quay.io သည် တည်ငြိမ်စွာအလုပ်လုပ်နေပါသည်။ ထိုအချိန်အတွင်း၊ App Registry အဆုံးမှတ်တွင် အသွားအလာများ သိသိသာသာ တိုးများလာသော်လည်း တိုးတက်မှုများက ဒေတာဘေ့စ်ပြတ်တောက်မှုကို တားဆီးနိုင်ခဲ့သည်။

ငါတို့ ဘာသင်ယူခဲ့လဲ။

မည်သည့်ဝန်ဆောင်မှုမဆို စက်ရပ်ခြင်းကို ရှောင်ရှားရန် ကြိုးစားသည်မှာ ရှင်းပါသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ မကြာသေးမီက ပြတ်တောက်မှုများသည် quay.io ပိုမိုကောင်းမွန်လာစေရန် ကူညီပေးခဲ့သည်ဟု ကျွန်ုပ်တို့ယုံကြည်ပါသည်။ မျှဝေလိုသော အဓိကသင်ခန်းစာအချို့ကို ကျွန်ုပ်တို့ လေ့လာသင်ယူခဲ့ပြီးဖြစ်သည်-

1. သင့်ဝန်ဆောင်မှုကို မည်သူအသုံးပြုသည်နှင့် မည်သို့မျှ ဒေတာသည် မည်သည့်အခါမျှ မလိုအပ်ပါ။. Quay "အလုပ်ပဲ" ဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် အသွားအလာကောင်းအောင်နှင့် ဝန်ကို စီမံခန့်ခွဲရန် အချိန်ဖြုန်းစရာမလိုပါ။ ဤအရာအားလုံးသည် ဝန်ဆောင်မှုကို ရက်အကန့်အသတ်မရှိ အတိုင်းအတာအထိ အတိုင်းအတာအထိ မှားယွင်းသော လုံခြုံရေးကို ဖန်တီးပေးခဲ့သည်။
2. ဝန်ဆောင်မှုကျသွားတဲ့အခါ၊ ၎င်းကို ပြန်လည်ရယူပြီး လုပ်ဆောင်ခြင်းသည် ထိပ်တန်းဦးစားပေးဖြစ်သည်။. Quay သည် ပထမအကြိမ်ပြတ်တောက်စဉ်အတွင်း လော့ခ်ချထားသောဒေတာဘေ့စ်ကို ဆက်လက်ခံစားခဲ့ရသောကြောင့် ကျွန်ုပ်တို့၏စံလုပ်ထုံးလုပ်နည်းများသည် ရည်ရွယ်ထားသောအကျိုးသက်ရောက်မှုမရှိခဲ့ဘဲ ၎င်းတို့ကိုအသုံးပြု၍ ဝန်ဆောင်မှုကို ပြန်လည်ရယူနိုင်ခြင်းမရှိပေ။ ယင်းကြောင့် အကြောင်းရင်းကို ရှာဖွေရန် မျှော်လင့်ချက်ဖြင့် အချိန်ကို ခွဲခြမ်းစိတ်ဖြာပြီး စုဆောင်းရမည့် အခြေအနေသို့ ဖြစ်ပေါ်စေသည် - လုပ်ဆောင်နိုင်စွမ်းကို ပြန်လည်ရယူရန် ကြိုးပမ်းမှုအားလုံးကို အာရုံစိုက်မည့်အစား၊
3. ဝန်ဆောင်မှုအင်္ဂါရပ်တစ်ခုစီ၏ အကျိုးသက်ရောက်မှုကို အကဲဖြတ်ပါ။. ဖောက်သည်များသည် App Registry ကို သုံးခဲသောကြောင့် ကျွန်ုပ်တို့အဖွဲ့အတွက် ဦးစားပေးမဟုတ်ပါ။ အချို့သော ထုတ်ကုန်အင်္ဂါရပ်များကို ရှားရှားပါးပါး အသုံးပြုသောအခါတွင် ၎င်းတို့၏ ချို့ယွင်းချက်များ ပေါ်လာခဲပြီး ဆော့ဖ်ဝဲရေးသားသူများသည် ကုဒ်ကို စောင့်ကြည့်ခြင်းကို ရပ်သွားကြသည်။ ဤသည်မှာ ဖြစ်သင့်သည်ဟူသော အယူအဆလွဲမှားခြင်း၏ သားကောင်ကို လွယ်လွယ်ဖြင့် လုယူရန် လွယ်ကူသည်—ထိုလုပ်ဆောင်ချက်သည် ကြီးကြီးမားမား ဖြစ်ရပ်တစ်ခု၏ အလယ်ဗဟိုတွင် ရုတ်တရက် မတွေ့မချင်း၊

လာမည့်ဘာလဲ?

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

1. ဝန်ဆောင်မှုသည် ပင်မ RDS စံနမူနာတွင် ပြဿနာများရှိသည့်အခါ သင့်လျော်သောအသွားအလာကို ကိုင်တွယ်ဖြေရှင်းရာတွင် အထောက်အကူဖြစ်စေရန် ဖတ်သာဒေတာဘေ့စ်ပုံတူများကို အသုံးပြုပါ။
2. RDS ဥပမာကို အပ်ဒိတ်လုပ်နေသည်။ လက်ရှိဗားရှင်းကိုယ်တိုင်က ပြဿနာမဟုတ်ပါဘူး။ ယင်းအစား၊ ကျွန်ုပ်တို့သည် မှားယွင်းသောလမ်းကြောင်းကို ဖယ်ရှားပစ်ချင်သည် (ကျရှုံးစဉ်အတွင်း ကျွန်ုပ်တို့လိုက်လျှောက်ခဲ့သည့်)၊ ဆော့ဖ်ဝဲလ်ကို ခေတ်မီအောင်ထားရှိခြင်းသည် အနာဂတ်တွင် ပြတ်တောက်မှုဖြစ်သည့်အခါ နောက်ထပ်အချက်တစ်ချက်ကို ဖယ်ရှားပေးမည်ဖြစ်သည်။
3. အစုအဝေးတစ်ခုလုံးတွင် ထပ်လောင်း ကက်ရှ်လုပ်ခြင်း။ ဒေတာဘေ့စ်ပေါ်ရှိ ဝန်ကို လျှော့ချနိုင်သည့် ကက်ရှ်လုပ်သည့် နေရာများကို ကျွန်ုပ်တို့ ဆက်လက်ရှာဖွေနေပါသည်။
4. ဘယ်သူက quay.io ကို ချိတ်ဆက်နေပြီး ဘာကြောင့်လဲဆိုတာ ကြည့်ဖို့ ဝဘ်အက်ပလီကေးရှင်း ဖိုင်းဝေါလ် (WAF) ကို ထည့်သွင်းခြင်း။
5. လာမည့်ထွက်ရှိမှုမှစတင်ကာ Red Hat OpenShift အစုအဖွဲ့များသည် quay.io တွင်ရရှိနိုင်သောကွန်တိန်နာပုံများကိုအခြေခံ၍ Operator Catalogs ၏မျက်နှာသာဖြင့် App Registry ကိုစွန့်လွှတ်ပါမည်။
6. App Registry အတွက် ရေရှည်အစားထိုးမှုသည် Open Container Initiative (OCI) artifact specifications များအတွက် အထောက်အပံ့ဖြစ်နိုင်သည်။ ၎င်းကို လက်ရှိတွင် မူရင်း Quay လုပ်ဆောင်ချက်အဖြစ် အကောင်အထည်ဖော်ထားပြီး သတ်မှတ်ချက်ကိုယ်တိုင် အပြီးသတ်ပြီးသည့်အခါ အသုံးပြုသူများ ရရှိနိုင်ပါသည်။

ကျွန်ုပ်တို့သည် သေးငယ်သော "startup-style" အဖွဲ့မှ ရင့်ကျက်သော SRE-driven ပလပ်ဖောင်းသို့ ပြောင်းရွှေ့ခြင်းဖြင့် အထက်ဖော်ပြပါအရာအားလုံးသည် Red Hat ၏ quay.io တွင် ရင်းနှီးမြှုပ်နှံမှု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ ကျွန်ုပ်တို့၏ဖောက်သည်အများစုသည် ၎င်းတို့၏နေ့စဥ်လုပ်ငန်း (Red Hat အပါအဝင်) တွင် quay.io ကို မှီခိုအားထားနေကြောင်း ကျွန်ုပ်တို့သိရပြီး မကြာသေးမီက ပြတ်တောက်မှုများနှင့် ဆက်လက်တိုးတက်ကောင်းမွန်လာစေရန် ကြိုးပမ်းမှုများနှင့်ပတ်သက်၍ တတ်နိုင်သမျှ ပွင့်လင်းမြင်သာမှုရှိရန် ကျွန်ုပ်တို့ကြိုးစားပါသည်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «CoreOS ကွန်တိန်နာပုံများအတွက် Red Hat အရင်းအမြစ်ဖွင့်ထားသော မှတ်ပုံတင်ကုဒ် - Quay";
• «ကျွန်ုပ်တို့၏ SRE နေ့စဉ်ဘဝမှ လက်တွေ့ကျသော ဇာတ်လမ်းများ။ အပိုင်း 2";
• «Kubernetes ရှိ pod ဦးစားပေးအရာများသည် Grafana Labs တွင် အလုပ်မလုပ်သည့်နည်း"။

source: www.habr.com