Мен басқа адамдардың Ansible кодын көп шолу жасаймын және өзім де көп жазамын. Қателерді (басқа адамдардың да, өзімдікі де), сондай-ақ бірқатар сұхбаттарды талдау барысында мен Ansible қолданушылары жіберетін негізгі қатені түсіндім - олар күрделі нәрселерге қарапайым нәрселерді меңгермей-ақ кіріседі.

Осы әмбебап әділетсіздікті түзету үшін мен оны білетіндер үшін Ansible-ге кіріспе жазуды жөн көрдім. Мен сізге ескертемін, бұл ер адамдарды қайталау емес, бұл әріптер көп және суреттері жоқ ұзақ оқу.

Оқырманның күткен деңгейі - ямланың бірнеше мың жолдары жазылған, бірдеңе өндірісте, бірақ «әйтеуір бәрі қисық».

Тақырыптар

Ansible пайдаланушысының басты қателігі - бір нәрсенің қалай аталатынын білмеу. Егер сіз атауларды білмесеңіз, құжаттамада не айтылғанын түсіне алмайсыз. Тірі мысал: сұхбат кезінде Ansible-де көп жаздым деп көрінген адам «ойын кітапшасы қандай элементтерден тұрады?» Деген сұраққа жауап бере алмады. Мен «ойын кітапшасы ойыннан тұрады деген жауап күтілді» деп ұсынғанда, «біз оны пайдаланбаймыз» деген қарғыс атқыр түсініктеме болды. Адамдар Ansible деп ақшаға жазады және ойынды пайдаланбайды. Олар оны шын мәнінде пайдаланады, бірақ оның не екенін білмейді.

Сондықтан қарапайым нәрседен бастайық: ол қалай аталады. Сіз мұны білетін шығарсыз немесе білмейсіз, өйткені сіз құжаттаманы оқыған кезде назар аудармадыңыз.

ansible-playbook ойын кітапшасын орындайды. Ойын кітабы - yml/yaml кеңейтімі бар файл, оның ішінде келесідей нәрсе бар:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Біз бұл файлдың барлығы ойын кітабы екенін түсіндік. Біз рөлдердің және тапсырмалардың қай жерде екенін көрсете аламыз. Бірақ ойын қайда? Ал ойын мен рөлдің немесе ойын кітабының айырмашылығы неде?

Мұның бәрі құжаттамада. Және олар оны сағынады. Жаңадан бастаушылар - өйткені тым көп және сіз бәрін бірден есте сақтай алмайсыз. Тәжірибелі - өйткені «ұсақ нәрселер». Тәжірибелі болсаңыз, бұл беттерді кем дегенде жарты жылда бір рет қайта оқып шығыңыз, сонда сіздің кодыңыз сынып жетекші болады.

Ендеше, есіңізде болсын: Playbook - бұл play және таңбаларынан тұратын тізім import_playbook.
Бұл бір пьеса:

- hosts: group1
  roles:
    - role1

және бұл тағы бір пьеса:

- hosts: group2,group3
  tasks:
    - debug:

Ойын дегеніміз не? Ол неге?

Ойнау ойын кітабының негізгі элементі болып табылады, өйткені ойнау және тек ойнау рөлдердің және/немесе тапсырмалардың тізімін олар орындалуы керек хосттар тізімімен байланыстырады. Құжаттаманың терең тереңдігінде сіз атап өтуге болады delegate_to, жергілікті іздеу плагиндері, желіге арналған арнайы параметрлер, өту хосттары және т.б. Олар тапсырмалар орындалатын орынды сәл өзгертуге мүмкіндік береді. Бірақ, ұмыт. Осы ақылды опциялардың әрқайсысының өте нақты қолданылуы бар және олар әмбебап емес. Біз әркім білуі және пайдалануы керек негізгі нәрселер туралы айтып отырмыз.

Егер сіз «бірдеңені» «бір жерде» орындағыңыз келсе, сіз ойын жазасыз. Рөл емес. Модульдер мен делегаттармен рөл емес. Сіз оны алып, пьеса жазасыз. Онда хосттар өрісінде орындалатын жерді, ал рөлдерде/тапсырмаларда нені орындау керектігін тізімдейсіз.

