Başqalarının Ansible kodunu çoxlu nəzərdən keçirirəm və özüm də çox yazıram. Səhvləri (həm başqalarının, həm də mənim), eləcə də bir sıra müsahibələrin təhlili zamanı Ansible istifadəçilərinin əsas səhvini başa düşdüm - onlar əsasları mənimsəmədən mürəkkəb şeylərə girirlər.

Bu ümumbəşəri ədalətsizliyi düzəltmək üçün mən bunu artıq bilənlər üçün Ansible-a giriş yazmaq qərarına gəldim. Sizə xəbərdarlıq edirəm, bu, kişilərin təkrarı deyil, bu, çoxlu hərflərin və şəkillərin olmadığı uzun oxunuşdur.

Oxucunun gözlənilən səviyyəsi odur ki, artıq bir neçə min sətir yamla yazılıb, nəsə istehsaldadır, amma “nədənsə hər şey əyridir”.

Başlıqlar

Ansible istifadəçisinin etdiyi əsas səhv bir şeyin nə adlandırıldığını bilməməkdir. Əgər adları bilmirsinizsə, sənədlərin nə dediyini başa düşə bilməzsiniz. Canlı bir misal: müsahibə zamanı Ansible-da çox yazdığını deyən adam “bir oyun dəftəri hansı elementlərdən ibarətdir?” sualına cavab verə bilmədi. Mən "cavabın oyun kitabının oyundan ibarət olması gözlənilən idi" deyəndə, "biz bundan istifadə etmirik" lənətə gəlmiş şərh gəldi. İnsanlar pul üçün Ansible yazır və oyundan istifadə etmirlər. Əslində istifadə edirlər, amma nə olduğunu bilmirlər.

Beləliklə, sadə bir şeylə başlayaq: buna nə deyilir. Bəlkə siz bunu bilirsiniz, ya da bilmirsiniz, çünki sənədləri oxuyanda diqqət etməmisiniz.

ansible-playbook oyun kitabını icra edir. Oyun kitabı yml/yaml uzantılı bir fayldır, içərisində belə bir şey var:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Artıq başa düşdük ki, bütün bu fayl bir oyun kitabıdır. Rolların və vəzifələrin harada olduğunu göstərə bilərik. Bəs oyun haradadır? Və oyun və rol və ya oyun kitabı arasındakı fərq nədir?

Hamısı sənədlərdə var. Və darıxırlar. Başlayanlar - çünki çox şey var və hər şeyi bir anda xatırlamayacaqsan. Təcrübəli - çünki "xırda şeylər". Əgər təcrübəlisinizsə, ən azı altı ayda bir dəfə bu səhifələri yenidən oxuyun və kodunuz sinifdə lider olacaq.

Belə ki, unutmayın: Playbook play və ibarət siyahıdır import_playbook.
Bu bir tamaşadır:

- hosts: group1
  roles:
    - role1

və bu da başqa bir oyundur:

- hosts: group2,group3
  tasks:
    - debug:

oyun nədir? Niyə o?

Oyun kitabçası üçün əsas elementdir, çünki oyun və yalnız oyun rolların və/və ya tapşırıqların siyahısını onların yerinə yetirilməli olduğu hostların siyahısı ilə əlaqələndirir. Sənədlərin dərin dərinliklərində qeyd tapa bilərsiniz delegate_to, yerli axtarış plaginləri, şəbəkəyə xüsusi parametrlər, keçid hostları və s. Tapşırıqların yerinə yetirildiyi yeri bir az dəyişdirməyə imkan verirlər. Ancaq, bunu unut. Bu ağıllı variantlardan hər birinin çox xüsusi istifadəsi var və onlar mütləq universal deyillər. Biz isə hər kəsin bilməli və istifadə etməli olduğu əsas şeylərdən danışırıq.

Əgər “bir şey” “bir yerdə” ifa etmək istəyirsinizsə, oyun yazırsınız. Rol deyil. Modullar və nümayəndələrlə bir rol deyil. Siz götürün və oyun yazın. Hansı ki, hostlar sahəsində harada icra olunacağını, rollarda/tapşırıqlarda isə nəyin yerinə yetiriləcəyini qeyd edirsiniz.

