Ansible- 120 VM ဖွဲ့စည်းမှုပုံစံကို CoreOS မှ CentOS သို့ 18 လအတွင်း ရွှေ့ပြောင်းခြင်း

ဤသည်မှာ မိန့်ခွန်း၏ စာသားဖြစ်သည်။ DevopsConf 2019-10-01 и SPbLUG 2019-09-25.

ဤသည်မှာ ကိုယ်တိုင်ရေးထားသော ဖွဲ့စည်းမှုပုံစံ စီမံခန့်ခွဲမှုစနစ်ကို အသုံးပြုသည့် ပရောဂျက်တစ်ခု၏ ဇာတ်လမ်းဖြစ်ပြီး Ansible သို့ ပြောင်းရွှေ့ရန် အဘယ်ကြောင့် အချိန် 18 လ ကြာသည်။

နေ့အမှတ် -ХХХ: အစမပြုမီ

အစပိုင်းတွင်၊ အခြေခံအဆောက်အအုံတွင် Hyper-V ကိုအသုံးပြုသည့် သီးခြား host အများအပြားပါဝင်သည်။ virtual machine တစ်ခုကို ဖန်တီးရာတွင် အဆင့်များစွာ လိုအပ်သည်- ဒစ်များကို မှန်ကန်သောနေရာတွင် ထားရှိခြင်း၊ DNS ကို စာရင်းသွင်းခြင်း၊ DHCP သိမ်းဆည်းခြင်း၊ VM configuration ကို git repository တွင် ထည့်သွင်းခြင်း။ ဤလုပ်ငန်းစဉ်ကို တစ်စိတ်တစ်ပိုင်းစက်မှုစနစ်ဖြင့် ပြုပြင်ထားသော်လည်း ဥပမာအားဖြင့်၊ VM များကို လက်ခံသူအချင်းချင်း လက်ဖြင့် ဖြန့်ဝေသည်။ သို့သော် ဥပမာအားဖြင့်၊ developer များသည် git တွင် VM configuration ကိုပြင်ပြီး VM ကို reboot လုပ်ခြင်းဖြင့် ၎င်းကို အသုံးပြုနိုင်သည်။

စိတ်ကြိုက်ဖွဲ့စည်းမှုစီမံခန့်ခွဲမှုဖြေရှင်းချက်

မူလစိတ်ကူးကို IaC အဖြစ် စိတ်ကူးထားပါသည်- ပြန်လည်စတင်ချိန်တွင် ၎င်းတို့၏ အခြေအနေကို သုညသို့ ပြန်လည်သတ်မှတ်သည့် နိုင်ငံမဲ့ VM အများအပြား။ VM configuration management ကဘာလဲ။ ကိန်းဂဏန်းအရ ရိုးရှင်းပုံရသည်-

1. VM အတွက် static MAC ကို ပုံဖော်ထားသည်။
2. CoreOS ပါသော ISO နှင့် boot disk ကို VM နှင့် ချိတ်ဆက်ထားသည်။
3. CoreOS သည် ၎င်း၏ IP ကို ​​အခြေခံ၍ WEB ဆာဗာမှ ဒေါင်းလုဒ်လုပ်ခြင်းဖြင့် စိတ်ကြိုက်ပြင်ဆင်ခြင်း script ကို စတင်သည်။
4. script သည် IP လိပ်စာအပေါ်အခြေခံ၍ SCP မှတစ်ဆင့် VM ဖွဲ့စည်းမှုပုံစံကို ဒေါင်းလုဒ်လုပ်သည်။
5. systemd unit ဖိုင်များနှင့် bash scripts များ၏ footcloth ကို စတင်လိုက်ပြီဖြစ်သည်။

ဤဖြေရှင်းချက်တွင် သိသာထင်ရှားသော ပြဿနာများစွာရှိသည်။

