Qrator filtering network configuration management စနစ်

TL; DR: ကျွန်ုပ်တို့၏အတွင်းပိုင်းကွန်ရက်ဖွဲ့စည်းပုံပြင်ဆင်မှုစီမံခန့်ခွဲမှုစနစ် QControl ၏ client-ဆာဗာဗိသုကာ၏ဖော်ပြချက်။ ၎င်းသည် endpoints များကြားတွင် ချုံ့ခြင်းမရှိဘဲ gzip ထုပ်ပိုးထားသော မက်ဆေ့ချ်များနှင့် အလုပ်လုပ်သော အလွှာနှစ်လွှာ သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကို အခြေခံထားသည်။ ဖြန့်ဝေထားသော routers များနှင့် endpoints များသည် configuration updates များကို လက်ခံရရှိကြပြီး protocol ကိုယ်တိုင်က localized intermediate relays များ တပ်ဆင်ခြင်းကို ခွင့်ပြုပါသည်။ စနစ်သည် နိယာမပေါ်တွင် တည်သည်။ ကွဲပြားသော အရန်သိမ်းဆည်းခြင်း။ (“လတ်တလော တည်ငြိမ်သော”၊ အောက်တွင် ရှင်းပြထားသည်) နှင့် ဖွဲ့စည်းမှုဖိုင်များကို တင်ဆက်ရန်အတွက် JMESpath query language ကို Jinja templateing engine နှင့်အတူ အသုံးပြုပါသည်။

Qrator Labs သည် ကမ္ဘာလုံးဆိုင်ရာ ဖြန့်ဝေတိုက်ခိုက်မှု လျှော့ချရေးကွန်ရက်ကို လုပ်ဆောင်ပါသည်။ ကျွန်ုပ်တို့၏ကွန်ရက်သည် anycast မူအရ လုပ်ဆောင်နေပြီး subnet များကို BGP မှတစ်ဆင့် ကြော်ငြာထားသည်။ ကမ္ဘာမြေ၏ ဒေသအများအပြားတွင် တည်ရှိနေသည့် BGP ကွန်ရက်တစ်ခုဖြစ်သည့်အတွက်၊ ကျွန်ုပ်တို့သည် အင်တာနက်၏ အူတိုင်ဖြစ်သော Tier-1 အော်ပရေတာများနှင့် တရားမ၀င်အသွားအလာများကို လုပ်ဆောင်နိုင်ပြီး စစ်ထုတ်နိုင်ပါသည်။

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

အစအဦး၌ နှုတ်ကပတ်တော်ရှိ၏။ အပ်ဒိတ်တစ်ခုလိုအပ်သည့်အတွက် ဆက်သွယ်ရေးပရိုတိုကောသည် လျင်မြန်စွာဖြစ်လာသည်။

QControl ၏တည်ရှိမှု၏အခြေခံအုတ်မြစ်နှင့် ဤပရိုတိုကောမျိုးကိုတည်ဆောက်ရာတွင် အချိန်နှင့်ရင်းမြစ်များစွာအသုံးပြုရခြင်း၏အဓိကအကြောင်းရင်းမှာ တစ်ခုတည်းသောခွင့်ပြုချက်ရှိသောဖွဲ့စည်းပုံဖွဲ့စည်းပုံကိုရယူရန်လိုအပ်ပြီး နောက်ဆုံးတွင် ကျွန်ုပ်တို့၏ရောက်ရှိနေသည့်နေရာများကို တစ်ပြိုင်တည်းလုပ်ဆောင်ရန် လိုအပ်ပါသည်။ အဲဒါကို။ သိုလှောင်မှုကိုယ်တိုင်က QControl ဖွံ့ဖြိုးတိုးတက်မှုအတွင်း လိုအပ်ချက်များစွာထဲမှတစ်ခုသာဖြစ်သည်။ ထို့အပြင်၊ လက်ရှိရောက်ရှိနေသည့်နေရာများ (POP)၊ ဒေတာအတည်ပြုခြင်းအတွက် စမတ်ကျသော (နှင့်စိတ်ကြိုက်ပြင်ဆင်နိုင်သော) နည်းလမ်းများအပြင် ဝင်ရောက်ထိန်းချုပ်မှုဆိုင်ရာ ဝန်ဆောင်မှုများနှင့် လက်ရှိစီစဉ်ထားသော ဝန်ဆောင်မှုများနှင့် ပေါင်းစပ်မှုများလည်း လိုအပ်ပါသည်။ ၎င်းအပြင်၊ ကျွန်ုပ်တို့သည် ဖိုင်များကို ပြုပြင်မွမ်းမံခြင်းထက် ကွန်မန်းများကို အသုံးပြု၍ ထိုကဲ့သို့သော စနစ်တစ်ခုကိုလည်း ထိန်းချုပ်လိုပါသည်။ QControl မတိုင်မီ၊ ဒေတာကို ကိုယ်တိုင်နီးပါး ရောက်ရှိနေသည့်နေရာများသို့ ပေးပို့ခဲ့သည်။ တည်ရှိနေသည့်နေရာများထဲမှ တစ်ခုသည် မရနိုင်ဘဲ၊ ၎င်းကို နောက်ပိုင်းတွင် အပ်ဒိတ်လုပ်ရန် မေ့သွားပါက၊ ဖွဲ့စည်းမှုပုံစံသည် ထပ်တူကျသွားမည်ဖြစ်ပြီး ၎င်းကို အရန်ကူးယူရန် အချိန်ဖြုန်းနေရမည်ဖြစ်သည်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါအစီအစဥ်ကို အကောင်အထည်ဖော်ခဲ့ပါသည်။

