Ansible ကို စတင်စမ်းသပ်နည်း၊ ပရောဂျက်ကို တစ်နှစ်အတွင်း ပြန်လည်ဖြည့်တင်းပြီး ရူးသွပ်သွားအောင် ပြုလုပ်နည်း

ဒါက စာသားမှတ်တမ်းပါ။ ဖျော်ဖြေပွဲ အပေါ် DevOps-40 2020-03-18:

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

အမွေအနှစ်၏ မွေးဖွားမှု

Day #1: လူနာ သုည

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

နံပါတ် ၈၉ - အမွေအနှစ် မွေးဖွားခြင်း။

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

• ဤနေရာတွင် ကျွန်ုပ်တို့တွင် အရေးတကြီးလုပ်ဆောင်စရာတစ်ခုရှိသည်၊ ညစ်ပတ်သောဟက်ခ်တစ်ခုလုပ်ပြီးနောက် ၎င်းကိုပြင်ကြပါစို့။
• မှတ်တမ်းရေးရန် မလိုအပ်ဘဲ ဤနေရာတွင်ဖြစ်ပျက်နေသည့်အရာအားလုံးကို ရှင်းပါသည်။
• Ansible/Python/Bash/Terraform ကို ငါသိတယ်။ ငါဘယ်လိုရှောင်နိုင်လဲ ကြည့်စမ်း။
• ကျွန်ုပ်သည် Full Stack Overflow Developer ဖြစ်ပြီး ၎င်းကို stackoverflow မှ ကူးယူထားပါသည်၊ ၎င်းသည် မည်သို့အလုပ်လုပ်သည်ကို ကျွန်ုပ်မသိသော်လည်း ၎င်းသည် အေးမြပြီး ပြဿနာကို ဖြေရှင်းပေးပါသည်။

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

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Day #109- ပြဿနာကို သတိထားပါ။

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

IaC ပြန်လည်ပြုပြင်ခြင်း။

နေ့ 139- သင်အမှန်တကယ် ပြန်လည်ပြုပြင်ရန် လိုအပ်ပါသလား။

refactor သို့ အလျင်စလိုမလုပ်မီ၊ အရေးကြီးသောမေးခွန်းများစွာကို ဖြေရပါမည်။

1. ဒါတွေအားလုံး ဘာကြောင့်လိုအပ်တာလဲ။
2. မင်းအချိန်ရလား?
3. အသိပညာ လုံလောက်သလား။

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

Day #149- refactoring ပြင်ဆင်ခြင်း။

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

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

သိသာထင်ရှားသော စမ်းသပ်မှုများ

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

နေ့အမှတ် -997- SDS ပံ့ပိုးမှု

Ansible ကို ပထမဆုံး စမ်းသပ်ခဲ့တာကတော့ SDS (Software Defined Storage) ကို တီထွင်ဖို့ ပရောဂျက်တစ်ခု မှာ ရှိနေပါတယ်။ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ သီးခြားဆောင်းပါးတစ်ပုဒ်ရှိပါသည်။
သင်၏ဖြန့်ဖြူးမှုကိုစမ်းသပ်သောအခါ ချိုင်းထောက်များပေါ်မှ စက်ဘီးကို မည်သို့ချိုးမည်နည်း။သို့သော် အတိုချုပ်အားဖြင့်၊ ကျွန်ုပ်တို့သည် ပြောင်းပြန်စမ်းသပ်ခြင်းပိရမစ်တစ်ခုဖြင့် အဆုံးသတ်ပြီး အခန်းကဏ္ဍတစ်ခုတွင် မိနစ် 60-90 ကြာမြင့်သော စမ်းသပ်မှုတစ်ခုဖြင့် အဆုံးသတ်ခဲ့သည်။ အခြေခံမှာ e2e စမ်းသပ်မှုများ၊ i.e. ကျွန်ုပ်တို့သည် ပြည့်စုံသော တပ်ဆင်မှုကို အသုံးချပြီးနောက် ၎င်းကို စမ်းသပ်ခဲ့သည်။ ပိုဆိုးတာက သူ့ကိုယ်ပိုင်စက်ဘီးကို တီထွင်ခဲ့တာ။ ဒါပေမယ့် ကျွန်တော် ဝန်ခံရပါမယ်၊ ဒီဖြေရှင်းချက်က အလုပ်လုပ်ပြီး တည်ငြိမ်တဲ့ ထုတ်ဝေမှုကို ခွင့်ပြုခဲ့ပါတယ်။

