زه د نورو خلکو د ځواب وړ کوډ ډیری بیاکتنې کوم او پخپله ډیر څه لیکم. د تیروتنو تحلیل کولو په جریان کې (دواړه د نورو خلکو او زما خپل) ، او همدارنګه یو شمیر مرکو ، ما د اصلي غلطۍ احساس وکړ چې ځواب ورکوونکي کارونکي یې کوي - دوی د لومړنيو مهارتونو پرته پیچلي شیانو ته ځي.

د دې نړیوالې بې عدالتۍ د سمولو لپاره، ما پریکړه وکړه چې د ځواب ورکوونکي لپاره د هغو کسانو لپاره چې دمخه یې پوهیږي یو پیژندنه ولیکئ. زه تاسو ته اخطار ورکوم، دا د انسانانو تکرار نه دی، دا د ډیرو لیکونو او هیڅ عکسونو سره اوږد لوست دی.

د لوستونکي تمه کچه دا ده چې د یملا څو زره کرښې لا دمخه لیکل شوي ، یو څه لا دمخه په تولید کې دي ، مګر "په یو څه ډول هرڅه ګډوډ دي."

نومونه

اصلي تېروتنه چې یو ځواب ورکوونکی کاروونکي کوي دا نه پوهیږي چې څه شی ویل کیږي. که تاسو نومونه نه پیژنئ، تاسو نشئ پوهیدلی چې اسناد څه وايي. یو ژوندی مثال: د مرکې په جریان کې، یو کس چې داسې ښکاري چې هغه په ​​ځواب کې ډیر څه لیکلي دي پوښتنې ته ځواب نه شي کولی "د لوبې کتاب کوم عناصر لري؟" او کله چې ما وړاندیز وکړ چې "د ځواب تمه کیده چې د لوبو کتاب د لوبې څخه جوړ دی،" ناوړه تبصره "موږ دا نه کاروو" تعقیب شو. خلک د پیسو لپاره ځواب ورکوونکي لیکي او لوبې نه کاروي. دوی په حقیقت کې دا کاروي، مګر نه پوهیږي چې دا څه دي.

نو راځئ چې د یو څه ساده سره پیل وکړو: دا څه ته ویل کیږي؟ شاید تاسو پدې پوهیږئ، یا شاید تاسو نه پوهیږئ، ځکه چې تاسو د اسنادو لوستلو ته پام نه و کړی.

د ځواب وړ پلې بوک د پلی بوک اجرا کوي. د لوبو کتاب د 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د محلي لټون پلگ انونه، د شبکې-کلی-ځانګړي ترتیبات، د کود کوربه، او نور. دوی تاسو ته اجازه درکوي یو څه ځای بدل کړئ چیرې چې دندې ترسره کیږي. مګر، د هغې په اړه هېر کړئ. د دې هوښیار انتخابونو څخه هر یو خورا ځانګړي کارونې لري ، او دا یقینا نړیوال ندي. او موږ د اساسي شیانو په اړه خبرې کوو چې هرڅوک باید پوه شي او وکاروي.

که تاسو غواړئ "یو څه" "چیرې" ترسره کړئ، تاسو لوبه ولیکئ. رول نه دی. د ماډلونو او استازو سره رول نلري. تاسو یې واخلئ او لوبه ولیکئ. په کوم کې، د کوربه په ساحه کې تاسو لیست کوئ چیرې چې اجرا کول، او په رولونو/دندو کې - څه باید اجرا شي.

ساده، سمه ده؟ دا څنګه بل ډول کیدی شي؟

یو له ځانګړتیاو شیبو څخه کله چې خلک د لوبې له لارې نه دا ترسره کولو لیوالتیا لري "هغه رول چې هرڅه تنظیموي." زه غواړم داسې رول ولرم چې د لومړي ډول سرورونه او د دوهم ډول سرور دواړه تنظیم کړي.

