Правя много рецензии на кода на Ansible на други хора и самият аз пиша много. В хода на анализиране на грешки (както на други хора, така и на мои собствени), както и на редица интервюта, разбрах основната грешка, която правят потребителите на Ansible - навлизат в сложни неща, без да овладеят основните.

За да коригирам тази универсална несправедливост, реших да напиша въведение към Ansible за тези, които вече го познават. Предупреждавам ви, това не е преразказ на мъже, това е лонгрид с много букви и без картинки.

Очакваното ниво на читателя е, че вече са написани няколко хиляди реда yamla, нещо вече се произвежда, но „някак си всичко е криво“.

имена

Основната грешка, която потребителят на Ansible прави, е да не знае как се нарича нещо. Ако не знаете имената, не можете да разберете какво пише в документацията. Жив пример: по време на интервю човек, който като че ли каза, че пише много в Ansible, не можа да отговори на въпроса „от какви елементи се състои книгата за игри?“ И когато предложих, че „отговорът се очакваше, че книгата-игра се състои от игра“, последва осъдителният коментар „ние не използваме това“. Хората пишат Ansible за пари и не използват play. Те всъщност го използват, но не знаят какво представлява.

Така че нека започнем с нещо просто: как се казва? Може би знаете това или може би не, защото не сте обърнали внимание, когато сте чели документацията.

ansible-playbook изпълнява книгата. Книгата за игра е файл с разширение 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, добавки за локално търсене, специфични за мрежата настройки, хостове за прескачане и др. Те ви позволяват леко да промените мястото, където се изпълняват задачите. Но забравете за това. Всяка от тези умни опции има много специфични приложения и определено не е универсална. И говорим за основни неща, които всеки трябва да знае и използва.

Ако искате да изпълните „нещо“ „някъде“, пишете игра. Не е роля. Не е роля с модули и делегати. Взимаш го и пишеш игра. В което, в полето hosts изброявате къде да се изпълнява, а в roles/tasks - какво да се изпълнява.

Просто, нали? Как би могло да бъде иначе?

Един от характерните моменти, когато хората имат желание да направят това не чрез игра, е „ролята, която определя всичко“. Бих искал да имам роля, която конфигурира както сървъри от първия тип, така и сървъри от втори тип.

Архетипен пример е мониторингът. Бих искал да имам роля за наблюдение, която ще конфигурира наблюдението. Ролята за наблюдение се възлага на хостове за наблюдение (според играта). Но се оказва, че за наблюдение трябва да доставим пакети на хостовете, които наблюдаваме. Защо не използвате делегат? Трябва също да конфигурирате iptables. делегат? Трябва също така да напишете/коригирате конфигурация за СУБД, за да активирате наблюдението. делегат! И ако креативността липсва, тогава можете да направите делегация include_role във вложен цикъл с помощта на сложен филтър върху списък от групи и вътре include_role можете да направите повече delegate_to отново. И тръгваме...

Доброто желание - да имаме една-единствена наблюдателна роля, която "прави всичко" - ни води в пълен ад, от който най-често има само един изход: да пренапишем всичко от нулата.

Къде стана грешката тук? В момента, в който открихте, че за да изпълните задача „x“ на хост X, трябва да отидете на хост Y и да направите „y“ там, трябваше да направите просто упражнение: отидете и напишете play, което на хост Y прави y. Не добавяйте нещо към "х", а го напишете от нулата. Дори и с твърдо кодирани променливи.

Изглежда, че всичко в параграфите по-горе е казано правилно. Но това не е вашият случай! Защото искате да напишете код за многократна употреба, който е СУХ и подобен на библиотека, и трябва да потърсите метод как да го направите.

Тук дебне друга сериозна грешка. Грешка, която превърна много проекти от сносно написани (може и по-добре, но всичко работи и се довършва лесно) в пълен ужас, който дори авторът не може да разбере. Работи, но не дай Боже да промените нещо.

Грешката е: ролята е библиотечна функция. Тази аналогия е съсипала толкова много добри начала, че е просто тъжно да се гледа. Ролята не е библиотечна функция. Тя не може да прави изчисления и не може да взема решения на ниво игра. Напомни ми какви решения взема играта?

Благодаря, прав си. Play взема решение (по-точно съдържа информация) за това кои задачи и роли да изпълнява на кои хостове.

Ако делегирате това решение на роля, та дори и с изчисления, вие обричате себе си (и този, който ще се опита да анализира вашия код) на жалко съществуване. Ролята не определя къде се изпълнява. Това решение се взема чрез игра. Ролята прави каквото й се каже, където й се каже.