Қарапайым, солай ма? Басқаша қалай болуы мүмкін?

Адамдардың ойын арқылы емес, мұны қалайтыны тән сәттердің бірі - «бәрін реттейтін рөл». Мен бірінші түрдегі серверлерді де, екінші түрдегі серверлерді де теңшейтін рөлге ие болғым келеді.

Архетиптік мысал - мониторинг. Мен бақылауды теңшейтін бақылау рөлін алғым келеді. Бақылау рөлі бақылау хосттарына тағайындалады (ойнауға сәйкес). Бірақ бақылау үшін біз бақылап отырған хосттарға пакеттерді жеткізуіміз керек екен. Неліктен делегат қолданбасқа? Сондай-ақ iptables конфигурациялау қажет. делегат? Сондай-ақ бақылауды қосу үшін ДҚБЖ конфигурациясын жазу/түзету қажет. делегат! Ал егер шығармашылық жетіспесе, онда делегация құра аласыз include_role топтар тізіміндегі күрделі сүзгіні пайдаланып кірістірілген циклде және ішінде include_role сіз көбірек жасай аласыз delegate_to қайтадан. Ал біз кетеміз...

Жақсы тілек – «бәрін жасайтын» бір ғана бақылау рөліне ие болу - бізді толық тозаққа апарады, одан шығудың бір ғана жолы бар: бәрін нөлден қайта жазу.

Бұл жерде қателік қай жерде болды? X хостындағы "x" тапсырмасын орындау үшін Y хостына барып, сол жерде "y" орындау керек екенін байқаған кезде, қарапайым жаттығуды орындау керек болды: барып, Y хостында орындайтын ойынды жазу керек. «Х»-ға бірдеңе қоспаңыз, бірақ оны нөлден бастап жазыңыз. Тіпті қатты кодталған айнымалылармен.

Жоғарыдағы абзацтардың бәрі дұрыс айтылған сияқты. Бірақ бұл сіздің жағдайыңыз емес! Өйткені сіз ҚҰРҒАҚ және кітапханаға ұқсас қайта пайдалануға болатын кодты жазғыңыз келеді және оны қалай жасау керектігінің әдісін іздеу керек.

Бұл жерде тағы бір күрделі қателік жасырынып жатыр. Көптеген жобаларды шыдамды түрде жазылғаннан (бұл жақсырақ болуы мүмкін, бірақ бәрі жұмыс істейді және аяқтау оңай) тіпті автордың өзі анықтай алмайтын толық қорқынышқа айналдырған қате. Бұл жұмыс істейді, бірақ Құдай сізге ештеңені өзгертуден сақтасын.

Қате: рөл - кітапхана функциясы. Бұл ұқсастық көптеген жақсы бастамаларды құртқаны сонша, оны көру өте өкінішті. Рөл кітапхана функциясы емес. Ол есептеулер жасай алмайды және ойын деңгейінде шешім қабылдай алмайды. Ойын қандай шешім қабылдайтынын еске түсіріңізші?

Рахмет, дұрыс айтасыз. Ойын қандай хосттарда қандай тапсырмалар мен рөлдерді орындау керектігі туралы шешім қабылдайды (дәлірек айтсақ, онда ақпарат бар).

Егер сіз бұл шешімді рөлге тапсырсаңыз, тіпті есептеулермен де, сіз өзіңізді (және кодыңызды талдауға тырысатын адамды) бақытсыз өмірге айналдырасыз. Рөл қай жерде орындалатынын шешпейді. Бұл шешім ойын арқылы қабылданады. Рөл айтқанын, айтқанын орындайды.

Неліктен Ansible-де бағдарламалау қауіпті және COBOL неге Ansible-ден жақсырақ, біз айнымалылар мен джинжа туралы тарауда сөйлесетін боламыз. Әзірге бір нәрсені айтайық - сіздің әрбір есептеуіңіз жаһандық айнымалылардағы өзгерістердің өшпес ізін қалдырады және сіз бұл туралы ештеңе істей алмайсыз. Екі «із» қиылысқан бойда бәрі жойылды.

