Optimizing Ansible Playbooks: Delegation

ဒီတစ်ခါတော့ Ansible ကိုလေ့လာနေကြတဲ့သူတွေအတွက် ကောင်းမွန်တဲ့ Ansible Playbook တစ်ခုရဖို့ Optimize လုပ်တဲ့အခါ သိထားသင့်တဲ့ နည်းလမ်းလေးတွေကိုမျှဝေချင်ပါတယ်။ ပထမဦးဆုံးအနေနဲ့ သိစေချင်တဲ့အချက်ကတော့ Delegation ပဲဖြစ်ပါတယ်။ မြန်မာလိုဆီလျော်အောင်ပြောမယ်ဆိုရင်တော့ တာဝန်ပေးတယ်လို့ဆိုရပါလိမ့်မယ်။ Ansible Playbook ဆိုတာ တကယ်တော့ ဆောင်ရွက်စေချင်တဲ့ လုပ်ငန်းဆောင်တာ (Task) တွေကို အစီအစဉ်တကျ ရေးသားထားတဲ့ စာသားဖိုင် (Text File) လေးတွေပါ။ ဒီ Task တွေကို ဘယ် server၊ ဘယ် device မှာလုပ်ဆောင်ခိုင်းမယ်ဆိုတာကို hosts ဆိုတဲ့ keyword နဲ့ကြေငြာပေးရပါတယ်။ Playbook ရေးကြည့်ဖူးတဲ့သူတွေဆိုရင်သိပါလိမ့်မယ်။ ဥပမာအနေနဲ့ ဒီ Playbook ကိုကြည့်ကြည့်ပါ။

play - one ဆိုတဲ့ Play တစ်ခုကနေ vm01.example.com ဆိုတဲ့ Host ပေါ်မှာ task တစ်ခု run ခိုင်းထားတာပါ။ အဓိကသတိထားမိစေချင်တာက myvar နဲ့ ansible_nodename ဆိုတဲ့ Variable တွေပဲဖြစ်ပါတယ်။ myvar ကတော့ play - one ဆိုတဲ့ play ရဲ့ variable ဖြစ်ပြီး ansible_nodename ကတော့ vm01.example.com ရဲ့ Facts ထဲက variable ကိုဖော်ပြခိုင်းထားတာပါ။ ထွက်လာတဲ့ output ကိုကြည့်ကြည့်ပါ။

အရင်ဦးဆုံး vm01.example.com ရဲ့ Facts တွေကို ရယူပါတယ်။ ပြီးမှ task - one ဆိုတဲ့ task ကို run ပါတယ်။ task ရဲ့ result ထဲမှာတွေ့ရတဲ့ ok: [vm01.example.com] ဆိုတဲ့ message က vm01.example.com ပေါ်မှာ task တွေ လုပ်ဆောင်သွားတယ်ဆိုတာကို ဖော်ပြနေတာဖြစ်ပြီး myvar နဲ့ ansible_nodename ဆိုတဲ့ variable တွေရဲ့ value တွေအနေနဲ့ကတော့ variable one နဲ့ vm01.example.com ဆိုပြီးတွေ့ရပါလိမ့်မယ်။

ဒီတစ်ခါ လက်ရှိ Playbook ထဲမှာပဲ နောက်ထပ် Play တစ်ခု ထပ်ထည့်ကြည့်ပါမယ်။

vm02.example.com ဆိုတဲ့ host ကို delegate လုပ်ပြီး ထပ်ဖြည့်လိုက်တဲ့ play - two ဆိုတဲ့ Play မှာတော့ myvar ရဲ့ value က variable two ဖြစ်ပြီး ansible_nodename ကတော့ vm02.example.com ဖြစ်နေတာတွေ့ရပါလိမ့်မယ်။