configuration server သည် data validation နှင့် storage အတွက် တာဝန်ရှိသည်၊ router တွင် clients နှင့် support teams များမှ configuration updates များကို server သို့ လက်ခံကာ ထုတ်လွှင့်သည့် endpoints အများအပြားရှိပြီး server မှ server မှ တည်ရှိနေသော point များအထိ ရှိပါသည်။

ကမ္ဘာတစ်ဝှမ်းရှိ အင်တာနက်ချိတ်ဆက်မှုအရည်အသွေးသည် ကျယ်ပြန့်စွာကွဲပြားဆဲဖြစ်သည် - ဤအချက်ကိုဖော်ပြရန်၊ ပရာ့ဂ်၊ ချက်သမ္မတနိုင်ငံမှ စင်ကာပူနှင့် ဟောင်ကောင်အထိ ရိုးရှင်းသော MTR ကို ကြည့်ကြပါစို့။

Prague မှ Singapore သို့ MTR

ဟောင်ကောင်မှာလည်း အလားတူပါပဲ။

High latency ဆိုသည်မှာ အရှိန်နိမ့်သည်။ ထို့အပြင် packet ဆုံးရှုံးမှုလည်း ရှိပါသည်။ ဗဟိုချုပ်ကိုင်မှုလျှော့ချထားသော စနစ်များကို တည်ဆောက်သည့်အခါ အမြဲတမ်းထည့်သွင်းစဉ်းစားရမည့် ဤပြဿနာအတွက် ချန်နယ်အကျယ်သည် လျော်ကြေးမပေးပေ။

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

မကြာသေးမီက တည်ငြိမ်သော ဒီဇိုင်း

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

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

ကျန်ရှိနေသေးသည်မှာ မကြာသေးမီက ကြီးမားလွန်းသောကြောင့်၊ ဥပမာအားဖြင့် လတ်ဆတ်သော တည်ငြိမ်သော ဖွဲ့စည်းမှုပုံစံကို အခါအားလျော်စွာ ပေးပို့ရန် ကျန်ရှိနေသေးသည်။ ဤနေရာ၌လည်း အရေးကြီးသည်မှာ ကျွန်ုပ်တို့သည် လက်ခံသူ တစ်ဦးချင်းစီအတွက် စိတ်ပူစရာမလိုဘဲ ဤအပ်ဒိတ်များအားလုံးကို ထုတ်လွှင့်ခြင်း/အမြောက်အများပေးသည့်မုဒ်တွင် ပေးပို့ခြင်းနှင့် ၎င်းတို့၏ ဒေတာအပိုင်းအစများကို စုစည်းနိုင်သည့်စွမ်းရည်ကို စိတ်ပူစရာမလိုဘဲ ပေးပို့ခြင်းဖြစ်ပါသည်။ လူတိုင်းတွင် မှန်ကန်သောတည်ငြိမ်မှုရှိကြောင်း ကျွန်ုပ်တို့သေချာသည်နှင့်၊ ကျွန်ုပ်တို့သည် လတ်တလောအသစ်များကိုသာ ပေးပို့ပါသည်။ ဤအရာသည် အလုပ်လုပ်ကြောင်း ရှင်းရှင်းလင်းလင်း သိထိုက်ပါသလား။ အလုပ်များ။ Stable ကို configuration server နှင့် လက်ခံသူများတွင် ကက်ရှ်လုပ်ထားပြီး မကြာသေးမီက လိုအပ်သလို ဖန်တီးထားသည်။

