მე ბევრ მიმოხილვას ვაკეთებ სხვა ადამიანების Ansible კოდზე და ბევრს ვწერ საკუთარ თავს. შეცდომების (როგორც სხვისი, ისე ჩემი) ანალიზის დროს, ისევე როგორც არაერთი ინტერვიუ, მივხვდი მთავარ შეცდომას, რომელსაც Ansible მომხმარებლები უშვებენ - ისინი რთულ საკითხებში ხვდებიან ძირითადის დაუფლების გარეშე.

ამ საყოველთაო უსამართლობის გამოსასწორებლად გადავწყვიტე, Ansible-ში შესავალი დამეწერა მათთვის, ვინც უკვე იცის. გაფრთხილებთ, ეს არ არის კაცების მოთხრობა, ეს არის დიდი ხნის ნასწავლი უამრავი ასოებით და სურათების გარეშე.

მკითხველის მოსალოდნელი დონე ის არის, რომ იამლას რამდენიმე ათასი სტრიქონი უკვე დაწერილია, რაღაც უკვე წარმოებაშია, მაგრამ „რაღაც რაღაცნაირად ყველაფერი მრუდია“.

სათაურები

Ansible მომხმარებლის მთავარი შეცდომა არის ის, რომ არ იცის რა ჰქვია. თუ სახელები არ იცი, ვერ გაიგებ რას წერს დოკუმენტაცია. ცოცხალი მაგალითი: ინტერვიუს დროს, ადამიანი, რომელიც თითქოს ამბობდა, რომ მან ბევრი დაწერა Ansible-ში, ვერ უპასუხა კითხვას "რა ელემენტებისაგან შედგება სათამაშო წიგნი?" და როდესაც მე ვთქვი, რომ „პასუხი მოსალოდნელი იყო, რომ სათამაშო წიგნი შედგება თამაშისგან“, მოჰყვა დამღუპველი კომენტარი „ჩვენ ამას არ ვიყენებთ“. ხალხი წერს Ansible-ს ფულისთვის და არ იყენებს თამაშს. ისინი რეალურად იყენებენ მას, მაგრამ არ იციან რა არის.

ასე რომ, დავიწყოთ რაღაც მარტივით: რა ჰქვია მას. შესაძლოა ეს იცით, ან შეიძლება არა, რადგან ყურადღება არ მიაქციეთ დოკუმენტაციის წაკითხვისას.

ansible-playbook ასრულებს სათამაშო წიგნს. 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, ადგილობრივი საძიებო დანამატები, ქსელის cli-ს სპეციფიკური პარამეტრები, ნახტომი ჰოსტები და ა.შ. ისინი საშუალებას გაძლევთ ოდნავ შეცვალოთ დავალებების შესრულების ადგილი. მაგრამ, დაივიწყე. თითოეულ ამ ჭკვიან ვარიანტს აქვს ძალიან სპეციფიკური გამოყენება და ისინი ნამდვილად არ არის უნივერსალური. და ჩვენ ვსაუბრობთ ძირითად საკითხებზე, რაც ყველამ უნდა იცოდეს და გამოიყენოს.

თუ გინდა "სადმე" შეასრულო "რაღაც", წერ პიესას. არა როლი. არ არის როლი მოდულებთან და დელეგატებთან. აიღებ და დაწერ პიესა. რომელშიც, ჰოსტების ველში ჩამოთვლით სად უნდა შესრულდეს, ხოლო როლებში/დავალებებს - რა უნდა შეასრულოთ.

მარტივი, არა? სხვანაირად როგორ შეიძლება?

ერთ-ერთი დამახასიათებელი მომენტი, როდესაც ადამიანებს აქვთ ამის სურვილი არა თამაშის საშუალებით, არის "როლი, რომელიც აყალიბებს ყველაფერს". მე მინდა მქონდეს როლი, რომელიც აკონფიგურირებს როგორც პირველი ტიპის სერვერებს, ასევე მეორე ტიპის სერვერებს.

