နှစ်သစ်ကူးနီးလာပြီ။ နိုင်ငံတစ်ဝှမ်းလုံးရှိ ကလေးများသည် Santa Claus ထံသို့ စာများပေးပို့ထားပြီး သို့မဟုတ် ၎င်းတို့အတွက် လက်ဆောင်များ ပြုလုပ်ထားပြီးဖြစ်ကာ လက်လီရောင်းချသူများအနက်မှ အဓိကအမှုဆောင်အရာရှိသည် အရောင်းအ၀ယ်ဖြစ်ခြင်းအတွက် ပြင်ဆင်နေပါသည်။ ဒီဇင်ဘာလတွင် ၎င်း၏ဒေတာစင်တာတွင် ဝန်အားသည် အဆများစွာတိုးလာသည်။ ထို့ကြောင့် ကုမ္ပဏီသည် ဒေတာစင်တာကို ခေတ်မီစေရန် ဆုံးဖြတ်ခဲ့ပြီး ၎င်း၏ဝန်ဆောင်မှုသက်တမ်းကုန်ဆုံးမည့် စက်ပစ္စည်းများအစား ဆာဗာအသစ် ဒါဇင်များစွာကို လည်ပတ်လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။ ဤအရာသည် ဝေ့ဝဲနေသော နှင်းပွင့်များ၏ နောက်ခံကို ဆန့်ကျင်သည့် ပုံပြင်ကို အဆုံးသတ်လိုက်ပြီး သည်းထိတ်ရင်ဖိုစရာ စတင်သည်။

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

ဆာဗာအသစ်များ ခန့်အပ်ခြင်းအား နောက်ဆုံးသတ်မှတ်ရက်နှင့် တင်းကြပ်စွာ ချိတ်ဆက်ထားသည်။ ၎င်းကို ရွှေ့ခြင်းသည် လက်ဆောင်ပေါင်း တစ်ဘီလီယံ တင်ပို့မှုနှင့် စနစ်များ၏ ရွှေ့ပြောင်းခြင်းတို့ကို အန္တရာယ်ဖြစ်စေသည်။ Father Frost နှင့် Santa Claus တို့ပါဝင်သော အဖွဲ့တစ်ဖွဲ့ပင်လျှင် ရက်စွဲကို မပြောင်းနိုင်ပါ - ဂိုဒေါင်စီမံခန့်ခွဲမှုအတွက် SAP စနစ်ကို တစ်နှစ်လျှင် တစ်ကြိမ်သာ လွှဲပြောင်းနိုင်ပါသည်။ ဒီဇင်ဘာ ၃၁ ရက်မှ ဇန်နဝါရီ ၁ ရက်အထိ၊ လက်လီရောင်းချသူ၏ ဘောလုံးကွင်း 31 အရွယ်အစားရှိသည့် ဂိုဒေါင်ကြီးများသည် ၎င်းတို့၏လုပ်ငန်းကို 1 နာရီကြာ ရပ်နားထားသည်။ ဤသည်မှာ စနစ်ကို ရွှေ့ရန် တစ်ခုတည်းသော အချိန်ကာလဖြစ်သည်။ ဆာဗာများကို မိတ်ဆက်သည့်အခါ ကျွန်ုပ်တို့တွင် အမှားအယွင်းအတွက် နေရာမရှိပါ။

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

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

OS တပ်ဆင်ခြင်းစီမံခန့်ခွဲမှု

ပထမအဆင့်သည် ရုပ်ပိုင်းဆိုင်ရာနှင့် virtual ဆာဗာများတွင် လည်ပတ်မှုစနစ်များ တပ်ဆင်ခြင်းကို စီမံခန့်ခွဲရန် စနစ်တစ်ခုဖြစ်သည်။ ၎င်းသည် အခြေခံ OS configurations များကို ဖန်တီးပေးကာ human factor ကိုဖယ်ရှားပေးသည်။

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