Sadə, elə deyilmi? Başqa cür necə ola bilərdi?

İnsanların bunu oyun vasitəsilə deyil, etmək istəyinin olduğu xarakterik məqamlardan biri də “hər şeyi təyin edən rol”dur. İstərdim ki, həm birinci tip serverləri, həm də ikinci tip serverləri konfiqurasiya edən bir rola sahib olmaq istərdim.

Arxetipik bir nümunə monitorinqdir. Mən monitorinqi konfiqurasiya edəcək bir monitorinq roluna sahib olmaq istərdim. Monitorinq rolu monitorinq hostlarına verilir (oynamağa görə). Ancaq belə çıxır ki, monitorinq üçün paketləri izlədiyimiz hostlara çatdırmalıyıq. Niyə nümayəndə istifadə etmirsiniz? Siz həmçinin iptables konfiqurasiya etməlisiniz. nümayəndə? Siz həmçinin monitorinqi aktivləşdirmək üçün DBMS üçün konfiqurasiya yazmalısınız/düzəltməlisiniz. nümayəndə! Yaradıcılıq çatışmırsa, onda bir heyət təşkil edə bilərsiniz include_role qrupların siyahısında çətin filtrdən istifadə edərək iç içə döngədə və içəridə include_role daha çox edə bilərsiniz delegate_to yenidən. Və gedirik...

Yaxşı bir arzu - "hər şeyi edən" tək bir monitorinq roluna sahib olmaq - bizi çox vaxt yalnız bir çıxış yolu olan tam cəhənnəmə aparır: hər şeyi sıfırdan yenidən yazmaq.

Burada səhv harada baş verdi? X hostunda "x" tapşırığını yerinə yetirmək üçün Y hostuna getməli və orada "y" etməli olduğunuzu kəşf etdiyiniz an sadə bir məşq etməli idiniz: gedib oyun yazmalısınız, bu da Y hostunda y edir. “x”ə nəsə əlavə etməyin, onu sıfırdan yazın. Hətta sərt kodlu dəyişənlərlə.

Görünür, yuxarıdakı paraqraflarda hər şey düzgün deyilib. Ancaq bu sizin işiniz deyil! Çünki siz DRY və kitabxanaya bənzər təkrar istifadə edilə bilən kod yazmaq istəyirsiniz və bunun necə ediləcəyinə dair bir üsul axtarmaq lazımdır.

Burada başqa bir ciddi səhv gizlənir. Bir çox layihələri dözülməz şəkildə yazılmışdan (daha yaxşı ola bilər, amma hər şey işləyir və bitirmək asandır) hətta müəllifin də anlaya bilməyəcəyi tam bir dəhşətə çevirən bir səhv. İşləyir, amma Allah heç nəyi dəyişməsin.

Səhv belədir: rol kitabxana funksiyasıdır. Bu bənzətmə o qədər yaxşı başlanğıcları məhv etdi ki, izləmək sadəcə kədərlidir. Rol kitabxana funksiyası deyil. O, hesablamalar apara bilmir və oyun səviyyəsində qərarlar qəbul edə bilmir. Oyunun hansı qərarlar verdiyini xatırlat?

Təşəkkürlər, düz deyirsən. Play hansı hostlarda hansı tapşırıqları və rolları yerinə yetirmək barədə qərar qəbul edir (daha doğrusu, məlumatı ehtiva edir).

Bu qərarı bir rola həvalə etsəniz və hətta hesablamalarla belə, özünüzü (və kodunuzu təhlil etməyə çalışacaq olanı) bədbəxt bir varlığa məhkum edərsiniz. Rol onun harada ifa olunacağına qərar vermir. Bu qərar oyunla verilir. Rol deyilənləri, deyilənləri yerinə yetirir.

Ansible-da proqramlaşdırma niyə təhlükəlidir və COBOL niyə Ansible-dan daha yaxşıdır, biz fəsildə dəyişənlər və jinja haqqında danışacağıq. Hələlik bir şeyi deyək - sizin hesablamalarınızın hər biri qlobal dəyişənlərdəki dəyişikliklərin silinməz izlərini qoyur və siz bununla bağlı heç nə edə bilməzsiniz. İki “iz” kəsişən kimi hər şey yox oldu.

