میں جوابی کوڈ کے بہت سارے جائزے اور اپنی بہت ساری تحریر کرتا ہوں۔ کیڑے (میرے اور دوسرے دونوں) کا تجزیہ کرتے ہوئے اور چند انٹرویوز کرتے ہوئے، مجھے احساس ہوا کہ جوابدہ صارفین بنیادی باتوں پر عبور حاصل کیے بغیر پیچیدہ مسائل سے نمٹنا کرتے ہیں۔

اس عالمگیر ناانصافی کو درست کرنے کے لیے، میں نے ان لوگوں کے لیے جواب دینے کا ایک تعارف لکھنے کا فیصلہ کیا جو اسے پہلے سے جانتے ہیں۔ خبردار رہو، یہ منگا کا دوبارہ بیان نہیں ہے، بلکہ بہت سارے الفاظ اور تصویروں کے ساتھ ایک طویل پڑھنا ہے۔

قارئین کی متوقع سطح یہ ہے کہ یملا کی کئی ہزار سطریں پہلے ہی لکھی جا چکی ہیں، کچھ پہلے ہی پروڈکشن میں ہے، لیکن "کسی نہ کسی طرح سب کچھ ٹیڑھا ہے۔"

نام

جوابدہ صارفین جو سب سے بڑی غلطی کرتے ہیں وہ یہ نہیں جانتے کہ چیزوں کو کیا کہتے ہیں۔ اگر آپ نام نہیں جانتے تو آپ دستاویزات کو نہیں سمجھ سکتے۔ ایک حقیقی زندگی کی مثال: ایک انٹرویو کے دوران، کوئی ایسا شخص جس نے دعویٰ کیا کہ اس نے بہت زیادہ جوابی تحریر لکھی ہے، اس سوال کا جواب نہیں دے سکا، "ایک پلے بک کن عناصر پر مشتمل ہوتی ہے؟" اور جب میں نے نشاندہی کی کہ "جواب کی توقع تھی کہ ایک پلے بک ڈراموں پر مشتمل ہے"، تباہ کن تبصرہ تھا، "ہم اسے استعمال نہیں کرتے۔" لوگ پیسے کے لیے جوابی لکھتے ہیں اور ڈرامے استعمال نہیں کرتے۔ وہ اصل میں اسے استعمال کرتے ہیں، لیکن نہیں جانتے کہ یہ کیا ہے.

تو آئیے سادہ سے شروع کریں: ان چیزوں کو کیا کہتے ہیں؟ ہو سکتا ہے کہ آپ یہ جانتے ہوں، شاید آپ نہیں جانتے، کیونکہ آپ نے دستاویزات کو پڑھتے وقت توجہ نہیں دی۔

جوابی پلے بک ایک پلے بک کو چلاتی ہے۔ پلے بک ایک فائل ہے جس میں yml/yaml ایکسٹینشن ہے، جس میں کچھ اس طرح ہے:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

ہم پہلے ہی قائم کر چکے ہیں کہ یہ پوری فائل ایک پلے بک ہے۔ ہم آپ کو دکھا سکتے ہیں کہ کردار اور کام کہاں ہیں۔ لیکن ڈرامہ کہاں ہے؟ اور ڈرامہ کسی کردار یا پلے بک سے کیسے مختلف ہے؟

یہ سب دستاویزات میں ہے۔ اور لوگ اسے چھوڑ دیتے ہیں۔ ابتدائی لوگ اسے چھوڑ دیتے ہیں کیونکہ ابھی یاد رکھنے کے لیے بہت کچھ ہے۔ تجربہ کار کوڈر اسے چھوڑ دیتے ہیں کیونکہ یہ "معمولی" ہے۔ اگر آپ تجربہ کار ہیں تو ہر چھ ماہ میں کم از کم ایک بار ان صفحات کو دوبارہ پڑھیں، اور آپ کا کوڈ ایک کلاس کے علاوہ ہوگا۔

تو، یاد رکھیں: پلے بک پلے کی ایک فہرست ہے اور import_playbook.
یہاں ایک ڈرامہ ہے:

- hosts: group1
  roles:
    - role1

اور یہ بھی ایک اور ڈرامہ ہے:

- hosts: group2,group3
  tasks:
    - debug:

پلے کیا ہے؟ یہ کس لیے ہے؟

