Men boshqa odamlarning Ansible kodini ko'p sharhlayman va o'zim ham ko'p yozaman. Xatolarni (boshqa odamlarning ham, meniki ham), shuningdek, bir qator intervyularni tahlil qilish jarayonida men Ansible foydalanuvchilari qiladigan asosiy xatoni angladim - ular asosiy narsalarni o'zlashtirmasdan murakkab narsalarga kirishadilar.

Ushbu umumbashariy adolatsizlikni tuzatish uchun men buni allaqachon biladiganlar uchun Ansible-ga kirish yozishga qaror qildim. Ogohlantirishim kerakki, bu odamlarning hikoyasi emas, bu juda ko'p harflar va rasmlarsiz uzoq o'qish.

O'quvchining kutilgan darajasi shundan iboratki, bir necha ming satr yamla allaqachon yozilgan, nimadir ishlab chiqarilmoqda, lekin "qandaydir hammasi egri".

Sarlavhalar

Ansible foydalanuvchisining asosiy xatosi nimadir deb atalishini bilmaslikdir. Agar siz nomlarni bilmasangiz, hujjatlarda nima deyilganini tushunolmaysiz. Jonli misol: intervyu paytida Ansible-da ko'p yozganman degan odam "o'yin kitobi qanday elementlardan iborat?" Degan savolga javob bera olmadi. Va men "javob o'yin kitobi o'yindan iborat bo'lishi kutilgan edi" deb taklif qilganimda, "biz bundan foydalanmaymiz" degan la'natli izoh keldi. Odamlar Ansibleni pul uchun yozadilar va o'yindan foydalanmaydilar. Ular aslida undan foydalanishadi, lekin nima ekanligini bilishmaydi.

Keling, oddiy narsadan boshlaylik: u nima deb ataladi? Ehtimol, siz buni bilasiz yoki bilmaysiz, chunki siz hujjatlarni o'qiyotganingizda e'tibor bermadingiz.

ansible-playbook o'yin kitobini bajaradi. O'yin kitobi yml/yaml kengaytmali fayl bo'lib, uning ichida shunday narsa mavjud:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Biz allaqachon bu faylning o'yin kitobi ekanligini angladik. Biz rollar va vazifalar qayerda ekanligini ko'rsatishimiz mumkin. Ammo o'yin qayerda? Va o'yin va rol yoki o'yin kitobi o'rtasidagi farq nima?

Hammasi hujjatlarda. Va ular buni sog'inadilar. Yangi boshlanuvchilar - chunki juda ko'p va siz bir vaqtning o'zida hamma narsani eslay olmaysiz. Tajribali - chunki "arzimas narsalar". Agar tajribangiz bo'lsa, kamida olti oyda bir marta ushbu sahifalarni qayta o'qing va sizning kodingiz sinfda etakchi bo'ladi.

Shunday qilib, esda tuting: Playbook - bu o'yin va dan iborat ro'yxat import_playbook.
Bu bitta o'yin:

- hosts: group1
  roles:
    - role1

va bu yana bir o'yin:

- hosts: group2,group3
  tasks:
    - debug:

O'yin nima? Nega u?

O'yin o'yin kitobining asosiy elementidir, chunki o'yin va faqat o'yin rollar va/yoki vazifalar ro'yxatini ular bajarilishi kerak bo'lgan xostlar ro'yxati bilan bog'laydi. Hujjatlarning chuqur chuqurlarida siz eslatib o'tishingiz mumkin delegate_to, mahalliy qidirish plaginlari, tarmoqqa xos sozlamalar, o'tish xostlari va boshqalar. Ular sizga vazifalar bajariladigan joyni biroz o'zgartirishga imkon beradi. Ammo, bu haqda unuting. Ushbu aqlli variantlarning har biri juda aniq foydalanishga ega va ular, albatta, universal emas. Va biz hamma bilishi va ishlatishi kerak bo'lgan asosiy narsalar haqida gapiramiz.

Agar siz "biror joyda" "biror narsa" ni bajarmoqchi bo'lsangiz, o'yin yozasiz. Rol emas. Modullar va delegatlar bilan rol emas. Siz uni olib, o'yin yozasiz. Xostlar maydonida siz qayerda bajarilishini va rollar/vazifalarda - nima bajarilishi kerakligini ko'rsatasiz.