Sıxlıq üçün qeyd: rol, şübhəsiz ki, nəzarət axınına təsir göstərə bilər. Yemək delegate_to və ağlabatan istifadələri var. Yemək meta: end host/play. Amma! Əsasları öyrətdiyimizi xatırlayırsınız? Unutdum delegate_to. Söhbət ən sadə və ən gözəl Ansible kodundan gedir. Hansı ki, oxumaq asandır, yazmaq asandır, sazlamaq asandır, sınaqdan keçirmək asandır və tamamlamaq asandır. Beləliklə, bir daha:

oynayın və yalnız oyun hansı ev sahibinə nəyin icra olunacağına qərar verir.

Bu bölmədə biz oyun və rol arasındakı ziddiyyətlə məşğul olduq. İndi vəzifələr və rol münasibətləri haqqında danışaq.

Tapşırıqlar və rollar

Oynamağı düşünün:

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

Tutaq ki, foo etmək lazımdır. Və belə görünür foo: name=foobar state=present. Bunu hara yazmalıyam? əvvəl? post? Rol yaratmaq?

...Və tapşırıqlar hara getdi?

Yenidən əsaslarla başlayırıq - oyun cihazı. Əgər bu məsələdə üzə çıxsanız, oyundan başqa hər şey üçün əsas götürə bilməzsiniz və nəticəniz "titrək" olacaq.

Cihazı çalın: host direktivi, oynatma özü və ilkin tapşırıqlar üçün parametrlər, tapşırıqlar, rollar, post_tasks bölmələri. Oyun üçün qalan parametrlər indi bizim üçün vacib deyil.

Bölmələrin vəzifə və rollarla sırası: pre_tasks, roles, tasks, post_tasks. Çünki semantik olaraq icra sırası arasındadır tasks и roles aydın deyil, o zaman ən yaxşı təcrübələr bir bölmə əlavə etdiyimizi söyləyir tasks, yalnız olmasa roles... Varsa roles, sonra bütün əlavə tapşırıqlar bölmələrə yerləşdirilir pre_tasks/post_tasks.

Yalnız hər şeyin semantik aydın olması qalır: birinci pre_taskssonra rolessonra post_tasks.

Ancaq hələ də suala cavab verməmişik: modul çağırışı haradadır? foo yaz? Hər modul üçün tam bir rol yazmalıyıq? Yoxsa hər şeyə qalın rol almaq daha yaxşıdır? Və əgər rol deyilsə, o zaman hara yazmalıyam - əvvəl və ya postda?

Bu suallara əsaslandırılmış cavab yoxdursa, bu, intuisiya çatışmazlığının, yəni eyni "sarsıntılı təməllərin" əlamətidir. Gəlin bunu anlayaq. Birincisi, təhlükəsizlik sualı: Əgər oyun varsa pre_tasks и post_tasks (və heç bir vəzifə və ya rol yoxdur), onda ilk tapşırığı yerinə yetirsəm bir şey poza bilər post_tasks Mən onu axıra qədər aparacağam pre_tasks?

Təbii ki, sualın ifadəsi onun qırılacağına işarə edir. Amma dəqiq nə?

... İşləyənlər. Əsasları oxumaq vacib bir faktı ortaya qoyur: bütün işləyicilər hər bölmədən sonra avtomatik olaraq yuyulur. Bunlar. -dən bütün tapşırıqlar pre_tasks, sonra xəbərdar edilən bütün idarəçilər. Sonra bütün rollar və rollarda bildirilmiş bütün işləyicilər yerinə yetirilir. sonra post_tasks və onların idarəçiləri.

Beləliklə, bir tapşırığı buradan sürükləsəniz post_tasks в pre_tasks, onda potensial olaraq işləyici icra edilməzdən əvvəl onu icra edəcəksiniz. məsələn, əgər varsa pre_tasks veb server quraşdırılıb və konfiqurasiya edilib və post_tasks ona bir şey göndərilir, sonra bu tapşırığı bölməyə köçürün pre_tasks "göndərmə" zamanı serverin hələ işləməməsinə və hər şeyin pozulacağına səbəb olacaq.