Қиындыққа арналған ескерту: рөл басқару ағынына әсер етуі мүмкін. Тамақ delegate_to және оның орынды пайдалануы бар. Тамақ meta: end host/play. Бірақ! Біз негіздерді үйрететінімізді есіңізде ме? Ұмытып кеткен delegate_to. Біз ең қарапайым және әдемі Ansible коды туралы айтып отырмыз. Оқуға, жазуға, жөндеуге, тексеруге және толтыруға оңай. Сонымен, тағы да:

ойнау және тек ойын қай хосттар орындалатынын шешеді.

Бұл бөлімде біз ойын мен рөл арасындағы қарама-қайшылықты қарастырдық. Енді тапсырмалар мен рөлдік қатынас туралы сөйлесейік.

Тапсырмалар мен рөлдер

Ойнауды қарастырыңыз:

- 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 рөлдерді орындау нәтижелерімен жұмыс істеуге мүмкіндік береді (соның ішінде өңдеушілер).

Бұл не екенін бізге Ansible сарапшысы айтып береді. meta: flush_handlers, бірақ егер біз ойында бөлімдердің орындалу ретіне сене алатын болсақ, бізге flush_handlers не үшін қажет? Сонымен қатар, meta: flush_handlers пайдалану бізге қайталанатын өңдеушілермен күтпеген нәрселерді бере алады, бұл пайдаланылған кезде бізге оғаш ескертулер береді. when у block және т.б. Неғұрлым дұрыс шешімді білсеңіз, «қиын» шешім үшін соғұрлым көп нюанстарды атай аласыз. Және қарапайым шешім - алдын ала/рөлдер/пост арасындағы табиғи бөлуді пайдалану - нюанстарды тудырмайды.

Ал, біздің «фу» дегенге қайта оралу. Мен оны қайда қоюым керек? Алдын ала, постта немесе рөлдерде ме? Әлбетте, бұл foo үшін өңдегіштің нәтижелері қажет пе, жоқ па байланысты. Егер олар жоқ болса, онда foo-ны алдын ала немесе кейінге қоюдың қажеті жоқ - бұл бөлімдердің ерекше мағынасы бар - кодтың негізгі бөлігінен бұрын және кейін тапсырмаларды орындау.

Енді «рөл немесе тапсырма» деген сұраққа жауап бұрыннан бар нәрсеге келеді - егер онда тапсырмалар болса, оларды тапсырмаларға қосу керек. Рөлдер болса, рөлді (тіпті бір тапсырмадан) жасау керек. Тапсырмалар мен рөлдердің бір уақытта пайдаланылмайтынын еске саламын.

Ansible негіздерін түсіну талғамға қатысты болып көрінетін сұрақтарға ақылға қонымды жауап береді.

Тапсырмалар мен рөлдер (екінші бөлім)

Енді ойын кітабын жазуды енді бастаған кездегі жағдайды талқылайық. Фу, бар және баз жасау керек. Бұл үш тапсырма, бір рөл немесе үш рөл бе? Сұрақты қорытындылау үшін: рөлдерді жазуды қай уақыттан бастау керек? Тапсырмаларды жазуға болатын кезде рөлдерді жазудың мәні неде?... Рөл дегеніміз не?

Ең үлкен қателіктердің бірі (мен бұл туралы айттым) рөлді бағдарлама кітапханасындағы функция сияқты деп ойлау. Жалпы функцияның сипаттамасы неге ұқсайды? Ол кіріс аргументтерін қабылдайды, жанама себептермен әрекеттеседі, жанама әсерлер жасайды және мәнді қайтарады.

Енді, назар. Бұл рөлде не істеуге болады? Сіз әрқашан жанама әсерлерді шақыра аласыз, бұл бүкіл Ansible мәні - жанама әсерлерді жасау. Жанама себептері бар ма? Бастауыш. Бірақ «мәнді беріңіз және оны қайтарыңыз» - бұл жерде ол жұмыс істемейді. Біріншіден, рөлге мән бере алмайсыз. Рөлге арналған vars бөлімінде ойнатудың өмірлік өлшемі бар жаһандық айнымалы мәнді орнатуға болады. Рөл ішінде өмір бойы ойнайтын жаһандық айнымалы мәнді орнатуға болады. Немесе тіпті ойын кітаптарының өмір сүру ұзақтығымен (set_fact/register). Бірақ сізде «жергілікті айнымалылар» болуы мүмкін емес. Сіз «мәнді қабылдауға» және «оны қайтаруға» болмайды.