နှစ်ဆင့် သယ်ယူပို့ဆောင်ရေး ဗိသုကာ

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏သယ်ယူပို့ဆောင်ရေးကို အဘယ်ကြောင့် အဆင့်နှစ်ဆင့်ဖြင့် တည်ဆောက်ခဲ့သနည်း။ အဖြေက တော်တော်ရိုးရှင်းပါတယ် - ကျွန်ုပ်တို့သည် OSI မော်ဒယ်မှ လှုံ့ဆော်မှုရယူပြီး ၎င်း၏သယ်ယူပို့ဆောင်ရေးနှင့် အပလီကေးရှင်းအလွှာများဖြင့် အဆင့်မြင့်မားသော ယုတ္တိဗေဒမှ လမ်းကြောင်းကို ခွဲထုတ်လိုပါသည်။ ကျွန်ုပ်တို့သည် သယ်ယူပို့ဆောင်ရေးပရိုတိုကော၏အခန်းကဏ္ဍအတွက် Thrift နှင့် ထိန်းချုပ်မှုမက်ဆေ့ခ်ျ၏အဆင့်မြင့်ဖော်မတ်အတွက် msgpack နံပါတ်စဉ်ဖော်မတ်ကို အသုံးပြုထားသည်။ ထို့ကြောင့် router (Multicast/broadcast/relay) သည် msgpack အတွင်းကို မကြည့်ဘဲ၊ အကြောင်းအရာများကို ပြန်ဖွင့်ခြင်း သို့မဟုတ် ထုပ်ပိုးခြင်းမပြုဘဲ ဒေတာများကိုသာ ပေးပို့ခြင်းဖြစ်သည်။

Thrift (အင်္ဂလိပ်မှ - “thrift” ဟု အသံထွက်သော [θrift]) သည် မတူညီသော ပရိုဂရမ်းမင်းဘာသာစကားများအတွက် ဝန်ဆောင်မှုများကို သတ်မှတ်ရန်နှင့် ဖန်တီးရန် အသုံးပြုသည့် ကြားခံဖော်ပြချက်ဘာသာစကားတစ်ခုဖြစ်သည်။ ၎င်းသည် အဝေးထိန်းစနစ်ခေါ်ဆိုမှု (RPC) အတွက် မူဘောင်တစ်ခုဖြစ်သည်။ ဘာသာစကားများအကြား ပိုမိုထိရောက်ပြီး လွယ်ကူစွာ လုပ်ဆောင်နိုင်သော ဝန်ဆောင်မှုများကို ဖွံ့ဖြိုးတိုးတက်စေရန် ဆော့ဖ်ဝဲပိုက်လိုင်းတစ်ခုအား ကုဒ်ထုတ်လုပ်သည့်အင်ဂျင်နှင့် ပေါင်းစပ်ထားသည်။

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

protobuf / gRPC ကဲ့သို့သော အခြားရွေးချယ်စရာများ ရှိသည်၊ သို့သော် ကျွန်ုပ်တို့၏ပရောဂျက်ကို စတင်သောအခါ၊ gRPC သည် အလွန်သစ်လွင်ပြီး ၎င်းကို ကျွန်ုပ်တို့ မယူဝံ့ပါ။

ဟုတ်ပါတယ်၊ ငါတို့ (တကယ်တော့ ရှိသင့်တယ်) ငါတို့ကိုယ်ပိုင်စက်ဘီးကို ဆောက်နိုင်ခဲ့တယ်။ Client-Server Architecture သည် Thrift တွင် Router တစ်ခုတည်ဆောက်ခြင်းနှင့် နှိုင်းယှဉ်ပါက ကျွန်ုပ်တို့လိုအပ်သောအရာအတွက် ပရိုတိုကောတစ်ခုဖန်တီးရန် ပိုမိုလွယ်ကူမည်ဖြစ်သည်။ တစ်နည်းမဟုတ်တစ်နည်း၊ ကိုယ်တိုင်ရေးထားသော ပရိုတိုကောများနှင့် လူကြိုက်များသော စာကြည့်တိုက်များ၏ အကောင်အထည်ဖော်မှုများအပေါ် အစဉ်အလာ ဘက်လိုက်မှုများ ရှိနေသည် (အကြောင်းပြချက်ကောင်းကြောင့်)၊ ထို့အပြင် ဆွေးနွေးမှုများအတွင်း မေးခွန်းတစ်ခု အမြဲပေါ်လာသည်- "ဤအရာကို အခြားဘာသာစကားသို့ မည်ကဲ့သို့ ပို့ရမည်နည်း။" ဒါနဲ့ ကျွန်တော်တို့ ချက်ချင်း စက်ဘီးစီးဖို့ စိတ်ကူးကို ထုတ်လိုက်တယ်။

Msgpack သည် JSON နှင့် ဆင်တူသော်လည်း ပိုမြန်ပြီး ပိုသေးငယ်သည်။ ၎င်းသည် ဒေတာများကို ဘာသာစကားများစွာအကြား ဖလှယ်နိုင်စေမည့် ဒွိဒေတာ အမှတ်စဉ်ဖော်မတ်တစ်ခုဖြစ်သည်။