İndi bir daha fikirləşək ki, bizə nə lazımdır pre_tasks и post_tasks? Məsələn, rolu yerinə yetirməzdən əvvəl lazım olan hər şeyi (işləyicilər də daxil olmaqla) tamamlamaq üçün. A post_tasks bizə rolların icrasının nəticələri ilə işləməyə imkan verəcək (o cümlədən işləyicilər).

Bunun nə olduğunu bizə ağıllı bir Ansible mütəxəssisi söyləyəcək. meta: flush_handlers, amma oyunda bölmələrin icrası qaydasına etibar edə bilsək, niyə flush_handlers lazımdır? Üstəlik, meta: flush_handlers istifadəsi bizə təkrar işləyicilərlə gözlənilməz şeylər verə bilər və istifadə edildikdə bizə qəribə xəbərdarlıqlar verə bilər. when у block və s. Münasib olanı nə qədər yaxşı bilsəniz, "çətin" bir həll üçün bir o qədər çox nüans adlandıra bilərsiniz. Və sadə bir həll - pre/rol/post arasında təbii bölgüdən istifadə - nüanslara səbəb olmur.

Və bizim 'foo'ya qayıdın. Hara qoymalıyam? Əvvəlcədən, postda və ya rollarda? Aydındır ki, bu, foo üçün işləyicinin nəticələrinə ehtiyacımız olub-olmamasından asılıdır. Əgər onlar orada deyillərsə, onda foo-nun nə əvvəl, nə də postda yerləşdirilməsinə ehtiyac yoxdur - bu bölmələrin xüsusi mənası var - kodun əsas hissəsindən əvvəl və sonra tapşırıqları yerinə yetirmək.

İndi "rol və ya tapşırıq" sualının cavabı artıq oyunda olan şeyə gəlir - orada tapşırıqlar varsa, onları tapşırıqlara əlavə etməlisiniz. Əgər rollar varsa, bir rol yaratmaq lazımdır (hətta bir tapşırıqdan da). Nəzərinizə çatdırım ki, vəzifələr və rollar eyni vaxtda istifadə edilmir.

Ansible-ın əsaslarını başa düşmək zövqlə bağlı görünən suallara ağlabatan cavablar verir.

Tapşırıqlar və rollar (ikinci hissə)

İndi bir oyun kitabı yazmağa başlayanda vəziyyəti müzakirə edək. Foo, bar və baz etmək lazımdır. Bu üç vəzifə bir roldur, yoxsa üç rol? Sualı ümumiləşdirmək üçün: rolları yazmağa hansı nöqtədən başlamaq lazımdır? Tapşırıqlar yaza bildiyiniz halda rollar yazmağın nə mənası var?... Rol nədir?

Ən böyük səhvlərdən biri (bu barədə artıq danışmışdım) bir rolun proqramın kitabxanasındakı funksiya kimi olduğunu düşünməkdir. Ümumi funksiya təsviri nə kimi görünür? Daxiletmə arqumentlərini qəbul edir, yan səbəblərlə qarşılıqlı əlaqə qurur, yan təsirlər edir və dəyəri qaytarır.

İndi, diqqət. Bundan rolda nə etmək olar? Siz həmişə yan təsirlər adlandıra bilərsiniz, bu, bütün Ansible-in mahiyyətidir - yan təsirlər yaratmaq. Yan səbəbləri varmı? İbtidai. Ancaq "dəyər keçin və qaytarın" ilə - bu işləmir. Birincisi, siz rola dəyər ötürə bilməzsiniz. Siz rol üçün vars bölməsində ömür boyu oyun ölçüsü ilə qlobal dəyişən təyin edə bilərsiniz. Rol daxilində ömür boyu oynayan qlobal dəyişən təyin edə bilərsiniz. Və ya hətta oyun kitablarının ömrü ilə (set_fact/register). Ancaq "yerli dəyişənlərə" sahib ola bilməzsiniz. Siz "dəyər götürə" və "geri qaytara" bilməzsiniz.