နေ့ #-701- အနှစ်သာရနှင့် စမ်းသပ်မီးဖိုချောင်

Ansible စမ်းသပ်ခြင်းအိုင်ဒီယာ၏ ဖွံ့ဖြိုးတိုးတက်မှုသည် အဆင်သင့်လုပ်ထားသော ကိရိယာများဖြစ်သည့် စမ်းသပ်မီးဖိုချောင်/မီးဖိုချောင်-ci နှင့် inspec တို့ဖြစ်သည်။ ရွေးချယ်မှုကို Ruby အသိပညာဖြင့် ဆုံးဖြတ်ခဲ့သည် (အသေးစိတ်အချက်အလက်များအတွက် Habré ရှိ ဆောင်းပါးကို ကြည့်ပါ- YML ပရိုဂရမ်မာများသည် Ansible ကိုစမ်းသပ်ရန်အိပ်မက်မက်ပါသလား။) ရာထူး ၁၀ ခုအတွက် မိနစ် ၄၀ ခန့် ပိုမြန်သည်။ ကျွန်ုပ်တို့သည် virtual machines အစုံကို ဖန်တီးပြီး အတွင်းတွင် စမ်းသပ်မှုများ လုပ်ဆောင်ခဲ့သည်။

ယေဘူယျအားဖြင့်၊ ဖြေရှင်းချက်သည် အလုပ်လုပ်သော်လည်း မျိုးရိုးလိုက်ခြင်းကြောင့် အနည်အနှစ်အချို့ရှိနေသည်။ စမ်းသပ်ခံလူအရေအတွက်သည် အခြေခံအခန်းကဏ္ဍ 13 ခုနှင့် မက်တာအခန်းကဏ္ဍ 2 ခုကို သေးငယ်သောအခန်းများ ပေါင်းစပ်လိုက်သောအခါ၊ ရုတ်တရက် စမ်းသပ်မှုများသည် မိနစ် 70 ကြာစပြုလာပြီး၊ 2 ဆနီးပါး ပိုရှည်လာသည်။ XP (extreme programming) အလေ့အကျင့်အကြောင်းပြောဖို့ ခက်တယ်... မိနစ် 70 ကို ဘယ်သူမှ မစောင့်ချင်ကြဘူး။ ဤသည်မှာ ချဉ်းကပ်ပုံပြောင်းရခြင်း၏ အကြောင်းရင်းဖြစ်သည်။

နေ့ #-601- အနှစ်သာရနှင့် မော်လီကျူး

သဘောတရားအရ၊ ၎င်းသည် testkitchen နှင့်ဆင်တူသည်၊ ကျွန်ုပ်တို့သာလျှင် အခန်းကဏ္ဍစမ်းသပ်ခြင်းအား docker သို့ ရွှေ့ပြီး stack ကို ပြောင်းလဲခဲ့သည်။ ရလဒ်အနေဖြင့်၊ အခန်းကဏ္ဍ 20 ခုအတွက်အချိန်ကိုတည်ငြိမ် 25-7 မိနစ်သို့လျှော့ချခဲ့သည်။

စမ်းသပ်ထားသော အခန်းကဏ္ဍများကို 17 ခုအထိ တိုးမြှင့်ပြီး 45 ခန်းကို ရေးထိုးခြင်းဖြင့်၊ ၎င်းကို 28 မိနစ်အတွင်း jenkins slave 2 တွင် လုပ်ဆောင်ခဲ့သည်။

Day #167- ပရောဂျက်သို့ Ansible စာမေးပွဲများ ထည့်ခြင်း။

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