1. CoreOS ISO ကို ရပ်တန့်ထားသည်။
2. VM များကို ရွှေ့ပြောင်းခြင်း/ဖန်တီးသည့်အခါ ရှုပ်ထွေးသော အလိုအလျောက်လုပ်ဆောင်မှုများနှင့် မှော်အတတ်များစွာ။
3. အပ်ဒိတ်လုပ်ရာတွင် ခက်ခဲခြင်းနှင့် အချို့သောဆော့ဖ်ဝဲလ်ဗားရှင်းတစ်ခု လိုအပ်သည့်အခါ။ kernel modules တွေနဲ့ ပိုပျော်စရာကောင်းပါတယ်။
4. ဒေတာမပါဘဲ VM များကို မရနိုင်ပါ၊ ဆိုလိုသည်မှာ၊ နောက်ထပ်အသုံးပြုသူဒေတာကို တပ်ဆင်ထားသည့် ဒစ်တစ်ခုဖြင့် VM များပေါ်လာသည်။
5. တစ်စုံတစ်ယောက်သည် systemd unit dependencies ကို အဆက်မပြတ် ဖောက်လုပ်နေပြီး CoreOS ကို ပြန်လည်စတင်သောအခါတွင် အေးခဲသွားမည်ဖြစ်သည်။ CoreOS တွင်ရရှိနိုင်သောကိရိယာများကို အသုံးပြု၍ ၎င်းကိုဖမ်းရန်ခက်ခဲသည်။
6. လျှို့ဝှက်ချက်စီမံခန့်ခွဲမှု။
7. CM မရှိခဲ့ပါ။ CoreOS အတွက် bash နှင့် YML configs များရှိသည်။

VM configuration ကိုအသုံးပြုရန်၊ ၎င်းကို ပြန်လည်စတင်ရန် လိုအပ်သော်လည်း ၎င်းသည် ပြန်လည်စတင်နိုင်မည်မဟုတ်ပေ။ သိသာထင်ရှားသောပြဿနာတစ်ခုဟုထင်ရသော်လည်း၊ မြဲမြံသောဒစ်များမရှိပါ - မှတ်တမ်းများကိုသိမ်းဆည်းရန်နေရာမရှိပါ။ ကောင်းပြီ၊ မှတ်တမ်းများပေးပို့နိုင်ရန် kernel loading option ကိုထည့်လိုက်ရအောင်။ ဒါပေမယ့် မဟုတ်ဘူး၊ ဘယ်လောက်ရှုပ်ထွေးလဲ။

Day #0- ပြဿနာကို အသိအမှတ်ပြုပါ။

၎င်းသည် ပုံမှန်အတိုင်း ဖွံ့ဖြိုးတိုးတက်မှု အခြေခံအဆောက်အအုံများဖြစ်သည်- jenkins၊ စမ်းသပ်မှုပတ်ဝန်းကျင်၊ စောင့်ကြည့်မှု၊ မှတ်ပုံတင်မှု။ CoreOS သည် k8s အစုအဝေးများကို hosting အတွက် ဒီဇိုင်းထုတ်ထားသည်။ ပြဿနာက CoreOS ကို ဘယ်လိုသုံးလဲ။ ပထမအဆင့်မှာ stack တစ်ခုကို ရွေးချယ်ခြင်းဖြစ်သည်။ ကျွန်ုပ်တို့သည်-

1. CentOS အခြေခံဖြန့်ချီရေးအနေနဲ့ ဆိုတော့ ၎င်းသည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်နှင့် အနီးစပ်ဆုံး ဖြန့်ဖြူးမှုဖြစ်သည်။
2. မြင်မရဘူး configuration management အတွက် ဆိုတော့ အဲဒီအပေါ်မှာ ကျယ်ကျယ်ပြန့်ပြန့် စစ်ဆေးမှုတွေ ရှိခဲ့ပါတယ်။
3. Jenkins ရှိပြီးသား လုပ်ငန်းစဉ်များကို အလိုအလျောက်လုပ်ဆောင်ရန် မူဘောင်တစ်ခုအနေဖြင့် အဘယ်ကြောင့်ဆိုသော်၊ ဖွံ့ဖြိုးတိုးတက်ရေးလုပ်ငန်းစဉ်များအတွက် တက်ကြွစွာအသုံးပြုထားပြီးဖြစ်သည်။
4. က Hyper-V ကို virtualization ပလပ်ဖောင်းအဖြစ်။ ဇာတ်လမ်း၏ နယ်ပယ်ကို ကျော်လွန်သွားသော အကြောင်းရင်းများစွာ ရှိသော်လည်း အတိုချုပ်အားဖြင့် - ကျွန်ုပ်တို့သည် တိမ်များကို အသုံးမပြုနိုင်ပါ၊ ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် hardware ကို အသုံးပြုရပါမည်။