Əsas odur ki, bundan irəli gəlir: yan təsirlərə səbəb olmadan Ansible-da nəsə yaza bilməzsiniz. Qlobal dəyişənlərin dəyişdirilməsi həmişə funksiya üçün yan təsirdir. Rust-da, məsələn, qlobal dəyişənin dəyişdirilməsidir unsafe. Və Ansible-da bu, rolun dəyərlərinə təsir etmək üçün yeganə üsuldur. İstifadə olunan sözlərə diqqət yetirin: "rola dəyər vermək" deyil, "rolun istifadə etdiyi dəyərləri dəyişdirmək". Rollar arasında heç bir təcrid yoxdur. Tapşırıqlar və rollar arasında heç bir təcrid yoxdur.

Ümumi: rol funksiya deyil.

Rolda nə yaxşıdır? Birincisi, rolun standart dəyərləri var (/default/main.yaml), ikincisi, rolun faylları saxlamaq üçün əlavə qovluqları var.

Standart dəyərlərin üstünlükləri nələrdir? Çünki Maslowun piramidasında, Ansible-ın dəyişən prioritetlərinin olduqca təhrif edilmiş cədvəlində, rol defoltları ən aşağı prioritetdir (mənfi Ansible əmr satırı parametrləri). Bu o deməkdir ki, əgər siz standart dəyərlər təqdim etməlisinizsə və onların inventar və ya qrup dəyişənlərindən olan dəyərləri üstələməkdən narahat olmasanız, o zaman rol defoltları sizin üçün yeganə düzgün yerdir. (Bir az yalan deyirəm - daha çox var |d(your_default_here), lakin stasionar yerlərdən danışsaq, onda yalnız rolun defoltları).