پلے پلے بک کا ایک اہم عنصر ہے، کیونکہ پلے، اور صرف پلے، کرداروں اور/یا کاموں کی فہرست کو میزبانوں کی فہرست سے جوڑتا ہے جس پر انہیں انجام دیا جانا چاہیے۔ دستاویزات کی گہرائی میں، آپ کو ذکر مل سکتا ہے۔ delegate_to، مقامی تلاش کے پلگ ان، نیٹ ورک-کلی-مخصوص ترتیبات، جمپ ہوسٹس، وغیرہ۔ وہ آپ کو کاموں کے عمل کی جگہ کو تھوڑا سا تبدیل کرنے کی اجازت دیتے ہیں۔ لیکن اس کے بارے میں بھول جاؤ. ان ہوشیار اختیارات میں سے ہر ایک کے بہت ہی مخصوص استعمال ہوتے ہیں، اور وہ یقینی طور پر آفاقی نہیں ہیں۔ ہم ان بنیادی باتوں کے بارے میں بات کر رہے ہیں جو ہر کسی کو جاننا اور استعمال کرنا چاہیے۔

اگر آپ "کچھ" "کہیں" کو انجام دینا چاہتے ہیں تو آپ ایک ڈرامہ لکھتے ہیں۔ کردار نہیں۔ ماڈیولز اور مندوبین کے ساتھ کوئی کردار نہیں۔ تم صرف ڈرامہ لکھو۔ میزبان فیلڈ میں، آپ یہ بتاتے ہیں کہ کہاں عمل کرنا ہے، اور رولز/ٹاسک میں، کیا کرنا ہے۔

یہ آسان ہے، ٹھیک ہے؟ یہ دوسری صورت میں کیسے ہو سکتا ہے؟

ایک خصوصیت والا لمحہ جب لوگ کھیلے بغیر یہ کرنا چاہتے ہیں وہ ہے "وہ کردار جو سب کچھ ترتیب دیتا ہے۔" وہ ایک ایسا کردار حاصل کرنا چاہتے ہیں جو ہر چیز کو ترتیب دے اور سرور پہلی قسم، اور سرور کی دوسری قسم۔

ایک قدیم مثال نگرانی ہے۔ میں ایک مانیٹرنگ رول کرنا چاہتا ہوں جو مانیٹرنگ کو ترتیب دے گا۔ نگرانی کا کردار نگرانی کے میزبانوں کو تفویض کیا گیا ہے (کھیل کے مطابق)۔ لیکن یہ پتہ چلتا ہے کہ نگرانی کے لیے، ہمیں ان میزبانوں کے لیے پیکجز تعینات کرنے کی ضرورت ہے جن کی ہم نگرانی کر رہے ہیں۔ ایک مندوب کا استعمال کیوں نہیں کرتے؟ اور ہمیں iptables کو بھی ترتیب دینے کی ضرورت ہے۔ ایک مندوب؟ اور ہمیں نگرانی کو فعال کرنے کے لیے DBMS کنفیگریشن فائل کو لکھنے/تبدیل کرنے کی بھی ضرورت ہے۔ ایک مندوب! اور اگر آپ تخلیقی محسوس کر رہے ہیں، تو آپ ایک وفد بنا سکتے ہیں۔ include_role گروپوں کی فہرست میں ایک ہوشیار فلٹر کے ساتھ نیسٹڈ لوپ میں، اور اندر include_role آپ اب بھی کر سکتے ہیں delegate_to دوبارہ اور ہم چلتے ہیں...

ایک واحد نگرانی کے کردار کی نیک خواہش جو "سب کچھ کرتا ہے" ہمیں سراسر جہنم میں لے جاتا ہے، جہاں سے عام طور پر ایک ہی راستہ ہوتا ہے: ہر چیز کو شروع سے دوبارہ لکھنا۔

غلطی کہاں ہوئی؟ جس لمحے آپ نے دریافت کیا کہ میزبان X پر ٹاسک "x" انجام دینے کے لیے آپ کو میزبان Y کے پاس جانا ہوگا اور وہاں "y" کرنا ہوگا، آپ کو ایک سادہ مشق کرنی چاہیے تھی: جا کر ایک ڈرامہ لکھیں جو y میزبان Y پر کرتا ہے۔ "x" میں کچھ شامل نہ کریں، بلکہ شروع سے لکھیں۔ یہاں تک کہ ہارڈ کوڈ متغیرات کے ساتھ۔

اوپر والے پیراگراف درست معلوم ہوتے ہیں۔ لیکن یہ آپ کا معاملہ نہیں ہے! کیونکہ آپ دوبارہ قابل استعمال کوڈ لکھنا چاہتے ہیں جو کہ DRY اور لائبریری جیسا ہو، اور آپ کو ایسا کرنے کا راستہ تلاش کرنے کی ضرورت ہے۔

یہاں ایک اور سنگین غلطی چھپی ہوئی ہے۔ ایک غلطی جس نے بہت سارے پروجیکٹس کو قابل تحریر سے تبدیل کردیا ہے (یہ بہتر ہوسکتا ہے ، لیکن سب کچھ کام کرتا ہے اور ختم کرنا آسان ہے) مکمل ہولناکیوں میں جس کا مصنف بھی اندازہ نہیں کرسکتا۔ یہ کام کرتا ہے، لیکن خدا کسی کو کچھ بھی بدلنے سے منع کرتا ہے۔