နံပါတ် 30 ရက်- တည်ဆဲသဘောတူညီချက်များကို ပြင်ဆင်ခြင်း - သဘောတူညီချက်များကို Code အဖြစ်

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

1. VM များကို စီစဉ်သတ်မှတ်ပါ။

Ansible သည် ဤအရာကို ကောင်းမွန်စွာ လုပ်ဆောင်သည်။ ခန္ဓာကိုယ်လှုပ်ရှားမှု အနည်းဆုံးဖြင့် VM configuration များကို ထိန်းချုပ်နိုင်သည်-

1. git repository တစ်ခုဖန်တီးပါ။
2. ကျွန်ုပ်တို့သည် VM များစာရင်းကို စာရင်းသေတ္တာများ၊ ပြခန်းစာအုပ်များနှင့် အခန်းကဏ္ဍများတွင် ထည့်သွင်းထားသည်။
3. Ansible ကို သင်သုံးနိုင်သည့် အထူး jenkins slave ကို ကျွန်ုပ်တို့ တည်ဆောက်နေပါသည်။
4. ကျွန်ုပ်တို့သည် အလုပ်တစ်ခုဖန်တီးပြီး Jenkins ကို စီစဉ်သတ်မှတ်ပေးသည်။

ပထမလုပ်ငန်းစဉ် အဆင်သင့်ဖြစ်ပါပြီ။ သဘောတူညီချက်တွေ ပြင်တယ်။

2. VM အသစ်ကို ဖန်တီးပါ။

ဒီမှာက အရာအားလုံးက သိပ်အဆင်မပြေဘူး။ Linux မှ Hyper-V တွင် VM များကိုဖန်တီးရန် အလွန်အဆင်မပြေပါ။ ဤလုပ်ငန်းစဉ်ကို စက်ကိရိယာအဖြစ် ပြောင်းလဲရန် ကြိုးပမ်းမှုများထဲမှ တစ်ခုမှာ-

1. Ansbile သည် WinRM မှတစ်ဆင့် windows host သို့ ချိတ်ဆက်သည်။
2. Ansible သည် powershell script ကို run သည်။
3. Powershell script သည် VM အသစ်တစ်ခုကို ဖန်တီးသည်။
4. Hyper-V/ScVMM ကိုအသုံးပြု၍ ဧည့်သည် OS တွင် VM ကိုဖန်တီးသောအခါ၊ လက်ခံသူအမည်ကို စီစဉ်သတ်မှတ်ထားသည်။
5. DHCP ငှားရမ်းမှုကို အပ်ဒိတ်လုပ်သောအခါ၊ VM သည် ၎င်း၏ hostname ကို ပေးပို့သည်။
6. Domain Controller ဘက်မှ Standard ddns & dhcp ပေါင်းစည်းမှုသည် DNS မှတ်တမ်းကို configure လုပ်သည်။
7. သင်၏စာရင်းထဲသို့ VM ကိုထည့်နိုင်ပြီး Ansible ဖြင့် စီစဉ်သတ်မှတ်နိုင်သည်။

3. VM နမူနာပုံစံကို ဖန်တီးပါ။

သူတို့က ဒီမှာ ဘာမှ မထွင်ဘူး - သူတို့က ထုပ်ပိုးတာကို ယူသွားတယ်။

1. packer ကိုထည့်ပါ၊ git repository သို့ kickstart config ကိုထည့်ပါ။
2. hyper-v နှင့် Packer ဖြင့် အထူး jenkins slave ကို စနစ်ထည့်သွင်းခြင်း။
3. ကျွန်ုပ်တို့သည် အလုပ်တစ်ခုဖန်တီးပြီး Jenkins ကို စီစဉ်သတ်မှတ်ပေးသည်။

ဒီလင့်ခ်က ဘယ်လိုအလုပ်လုပ်လဲ-