یو لرغونی بیلګه څارنه ده. زه غواړم د څارنې رول ولرم چې نظارت به تنظیم کړي. د څارنې رول د څارنې کوربه ته ټاکل شوی (د لوبې سره سم). مګر دا معلومه شوه چې د څارنې لپاره موږ اړتیا لرو کوربه ته کڅوړې وړاندې کړو چې موږ یې څارنه کوو. ولې استازي نه کاروئ؟ تاسو د iptables تنظیم کولو ته هم اړتیا لرئ. استازي؟ تاسو اړتیا لرئ د DBMS لپاره د نظارت وړ کولو لپاره یو ترتیب ولیکئ / سم کړئ. استازي! او که خلاقیت کم وي، نو تاسو کولی شئ یو پلاوی جوړ کړئ include_role په نیست شوي لوپ کې د ګروپونو لیست او دننه کې د پیچلي فلټر په کارولو سره include_role تاسو ډیر څه کولی شئ delegate_to بیا او موږ ځو ...

یوه ښه هیله - د نظارت یو واحد رول ولرئ ، کوم چې "هر څه کوي" - موږ بشپړ دوزخ ته رسوي چې ډیری وختونه یوازې یوه لاره شتون لري: له پیل څخه هرڅه بیا لیکل.

دلته کومه تېروتنه شوې؟ هغه شیبه چې تاسو وموندله چې په کوربه X کې د "x" د ترسره کولو لپاره تاسو باید کوربه Y ته لاړ شئ او هلته "y" ترسره کړئ، تاسو باید یو ساده تمرین ترسره کړئ: لاړ شئ او لوبه ولیکئ، کوم چې په کوربه Y ترسره کوي. په "x" کې یو څه مه اضافه کړئ، مګر له پیل څخه یې ولیکئ. حتی د هارډ کوډ شوي متغیرونو سره.

داسې ښکاري چې په پورته پراګرافونو کې هرڅه سم ویل شوي. مګر دا ستاسو قضیه نه ده! ځکه چې تاسو غواړئ د بیا کارونې وړ کوډ ولیکئ چې DRY او د کتابتون په څیر وي، او تاسو اړتیا لرئ چې د دې کولو څرنګوالي په اړه یو میتود وګورئ.

دا هغه ځای دی چې بله جدي تېروتنه پټه ده. یوه تېروتنه چې ډیری پروژې یې د زغم لیکلو څخه بدلې کړې (دا غوره کیدی شي ، مګر هرڅه کار کوي او پای ته رسیدل یې اسانه دي) په بشپړ وحشت کې چې حتی لیکوال یې نشي پیژندلی. دا کار کوي، مګر خدای مه کړه تاسو هیڅ شی بدل نه کړئ.

تېروتنه دا ده: رول د کتابتون فعالیت دی. دې مشابهت دومره ښه پیلونه خراب کړي چې لیدل یې یوازې غمجن دي. رول د کتابتون فعالیت نه دی. هغه نشي کولی محاسبه وکړي او نشي کولی د لوبې کچې پریکړې وکړي. ما ته یادونه وکړه چې لوبې کومې پریکړې کوي؟

مننه، تاسو سمه یاست. لوبه پریکړه کوي (په دقیق ډول، دا معلومات لري) پدې اړه چې کوم دندې او رولونه په کوم کوربه کې ترسره کیږي.

که تاسو دا پریکړه یو رول ته واستوئ ، او حتی د محاسبې سره ، تاسو خپل ځان (او هغه څوک چې ستاسو کوډ پارس کولو هڅه به کوي) بدبخت وجود ته واړوئ. رول پریکړه نه کوي چې چیرته ترسره کیږي. دا پریکړه د لوبې لخوا ترسره کیږي. رول هغه څه کوي چې ورته ویل شوي ، چیرې چې ورته ویل شوي.

ولې په ځواب کې برنامه کول خطرناک دي او ولې COBOL د انسیبل څخه غوره دی موږ به په فصل کې د متغیرونو او جنجا په اړه وغږیږو. د اوس لپاره، راځئ چې یو شی ووایو - ستاسو هره محاسبه په نړیوالو متغیرونو کې د بدلونونو نه هیریدونکې نښې پریږدي، او تاسو د دې په اړه هیڅ نه شئ کولی. هرڅومره ژر چې دوه "نښې" سره یو ځای شي ، هرڅه ورک شوي.

