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

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

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

အမည်များ

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

ဒီတော့ ရိုးရှင်းတဲ့ အရာတစ်ခုနဲ့ စကြည့်ရအောင်။ အဲဒါကို ဘာလို့ခေါ်လဲ။ စာရွက်စာတမ်းကိုဖတ်တဲ့အခါ သင်ဂရုမစိုက်တာကြောင့် ဒါကိုသင်သိနိုင်သလို သင်မသိတာဖြစ်နိုင်ပါတယ်။

ansible-playbook သည် playbook ကို လုပ်ဆောင်သည်။ ပလေးစာအုပ်သည် yml/yaml တိုးချဲ့မှုပါရှိသော ဖိုင်တစ်ခုဖြစ်ပြီး၊ ၎င်းအထဲတွင် ဤကဲ့သို့သော အရာတစ်ခုပါရှိသည်-

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

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

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

ထို့ကြောင့်၊ Playbook သည် play နှင့် play ပါဝင်သောစာရင်းတစ်ခုဖြစ်သည်။ import_playbook.
ဒါက ပြဇာတ်တစ်ခုပါ

- hosts: group1
  roles:
    - role1

ဒါကလည်း နောက်ထပ်ကစားစရာတစ်ခုပါ။

- hosts: group2,group3
  tasks:
    - debug:

ကစားခြင်းဆိုတာဘာလဲ။ သူမ ဘာကြောင့်လဲ?

Play သည် ပလေးစာအုပ်တစ်အုပ်အတွက် အဓိကကျသော အစိတ်အပိုင်းတစ်ခုဖြစ်သည်၊ အကြောင်းမှာ၊ ၎င်းတို့သည် လုပ်ဆောင်ရမည့် host စာရင်းတစ်ခုနှင့် လုပ်ဆောင်ရမည့် အခန်းကဏ္ဍများစာရင်းနှင့်/သို့မဟုတ် အလုပ်များကိုသာ တွဲလျက်ကစားသောကြောင့် ဖြစ်သည်။ စာတမ်း၏ နက်နဲသော နက်နဲသော နေရာတွင် ဖော်ပြထားသည်ကို တွေ့နိုင်သည်။ delegate_to၊ ဒေသတွင်းရှာဖွေမှုပလပ်အင်များ၊ ကွန်ရက်-ကလစ်-သတ်သတ်မှတ်မှတ်ဆက်တင်များ၊ jump hosts စသည်တို့။ ၎င်းတို့သည် သင့်အား အလုပ်များလုပ်ဆောင်သည့်နေရာကို အနည်းငယ်ပြောင်းလဲခွင့်ပြုသည်။ ဒါပေမယ့် အဲဒါကို မေ့လိုက်ပါ။ ဤလိမ္မာပါးနပ်သောရွေးချယ်မှုတစ်ခုစီတွင် အလွန်တိကျသောအသုံးပြုမှုများပါရှိပြီး ၎င်းတို့သည် universal မဟုတ်ပါ။ ပြီးတော့ လူတိုင်းသိထားသင့်တဲ့အရာတွေအကြောင်းပြောနေတာ။

"တစ်ခုခု" "တစ်နေရာရာမှာ" ဖျော်ဖြေချင်ရင် ကစားနည်းကို ရေးပါ။ အခန်းကဏ္ဍမဟုတ်ပါ။ မော်ဂျူးများနှင့် ကိုယ်စားလှယ်များ၏ အခန်းကဏ္ဍမဟုတ်ပါ။ မင်းယူသွားပြီး ရေးလိုက်။ ၎င်းတွင်၊ host အကွက်တွင် သင်လုပ်ဆောင်ရမည့်နေရာကို စာရင်းပြုစုပြီး အခန်းကဏ္ဍ/တာဝန်များ- လုပ်ဆောင်ရမည့်အရာကို ဖော်ပြပါ။

ရိုးရှင်းတယ် မဟုတ်လား။ ဘယ်လိုမှ တခြားဖြစ်နိုင်မှာလဲ?

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