Oddiy, to'g'rimi? Qanday qilib boshqacha bo'lishi mumkin?

Odamlar buni o'yin orqali emas, balki qilishni xohlaydigan xarakterli daqiqalardan biri bu "hamma narsani o'rnatadigan rol". Men birinchi turdagi serverlarni va ikkinchi turdagi serverlarni sozlaydigan rolga ega bo'lishni xohlayman.

Arxetipik misol - monitoring. Men monitoringni sozlaydigan monitoring roliga ega bo'lishni xohlayman. Monitoring roli monitoring xostlariga beriladi (o'ynashga ko'ra). Ammo ma'lum bo'lishicha, monitoring uchun biz kuzatayotgan hostlarga paketlarni etkazib berishimiz kerak. Nega delegatdan foydalanmaslik kerak? Shuningdek, iptables-ni sozlashingiz kerak. delegat? Shuningdek, monitoringni yoqish uchun DBMS konfiguratsiyasini yozish/tuzatish kerak. delegat! Va agar ijodkorlik etishmayotgan bo'lsa, unda siz delegatsiya qilishingiz mumkin include_role guruhlar ro'yxatida va ichkarida murakkab filtrdan foydalangan holda ichkariga kiritilgan tsiklda include_role ko'proq qila olasiz delegate_to yana. Va biz ketamiz ...

Yaxshi istak - "hamma narsani bajaradigan" bitta nazorat roliga ega bo'lish - bizni to'liq do'zaxga olib boradi, undan chiqishning bitta yo'li bor: hamma narsani noldan qayta yozish.

Bu erda xato qayerda sodir bo'ldi? X xostidagi "x" vazifasini bajarish uchun Y xostiga borib, u yerda "y" ni bajarish kerakligini bilganingizdan so'ng, siz oddiy mashq bajarishingiz kerak edi: borib o'yin yozishingiz kerak, bu esa Y hostida y qiladi. "X" ga biror narsa qo'shmang, lekin uni noldan yozing. Hatto qattiq kodlangan o'zgaruvchilar bilan ham.

Yuqoridagi paragraflarda hamma narsa to'g'ri aytilganga o'xshaydi. Ammo bu sizning holatingiz emas! Chunki siz DRY va kutubxonaga o'xshash qayta foydalanish mumkin bo'lgan kod yozmoqchisiz va buni qanday qilish usulini izlashingiz kerak.

