مان ٻين ماڻهن جي جوابي ڪوڊ جا ڪيترائي جائزو وٺندو آهيان ۽ پاڻ گهڻو ڪجهه لکندو آهيان. غلطين جي تجزيي جي دوران (ٻنهي ٻين ماڻهن جي ۽ منهنجي پنهنجي)، ۽ گڏوگڏ ڪيترن ئي انٽرويوز، مون کي بنيادي غلطي جو احساس ٿيو ته جواب ڏيڻ وارا صارف ڪندا آهن - اهي بنيادي مسئلن تي مهارت حاصل ڪرڻ کان سواء پيچيده شين ۾ پئجي ويندا آهن.

هن آفاقي ناانصافي کي درست ڪرڻ لاء، مون فيصلو ڪيو ته جواب ڏيڻ لاء هڪ تعارف لکڻ لاء انهن لاء جيڪي اڳ ۾ ئي ڄاڻن ٿا. مان توهان کي ڊيڄاريان ٿو، هي انسانن کي ٻيهر ٻڌائڻ وارو نه آهي، هي تمام گهڻو خطن ۽ تصويرن سان گڏ ڊگهو آهي.

پڙهندڙ جي متوقع سطح اها آهي ته ياملا جون هزارين لائينون اڳ ۾ ئي لکيون ويون آهن، ڪجهه اڳ ۾ ئي پيداوار ۾ آهي، پر "ڪنهن نه ڪنهن طرح سڀ ڪجهه ٽڙيل آهي."

نالا

بنيادي غلطي هڪ جوابي صارف ڪري ٿو اهو نه ڄاڻڻ آهي ته ڪنهن شيءِ کي ڇا چئبو آهي. جيڪڏھن توھان نالن کي نٿا ڄاڻو، توھان سمجھي نٿا سگھو ته دستاويز ڇا ٿو چوي. هڪ زنده مثال: هڪ انٽرويو دوران، هڪ شخص جيڪو اهو چوڻ لڳي ٿو ته هن جواب ۾ گهڻو ڪجهه لکيو آهي، اهو سوال جو جواب نه ڏئي سگهيو آهي ته "پلي بڪ ڪهڙي عناصر تي مشتمل آهي؟" ۽ جڏهن مون تجويز ڪيو ته "جواب جي توقع ڪئي وئي ته راند جو ڪتاب راند تي مشتمل آهي،" تبصرو تبصرو "اسان اهو استعمال نٿا ڪريون" پٺيان. ماڻهو لکندا جوابي پئسن لاءِ ۽ راند کي استعمال نٿا ڪن. اهي اصل ۾ استعمال ڪندا آهن، پر نه ڄاڻندا آهن ته اهو ڇا آهي.

سو اچو ته ڪجھ سادو سان شروع ڪريون: ان کي ڇا چئبو آهي. ٿي سگهي ٿو توهان کي اها خبر هجي، يا شايد توهان نه ٿا ڄاڻو، ڇو ته توهان ڌيان نه ڏنو جڏهن توهان دستاويز پڙهي رهيا آهيو.

جوابي-پلے بڪ پلي بڪ تي عمل ڪري ٿو. هڪ پلے بڪ yml/yaml ايڪسٽينشن سان هڪ فائيل آهي، جنهن جي اندر ڪجهه هن طرح آهي:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

اسان اڳ ۾ ئي محسوس ڪيو ته هي سڄو فائل هڪ پلے بڪ آهي. اسان ڏيکاريون ٿا ته ڪردار ڪٿي آهن ۽ ڪم ڪٿي آهن. پر راند ڪٿي آهي؟ ۽ راند ۽ ڪردار يا راند جي ڪتاب ۾ ڇا فرق آهي؟

اهو سڀ دستاويز ۾ آهي. ۽ اھي ان کي ياد ڪندا آھن. شروعات ڪندڙ - ڇاڪاڻ ته اتي تمام گهڻو آهي ۽ توهان کي هڪ ڀيرو هر شيء ياد نه ايندي. تجربا - ڇاڪاڻ ته "ننڍو شيون". جيڪڏھن توھان تجربيڪار آھيو، انھن صفحن کي پڙھو گھٽ ۾ گھٽ ھر ڇھن مھينن ۾، ۽ توھان جو ڪوڊ ڪلاس-ليڊنگ بڻجي ويندو.