တပ်ဆင်မှုစီမံခန့်ခွဲမှုစနစ်အတွက် "အမြင့်ဆုံး" တာဝန်မှာ BIOS/Firmware အဆင့်မှ ဆာဗာများကို OS သို့ အလိုအလျောက် configure လုပ်ရန်ဖြစ်သည်။ ဤနေရာတွင် အများအပြားသည် စက်ကိရိယာနှင့် စနစ်ထည့်သွင်းခြင်းလုပ်ငန်းများအပေါ် မူတည်ပါသည်။ ကွဲပြားသော အသုံးအဆောင်ပစ္စည်းများအတွက် သင်စဉ်းစားနိုင်ပါသည်။ REDFISH API. အကယ်၍ ဟာ့ဒ်ဝဲအားလုံးသည် ရောင်းချသူတစ်ခုတည်းမှဖြစ်ပါက၊ အဆင်သင့်လုပ်ထားသော စီမံခန့်ခွဲမှုကိရိယာများ (ဥပမာ၊ HP ILO Amplifier၊ DELL OpenManage စသည်ဖြင့်) ကို အသုံးပြုရန် မကြာခဏ ပိုမိုအဆင်ပြေပါသည်။

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

HashiСorp Packer ကို အသုံးပြု၍ ပြင်ဆင်ထားသော နမူနာများကို အခြေခံ၍ ကျွန်ုပ်တို့သည် virtual ဆာဗာများကို ဖန်တီးထားပါသည်။ အကြောင်းရင်းမှာ အတူတူပင်ဖြစ်သည်- OS ကို ထည့်သွင်းသည့်အခါ ဖြစ်နိုင်သော လူသားအမှားများကို တားဆီးရန်။ သို့သော်၊ ရုပ်ပိုင်းဆိုင်ရာဆာဗာများနှင့်မတူဘဲ၊ Packer သည် PXE၊ ကွန်ရက်စတင်ခြင်းနှင့် VLAN အပြောင်းအလဲများအတွက် လိုအပ်မှုကို ဖယ်ရှားပေးပါသည်။ ၎င်းသည် virtual ဆာဗာများကို ဖန်တီးရန် ပိုမိုလွယ်ကူပြီး ရိုးရှင်းစေသည်။

ထမင်း။ 1. လည်ပတ်မှုစနစ်များ တပ်ဆင်ခြင်းကို စီမံခန့်ခွဲခြင်း။

လျှို့ဝှက်ချက်များကိုစီမံခန့်ခွဲ

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

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

• configuration control code တွင် တိုက်ရိုက် သို့မဟုတ် repository ရှိ ဖိုင်များတွင်၊
• အထူးပြု ဖွဲ့စည်းမှု စီမံခန့်ခွဲမှု ကိရိယာများ (ဥပမာ၊ Ansible Vault);
• CI/CD စနစ်များ (Jenkins/TeamCity/GitLab/etc.) သို့မဟုတ် ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှုစနစ်များ (Ansible Tower/Ansible AWX);
• လျှို့ဝှက်ချက်များကိုလည်း "ကိုယ်တိုင်" လွှဲပြောင်းနိုင်သည်။ ဥပမာအားဖြင့်၊ ၎င်းတို့ကို သတ်မှတ်ထားသော တည်နေရာတစ်ခုတွင် ခင်းကျင်းထားပြီး၊ ထို့နောက် ၎င်းတို့ကို ဖွဲ့စည်းမှုဆိုင်ရာ စီမံခန့်ခွဲမှုစနစ်များဖြင့် အသုံးပြုသည်။
• အထက်ဖော်ပြပါ ပေါင်းစပ်မှုအမျိုးမျိုး။

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

ဗဟိုချုပ်ကိုင်ထားသော လျှို့ဝှက်သိုလှောင်မှု HashiCorp Vault ကို အသုံးပြုခဲ့သည်။ ယင်းက ကျွန်ုပ်တို့အား ခွင့်ပြုခဲ့သည်-