غلطی یہ ہے: ایک کردار لائبریری کا فنکشن ہے۔ اس مشابہت نے بہت سارے اچھے پروجیکٹس کو برباد کر دیا ہے یہ دیکھ کر دکھ ہوتا ہے۔ ایک کردار لائبریری کا فنکشن نہیں ہے۔ یہ حساب نہیں کر سکتا، اور یہ پلے لیول کے فیصلے نہیں کر سکتا۔ مجھے یاد دلائیں کہ پلے کیا فیصلے کرتا ہے؟

شکریہ، آپ ٹھیک کہہ رہے ہیں۔ Play فیصلہ کرتا ہے (یا اس کے بجائے، معلومات پر مشتمل ہے) اس بارے میں کہ کون سے کام اور کردار کن میزبانوں پر چلائے جائیں۔

اگر آپ اس فیصلے کو کسی کردار کے سپرد کرتے ہیں، خاص طور پر حساب کے ساتھ، تو آپ اپنے آپ کو (اور کوئی اور جو آپ کے کوڈ کو پارس کرنے کی کوشش کر رہا ہے) کو ایک دکھی وجود کی مذمت کر رہے ہیں۔ کردار اس بات کا فیصلہ نہیں کرتا کہ یہ کہاں پر عمل کرتا ہے۔ پلے یہ فیصلہ کرتا ہے۔ کردار وہی کرتا ہے جو اسے بتایا جاتا ہے، جہاں اسے بتایا جاتا ہے۔

ہم اس بات پر بحث کریں گے کہ جوابی پروگرامنگ کیوں خطرناک ہے اور COBOL کس طرح Ansible سے بہتر ہے متغیرات اور جنجا کے باب میں۔ ابھی کے لیے، ہم صرف یہ کہیں گے: آپ کا ہر حساب کتاب عالمی متغیرات میں تبدیلیوں کا ایک انمٹ نشان چھوڑتا ہے، اور اس کے بارے میں آپ کچھ نہیں کر سکتے۔ جیسے ہی یہ دونوں "ٹریس" آپس میں ملتے ہیں، سب کچھ ختم ہو جاتا ہے۔

چننے والوں کے لیے نوٹ: کردار یقینی طور پر کنٹرول کے بہاؤ کو متاثر کر سکتا ہے۔ ہے delegate_to اور اس میں کچھ معقول درخواستیں ہیں۔ ہیں meta: end host/play. لیکن! یاد رکھیں، ہم بنیادی باتیں سیکھ رہے ہیں؟ کے بارے میں بھول گیا delegate_toہم سب سے آسان اور خوبصورت جوابی کوڈ کے بارے میں بات کر رہے ہیں۔ یہ پڑھنے میں آسان، لکھنے میں آسان، ڈیبگ کرنے میں آسان، جانچنے میں آسان اور بہتر کرنے میں آسان ہے۔ تو، ایک بار پھر:

play and only play فیصلہ کرتا ہے کہ کون سے میزبانوں پر عمل کیا جاتا ہے۔

اس سیکشن میں، ہم نے کھیل اور کردار کے درمیان تعلق کو دریافت کیا ہے۔ اب آئیے کاموں اور کرداروں کے درمیان تعلق کو دریافت کریں۔

کام اور کردار

آئیے اس ڈرامے کو دیکھتے ہیں:

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

آئیے کہتے ہیں کہ آپ کو foo کرنے کی ضرورت ہے۔ اور ایسا لگتا ہے۔ foo: name=foobar state=presentمیں یہ کہاں لکھوں؟ پری میں؟ پوسٹ ایک کردار بنائیں؟

…اور کام کہاں گئے؟

ہم بنیادی باتوں کے ساتھ دوبارہ شروع کر رہے ہیں — Play سسٹم۔ اگر آپ اس بارے میں واضح نہیں ہیں، تو آپ Play کو ہر چیز کے لیے بنیاد کے طور پر استعمال نہیں کر سکتے، اور آپ کے نتائج متزلزل ہوں گے۔

پلے ڈیوائس: ڈائریکٹو، پلے سیٹنگز، اور پری_ٹاسک، ٹاسکس، رولز اور پوسٹ_ٹاسک سیکشنز کی میزبانی کرتا ہے۔ باقی کھیل کے پیرامیٹرز اب ہمارے لیے اہم نہیں ہیں۔