تنهن ڪري، ياد رکو: Playbook هڪ فهرست آهي جنهن ۾ راند ۽ import_playbook.
هي هڪ راند آهي:

- hosts: group1
  roles:
    - role1

۽ هي پڻ هڪ ٻيو راند آهي:

- hosts: group2,group3
  tasks:
    - debug:

راند ڇا آهي؟ هوءَ ڇو آهي؟

راند هڪ پلے بڪ لاءِ هڪ اهم عنصر آهي، ڇاڪاڻ ته راند ۽ صرف راند ڪردارن ۽/يا ڪمن جي هڪ فهرست کي ميزبانن جي فهرست سان جوڙي ٿو جنهن تي انهن کي عمل ۾ آڻڻ لازمي آهي. دستاويز جي اونهي کوٽائي ۾ توهان جو ذڪر ڳولي سگهو ٿا delegate_to, local lookup plugins, network-cli-specific settings, jump hosts, etc. اهي توهان کي ٿوري جاء تبديل ڪرڻ جي اجازت ڏين ٿا جتي ڪم ڪيا ويا آهن. پر، ان جي باري ۾ وساريو. انهن مان هر هڪ هوشيار اختيارن ۾ تمام خاص استعمال آهن، ۽ اهي يقيني طور تي آفاقي نه آهن. ۽ اسان بنيادي شين بابت ڳالهائي رهيا آهيون جيڪي هرڪو ڄاڻڻ ۽ استعمال ڪرڻ گهرجي.

جيڪڏهن توهان "ڪجهه" "ڪجهه" انجام ڏيڻ چاهيو ٿا، توهان راند لکندا آهيو. ڪردار ناهي. ماڊلز ۽ نمائندن سان ڪو ڪردار ناهي. توهان ان کي وٺو ۽ راند لکو. جنهن ۾، ميزبان جي فيلڊ ۾ توهان فهرست ڏيو ٿا جتي عمل ڪرڻو آهي، ۽ ڪردار/ٽاسڪ ۾ - ڇا عمل ڪرڻو آهي.

سادو، صحيح؟ اها ٻي صورت ۾ ڪيئن ٿي سگهي ٿي؟

هڪ خاص لمحن مان جڏهن ماڻهن کي اها خواهش هوندي آهي ته اهو راند ذريعي نه ڪيو وڃي ”ڪردار جيڪو هر شي کي ترتيب ڏئي ٿو“. مان هڪ ڪردار ادا ڪرڻ چاهيان ٿو جيڪو ٻنهي سرورن کي ترتيب ڏئي پهرين قسم جا سرور ۽ ٻئي قسم جا سرور.

هڪ آثار قديمه مثال مانيٽرنگ آهي. مان چاهيان ٿو مانيٽرنگ جو ڪردار جيڪو مانيٽرنگ کي ترتيب ڏيندو. نگراني جو ڪردار نگراني ميزبانن کي لڳايو ويو آهي (راند جي مطابق). پر اهو ظاهر ٿئي ٿو ته مانيٽرنگ لاءِ اسان کي ضرورت آهي ته پيڪيجز انهن ميزبانن کي پهچائڻا آهن جن جي اسان نگراني ڪري رهيا آهيون. ڇو نه نمائندو استعمال ڪريو؟ توھان کي پڻ iptables ترتيب ڏيڻ جي ضرورت آھي. نمائندو؟ مانيٽرنگ کي فعال ڪرڻ لاءِ توهان کي DBMS لاءِ هڪ ترتيب لکڻ/صحيح ڪرڻ جي ضرورت آهي. نمائندو! ۽ جيڪڏهن تخليقيت جي کوٽ آهي، ته پوء توهان هڪ وفد ٺاهي سگهو ٿا include_role گروپن جي لسٽ تي، ۽ اندر اندر هڪ نچڻ واري لوپ ۾ هڪ مشڪل فلٽر استعمال ڪندي include_role توهان وڌيڪ ڪري سگهو ٿا delegate_to ٻيهر. ۽ اسان پري وڃون ٿا ...

