Би бусдын Ansible кодыг маш их шүүмжилдэг, өөрөө ч их бичдэг. Алдааг (бусад хүмүүсийн болон миний аль алиных нь), мөн хэд хэдэн ярилцлагад дүн шинжилгээ хийх явцад би Ansible-ийн хэрэглэгчдийн гаргадаг гол алдааг ойлгосон - тэд үндсэн зүйлийг эзэмшихгүйгээр нарийн төвөгтэй зүйлд ордог.

Энэхүү бүх нийтийн шударга бус байдлыг засахын тулд би үүнийг аль хэдийн мэддэг хүмүүст зориулж Ansible-ийн оршил бичихээр шийдсэн. Би танд анхааруулж байна, энэ бол эрэгтэй хүний ​​тухай өгүүлэх зүйл биш, энэ бол маш олон үсэгтэй, зураггүй урт уншлага юм.

Уншигчийн хүлээгдэж буй түвшин бол хэдэн мянган мөр ямла аль хэдийн бичигдсэн, ямар нэг зүйл аль хэдийн үйлдвэрлэгдсэн, гэхдээ "ямар нэгэн байдлаар бүх зүйл муруйсан".

Гарчиг

Ansible хэрэглэгчийн гаргадаг гол алдаа бол ямар нэг зүйлийг юу гэж нэрлэхээ мэдэхгүй байх явдал юм. Хэрэв та нэрийг нь мэдэхгүй бол баримт бичигт юу бичсэнийг ойлгохгүй. Амьд жишээ: Ярилцлагын үеэр Ansible дээр маш их бичсэн гэж хэлсэн хүн "Тоглоомын дэвтэр ямар элементүүдээс бүрддэг вэ?" Гэсэн асуултад хариулж чадахгүй байв. Тэгээд би "Тоглоомын дэвтэр нь тоглоомоос бүрддэг гэсэн хариултыг хүлээж байсан" гэж хэлэх үед "бид үүнийг ашигладаггүй" гэсэн хараал идсэн тайлбар гарч ирэв. Хүмүүс Ansible гэж мөнгөөр ​​бичдэг, тоглоом хэрэглэдэггүй. Тэд үүнийг үнэхээр ашигладаг, гэхдээ энэ нь юу болохыг мэддэггүй.

Тиймээс энгийн зүйлээс эхэлье: үүнийг юу гэж нэрлэдэг вэ? Та баримт бичгийг уншихдаа анхаарал хандуулаагүй тул та үүнийг мэдэж байгаа эсвэл мэдэхгүй байж магадгүй юм.

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, локал хайлтын залгаасууд, сүлжээний тусгай тохиргоонууд, jump hosts гэх мэт. Эдгээр нь даалгаврыг гүйцэтгэх газрыг бага зэрэг өөрчлөх боломжийг танд олгоно. Гэхдээ үүнийг март. Эдгээр ухаалаг сонголт бүр нь маш тодорхой хэрэглээтэй бөгөөд тэдгээр нь мэдээжийн хэрэг бүх нийтийнх биш юм. Мөн бид хүн бүрийн мэдэж, хэрэглэх ёстой үндсэн зүйлийн талаар ярьж байна.

Хэрэв та "ямар нэгэн зүйл" "хаа нэгтээ" тоглохыг хүсч байвал та жүжиг бичдэг. Дүр биш. Модулиуд болон төлөөлөгчидтэй үүрэг биш. Та үүнийг аваад жүжиг бичээрэй. Хостуудын талбарт та хаана гүйцэтгэх, үүрэг/даалгавруудад юу гүйцэтгэхийг жагсаана.

Энгийн, тийм үү? Яаж өөрөөр байж болох юм бэ?

Хүмүүс тоглоомоор бус үүнийг хийхийг хүсдэг нэг онцлог шинж чанар бол "бүх зүйлийг бий болгодог дүр" юм. Би эхний төрлийн серверүүд болон хоёр дахь төрлийн серверүүдийг хоёуланг нь тохируулах үүрэгтэй байхыг хүсч байна.