1. Packer သည် VM အလွတ်တစ်ခုကို ဖန်တီးပြီး ISO ကို ကောက်ယူသည်။
2. VM boots တွင်၊ Packer သည် ကျွန်ုပ်တို့၏ kickstart ဖိုင်ကို floppy disk သို့မဟုတ် http မှအသုံးပြုရန်အတွက် bootloader ထဲသို့ command ဝင်လာပါသည်။
3. Anaconda ကို ကျွန်ုပ်တို့၏ config ဖြင့် စတင်လိုက်သည်၊ နှင့် ကနဦး OS configuration ပြီးပါပြီ။
4. Packer သည် VM ကိုရရှိနိုင်ရန်စောင့်ဆိုင်းနေသည်။
5. VM အတွင်းရှိ Packer သည် စက်တွင်းမုဒ်တွင် အသုံးပြုနိုင်သည်။
6. Ansible သည် အဆင့် #1 တွင်အလုပ်လုပ်သော တူညီသောအခန်းကဏ္ဍများကို အသုံးပြုသည်။
7. Packer သည် VM နမူနာပုံစံကို တင်ပို့သည်။

Day #75- ဖောက်ဖျက်ခြင်းမပြုဘဲ သဘောတူညီချက်ကို ပြန်လည်ပြင်ဆင်ပါ = Test ansible + Testkitchen

ကုဒ်တွင် ကွန်ဗင်းရှင်းများကို ရိုက်ကူးခြင်းသည် မလုံလောက်ပါ။ နောက်ဆုံးအနေနဲ့၊ သင် တစ်ခုခုကို ပြောင်းလဲချင်တယ်ဆိုရင် လုပ်ငန်းစဉ်ရဲ့ အတွင်းအပြင်မှာ တစ်ခုခုကို ချိုးဖျက်နိုင်ပါတယ်။ ထို့ကြောင့် အခြေခံအဆောက်အဦကိစ္စတွင်၊ ဤအခြေခံအဆောက်အအုံကို စမ်းသပ်ခြင်းပေါ်လာသည်။ အဖွဲ့အတွင်း အသိပညာကို ထပ်တူကျစေရန်၊ ကျွန်ုပ်တို့သည် Ansible အခန်းကဏ္ဍများကို စတင်စမ်းသပ်ခဲ့ပါသည်။ လေးလေးနက်နက် မပြောတတ်ဘူးဆိုတော့... အဲဒီ့အချိန်တုန်းက အဖြစ်အပျက်တွေကို ဖော်ပြတဲ့ ဆောင်းပါးတစ်ပုဒ်ရှိတယ်။ YML ပရိုဂရမ်မာများသည် Ansible ကိုစမ်းသပ်ရန်အိပ်မက်မက်နိုင်သလား၊ ကျွန်ုပ်ကိုစမ်းသပ်ပါလား။(ဒီ spoiler က နောက်ဆုံးဗားရှင်းမဟုတ်တော့ နောက်ပိုင်းမှာ အရာအားလုံးက ပိုရှုပ်ထွေးလာတယ်။ Ansible ကို စတင်စမ်းသပ်နည်း၊ ပရောဂျက်ကို တစ်နှစ်အတွင်း ပြန်လည်ဖြည့်တင်းပြီး ရူးသွပ်သွားအောင် ပြုလုပ်နည်း).

Day #130- CentOS+ansible မလိုအပ်ဘူးလား။ openshift ဖြစ်နိုင်သလား။

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

Day #170- Openshift က မသင့်တော်ဘူး၊ Windows Azure Pack ကို အခွင့်အရေးယူလိုက်ကြရအောင်။

Hyper-V သည် အလွန်ဖော်ရွေခြင်းမရှိပါ၊ SCVMM သည် ပိုကောင်းအောင်မလုပ်ပါ။ သို့သော် SCVMM ၏ add-on တစ်ခုဖြစ်သည့် Windows Azure Pack နှင့် Azure ကိုတုပသည့်အရာတစ်ခုရှိသည်။ သို့သော် လက်တွေ့တွင်၊ ထုတ်ကုန်သည် စွန့်ပစ်ထားပုံပေါ်သည်- စာရွက်စာတမ်းသည် လင့်ခ်များကွဲသွားပြီး အလွန်ကျဲသည်။ သို့သော် ကျွန်ုပ်တို့၏ တိမ်တိုက်၏ဘဝကို ရိုးရှင်းလွယ်ကူစေမည့် ရွေးချယ်စရာများကို လေ့လာခြင်း၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် ၎င်းတို့ကိုလည်း ကြည့်ရှုခဲ့သည်။