هڪ سٺي خواهش - هڪ واحد مانيٽرنگ ڪردار هجڻ، جيڪو "سڀ ڪجهه ڪري ٿو" - اسان کي مڪمل دوزخ ڏانهن وٺي ٿو، جتان اڪثر ڪري صرف هڪ ئي رستو آهي: شروع کان هر شي کي ٻيهر لکڻ لاء.

هتي غلطي ڪٿي ٿي؟ جنهن لمحي توهان دريافت ڪيو ته ميزبان X تي "x" ٽاسڪ ڪرڻ لاءِ توهان کي ميزبان Y ڏانهن وڃڻو هو ۽ اتي "y" ڪرڻو هو، توهان کي هڪ سادي مشق ڪرڻي هئي: وڃو ۽ راند لکو، جيڪو ميزبان Y تي ڪري ٿو. "x" ۾ ڪا شيء شامل نه ڪريو، پر ان کي شروع کان لکو. جيتوڻيڪ هارڊ ڪوڊ ٿيل متغيرن سان.

اهو لڳي ٿو ته مٿين پيراگراف ۾ سڀ ڪجهه صحيح طور تي چيو ويو آهي. پر اهو توهان جو معاملو ناهي! ڇاڪاڻ ته توهان ٻيهر استعمال لائق ڪوڊ لکڻ چاهيو ٿا جيڪو DRY ۽ لائبريري جهڙو آهي، ۽ توهان کي اهو ڪرڻو پوندو ته اهو ڪيئن ڪجي.

هتي هڪ ٻي سنگين غلطي آهي. هڪ غلطي جنهن ڪيترن ئي منصوبن کي تحمل سان لکڻ کان بدلائي ڇڏيو (اهو بهتر ٿي سگهي ٿو، پر هر شي ڪم ڪري ٿي ۽ ختم ڪرڻ آسان آهي) هڪ مڪمل خوفناڪ ٿي سگهي ٿو جيڪو ليکڪ به نه سمجهي سگهي. اهو ڪم ڪري ٿو، پر خدا توهان کي ڪجهه به تبديل ڪرڻ کان منع ڪري ٿو.

غلطي آهي: ڪردار هڪ لائبريري فنڪشن آهي. هن قياس تمام گهڻيون سٺيون شروعاتون برباد ڪري ڇڏيون آهن ته اهو ڏسڻ لاءِ اداس آهي. ڪردار هڪ لائبريري فنڪشن نه آهي. هوءَ حساب ڪتاب نٿي ڪري سگهي ۽ نه ئي راند جي سطح جا فيصلا ڪري سگهي ٿي. مون کي ياد ڏياريو ته ڪهڙو فيصلو راند ڪندو آهي؟

مهرباني، توهان صحيح آهيو. راند هڪ فيصلو ڪري ٿو (وڌيڪ واضح طور تي، ان ۾ معلومات شامل آهي) بابت ڪهڙن ڪمن ۽ ڪردارن کي انجام ڏيڻ جي ميزباني تي.

جيڪڏهن توهان هن فيصلي کي هڪ ڪردار ڏانهن نمائندو ڪيو، ۽ حتي حساب سان، توهان پنهنجو پاڻ کي برباد ڪيو (۽ جيڪو توهان جي ڪوڊ کي پارس ڪرڻ جي ڪوشش ڪندو) هڪ بدحالي وجود ڏانهن. ڪردار اهو فيصلو نٿو ڪري ته اهو ڪٿي انجام ڏنو وڃي. اهو فيصلو راند ذريعي ڪيو ويو آهي. ڪردار اهو ئي ڪندو آهي جيڪو ان کي ٻڌايو ويو آهي، جتي اهو ٻڌايو ويو آهي.

جوابي پروگرام ۾ پروگرام ڪرڻ خطرناڪ ڇو آهي ۽ ڪوبول جوابي کان بهتر ڇو آهي، اسان هن باب ۾ متغير ۽ جنجا بابت ڳالهائينداسين. هن وقت لاءِ، اچو ته هڪ ڳالهه ٻڌايان - توهان جي هر حساب جي پويان عالمي متغيرن ۾ تبديلين جو اڻ کٽ نشان ڇڏي ٿو، ۽ توهان ان بابت ڪجهه به نٿا ڪري سگهو. جيئن ئي ٻه ”نشانيون“ هڪ ٻئي سان ٽڪرائجي ويون ته سڀ ڪجهه ختم ٿي ويو.