Архетипийн жишээ бол мониторинг юм. Би хяналтыг тохируулах хяналтын үүрэгтэй болмоор байна. Хяналтын үүрэг нь хяналтын хостуудад (тоглолтын дагуу) хуваарилагдсан. Гэхдээ хяналт тавихын тулд бид хянаж буй хостуудад багцуудыг хүргэх шаардлагатай болж байна. Яагаад төлөөлөгчийг ашиглаж болохгүй гэж? Та мөн iptables-ийг тохируулах хэрэгтэй. төлөөлөгч? Та мөн хяналтыг идэвхжүүлэхийн тулд DBMS-ийн тохиргоог бичих/засах хэрэгтэй. төлөөлөгч! Бүтээлч байдал дутагдаж байвал төлөөлөгч гаргаж болно include_role бүлгүүдийн жагсаалтад зальтай шүүлтүүр ашиглан үүрлэсэн гогцоонд болон дотор include_role та илүү ихийг хийж чадна delegate_to дахин. Тэгээд бид явлаа ...

"Бүхнийг хийдэг" нэг хяналтын үүрэг гүйцэтгэх сайн хүсэл нь биднийг бүрэн там руу хөтөлдөг бөгөөд үүнээс гарах цорын ганц арга зам байдаг: бүгдийг эхнээс нь дахин бичих.

Энд алдаа хаана гарсан бэ? X хост дээр "x" гэсэн даалгаврыг хийхийн тулд Y хост руу очоод тэнд "y" хийх хэрэгтэйг олж мэдсэн тэр мөчид та энгийн дасгал хийх хэрэгтэй болсон: явж, Y хост дээр тоглодог тоглоом бичих хэрэгтэй. "X" дээр ямар нэг зүйл нэмж болохгүй, гэхдээ үүнийг эхнээс нь бичээрэй. Хатуу кодлогдсон хувьсагчтай ч гэсэн.

Дээрх догол мөрөнд байгаа бүх зүйлийг зөв хэлсэн бололтой. Гэхдээ энэ бол таны хэрэг биш! Учир нь та дахин ашиглах боломжтой кодыг DRY, номын сан шиг бичихийг хүсч байгаа бөгөөд үүнийг хэрхэн хийх аргыг хайж олох хэрэгтэй.

Энд бас нэг ноцтой алдаа нуугдаж байна. Олон төслийг тэвчиж болохуйц бичсэн (энэ нь илүү дээр байж болох ч бүх зүйл ажилладаг бөгөөд дуусгахад хялбар байдаг) алдаа нь зохиогч нь хүртэл ойлгохгүй бүрэн аймшигт байдалд хүргэсэн. Энэ нь ажилладаг, гэхдээ Бурхан таныг ямар нэгэн зүйлийг өөрчлөхийг хориглодог.

Алдаа нь: үүрэг бол номын сангийн функц юм. Энэ зүйрлэл нь маш олон сайхан эхлэлийг сүйрүүлсэн тул харахад үнэхээр гунигтай байдаг. Энэ үүрэг нь номын сангийн функц биш юм. Тэр тооцоо хийж чаддаггүй, тоглоомын түвшний шийдвэр гаргаж чаддаггүй. Тоглоом ямар шийдвэр гаргадгийг надад сануулаарай?

Баярлалаа, чиний зөв. Play нь аль хост дээр ямар даалгавар, үүргийг гүйцэтгэх талаар шийдвэр гаргадаг (илүү нарийвчлалтай, мэдээлэл агуулсан).

Хэрэв та энэ шийдвэрийг үүрэг хариуцлагад шилжүүлбэл, тэр ч байтугай тооцоололтой байсан ч та өөрийгөө (мөн таны кодыг задлан шинжлэхийг оролдох хүнийг) өрөвдөлтэй амьдрахад хүргэнэ. Дүр нь хаана тоглохыг шийддэггүй. Энэ шийдвэрийг тоглоомоор гаргадаг. Дүр бол хэлсэн зүйлээ, хэлсэн газраа л хийдэг.

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 хэрэгтэй байна вэ? Түүнчлэн, мета: flush_handlers-ийг ашиглах нь давхардсан боловсруулагчтай гэнэтийн зүйлийг өгч, ашиглах үед хачирхалтай анхааруулга өгдөг. when у block гэх мэт. Асуудлыг илүү сайн мэдэх тусам "зөвхөн" шийдлийг олохын тулд илүү олон нюансуудыг нэрлэж болно. Мөн энгийн шийдэл - өмнөх / үүрэг / дараах хоорондох байгалийн хуваагдлыг ашиглах нь нарийн ширийн зүйлийг үүсгэдэггүй.

Тэгээд бидний "foo" руу буцах. Би хаана тавих ёстой вэ? Урьдчилсан, бичлэг эсвэл дүрд үү? Мэдээжийн хэрэг, энэ нь 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 - Бид дүрсний гимнастикаар бус үндсэн Ансиблийн ур чадвараа дээшлүүлж байгааг би танд сануулж байна.