ယေဘူယျအားဖြင့်၊ မည်သို့လုပ်ရမည်ကို အရေးမကြီးပါ၊ စာရွက်တစ်ရွက်ပေါ်တွင် ရေးနိုင်သည်၊ ဗီရိုပေါ်တွင် စတစ်ကာများတင်နိုင်သည်၊ Jira တွင် အလုပ်များကို ဖန်တီးနိုင်သည်၊ သို့မဟုတ် Google Docs ကိုဖွင့်ပြီး လက်ရှိအခြေအနေကို ချရေးနိုင်သည်။ ဟိုမှာ။ လုပ်ငန်းစဉ်သည် ချက်ချင်းမဟုတ်သောကြောင့် ခြေထောက်များသည် ရှည်လျားပြီး ငြီးငွေ့လာမည်ဖြစ်သည်။ မည်သူမဆို သင့်အား စိတ်ကူးစိတ်သန်းများ လောင်ကျွမ်းစေကာ ပင်ပန်းနွမ်းနယ်ပြီး ပြန်လည်ပြုပြင်နေစဉ်တွင် နစ်မွန်းနေစေလိုသည်မှာ မဖြစ်နိုင်ပေ။

ပြန်လည်ပြုပြင်ခြင်းသည် ရိုးရှင်းပါသည်။

• စားသည်။
• အိပ်သင့်ပါတယ်။
• ကုဒ်။
• IaC စမ်းသပ်မှု။
• ပြန်ဆို

ပြီးတော့ ရည်ရွယ်ထားတဲ့ ပန်းတိုင်ကို ရောက်တဲ့အထိ ဒါကို ထပ်လုပ်တယ်။

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

Day #181: Green Build Master

Linting သည် Green Build Master သို့ ပထမဆုံးခြေလှမ်းလေးတစ်ခုဖြစ်သည်။ ၎င်းသည် မည်သည့်အရာမျှ ပျက်ပြားမည်မဟုတ်သော်လည်း၊ ၎င်းသည် သင့်အား လုပ်ငန်းစဉ်များကို အမှားရှာပြင်နိုင်ပြီး Jenkins တွင် အစိမ်းရောင်တည်ဆောက်မှုများကို ပြုလုပ်နိုင်စေမည်ဖြစ်သည်။ အကြံဥာဏ်သည် အသင်းသားအချင်းချင်း အလေ့အကျင့်များ မွေးမြူရန်ဖြစ်သည်။

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

Day #193: အလင်းတန်းမှ ယူနစ်စမ်းသပ်မှုအထိ

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

Day #211- ယူနစ်မှ ပေါင်းစပ်စစ်ဆေးမှုများအထိ

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

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

Jenkins + Docker + Ansible = စမ်းသပ်မှုများ

1. ငွေရှင်းပြီး repo နှင့် build အဆင့်များကိုထုတ်ပေးပါ။
2. ပျာယာခတ်စာအုပ် အဆင့်များကို အပြိုင်ဖွင့်ပါ။
3. ပျဉ်းမပင်အဆင့်များကို အပြိုင်ဖွင့်ပါ။
4. အထားအသိုစစ်ဆေးမှုအဆင့်များကို အပြိုင်လုပ်ဆောင်ပါ။
5. စမ်းသပ်မှုအဆင့်များကို အပြိုင်လုပ်ဆောင်ပါ။
   1. လင်းတဲအခန်းကဏ္ဍ။
   2. အခြားအခန်းကဏ္ဍများအပေါ် မှီခိုမှုကို စစ်ဆေးပါ။
   3. Syntax ကိုစစ်ဆေးပါ။
   4. docker ဥပမာကိုဖန်တီးပါ။
   5. molecule/default/playbook.yml ကိုဖွင့်ပါ။
   6. ချို့တဲ့မှုကို စစ်ဆေးပါ။
6. ပေါင်းစပ်စစ်ဆေးမှုများကို လုပ်ဆောင်ပါ။
7. အပြီးသတ်

Day #271: Bus Factor

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

ပြီးတော့ ဒီမှာ အဆင်ပြေရမယ်။ ပြန်လည်သုံးသပ်ရန်၊ ၎င်းလုပ်ဆောင်ခဲ့သည့် အလုပ်၏ဘောင်အတွင်းနှင့် ဆွေးနွေးမှုများ၏သမိုင်းကြောင်းကို ကြည့်ရန် အဆင်ပြေသည်။ ကျွန်ုပ်တို့တွင် jenkins + bitbucket + jira ပေါင်းစပ်ထားသည်။

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

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

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

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

Day #311- စာမေးပွဲများကို အရှိန်မြှင့်ပါ။