Защо е опасно да се програмира в Ansible и защо COBOL е по-добър от Ansible, ще говорим в главата за променливите и jinja. Засега нека кажем едно нещо - всяко ваше изчисление оставя след себе си незаличима следа от промени в глобалните променливи и вие не можете да направите нищо по въпроса. Щом двете „следи“ се пресекоха, всичко изчезна.

Бележка за недоволните: ролята със сигурност може да повлияе на контролния поток. Яжте delegate_to и има разумни приложения. Яжте meta: end host/play. Но! Спомняте ли си, че преподаваме основите? Забравих за delegate_to. Говорим за най-простия и красив Ansible код. Което е лесно за четене, лесно за писане, лесно за отстраняване на грешки, лесно за тестване и лесно за попълване. И така, още веднъж:

play и само play решава на кои хостове какво се изпълнява.

В този раздел се занимавахме с опозицията между игра и роля. Сега нека поговорим за връзката между задачи и роли.

Задачи и роли

Помислете за игра:

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

Да кажем, че трябва да направите foo. И изглежда като foo: name=foobar state=present. Къде трябва да напиша това? в преди? пост? Създаване на роля?

...И къде отидоха задачите?

Отново започваме с основите – устройството за игра. Ако плавате по този въпрос, не можете да използвате играта като основа за всичко останало и резултатът ви ще бъде "нестабилен".

Устройство за възпроизвеждане: директива за хостове, настройки за самото възпроизвеждане и секции pre_tasks, tasks, role, post_tasks. Останалите параметри за игра сега не са важни за нас.

Редът на техните раздели със задачи и роли: pre_tasks, roles, tasks, post_tasks. Тъй като семантично редът на изпълнение е между tasks и roles не е ясно, тогава най-добрите практики казват, че добавяме раздел tasks, само ако не roles... Ако има roles, след което всички приложени задачи са поставени в раздели pre_tasks/post_tasks.

Остава само всичко да е семантично ясно: първо pre_tasks, тогава roles, тогава post_tasks.

Но все още не сме отговорили на въпроса: къде е извикването на модула? foo пиша? Трябва ли да пишем цяла роля за всеки модул? Или е по-добре да имаш дебела роля за всичко? И ако не е роля, тогава къде да пиша - в pre или post?

Ако няма аргументиран отговор на тези въпроси, това е знак за липса на интуиция, тоест същите тези „нестабилни основи“. Нека да го разберем. Първо, въпрос за сигурност: Ако играта има 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 не е необходимо да се поставя нито в pre, нито в post - тези секции имат специално значение - изпълнение на задачи преди и след основната част от кода.

Сега отговорът на въпроса „роля или задача“ се свежда до това, което вече е в играта - ако има задачи там, тогава трябва да ги добавите към задачите. Ако има роли, трябва да създадете роля (дори от една задача). Нека напомня, че задачите и ролите не се използват едновременно.

Разбирането на основите на Ansible дава разумни отговори на привидно въпроси на вкуса.

Задачи и роли (втора част)

Сега нека обсъдим ситуацията, когато тепърва започвате да пишете книга-игра. Трябва да направите foo, bar и baz. Това три задачи една роля ли са или три роли? За да обобщим въпроса: в кой момент трябва да започнете да пишете роли? Какъв е смисълът да пишеш роли, когато можеш да пишеш задачи?... Какво е роля?

Една от най-големите грешки (вече говорих за това) е да мислим, че ролята е като функция в библиотеката на програмата. Как изглежда общото описание на функцията? Той приема входни аргументи, взаимодейства със странични причини, прави странични ефекти и връща стойност.

Сега внимание. Какво може да се направи от това в ролята? Винаги сте добре дошли да извиквате странични ефекти, това е същността на целия 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/). Но в сравнение със задачите в книгата (която също може да има всичко това), единственото предимство тук е, че файловете не се изхвърлят в една купчина, а в няколко отделни купчини.

Още една подробност: можете да опитате да създадете роли, които ще бъдат достъпни за повторна употреба (чрез galaxy). С появата на колекциите разпределението на ролите може да се счита за почти забравено.

По този начин ролите имат две важни характеристики: имат настройки по подразбиране (уникална функция) и ви позволяват да структурирате кода си.