არქეტიპული მაგალითია მონიტორინგი. მე მინდა მქონდეს მონიტორინგის როლი, რომელიც მონიტორინგს დააკონფიგურირებს. მონიტორინგის როლი ენიჭება მონიტორინგის მასპინძლებს (თამაშის მიხედვით). მაგრამ გამოდის, რომ მონიტორინგისთვის ჩვენ უნდა მივაწოდოთ პაკეტები მასპინძლებს, რომლებსაც ჩვენ ვაკვირდებით. რატომ არ გამოიყენოთ დელეგატი? თქვენ ასევე უნდა დააკონფიგურიროთ iptables. დელეგატი? თქვენ ასევე უნდა დაწეროთ/შეასწოროთ კონფიგურაცია DBMS-ისთვის, რათა ჩართოთ მონიტორინგი. დელეგატი! და თუ კრეატიულობა აკლია, მაშინ შეგიძლია დელეგირება include_role წყობილ მარყუჟში რთული ფილტრის გამოყენებით ჯგუფების სიაში და შიგნით include_role მეტის გაკეთება შეგიძლია delegate_to ისევ. და წავედით...

კარგი სურვილი - გვქონდეს ერთი მონიტორინგის როლი, რომელიც "აკეთებს ყველაფერს" - მიგვიყვანს სრულ ჯოჯოხეთში, საიდანაც ყველაზე ხშირად მხოლოდ ერთი გამოსავალია: ყველაფრის თავიდან გადაწერა.

სად მოხდა აქ შეცდომა? იმ მომენტში, როცა აღმოაჩინე, რომ X მასპინძელზე დავალების „x“ შესასრულებლად უნდა წასულიყავი Y-ს მასპინძელთან და გაეკეთებინა „y“ იქ, უნდა შეგესრულებინა მარტივი სავარჯიშო: წადი და დაწერე თამაში, რომელიც Y მასპინძელზე აკეთებს y-ს. "x"-ს არ დაუმატოთ რამე, არამედ დაწეროთ ნულიდან. თუნდაც მყარი კოდირებული ცვლადებით.

როგორც ჩანს, ზემოთ მოცემულ აბზაცებში ყველაფერი სწორად არის ნათქვამი. მაგრამ ეს შენი საქმე არ არის! იმიტომ, რომ გსურთ დაწეროთ მრავალჯერადი გამოყენებადი კოდი, რომელიც არის მშრალი და ბიბლიოთეკის მსგავსი, და თქვენ უნდა მოძებნოთ მეთოდი, თუ როგორ უნდა გააკეთოთ ეს.

აქ კიდევ ერთი სერიოზული შეცდომა იმალება. შეცდომა, რომელმაც მრავალი პროექტი გადააქცია ტოლერანტულად დაწერილიდან (ეს შეიძლება უკეთესიც იყოს, მაგრამ ყველაფერი მუშაობს და ადვილი დასასრულებელია) სრულ საშინელებად, რომელსაც ავტორიც კი ვერ ხვდება. მუშაობს, მაგრამ ღმერთმა ქნას, რამე შეცვალო.

შეცდომაა: როლი ბიბლიოთეკის ფუნქციაა. ამ ანალოგიამ გააფუჭა იმდენი კარგი დასაწყისი, რომ ყურება უბრალოდ სამწუხაროა. როლი არ არის ბიბლიოთეკის ფუნქცია. მას არ შეუძლია გათვლების გაკეთება და არ შეუძლია გადაწყვეტილებების მიღება თამაშის დონეზე. შემახსენე რა გადაწყვეტილებებს იღებს თამაში?

