რა არის Ansible და რატომ იცვლება მასთან ერთად ოპერირების წესი

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

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

ოთხი ცნება, რომელიც ყველაფერს ხსნის#

Inventory — მოწყობილობებისა და სერვერების სია, ჯგუფებად დაყოფილი. ჯგუფი შეიძლება იყოს „ბირთვის როუტერები“, „წვდომის კომუტატორები“, „VPS ამსტერდამში“. ცვლადები ენიჭება როგორც ჯგუფს, ისე ცალკეულ ჰოსტს.

Playbook — YAML ფაილი, რომელიც ამბობს, რომელ ჯგუფზე რა მდგომარეობა უნდა დამყარდეს. ეს არის ის ფაილი, რომელიც ვერსიების კონტროლში ინახება და code review-ს გადის ისევე, როგორც ნებისმიერი სხვა კოდი.

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

Role — playbook-ების, ცვლადებისა და შაბლონების მრავალჯერადი გამოყენების ერთეული. „ჩვენი სტანდარტული Linux ჰოსტი“ ერთი role-ია, რომელიც ორმოცდაათ სერვერზე ერთნაირად გაიშვება.

იდემპოტენტურობა — ერთადერთი თვისება, რომელიც მართლა მნიშვნელოვანია#

თუ ერთი ტერმინი უნდა დაიმახსოვროთ, ეს ის არის. იდემპოტენტური ოპერაცია იმავე შედეგს იძლევა, ერთხელ გაუშვებთ თუ ორმოცდაათჯერ.

პრაქტიკაში ეს ასე გამოიყურება: playbook ამბობს „ამ ინტერფეისზე უნდა იდგეს MTU 9000“. პირველი გაშვება ცვლის კონფიგურაციას და აღნიშნავს changed. მეორე გაშვება ამოწმებს, ხედავს, რომ MTU უკვე 9000-ია, არაფერს ცვლის და აღნიშნავს ok. მესამე, მეასე — იგივე.

აქედან გამომდინარეობს ორი შედეგი, რომელიც ოპერირების წესს ცვლის:

• playbook-ის გაშვება წყვეტს იმას, რომ სახიფათო მოქმედება იყოს. მისი გაშვება შეიძლება განრიგზე, ყოველდღიურად, ყოველგვარი ცერემონიის გარეშე.
• --check რეჟიმი რეალურ ინსტრუმენტად იქცევა. ის არაფერს ცვლის, მაგრამ გეუბნებათ, რა შეიცვლებოდა. ეს არის კონფიგურაციული დრიფტის აღმოჩენის ყველაზე იაფი გზა: თუ „არაფრის შემცვლელი“ გაშვება ოცდაათ ცვლილებას გვპირდება, ვიღაცამ ხელით შეცვალა რაღაც.

რატომ არის agent-ის არქონა გადამწყვეტი#

Ansible agentless-ია: მართულ მოწყობილობაზე არაფერი დგება. კავშირი მიდის SSH-ით (ქსელურ აპარატურაზე — ხშირად NETCONF-ით ან ვენდორის API-ით), ბრძანება სრულდება და კავშირი იხურება.

სერვერების სამყაროში ეს მოხერხებულობაა. ქსელურ აპარატურაზე ეს ხშირად ერთადერთი შესაძლებლობაა — როუტერზე ან კომუტატორზე თქვენს agent-ს ვერსად დააყენებთ. სწორედ ამიტომ არის Ansible იმ მცირერიცხოვან ინსტრუმენტთა შორის, რომელიც ერთი და იმავე ლოგიკით წვდება Linux ჰოსტსაც და MikroTik-ის, Juniper-ის თუ Cisco-ს მოწყობილობასაც.

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

განრიგზე დაყენებული ავტომატიზაცია#

სწორედ ამ ხარვეზს პასუხობს playbook-ების განრიგზე გაშვება. თუ „ერთხელ გაშვებული“ playbook კონფიგურაციულ დრიფტს ვერ იჭერს, განრიგზე მდგარი playbook — იჭერს.

გადიდება

Semaphore ამ სურათზე Ansible-ის თავზე დამატებული ფენაა და სამ პრაქტიკულ პრობლემას წყვეტს, რომელიც სუფთა ansible-playbook ბრძანებას აქვს:

• განრიგი — cron-გამოსახულება თითოეულ სამუშაოზე, ცალკე ჩართვა-გამორთვის შესაძლებლობით.
• წვდომა და საიდუმლოებები — SSH-ის გასაღებები ცენტრალიზებულ Key Store-შია და არა ინჟინრის ლეპტოპზე; ვინ რომელ inventory-ს უშვებს, როლებით განისაზღვრება.
• ისტორია — ყოველი გაშვების ჟურნალი რჩება. „როდის გაშვდა ბოლოს და რა თქვა“ ისეთივე კითხვაა, როგორც „რომელი კონფიგურაცია იდგა სამშაბათს“.

სად ჩერდება Ansible#

პატიოსანი პასუხი უფრო სასარგებლოა, ვიდრე სია იმისა, რაც შეუძლია:

• ეს არ არის მონიტორინგის სისტემა. Ansible ამბობს „მდგომარეობა დავაყენე“; ის არ გეუბნებათ, ახლა როგორ მუშაობს სერვისი. ეს Zabbix-ის, LibreNMS-ის ან Prometheus-ის საქმეა.
• ეს არ არის CMDB. inventory არის ის, რაც თქვენ ჩაწერეთ, და არა ის, რაც ქსელში რეალურად დგას. აღმოჩენა ცალკე ამოცანაა.
• push-მოდელი მასშტაბზე ნელია. ათასობით ჰოსტზე თანმიმდევრული SSH კავშირები იგრძნობა; forks, pipelining და ჯგუფებად დაყოფა აუცილებელი ხდება.
• YAML კოდი ხდება. დიდი playbook-ების ნაკრები იმავე პრობლემებს იძენს, რაც ნებისმიერ კოდს — გამეორება, ტესტირების საჭიროება, რეფაქტორინგი. ansible-lint და როლებად დაყოფა არჩევითი აღარაა.

როგორ ვიყენებთ#

ჩვენთან Ansible სამ ადგილას დგას: სტანდარტული კონფიგურაციის დაყენება ახალ ჰოსტებზე, განმეორებადი შემოწმებები განრიგზე (latency, DNS, სერვისების მდგომარეობა), და ცვლილების გავრცელება მოწყობილობათა ჯგუფზე, როცა იგივე ცვლილება ბევრგან უნდა შევიდეს.

კონფიგურაციების შეგროვება და ვერსიებად შენახვა ცალკე ინსტრუმენტს გადავეცით — ის ყოველდღიურად აგროვებს RouterOS, JunOS, IOS და EOS კონფიგურაციებს და git-ში ინახავს. ეს ორი ერთმანეთს ავსებს: Ansible ცვლის მდგომარეობას, არქივი კი იმახსოვრებს, როგორი იყო ის ცვლილებამდე.