Връщайки се към първоначалния въпрос: кога да изпълняваме задачи и кога да изпълняваме роли? Задачите в книгата най-често се използват или като „лепило“ преди/след ролите, или като независим градивен елемент (тогава не трябва да има роли в кода). Купчина нормални задачи, смесени с роли, е недвусмислена помия. Трябва да се придържате към определен стил - или задача, или роля. Ролите осигуряват разделяне на обекти и настройки по подразбиране, задачите ви позволяват да четете код по-бързо. Обикновено по-„стационарен“ (важен и сложен) код се поставя в роли, а спомагателните скриптове се пишат в стил на задача.

Възможно е да направите 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. И естественото място за това изглежда е манипулаторът. Но ако го направите не манипулатор, а задача в края на списък със задачи или роля, тогава той ще се изпълнява идемпотентно всеки път. Дори книгата с игри да се счупи по средата. Това изобщо не решава проблема с рестартирането (не можете да направите задача с атрибута restarted, защото идемпотентността се губи), но определено си струва да направите state=started, общата стабилност на книгите за игри се увеличава, защото броят на връзките и динамичното състояние намалява.

Друго положително свойство на манипулатора е, че не задръства изхода. Няма промени - няма допълнително пропуснато или добре в изхода - по-лесно за четене. Това също е отрицателно свойство - ако намерите печатна грешка в линейно изпълнена задача при първото изпълнение, тогава манипулаторите ще бъдат изпълнени само когато се променят, т.е. при някои условия - много рядко. Например за първи път в живота си пет години по-късно. И, разбира се, ще има печатна грешка в името и всичко ще се счупи. И ако не ги стартирате втори път, няма промяна.

Отделно трябва да говорим за наличието на променливи. Например, ако уведомите задача с цикъл, какво ще има в променливите? Можете да гадаете аналитично, но не винаги е тривиално, особено ако променливите идват от различни места.

... Така че манипулаторите са много по-малко полезни и много по-проблематични, отколкото изглеждат. Ако можете да напишете нещо красиво (без излишни украшения) без манипулатори, по-добре е да го направите без тях. Ако не се получи красиво, по-добре е с тях.

Разяждащият читател правилно отбелязва, че не сме обсъждали listenче манипулатор може да извика notify за друг манипулатор, че манипулатор може да включва import_tasks (което може да прави include_role с with_items), че манипулаторната система в Ansible е Turing-complete, че манипулаторите от include_role се пресичат по любопитен начин с манипулатори от игра, и т.н. .d. - всичко това очевидно не е „основата“).

Въпреки че има един специфичен WTF, който всъщност е функция, която трябва да имате предвид. Ако задачата ви е изпълнена с delegate_to и има notify, тогава съответният манипулатор се изпълнява без delegate_to, т.е. на хоста, където е възложена игра. (Въпреки че манипулаторът, разбира се, може да има delegate_to Един и същ).

Отделно искам да кажа няколко думи за многократно използваните роли. Преди да се появят колекции, имаше идея, че можете да правите универсални роли, които могат да бъдат ansible-galaxy install и отиде. Работи на всички ОС от всички варианти във всички ситуации. Така че, моето мнение: не работи. Всяка роля с маса include_vars, поддържащ 100500 1 случая, е обречен на бездна от ъглови грешки в случаите. Те могат да бъдат покрити с масивно тестване, но както при всяко тестване, или имате декартово произведение на входни стойности и обща функция, или имате „покрити индивидуални сценарии“. Моето мнение е, че е много по-добре ролята да е линейна (цикломатична сложност XNUMX).

Колкото по-малко ако (изрични или декларативни - във формата when или форма include_vars по набор от променливи), толкова по-добра е ролята. Понякога трябва да направите клонове, но, повтарям, колкото по-малко са, толкова по-добре. Така че изглежда като добра роля с galaxy (работи!) с куп when може да бъде по-малко за предпочитане от „собствената“ роля от пет задачи. Моментът, в който ролята с galaxy е по-добра, е когато започнеш да пишеш нещо. Моментът, в който става по-лошо, е когато нещо се счупи и имате съмнение, че е заради „ролята с галактика“. Отваряте го и има пет включвания, осем листа със задачи и стек whenО... И трябва да разберем това. Вместо 5 задачи, линеен списък, в който няма какво да се счупи.

В следващите части

• Малко за инвентара, груповите променливи, плъгина host_group_vars, hostvars. Как да завържем гордиев възел със спагети. Обхват и приоритетни променливи, Ansible памет модел. „И така, къде да съхраняваме потребителското име за базата данни?“
• jinja: {{ jinja }} — nosql notype nosense мек пластелин. Има го навсякъде, дори и там, където не го очаквате. Малко за !!unsafe и вкусен ямл.

Източник: www.habr.com