Ең бастысы, сіз Ansible-де жанама әсерлерсіз бірдеңе жаза алмайсыз. Жаһандық айнымалы мәндерді өзгерту әрқашан функция үшін жанама әсер болып табылады. Мысалы, Rust бағдарламасында жаһандық айнымалыны өзгерту болып табылады 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 — Естеріңізге сала кетейін, біз фигуралық гимнастикадан емес, қарапайым Ansible бойынша дағдыларды жетілдіреміз.

Өңдеушілер мен тапсырмалар

Тағы бір анық нәрсені талқылайық: өңдеушілер. Оларды қалай дұрыс пайдалану керектігін білу өнер десе де болады. Өңдеуші мен сүйрегіштің айырмашылығы неде?

Негіздерді еске түсіргендіктен, мына мысал:

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

Рөл өңдегіштері rolename/handlers/main.yaml ішінде орналасқан. Өңдеушілер ойынның барлық қатысушылары арасында шатасады: pre/post_tasks рөлдерді өңдеушілерді тарта алады және рөл өңдеушілерді ойыннан тарта алады. Дегенмен, өңдеушілерге арналған "роларалық" қоңыраулар тривиальды өңдегішті қайталауға қарағанда әлдеқайда көп wtf тудырады. (Ең жақсы тәжірибелердің тағы бір элементі өңдеуші атауларын қайталамауға тырысу).

Негізгі айырмашылығы - тапсырма әрқашан орындалады (идемпотентті) (плюс/минус тегтері және when), және өңдеуші - күйдің өзгеруі бойынша (өзгертілген жағдайда ғана өртке хабарлаңыз). Бұл нені білдіреді? Мысалы, қайта іске қосқан кезде, егер ешқандай өзгеріс болмаса, өңдеуші болмайды. Неліктен генерациялау тапсырмасында өзгеріс болмаған кезде өңдегішті орындау қажет болуы мүмкін? Мысалы, бір нәрсе бұзылып, өзгергендіктен, орындау өңдеушіге жетпеді. Мысалы, желі уақытша өшірілгендіктен. Конфигурация өзгерді, қызмет қайта іске қосылмаған. Келесі жолы оны іске қосқанда конфигурация бұдан былай өзгермейді және қызмет конфигурацияның ескі нұсқасында қалады.

Конфигурацияға қатысты жағдайды шешу мүмкін емес (дәлірек айтқанда, сіз өзіңіз үшін файл жалаушалары бар арнайы қайта іске қосу протоколын ойлап таба аласыз және т.б., бірақ бұл енді кез келген пішінде «негізгі» емес). Бірақ тағы бір ортақ оқиға бар: біз қолданбаны орнаттық, оны жаздык .service-файл, енді біз оны қалаймыз daemon_reload и state=started. Ал бұл үшін табиғи орын өңдеуші сияқты. Бірақ егер сіз оны өңдеуші емес, тапсырмалар тізімінің немесе рөлдің соңындағы тапсырма жасасаңыз, ол әр уақытта икемді түрде орындалады. Ойын кітапшасы ортасынан сынса да. Бұл қайта іске қосылған мәселені мүлде шешпейді (қайта іске қосылған атрибутпен тапсырманы орындай алмайсыз, өйткені идемпотенттілік жоғалады), бірақ бұл міндетті түрде state=started әрекетін орындауға тұрарлық, ойын кітаптарының жалпы тұрақтылығы артады, себебі қосылыстар саны мен динамикалық күйі төмендейді.

Өңдеушінің тағы бір оң қасиеті - ол шығысты бітеп тастамайды. Ешқандай өзгерістер болған жоқ - қосымша өткізіп жіберу немесе шығаруда OK - оқуға оңай. Бұл сондай-ақ теріс қасиет - егер сіз бірінші іске қосуда сызықтық орындалған тапсырмада қате тапсаңыз, өңдеушілер өзгертілген кезде ғана орындалады, яғни. кейбір жағдайларда - өте сирек. Мысалы, бес жылдан кейін өмірімде бірінші рет. Және, әрине, атауында қате болады және бәрі бұзылады. Егер сіз оларды екінші рет іске қоспасаңыз, ешқандай өзгеріс болмайды.