အချိန်ကြာလာသည်နှင့်အမျှ၊ စမ်းသပ်မှုများ ပိုများလာကာ အဆိုးဆုံးအခြေအနေတွင် တစ်နာရီအထိ နှေးကွေးသွားခဲ့သည်။ နောက်ကြောင်းပြန်များထဲမှ တစ်ခုတွင် "စမ်းသပ်မှုတွေရှိနေတာ ကောင်းပါတယ်၊ ဒါပေမယ့် နှေးတယ်" ဆိုတဲ့ စကားစုတစ်ခု ပါရှိပါတယ်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် virtual machines များတွင် ပေါင်းစပ်စမ်းသပ်မှုများကို စွန့်လွှတ်ပြီး ပိုမိုမြန်ဆန်စေရန် Docker အတွက် ၎င်းတို့ကို ပြုပြင်ပြောင်းလဲခဲ့သည်။ အသုံးပြုသည့်ကိရိယာအရေအတွက်ကို လျှော့ချရန်အတွက် testinfra ကို ansible verifier ဖြင့်လည်း အစားထိုးခဲ့သည်။

အတိအကျပြောရလျှင် အတိုင်းအတာတစ်ခု ရှိသည်-

1. Docker သို့ပြောင်းပါ။
2. မှီခိုမှုများကြောင့် ထပ်နေသည့် အခန်းကဏ္ဍ စမ်းသပ်ခြင်းကို ဖယ်ရှားပါ။
3. ကျွန်အရေအတွက်ကို တိုးစေပါ။
4. စမ်းသပ်လည်ပတ်ရန်အမိန့်။
5. ပျားခတ်နိုင်စွမ်း အားလုံး ဒေသအလိုက် command တစ်ခုတည်းဖြင့်။

ရလဒ်အနေဖြင့် jenkins ရှိ ပိုက်လိုင်းသည်လည်း တစ်စုတစ်စည်းတည်းဖြစ်ခဲ့သည်။

1. တည်ဆောက်ပုံအဆင့်ဆင့်ကို ဖန်တီးပါ။
2. အားလုံးကို တဆက်တည်း ခင်းထားသည်။
3. စမ်းသပ်မှုအဆင့်များကို အပြိုင်လုပ်ဆောင်ပါ။
4. Finish ကို။

လေ့လာသင်ယူသင်ခန်းစာ

ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်များကို ရှောင်ကြဉ်ပါ။

Ansible သည် ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်များကို အသုံးပြုသည်၊ ပုံစံတွင် တစ်စိတ်တစ်ပိုင်းဖြေရှင်းချက်တစ်ခုရှိသည်။ private_role_varsဒါပေမယ့် ဒါက panacea မဟုတ်ပါဘူး။

ဥပမာတစ်ခုပေးပါရစေ။ ရကြပါစေ role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

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

ဆိုး: global variable ကိုသုံးပါ။

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

ကောငျး: v defaults လိုအပ်သော ကိန်းရှင်များကို သတ်မှတ်ပြီး နောက်ပိုင်းတွင် ၎င်းတို့ကိုသာ အသုံးပြုပါ။

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

အခန်းကဏ္ဍ ကိန်းရှင်များကို ရှေ့ဆက်ပါ။

ဆိုး: global variable ကိုသုံးပါ။

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

ကောငျး: ကိန်းရှင်များအတွက် အခန်းကဏ္ဍများတွင်၊ အခန်းကဏ္ဍအမည်နှင့် ရှေ့ဆက်သော ကိန်းရှင်များကို အသုံးပြုပါ၊ ၎င်းသည် စာရင်းဇယားကို ကြည့်ရှုခြင်းဖြင့် ဖြစ်ပျက်နေသည့်အရာကို နားလည်ရန် ပိုမိုလွယ်ကူစေမည်ဖြစ်သည်။

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

loop control variable ကိုသုံးပါ။

ဆိုး: loops များတွင် standard variable ကိုသုံးပါ။ itemဤလုပ်ငန်းဆောင်တာ/ဖွင့်စာအုပ်ကို တစ်နေရာရာတွင် ထည့်သွင်းထားပါက၊ ၎င်းသည် မမျှော်လင့်ထားသော အပြုအမူကို ဖြစ်ပေါ်စေနိုင်သည်။

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

ကောငျး: မှတဆင့် loop တစ်ခုအတွင်းရှိ variable တစ်ခုကို ပြန်လည်သတ်မှတ်ပါ။ loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