Bu erda yana bir jiddiy xato yashiringan. Ko'pgina loyihalarni chidab bo'lmas tarzda yozilgandan (yaxshiroq bo'lishi mumkin, lekin hamma narsa ishlaydi va tugatish oson) to'liq dahshatga aylantirgan xato, hatto muallif ham tushunolmaydi. Bu ishlaydi, lekin Xudo sizni hech narsani o'zgartirishdan saqlasin.

Xato: rol kutubxona funktsiyasidir. Bu o'xshatish juda ko'p yaxshi boshlanishlarni buzdiki, tomosha qilish juda achinarli. Rol kutubxona funktsiyasi emas. U hisob-kitoblarni qila olmaydi va o'yin darajasida qarorlar qabul qila olmaydi. Eslatib o'tamiz, o'yin qanday qarorlar qabul qiladi?

Rahmat, siz haqsiz. O'yin qaysi hostlarda qanday vazifalar va rollarni bajarish haqida qaror qabul qiladi (aniqrog'i, unda ma'lumot mavjud).

Agar siz ushbu qarorni rolga topshirsangiz va hatto hisob-kitoblar bilan ham, siz o'zingizni (va sizning kodingizni tahlil qilishga harakat qiladigan odamni) baxtsiz hayotga mahkum qilasiz. Rol qaerda ijro etilishini hal qilmaydi. Bu qaror o'yin orqali qabul qilinadi. Rol aytilganini, aytilgan joyini bajaradi.

Nima uchun Ansible-da dasturlash xavfli va nima uchun COBOL Ansible-dan yaxshiroq, biz o'zgaruvchilar va jinja haqida bobda gaplashamiz. Hozircha bitta narsani aytaylik - sizning har bir hisob-kitobingiz global o'zgaruvchilardagi o'zgarishlarning o'chmas izini qoldiradi va siz bu haqda hech narsa qila olmaysiz. Ikki "iz" kesishishi bilanoq, hamma narsa yo'qoldi.

Qattiqqo'llik uchun eslatma: rol, albatta, boshqaruv oqimiga ta'sir qilishi mumkin. Yemoq delegate_to va u oqilona foydalanishga ega. Yemoq meta: end host/play. Lekin! Esingizdami, biz asoslarni o'rgatamiz? Unutgan delegate_to. Biz eng oddiy va eng chiroyli Ansible kodi haqida gapiramiz. O'qish oson, yozish oson, disk raskadrovka qilish oson, sinab ko'rish va bajarish oson. Shunday qilib, yana bir bor:

o'ynang va faqat o'yin qaysi mezbonlar nima bajarilishini hal qiladi.

Ushbu bo'limda biz o'yin va rol o'rtasidagi qarama-qarshilikni ko'rib chiqdik. Endi vazifalar va rol munosabatlari haqida gapiraylik.

Vazifalar va rollar

O'yinni ko'rib chiqing:

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

Aytaylik, sizga foo qilish kerak. Va shunday ko'rinadi foo: name=foobar state=present. Buni qayerga yozishim kerak? oldin? post? Rol yaratilsinmi?

...Vazifalar qayerga ketdi?

Biz yana asoslardan boshlaymiz - o'yin qurilmasi. Agar siz bu masalada suzsangiz, boshqa hamma narsa uchun o'yinni asos sifatida ishlata olmaysiz va natijangiz "silkinish" bo'ladi.

Qurilmani o'ynatish: xostlar direktivasi, o'ynashning o'zi va oldingi_vazifalar uchun sozlamalar, vazifalar, rollar, post_tasks bo'limlari. O'yin uchun qolgan parametrlar hozir biz uchun muhim emas.

Bo'limlarning vazifalari va rollari bilan tartibi: pre_tasks, roles, tasks, post_tasks. Semantik jihatdan bajarilish tartibi o'rtasida bo'lgani uchun tasks и roles aniq emas, keyin eng yaxshi amaliyotlar biz bo'lim qo'shayotganimizni aytadi tasks, faqat bo'lmasa roles... Agar bo'lsa roles, keyin barcha biriktirilgan vazifalar bo'limlarga joylashtiriladi pre_tasks/post_tasks.

Qolgan narsa shundaki, hamma narsa semantik jihatdan aniq: birinchi pre_tasks, keyin roles, keyin post_tasks.

Lekin biz hali ham savolga javob bermadik: modul chaqiruvi qayerda? foo yozing? Har bir modul uchun butun rolni yozishimiz kerakmi? Yoki hamma narsa uchun qalin rolga ega bo'lish yaxshiroqmi? Agar rol bo'lmasa, qayerga yozishim kerak - oldingi yoki postda?

Agar bu savollarga asosli javob bo'lmasa, bu sezgi yo'qligining belgisi, ya'ni o'sha "silkinish asoslar". Keling, buni aniqlaylik. Birinchidan, xavfsizlik savoli: Agar o'yin mavjud bo'lsa pre_tasks и post_tasks (va vazifalar yoki rollar yo'q), agar men birinchi vazifani bajarsam, biror narsa buzilishi mumkin post_tasks Men uni oxirigacha ko'chiraman pre_tasks?

Albatta, savolning matni uning buzilishiga ishora qiladi. Lekin aniq nima?

... Ishlovchilar. Asosiy ma'lumotlarni o'qish muhim haqiqatni ochib beradi: barcha ishlov beruvchilar har bir bo'limdan keyin avtomatik ravishda tozalanadi. Bular. dan barcha vazifalar pre_tasks, keyin xabar qilingan barcha ishlov beruvchilar. Keyin barcha rollar va rollarda bildirilgan barcha ishlov beruvchilar bajariladi. Keyin post_tasks va ularning boshqaruvchilari.

Shunday qilib, agar siz vazifani tortib olsangiz post_tasks в pre_tasks, keyin potentsial ravishda ishlov beruvchi bajarilishidan oldin uni bajarasiz. masalan, agar mavjud bo'lsa pre_tasks veb-server o'rnatilgan va sozlangan, va post_tasks unga biror narsa yuboriladi, keyin bu vazifani bo'limga o'tkazing pre_tasks "yuborish" vaqtida server hali ishlamayotganiga va hamma narsa buzilib ketishiga olib keladi.

Endi yana o'ylab ko'raylik, bizga nima uchun kerak pre_tasks и post_tasks? Masalan, rolni bajarishdan oldin zarur bo'lgan hamma narsani (shu jumladan ishlov beruvchilarni) bajarish uchun. A post_tasks rollarni bajarish natijalari (jumladan, ishlovchilar) bilan ishlashga imkon beradi.

Ansiblening aqlli mutaxassisi bizga nima ekanligini aytib beradi. meta: flush_handlers, lekin agar biz o'yindagi bo'limlarni bajarish tartibiga tayansak, nima uchun bizga flush_handlers kerak? Bundan tashqari, meta: flush_handlers dan foydalanish bizga takroriy ishlov beruvchilar bilan kutilmagan narsalarni berishi mumkin va foydalanilganda bizga g'alati ogohlantirishlar beradi. when у block va hokazo. Mumkin bo'lgan narsani qanchalik yaxshi bilsangiz, "hiyla" yechim uchun ko'proq nuanslarni nomlashingiz mumkin. Va oddiy yechim - oldingi/rollar/post o'rtasidagi tabiiy bo'linishdan foydalanish - nuanslarga olib kelmaydi.

Va bizning "foo" ga qayting. Uni qaerga qo'yishim kerak? Oldin, post yoki rollardami? Shubhasiz, bu foo uchun ishlov beruvchining natijalari kerakmi yoki yo'qligiga bog'liq. Agar ular yo'q bo'lsa, foo ni ham oldingi, ham keyingi qismga joylashtirish shart emas - bu bo'limlar alohida ma'noga ega - kodning asosiy qismidan oldin va keyin vazifalarni bajarish.

Endi "rol yoki vazifa" degan savolga javob allaqachon o'yinda bo'lgan narsaga to'g'ri keladi - agar u erda vazifalar bo'lsa, ularni vazifalarga qo'shishingiz kerak. Agar rollar mavjud bo'lsa, siz rol yaratishingiz kerak (hatto bitta vazifadan ham). Sizga shuni eslatib o'tamanki, vazifalar va rollar bir vaqtning o'zida ishlatilmaydi.

Ansible asoslarini tushunish ta'mga oid ko'rinadigan savollarga oqilona javob beradi.

Vazifalar va rollar (ikkinchi qism)

Endi siz o'yin kitobini yozishni boshlayotgan vaziyatni muhokama qilaylik. Siz foo, bar va baz qilishingiz kerak. Bu uchta vazifa, bitta rolmi yoki uchta rolmi? Savolni umumlashtirish uchun: rollarni yozishni qaysi nuqtadan boshlash kerak? Vazifalarni yozish mumkin ekan, rollarni yozishning nima keragi bor?... Rol nima?

Eng katta xatolardan biri (men bu haqda allaqachon gapirganman) bu rolni dastur kutubxonasidagi funktsiyaga o'xshash deb o'ylashdir. Umumiy funktsiya tavsifi nimaga o'xshaydi? U kirish argumentlarini qabul qiladi, yon sabablar bilan o'zaro ta'sir qiladi, yon ta'sir qiladi va qiymatni qaytaradi.

Endi, diqqat. Bundan rolda nima qilish mumkin? Siz har doim nojo'ya ta'sirlarni chaqirishingiz mumkin, bu butun Ansiblening mohiyati - yon ta'sirlarni yaratish. Yon sabablari bormi? Boshlang'ich. Ammo "qiymatni o'tkazing va uni qaytaring" bilan - bu ishlamaydi. Birinchidan, siz rolga qiymat o'tkaza olmaysiz. Rol uchun vars bo'limida umr bo'yi o'ynash hajmi bilan global o'zgaruvchini o'rnatishingiz mumkin. Rol ichida umr bo'yi o'ynaladigan global o'zgaruvchini o'rnatishingiz mumkin. Yoki o'yin kitoblarining butun umri bilan ham (set_fact/register). Lekin sizda "mahalliy o'zgaruvchilar" bo'lishi mumkin emas. Siz "qiymatni qabul qila olmaysiz" va "qaytara olmaysiz".

Bundan asosiy narsa kelib chiqadi: siz Ansible-da nojo'ya ta'sirlarsiz biror narsa yozolmaysiz. Global o'zgaruvchilarni o'zgartirish har doim funktsiya uchun yon ta'sirdir. Rustda, masalan, global o'zgaruvchini o'zgartirish unsafe. Va Ansible-da bu rol uchun qiymatlarga ta'sir qilishning yagona usuli. Ishlatilgan so'zlarga e'tibor bering: "rolga qiymat berish" emas, balki "rol foydalanadigan qiymatlarni o'zgartirish". Rollar o'rtasida hech qanday izolyatsiya yo'q. Vazifalar va rollar o'rtasida hech qanday izolyatsiya yo'q.

Jami: rol funksiya emas.

Rolning nimasi yaxshi? Birinchidan, rol standart qiymatlarga ega (/default/main.yaml), ikkinchidan, rolda fayllarni saqlash uchun qo'shimcha kataloglar mavjud.

Standart qiymatlarning qanday afzalliklari bor? Maslou piramidasida, Ansible-ning o'zgarmaydigan ustuvorliklarining ancha buzilgan jadvalida rolning sukut bo'yicha parametrlari eng past ustuvor hisoblanadi (minus Ansible buyruq qatori parametrlari). Bu shuni anglatadiki, agar siz standart qiymatlarni taqdim etishingiz kerak bo'lsa va ular inventar yoki guruh o'zgaruvchilari qiymatlarini bekor qilish haqida tashvishlanmasangiz, unda rolning standart sozlamalari siz uchun yagona to'g'ri joydir. (Men bir oz yolg'on gapiryapman - ko'proq bor |d(your_default_here), lekin agar biz statsionar joylar haqida gapiradigan bo'lsak, unda faqat rol standarti).

Rollarda yana nima ajoyib? Chunki ularning o‘z kataloglari bor. Bu o'zgaruvchilar uchun kataloglar, ham doimiy (ya'ni rol uchun hisoblangan) va dinamik (naqsh yoki anti-naqsh mavjud - include_vars bilan birga {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Bular uchun kataloglar files/, templates/. Bundan tashqari, bu sizga o'z modullari va plaginlariga ega bo'lish imkonini beradi (library/). Ammo, o'yin kitobidagi vazifalar bilan solishtirganda (bularning barchasi ham bo'lishi mumkin), bu erda yagona afzallik shundaki, fayllar bitta qoziqqa emas, balki bir nechta alohida qoziqlarga tashlanadi.

Yana bir tafsilot: siz qayta foydalanish mumkin bo'lgan rollarni yaratishga harakat qilishingiz mumkin (galaktika orqali). To'plamlarning paydo bo'lishi bilan rollarni taqsimlash deyarli unutilgan deb hisoblanishi mumkin.

Shunday qilib, rollar ikkita muhim xususiyatga ega: ular standart sozlamalarga ega (noyob xususiyat) va ular sizning kodingizni tuzishga imkon beradi.

Asl savolga qaytish: vazifalarni qachon va qachon rollarni bajarish kerak? O'yin kitobidagi vazifalar ko'pincha rollardan oldin / keyin "elim" yoki mustaqil qurilish elementi sifatida ishlatiladi (keyin kodda rollar bo'lmasligi kerak). Rollar bilan aralashtirilgan oddiy vazifalar to'plami - bu aniq beqarorlik. Siz ma'lum bir uslubga rioya qilishingiz kerak - vazifa yoki rol. Rollar ob'ektlar va standart sozlamalarni ajratishni ta'minlaydi, vazifalar kodni tezroq o'qishga imkon beradi. Odatda, rollarga ko'proq "statsionar" (muhim va murakkab) kod qo'yiladi va yordamchi skriptlar vazifa uslubida yoziladi.

Import_role vazifani bajarish mumkin, lekin agar siz buni yozsangiz, o'zingizning go'zallik tuyg'usingizga nima uchun buni qilishni xohlayotganingizni tushuntirishga tayyor bo'ling.

Aqlli o'quvchi rollar rollarni import qilishi mumkin, rollar galaxy.yml orqali bog'liq bo'lishi mumkin, shuningdek, dahshatli va dahshatli narsa borligini aytishi mumkin. include_role — Eslatib o‘tamiz, biz figurali gimnastika bo‘yicha emas, balki asosiy Ansible bo‘yicha mahoratimizni oshirmoqdamiz.

Ishtirokchilar va vazifalar

Keling, yana bir aniq narsani muhokama qilaylik: ishlov beruvchilar. Ulardan to'g'ri foydalanishni bilish deyarli san'atdir. Ishlovchi va tortuvchi o'rtasidagi farq nima?

Biz asoslarni eslayotganimiz sababli, bu erda bir misol:

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

Rol ishlovchilari rolename/handlers/main.yaml da joylashgan. Ishtirokchilar barcha o'yin ishtirokchilari o'rtasida ovora bo'ladilar: pre/post_tasks rollarni ishlovchilarni tortib olishi mumkin va rol o'yindan ishlovchilarni tortib olishi mumkin. Biroq, ishlov beruvchilarga "o'zaro rolli" qo'ng'iroqlar ahamiyatsiz ishlov beruvchini takrorlashdan ko'ra ko'proq wtfga olib keladi. (Eng yaxshi amaliyotlarning yana bir elementi ishlov beruvchi nomlarini takrorlamaslikka harakat qilishdir).

Asosiy farq shundaki, vazifa har doim (idempotently) bajariladi (ortiqcha/minus teglar va when), va ishlov beruvchi - holat o'zgarishi bo'yicha (faqat o'zgartirilgan bo'lsa, yong'inlarga xabar bering). Bu qanday ma'nono bildiradi? Masalan, qayta ishga tushirganingizda, agar o'zgarishlar bo'lmasa, ishlov beruvchi bo'lmaydi. Nima uchun ishlab chiqarish vazifasida hech qanday o'zgarish bo'lmasa, biz ishlov beruvchini bajarishimiz kerak bo'lishi mumkin? Masalan, biror narsa buzilgan va o'zgarganligi sababli, lekin ijro etuvchiga etib bormagan. Masalan, tarmoq vaqtincha ishlamay qolganligi sababli. Konfiguratsiya o'zgartirildi, xizmat qayta ishga tushirilmadi. Keyingi safar uni ishga tushirganingizda, konfiguratsiya endi o'zgarmaydi va xizmat konfiguratsiyaning eski versiyasida qoladi.

Konfiguratsiya bilan bog'liq vaziyatni hal qilib bo'lmaydi (aniqrog'i, siz o'zingiz uchun fayl bayroqlari va boshqalar bilan maxsus qayta ishga tushirish protokolini ixtiro qilishingiz mumkin, ammo bu endi hech qanday shaklda "asosiy" emas). Ammo yana bir umumiy voqea bor: biz dasturni o'rnatdik, uni yozib oldik .service-fayl, va endi biz buni xohlaymiz daemon_reload и state=started. Va buning uchun tabiiy joy ishlov beruvchiga o'xshaydi. Ammo agar siz uni ishlov beruvchi emas, balki vazifalar roʻyxati yoki rol oxiridagi vazifa qilib qoʻysangiz, u har safar identifikatsiyasiz bajariladi. O'yin kitobi o'rtada singan bo'lsa ham. Bu qayta ishga tushirilgan muammoni umuman hal qilmaydi (qayta ishga tushirilgan atribut bilan vazifani bajara olmaysiz, chunki idempotentsiya yo'qoladi), lekin bu, albatta, davlat=started ni bajarishga arziydi, o'yin kitoblarining umumiy barqarorligi oshadi, chunki ulanishlar soni va dinamik holat kamayadi.

Ishlovchining yana bir ijobiy xususiyati shundaki, u chiqishni to'sib qo'ymaydi. Hech qanday o'zgarishlar yo'q - hech qanday qo'shimcha o'tkazib yuborilmagan yoki chiqishda OK - o'qish osonroq. Bu ham salbiy xususiyatdir - agar siz birinchi ishga tushirishda chiziqli bajarilgan vazifada matn terish xatosini topsangiz, ishlov beruvchilar faqat o'zgartirilganda bajariladi, ya'ni. ba'zi sharoitlarda - juda kamdan-kam hollarda. Misol uchun, besh yildan keyin hayotimda birinchi marta. Va, albatta, nomda xato bo'ladi va hamma narsa buziladi. Va agar siz ularni ikkinchi marta ishlatmasangiz, hech qanday o'zgarish bo'lmaydi.

Alohida, biz o'zgaruvchilarning mavjudligi haqida gapirishimiz kerak. Misol uchun, agar siz topshiriqni tsikl bilan xabardor qilsangiz, o'zgaruvchilarda nima bo'ladi? Siz analitik tarzda taxmin qilishingiz mumkin, lekin bu har doim ham ahamiyatsiz emas, ayniqsa o'zgaruvchilar turli joylardan kelgan bo'lsa.

... Shunday qilib, ishlov beruvchilar ko'rinadiganidan ko'ra kamroq foydali va juda muammoli. Agar siz biron bir narsani ishlov beruvchilarsiz chiroyli (burilishlarsiz) yozishingiz mumkin bo'lsa, ularsiz buni qilish yaxshiroqdir. Agar u chiroyli tarzda ishlamasa, ular bilan yaxshi bo'ladi.

Korroziv o'quvchi to'g'ri ta'kidlaydiki, biz muhokama qilmaganmiz listenishlov beruvchi boshqa ishlov beruvchi uchun notify ga qo'ng'iroq qilishi mumkinligi, ishlov beruvchi import_tasksni o'z ichiga olishi mumkinligi (ular with_items bilan include_role qilish mumkin), Ansible'dagi ishlov beruvchilar tizimi Turing-complete ekanligini, include_role dan ishlov beruvchilar o'yindan ishlov beruvchilar bilan qiziq tarzda kesishadi, va boshqalar .d. - bularning barchasi "asosiy" emasligi aniq).

Garchi bitta o'ziga xos WTF mavjud bo'lsa-da, bu aslida siz yodda tutishingiz kerak bo'lgan xususiyatdir. Agar sizning vazifangiz bilan bajarilgan bo'lsa delegate_to va u xabardor qildi, keyin tegishli ishlov beruvchisiz bajariladi delegate_to, ya'ni. o'yin tayinlangan xostda. (Garchi ishlovchi, albatta, bo'lishi mumkin delegate_to Bir xil).

Alohida, men qayta ishlatiladigan rollar haqida bir necha so'z aytmoqchiman. To'plamlar paydo bo'lishidan oldin, siz universal rollarni yaratishingiz mumkin degan fikr bor edi ansible-galaxy install va ketdi. Barcha holatlarda barcha variantlarning barcha OS da ishlaydi. Shunday qilib, mening fikrim: bu ishlamaydi. Massa bilan har qanday rol include_vars, 100500 ishni qo'llab-quvvatlaydi, burchak ishi xatoliklari tubsizligiga mahkum. Ularni ommaviy sinovdan o'tkazish mumkin, ammo har qanday testda bo'lgani kabi, sizda kirish qiymatlari va umumiy funktsiyaning kartezian mahsuloti mavjud yoki sizda "individual stsenariylar" mavjud. Mening fikrimcha, agar rol chiziqli bo'lsa (siklomatik murakkablik 1) yaxshi bo'ladi.

Kamroq iflar (aniq yoki deklarativ - shaklda when yoki shakl include_vars o'zgaruvchilar to'plami bo'yicha), rol qanchalik yaxshi bo'lsa. Ba'zan siz shoxchalar yasashingiz kerak, lekin takror aytaman, qancha kam bo'lsa, shuncha yaxshi. Shunday qilib, galaktika bilan yaxshi rol o'xshaydi (u ishlaydi!) Bir guruh bilan when beshta vazifadan "o'z" rolidan kamroq afzalroq bo'lishi mumkin. Galaktikaning roli yaxshiroq bo'lgan payt, siz biror narsa yozishni boshlaganingizda. Vaziyat yomonlashganda, biror narsa buziladi va siz bu "galaktika bilan rol" tufayli ekanligiga shubha qilasiz. Siz uni ochasiz va u erda beshta qo'shimcha, sakkizta vazifa varag'i va to'plam mavjud when'Ov... Va biz buni aniqlashimiz kerak. 5 ta vazifa o'rniga chiziqli ro'yxat bo'lib, unda sindiradigan hech narsa yo'q.

Keyingi qismlarda

• Inventar, guruh o'zgaruvchilari, host_group_vars plagini, hostvars haqida bir oz. Gordian tugunini spagetti bilan qanday bog'lash mumkin. Qo'llash doirasi va ustuvorlik o'zgaruvchilari, Ansible xotira modeli. "Xo'sh, biz ma'lumotlar bazasi uchun foydalanuvchi nomini qayerda saqlaymiz?"
• jinja: {{ jinja }} — nosql notype nosense yumshoq plastilin. U hamma joyda, hatto siz kutmagan joyda ham. Bir oz haqida !!unsafe va mazali yaml.

Manba: www.habr.com