• လျှို့ဝှက်ချက်များကို လုံခြုံအောင်ထားပါ။ ၎င်းတို့ကို ကုဒ်ဝှက်ထားပြီး တစ်စုံတစ်ယောက်သည် Vault ဒေတာဘေ့စ်သို့ ဝင်ရောက်ခွင့် ရရှိပါက (ဥပမာ၊ ၎င်းအား အရန်သိမ်းဆည်းမှုမှ ပြန်လည်ရယူခြင်းဖြင့်) ၎င်းတို့တွင် သိမ်းဆည်းထားသည့် လျှို့ဝှက်ချက်များကို ဖတ်နိုင်မည်မဟုတ်ပေ။
• လျှို့ဝှက်ချက်များရယူရန် မူဝါဒများကို စုစည်းပါ။ ၎င်းတို့အတွက် “ခွဲဝေချထားပေးသော လျှို့ဝှက်ချက်များ” ကိုသာ အသုံးပြုသူများနှင့် အပလီကေးရှင်းများတွင် ရရှိနိုင်သည်။
• လျှို့ဝှက်ချက်များကို ဝင်ရောက်စစ်ဆေးခြင်း။ လျှို့ဝှက်ချက်ပါရှိသော လုပ်ဆောင်ချက်များကို Vault စာရင်းစစ်မှတ်တမ်းတွင် မှတ်တမ်းတင်ထားသည်။
• လျှို့ဝှက်ချက်များဖြင့် လုပ်ဆောင်ခြင်း၏ ပြည့်စုံသော "ဘဝသံသရာ" ကို စုစည်းပါ။ ၎င်းတို့ကို ဖန်တီးနိုင်သည်၊ ရုပ်သိမ်းသည်၊ သက်တမ်းကုန်ဆုံးရက်ကို သတ်မှတ်နိုင်သည်။
• လျှို့ဝှက်ချက်များကို ရယူလိုသည့် အခြားစနစ်များနှင့် ပေါင်းစပ်ရန် လွယ်ကူသည်။
• ထို့အပြင် အဆုံးမှအဆုံး ကုဒ်ဝှက်ခြင်း၊ OS နှင့် ဒေတာဘေ့စ်အတွက် တစ်ကြိမ်စကားဝှက်များ၊ ခွင့်ပြုချက်စင်တာများ၏ လက်မှတ်များ စသည်တို့ကိုလည်း အသုံးပြုပါ။

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

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏စနစ်သို့ နောက်ထပ်အဆင့်တစ်ခုကို ထပ်ထည့်သည်- လျှို့ဝှက်ချက်များ စီမံခန့်ခွဲမှုနှင့် ဗဟိုစစ်မှန်ကြောင်း/ခွင့်ပြုချက်-

ထမင်း။ 2. လျှို့ဝှက်ချက်စီမံခန့်ခွဲမှု။

ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှု

ကျွန်ုပ်တို့သည် CMS စနစ်၏ဗဟိုသို့ရောက်ရှိသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ၎င်းသည် Ansible နှင့် Red Hat Ansible AWX ပေါင်းစပ်မှုဖြစ်သည်။

Ansible, Chef, Puppet, SaltStack အစား သုံးနိုင်ပါတယ်။ စံနှုန်းများစွာအပေါ် အခြေခံ၍ Ansible ကို ရွေးချယ်ခဲ့သည်။