ဒီလို Play နှစ်ခုခွဲရေးခြင်းအားဖြင့် မတူညီတဲ့ Host တွေ Host Group တွေမှာ မတူညီတဲ့ task တွေကို Playbook တစ်ခုတည်းကနေလုပ်ဆောင်နိုင်စေမှာဖြစ်ပါတယ်။ Play တစ်ခုတည်းနဲ့သာဆိုရင် အဲဒီ Play အတွက် delegate လုပ်လိုက်တဲ့ Host ဒါမှမဟုတ် Host Group တစ်ခုအတွက် တူညီတဲ့ task တွေကိုပဲ ဆောင်ရွက်ပေးနိုင်မှာဖြစ်ပါတယ်။ ဒါပေမဲ့ တချို့အခြေအနေတွေမှာတော့ Playbook တစ်ခုထဲ Play တွေခွဲရေးရုံနဲ့ အဆင်မပြေနိုင်တဲ့ အခြေအနေတွေရှိပါတယ်။ အဓိကက delegate လုပ်နေတဲ့ Host၊ တနည်းအားဖြင့် hosts keyword နဲ့ကြေငြာထားတဲ့ Host ရဲ့ Facts ကို အခြား host တစ်ခုမှာ run မယ့် Task ထဲထည့်သွင်းအသုံးပြုချင်တယ်ဆိုရင် တော့ Play ခွဲရေးတဲ့နည်းကအဆင်မပြေတော့ပါဘူး။ Play တစ်ခုရဲ့ Facts တွေကို အဲ့ဒီ Play အတွင်းမှာရှိတဲ့ Task တွေကပဲအသုံးပြုနိုင်တာကြောင့်ပါ။ အပေါ်ကနမူနာမှာတွေ့ရတဲ့အတိုင်း ansible_nodename ဆိုတဲ့ variable အနေနဲ့ name တူသည့်တိုင်အောင် Play မတူတဲ့ အတွက် သက်ဆိုင်ရာ Host ရဲ့ Facts ပေါ်မူတည်ပြီး value တွေမတူတော့တာကိုမြင်တွေ့ရတာပဲဖြစ်ပါတယ်။ ဒါကြောင့် ပထမ Play ရဲ့ host မှာရှိတဲ့ ansible_nodename ဆိုတဲ့ Fact variable ကို ဒုတိယ Play ရဲ့ host မှာဆက်သုံးနိုင်စေဖို့ရာ အလွယ်ကူဆုံးကတော့ အဲဒီ Play ၂ခုကို တစ်ခုတည်းအနေနဲ့ ပေါင်းလိုက်ပြီး delegate_to ဆိုတဲ့ keyword ကိုသုံးလိုက်တဲ့နည်းပဲဖြစ်ပါတယ်။

ဒီ Playbook မှာတော့ play - one ဆိုတဲ့ Play တစ်ခုတည်းပါပြီး သူ့ထဲမှာမှ task - one နဲ့ task - two ဆိုပြီး task နှစ်ခုခွဲထားပါတယ်။

ဒီ result ကို Play နှစ်ခုခွဲရေးထားတဲ့ Playbook ရဲ့ result နဲ့ ယှဉ်ကြည့်ပါ။ Gathering Facts အနေနဲ့ vm01.example.com အတွက်သာတွေ့ရမှာဖြစ်ပြီး task နှစ်ခုလုံးမှာပေးထားတဲ့ ansible_nodename ဆိုတဲ့ Fact variable ရဲ့ value က vm01.example.com ပဲဖြစ်နေပါလိမ့်မယ်။ ဒါပေမဲ့ task - two အနေနဲ့ တကယ်တမ်း run သွားတာက vm02.example.com ပေါ်မှာဖြစ်တယ် ဆိုတာကို ok: [vm01.example.com -> vm02.example.com] ဆိုတဲ့ output နဲ့ဖေါ်ပြပေးနေတာကိုတွေ့ရမှာပဲဖြစ်ပါတယ်။ ပိုပြီး မြင်သာချင်တယ်ဆိုရင်တော့ အောက်မှာဖော်ပြထားတဲ့ Playbook နဲ့ထပ်မံစမ်းကြည့်နိုင်ပါတယ်။

အဓိကကတော့ လက်ရှိ run နေတဲ့ Play ထဲမှာအကြုံးမဝင်တဲ့ အခြား Host/Host Group မှာ task တချို့ကို လှမ်းပြီး run စေချင်တယ်ဆိုရင်တော့ Play တစ်ခုထပ်ခွဲစရာမလိုပဲ delegate_to နဲ့ run ခိုင်းလို့ ရတယ်ဆိုတာရယ်၊ Play နဲ့သတ်ဆိုင်တဲ့ Facts တွေကို ဆက်လက် အသုံးပြုနိုင်မှာ ဖြစ်တယ်ဆိုတာရယ်ကို သိထားခြင်းအားဖြင့် လိုအပ်သလို ထည့်သွင်း အသုံးပြုနိုင်စေဖို့ပဲ ဖြစ်ပါတယ်။ delegate_to keyword မသုံးလဲ အလုပ်ဖြစ်တဲ့ နည်းလမ်းတွေရှိပေမဲ့ သုံးလိုက်ခြင်းအားဖြင့် ကိုယ့်ရဲ့ Playbook မှာမလိုအပ်တဲ့ ရှုပ်ထွေးသွားစေနိုင်တဲ့ task တွေကိုလျှော့ချနိုင်သွားမှာဖြစ်ပါတယ်။

Reference: Playbooks_Delegation