د 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. ځکه چې په اصطلاح کې د اعدام حکم تر منځ دی 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, مګر موږ ولې فلش_handlers ته اړتیا لرو که چیرې موږ په لوبو کې د برخو د اجرا کولو په ترتیب تکیه وکړو؟ سربیره پردې ، د میټا کارول: فلش_هنډلر کولی شي موږ ته د نقل شوي هینډلرونو سره غیر متوقع شیان راکړي ، کله چې کارول کیږي موږ ته عجیب اخطارونه راکوي when у block etc هرڅومره ښه چې تاسو په ځواب کې پوه شئ ، هومره نور لنډیزونه چې تاسو یې د "پیچلي" حل لپاره نومولی شئ. او یو ساده حل - د مخکې / رول / پوسټ تر مینځ طبیعي ویش کارول - د باریکیو لامل نه کیږي.

او، بیرته زموږ 'foo' ته. زه باید چیرته واچوم؟ مخکې، پوسټ یا رول کې؟ په ښکاره ډول، دا پدې پورې اړه لري چې ایا موږ د foo لپاره د سمبالونکي پایلو ته اړتیا لرو. که دوی هلته نه وي، نو foo ته اړتیا نشته چې په مخکې یا پوسټ کې ځای په ځای شي - دا برخې ځانګړې معنی لري - د کوډ اصلي بدن څخه مخکې او وروسته د دندو اجرا کول.

اوس د پوښتنې ځواب "رول یا دنده" هغه څه ته راځي چې دمخه په لوبو کې دي - که چیرې دندې شتون ولري ، نو تاسو اړتیا لرئ دا په دندو کې اضافه کړئ. که چیرې رول شتون ولري، تاسو اړتیا لرئ یو رول جوړ کړئ (حتی د یوې دندې څخه). اجازه راکړئ تاسو ته یادونه وکړم چې دندې او رولونه په ورته وخت کې نه کارول کیږي.

د ځواب ویلو اساساتو پوهیدل د خوند پوښتنو ته مناسب ځوابونه وړاندې کوي.

دندې او دندې (دوهمه برخه)

اوس راځئ چې د وضعیت په اړه بحث وکړو کله چې تاسو یوازې د لوبې کتاب لیکل پیل کوئ. تاسو اړتیا لرئ چې فو، بار او باز جوړ کړئ. ایا دا درې دندې دي، یو رول یا درې رولونه؟ د پوښتنې لنډیز لپاره: تاسو باید په کوم ځای کې د رول لیکلو پیل وکړئ؟ کله چې تاسو دندې لیکلی شئ د رول لیکلو معنی څه ده؟... رول څه شی دی؟

یوه لویه تیروتنه (ما دمخه پدې اړه خبرې کړې) دا فکر کول دي چې رول د برنامې کتابتون کې د فعالیت په څیر دی. د عمومي فعالیت توضیحات څه ډول ښکاري؟ دا د ننوتلو دلیلونه مني، د اړخیزو لاملونو سره تعامل کوي، اړخیزې اغیزې کوي، او ارزښت بیرته راولي.

اوس، پاملرنه. په رول کې له دې څخه څه کیدی شي؟ تاسو تل د جانبي عوارضو غږولو ته ښه راغلاست وایاست، دا د ټول ځواب جوهر دی - د جانبي عوارضو رامنځته کول. د غاړې لاملونه لري؟ ابتدايي. مګر د "یو ارزښت تیر کړئ او بیرته یې ورکړئ" سره - دا هغه ځای دی چې دا کار نه کوي. لومړی، تاسو نشئ کولی رول ته ارزښت انتقال کړئ. تاسو کولی شئ د رول لپاره د vars برخه کې د لوبې د ژوند اندازې سره نړیوال متغیر تنظیم کړئ. تاسو کولی شئ د رول دننه لوبې کولو سره یو نړیوال متغیر تنظیم کړئ. یا حتی د لوبو کتابونو ژوند سره (set_fact/register). مګر تاسو نشئ کولی "ځایی تغیرات" ولرئ. تاسو نشئ کولی "یو ارزښت واخلئ" او "بیا یې کړئ".

اصلي شی له دې څخه تعقیب کیږي: تاسو نشئ کولی په ځواب کې یو څه ولیکئ پرته لدې چې د اړخیزو تاثیراتو لامل شي. د نړیوالو متغیرونو بدلول تل د فعالیت لپاره یو اړخیزه اغیزه ده. په زنګ کې، د بیلګې په توګه، د نړیوال متغیر بدلول دي unsafe. او په ځواب کې دا یوازینی میتود دی چې د رول لپاره ارزښتونه اغیزه کوي. کارول شوي ټکي په پام کې ونیسئ: نه "رول ته ارزښت ورکړئ"، مګر "هغه ارزښتونه بدل کړئ چې رول یې کاروي". د رول تر منځ هیڅ انزوا نشته. د دندو او رول تر منځ هیڅ انزوا نشته.