მადლობა, მართალი ხარ. 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: 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, თუ შეგვიძლია დავეყრდნოთ სექციების შესრულების თანმიმდევრობას თამაშში? უფრო მეტიც, meta: flush_handlers-ის გამოყენებამ შეიძლება მოგვცეს მოულოდნელი რამ დუბლიკატი დამმუშავებლების საშუალებით, რაც გვაძლევს უცნაურ გაფრთხილებებს გამოყენებისას. when у block და ა.შ. რაც უფრო კარგად იცნობთ პასუხს, მით უფრო მეტი ნიუანსი შეგიძლიათ დაასახელოთ "რთული" გადაწყვეტისთვის. და მარტივი გამოსავალი - ბუნებრივი დაყოფის გამოყენება პრე/როლებს/პოსტს შორის - არ იწვევს ნიუანსებს.

და დავუბრუნდეთ ჩვენს "ფუს". სად უნდა დავაყენო? წინასწარ, პოსტში თუ როლებში? ცხადია, ეს დამოკიდებულია იმაზე, გვჭირდება თუ არა დამმუშავებლის შედეგები 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 - შეგახსენებთ, რომ საბაზისო Ansible-ში ვიუმჯობესებთ უნარებს და არა ფიგურულ ტანვარჯიშში.

დამმუშავებლები და ამოცანები

მოდით განვიხილოთ კიდევ ერთი აშკარა რამ: დამმუშავებლები. მათი სწორად გამოყენების ცოდნა თითქმის ხელოვნებაა. რა განსხვავებაა დამმუშავებელსა და დრაგს შორის?

ვინაიდან ჩვენ გვახსოვს საფუძვლები, აქ არის მაგალითი:

- 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 გაკეთება, playbooks-ის საერთო სტაბილურობა იზრდება, რადგან კავშირების რაოდენობა და დინამიური მდგომარეობა მცირდება.

დამმუშავებლის კიდევ ერთი დადებითი თვისება ის არის, რომ ის არ ბლოკავს გამომავალს. არანაირი ცვლილება არ ყოფილა - არ არის ზედმეტი გამოტოვებული ან კარგი გამოსავალი - უფრო ადვილად იკითხება. ასევე უარყოფითი თვისებაა - თუ პირველივე გაშვებაზე წრფივად შესრულებულ ამოცანაში იპოვით შეცდომას, მაშინ დამმუშავებლები შესრულდება მხოლოდ შეცვლისას, ე.ი. ზოგიერთ პირობებში - ძალიან იშვიათად. მაგალითად, ჩემს ცხოვრებაში პირველად ხუთი წლის შემდეგ. და, რა თქმა უნდა, სახელში იქნება შეცდომა და ყველაფერი დაიშლება. და თუ მათ მეორედ არ აწარმოებთ, არ შეიცვლება.

ცალკე, ჩვენ უნდა ვისაუბროთ ცვლადების ხელმისაწვდომობაზე. მაგალითად, თუ აცნობებთ ამოცანას მარყუჟით, რა იქნება ცვლადებში? თქვენ შეგიძლიათ გამოიცნოთ ანალიტიკურად, მაგრამ ეს ყოველთვის არ არის ტრივიალური, განსაკუთრებით თუ ცვლადები სხვადასხვა ადგილიდან მოდის.

... ასე რომ, დამმუშავებლები გაცილებით ნაკლებად სასარგებლო და ბევრად უფრო პრობლემურია, ვიდრე ერთი შეხედვით ჩანს. თუ თქვენ შეგიძლიათ დაწეროთ რაიმე ლამაზად (ფრიკლების გარეშე) დამმუშავებლების გარეშე, უმჯობესია ამის გაკეთება მათ გარეშე. თუ ეს ლამაზად არ გამოდგება, მათთან უკეთესია.

კოროზიული მკითხველი მართებულად აღნიშნავს, რომ ჩვენ არ გვისაუბრია listenრომ დამმუშავებელს შეუძლია დარეკოს შეტყობინებები სხვა დამმუშავებლისთვის, რომ დამმუშავებელს შეუძლია შეიცავდეს import_tasks (რომელიც შეიძლება შეიცავდეს_role-ს with_items-თან ერთად), რომ დამმუშავებლის სისტემა Ansible-ში არის Turing-სრული, რომ კურატორები include_role-დან ცნობისმოყვარეულად იკვეთება თამაშიდან შემსრულებელებთან, და ა.შ. .დ. - ეს ყველაფერი აშკარად არ არის "საფუძვლები").