کاموں اور کرداروں کے ساتھ ان کے حصوں کی ترتیب: pre_tasks, roles, tasks, post_tasks. چونکہ semantically کے درمیان پھانسی کا حکم tasks и roles یہ واضح نہیں ہے، لیکن بہترین طریقوں کا کہنا ہے کہ ہم ایک سیکشن شامل کرتے ہیں۔ tasks، صرف اگر نہیں rolesاگر موجود ہے۔ roles، پھر تمام منسلک کام حصوں میں رکھے جاتے ہیں۔ pre_tasks/post_tasks.

صرف ایک چیز جو باقی ہے وہ یہ ہے کہ سب کچھ واضح ہے: پہلے pre_tasksپھر rolesپھر post_tasks.

لیکن ہم نے ابھی تک اس سوال کا جواب نہیں دیا ہے: ماڈیول کال کہاں ہے؟ foo کیا ہمیں لکھنا چاہیے؟ کیا ہمیں ہر ماڈیول کے لیے ایک مکمل کردار لکھنے کی ضرورت ہے؟ یا یہ بہتر ہے کہ ہر چیز کے لیے ایک ہی کردار ہو؟ اور اگر کوئی کردار نہیں تو ہم اسے کہاں لکھیں — پہلے یا پوسٹ میں؟

اگر ان سوالات کا کوئی معقول جواب نہیں ہے، تو یہ وجدان کی کمی کی علامت ہے، یعنی وہی "متزلزل بنیادیں"۔ آئیے اس کا پتہ لگائیں۔ سب سے پہلے، ایک سیکورٹی سوال: اگر کھیل ہے 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 ہمیں رول ایگزیکیوشن کے نتائج (بشمول ہینڈلرز) کے ساتھ کام کرنے کی اجازت دے گا۔

ایک گہری جوابدہ ماہر ہمیں بتائے گا کہ کیا ہے۔ meta: flush_handlers، لیکن اگر ہم کھیل میں سیکشن پر عمل درآمد کے حکم پر بھروسہ کر سکتے ہیں تو ہمیں flush_handlers کی ضرورت کیوں ہے؟ مزید برآں، meta: flush_handlers کا استعمال ڈپلیکیٹ ہینڈلرز کے ساتھ غیر متوقع مسائل پیدا کر سکتا ہے، جس کے استعمال پر عجیب انتباہات کا باعث بن سکتا ہے۔ when у block وغیرہ وغیرہ۔ آپ جواب کو جتنا بہتر جانتے ہوں گے، آپ "مشکل" حل کے لیے اتنی ہی باریکیوں کی شناخت کر سکیں گے۔ لیکن سادہ حل — پہلے/کردار/پوسٹ کے درمیان قدرتی تقسیم کا استعمال کرتے ہوئے — سیدھا ہے۔

اور، ہمارے 'foo' پر واپس۔ ہم اسے کہاں رکھنا چاہئے؟ پری، پوسٹ، یا کردار میں؟ ظاہر ہے، یہ اس بات پر منحصر ہے کہ آیا ہمیں foo کے لیے ہینڈلر کے نتائج کی ضرورت ہے۔ اگر ہم ایسا نہیں کرتے ہیں، تو foo کو پہلے یا پوسٹ میں نہیں رکھا جانا چاہیے- ان حصوں کا ایک خاص مقصد ہے: کوڈ کے مرکزی حصے سے پہلے اور بعد میں کاموں کو انجام دینا۔

اب "کردار یا ٹاسک" سوال کا جواب ڈرامے میں پہلے سے موجود چیزوں پر آتا ہے — اگر کام ہیں، تو آپ کو انہیں کاموں میں شامل کرنے کی ضرورت ہے۔ اگر کردار ہیں، تو آپ کو ایک کردار بنانے کی ضرورت ہے (چاہے یہ صرف ایک کام ہی کیوں نہ ہو)۔ یاد دہانی کے طور پر، کاموں اور کرداروں کو بیک وقت استعمال نہیں کیا جا سکتا۔

جوابدہی کے بنیادی اصولوں کو سمجھنا بظاہر ذاتی سوالوں کے صحیح جوابات فراہم کرتا ہے۔

کام اور کردار (حصہ دو)

اب آئیے اس صورتحال پر بات کرتے ہیں جہاں آپ ابھی پلے بک لکھنا شروع کر رہے ہیں۔ آپ کو foo، bar، اور baz بنانے کی ضرورت ہے۔ کیا یہ تین کام ہیں، ایک کردار، یا تین کردار؟ خلاصہ کرنے کے لیے، آپ کو کردار لکھنا کب شروع کرنا چاہیے؟ جب آپ کام لکھ سکتے ہیں تو کردار لکھنے کا کیا فائدہ ہے؟ اور کردار کیا ہے؟