• ပထမအချက်မှာ စွယ်စုံရဖြစ်သည်။ ထိန်းချုပ်ရန်အတွက် အဆင်သင့်လုပ်ထားသော module အစုံ အထင်ကြီးစရာပါပဲ။. သင့်တွင် ၎င်းကို မလုံလောက်ပါက GitHub နှင့် Galaxy တို့တွင် ရှာဖွေနိုင်သည်။
• ဒုတိယအနေဖြင့်၊ စီမံခန့်ခွဲထားသောစက်ပစ္စည်းများတွင် အေးဂျင့်များကို တပ်ဆင်ရန်နှင့် ပံ့ပိုးပေးရန် မလိုအပ်ဘဲ၊ ၎င်းတို့သည် ဝန်ကို အနှောင့်အယှက်မပေးကြောင်း သက်သေပြရန်နှင့် “စာညှပ်များ” မရှိခြင်းကို အတည်ပြုပါ။
• တတိယအနေဖြင့်၊ Ansible တွင်ဝင်ရောက်ရန်အတားအဆီးနည်းပါးသည်။ အရည်အချင်းပြည့်မီသော အင်ဂျင်နီယာတစ်ဦးသည် ထုတ်ကုန်နှင့် အလုပ်လုပ်သည့် ပထမဆုံးနေ့တွင် စာသားအတိုင်း အလုပ်လုပ်သည့် ကစားစာအုပ်ကို ရေးပေးလိမ့်မည်။

ဒါပေမယ့် ထုတ်လုပ်ရေးပတ်ဝန်းကျင်မှာ Ansible တစ်ခုတည်းက ကျွန်တော်တို့အတွက် မလုံလောက်ပါဘူး။ မဟုတ်ပါက၊ ဝင်ရောက်ခွင့်ကို ကန့်သတ်ခြင်းနှင့် စီမံခန့်ခွဲသူများ၏ လုပ်ဆောင်ချက်များကို စစ်ဆေးခြင်းနှင့်အတူ ပြဿနာများစွာ ပေါ်ပေါက်လာမည်ဖြစ်သည်။ ဝင်ရောက်ခွင့်ကို ဘယ်လိုကန့်သတ်မလဲ။ နောက်ဆုံးတွင်၊ ဌာနတစ်ခုစီအတွက် (ဖတ်ရန်- Ansible playbook ကိုဖွင့်ပါ) "၎င်း၏ကိုယ်ပိုင်" ဆာဗာအစုံကို စီမံခန့်ခွဲရန် လိုအပ်ပါသည်။ သတ်မှတ်ထားသော Ansible playbooks အချို့သောဝန်ထမ်းများကိုသာမည်သို့ခွင့်ပြုမည်နည်း။ သို့မဟုတ် Ansible လည်ပတ်နေသော ဆာဗာများနှင့် စက်ကိရိယာများပေါ်တွင် ဒေသဆိုင်ရာ ဗဟုသုတများစွာကို မထည့်သွင်းဘဲ ပလေးစာအုပ်ကို မည်သူဖွင့်ခဲ့သည်ကို မည်သို့ခြေရာခံနိုင်မည်နည်း။

ထိုကဲ့သို့သော ပြဿနာများကို ခြင်္သေ့ဝေစုက Red Hat မှ ဖြေရှင်းပေးသည်။ Ansible Towerသို့မဟုတ် သူ၏ open-source upstream ပရောဂျက် Ansible AWX. ထို့ကြောင့် ကျွန်ုပ်တို့သည် ၎င်းကို ဖောက်သည်များအတွက် နှစ်သက်သည်။

ကျွန်ုပ်တို့၏ CMS စနစ်၏ ပုံတူနှင့် နောက်ထပ်တစ်ခု ထိပါ။ Ansible playbook ကို code repository စီမံခန့်ခွဲမှုစနစ်များတွင် သိမ်းဆည်းထားသင့်သည်။ ငါတို့မှာရှိတယ်။ GitLab CE.