စံပြဥပမာတစ်ခုသည် စောင့်ကြည့်ခြင်းဖြစ်ပါသည်။ စောင့်ကြည့်ရေးကဏ္ဍကို စီစဉ်ပေးမယ့် စောင့်ကြည့်ရေးကဏ္ဍတစ်ခု ရှိချင်ပါတယ်။ စောင့်ကြည့်ရေး အခန်းကဏ္ဍကို စောင့်ကြည့်ရေးအိမ်ရှင်များ (ကစားမှုအရ) တွင် တာဝန်ပေးအပ်သည်။ သို့သော် စောင့်ကြည့်စစ်ဆေးရန်အတွက် ကျွန်ုပ်တို့ စောင့်ကြည့်နေသော host များထံသို့ ပက်ကေ့ခ်ျများ ပေးပို့ရန် လိုအပ်ကြောင်း ထွက်ပေါ်လာပါသည်။ ကိုယ်စားလှယ်ကို ဘာကြောင့်မသုံးတာလဲ။ iptables များကိုလည်း configure လုပ်ရန် လိုအပ်ပါသည်။ ကိုယ်စားလှယ် စောင့်ကြည့်ခြင်းကိုဖွင့်ရန် DBMS အတွက် config တစ်ခုရေးရန်/ပြင်ရန် လိုအပ်သည်။ ကိုယ်စားလှယ် တီထွင်ဖန်တီးနိုင်မှု အားနည်းနေပါက သင်သည် ကိုယ်စားလှယ်အဖွဲ့တစ်ခု ပြုလုပ်နိုင်သည်။ include_role အဖွဲ့များစာရင်းနှင့် အတွင်းပိုင်းရှိ ဆန်းကျယ်သော filter ကို အသုံးပြု၍ nested loop တစ်ခုတွင် include_role သင်ပိုပြီးလုပ်နိုင်တယ်။ delegate_to တဖန်။ ပြီး​တော့ငါတို့သွား​တော့...

“အရာရာတိုင်းကို လုပ်ဆောင်သည်” ဟူသော တစ်ခုတည်းသော စောင့်ကြည့်ရေး အခန်းကဏ္ဍတစ်ခုရှိရန် ဆန္ဒကောင်းတစ်ခုသည် ကျွန်ုပ်တို့ကို ပြီးပြည့်စုံသော ငရဲသို့ ပို့ဆောင်ပေးသည့် နည်းလမ်းတစ်ခုသာ ရှိသည်- အရာအားလုံးကို အစမှ ပြန်ရေးရန် တစ်ခုတည်းသော ဆန္ဒဖြစ်သည်။

ဒီနေရာမှာ အမှားက ဘယ်မှာ ဖြစ်ခဲ့တာလဲ။ host X တွင် task "x" ကိုလုပ်ဆောင်ရန် သင်ရှာဖွေတွေ့ရှိသည့်အခိုက်တွင် host Y သို့သွားပြီး "y" လုပ်ရမည်ဖြစ်ပြီး၊ ရိုးရှင်းသောလေ့ကျင့်ခန်းတစ်ခုပြုလုပ်ရန် လိုအပ်သည်- သွား၍ကစားပါ၊ host Y တွင် y လုပ်နိုင်သည် ။ "x" မှာ တစ်ခုခုမထည့်ဘဲ အစကနေ ရေးပါ။ hardcoded variable တွေနဲ့တောင်။

အပေါ်က စာပိုဒ်ထဲက အားလုံးကို မှန်ကန်စွာ ပြောထားပုံရတယ်။ ဒါပေမယ့် ဒါက မင်းကိစ္စမဟုတ်ဘူး။ DRY နှင့် စာကြည့်တိုက်ကဲ့သို့ ပြန်သုံးနိုင်သော ကုဒ်ကို ရေးသားလိုသောကြောင့် ၎င်းကို ပြုလုပ်နည်းကို ရှာဖွေရန် လိုအပ်ပါသည်။

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

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

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

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

Ansible တွင် ပရိုဂရမ်အတွက် အဘယ်ကြောင့် အန္တရာယ်ရှိသနည်း၊ အဘယ်ကြောင့် COBOL သည် Ansible ထက် ပိုကောင်းသနည်း၊ ကျွန်ုပ်တို့သည် ကိန်းရှင်များနှင့် jinja အကြောင်း အခန်းတွင် ဆွေးနွေးပါမည်။ အခုအချိန်မှာ၊ တစ်ခုပဲ ဆိုကြပါစို့ - မင်းရဲ့ တွက်ချက်မှုတစ်ခုစီဟာ ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်တွေရဲ့ ပြောင်းလဲမှုတွေရဲ့ နောက်ကွယ်မှာ ဖျောက်ဖျက်လို့မရနိုင်တဲ့ သဲလွန်စတစ်ခုကို ချန်ထားခဲ့ရပြီး အဲဒါနဲ့ ပတ်သက်ပြီး သင်ဘာမှ မလုပ်နိုင်ပါဘူး။ “ခြေရာ” နှစ်ခု ဖြတ်သွားသည်နှင့် တပြိုင်နက် အရာအားလုံး ပျောက်ကွယ်သွားခဲ့သည်။

squeamish အတွက် မှတ်ချက်- အခန်းကဏ္ဍသည် ထိန်းချုပ်စီးဆင်းမှုကို သေချာပေါက် လွှမ်းမိုးနိုင်သည်။ စားသည် delegate_to ကျိုးကြောင်းဆီလျော်စွာ အသုံးပြုမှုများ ရှိသည်။ စားသည် meta: end host/play. ဒါပေမယ့်! အခြေခံတွေကို သင်ပေးနေတာ မှတ်မိလား။ မေ့သွားပြီ delegate_to. ကျွန်ုပ်တို့သည် အရိုးရှင်းဆုံးနှင့် အလှပဆုံး Ansible ကုဒ်အကြောင်း ပြောနေပါသည်။ ၎င်းသည် ဖတ်ရန်လွယ်ကူသည်၊ ရေးရလွယ်ကူသည်၊ အမှားရှာရန်လွယ်ကူသည်၊ စမ်းသပ်ရန်လွယ်ကူပြီး ပြီးမြောက်ရန်လွယ်ကူသည်။ ဒီတော့ နောက်တစ်ကြိမ်-