squeamish لاء نوٽ: ڪردار ضرور ڪنٽرول وهڪري تي اثر انداز ڪري سگهي ٿو. کائو delegate_to ۽ ان جا معقول استعمال آهن. کائو meta: end host/play. پر! ياد رکو ته اسان بنياديات سيکاريندا آهيون؟ جي باري ۾ وساريو delegate_to. اسان سڀ کان آسان ۽ سڀ کان وڌيڪ خوبصورت جوابي ڪوڊ بابت ڳالهائي رهيا آهيون. جيڪو پڙهڻ ۾ آسان، لکڻ ۾ آسان، ڊيبگ ڪرڻ ۾ آسان، ٽيسٽ ڪرڻ ۾ آسان ۽ مڪمل ڪرڻ ۾ آسان آهي. تنهن ڪري، هڪ ڀيرو ٻيهر:

راند ۽ صرف راند اهو فيصلو ڪري ٿو ته ڪهڙن ميزبانن تي عمل ڪيو وڃي.

هن حصي ۾، اسان راند ۽ ڪردار جي وچ ۾ مخالفت سان ڳالهايو. هاڻي اچو ته ڪم ۽ ڪردار جي رشتي بابت ڳالهايون.

ڪم ۽ ڪردار

راند تي غور ڪريو:

- 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. ڇاڪاڻ ته 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 جيڪڏهن اسان راند ۾ حصن جي عمل جي حڪم تي ڀروسو ڪري سگهون ٿا؟ ان کان علاوه، ميٽا جو استعمال: flush_handlers اسان کي اڻڄاتل شيون ڏئي سگھن ٿا نقلي هٿيارن سان، اسان کي عجيب ڊيڄاريندڙ ڏيو جڏهن استعمال ڪيو وڃي when у block وغيره بهتر توهان ڄاڻو ٿا جوابي، وڌيڪ nuances توهان هڪ "مشڪل" حل لاء نالو ڪري سگهو ٿا. ۽ هڪ سادي حل - اڳ / ڪردار / پوسٽ جي وچ ۾ قدرتي تقسيم استعمال ڪندي - nuances سبب نه ٿو ڪري.

۽، اسان جي 'foo' ڏانهن واپس. مون کي ان کي ڪٿي رکڻ گهرجي؟ اڳ ۾، پوسٽ يا ڪردار ۾؟ ظاهر آهي، اهو ان تي منحصر آهي ته ڇا اسان کي گهربل نتيجن جي ضرورت آهي foo لاءِ. جيڪڏهن اهي نه آهن، ته پوءِ foo کي اڳي يا پوسٽ ۾ رکڻ جي ضرورت ناهي - انهن حصن جي هڪ خاص معنيٰ آهي - ڪوڊ جي بنيادي حصي کان اڳ ۽ بعد ۾ ڪمن تي عمل ڪرڻ.

ھاڻي سوال جو جواب "ڪردار يا ڪم" ھيٺ اچي ٿو جيڪو اڳ ۾ ئي راند ۾ آھي - جيڪڏھن اتي ڪم آھن، پوء توھان انھن کي ڪمن ۾ شامل ڪرڻ جي ضرورت آھي. جيڪڏهن ڪردار آهن، توهان کي هڪ ڪردار ٺاهڻ جي ضرورت آهي (هڪ ڪم کان به). مون کي توهان کي ياد ڏيارڻ ڏيو ته ڪم ۽ ڪردار هڪ ئي وقت ۾ استعمال نه ٿيندا آهن.

جوابن جي بنيادي ڳالهين کي سمجھڻ سان ذوق جي بظاهر سوالن جا معقول جواب ملي ٿي.

ڪم ۽ ڪردار (حصو ٻيو)