سب سے بڑی غلطیوں میں سے ایک (میں نے پہلے ہی اس کا ذکر کیا ہے) پروگرام کی لائبریری میں ایک فنکشن کے طور پر کردار کے بارے میں سوچنا ہے۔ فنکشن کی عمومی وضاحت کیسی نظر آتی ہے؟ یہ ان پٹ دلائل لیتا ہے، سائڈ کالز کے ساتھ تعامل کرتا ہے، ضمنی اثرات انجام دیتا ہے، اور ایک قدر واپس کرتا ہے۔

اب، توجہ دینا. آپ ایک کردار میں کیا کر سکتے ہیں؟ کال سائڈ ایفیکٹس - ہمیشہ خوش آمدید؛ یہ جواب دینے کا پورا نقطہ ہے - ضمنی اثرات پیدا کرنا۔ سائیڈ کالز ہیں؟ سادہ لیکن "ایک قدر پاس کریں اور اسے واپس کریں" - یہ وہ جگہ ہے جہاں یہ مشکل ہو جاتا ہے۔ سب سے پہلے، آپ کسی کردار کو قدر نہیں دے سکتے۔ آپ کردار کے لیے vars سیکشن میں زندگی بھر کے کھیل کے ساتھ عالمی متغیر سیٹ کر سکتے ہیں۔ آپ ایک کردار کے اندر زندگی بھر کے کھیل کے ساتھ ایک عالمی متغیر ترتیب دے سکتے ہیں۔ یا پلے بک لائف ٹائم کے ساتھ بھی (set_fact/register)۔ لیکن آپ کے پاس "مقامی متغیرات" نہیں ہوسکتے ہیں۔ آپ "قدر نہیں لے سکتے" اور "واپس" نہیں کر سکتے۔

اس سے جو اہم نکتہ سامنے آتا ہے وہ یہ ہے کہ آپ ضمنی اثرات کے بغیر جواب میں کچھ نہیں لکھ سکتے۔ عالمی متغیرات کو تبدیل کرنا ہمیشہ کسی فنکشن کے لیے ایک ضمنی اثر ہوتا ہے۔ زنگ میں، مثال کے طور پر، عالمی متغیر کو تبدیل کرنا ہے۔ unsafeاور جواب میں، یہ ایک کردار کے لیے اقدار کو متاثر کرنے کا واحد طریقہ ہے۔ استعمال کیے گئے الفاظ کو نوٹ کریں: "کردار کے لیے قدر کو منتقل کریں"، بلکہ "کردار کے ذریعے استعمال ہونے والی اقدار کو تبدیل کریں۔" کرداروں کے درمیان کوئی تنہائی نہیں ہے۔ کاموں اور کرداروں کے درمیان کوئی تنہائی نہیں ہے۔

کل: ایک کردار ایک فنکشن نہیں ہے.

ایک کردار کے بارے میں کیا اچھا ہے؟ سب سے پہلے، ایک کردار کی ڈیفالٹ اقدار ہوتی ہیں (/default/main.yaml)، دوم، رول میں فائلوں کو اسٹور کرنے کے لیے اضافی ڈائریکٹریز ہیں۔

پہلے سے طے شدہ اقدار کے بارے میں کیا بہت اچھا ہے؟ کیونکہ Ansible کی بجائے بٹی ہوئی Maslow کی متغیر ترجیحات کے درجہ بندی میں، رول ڈیفالٹس سب سے کم اہم ہیں (Asible کے کمانڈ لائن پیرامیٹرز کو چھوڑ کر)۔ اس کا مطلب یہ ہے کہ اگر آپ کو پہلے سے طے شدہ اقدار فراہم کرنے کی ضرورت ہے اور انوینٹری یا گروپ متغیرات سے قدروں کو اوور رائیڈ کرنے کے بارے میں فکر نہ کریں، تو رول ڈیفالٹس آپ کے لیے واحد صحیح جگہ ہیں۔ (میں تھوڑا جھوٹ بول رہا ہوں - اور بھی ہے۔) |d(your_default_here)، لیکن اگر ہم اسٹیشنری جگہوں کے بارے میں بات کرتے ہیں، تو صرف رول ڈیفالٹس)۔