ကစားပြီး ကစားခြင်းသည် မည်သည့်အရာကို လက်ခံဆောင်ရွက်ပေးမည်ကို ဆုံးဖြတ်သည် ။

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

တာဝန်များနှင့် ရာထူးများ

ကစားရန် စဉ်းစားပါ-

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

foo လုပ်ဖို့လိုတယ်ဆိုပါစို့။ ကြည့်ရတာ foo: name=foobar state=present. ဒါကို ဘယ်မှာရေးရမလဲ။ ကြိုတင်မှာလား? ပို့စ်? အခန်းကဏ္ဍတစ်ခု ဖန်တီးမလား။

...အလုပ်တွေ ဘယ်ရောက်သွားတာလဲ။

ကျွန်ုပ်တို့သည် အခြေခံအချက်များ- ကစားကိရိယာဖြင့် ပြန်လည်စတင်နေပါသည်။ သင်သည် ဤပြဿနာကို ပျံ့လွင့်နေပါက၊ သင်သည် အခြားအရာအားလုံးအတွက် ကစားအားကို အခြေခံအဖြစ် အသုံးမပြုနိုင်တော့ဘဲ သင်၏ရလဒ်သည် "တုန်လှုပ်ခြောက်ခြားသွားလိမ့်မည်" ဖြစ်သည်။

Play စက်ပစ္စည်း- လမ်းညွှန်ချက်၊ ကိုယ်တိုင်ဖွင့်ရန် ဆက်တင်များနှင့် pre_tasks၊ အလုပ်များ၊ အခန်းကဏ္ဍများ၊ post_tasks ကဏ္ဍများ။ ကစားရန်ကျန်ရှိသော ကန့်သတ်ချက်များသည် ယခု ကျွန်ုပ်တို့အတွက် အရေးမကြီးပါ။

လုပ်ငန်းတာဝန်များနှင့် အခန်းကဏ္ဍများပါရှိသော ၎င်းတို့၏ကဏ္ဍများ၏ အစီအစဥ်- pre_tasks, roles, tasks, post_tasks. ဝေါဟာရအားဖြင့် ကွပ်မျက်ခြင်းအမိန့်သည် ကြားတွင်ရှိသောကြောင့်ဖြစ်သည်။ tasks и roles ရှင်းရှင်းလင်းလင်းမဟုတ်ပါ၊ ထို့နောက် အကောင်းဆုံးအလေ့အကျင့်များက ကျွန်ုပ်တို့သည် ကဏ္ဍတစ်ခုကို ပေါင်းထည့်နေသည်ဟုဆိုသည်။ tasksမဟုတ်လျှင်သာ roles... ရှိလျှင် rolesထို့နောက် ပူးတွဲလုပ်ဆောင်စရာများအားလုံးကို အပိုင်းများတွင် ထားရှိပါ။ pre_tasks/post_tasks.

ကျန်တာအားလုံးက ဝေါဟာရအရ ရှင်းပါတယ်- ပထမ pre_tasksထို့နောက် rolesထို့နောက် post_tasks.

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

ဤမေးခွန်းများအတွက် ကျိုးကြောင်းဆီလျော်သော အဖြေမရှိလျှင် ဤအရာသည် ပင်ကိုယ်မရှိခြင်း၏ လက္ခဏာဖြစ်သည်၊ ဆိုလိုသည်မှာ ထိုတူညီသော "တုန်ခါနေသော အခြေခံအုတ်မြစ်များ" ဖြစ်သည်။ အဖြေရှာကြည့်ရအောင်။ ပထမဦးစွာ လုံခြုံရေးမေးခွန်း- အကယ်၍ ကစားခွင့်ရှိပါသလား။ pre_tasks и post_tasks (အလုပ်များ သို့မဟုတ် အခန်းကဏ္ဍများ မပါရှိပါ) သို့ဆိုလျှင် ကျွန်ုပ်သည် ပထမတာဝန်ကို လုပ်ဆောင်ပါက တစ်ခုခု ပျက်သွားနိုင်သည်။ post_tasks အဆုံးထိ ရွှေ့လိုက်မယ်။ pre_tasks?

ဟုတ်ပါတယ်၊ မေးခွန်းရဲ့ အသုံးအနှုန်းက ပျက်သွားလိမ့်မယ်လို့ အရိပ်အမြွက်ပြပါတယ်။ ဒါပေမယ့်အတိအကျဘာလဲ?

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

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

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