هاڻي اچو ته ان صورتحال تي بحث ڪريون جڏهن توهان صرف هڪ راند ڪتاب لکڻ شروع ڪري رهيا آهيو. توهان کي فو، بار ۽ باز ٺاهڻ جي ضرورت آهي. اهي ٽي ڪم آهن، هڪ ڪردار يا ٽي ڪردار؟ سوال کي اختصار ڪرڻ لاءِ: توهان کي ڪهڙي نقطي تي ڪردار لکڻ شروع ڪرڻ گهرجي؟ ڪردار لکڻ جو ڪهڙو مقصد آهي جڏهن توهان ڪم لکي سگهو ٿا؟... ڪردار ڇا آهي؟

هڪ وڏي غلطي (مان اڳ ۾ ئي هن بابت ڳالهايو آهي) اهو سوچڻ آهي ته هڪ ڪردار پروگرام جي لائبريري ۾ هڪ فنڪشن وانگر آهي. عام فنڪشن جي وضاحت ڇا نظر اچي ٿي؟ اهو ان پٽ دليلن کي قبول ڪري ٿو، ضمني سببن سان لهه وچڙ ڪري ٿو، ضمني اثرات ڪري ٿو، ۽ قيمت واپس ڪري ٿو.

هاڻي، ڌيان. هن ڪردار ۾ ڇا ڪري سگهجي ٿو؟ توھان کي ھميشه ڀليڪار چئجي ٿو پاسي اثرات کي سڏڻ لاءِ، ھي آھي پوري جوابي جو خلاصو - پاسي اثرات پيدا ڪرڻ لاءِ. پاسي جا سبب آهن؟ ابتدائي. پر "هڪ قدر پاس ڪريو ۽ ان کي واپس ڪريو" سان - اهو آهي جتي اهو ڪم نٿو ڪري. پهرين، توهان هڪ ڪردار کي قدر نه ٿا ڪري سگهو. توهان ڪردار لاءِ vars سيڪشن ۾ راند جي زندگيءَ جي ماپ سان عالمي متغير سيٽ ڪري سگهو ٿا. توهان هڪ عالمي متغير مقرر ڪري سگهو ٿا زندگي گذارڻ سان گڏ ڪردار جي اندر. يا اڃا تائين راند جي ڪتابن جي زندگي سان (set_fact/register). پر توهان وٽ "مقامي متغير" نه هوندا. توهان نٿا ڪري سگهو "هڪ قدر وٺو" ۽ "ان کي واپس".

مکيه شيء هن مان هن ريت آهي: توهان ضمني اثرات جي سبب بغير جوابي ۾ ڪجهه لکي نٿا سگهو. عالمي متغير کي تبديل ڪرڻ هميشه هڪ فنڪشن لاء هڪ طرفي اثر آهي. Rust ۾، مثال طور، هڪ عالمي متغير تبديل ڪرڻ آهي unsafe. ۽ جواب ۾ اهو واحد طريقو آهي جيڪو ڪردار لاءِ قدرن کي متاثر ڪري ٿو. استعمال ٿيل لفظن کي نوٽ ڪريو: "ڪردار جي قدر کي پاس ڪريو"، پر "اھي قدر تبديل ڪريو جيڪي ڪردار استعمال ڪن ٿا". ڪردارن جي وچ ۾ ڪابه اڪيلائي ناهي. ڪم ۽ ڪردار جي وچ ۾ ڪو به اڪيلائي نه آهي.

Total: ڪردار هڪ فنڪشن نه آهي.

ڪردار بابت ڇا سٺو آهي؟ پهريون، ڪردار ۾ ڊفالٽ قدر آهن (/default/main.yaml)، ٻيو، ڪردار ۾ فائلن کي محفوظ ڪرڻ لاء اضافي ڊائريڪٽريون آهن.