Day #250- Windows Azure Pack က သိပ်မကောင်းဘူး။ ကျွန်ုပ်တို့သည် SCVMM တွင်ရှိနေပါသည်။

Windows Azure Pack သည် အလားအလာကောင်းပုံပေါက်သော်လည်း မလိုအပ်သောအင်္ဂါရပ်များအကြောင်းကြောင့် WAP ကိုစနစ်ထဲသို့မသွင်းရန်နှင့် SCVMM တွင်နေရန်ဆုံးဖြတ်ခဲ့သည်။

Day #360: ဆင်တစ်ကောင်ကို အပိုင်းပိုင်းစားပါ။

တစ်နှစ်အကြာတွင် ရွှေ့ပြောင်းရန် ပလက်ဖောင်းသည် အဆင်သင့်ဖြစ်ခဲ့ပြီး ရွေ့လျားမှုလုပ်ငန်းစဉ် စတင်ခဲ့သည်။ ဤရည်ရွယ်ချက်အတွက်၊ SMART အလုပ်တစ်ခုကို သတ်မှတ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် VM အားလုံးကိုစစ်ဆေးပြီး ဖွဲ့စည်းမှုပုံစံကို တစ်ခုပြီးတစ်ခုရှာဖွေကာ Ansible တွင် ဖော်ပြပြီး ၎င်းကို စမ်းသပ်မှုများဖြင့် ဖုံးအုပ်ထားသည်။

Day #450- သင်ဘယ်လိုစနစ်မျိုးရခဲ့လဲ။

ဖြစ်စဉ်ကိုယ်တိုင်က စိတ်ဝင်စားစရာ မဟုတ်ဘူး။ ၎င်းသည် ပုံမှန်ဖြစ်သည်၊ ဖွဲ့စည်းမှုအများစုသည် အတော်လေးရိုးရှင်းသော သို့မဟုတ် isomorphic ဖြစ်သည်ကို မှတ်သားနိုင်ပြီး Pareto နိယာမအရ VM configurations များ၏ 80% သည် အချိန်၏ 20% လိုအပ်သည်။ တူညီသောနိယာမအားဖြင့်၊ အချိန်၏ 80% ကို ရွှေ့ရန်ပြင်ဆင်ပြီး 20% ကိုသာ ရွှေ့ခြင်းဖြစ်ပါသည်။

နေ့ #540- နောက်ဆုံး

18 လအတွင်း ဘာတွေဖြစ်ခဲ့လဲ။

1. သဘောတူညီချက်များသည် ကုဒ်တစ်ခုဖြစ်လာခဲ့သည်။
2. ကိုယ်တိုင်လုပ်အား -> စက်မှုလယ်ယာ -> အလိုအလျောက်.

links များ

• အင်္ဂလိပ်ဗားရှင်း
• ကိုယ်ပိုင်ဘလော့ဂ်မှ ပို့စ်ကို ဖြတ်ပါ။
• ဆလိုက်
• Ansible ကို စတင်စမ်းသပ်နည်း၊ ပရောဂျက်ကို တစ်နှစ်အတွင်း ပြန်လည်ဖြည့်တင်းပြီး ရူးသွပ်သွားအောင် ပြုလုပ်နည်း
• Infrastructure Code လိုင်းပေါင်း 200 ကျော်ကို စမ်းသပ်ခြင်းမှ သင်ခန်းစာများ
• Openshift သို့ အသုံးချကြပါစို့
• သင့်ကိုယ်ပိုင် OS ဖြန့်ဖြူးမှုကို စမ်းသပ်နည်း
• တတ်နိုင်ရင် ငါ့ကို စမ်းသပ်ပါ။ YML developer များသည် စမ်းသပ်ခြင်း၏ စိတ်ကူးယဉ်အိပ်မက်များ ဖြစ်ပါသလား။

source: www.habr.com