block<\/code> itd. Im lepiej znasz ansible, tym wi\u0119cej szczeg\u00f3\u0142\u00f3w mo\u017cesz nazwa\u0107 dla \"sprytnego\" rozwi\u0105zania. A proste rozwi\u0105zanie \u2014 wykorzystanie naturalnego podzia\u0142u mi\u0119dzy pre\/roles\/post \u2014 nie budzi w\u0105tpliwo\u015bci.<\/p>\n<\/p>\n
I wracaj\u0105c do naszego 'foo'. Gdzie go umie\u015bci\u0107? W pre, post czy w roles? Oczywi\u015bcie, to zale\u017cy od tego, czy potrzebujemy wynik\u00f3w pracy handlera dla foo. Je\u015bli ich nie ma, foo nie trzeba umieszcza\u0107 ani w pre, ani w post \u2014 te sekcje maj\u0105 specjalne znaczenie \u2014 wykonywanie zada\u0144 przed i po g\u0142\u00f3wnym bloku kodu.<\/p>\n
<\/p>\n
Teraz odpowied\u017a na pytanie \"rola czy zadanie\" sprowadza si\u0119 do tego, co ju\u017c istnieje w play \u2014 je\u015bli s\u0105 tam tasks, trzeba je dopisa\u0107 do tasks. Je\u015bli s\u0105 roles \u2014 trzeba stworzy\u0107 rol\u0119 (nawet z jednego tasku). Przypominam, tasks i roles nie s\u0105 u\u017cywane jednocze\u015bnie.<\/p>\n
<\/p>\n
Zrozumienie podstaw Ansible\u2019a daje uzasadnione odpowiedzi na, wydawa\u0142oby si\u0119, pytania o charakterze subiektywnym.<\/p>\n
<\/p>\n
Zadania i role (cz\u0119\u015b\u0107 druga)<\/h1>\n <\/p>\n
Teraz om\u00f3wimy sytuacj\u0119, gdy dopiero zaczynasz pisa\u0107 playbook. Musisz zrobi\u0107 foo, bar i baz. To trzy zadania, jedna rola czy trzy role? Generalizuj\u0105c pytanie: w kt\u00f3rym momencie nale\u017cy zacz\u0105\u0107 pisa\u0107 role? Jaki jest sens pisania r\u00f3l, skoro mo\u017cna pisa\u0107 zadania?\u2026 Czym jest rola?<\/p>\n
<\/p>\n
Jednym z najwi\u0119kszych b\u0142\u0119d\u00f3w (ju\u017c o tym wspomnia\u0142em) jest mylenie roli z funkcj\u0105 w bibliotece programu. Jak wygl\u0105da og\u00f3lne opisanie funkcji? Przyjmuje argumenty na wej\u015bciu, oddzia\u0142uje na side causes, wywo\u0142uje side effects, zwraca warto\u015b\u0107.<\/p>\n
<\/p>\n
Teraz, uwaga. Co mo\u017cna zrobi\u0107 w roli? Wywo\u0142ywa\u0107 efekty uboczne \u2014 zawsze prosz\u0119, to jest istota ca\u0142ego Ansibla \u2014 generowanie efekt\u00f3w ubocznych. Mie\u0107 przyczyny uboczne? Elementarne. Ale z \"przekaza\u0107 warto\u015b\u0107 i zwr\u00f3ci\u0107 j\u0105\" \u2014 tutaj ju\u017c nie. Po pierwsze, nie mo\u017cesz przekaza\u0107 warto\u015bci do roli. Mo\u017cesz ustawi\u0107 zmienn\u0105 globaln\u0105 o czasie \u017cycia r\u00f3wnym play w sekcji vars dla roli. Mo\u017cesz ustawi\u0107 zmienn\u0105 globaln\u0105 o czasie \u017cycia w play wewn\u0105trz roli. Lub nawet o czasie \u017cycia playbooka (set_fact<\/code>\/register<\/code>). Ale nie mo\u017cesz mie\u0107 \"zmiennych lokalnych\". Nie mo\u017cesz \"przyjmowa\u0107 warto\u015bci\" i \"zwraca\u0107 jej\".<\/p>\n<\/p>\n
Z tego wynika najwa\u017cniejsze: nie mo\u017cna w Ansible napisa\u0107 czego\u015b i nie wywo\u0142a\u0107 side effects. Zmiana zmiennych globalnych \u2014 to zawsze side effect dla funkcji. W Rust, na przyk\u0142ad, zmiana zmiennej globalnej to unsafe<\/code>. W Ansible jest to jedyny spos\u00f3b na wp\u0142ywanie na warto\u015bci dla roli. Zauwa\u017c, jak u\u017cywane s\u0105 s\u0142owa: nie "przekaza\u0107 warto\u015b\u0107 do roli", ale "zmieni\u0107 warto\u015bci, z kt\u00f3rych korzysta rola". Nie ma izolacji mi\u0119dzy rolami. Nie ma izolacji mi\u0119dzy zadaniami a rolami.<\/p>\n<\/p>\n
Podsumowuj\u0105c: rola \u2014 to nie funkcja<\/strong>.<\/p>\n<\/p>\n
Co dobrego jest w roli? Po pierwsze, rola ma warto\u015bci domy\u015blne (\/default\/main.yaml<\/code>), po drugie, rola ma dodatkowe katalogi do przechowywania plik\u00f3w.<\/p>\n<\/p>\n
Czym wi\u0119c s\u0105 dobre warto\u015bci domy\u015blne? Tym, \u017ce w mocno zniekszta\u0142conej tabeli priorytet\u00f3w zmiennych wed\u0142ug Maslowa, domy\u015blne warto\u015bci roli \u2014 s\u0105 najbardziej nisko priorytetowe (z wyj\u0105tkiem parametr\u00f3w wiersza polece\u0144 Ansible). To oznacza, \u017ce je\u015bli musisz dostarczy\u0107 warto\u015bci domy\u015blne i nie martwi\u0107 si\u0119, \u017ce zast\u0105pi\u0105 warto\u015bci z inwentarza lub zmiennych grupowych, to domy\u015blne warto\u015bci roli to jedyne w\u0142a\u015bciwe miejsce dla Ciebie. (Troszk\u0119 k\u0142ami\u0119 \u2014 jest jeszcze |d(your_default_here)<\/code>, ale je\u015bli m\u00f3wimy o sta\u0142ych miejscach \u2014 to tylko domy\u015blne warto\u015bci r\u00f3l).<\/p>\n<\/p>\n
Co jeszcze jest dobre w rolach? To, \u017ce maj\u0105 swoje katalogi. S\u0105 to katalogi dla zmiennych, zar\u00f3wno sta\u0142ych (tzn. obliczanych dla roli), jak i dynamicznych (jest taki wzorzec lub antywzorzec \u2014 include_vars<\/code> wraz z {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). To s\u0105 katalogi dla files\/<\/code>, templates\/<\/code>. Dodatkowo pozwala to na posiadanie w\u0142asnych modu\u0142\u00f3w i wtyczek w rolach (library\/<\/code>). Jednak w por\u00f3wnaniu z zadaniami w playbooku (kt\u00f3ry te\u017c mo\u017ce mie\u0107 to wszystko), korzy\u015b\u0107 tkwi tylko w tym, \u017ce pliki s\u0105 podzielone na kilka osobnych zbior\u00f3w, a nie wrzucone do jednego.<\/p>\n<\/p>\n
Jeszcze jeden szczeg\u00f3\u0142: mo\u017cna pr\u00f3bowa\u0107 tworzy\u0107 role, kt\u00f3re b\u0119d\u0105 dost\u0119pne do ponownego u\u017cycia (przez galaxy). Po wprowadzeniu kolekcji dystrybucja r\u00f3l mo\u017ce by\u0107 uwa\u017cana za prawie zapomnian\u0105.<\/p>\n
<\/p>\n
W ten spos\u00f3b role maj\u0105 dwie wa\u017cne cechy: maj\u0105 domy\u015blne warto\u015bci (unikalna cecha) i pozwalaj\u0105 strukturyzowa\u0107 kod.<\/p>\n
<\/p>\n
Wracaj\u0105c do pierwotnego pytania: kiedy stosowa\u0107 zadania, a kiedy role? Zadania w playbooku s\u0105 najcz\u0119\u015bciej u\u017cywane jako "klej" przed\/po rolach, lub jako samodzielny element konstrukcyjny (wtedy w kodzie nie powinno by\u0107 r\u00f3l). Mieszanie normalnych zada\u0144 z rolami to wyra\u017ana niechlujno\u015b\u0107. Nale\u017cy stosowa\u0107 konkretny styl \u2014 albo zadania, albo role. Role oferuj\u0105 podzia\u0142 dla encji i domy\u015blne warto\u015bci, zadania pozwalaj\u0105 szybciej czyta\u0107 kod. Zwykle w rolach umieszczany jest bardziej "sta\u0142y" (wa\u017cny i skomplikowany) kod, a w stylu zada\u0144 pisane s\u0105 pomocnicze skrypty.<\/p>\n
<\/p>\n
Mo\u017cna zrobi\u0107 import_role jako zadanie, ale je\u015bli to robisz, przygotuj si\u0119 na wyja\u015bnienie dla w\u0142asnego poczucia estetyki, dlaczego chcesz to robi\u0107.<\/p>\n
<\/p>\n
Dociekliwy czytelnik mo\u017ce powiedzie\u0107, \u017ce role mog\u0105 importowa\u0107 role, role mog\u0105 mie\u0107 zale\u017cno\u015bci przez galaxy.yml, a ponadto istnieje co\u015b strasznego i przera\u017caj\u0105cego. include_role<\/code> Przypominam, \u017ce rozwijamy umiej\u0119tno\u015bci w podstawowym Ansible, a nie w gimnastyce artystycznej.<\/p>\n<\/p>\n
Handlerzy i zadania<\/h1>\n <\/p>\n
Porozmawiajmy o jeszcze jednej oczywistej kwestii: handlerzy. Umiej\u0119tno\u015b\u0107 ich odpowiedniego u\u017cycia to niemal sztuka. Jaka jest r\u00f3\u017cnica mi\u0119dzy handlerem a zadaniem?<\/p>\n
<\/p>\n
Poniewa\u017c przypominamy sobie podstawy, oto przyk\u0142ad:<\/p>\n
<\/p>\n
- hosts: group1\n tasks:\n - foo:\n notify: handler1\n handlers:\n - name: handler1\n bar:<\/code><\/pre>\n<\/p>\n
Handler\u2019y roli znajduj\u0105 si\u0119 w rolename\/handlers\/main.yaml. Handler\u2019y s\u0105 dzielone mi\u0119dzy wszystkimi uczestnikami play: pre\/post_tasks mog\u0105 wywo\u0142ywa\u0107 handler\u2019y roli, a rola mo\u017ce wywo\u0142ywa\u0107 handler\u2019y z play. Jednak "cross-rolowe" wywo\u0142ania handler\u2019\u00f3w powoduj\u0105 znacznie wi\u0119ksze zaskoczenie, ni\u017c powtarzanie trywialnego handler\u2019a. (Kolejny element najlepszych praktyk \u2014 staraj si\u0119 unika\u0107 powtarzania nazw handler\u2019\u00f3w).<\/p>\n
<\/p>\n
Podstawowa r\u00f3\u017cnica polega na tym, \u017ce zadanie jest zawsze wykonywane (idempotentnie) (plus\/minus tagi i when<\/code>), a handler \u2014 w zale\u017cno\u015bci od zmiany stanu (notify dzia\u0142a tylko, je\u015bli by\u0142o zmienione). Co z tego wynika? Na przyk\u0142ad, \u017ce przy kolejnym uruchomieniu, je\u015bli nie by\u0142o zmiany, to nie b\u0119dzie r\u00f3wnie\u017c handlera. A dlaczego mo\u017ce by\u0107 tak, \u017ce musimy uruchomi\u0107 handler, kiedy w zadaniu macierzystym nie by\u0142o zmiany? Na przyk\u0142ad dlatego, \u017ce co\u015b si\u0119 zepsu\u0142o i zmiana by\u0142a, ale do handlera wykonanie nie dotar\u0142o. Na przyk\u0142ad, poniewa\u017c sie\u0107 chwilowo zawiod\u0142a. Konfiguracja zmieni\u0142a si\u0119, us\u0142uga nie zosta\u0142a uruchomiona ponownie. Przy nast\u0119pnym uruchomieniu konfiguracja ju\u017c si\u0119 nie zmienia, a us\u0142uga pozostaje z star\u0105 wersj\u0105 konfiguracji.<\/p>\n<\/p>\n
Sytuacja z konfiguracj\u0105 jest nierozwi\u0105zywalna (w\u0142a\u015bciwie, mo\u017cna wymy\u015bli\u0107 specjalny protok\u00f3\u0142 ponownego uruchamiania z flagami plik\u00f3w itd., ale to ju\u017c nie jest \u2018basic ansible\u2019 w \u017cadnej postaci). Za to jest inna cz\u0119sta historia: zainstalowali\u015bmy aplikacj\u0119, zapisali\u015bmy j\u0105, .service<\/code>-plik, i teraz chcemy go daemon_reload<\/code> i stan=uruchomiony<\/code>. Naturalnym miejscem dla tego wydaje si\u0119 by\u0107 handler. Ale je\u015bli zrobisz z niego task na ko\u0144cu listy zada\u0144 lub rol\u0119, to b\u0119dzie wykonywany idempotentnie za ka\u017cdym razem. Nawet je\u015bli playbook si\u0119 zepsuje w po\u0142owie. To nie rozwi\u0105zuje problemu restarted (nie mo\u017cna zrobi\u0107 tasku z atrybutem restarted, poniewa\u017c traci si\u0119 idempotentno\u015b\u0107), ale zdecydowanie warto ustawi\u0107 state=started, og\u00f3lna stabilno\u015b\u0107 playbook\u00f3w wzrasta, poniewa\u017c zmniejsza si\u0119 liczba zale\u017cno\u015bci i dynamicznych stan\u00f3w.<\/p>\n<\/p>\n
Kolejn\u0105 pozytywn\u0105 cech\u0105 handler\u2019a jest to, \u017ce nie zatyka on wyj\u015bcia. Nie by\u0142o zmian \u2014 brak zb\u0119dnych skipped lub ok w wyj\u015bciu \u2014 \u0142atwiej to przeczyta\u0107. To r\u00f3wnie\u017c jest negatywn\u0105 cech\u0105 \u2014 je\u015bli znajdziesz liter\u00f3wk\u0119 w liniowo wykonywanej task\u2019ie przy pierwszym uruchomieniu, to handler\u2019y b\u0119d\u0105 wykonywane tylko przy changed, czyli pod pewnymi warunkami \u2014 bardzo rzadko. Na przyk\u0142ad, pierwszy raz w \u017cyciu po pi\u0119ciu latach. I, oczywi\u015bcie, tam b\u0119dzie liter\u00f3wka w nazwie i wszystko si\u0119 zepsuje. A drugi raz ich nie uruchomisz \u2014 bo changed nie ma.<\/p>\n
<\/p>\n
Osobno trzeba porozmawia\u0107 o dost\u0119pno\u015bci zmiennych. Na przyk\u0142ad, je\u015bli u\u017cywasz notify dla tasku z p\u0119tl\u0105, to co b\u0119dzie w zmiennych? Mo\u017cna to dedukowa\u0107 analitycznie, ale nie zawsze jest to trywialne, zw\u0142aszcza je\u015bli zmienne pochodz\u0105 z r\u00f3\u017cnych \u017ar\u00f3de\u0142.<\/p>\n
<\/p>\n
Zatem handlery s\u0105 znacznie mniej przydatne i znacznie bardziej problematyczne, ni\u017c si\u0119 wydaje. Je\u015bli mo\u017cna co\u015b napisa\u0107 \u0142adnie (bez trik\u00f3w) bez handler\u00f3w, lepiej zrobi\u0107 to bez nich. Je\u015bli nie wychodzi \u0142adnie \u2014 lepiej ju\u017c z nimi.<\/p>\n
<\/p>\n
Skrupulatny czytelnik s\u0142usznie zauwa\u017ca, \u017ce nie om\u00f3wili\u015bmy listen<\/code>, \u017ce handler mo\u017ce wywo\u0142a\u0107 notify dla innego handlera, \u017ce handler mo\u017ce zawiera\u0107 import_tasks (kt\u00f3ry mo\u017ce robi\u0107 include_role z with_items), \u017ce system handler\u00f3w w Ansible jest turingowo pe\u0142ny, \u017ce handlery z include_role niezwykle interesuj\u0105co krzy\u017cuj\u0105 si\u0119 z handlerami z play itd. \u2014 to wszystko zdecydowanie nie s\u0105 \"podstawy\".<\/p>\n<\/p>\n
Chocia\u017c jest jeden okre\u015blony WTF, kt\u00f3ry tak naprawd\u0119 jest funkcj\u0105, o kt\u00f3rej nale\u017cy pami\u0119ta\u0107. Je\u015bli masz task, kt\u00f3ry wykonuje si\u0119 z delegate_to<\/code> i ma notify, to odpowiedni handler jest wykonywany bez delegate_to<\/code>, tzn. na ho\u015bcie, na kt\u00f3rym przypisana jest play. (Chocia\u017c handler mo\u017ce mie\u0107 r\u00f3wnie\u017c delegate_to<\/code> to).<\/p>\n<\/p>\n
Osobno chc\u0119 powiedzie\u0107 kilka s\u0142\u00f3w o reusable roles. Do czasu pojawienia si\u0119 kolekcji istnia\u0142a idea, \u017ce mo\u017cna stworzy\u0107 uniwersalne role, kt\u00f3re mo\u017cna ansible-galaxy install<\/code> i pojecha\u0142. Dzia\u0142a na wszystkich systemach operacyjnych w ka\u017cdej sytuacji. Moje zdanie: to nie dzia\u0142a. Ka\u017cda rola z masow\u0105 include_vars<\/code>, wspieraj\u0105c 100500 przypadk\u00f3w, jest skazana na otch\u0142anie bug\u00f3w corner case. Mo\u017cna je zaklepa\u0107 masywnym testowaniem, ale jak z ka\u017cdym testowaniem, albo macie iloczyn kartezja\u0144ski warto\u015bci wej\u015bciowych i funkcj\u0119 totaln\u0105, albo \"pokryte s\u0105 poszczeg\u00f3lne scenariusze\". Moim zdaniem \u2014 znacznie lepiej, gdy rola jest liniowa (z\u0142o\u017cono\u015b\u0107 cyklomatyczna 1).<\/p>\n<\/p>\n
Im mniej if\u00f3w (jawnych lub deklaratywnych \u2014 w formie when<\/code> lub formie include_vars<\/code> na zestaw zmiennych), tym lepiej rola. Czasami trzeba robi\u0107 rozga\u0142\u0119zienia, ale, powtarzam, im ich mniej, tym lepiej. Tak wi\u0119c wydaje si\u0119, \u017ce dobra rola z galaxy (dzia\u0142a przecie\u017c!) z mn\u00f3stwem when<\/code> mo\u017ce by\u0107 mniej preferowana ni\u017c \"w\u0142asna\" rola z pi\u0119ciu zada\u0144. Moment, w kt\u00f3rym rola z galaxy jest lepsza \u2014 to gdy zaczynasz co\u015b pisa\u0107. Moment, w kt\u00f3rym staje si\u0119 gorsza \u2014 to gdy co\u015b si\u0119 psuje i masz podejrzenie, \u017ce to przez \"rol\u0119 z galaxy\". Otwierasz j\u0105, a tam pi\u0119\u0107 inklud\u00f3w, osiem list zada\u0144 i sterta when<\/code>\u2019\u00f3w\u2026 I trzeba si\u0119 w tym ogarn\u0105\u0107. Zamiast 5 zada\u0144 w liniowej li\u015bcie, w kt\u00f3rej nie ma nic do zepsucia.<\/p>\n<\/p>\n
W nast\u0119pnych cz\u0119\u015bciach<\/h1>\n <\/p>\n
\nTroch\u0119 o inwentarzu, grupowych zmiennych, pluginie host_group_vars, hostvars. Jak ze spaghetti zwi\u0105za\u0107 Gordyjski w\u0119ze\u0142. Zakres i priorytet zmiennych, model pami\u0119ci Ansible. \"Gdzie wi\u0119c przechowywa\u0107 nazw\u0119 u\u017cytkownika dla bazy danych?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nosense mi\u0119kka plastelina. Jest wsz\u0119dzie, nawet tam, gdzie si\u0119 go nie spodziewasz. Troch\u0119 o !!unsafe<\/code> i smacznym yaml.<\/li>\n<\/ul>\n\u0179r\u00f3d\u0142o: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f \u0434\u0435\u043b\u0430\u044e \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0432\u044c\u044e \u0434\u043b\u044f \u0447\u0443\u0436\u043e\u0433\u043e \u043a\u043e\u0434\u0430 \u043d\u0430 \u0410\u043d\u0441\u0438\u0431\u043b \u0438 \u043c\u043d\u043e\u0433\u043e \u043f\u0438\u0448\u0443 \u0441\u0430\u043c. \u0412 \u0445\u043e\u0434\u0435 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u043e\u0448\u0438\u0431\u043e\u043a (\u043a\u0430\u043a \u0447\u0443\u0436\u0438\u0445, \u0442\u0430\u043a \u0438 \u0441\u0432\u043e\u0438\u0445), \u0430 \u0442\u0430\u043a \u0436\u0435 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0439, \u044f \u043f\u043e\u043d\u044f\u043b \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u043e\u0448\u0438\u0431\u043a\u0443, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0410\u043d\u0441\u0438\u0431\u043b\u0430 \u2014 \u043e\u043d\u0438 \u043b\u0435\u0437\u0443\u0442 \u0432 \u0441\u043b\u043e\u0436\u043d\u043e\u0435, \u043d\u0435 \u043e\u0441\u0432\u043e\u0438\u0432 \u0431\u0430\u0437\u043e\u0432\u043e\u0433\u043e. \u0414\u043b\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439 \u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u043e\u0439 \u043d\u0435\u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u043e\u0441\u0442\u0438 \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0410\u043d\u0441\u0438\u0431\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87084","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t