ڊفالٽ ويلز جا ڪهڙا فائدا آهن؟ ڇاڪاڻ ته مسلو جي پرامڊ ۾، جوابي جي بدران بدليل جدول متغير ترجيحن جي، ڪردار ڊفالٽ سڀ کان گهٽ ترجيح آهن (مائنس جوابي ڪمان لائن پيٽرولر). هن جو مطلب اهو آهي ته جيڪڏهن توهان کي ڊفالٽ قدر مهيا ڪرڻ جي ضرورت آهي ۽ انهن جي باري ۾ پريشان نه ڪريو قدرن کي انوینٽري يا گروپ متغيرن کان مٿانهون ڪرڻ جي، پوء ڪردار ڊفالٽ صرف توهان لاء صحيح جڳهه آهن. (مان ٿورڙو ڪوڙ ڳالهائي رهيو آهيان - اتي وڌيڪ آهن |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. ۽ هن لاءِ قدرتي جڳهه هينڊلر لڳي ٿي. پر جيڪڏهن توهان ان کي هينڊلر نه پر هڪ ٽاسڪ لسٽ يا ڪردار جي آخر ۾ هڪ ٽاسڪ ٺاهيو، ته پوءِ اهو هر دفعي غيرمعمولي طور تي عمل ڪيو ويندو. جيتوڻيڪ راند جو ڪتاب وچ ۾ ڀڄي ويو. اهو ٻيهر شروع ٿيل مسئلو حل نٿو ڪري (توهان ٻيهر شروع ٿيل وصف سان ڪم نه ٿا ڪري سگهو، ڇاڪاڻ ته idempotency گم ٿي وئي آهي)، پر اهو ضرور ڪرڻ جي قابل آهي state = started، playbooks جي مجموعي استحڪام وڌي ٿي، ڇاڪاڻ ته ڪنيڪشن جو تعداد ۽ متحرڪ حالت گھٽجي ٿي.

هينڊلر جي هڪ ٻي مثبت ملڪيت اها آهي ته اهو ان پٽ کي بند نٿو ڪري. ڪا به تبديلي نه هئي - ڪو به اضافي نه ڇڏيو ويو يا اوڪ آئوٽ ۾ - پڙهڻ ۾ آسان. اهو پڻ هڪ ناڪاري ملڪيت آهي - جيڪڏهن توهان کي پهرين رن تي هڪ لڪير سان جاري ڪيل ڪم ۾ ٽائپو ملي ٿو، ته پوء هينڊلر صرف ان وقت تي عمل ڪيو ويندو جڏهن تبديل ڪيو ويندو، يعني. ڪجهه حالتن هيٺ - تمام گهٽ. مثال طور، منهنجي زندگيء ۾ پهريون ڀيرو پنجن سالن کان پوء. ۽، يقينا، نالي ۾ هڪ ٽائپو ٿيندو ۽ سڀ ڪجهه ڀڄي ويندو. ۽ جيڪڏهن توهان انهن کي ٻيو ڀيرو نه هلائيندا، اتي ڪا به تبديلي ناهي.

الڳ الڳ، اسان کي متغير جي دستيابي بابت ڳالهائڻ جي ضرورت آهي. مثال طور، جيڪڏهن توهان لوپ سان هڪ ڪم کي اطلاع ڏيو ٿا، متغير ۾ ڇا ٿيندو؟ توهان تجزياتي انداز ۾ اندازو لڳائي سگهو ٿا، پر اهو هميشه معمولي ناهي، خاص طور تي جيڪڏهن متغير مختلف هنڌن کان ايندا آهن.

... تنهنڪري هينڊلر تمام گهٽ ڪارائتو آهن ۽ انهن جي ڀيٽ ۾ تمام گهڻو مشڪل آهي. جيڪڏهن توهان هينڊلر کان سواءِ ڪجهه سهڻي نموني لکي سگهو ٿا (بغير بغير)، اهو بهتر آهي ته ان کان سواءِ. جيڪڏهن اهو خوبصورت طور تي ڪم نٿو ڪري، اهو انهن سان بهتر آهي.

مرڪندڙ پڙهندڙ صحيح اشارو ڪري ٿو ته اسان بحث نه ڪيو آهي listenته هڪ هينڊلر ٻئي هينڊلر لاءِ اطلاع ڏئي سگهي ٿو، ته هڪ هينڊلر import_tasks شامل ڪري سگهي ٿو (جيڪو ڪري سگھي ٿو include_role with_items)، ته هينڊلر سسٽم جوابي ۾ Turing-complete آهي، ته هينڊلر Include_role کان هينڊلر هڪ تجسس واري انداز ۾ راند کان هينڊلر سان گڏ ڪن ٿا، وغيره. ڊي. - اهو سڀ ڪجهه واضح طور تي "بنيادي" ناهي).