လိမ္မာပါးနပ်သော Ansible ကျွမ်းကျင်သူက ၎င်းသည် ကျွန်ုပ်တို့အား ပြောပြလိမ့်မည်။ meta: flush_handlersသို့သော် ကျွန်ုပ်တို့သည် play တွင် အပိုင်းများကို အကောင်အထည်ဖော်ရန် အစီအစဥ်ကို အားကိုးနိုင်လျှင် အဘယ်ကြောင့် flush_handlers လိုအပ်သနည်း။ ထို့အပြင်၊ meta-flush_handlers ကိုအသုံးပြုခြင်းသည် ကျွန်ုပ်တို့အား ထပ်နေသောလက်ကိုင်ကိရိယာများဖြင့် မမျှော်လင့်ထားသောအရာများကို ပေးစွမ်းနိုင်ပြီး အသုံးပြုသည့်အခါတွင် ထူးဆန်းသောသတိပေးချက်များပေးနိုင်ပါသည်။ when у block စသည်တို့ ansible ကို သင်ပိုသိလေလေ၊ "ဆန်းကျယ်သောဖြေရှင်းချက်" အတွက် ကွဲပြားမှုများ ပိုများလေဖြစ်သည်။ ရိုးရှင်းသောဖြေရှင်းချက် - အကြို / အခန်းကဏ္ဍ / ပို့စ်အကြားသဘာဝကွဲပြားမှုကိုအသုံးပြုသည် - ကွဲပြားမှုများမဖြစ်ပေါ်စေပါ။

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

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

Ansible ၏အခြေခံများကိုနားလည်ခြင်းသည်အရသာရှိပုံရသောမေးခွန်းများအတွက်ကျိုးကြောင်းဆီလျော်သောအဖြေများကိုပေးသည်။

တာဝန်များနှင့် အခန်းကဏ္ဍများ (အပိုင်းနှစ်)

အခုမှ playbook ရေးတော့မယ့် အခြေအနေအကြောင်း ဆွေးနွေးကြည့်ရအောင်။ သင်သည် foo၊ bar နှင့် baz ပြုလုပ်ရန်လိုအပ်သည်။ ဤတာဝန်သုံးခု၊ အခန်းကဏ္ဍတစ်ခု သို့မဟုတ် ကဏ္ဍသုံးရပ်ဖြစ်ပါသလား။ မေးခွန်းကို အကျဉ်းချုံ့ရန်- မည်သည့်အချိန်၌ အခန်းကဏ္ဍများကို စတင်ရေးသားသင့်သနည်း။ အလုပ်တွေကို ရေးနိုင်တဲ့အခါ ရေးရမယ့် အခန်းကဏ္ဍက ဘာလဲ။... အခန်းကဏ္ဍဆိုတာ ဘာလဲ?

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

ကဲ သတိထား။ ဒီအခန်းကဏ္ဍကနေ ဘာလုပ်နိုင်မလဲ။ ဘေးထွက်ဆိုးကျိုးများကို ခေါ်ဆိုရန် သင့်အား အမြဲကြိုဆိုပါသည်၊ ဤသည်မှာ Ansible တစ်ခုလုံး၏ အနှစ်သာရဖြစ်သည် - ဘေးထွက်ဆိုးကျိုးများ ဖန်တီးရန်။ ဘေးထွက်အကြောင်းရင်းများရှိပါသလား။ အခြေခံ။ ဒါပေမယ့် "တန်ဖိုးတစ်ခုဖြတ်ပြီးပြန်ပေး" ဖြင့် - ၎င်းသည်အလုပ်မဖြစ်ပါ။ ပထမ၊ သင်သည် အခန်းကဏ္ဍတစ်ခုသို့ တန်ဖိုးတစ်ခုကို မဖြတ်သန်းနိုင်ပါ။ အခန်းကဏ္ဍအတွက် vars ကဏ္ဍတွင် ကစားသည့် တစ်သက်တာအရွယ်အစားဖြင့် ဂလိုဘယ်ကိန်းရှင်ကို သင် သတ်မှတ်နိုင်သည်။ အခန်းကဏ္ဍအတွင်းတွင် ကစားသည့် တစ်သက်တာဖြင့် ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်တစ်ခုကို သင် သတ်မှတ်နိုင်သည်။ ဒါမှမဟုတ် Playbook တွေရဲ့ သက်တမ်းနဲ့တောင် (set_fact/register) ဒါပေမယ့် သင့်မှာ "local variables" တွေ ရှိမနေနိုင်ပါဘူး။ "တန်ဖိုး" နဲ့ "ပြန်ပေး" လို့မရပါဘူး။