کرداروں کے بارے میں اور کیا اچھا ہے؟ ان کے اپنے کیٹلاگ ہیں۔ یہ متغیرات کے لیے کیٹلاگ ہیں، دونوں مستقل (یعنی کردار کے لیے حساب کیا جاتا ہے) اور متحرک (ایک پیٹرن یا اینٹی پیٹرن ہے- include_vars ساتھ مل کر {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.) یہ اس کے لیے ڈائریکٹریز ہیں۔ files/, templates/. یہ کرداروں کو اپنے ماڈیولز اور پلگ ان رکھنے کی بھی اجازت دیتا ہے (library/)۔ لیکن، پلے بک کے کاموں کے مقابلے (جس میں یہ سب کچھ بھی ہو سکتا ہے)، یہاں صرف ایک فائدہ یہ ہے کہ فائلوں کو ایک ڈھیر میں نہیں بلکہ کئی الگ الگ ڈھیروں میں ڈالا جاتا ہے۔

ایک اور تفصیل: آپ ایسے کردار بنانے کی کوشش کر سکتے ہیں جو دوبارہ قابل استعمال ہوں (Galaxy کے ذریعے)۔ کلیکشنز کی آمد کے ساتھ، رول شیئرنگ کو تقریباً فراموش سمجھا جا سکتا ہے۔

لہذا کرداروں میں دو اہم خصوصیات ہیں: ان میں ڈیفالٹس ہیں (ایک منفرد خصوصیت) اور وہ آپ کو اپنے کوڈ کی ساخت بنانے کی اجازت دیتے ہیں۔

اصل سوال کی طرف لوٹنا: کاموں کو کب استعمال کرنا ہے اور کرداروں کو کب استعمال کرنا ہے؟ پلے بک میں کام اکثر یا تو کرداروں سے پہلے یا بعد میں "گلو" کے طور پر استعمال ہوتے ہیں، یا اسٹینڈ اسٹون بلڈنگ بلاک کے طور پر استعمال ہوتے ہیں (اس صورت میں کوڈ میں کردار نہیں ہونے چاہئیں)۔ کرداروں کے ساتھ ملا ہوا عام کاموں کا ڈھیر واضح طور پر میلا ہے۔ ایک مخصوص انداز کی پیروی کی جانی چاہیے - یا تو کام یا کردار۔ کردار خدشات اور ڈیفالٹس کی علیحدگی فراہم کرتے ہیں، جبکہ کام کوڈ کو پڑھنے میں آسان بناتے ہیں۔ عام طور پر، کرداروں کو زیادہ "اسٹیشنری" (اہم اور پیچیدہ) کوڈ کے لیے استعمال کیا جاتا ہے، جب کہ ٹاسک طرز کے اسکرپٹ کو معاون اسکرپٹ کے لیے استعمال کیا جاتا ہے۔

import_role کو ایک کام کے طور پر بنانا ممکن ہے، لیکن اگر آپ ایسی بات لکھتے ہیں، تو اپنے حسن کے احساس کو سمجھانے کے لیے تیار رہیں کہ آپ ایسا کیوں کرنا چاہتے ہیں۔

ایک اچھا قاری یہ کہہ سکتا ہے کہ کردار کردار درآمد کر سکتے ہیں، کرداروں کا انحصار galaxy.yml کے ذریعے ہو سکتا ہے، اور خوفناک اور خوفناک بھی ہے۔ include_role — میں آپ کو یاد دلاتا ہوں کہ ہم فگر جمناسٹکس میں نہیں بلکہ بنیادی جواب دینے میں اپنی صلاحیتوں کو بہتر بنا رہے ہیں۔

ہینڈلر اور کام

آئیے ایک اور واضح چیز پر بات کرتے ہیں: ہینڈلرز۔ ان کو صحیح طریقے سے استعمال کرنے کا طریقہ جاننا تقریباً ایک فن ہے۔ ہینڈلر اور ٹاسک میں کیا فرق ہے؟

چونکہ ہم بنیادی باتوں کا جائزہ لے رہے ہیں، یہاں ایک مثال ہے:

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

رول کے ہینڈلرز کو rolename/handlers/main.yaml میں محفوظ کیا جاتا ہے۔ ہینڈلرز تمام پلے شرکاء کے درمیان شیئر کیے جاتے ہیں: pre/post_tasks کسی کردار کے ہینڈلرز کو کال کر سکتے ہیں، اور ایک کردار ہینڈلرز کو ڈرامے کے اندر سے کال کر سکتا ہے۔ تاہم، کراس رول ہینڈلر کالیں معمولی ہینڈلر کو دہرانے سے کہیں زیادہ خلل ڈالتی ہیں۔ (ایک اور بہترین عمل ہینڈلر کے ناموں کو دہرانے سے گریز کرنا ہے۔)

بنیادی فرق یہ ہے کہ کام کو ہمیشہ انجام دیا جاتا ہے۔ when)، اور ہینڈلر ریاست کی تبدیلی سے متحرک ہوتا ہے (اطلاع صرف اس صورت میں ٹرگر کیا جاتا ہے جب کوئی تبدیلی ہوئی ہو)۔ اس کے نتائج کیا ہیں؟ مثال کے طور پر، اگر دوبارہ شروع کرنے پر کوئی تبدیلی نہیں ہوئی، تو کوئی ہینڈلر نہیں ہوگا۔ اور جب اصل کام تبدیل نہیں ہوا ہے تو ہمیں ہینڈلر کو چلانے کی ضرورت کیوں پڑ سکتی ہے؟ مثال کے طور پر، کیونکہ کچھ ٹوٹ گیا تھا اور تبدیلی ہوئی تھی، لیکن عملدرآمد ہینڈلر تک نہیں پہنچا تھا۔ مثال کے طور پر، کیونکہ نیٹ ورک عارضی طور پر بند تھا۔ کنفیگریشن بدل گئی، لیکن سروس دوبارہ شروع نہیں ہوئی۔ اگلی لانچ پر، کنفیگریشن کو مزید تبدیل نہیں کیا جائے گا، اور سروس کنفیگریشن کے پرانے ورژن کے ساتھ ہی رہتی ہے۔