ထည့်သွင်းမှု ကိန်းရှင်များကို စစ်ဆေးပါ။

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

ကောငျး: ကိန်းရှင်များကို စစ်ဆေးပါ။

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

hashes အဘိဓာန်များကို ရှောင်ပါ၊ ပြားချပ်ချပ်ဖွဲ့စည်းပုံကို သုံးပါ။

အခန်းကဏ္ဍတစ်ခုသည် ၎င်း၏ကန့်သတ်ချက်များအနက်မှ hash/dictionary ကိုမျှော်လင့်ထားပါက၊ ကျွန်ုပ်တို့သည် ကလေးပါရာမီတာများထဲမှ တစ်ခုကို ပြောင်းလဲလိုပါက၊ ဖွဲ့စည်းမှုဆိုင်ရာ ရှုပ်ထွေးမှုကို တိုးမြင့်လာစေမည့် hash/dictionary တစ်ခုလုံးကို ကျော်ရန် လိုအပ်မည်ဖြစ်ပါသည်။

ဆိုး: hash/dictionary ကိုသုံးပါ။

---
user:
  name: admin
  group: admin

ကောငျး: ပြားချပ်သော ကိန်းရှင်ဖွဲ့စည်းပုံကို သုံးပါ။

---
user_name: admin
user_group: "{{ user_name }}"

အစွမ်းထက်သော ပြခန်းများနှင့် အခန်းကဏ္ဍများကို ဖန်တီးပါ။

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

command shell modules များအသုံးပြုခြင်းကို ရှောင်ကြဉ်ပါ။

shell module တစ်ခုကိုအသုံးပြုခြင်းသည် Ansible ၏အဓိကအချက်ဖြစ်သည့် declarative one အစား မရှိမဖြစ်လိုအပ်သော ဖော်ပြချက်ပါရာဒိုင်းကို ဖြစ်ပေါ်စေပါသည်။

မော်လီကျူးမှတစ်ဆင့် သင့်အခန်းကဏ္ဍများကို စမ်းသပ်ပါ။

မော်လီကျူးသည် အလွန်လိုက်လျောညီထွေရှိသော အရာဖြစ်သည်၊ အချို့သော အခြေအနေများကို ကြည့်ကြပါစို့။

မော်လီကျူးများစွာသော သာဓကများ

В molecule.yml အပိုင်း platforms သင်အသုံးချနိုင်သော host များစွာကို သင်ဖော်ပြနိုင်သည်။

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

သို့ဖြစ်ရာ ဤအိမ်ရှင်ဖြစ်လျှင် ဖြစ်နိုင်ပါသည်။ converge.yml အသုံးပြုရန်-

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

အနှစ်သာရ စစ်ဆေးသူ

မော်လီကျူးတွင် instance ကို မှန်ကန်စွာ configure လုပ်ထားကြောင်း စစ်ဆေးရန် ansible ကို သုံးနိုင်သည်၊ ထို့အပြင်၊ ၎င်းသည် ထုတ်ဝေမှု 3 ကတည်းက ပုံသေဖြစ်သည်။ ၎င်းသည် testinfra/inspec ကဲ့သို့ ပြောင်းလွယ်ပြင်လွယ်မဟုတ်သော်လည်း၊ ဖိုင်၏အကြောင်းအရာများသည် ကျွန်ုပ်တို့၏မျှော်လင့်ချက်များနှင့် ကိုက်ညီမှုရှိမရှိ စစ်ဆေးနိုင်သည်-

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

သို့မဟုတ် ဝန်ဆောင်မှုကို အသုံးပြုပါ၊ ၎င်းကို ရရှိလာစေရန် စောင့်ပြီး မီးခိုးစမ်းသပ်မှု ပြုလုပ်ပါ-

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

ရှုပ်ထွေးသောယုတ္တိဗေဒကို modules နှင့် plugins များတွင်ထည့်ပါ။