ټول: رول یو فعالیت نه دی.

د رول په اړه څه ښه دي؟ لومړی، رول ډیفالټ ارزښتونه لري (/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)، او سمبالونکی - د دولت د بدلون له مخې (یوازې د اور په اړه خبر ورکړئ که دا بدل شوی وي). دا څه مانا لري؟ د مثال په توګه، دا حقیقت چې کله تاسو بیا پیل کړئ، که چیرې هیڅ بدلون نه وي، نو بیا به هیڅ سمبالونکی نه وي. ولې دا ممکن وي چې موږ د هینډلر اجرا کولو ته اړتیا لرو کله چې د تولید په دنده کې هیڅ بدلون نه و؟ د مثال په توګه، ځکه چې یو څه مات شوی او بدل شوی، مګر اعدام د سمبالونکي ته ندی رسیدلی. د مثال په توګه، ځکه چې شبکه په موقتي توګه ښکته وه. تشکیل بدل شوی، خدمت بیا پیل شوی نه دی. بل ځل چې تاسو یې پیل کړئ، تشکیل نور نه بدلیږي، او خدمت د پخوانیو نسخو سره پاتې کیږي.

د تشکیل سره وضعیت نشي حل کیدی (په دقیق ډول ، تاسو کولی شئ د ځان لپاره د فایل بیرغونو سره د ځانګړي بیا پیل پروتوکول اختراع کړئ ، او داسې نور ، مګر دا نور په هیڅ ډول 'بنسټیز ځواب' نه دی). مګر یو بل عام کیسه شتون لري: موږ غوښتنلیک نصب کړ، ثبت یې کړ .service- فایل، او اوس موږ دا غواړو daemon_reload и state=started. او د دې لپاره طبیعي ځای داسې ښکاري چې سمبالونکی وي. مګر که تاسو دا یو سمبالونکی نه بلکه د ټاسک لیست یا رول په پای کې دنده وګرځوئ ، نو دا به هر وخت په کلکه سره اجرا شي. حتی که د لوبو کتاب په مینځ کې مات شو. دا په بشپړ ډول د بیا پیل شوې ستونزه حل نه کوي (تاسو نشئ کولی د بیا پیل شوي خاصیت سره یو کار ترسره کړئ، ځکه چې د پام وړ وړتیا له لاسه ورکړې ده)، مګر دا یقینا د دې ارزښت لري چې حالت = پیل شوی، د پلی بوکس عمومي ثبات زیاتیږي، ځکه چې د اړیکو شمیر او متحرک حالت کمیږي.

د هینډلر بل مثبت ملکیت دا دی چې دا محصول نه بندوي. هیڅ بدلون نه و - په محصول کې هیڅ اضافي پریښودل یا سم ندي - لوستل اسانه دي. دا یو منفي ملکیت هم دی - که تاسو په لومړي سر کې په خطي ډول اجرا شوي دنده کې ټایپ ومومئ ، نو بیا سمبالونکي به یوازې هغه وخت اجرا شي کله چې بدل شي ، د بیلګې په توګه. په ځینو شرایطو کې - ډیر لږ. د مثال په توګه، پنځه کاله وروسته زما په ژوند کې د لومړي ځل لپاره. او البته، په نوم کې به ټایپ وي او هرڅه به مات شي. او که تاسو دوی دوهم ځل ونه چلوئ، هیڅ بدلون نشته.

په جلا توګه، موږ باید د متغیرونو شتون په اړه وغږیږو. د مثال په توګه، که تاسو یو کار د لوپ سره خبر کړئ، په متغیرونو کې به څه وي؟ تاسو کولی شئ په تحلیلي توګه اټکل وکړئ، مګر دا تل کوچني نه وي، په ځانګړې توګه که چیرې متغیرات د مختلفو ځایونو څخه راشي.