ဤအရာမှ အဓိကအချက်မှာ အောက်ပါအတိုင်းဖြစ်သည်- ဘေးထွက်ဆိုးကျိုးမဖြစ်စေဘဲ Ansible တွင် တစ်စုံတစ်ခုကို သင်မရေးနိုင်ပါ။ ကမ္ဘာလုံးဆိုင်ရာ ကိန်းရှင်များကို ပြောင်းလဲခြင်းသည် လုပ်ဆောင်ချက်တစ်ခုအတွက် အမြဲတမ်း ဘေးထွက်ဆိုးကျိုးတစ်ခုဖြစ်သည်။ ဥပမာ Rust တွင် global variable ကိုပြောင်းလဲခြင်း။ unsafe. Ansible တွင် ၎င်းသည် အခန်းကဏ္ဍတစ်ခုအတွက် တန်ဖိုးများကို လွှမ်းမိုးရန် တစ်ခုတည်းသောနည်းလမ်းဖြစ်သည်။ အသုံးပြုထားသော စကားလုံးများကို မှတ်သားထားပါ- "အခန်းကဏ္ဍသို့ တန်ဖိုးတစ်ခု မပေးပို့ပါ" မဟုတ်ဘဲ "အခန်းကဏ္ဍမှ အသုံးပြုသော တန်ဖိုးများကို ပြောင်းလဲပါ"။ အခန်းကဏ္ဍများအကြား သီးခြားခွဲထားခြင်းမရှိပေ။ အလုပ်များနှင့် ရာထူးများကြားတွင် သီးခြားခွဲထားခြင်းမရှိပါ။

စုစုပေါင်း: အခန်းကဏ္ဍတစ်ခုသည် လုပ်ဆောင်မှုတစ်ခုမဟုတ်ပါ။.

ဇာတ်ရုပ်က ဘာကောင်းလဲ။ ပထမ၊ အခန်းကဏ္ဍတွင် ပုံသေတန်ဖိုးများရှိသည် (/default/main.yaml) ဒုတိယအနေဖြင့်၊ အခန်းကဏ္ဍတွင် ဖိုင်များကို သိမ်းဆည်းရန်အတွက် နောက်ထပ်လမ်းညွှန်များ ပါရှိသည်။

မူရင်းတန်ဖိုးများ၏ အကျိုးကျေးဇူးများကား အဘယ်နည်း။ Maslow ၏ ပိရမစ်တွင်၊ Ansible ၏ ပြောင်းလဲနိုင်သော ဦးစားပေးမှုများ၏ အသွင်အပြင်ဇယားဖြစ်သောကြောင့်၊ အခန်းကဏ္ဍ ပုံသေများသည် ဦးစားပေးအနိမ့်ဆုံးဖြစ်သည် (အနုတ် Ansible အမိန့်ပေးစာကြောင်း ကန့်သတ်ချက်များ)။ ဆိုလိုသည်မှာ သင်သည် ပုံသေတန်ဖိုးများကို ပေးဆောင်ရန် လိုအပ်ပြီး သိုလှောင်မှု သို့မဟုတ် အုပ်စုကွဲလွဲချက်များမှ တန်ဖိုးများကို ၎င်းတို့ကို ကျော်လွန်မည်ကို မစိုးရိမ်ပါက၊ Role defaults များသည် သင့်အတွက် တစ်ခုတည်းသော မှန်ကန်သောနေရာဖြစ်သည်။ (နည်းနည်းတော့ လိမ်နေတယ် - နောက်ထပ် ရှိသေးတယ်။ |d(your_default_here)၊ သို့သော် ကျွန်ုပ်တို့သည် ငုတ်လျှိုးနေသောနေရာများအကြောင်းပြောလျှင် အခန်းကဏ္ဍပုံသေများသာဖြစ်သည်)။