جيتوڻيڪ اتي ھڪڙو مخصوص WTF آھي جيڪو اصل ۾ ھڪڙي خاصيت آھي جيڪو توھان کي ذهن ۾ رکڻ جي ضرورت آھي. جيڪڏهن توهان جو ڪم مڪمل ڪيو ويو آهي delegate_to ۽ ان کي اطلاع ڏنو آهي، ته پوءِ لاڳاپيل هينڊلر کان سواءِ عمل ڪيو ويندو آهي delegate_to، i.e. ميزبان تي جتي راند مقرر ڪئي وئي آهي. (جيتوڻيڪ سنڀاليندڙ، يقينا، ٿي سگهي ٿو delegate_to ساڳيو).

الڳ الڳ، مان ٻيهر استعمال ٿيندڙ ڪردار جي باري ۾ ڪجهه لفظ چوڻ چاهيان ٿو. مجموعا ظاهر ٿيڻ کان اڳ، اتي هڪ خيال هو ته توهان عالمي ڪردار ٺاهي سگهو ٿا جيڪي ٿي سگهي ٿو ansible-galaxy install ۽ ويو. سڀني حالتن ۾ سڀني قسمن جي سڀني او ايس تي ڪم ڪري ٿو. تنهن ڪري، منهنجي راء: اهو ڪم نٿو ڪري. ماس سان ڪو به ڪردار include_vars, 100500 ڪيسن جي حمايت ڪندي، ڪنڊي ڪيس جي بگن جي ابتڙ کي برباد ڪيو ويو آهي. انهن کي وڏي پيماني تي جاچ ڪري سگهجي ٿو، پر جيئن ڪنهن به جاچ سان، يا ته توهان وٽ آهي ڪارٽسين پراڊڪٽ جو ان پٽ ويلز ۽ ڪل فنڪشن، يا توهان وٽ آهي ”انفرادي منظرنامو ڍڪيل“. منهنجي راءِ آهي ته اهو گهڻو بهتر آهي جيڪڏهن ڪردار لڪير هجي (سائيڪوميٽڪ پيچيدگي 1).

ٿورڙا ifs (واضح يا بيان ڪندڙ - فارم ۾ when يا فارم include_vars متغيرن جي سيٽ جي ذريعي)، بهتر ڪردار. ڪڏهن ڪڏهن توهان کي شاخون ٺاهڻو پوندو، پر، مان ورجائي ٿو، اتي گهٽ آهن، بهتر. تنهنڪري اهو لڳي ٿو ته گليڪس سان گڏ سٺو ڪردار (اهو ڪم ڪري ٿو!) سان گڏ when پنجن ڪمن مان ”پنهنجي“ ڪردار کان گهٽ ترجيح ٿي سگھي ٿو. اهو لمحو جڏهن گليڪس سان ڪردار بهتر آهي جڏهن توهان ڪجهه لکڻ شروع ڪيو. اهو لمحو جڏهن اهو خراب ٿي ويندو آهي جڏهن ڪجهه ڀڃي ٿو ۽ توهان کي شڪ آهي ته اهو "ڪهڪشان سان ڪردار" جي ڪري آهي. توهان ان کي کوليو، ۽ اتي پنج شامل آهن، اٺ ٽاسڪ شيٽ ۽ هڪ اسٽيڪ when'او... ۽ اسان کي اهو سمجهڻ گهرجي. 5 ڪمن جي بدران، هڪ لڪير لسٽ جنهن ۾ ٽوڙڻ لاء ڪجھ به ناهي.

هيٺين حصن ۾

• انوینٽري بابت ٿورو، گروپ متغير، host_group_vars پلگ ان، hostvars. گورڊن ڳٽ کي اسپگيٽي سان ڪيئن ڳنڍجي. دائرو ۽ ترجيح متغير، جوابي ميموري ماڊل. "پوءِ اسان ڊيٽابيس لاءِ يوزرنيم ڪٿي ذخيرو ڪندا آهيون؟"
• jinja: {{ jinja }} - nosql نوٽ ٽائپ نڪسن نرم پلاسٽڪائن. اهو هر جڳهه آهي، جيتوڻيڪ جتي توهان ان جي توقع نه ڪندا آهيو. جي باري ۾ ٿورو !!unsafe ۽ لذيذ يامل.

جو ذريعو: www.habr.com