Ansible သည် ကြေငြာချဉ်းကပ်နည်းကို ထောက်ခံပေးသောကြောင့် သင်ကုဒ်ကိုင်းဖြတ်ခြင်း၊ ဒေတာအသွင်ပြောင်းခြင်း၊ shell modules များပြုလုပ်သောအခါ၊ ကုဒ်ကိုဖတ်ရန်ခက်ခဲလာသည်။ ဒါကို တိုက်ဖျက်ပြီး နားလည်လွယ်အောင်ထားဖို့၊ သင့်ကိုယ်ပိုင် module တွေဖန်တီးခြင်းဖြင့် ဒီရှုပ်ထွေးမှုကို တိုက်ဖျက်ဖို့ မလိုအပ်ပါဘူး။

အကြံပြုချက်များနှင့် လှည့်ကွက်များကို အကျဉ်းချုပ်ပါ။

1. ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်များကို ရှောင်ကြဉ်ပါ။
2. အခန်းကဏ္ဍ ကိန်းရှင်များကို ရှေ့ဆက်ပါ။
3. loop control variable ကိုသုံးပါ။
4. ထည့်သွင်းမှု ကိန်းရှင်များကို စစ်ဆေးပါ။
5. hashes အဘိဓာန်များကို ရှောင်ပါ၊ ပြားချပ်ချပ်ဖွဲ့စည်းပုံကို သုံးပါ။
6. အစွမ်းထက်သော ပြခန်းများနှင့် အခန်းကဏ္ဍများကို ဖန်တီးပါ။
7. command shell modules များအသုံးပြုခြင်းကို ရှောင်ကြဉ်ပါ။
8. မော်လီကျူးမှတစ်ဆင့် သင့်အခန်းကဏ္ဍများကို စမ်းသပ်ပါ။
9. ရှုပ်ထွေးသောယုတ္တိဗေဒကို မော်ဂျူးများနှင့် ပလပ်အင်များတွင် ထည့်သွင်းပါ။

ကောက်ချက်

သင့်တွင် IaC ရှိလျှင်ပင် ပရောဂျက်တစ်ခုပေါ်ရှိ အခြေခံအဆောက်အအုံများကို ပြန်လည်ဖြည့်သွင်းရုံဖြင့် သင်သွား၍မရပါ။ ဤသည်မှာ စိတ်ရှည်မှု၊ အချိန်နှင့် အသိပညာ လိုအပ်သည့် ရှည်လျားသော လုပ်ငန်းစဉ်ဖြစ်သည်။

links များ

• ဆလိုက် Ansible ကို ဘယ်လိုစမ်းသပ်ပြီး အခွံမခွာပါနဲ့။
• ဗီဒီယို Ansible ကို ဘယ်လိုစမ်းသပ်ပြီး အခွံမခွာပါနဲ့။
• အခြေခံအဆောက်အဦကုဒ် လိုင်းပေါင်း 200 ကို စမ်းသပ်ခြင်းမှ ကျွန်ုပ်သင်ယူခဲ့ရာ
• Ansible- 120 VM ဖွဲ့စည်းမှုပုံစံကို Coreos မှ Centos သို့ 18 လအတွင်း ရွှေ့ပြောင်းခြင်း
• သင်၏ဖြန့်ဖြူးမှုကိုစမ်းသပ်သောအခါ ချိုင်းထောက်များပေါ်မှ စက်ဘီးကို မည်သို့ချိုးမည်နည်း။
• YML ပရိုဂရမ်မာများသည် Ansible ကိုစမ်းသပ်ရန်အိပ်မက်မက်နိုင်သလား၊ ကျွန်ုပ်ကိုစမ်းသပ်ပါလား။
• အံ့သြဖွယ်ကောင်းသော IaC စမ်းသပ်ခြင်းဆောင်းပါးများ၊ မိန့်ခွန်းများနှင့် လင့်ခ်များစာရင်း
• cross post
• အင်္ဂလိပ်ဗားရှင်း

UPD1 2020.05.01 20:30 — Playbooks ၏ အဓိက ပရိုဖိုင်းအတွက် သင်သုံးနိုင်သည်။ callback_whitelist = profile_tasks အချိန်အကြာကြီး အတိအကျ အလုပ်လုပ်တာကို နားလည်ဖို့။ ပြီးတော့ ကျွန်တော်တို့ ဖြတ်သွားကြတယ်။ Ansible acceleration ဂန္တဝင်. ကြိုးစားလို့လည်း ရပါတယ်။ မီရိုဂျင်
UPD2 2020.05.03 16:34 - အင်္ဂလိပ်ဗားရှင်း

source: www.habr.com