Айнымалылардың қол жетімділігі туралы бөлек айту керек. Мысалы, тапсырманы цикл арқылы хабардар етсеңіз, айнымалыларда не болады? Сіз аналитикалық түрде болжай аласыз, бірақ бұл әрқашан маңызды емес, әсіресе айнымалылар әртүрлі жерлерден келсе.

... Сондықтан өңдеушілер көрінгеннен әлдеқайда пайдалы және әлдеқайда проблемалы. Егер сіз бірдеңені өңдеушілерсіз әдемі (бүркісіз) жаза алсаңыз, оны оларсыз жасаған дұрыс. Егер бұл әдемі болмаса, олармен жақсырақ.

Тотығушы оқырман біз талқылаған жоқпыз деп дұрыс айтады listenөңдеуші басқа өңдеуші үшін notify шақыра алатынын, өңдеуші import_tasks қоса алатынын (олар with_items көмегімен қосу_рөлін орындай алады), Ansible жүйесіндегі өңдеушілер жүйесі Turing-complete екенін, include_role өңдеушілері ойыннан өңдеушілермен қызықты түрде қиылысады, т.б. .d. - мұның бәрі «негіздер» емес).

Бір нақты WTF бар болса да, ол шын мәнінде есте сақтау қажет мүмкіндік болып табылады. Егер тапсырма орындалса delegate_to және ол хабардар етті, содан кейін сәйкес өңдеуші онсыз орындалады delegate_to, яғни. ойын тағайындалған хостта. (Әрине өңдеушіде болуы мүмкін delegate_to Дәл солай).

Бөлек, мен қайта пайдалануға болатын рөлдер туралы бірнеше сөз айтқым келеді. Топтамалар пайда болғанға дейін сіз әмбебап рөлдерді жасай аласыз деген идея болды ansible-galaxy install және кетті. Барлық жағдайларда барлық нұсқалардың барлық ОЖ-де жұмыс істейді. Сонымен, менің пікірім: бұл жұмыс істемейді. Массасы бар кез келген рөл include_vars, 100500 істі қолдайтын, бұрыштық қаптама қателерінің тұңғиығына ұшырайды. Оларды жаппай тестілеумен қамтуға болады, бірақ кез келген тестілеу сияқты, сізде кіріс мәндерінің және жалпы функцияның декарттық өнімі бар немесе сізде «жеке сценарийлер қамтылған». Менің ойымша, рөл сызықтық болса, әлдеқайда жақсы (цикломатиялық күрделілік 1).

Егер азырақ болса (анық немесе декларативті - пішінде when немесе пішін include_vars айнымалылар жиыны бойынша), рөл соғұрлым жақсырақ. Кейде сіз бұтақтарды жасауыңыз керек, бірақ, қайталап айтамын, неғұрлым аз болса, соғұрлым жақсы. Сондықтан бұл галактикамен жақсы рөл сияқты көрінеді (ол жұмыс істейді!) when бес тапсырмадан «өзінің» рөлінен гөрі артық болуы мүмкін. Галактиканың рөлі жақсырақ болған кез - сіз бірдеңе жаза бастаған кезде. Бірдеңе бұзылып, «галактикамен рөлге» байланысты деген күдік пайда болады. Сіз оны ашсаңыз, бес қосынды, сегіз тапсырма парағы және стек бар when'ov... Және біз мұны анықтауымыз керек. 5 тапсырманың орнына, бұзатын ештеңе жоқ сызықтық тізім.

Келесі бөліктерде

• Түгендеу, топтық айнымалылар, host_group_vars плагині, хосттар туралы аздап. Гордиан түйінін спагеттимен қалай байлау керек. Ауқым және басымдық айнымалылары, Ansible жады моделі. «Дерекқордың пайдаланушы атын қайда сақтаймыз?»
• jinja: {{ jinja }} — nosql notype nosense жұмсақ пластилин. Ол барлық жерде, тіпті сіз күтпеген жерде де бар. Біраз туралы !!unsafe және дәмді ямл.

Ақпарат көзі: www.habr.com