მიუხედავად იმისა, რომ არსებობს ერთი კონკრეტული WTF, რომელიც რეალურად არის ფუნქცია, რომელიც უნდა გახსოვდეთ. თუ თქვენი დავალება შესრულებულია delegate_to და მან შეატყობინა, შემდეგ შესაბამისი დამმუშავებელი შესრულებულია გარეშე delegate_to, ე.ი. მასპინძელზე, სადაც თამაში არის დანიშნული. (მიუხედავად იმისა, რომ დამმუშავებელს, რა თქმა უნდა, შეიძლება ჰქონდეს delegate_to იგივე).

ცალკე, მინდა ვთქვა რამდენიმე სიტყვა მრავალჯერადი გამოყენების როლებზე. სანამ კოლექციები გამოჩნდებოდა, არსებობდა იდეა, რომ შეგეძლო უნივერსალური როლების გაკეთება ansible-galaxy install და წავიდა. მუშაობს ყველა ვერსიის ყველა OS-ზე ყველა სიტუაციაში. ასე რომ, ჩემი აზრით: ეს არ მუშაობს. ნებისმიერი როლი მასით include_vars, რომელიც მხარს უჭერს 100500 საქმეს, განწირულია კუთხის საქმის შეცდომების უფსკრულში. ისინი შეიძლება დაიფაროს მასიური ტესტირებით, მაგრამ როგორც ნებისმიერი ტესტირებისას, ან გაქვთ შეყვანის მნიშვნელობების დეკარტიული პროდუქტი და მთლიანი ფუნქცია, ან გაქვთ „დაფარული ინდივიდუალური სცენარები“. ჩემი აზრით, ბევრად უკეთესია, თუ როლი არის ხაზოვანი (ციკლომატური სირთულე 1).

ნაკლები თუ (გამოხატული ან დეკლარაციული - ფორმაში when ან ფორმა include_vars ცვლადების ნაკრების მიხედვით), მით უკეთესია როლი. ხანდახან ტოტები უნდა გააკეთო, მაგრამ, ვიმეორებ, რაც ნაკლებია, მით უკეთესი. ასე რომ, როგორც ჩანს, კარგი როლია გალაქტიკასთან (მუშაობს!) თაიგულთან ერთად when შეიძლება ნაკლებად სასურველი იყოს, ვიდრე „საკუთარი“ როლი ხუთი ამოცანიდან. მომენტი, როცა როლი გალაქტიკაში უკეთესია, არის როცა რაღაცის წერას იწყებ. ის მომენტი, როცა უარესდება, არის ის, როცა რაღაც იშლება და ეჭვი გეპარება, რომ ეს არის „გალაქტიკასთან როლის“ გამო. თქვენ ხსნით მას და არის ხუთი ჩართვა, რვა დავალების ფურცელი და დასტა when'ოვ... და ჩვენ უნდა გავარკვიოთ ეს. 5 დავალების ნაცვლად, ხაზოვანი სია, რომელშიც გასატეხი არაფერია.

შემდეგ ნაწილებში

• ცოტა რამ ინვენტარის, ჯგუფის ცვლადების, host_group_vars მოდულის, hostvars-ის შესახებ. როგორ დავაკავშიროთ გორდიუსის კვანძი სპაგეტით. ფარგლები და უპირატესობის ცვლადები, Ansible მეხსიერების მოდელი. "მაშ, სად ვინახავთ მომხმარებლის სახელს მონაცემთა ბაზისთვის?"
• jinja: {{ jinja }} — nosql notype nosense რბილი პლასტილინი. ყველგან არის, იქაც კი, სადაც არ ელოდები. ცოტა შესახებ !!unsafe და გემრიელი იამლი.

წყარო: www.habr.com