تشکیل کا مسئلہ ناقابل حل ہے (یا اس کے بجائے، آپ فائل جھنڈوں اور اسی طرح کے ساتھ ایک خصوصی ری اسٹارٹ پروٹوکول ایجاد کرسکتے ہیں، لیکن یہ کسی بھی طرح سے 'بنیادی جوابی' نہیں ہے)۔ لیکن ایک اور عام منظرنامہ ہے: ہم نے ایپلیکیشن انسٹال کی، اسے ریکارڈ کیا، .serviceفائل، اور اب ہم اسے چاہتے ہیں۔ daemon_reload и state=startedاور اس کے لیے قدرتی جگہ ہینڈلر لگتا ہے۔ لیکن اگر آپ اسے ہینڈلر نہیں بلکہ ٹاسک لسٹ یا رول کے آخر میں ایک ٹاسک بناتے ہیں، تو یہ ہر بار غیرمعمولی طور پر کام کرے گا، چاہے پلے بک آدھے راستے میں ہی کریش ہو جائے۔ اس سے دوبارہ شروع ہونے والے مسئلے کو مکمل طور پر حل نہیں کیا جاتا ہے (آپ دوبارہ شروع ہونے والے وصف کے ساتھ کوئی کام نہیں بنا سکتے، کیونکہ اس میں قابلیت ختم ہوجاتی ہے)، لیکن یہ یقینی طور پر سیٹ کرنے کے قابل ہے state=started؛ یہ کنکشن کی تعداد اور متحرک حالت کو کم کرکے پلے بک کے مجموعی استحکام کو بڑھاتا ہے۔

ہینڈلرز کی ایک اور مثبت خاصیت یہ ہے کہ وہ آؤٹ پٹ کو بے ترتیبی نہیں کرتے۔ اگر کوئی تبدیلیاں نہیں ہوئی ہیں، تو آؤٹ پٹ میں کوئی اضافی چھوڑی ہوئی یا ٹھیک قدریں نہیں ہیں، جس سے پڑھنے میں آسانی ہوگی۔ یہ بھی ایک منفی خاصیت ہے: اگر آپ کو پہلی بار ایک لکیری طور پر انجام پانے والے کام میں ٹائپنگ کی غلطی نظر آتی ہے، تو ہینڈلرز کو صرف اس وقت عمل میں لایا جائے گا جب اسے تبدیل کیا جائے، یعنی کچھ شرائط کے تحت - بہت کم۔ مثال کے طور پر، پانچ سالوں میں پہلی بار۔ اور ظاہر ہے کہ نام میں ٹائپنگ ہو گی اور سب کچھ ٹوٹ جائے گا۔ اور وہ دوسری بار نہیں چلیں گے - کوئی تبدیلی نہیں ہے۔

متغیر رسائی پر الگ سے بات کرنے کی ضرورت ہے۔ مثال کے طور پر، اگر آپ کسی کام کو لوپ کے ساتھ مطلع کرتے ہیں، تو متغیرات میں کیا ہوگا؟ آپ اسے تجزیاتی طور پر نکال سکتے ہیں، لیکن یہ ہمیشہ معمولی نہیں ہوتا، خاص طور پر اگر متغیرات مختلف جگہوں سے آئیں۔

…لہٰذا ہینڈلرز اس سے کہیں کم کارآمد اور کہیں زیادہ پریشانی کا شکار ہیں جتنا کہ لگتا ہے۔ اگر آپ ہینڈلرز کے بغیر کچھ خوبصورتی سے (بغیر کسی جھرجھری کے) لکھ سکتے ہیں، تو ان کے بغیر کرنا بہتر ہے۔ اگر یہ خوبصورتی سے نہیں کیا جا سکتا، تو ان کا استعمال کرنا بہتر ہے۔