ပထမအဆင့်တွင် မက်ဆေ့ချ်ပေးပို့ရန် router အတွက် လိုအပ်သော အနိမ့်ဆုံးအချက်အလက်များနှင့်အတူ Thrift ရှိသည်။ ဒုတိယအဆင့်တွင် ထုပ်ပိုးထားသော msgpack ဖွဲ့စည်းပုံများရှိသည်။

JSON ထက်စာရင် ပိုမြန်ပြီး ပိုကျစ်လစ်တဲ့အတွက် msgpack ကို ရွေးချယ်ခဲ့ပါတယ်။ သို့သော် ပို၍အရေးကြီးသည်မှာ၊ ၎င်းသည် ကျွန်ုပ်တို့၏ "လတ်တလောတည်ငြိမ်သော" အစီအစဉ်အတွက် အရေးကြီးသော ဒေတာမရှိခြင်းကို ညွှန်ပြသည့် အကြမ်း binaries သို့မဟုတ် အထူးအရာဝတ္ထုများကို ဖြတ်သန်းခြင်းကဲ့သို့သော အေးမြသောအင်္ဂါရပ်များကို အသုံးပြုနိုင်ရန် စိတ်ကြိုက်ဒေတာအမျိုးအစားများကို ပံ့ပိုးပေးပါသည်။

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

Jinja
အချို့သော စားသုံးသူများအတွက်၊ ကျွန်ုပ်တို့သည် configuration ကို ဖိုင်အဖြစ်ပြောင်းရန် လိုအပ်သည် - ထို့ကြောင့် ကျွန်ုပ်တို့သည် template engine ကိုအသုံးပြုပြီး Jinja သည် သိသာထင်ရှားသောရွေးချယ်မှုဖြစ်သည်။ ၎င်း၏အကူအညီဖြင့်၊ ကျွန်ုပ်တို့သည် ဦးတည်ရာသို့လက်ခံရရှိသည့် ပုံစံပလိတ်နှင့် ဒေတာမှ စီစဉ်ဖွဲ့စည်းမှုဖိုင်တစ်ခုကို ထုတ်ပေးပါသည်။

ဖွဲ့စည်းမှုပုံစံဖိုင်တစ်ခုထုတ်လုပ်ရန် ကျွန်ုပ်တို့သည် JMESPath တောင်းဆိုချက်၊ FS ရှိဖိုင်တည်နေရာအတွက် နမူနာတစ်ခုနှင့် config ကိုယ်တိုင်အတွက် နမူနာတစ်ခု လိုအပ်ပါသည်။ ဤအဆင့်တွင် ဖိုင်ခွင့်ပြုချက်များကို ရှင်းလင်းရန် အကြံကောင်းတစ်ခုဖြစ်သည်။ ဤအရာအားလုံးကို ဖိုင်တစ်ခုတွင် အောင်မြင်စွာ ပေါင်းစပ်ထားသည် - ဖွဲ့စည်းမှုပုံစံပုံစံမစတင်မီ၊ ကျန်အရာများကို ဖော်ပြသည့် YAML ဖော်မတ်တွင် ခေါင်းစီးတစ်ခုကို ထည့်ထားသည်။

ဥပမာ:

---
selector: "[@][?@.fft._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


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

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

configuration server နှင့် configuration လက်ခံသူများအကြား ဆက်သွယ်မှုကို ရိုးရှင်းစေရန် မကြာသေးမီက တည်ငြိမ်သော အပ်ဒိတ်အစီအစဉ်ကို အသုံးပြု၍ ဤအရာအားလုံးကို ကျွန်ုပ်တို့ လုပ်ဆောင်နိုင်ခဲ့ပါသည်။ အကြောင်းအရာ-အမှီအခိုကင်းသော ဒေတာလမ်းကြောင်းကို ပံ့ပိုးရန် အလွှာနှစ်လွှာ ပရိုတိုကောကို အသုံးပြုခြင်း။ Jinja-based configuration generation engine ကို ဖြန့်ဝေထားသော filtering network တွင် အောင်မြင်စွာ ပေါင်းစပ်ထားသည်။ ဤစနစ်သည် ကျွန်ုပ်တို့၏ ဖြန့်ဝေမှုနှင့် ကွဲပြားနေသော အရံပစ္စည်းများအတွက် ကျယ်ပြန့်သော ဖွဲ့စည်းမှုပုံစံများကို ပံ့ပိုးပေးပါသည်။

အကြောင်းအရာကို ရေးသားရာတွင် သင်၏အကူအညီအတွက် ကျေးဇူးတင်ပါသည်။ VolanDamrod, serenheit, NoN.

အင်္ဂလိပ်ဗားရှင်း ပို့စ်။

source: www.habr.com