ဇာတ်ရုပ်တွေမှာ တခြားဘာတွေကောင်းလဲ။ ဘာလို့လဲဆိုတော့ သူတို့မှာ ကိုယ်ပိုင် catalog တွေရှိတယ်။ ဤအရာများသည် ကိန်းသေများအတွက် လမ်းညွှန်များဖြစ်သည်၊ ကိန်းသေ (ဆိုလိုသည်မှာ အခန်းကဏ္ဍအတွက် တွက်ချက်ထားသည်) နှင့် ရွေ့လျားမှု (ပုံစံတစ်ခု သို့မဟုတ် ဆန့်ကျင်ဘက်ပုံစံတစ်ခု ရှိသည် - include_vars နှင့် {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml။) ဒါတွေက လမ်းညွှန်ချက်တွေပါ။ files/, templates/. ထို့အပြင်၊ ၎င်းသည် သင့်တွင် ကိုယ်ပိုင် module များနှင့် plugins များ ရှိနိုင်စေသည် (library/) သို့သော်၊ playbook တစ်ခုရှိအလုပ်များနှင့် နှိုင်းယှဉ်ပါက (ဒါတွေအားလုံးလည်းပါနိုင်သည်) ဤနေရာတွင် တစ်ခုတည်းသောအကျိုးအမြတ်မှာ ဖိုင်များကို တစ်ပုံတည်းတွင် မစွန့်ပစ်ဘဲ သီးခြားအစုအဝေးများစွာရှိခြင်းပင်ဖြစ်သည်။

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

ထို့ကြောင့်၊ အခန်းကဏ္ဍများတွင် အရေးကြီးသောအင်္ဂါရပ်နှစ်ခုရှိသည်- ၎င်းတို့တွင် ပုံသေများ (ထူးခြားသောအင်္ဂါရပ်တစ်ခု) ရှိပြီး ၎င်းတို့သည် သင့်အား သင့်ကုဒ်ကို တည်ဆောက်နိုင်စေပါသည်။

မူလမေးခွန်းသို့ ပြန်သွားခြင်း- အလုပ်များကို မည်သည့်အချိန်တွင် လုပ်ဆောင်ရမည်နှင့် အခန်းကဏ္ဍများကို မည်သည့်အချိန်တွင် လုပ်ဆောင်ရမည်နည်း။ ပြခန်းစာအုပ်တစ်အုပ်ရှိ လုပ်ဆောင်စရာများကို အခန်းကဏ္ဍများ မတိုင်မီ/ပြီးနောက် “ကော်” အဖြစ် သို့မဟုတ် သီးခြားတည်ဆောက်မှုဒြပ်စင်အဖြစ် (ထို့နောက် ကုဒ်တွင် အခန်းကဏ္ဍများ မရှိသင့်ပါ)။ အခန်းကဏ္ဍများနှင့် ရောနှောထားသော သာမန်အလုပ်များအစုအဝေးသည် မရေရာသော ကောက်ကျစ်သော ကောက်ကျစ်ခြင်း ဖြစ်သည်။ အလုပ်တစ်ခု သို့မဟုတ် အခန်းကဏ္ဍတစ်ခုအား သတ်သတ်မှတ်မှတ်ပုံစံကို လိုက်နာသင့်သည်။ အခန်းကဏ္ဍများသည် အရာဝတ္ထုများနှင့် ပုံသေများကို ပိုင်းခြားပေးသည်၊ အလုပ်များသည် သင့်အား ကုဒ်ကို ပိုမိုမြန်ဆန်စွာ ဖတ်နိုင်စေပါသည်။ အများအားဖြင့်၊ ပိုမို “စာရေးကိရိယာ” (အရေးကြီးပြီး ရှုပ်ထွေးသော) ကုဒ်များကို အခန်းကဏ္ဍများတွင် ထည့်သွင်းထားပြီး အရန်စခရစ်များကို အလုပ်ပုံစံဖြင့် ရေးသားထားသည်။

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

လိမ္မာပါးနပ်သောစာဖတ်သူသည် အခန်းကဏ္ဍများသည် အခန်းကဏ္ဍများကို တင်သွင်းနိုင်သည်၊ အခန်းကဏ္ဍများသည် galaxy.yml မှတစ်ဆင့် မှီခိုမှုများရှိနိုင်သည်၊ နှင့် ကြောက်မက်ဖွယ်ကောင်းသည့်အရာလည်း ရှိသည်၊ include_role — ကျွန်ုပ်တို့သည် ပုံသဏ္ဍာန်ကျွမ်းဘားအားကစားတွင်မဟုတ်ဘဲ အခြေခံ Ansible တွင် စွမ်းရည်များကို မြှင့်တင်နေကြောင်း သင့်အား သတိပေးအပ်ပါသည်။

ကိုင်တွယ်သူများနှင့် အလုပ်များ

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

ကျွန်ုပ်တို့သည် အခြေခံများကို မှတ်မိနေသောကြောင့်၊ ဤနေရာတွင် ဥပမာတစ်ခုရှိသည်။

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

အခန်းကဏ္ဍ၏ ကိုင်တွယ်ဖြေရှင်းသူများသည် rolename/handlers/main.yaml တွင် တည်ရှိသည်။ ကိုင်တွယ်သူသည် ကစားသူအားလုံးကြားတွင် တင်းမာမှုများရှိနေသည်- အကြို/post_tasks များသည် အခန်းကဏ္ဍကိုင်တွယ်သူများကို ဆွဲထုတ်နိုင်ပြီး အခန်းကဏ္ဍတစ်ခုမှ ကိုင်တွယ်သူများကို ပြဇာတ်မှ ဆွဲထုတ်နိုင်သည်။ သို့သော်လည်း၊ ကိုင်တွယ်သူများထံသို့ "ကဏ္ဍစုံ" ခေါ်ဆိုမှုများသည် အသေးအဖွဲကိုင်တွယ်သူအား ထပ်ခါတလဲလဲလုပ်ခြင်းထက် wtf ကို ပိုမိုဖြစ်ပေါ်စေပါသည်။ (အကောင်းဆုံးအလေ့အကျင့်များ၏ အခြားအစိတ်အပိုင်းမှာ ကိုင်တွယ်သူအမည်များကို ထပ်ခါတလဲလဲ မကြိုးစားရန်ဖြစ်သည်။

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

config ပါရှိသော အခြေအနေအား ဖြေရှင်း၍မရပါ (အတိအကျအားဖြင့်၊ သင်သည် ဖိုင်အလံများ စသည်ဖြင့် သင်ကိုယ်တိုင် အထူးပြန်လည်စတင်သည့် ပရိုတိုကောကို တီထွင်နိုင်သည်၊ သို့သော် ၎င်းသည် မည်သည့်ပုံစံဖြင့်မဆို 'အခြေခံသိနိုင်သည်' မဟုတ်တော့ပါ)။ ဒါပေမယ့် နောက်ထပ် အဖြစ်များတဲ့ ဇာတ်လမ်းတစ်ခု ရှိပါတယ်၊ ကျွန်တော်တို့ အက်ပ်ကို ထည့်သွင်းပြီး မှတ်တမ်းတင်ထားပါတယ်။ .service-file ၊ အခုကျွန်တော်တို့လိုချင်တယ်။ daemon_reload и state=started. ပြီးတော့ ဒီအတွက် သဘာဝနေရာက ကိုင်တွယ်သူဖြစ်ပုံရတယ်။ သို့သော် အကယ်၍ သင်သည် ၎င်းအား ကိုင်တွယ်သူမဟုတ်သော်လည်း အလုပ်စာရင်းတစ်ခု သို့မဟုတ် အခန်းကဏ္ဍတစ်ခု၏အဆုံးတွင် အလုပ်တစ်ခုပြုလုပ်ပါက၊ ၎င်းကို အချိန်တိုင်းတွင် အစွမ်းကုန်လုပ်ဆောင်သွားမည်ဖြစ်သည်။ ကစားစာအုပ် အလယ်မှာ ကွဲသွားရင်တောင်။ ၎င်းသည် ပြန်လည်စတင်သည့်ပြဿနာကို လုံးဝမဖြေရှင်းနိုင်ဘဲ (ပြန်လည်စတင်သည့် အရည်အချင်းနှင့် အလုပ်တစ်ခုကို သင်မလုပ်နိုင်ပါ၊ အကြောင်းမှာ အစွမ်းအစပျောက်ဆုံးသွားသောကြောင့်)၊ သို့သော် ၎င်းသည် state=started လုပ်ရန် သေချာပေါက် တန်ဖိုးရှိပြီး၊ playbooks များ၏ အလုံးစုံတည်ငြိမ်မှုသည် တိုးလာသောကြောင့်၊ ချိတ်ဆက်မှုအရေအတွက်နှင့် dynamic state လျော့နည်းသွားသည်။

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

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

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

အဆိပ်သင့်သော စာဖတ်သူသည် ကျွန်ုပ်တို့ မဆွေးနွေးရသေးကြောင်း မှန်ကန်စွာ ထောက်ပြသည်။ listenကိုင်တွယ်သူသည် အခြားကိုင်တွယ်သူအား အကြောင်းကြားနိုင်ကြောင်း၊ ကိုင်တွယ်သူသည် ကိုင်တွယ်သူထံမှ ကိုင်တွယ်သူများနှင့် စပ်စုသောနည်းလမ်းဖြင့် ကိုင်တွယ်သူများနှင့် စပ်စုသောနည်းလမ်းဖြင့် ကိုင်တွယ်သည့်နည်းလမ်းဖြင့် ကိုင်တွယ်သည့်ပုံစံဖြင့် ချိတ်ဆက်သည့် import_tasks (inport_tasks များပါ၀င်နိုင်သည့်_role နှင့်_items ပါ၀င်နိုင်သည်)၊ ကိုင်တွယ်သူသည် အခြားကိုင်တွယ်သူအတွက် အကြောင်းကြားချက်ခေါ်ဆိုနိုင်သည်။ စသည်တို့ .d. - ဤအရာအားလုံးသည် "အခြေခံများ" မဟုတ်ကြောင်းရှင်းရှင်းလင်းလင်း) ။

အတိအကျ WTF တစ်ခုရှိသော်လည်း အမှန်တကယ်တွင် သင်မှတ်သားထားရန်လိုအပ်သည့် အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ မင်းရဲ့တာဝန်ကို အကောင်အထည်ဖော်ရင် delegate_to အကြောင်းကြားပြီးသည်နှင့် သက်ဆိုင်ရာ ကိုင်တွယ်သူသည် မလိုအပ်ဘဲ လုပ်ဆောင်ပါသည်။ delegate_to, i.e. ကစားရန်သတ်မှတ်ထားသော အိမ်ရှင်အပေါ်။ (ဒါပေမယ့် ကိုင်တွယ်သူမှာ ရှိကောင်းရှိနိုင်ပါတယ်။ delegate_to အတူတူ)။

သီးခြားအားဖြင့်၊ ပြန်သုံးနိုင်သော အခန်းကဏ္ဍများအကြောင်း စကားအနည်းငယ် ပြောလိုပါသည်။ စုစည်းမှုများ မပေါ်မီတွင်၊ သင်ဖြစ်နိုင်သည့် universal roles များ ဖန်တီးရန် စိတ်ကူးတစ်ခုရှိခဲ့သည်။ ansible-galaxy install သွားတယ်။ အခြေအနေအားလုံးတွင် မျိုးကွဲအားလုံး၏ OS အားလုံးတွင် အလုပ်လုပ်သည်။ ဒီတော့ ကျွန်တော့်အမြင်ကတော့ အလုပ်မဖြစ်ပါဘူး။ အစုလိုက်အပြုံလိုက် အခန်းကဏ္ဍတစ်ခုခု include_varsအမှုပေါင်း 100500 ကို ပံ့ပိုးပေးသော၊ ထောင့်ကိစ္စ ချို့ယွင်းချက်များ ချောက်ထဲကျမည် ဖြစ်သည်။ ၎င်းတို့ကို ကြီးမားသောစမ်းသပ်မှုဖြင့် ဖုံးအုပ်ထားနိုင်သော်လည်း မည်သည့်စမ်းသပ်မှုကဲ့သို့ပင်၊ သင့်တွင် ထည့်သွင်းတန်ဖိုးများနှင့် စုစုပေါင်းလုပ်ဆောင်နိုင်စွမ်းရှိသည့် Cartesian ထုတ်ကုန်တစ်ခု သို့မဟုတ် သင့်တွင် "တစ်ဦးချင်းအခြေအနေများကို ဖုံးအုပ်ထားသည်။" အခန်းကဏ္ဍသည် linear (cyclomatic complexity 1) ဆိုလျှင် ပိုကောင်းသည်ဟု ကျွန်ုပ်ထင်မြင်ပါသည်။

ဖောင်တွင် ifs (ရှင်းလင်းပြတ်သားစွာ သို့မဟုတ် ကြေငြာချက်- နည်းပါးသည်။ when သို့မဟုတ် ပုံစံ include_vars variables အစုံဖြင့်) အခန်းကဏ္ဍပိုကောင်းလေဖြစ်သည်။ တစ်ခါတလေမှာ အကိုင်းအခက်တွေ လုပ်ရပေမယ့် နည်းနည်းရှိလေလေ ပိုကောင်းလေပါပဲ။ ဒါကြောင့် galaxy နဲ့ ကောင်းမွန်တဲ့ အခန်းကဏ္ဍတစ်ခု (ဒါက အလုပ်လုပ်ပါတယ်!) နဲ့ စည်းထားပုံရပါတယ်။ when အလုပ်ငါးခုမှ "တစ်ဦး၏ကိုယ်ပိုင်" အခန်းကဏ္ဍထက် ပိုနည်းသည်။ galaxy နဲ့ အခန်းကဏ္ဍက ပိုကောင်းလာတဲ့အခိုက်အတန့်က တစ်ခုခုကို စရေးတဲ့ အချိန်ပါပဲ။ ပိုဆိုးလာတဲ့အခိုက်အတန့်ကတော့ တစ်ခုခုကွဲသွားတဲ့အခါ “ဂလက်ဆီနဲ့ အခန်းကဏ္ဍ” ကြောင့်ဖြစ်တယ်ဆိုတဲ့ သံသယတွေ ရှိနေပါတယ်။ သင် ၎င်းကိုဖွင့်ပြီး၊ ပါဝင်မှုငါးခု၊ လုပ်ဆောင်စရာစာရွက် ရှစ်ခုနှင့် အပိုင်းတစ်ခုပါရှိသည်။ when'အိုး... ငါတို့ ဒါကို အဖြေရှာဖို့ လိုတယ်။ လုပ်ဆောင်စရာ ၅ ခုအစား၊ ချိုးဖျက်စရာမရှိသော linear စာရင်းတစ်ခု။

အောက်ပါအပိုင်းများတွင်

• စာရင်းအင်းများ၊ အုပ်စုကွဲလွဲချက်များ၊ host_group_vars plugin၊ hostvars အကြောင်း အနည်းငယ်။ ဂေါ်ဖီထုပ်ကို spaghetti နဲ့ ဘယ်လိုချည်မလဲ။ နယ်ပယ်နှင့် ရှေ့ပြေးကိန်းရှင်များ၊ Ansible memory model။ "ဒါဆို ဒေတာဘေ့စ်အတွက် အသုံးပြုသူအမည်ကို ဘယ်မှာ သိမ်းဆည်းမလဲ။"
• jinja: {{ jinja }} - nosql notype nosense ပျော့ပလပ်စတစ်။ မင်းမမျှော်လင့်ထားတဲ့ နေရာတိုင်းမှာ ရှိနေတယ်။ နည်းနည်းလောက် !!unsafe နှင့်အရသာရှိသော yaml ။

source: www.habr.com