Rollarda başqa nə gözəldir? Çünki onların öz kataloqları var. Bunlar həm sabit (yəni, rol üçün hesablanmış) həm də dinamik dəyişənlər üçün qovluqlardır (ya nümunə, ya da anti-naxış var - include_vars ilə birlikdə {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Bunlar üçün kataloqlar files/, templates/. Həmçinin, bu, öz modullarınız və plaginlərinizə (library/). Ancaq bir oyun kitabındakı (bütün bunlar da ola bilər) tapşırıqlarla müqayisədə burada yeganə fayda, faylların bir yığına deyil, bir neçə ayrı yığına atılmasıdır.

Daha bir təfərrüat: təkrar istifadə oluna biləcək rollar yaratmağa cəhd edə bilərsiniz (qalaktika vasitəsilə). Kolleksiyaların meydana çıxması ilə rol bölgüsü demək olar ki, unudulmuş hesab edilə bilər.

Beləliklə, rolların iki mühüm xüsusiyyəti var: onların standartları var (unikal xüsusiyyət) və onlar sizə kodunuzu strukturlaşdırmağa imkan verir.

Orijinal suala qayıdaq: tapşırıqları nə vaxt yerinə yetirməli və rolları nə vaxt yerinə yetirməli? Oyun kitabındakı tapşırıqlar ən çox ya rollardan əvvəl/sonra “yapışqan” kimi, ya da müstəqil tikinti elementi kimi istifadə olunur (sonra kodda heç bir rol olmamalıdır). Rollarla qarışan normal tapşırıqların yığını birmənalı səliqəsizlikdir. Müəyyən bir üsluba riayət etməlisiniz - ya bir vəzifə, ya da bir rol. Rollar obyektlərin və defoltların ayrılmasını təmin edir, tapşırıqlar kodu daha sürətli oxumağa imkan verir. Adətən, rollara daha çox “stasionar” (vacib və mürəkkəb) kodlar qoyulur və köməkçi skriptlər tapşırıq üslubunda yazılır.

Tapşırıq olaraq import_role etmək mümkündür, lakin bunu yazsanız, o zaman öz gözəllik hissinizə bunu niyə etmək istədiyinizi izah etməyə hazır olun.

Ağıllı oxucu deyə bilər ki, rollar rolları idxal edə bilər, rolların galaxy.yml vasitəsilə asılılıqları ola bilər, həmçinin dəhşətli və dəhşətli bir şey də var. include_role — Xatırladıram ki, biz fiqurlu gimnastikada yox, əsas Ansible üzrə bacarıqlarımızı artırırıq.

İşləyənlər və tapşırıqlar

Başqa bir aşkar şeyi müzakirə edək: işləyicilər. Onları düzgün istifadə etməyi bilmək, demək olar ki, bir sənətdir. İşləyici ilə sürükləmə arasındakı fərq nədir?

Əsasları xatırladığımız üçün burada bir nümunə var:

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

Rolu idarə edənlər rolename/handlers/main.yaml ünvanında yerləşir. İşləyicilər bütün oyun iştirakçıları arasında dolaşırlar: pre/post_tasks rolu idarə edənləri çəkə bilər və rol işləyiciləri oyundan kənarlaşdıra bilər. Bununla belə, işləyicilərə "çarpaz rol" zəngləri əhəmiyyətsiz işləyicinin təkrarlanmasından daha çox wtf-yə səbəb olur. (Ən yaxşı təcrübələrin digər elementi işləyici adlarını təkrarlamamağa çalışmaqdır).

Əsas fərq, tapşırığın həmişə (idempotently) yerinə yetirilməsidir (plus/minus etiketləri və when), və işləyici - vəziyyət dəyişikliyi ilə (yalnız dəyişdirildikdə yanğınları xəbərdar edin). Bu nə deməkdir? Məsələn, yenidən başlatdığınız zaman heç bir dəyişiklik olmasaydı, işləyici olmayacaqdır. Yaratma tapşırığında heç bir dəyişiklik olmadıqda niyə işləyicini icra etməmiz lazım ola bilər? Məsələn, bir şey qırıldı və dəyişdi, amma icra işləyiciyə çatmadı. Məsələn, şəbəkə müvəqqəti olaraq bağlandığından. Konfiqurasiya dəyişdi, xidmət yenidən işə salınmadı. Növbəti dəfə onu işə saldıqda konfiqurasiya artıq dəyişmir və xidmət konfiqurasiyanın köhnə versiyasında qalır.

Konfiqurasiya ilə bağlı vəziyyəti həll etmək mümkün deyil (daha doğrusu, siz özünüz fayl bayraqları və s. ilə xüsusi yenidən başlatma protokolu icad edə bilərsiniz, lakin bu, artıq heç bir formada "əsas mümkün" deyil). Ancaq başqa bir ümumi hekayə var: proqramı quraşdırdıq, qeyd etdik .service-fayl və indi biz onu istəyirik daemon_reload и state=started. Və bunun üçün təbii yer işləyici kimi görünür. Ancaq onu işləyici deyil, tapşırıq siyahısının və ya rolun sonunda bir tapşırıq etsəniz, o, hər dəfə qeyri-müəyyən şəkildə yerinə yetiriləcəkdir. Oyun dəftəri ortada qırılsa belə. Bu, yenidən işə salınmış problemi qətiyyən həll etmir (yenidən işə salınmış atributla bir tapşırığı yerinə yetirə bilməzsiniz, çünki qeyri-müəyyənlik itirilir), lakin mütləq vəziyyət = started etməyə dəyər, oyun kitablarının ümumi sabitliyi artır, çünki birləşmələrin sayı və dinamik vəziyyət azalır.

İşləyicinin başqa bir müsbət xüsusiyyəti, çıxışı tıxanmamasıdır. Dəyişikliklər yox idi - heç bir əlavə atlanma və ya çıxışda tamam - oxumaq daha asandır. Bu, həm də mənfi xüsusiyyətdir - əgər siz xətti şəkildə yerinə yetirilən tapşırığı ilk işə saldıqda səhv tapsanız, o zaman işləyicilər yalnız dəyişdirildikdə yerinə yetiriləcək, yəni. bəzi şərtlərdə - çox nadir hallarda. Məsələn, beş ildən sonra həyatımda ilk dəfə. Və təbii ki, adda hərf səhvi olacaq və hər şey pozulacaq. Onları ikinci dəfə işlətməsəniz, heç bir dəyişiklik yoxdur.

Ayrı-ayrılıqda, dəyişənlərin mövcudluğu haqqında danışmaq lazımdır. Məsələn, bir tapşırığı dövrə ilə xəbərdar etsəniz, dəyişənlərdə nə olacaq? Siz analitik olaraq təxmin edə bilərsiniz, lakin bu, həmişə əhəmiyyətsiz deyil, xüsusən də dəyişənlər müxtəlif yerlərdən gəlirsə.

... Beləliklə, işləyicilər göründüklərindən daha az faydalı və daha problemlidirlər. İşləyicilər olmadan gözəl bir şey yaza bilsəniz (frillless), onsuz bunu etmək daha yaxşıdır. Əgər gözəl nəticə vermirsə, onlarla daha yaxşıdır.

Aşındırıcı oxucu haqlı olaraq qeyd edir ki, biz müzakirə etməmişik listenbir işləyicinin başqa bir işləyici üçün bildiriş çağıra biləcəyini, işləyicinin import_taskları daxil edə biləcəyini (bunlar with_items ilə rolu daxil edə bilər), Ansible-dəki işləyici sisteminin Turing-complete olduğunu, include_role-un işləyicilərinin oyundan idarəedicilərlə maraqlı şəkildə kəsişdiyini, və s. .d. - bütün bunlar açıq şəkildə "əsaslar" deyil).

Baxmayaraq ki, yadda saxlamağınız lazım olan bir xüsusiyyət olan bir xüsusi WTF var. Əgər tapşırığınız yerinə yetirilirsə delegate_to və xəbərdar etdi, sonra müvafiq işləyici olmadan icra olunur delegate_to, yəni. oyunun təyin olunduğu hostda. (Baxmayaraq ki, işləyici, əlbəttə ki, ola bilər delegate_to Eyni).

Ayrı-ayrılıqda təkrar istifadə edilə bilən rollar haqqında bir neçə söz demək istəyirəm. Kolleksiyalar görünməzdən əvvəl, ola biləcək universal rolları edə biləcəyiniz bir fikir var idi ansible-galaxy install və getdi. Bütün hallarda bütün variantların bütün ƏS-lərində işləyir. Beləliklə, mənim fikrim: işləmir. Kütləvi hər hansı bir rol include_vars, 100500 işi dəstəkləyən, künc işi səhvlərinin uçuruma məhkumdur. Onlar kütləvi testlərlə bağlana bilər, lakin hər hansı bir testdə olduğu kimi, ya giriş dəyərlərinin və ümumi funksiyanın Kartezian məhsuluna sahibsiniz, ya da "fərdi ssenariləri əhatə edirsiniz". Mənim fikrimcə, rolun xətti (siklomatik mürəkkəblik 1) olması daha yaxşıdır.

Daha az if (açıq və ya bəyanedici - formada when və ya forma include_vars dəyişənlər dəsti ilə), rol daha yaxşı olar. Bəzən budaqlar etmək lazımdır, amma təkrar edirəm, nə qədər az olsa, bir o qədər yaxşıdır. Beləliklə, qalaktika ilə yaxşı bir rol kimi görünür (işləyir!) Bir dəstə ilə when beş tapşırıqdan “özünün” rolundan daha az üstünlük təşkil edə bilər. Qalaktikada rolun daha yaxşı olduğu an nəsə yazmağa başladığın zamandır. Vəziyyətin daha da pisləşdiyi an, bir şeyin qırıldığı və bunun "qalaktika ilə rolu" ilə əlaqədar olduğuna şübhə etdiyiniz zamandır. Siz onu açırsınız və orada beş daxiletmə, səkkiz tapşırıq vərəqi və bir yığın var when'ov... Və bunu başa düşməliyik. 5 tapşırığın əvəzinə, pozulacaq heç bir şey olmayan xətti bir siyahı.

Növbəti hissələrdə

• İnventar, qrup dəyişənləri, host_group_vars plagini, hostvarlar haqqında bir az. Gordian düyünü spagetti ilə necə bağlamaq olar. Əhatə dairəsi və üstünlük dəyişənləri, Ansible yaddaş modeli. "Bəs verilənlər bazası üçün istifadəçi adını harada saxlayırıq?"
• jinja: {{ jinja }} — nosql notype nosense yumşaq plastilin. Hər yerdə, hətta gözləmədiyiniz yerdə də var. Bir az haqqında !!unsafe və ləzzətli yam.

Mənbə: www.habr.com