ထို့ကြောင့်၊ configurations များကို ၎င်းတို့ကိုယ်တိုင် Ansible/Ansible AWX/GitLab ပေါင်းစပ်ခြင်းဖြင့် စီမံခန့်ခွဲသည် (ပုံ 3 ကိုကြည့်ပါ)။ ဟုတ်ပါတယ်၊ AWX/GitLab ကို အထောက်အထားစိစစ်ခြင်းစနစ်တစ်ခုတည်းနဲ့ ပေါင်းစပ်ထားပြီး Ansible playbook ကို HashiCorp Vault နဲ့ ပေါင်းစပ်ထားပါတယ်။ “ဂိမ်း၏စည်းမျဉ်းများ” အားလုံးကို သတ်မှတ်ထားသည့် Ansible AWX မှတစ်ဆင့်သာ ထုတ်လုပ်သည့်ပတ်ဝန်းကျင်တွင် ထည့်သွင်းသည်- မည်သူက မည်သည်ကို စီမံနိုင်သည်၊ CMS အတွက် ဖွဲ့စည်းမှုဆိုင်ရာ စီမံခန့်ခွဲမှုကုဒ်ကို မည်သည့်နေရာတွင် ရယူရမည်နည်း။

ထမင်း။ 3. ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှု။

စမ်းသပ်စီမံခန့်ခွဲမှု

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

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

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

ကုဒ်ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ဖွဲ့စည်းမှုပုံစံစီမံခန့်ခွဲမှုတို့သည် ပိုမိုတည်ငြိမ်လာပြီး ကြိုတင်ခန့်မှန်းနိုင်လာပါသည်။ စဉ်ဆက်မပြတ် စမ်းသပ်မှုများကို စုစည်းရန်၊ ကျွန်ုပ်တို့သည် GitLab CI/CD toolkit ကို အသုံးပြုပြီး ရယူခဲ့သည်။ Ansible မော်လီကျူး.

ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှုကုဒ်တွင် အပြောင်းအလဲရှိသည့်အခါတိုင်း၊ GitLab CI/CD သည် Molecule ဟုခေါ်သည်-

• code syntax ကို စစ်ဆေးတယ်၊
• Docker container ကို မြှင့်၊
• ပြုပြင်ထားသော ကုဒ်ကို ဖန်တီးထားသော ကွန်တိန်နာသို့ သက်ရောက်သည်၊
• အစွမ်းအစမရှိခြင်းအတွက် အခန်းကဏ္ဍကို စစ်ဆေးပြီး ဤကုဒ်အတွက် စမ်းသပ်မှုများ လုပ်ဆောင်သည် (ဤနေရာတွင် အသေးစိတ်ဖော်ပြမှုသည် သာလွန်ကောင်းမွန်သော အခန်းကဏ္ဍအဆင့်တွင်ဖြစ်သည်၊ ပုံ 4 ကိုကြည့်ပါ)။

ကျွန်ုပ်တို့သည် Ansible AWX ကို အသုံးပြု၍ ထုတ်လုပ်မှုပတ်ဝန်းကျင်သို့ ဖွဲ့စည်းမှုပုံစံများကို ပေးပို့ထားပါသည်။ စစ်ဆင်ရေး အင်ဂျင်နီယာများသည် ကြိုတင်သတ်မှတ်ထားသော ပုံစံများမှတစ်ဆင့် ဖွဲ့စည်းမှုပုံစံပြောင်းလဲမှုများကို အသုံးပြုခဲ့ကြသည်။ AWX သည် ၎င်းကိုအသုံးပြုသည့်အခါတိုင်း GitLab မာစတာဌာနခွဲမှ ကုဒ်၏နောက်ဆုံးဗားရှင်းကို လွတ်လပ်စွာ "တောင်းဆိုခဲ့သည်" ဖြစ်သည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် စမ်းသပ်မထားသော သို့မဟုတ် ခေတ်မမီသောကုဒ်ကို အသုံးပြုခြင်းကို ဖယ်ထုတ်လိုက်ပါသည်။ ပုံမှန်အားဖြင့်၊ စမ်းသပ်ခြင်း၊ သုံးသပ်ခြင်းနှင့် အတည်ပြုပြီးနောက်မှသာ ကုဒ်သည် ပင်မဌာနခွဲသို့ ဝင်ရောက်သည်။