... نو سمبالونکي خورا لږ ګټور دي او د دوی په پرتله خورا ستونزمن دي. که تاسو کولی شئ یو څه په ښکلي ډول ولیکئ (پرته له فلز پرته) ، نو دا به غوره وي چې دا له دوی پرته ترسره کړئ. که دا په ښه توګه کار ونکړي، دا د دوی سره ښه دی.

کره کتونکی سمه په ګوته کوي چې موږ بحث نه دی کړی listenدا چې یو هینډلر کولی شي بل هینډلر ته خبر ورکړي، چې یو هینډلر کولی شي import_tasks شامل کړي (کوم چې کولی شي په کې شامل_رول with_items وکړي)، دا چې په ځواب کې د هینډلر سیسټم تورینګ بشپړ دی، چې د Include_role څخه هینډلرونه د لوبې څخه د هینډلرانو سره په زړه پورې طریقه سره یو ځای کوي، etc.d. - دا ټول په ښکاره ډول "اساسي" ندي).

که څه هم یو ځانګړی WTF شتون لري چې په حقیقت کې یو ځانګړتیا ده چې تاسو باید په ذهن کې وساتئ. که ستاسو دنده اجرا شي delegate_to او دا خبرتیا ورکوي، نو د اړونده سمبالونکي پرته اعدام کیږي delegate_to, i.e. په کوربه کې چیرې چې لوبه ټاکل شوې. (که څه هم سمبالونکی، البته، ممکن ولري delegate_to ورته).

په جلا توګه، زه غواړم د بیا کارونې وړ رولونو په اړه یو څو ټکي ووایم. مخکې له دې چې راټولونه ښکاره شي، داسې نظر شتون درلود چې تاسو کولی شئ نړیوال رولونه جوړ کړئ چې کیدی شي ansible-galaxy install او لاړ. په ټولو حالتونو کې د ټولو ډولونو په ټولو OS کې کار کوي. نو، زما نظر: دا کار نه کوي. د ډله ایزو سره هر ډول رول include_vars, د 100500 قضیو ملاتړ کوي، د کونج کیس بګونو ته زیان رسوي. دوی د لوی ازموینې سره پوښل کیدی شي ، مګر لکه څنګه چې د هرې ازموینې سره ، یا تاسو د ان پټ ارزښتونو کارټیسین محصول او ټول فعالیت لرئ ، یا تاسو "انفرادي سناریوګانې پوښلي" لرئ. زما نظر دا دی چې دا خورا ښه دی که چیرې رول خطي وي (سایکلومیټ پیچلتیا 1).

لږ ifs (ښکاره یا اعالمیه - په شکل کې when یا بڼه include_vars د متغیرونو د سیټ په واسطه)، رول ښه دی. ځینې ​​​​وختونه تاسو باید څانګې جوړې کړئ، مګر، زه تکراروم، چې لږ څه شتون لري، ښه. نو داسې ښکاري چې د ګیلیکسي سره یو ښه رول (دا کار کوي!) د یوې ډلې سره when کیدای شي د پنځو دندو څخه د "خپل" رول څخه لږ غوره وي. هغه شیبه چې د ګیلیکسي رول غوره وي کله چې تاسو یو څه لیکل پیل کړئ. هغه شیبه کله چې دا خرابیږي کله چې یو څه مات شي او تاسو شک لرئ چې دا د "د کهکشان سره د رول" له امله دی. تاسو یې پرانیزئ، او پنځه شمولیتونه، اته کاري پاڼې او یو سټیک شتون لري whenاو موږ باید دا معلومه کړو. د 5 دندو پرځای، یو خطي لیست چې په کې د ماتولو لپاره هیڅ شی شتون نلري.

په لاندې برخو کې

• د لیست په اړه لږ څه، د ګروپ متغیرونه، host_group_vars پلگ ان، hostvars. څنګه د سپتیټي سره د ګورډین غوټۍ وتړئ. ساحه او لومړیتوب متغیرونه، د ځواب وړ حافظې ماډل. "نو موږ د ډیټابیس لپاره د کارن نوم چیرته ذخیره کوو؟"
• jinja: {{ jinja }} - nosql نوټیپ نوسینس نرم پلاستیک. دا هر ځای دی، حتی چیرې چې تاسو یې تمه نه لرئ. په اړه لږ څه !!unsafe او خوندور یامل.

سرچینه: www.habr.com