Ажиллагчид ба даалгавар

Өөр нэг тодорхой зүйлийг ярилцъя: зохицуулагчид. Тэдгээрийг хэрхэн зөв ашиглахаа мэдэх нь бараг л урлаг юм. Баригч болон чирэх хоёрын ялгаа юу вэ?

Бид үндсэн ойлголтуудыг санаж байгаа тул энд жишээ дурдъя:

- 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зохицуулагч нь өөр зохицуулагчийн мэдэгдлийг дуудаж болох, зохицуулагч нь import_tasks (энэ нь with_items-тэй хамт үүрэг гүйцэтгэх боломжтой), Ansible дахь зохицуулагчийн систем нь Turing-complete, include_role-ийн зохицуулагчид тоглоомын зохицуулагч нартай сониуч байдлаар огтлолцдог, гэх мэт .d. - энэ бүхэн "үндсэн" зүйл биш нь тодорхой байна).

Хэдийгээр таны санаж байх ёстой нэг онцлог WTF байдаг. Хэрэв таны даалгавар хэрэгжсэн бол delegate_to болон энэ нь мэдэгдэнэ, дараа нь харгалзах зохицуулагч ямар ч гүйцэтгэсэн байна delegate_to, өөрөөр хэлбэл тоглох хуваарилагдсан хост дээр. (Хэдийгээр зохицуулагч нь мэдээжийн хэрэг байж магадгүй юм delegate_to Үүнтэй адил).

Дахин ашиглах боломжтой дүрүүдийн талаар тусад нь хэдэн үг хэлмээр байна. Цуглуулга гарч ирэхээс өмнө та бүх нийтийн дүрүүдийг бүтээж болно гэсэн санаа байсан ansible-galaxy install бас явлаа. Бүх нөхцөл байдалд бүх хувилбарын бүх үйлдлийн систем дээр ажиллана. Тиймээс, миний бодол: энэ нь ажиллахгүй байна. Масстай ямар ч үүрэг include_vars, 100500 хэргийг дэмждэг, булангийн тохиолдлын алдааг ангал руу илгээсэн. Тэдгээрийг их хэмжээний туршилтаар хамруулах боломжтой, гэхдээ ямар ч туршилтын нэгэн адил та оролтын утга ба нийт функцийн декарт бүтээгдэхүүнтэй эсвэл "хувийн хувилбаруудыг хамарсан" байна. Миний бодлоор үүрэг нь шугаман байвал илүү дээр юм (цикломат нарийн төвөгтэй байдал 1).

Цөөн ifs (тодорхой эсвэл тунхаглал - хэлбэрээр when эсвэл хэлбэр include_vars хувьсагчийн олонлогоор), илүү сайн үүрэг гүйцэтгэдэг. Заримдаа та мөчир хийх хэрэгтэй, гэхдээ би давтан хэлэхэд цөөн байх тусмаа сайн. Тиймээс энэ нь галактиктай (энэ нь ажилладаг!) маш сайн дүр юм шиг санагдаж байна when таван даалгавраас "өөрийн" үүрэг гүйцэтгэхээс хамаагүй илүү байж болно. Галактикийн дүр илүү сайн болох үе бол та ямар нэгэн зүйл бичиж эхлэх үе юм. Энэ нь бүр дордох мөч бол ямар нэг зүйл эвдэрч, "галактиктай үүрэг гүйцэтгэсэн" гэсэн хардлага төрдөг. Та үүнийг нээвэл тэнд таван оруулга, найман ажлын хуудас, стек байна when'ov... Тэгээд бид үүнийг ойлгох хэрэгтэй. 5 даалгаврын оронд эвдэх зүйлгүй шугаман жагсаалт.

Дараах хэсгүүдэд

• Бараа материалын талаар бага зэрэг, бүлгийн хувьсагчид, host_group_vars залгаас, hostvars. Гордиан зангилааг спагеттитэй хэрхэн яаж холбох вэ. Хамрах хүрээ ба тэргүүлэх хувьсагчид, Ansible санах ойн загвар. "Тэгвэл бид мэдээллийн сангийн хэрэглэгчийн нэрийг хаана хадгалах вэ?"
• jinja: {{ jinja }} — nosql notype nosense зөөлөн plasticine. Энэ нь хаа сайгүй, тэр ч байтугай таны төсөөлөөгүй газар хүртэл байдаг. Бага зэрэг !!unsafe мөн амттай ямл.

Эх сурвалж: www.habr.com