مستعد قاری بجا طور پر بتاتا ہے کہ ہم نے بحث نہیں کی۔ listen، کہ ایک ہینڈلر دوسرے ہینڈلر کو مطلع کر سکتا ہے، کہ ایک ہینڈلر import_tasks شامل کر سکتا ہے (جس میں شامل_رول کر سکتا ہے with_items)، کہ Ansible میں ہینڈلر سسٹم ٹورنگ مکمل ہے، کہ Include_role کے ہینڈلرز انتہائی دلچسپ انداز میں کھیل سے ہینڈلرز کو آپس میں جوڑتے ہیں، وغیرہ۔ یہ سب واضح طور پر "بنیادی باتیں" نہیں ہے۔

اگرچہ ایک مخصوص WTF ہے، جو دراصل ایک خصوصیت ہے، اور جسے آپ کو ذہن میں رکھنا چاہیے۔ اگر آپ کا کام چل رہا ہے۔ delegate_to اور اس نے مطلع کیا ہے، پھر متعلقہ ہینڈلر کو بغیر پھانسی دی جاتی ہے۔ delegate_to، یعنی میزبان پر جہاں ڈرامہ تفویض کیا گیا ہے۔ (حالانکہ ہینڈلر کے پاس ہو سکتا ہے۔ delegate_to اسی).

میں دوبارہ قابل استعمال کرداروں کے بارے میں بھی کچھ الفاظ کہنا چاہوں گا۔ جمع کرنے سے پہلے، ایک خیال تھا کہ آپ عالمگیر کردار بنا سکتے ہیں جو ہو سکتے ہیں۔ ansible-galaxy install اور یہ جاتا ہے. یہ تمام حالات میں تمام OS ورژن پر کام کرتا ہے۔ تو، میری رائے: یہ کام نہیں کرتا. بڑے پیمانے پر کوئی بھی کردار include_vars, 100500 کیسز کی حمایت کرتے ہوئے، کارنر کیس کے کیڑے کے خاتمے کے لیے برباد ہے۔ ان کو وسیع پیمانے پر جانچ کے ساتھ پلگ کیا جا سکتا ہے، لیکن کسی بھی ٹیسٹنگ کی طرح، یا تو آپ کے پاس ان پٹ ویلیوز کا کارٹیشین پروڈکٹ اور کل فنکشن ہے، یا آپ نے "انفرادی منظرناموں کا احاطہ کیا ہے۔" میری رائے میں، یہ بہت بہتر ہے اگر کردار لکیری ہو (سائیکلومیٹک پیچیدگی 1)۔

کم ifs (واضح یا اعلانیہ - شکل میں when یا فارم include_vars (متغیرات کے ایک سیٹ کے ذریعہ)، کردار اتنا ہی بہتر ہوگا۔ کبھی کبھی آپ کو برانچ کرنا پڑتا ہے، لیکن، میں دہراتا ہوں، کم، بہتر. لہذا، یہ کہکشاں کے ساتھ ایک اچھا کردار لگتا ہے (یہ کام کرتا ہے!) کے ایک گروپ کے ساتھ when آپ کے اپنے پانچ کام کے کردار سے کم ترجیحی ہو سکتی ہے۔ وہ لمحہ جب کہکشاں کا کردار بہتر ہوتا ہے جب آپ کچھ لکھنا شروع کرتے ہیں۔ وہ لمحہ جب یہ خراب ہوتا ہے جب کچھ ٹوٹ جاتا ہے، اور آپ کو شبہ ہے کہ یہ Galaxy کے کردار کی وجہ سے ہے۔ آپ اسے کھولتے ہیں، اور اس میں پانچ شامل ہیں، آٹھ کام کی فہرستیں، اور ایک اسٹیک۔ when'اوہ... اور ہمیں اس کا پتہ لگانے کی ضرورت ہے۔ 5 کاموں کے بجائے، ہمیں ایک لکیری فہرست کی ضرورت ہے جس میں توڑنے کے لیے کچھ نہیں ہے۔

مندرجہ ذیل حصوں میں

• انوینٹریز، گروپ متغیرات، host_group_vars پلگ ان، اور hostvars کے بارے میں تھوڑا سا۔ اسپگیٹی سے گورڈین گرہ کیسے باندھیں۔ دائرہ کار اور متغیرات کی ترجیح، جوابی میموری ماڈل۔ "تو ڈیٹابیس کے لیے صارف کا نام کہاں ذخیرہ کیا جائے؟"
• jinja: {{ jinja }} - nosql notype nosense soft plasticine. یہ ہر جگہ ہے، یہاں تک کہ جہاں آپ کم از کم اس کی توقع کرتے ہیں۔ کے بارے میں تھوڑا سا !!unsafe اور مزیدار یامل.

ماخذ: www.habr.com