ထမင်း။ 4. GitLab CI/CD ရှိ အခန်းကဏ္ဍများကို အလိုအလျောက် စမ်းသပ်ခြင်း။

ထုတ်လုပ်မှုစနစ်များ လည်ပတ်မှုနှင့် ပတ်သက်သော ပြဿနာတစ်ခုလည်း ရှိပါသည်။ လက်တွေ့ဘဝတွင်၊ CMS ကုဒ်တစ်ခုတည်းဖြင့် configuration ပြောင်းလဲမှုများကို ပြုလုပ်ရန် အလွန်ခက်ခဲပါသည်။ အင်ဂျင်နီယာတစ်ဦးသည် ကုဒ်တည်းဖြတ်ခြင်း၊ စမ်းသပ်ခြင်း၊ အတည်ပြုချက်စသည်တို့ကို မစောင့်ဆိုင်းဘဲ “ဤနေရာနှင့် ယခု” ဖွဲ့စည်းမှုပုံစံကို ပြောင်းလဲရသည့်အခါ အရေးပေါ်အခြေအနေများ ဖြစ်ပေါ်လာပါသည်။

ရလဒ်အနေဖြင့်၊ လက်စွဲပြောင်းလဲမှုများကြောင့်၊ စက်ကိရိယာအမျိုးအစားတူတွင် ဖွဲ့စည်းမှုပုံစံတွင် ကွဲလွဲမှုများ ပေါ်လာသည် (ဥပမာ၊ sysctl ဆက်တင်များကို HA အစုအဝေးများပေါ်တွင် ကွဲပြားစွာ စီစဉ်သတ်မှတ်ထားသည်)။ သို့မဟုတ် စက်ကိရိယာပေါ်ရှိ အမှန်တကယ်ဖွဲ့စည်းပုံသည် CMS ကုဒ်တွင် သတ်မှတ်ထားသည့်အရာနှင့် ကွဲပြားသည်။

ထို့ကြောင့်၊ စဉ်ဆက်မပြတ် စမ်းသပ်ခြင်းအပြင်၊ ဖွဲ့စည်းတည်ဆောက်ပုံ ကွဲလွဲမှုများကို ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်ကို စစ်ဆေးပါသည်။ ကျွန်ုပ်တို့သည် အရိုးရှင်းဆုံးရွေးချယ်ခွင့်ကို ရွေးချယ်ခဲ့သည်- အပြောင်းအလဲများကို အသုံးမပြုဘဲ၊ စီစဉ်ထားသောနှင့် အမှန်တကယ်ဖွဲ့စည်းမှုကြားတွင် ကွဲလွဲမှုအားလုံးကို အကြောင်းကြားခြင်းဖြင့် "dry run" မုဒ်တွင် CMS configuration ကုဒ်ကို လုပ်ဆောင်နေသည်။ ထုတ်လုပ်ရေးဆာဗာများတွင် “—စစ်ဆေး” ရွေးချယ်မှုဖြင့် Ansible playbook အားလုံးကို အခါအားလျော်စွာ လုပ်ဆောင်ခြင်းဖြင့် ၎င်းကို ကျွန်ုပ်တို့ အကောင်အထည်ဖော်ခဲ့သည်။ အမြဲလိုလို၊ Ansible AWX သည် ပလေးစာအုပ်ကို စတင်ထုတ်ဝေပြီး ခေတ်နှင့်အမီ ထိန်းသိမ်းရန် တာဝန်ရှိသည် (ပုံ 5 ကိုကြည့်ပါ)။

ထမင်း။ 5. Ansible AWX တွင် ဖွဲ့စည်းမှုကွဲလွဲမှုများကို စစ်ဆေးပါ။

