როგორ აიღოთ თქვენი ქსელის ინფრასტრუქტურის კონტროლი. თავი მეოთხე. ავტომატიზაცია. შაბლონები

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

რამდენიმე თემის დატოვების შემდეგ გადავწყვიტე ახალი თავი დამეწყო.

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

DevOps ქსელისთვის

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

როდესაც 5 წელზე მეტი ხნის წინ, ჩვენთან მოვიდნენ ჩვენი დეველოპერები, ქსელის თანამშრომლები, ამ წინადადებებით, ჩვენ არ გაგვახარა.

უნდა ითქვას, რომ ჩვენ მემკვიდრეობით მივიღეთ საკმაოდ ჭრელი ქსელი, რომელიც შედგება 10-მდე სხვადასხვა გამყიდველის აღჭურვილობისგან. მოსახერხებელი იყო ზოგიერთი ნივთის კონფიგურაცია ჩვენი საყვარელი კლიკის საშუალებით, მაგრამ სხვებში ჩვენ ვამჯობინეთ GUI-ის გამოყენება. გარდა ამისა, "ცოცხალ" აღჭურვილობაზე ხანგრძლივმა მუშაობამ გვასწავლა რეალურ დროში კონტროლი. მაგალითად, ცვლილებების შეტანისას, ბევრად უფრო კომფორტულად ვგრძნობ თავს უშუალოდ cli-ზე მუშაობას. ამ გზით მე შემიძლია სწრაფად დავინახო, რომ რაღაც არასწორედ წარიმართა და გავაბრუნო ცვლილებები. ეს ყველაფერი გარკვეულ წინააღმდეგობაში იყო მათ იდეებთან.

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

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

არ მინდა ვთქვა, რომ ყველა ეს საკითხი გადაუჭრელია. უბრალოდ „A“-ს თქმას, ალბათ, აქვს „B“-ს თქმაც, და თუ გსურთ გამოიყენოთ იგივე პროცესები ცვლილებების კონტროლისთვის, როგორც განვითარებაში, მაშინ წარმოების გარდა უნდა გქონდეთ დეველოპმენტი და დადგმის გარემო. მაშინ ეს მიდგომა დასრულებულად გამოიყურება. მაგრამ რამდენი დაჯდება?

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

პროექტი

ბოლო ორი წელია, რაც მე ვმონაწილეობ პროექტში, რომელიც ავაშენებ მონაცემთა ცენტრის მსხვილ პროვაიდერს. მე ვარ პასუხისმგებელი F5 და Palo Alto ამ პროექტში. Cisco-ს თვალსაზრისით, ეს არის "მესამე მხარის აღჭურვილობა".

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

ეტაპი ერთი

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

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

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

ახლა შეგვეძლო ცოტათი მიმოიხედე გარშემო.
და ეს იყო მეორე ეტაპის დასაწყისი.

მეორე ეტაპი

გადავწყვიტე პროცესის ავტომატიზაცია.

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

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

ასე რომ, YAML და Jinja2-ის გამოყენებისას, YAML ფაილი კონფიგურაციის პარამეტრებით, როგორიცაა IP მისამართები, BGP AS ნომრები, ... შესანიშნავად ასრულებს NIP-ის როლს, ხოლო Jinja2 შაბლონები მოიცავს დიზაინის შესაბამის სინტაქსს, ანუ ის არსებითად არის LLD-ის ასახვა.

YAML და Jinja2-ის სწავლას ორი დღე დასჭირდა. რამდენიმე კარგი მაგალითი საკმარისია იმის გასაგებად, თუ როგორ მუშაობს ეს. შემდეგ დაახლოებით ორი კვირა დასჭირდა ყველა იმ შაბლონის შექმნას, რომელიც ემთხვეოდა ჩვენს დიზაინს: ერთი კვირა Palo Alto-სთვის და კიდევ ერთი კვირა F5-ისთვის. ეს ყველაფერი გამოქვეყნდა კორპორატიულ githab-ზე.

ახლა ცვლილების პროცესი ასე გამოიყურებოდა:

• შეცვალა YAML ფაილი
• შექმნა კონფიგურაციის ფაილი შაბლონის გამოყენებით (Jinja2)
• შენახულია დისტანციურ საცავში
• ატვირთა შექმნილი კონფიგურაცია აღჭურვილობაში
• შეცდომა დავინახე
• შეცვალა YAML ფაილი ან Jinja2 შაბლონი
• შექმნა კონფიგურაციის ფაილი შაბლონის გამოყენებით (Jinja2)
• ...

გასაგებია, რომ თავიდან დიდი დრო იხარჯებოდა რედაქტირებაზე, მაგრამ ერთი-ორი კვირის შემდეგ ეს საკმაოდ იშვიათობა გახდა.

კარგი ტესტი და ყველაფრის გამართვის შესაძლებლობა იყო კლიენტის სურვილი შეცვალოს დასახელების კონვენცია. მათ, ვინც მუშაობდა F5-თან, ესმით სიტუაციის პიკანტურობა. მაგრამ ჩემთვის ეს ყველაფერი საკმაოდ მარტივი იყო. შევცვალე სახელები YAML ფაილში, წავშალე მთელი კონფიგურაცია მოწყობილობიდან, შევქმენი ახალი და ავტვირთე. ყველაფერს, შეცდომების გამოსწორების ჩათვლით, დასჭირდა 4 დღე: ორი დღე თითოეული ტექნოლოგიისთვის. ამის შემდეგ მზად ვიყავი შემდეგი ეტაპისთვის, კერძოდ DEV და Staging მონაცემთა ცენტრების შესაქმნელად.

Dev და დადგმა

დადგმა რეალურად სრულად იმეორებს წარმოებას. Dev არის მძიმედ ამოღებული ასლი, რომელიც აგებულია ძირითადად ვირტუალურ აპარატურაზე. იდეალური სიტუაცია ახალი მიდგომისთვის. თუ გამოვყოფ დროს დახარჯულს საერთო პროცესისგან, მაშინ ვფიქრობ, რომ სამუშაოს 2 კვირაზე მეტი დრო დასჭირდა. მთავარი დრო მეორე მხარის მოლოდინში და პრობლემების ერთად ძიებაა. მესამე მხარის განხორციელება თითქმის შეუმჩნეველი დარჩა სხვებისთვის. დროც კი იყო, რომ რაღაც შემესწავლა და რამდენიმე სტატია დამეწერა ჰაბრეზე :)

შეჯამება

მაშ, რა მაქვს ბოლოში?

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

ყოველივე ამან განაპირობა ის, რომ

• შეცდომის მაჩვენებელი თითქმის 0-მდე დაეცა
• რუტინის 90 პროცენტი გაქრა
• განხორციელების სიჩქარე მნიშვნელოვნად გაიზარდა

PAY, F5Y, ACY

მე ვთქვი, რომ რამდენიმე მაგალითი საკმარისია იმის გასაგებად, თუ როგორ მუშაობს.
აქ არის მოკლე (და რა თქმა უნდა შეცვლილი) ვერსია იმისა, რაც შეიქმნა ჩემი მუშაობის დროს.

გადაიხადე = განლაგება Palo Aლტო-დან Yამლ = პალო ალტო იამლიდან
F5Y = განლაგება F5 საწყისი Yამლ = F5 საწყისი Yaml (მალე)
Acy = განლაგება ACმე დან Yამლ = F5 საწყისი Yaml

რამდენიმე სიტყვას დავამატებ ACY-ზე (არ აგვერიოს ACI-ში).

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

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

ამ პროექტის ინჟინრები იყენებენ Excel-ს YAML-ის ნაცვლად ACI-ის კონფიგურაციისთვის ზუსტად იგივე მიზნებისთვის. Excel-ის გამოყენებას, რა თქმა უნდა, აქვს უპირატესობები:

• თქვენი NIP ერთ ფაილში
• ლამაზი ნიშნები, რომლებიც სასიამოვნოა კლიენტისთვის
• შეგიძლიათ გამოიყენოთ Excel-ის რამდენიმე ინსტრუმენტი

მაგრამ არის ერთი მინუსი და, ჩემი აზრით, ის აჭარბებს დადებით მხარეებს. ცვლილებების კონტროლი და გუნდური მუშაობის კოორდინაცია ბევრად უფრო რთული ხდება.

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

წყარო: www.habr.com