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

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

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

نام

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

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

جوابی پلے بک پلے بک کو انجام دیتی ہے۔ پلے بک ایک فائل ہے جس میں 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 اور لائبریری جیسا ہو، اور آپ کو اسے کرنے کا طریقہ تلاش کرنے کی ضرورت ہے۔

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

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

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

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

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

نچوڑ کے لیے نوٹ: کردار یقینی طور پر کنٹرول کے بہاؤ کو متاثر کر سکتا ہے۔ کھاؤ 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. میں یہ کہاں لکھوں؟ پہلے میں؟ پوسٹ ایک کردار بنائیں؟

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

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

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

کاموں اور کرداروں کے ساتھ ان کے حصوں کی ترتیب: pre_tasks, roles, tasks, post_tasks. چونکہ معنوی طور پر پھانسی کا حکم درمیان میں ہے۔ 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، لیکن اگر ہم کھیل میں سیکشنز کے نفاذ کے حکم پر بھروسہ کر سکتے ہیں تو ہمیں فلش_ہینڈلرز کی ضرورت کیوں ہے؟ مزید برآں، meta: flush_handlers کا استعمال ہمیں ڈپلیکیٹ ہینڈلرز کے ساتھ غیر متوقع چیزیں دے سکتا ہے، استعمال ہونے پر ہمیں عجیب انتباہات دے سکتا ہے۔ when у block وغیرہ جتنا بہتر آپ جوابدہ کو جانتے ہیں، اتنی ہی باریکیوں کو آپ "مشکل" حل کے لیے نام دے سکتے ہیں۔ اور ایک آسان حل - پہلے/کردار/پوسٹ کے درمیان قدرتی تقسیم کا استعمال - باریکیوں کا سبب نہیں بنتا۔

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

اب سوال کا جواب "کردار یا ٹاسک" پر آتا ہے جو پہلے سے چل رہا ہے - اگر وہاں کام ہیں، تو آپ کو انہیں کاموں میں شامل کرنے کی ضرورت ہے۔ اگر کردار ہیں، تو آپ کو ایک کردار بنانے کی ضرورت ہے (یہاں تک کہ ایک کام سے بھی)۔ میں آپ کو یاد دلاتا ہوں کہ کام اور کردار ایک ہی وقت میں استعمال نہیں ہوتے ہیں۔

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

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

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

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

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

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

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

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

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

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

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

اس طرح، کرداروں میں دو اہم خصوصیات ہیں: ان میں پہلے سے طے شدہ (ایک منفرد خصوصیت) ہے اور وہ آپ کو اپنے کوڈ کو تشکیل دینے کی اجازت دیتے ہیں۔

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

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

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

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

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

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

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

کردار کے ہینڈلرز rolename/handlers/main.yaml میں واقع ہیں۔ ہینڈلرز تمام پلے شرکاء کے درمیان رمج کرتے ہیں: pre/post_tasks رول ہینڈلرز کو کھینچ سکتے ہیں، اور ایک کردار ہینڈلرز کو ڈرامے سے کھینچ سکتا ہے۔ تاہم، ہینڈلرز کو "کراس رول" کالز ایک معمولی ہینڈلر کو دہرانے سے کہیں زیادہ wtf کا باعث بنتی ہیں۔ (بہترین طریقوں کا ایک اور عنصر ہینڈلر کے ناموں کو نہ دہرانے کی کوشش کرنا ہے)۔

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

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

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

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

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

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

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

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

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

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

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

ماخذ: www.habr.com