စစ်ဆေးပြီးနောက် AWX သည် စီမံခန့်ခွဲသူများထံ ကွဲလွဲမှုအစီရင်ခံချက်ကို ပေးပို့သည်။ ၎င်းတို့သည် ပြဿနာရှိသော ဖွဲ့စည်းမှုပုံစံကို လေ့လာပြီးနောက် ချိန်ညှိထားသော ပလေးစာအုပ်များမှတစ်ဆင့် ၎င်းကို ပြုပြင်ပါ။ ဤသည်မှာ ကျွန်ုပ်တို့သည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်တွင် ဖွဲ့စည်းမှုပုံစံကို ထိန်းသိမ်းထားပုံဖြစ်ပြီး CMS သည် အမြဲတမ်းနောက်ဆုံးပေါ်နှင့် ထပ်တူပြုပါသည်။ CMS ကုဒ်ကို “ထုတ်လုပ်မှု” ဆာဗာများတွင် အသုံးပြုသောအခါ ၎င်းသည် မနှစ်မြို့ဖွယ် “အံ့ဖွယ်များ” ကို ဖယ်ရှားပေးသည်။

ယခု ကျွန်ုပ်တို့တွင် Ansible AWX/GitLab/Molecule (ပုံ 6) ပါ၀င်သည့် အရေးကြီးသောစမ်းသပ်မှုအလွှာတစ်ခုရှိသည်။

ထမင်း။ 6. စမ်းသပ်စီမံခန့်ခွဲမှု။

ခက်သလား? ကျွန်တော် မငြင်းခုန်ပါဘူး။ သို့သော် ထိုသို့သော ရှုပ်ထွေးသော configuration management သည် server configuration ၏ အလိုအလျောက်လုပ်ဆောင်ခြင်းဆိုင်ရာ မေးခွန်းများစွာအတွက် ပြည့်စုံသောအဖြေတစ်ခု ဖြစ်လာခဲ့သည်။ ယခုအခါ လက်လီရောင်းချသူ၏ စံဆာဗာများတွင် အမြဲတမ်း တင်းကျပ်စွာ သတ်မှတ်ဖွဲ့စည်းမှုတစ်ခု ရှိနေပါသည်။ CMS သည် အင်ဂျင်နီယာတစ်ဦးနှင့်မတူဘဲ လိုအပ်သောဆက်တင်များကိုထည့်သွင်းရန်၊ အသုံးပြုသူများကိုဖန်တီးကာ လိုအပ်သောဆက်တင်များစွာ သို့မဟုတ် ရာပေါင်းများစွာကို လုပ်ဆောင်ရန်မေ့လိမ့်မည်မဟုတ်ပါ။

ယနေ့ခေတ် ဆာဗာများနှင့် ပတ်ဝန်းကျင်များ၏ ဆက်တင်များတွင် "လျှို့ဝှက်အသိပညာ" မရှိပါ။ လိုအပ်သောအင်္ဂါရပ်များအားလုံးကို playbook တွင်ပြသထားသည်။ တီထွင်ဖန်တီးနိုင်စွမ်းနှင့် မရေရာသော ညွှန်ကြားချက်များ မရှိတော့ပါ-"၎င်းကို ပုံမှန် Oracle ကဲ့သို့ ထည့်သွင်းပါ၊ သို့သော် သင်သည် sysctl ဆက်တင်အချို့ကို သတ်မှတ်ပြီး လိုအပ်သော UID ဖြင့် အသုံးပြုသူများကို ပေါင်းထည့်ရန် လိုအပ်သည်။ ဒီကောင်တွေကို မေးကြည့်တော့ သူတို့က သိတယ်။"။

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

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

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

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

စာရေးသူ- Sergey Artemov၊ ဌာနဗိသုကာပညာရှင် DevOps ဖြေရှင်းချက်များ "ဂျက်လေယာဉ်အချက်အလက်စနစ်များ"

source: www.habr.com