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

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

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

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

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

OS ინსტალაციის მენეჯმენტი

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

ამ სისტემის გამოყენებით, ჩვენ მივიღეთ სტანდარტული სერვერის მაგალითები OS-ით, რომელიც შესაფერისია შემდგომი ავტომატიზაციისთვის. "ჩამოსხმის" დროს მათ მიიღეს ადგილობრივი მომხმარებლების მინიმალური ნაკრები და საჯარო SSH გასაღებები, ასევე თანმიმდევრული OS კონფიგურაცია. ჩვენ გარანტირებული გვქონდა სერვერების მართვა CMS-ის საშუალებით და დარწმუნებულები ვიყავით, რომ სიურპრიზები არ იყო „ქვემოთ“ OS დონეზე.

ინსტალაციის მართვის სისტემის "მაქსიმალური" ამოცანაა სერვერების ავტომატურად კონფიგურაცია BIOS/Firmware დონიდან OS-მდე. აქ ბევრი რამ არის დამოკიდებული აღჭურვილობასა და დაყენების ამოცანებზე. ჰეტეროგენული აღჭურვილობისთვის, შეგიძლიათ განიხილოთ REDFISH API. თუ მთელი აპარატურა არის ერთი გამყიდველისგან, მაშინ ხშირად უფრო მოსახერხებელია მზა მართვის ხელსაწყოების გამოყენება (მაგალითად, HP ILO გამაძლიერებელი, DELL OpenManage და ა.შ.).

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

ჩვენ შევქმენით ვირტუალური სერვერები HashiСorp Packer-ის გამოყენებით მომზადებული შაბლონების საფუძველზე. მიზეზი იგივე იყო: OS-ის დაყენებისას შესაძლო ადამიანური შეცდომების თავიდან ასაცილებლად. მაგრამ, ფიზიკური სერვერებისგან განსხვავებით, Packer გამორიცხავს PXE, ქსელის ჩატვირთვისა და VLAN ცვლილებების საჭიროებას. ამან გაადვილა და გაამარტივა ვირტუალური სერვერების შექმნა.

ბრინჯი. 1. ოპერაციული სისტემების ინსტალაციის მართვა.

საიდუმლოების მართვა

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

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

• პირდაპირ კონფიგურაციის კონტროლის კოდში ან საცავში არსებულ ფაილებში;
• სპეციალიზებულ კონფიგურაციის მართვის ინსტრუმენტებში (მაგალითად, Ansible Vault);
• CI/CD სისტემებში (Jenkins/TeamCity/GitLab/ა.შ.) ან კონფიგურაციის მართვის სისტემებში (Ansible Tower/Ansible AWX);
• საიდუმლოების გადაცემა ასევე შესაძლებელია "ხელით". მაგალითად, ისინი განლაგებულია მითითებულ ადგილას და შემდეგ გამოიყენება კონფიგურაციის მართვის სისტემებით;
• ზემოაღნიშნულის სხვადასხვა კომბინაციები.

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

ჩვენ გამოვიყენეთ ცენტრალიზებული საიდუმლო საცავი HashiCorp Vault. ამან მოგვცა საშუალება:

• შეინახეთ საიდუმლოებები უსაფრთხოდ. ისინი დაშიფრულია და თუნდაც ვინმემ მოიპოვოს წვდომა Vault-ის მონაცემთა ბაზაზე (მაგალითად, სარეზერვო ასლიდან აღდგენით), ვერ შეძლებს იქ შენახული საიდუმლოების წაკითხვას;
• საიდუმლოებასთან წვდომის პოლიტიკის ორგანიზება. მომხმარებლებისა და აპლიკაციებისთვის ხელმისაწვდომია მხოლოდ მათთვის „გამოყოფილი“ საიდუმლოებები;
• აუდიტის ხელმისაწვდომობა საიდუმლოებას. ნებისმიერი ქმედება საიდუმლოებით აღირიცხება Vault-ის აუდიტის ჟურნალში;
• საიდუმლოებთან მუშაობის სრულფასოვანი „სიცოცხლის ციკლის“ ორგანიზება. მათი შექმნა, გაუქმება, ვადის დაწესება და ა.შ.
• მარტივი ინტეგრირება სხვა სისტემებთან, რომლებსაც სჭირდებათ საიდუმლოებაზე წვდომა;
• და ასევე გამოიყენეთ ბოლოდან ბოლომდე დაშიფვრა, ერთჯერადი პაროლები OS და მონაცემთა ბაზისთვის, ავტორიზებული ცენტრების სერთიფიკატები და ა.შ.

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

ჩვენ ვამატებთ ჩვენს სისტემას კიდევ ერთ დონეს: საიდუმლოების მართვა და ცენტრალური ავთენტიფიკაცია/ავტორიზაცია:

ბრინჯი. 2. საიდუმლოების მართვა.

Კონფიგურაციის მართვა

ჩვენ მივედით ბირთვამდე - CMS სისტემაში. ჩვენს შემთხვევაში, ეს არის Ansible და Red Hat Ansible AWX-ის კომბინაცია.

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

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

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

ასეთ საკითხებში ლომის წილს Red Hat წყვეტს Ansible Tower, ან მისი ღია წყაროს ზემოთ პროექტი Ansible AWX. სწორედ ამიტომ ვამჯობინეთ იგი მომხმარებლისთვის.

და კიდევ ერთი შეხება ჩვენი CMS სისტემის პორტრეტზე. Ansible Playbook უნდა ინახებოდეს კოდების საცავის მართვის სისტემებში. ჩვენ გვაქვს GitLab CE.

ამრიგად, თავად კონფიგურაციები იმართება Ansible/Ansible AWX/GitLab-ის კომბინაციით (იხ. ნახ. 3). რა თქმა უნდა, AWX/GitLab ინტეგრირებულია ერთიან ავთენტიფიკაციის სისტემასთან, ხოლო Ansible playbook ინტეგრირებულია HashiCorp Vault-თან. კონფიგურაციები საწარმოო გარემოში შემოდის მხოლოდ Ansible AWX-ის საშუალებით, რომელშიც მითითებულია ყველა „თამაშის წესი“: ვის შეუძლია რისი კონფიგურაცია, სად მიიღოს CMS-ის კონფიგურაციის მართვის კოდი და ა.შ.

ბრინჯი. 3. კონფიგურაციის მართვა.

ტესტის მენეჯმენტი

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

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

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

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

როდესაც ხდება ცვლილება კონფიგურაციის მართვის კოდში, GitLab CI/CD უწოდებს Molecule-ს:

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

ჩვენ მივაწოდეთ კონფიგურაციები წარმოების გარემოში Ansible AWX-ის გამოყენებით. ოპერაციების ინჟინრებმა გამოიყენეს კონფიგურაციის ცვლილებები წინასწარ განსაზღვრული შაბლონების მეშვეობით. AWX დამოუკიდებლად „ითხოვდა“ კოდის უახლეს ვერსიას GitLab სამაგისტრო ფილიალიდან ყოველ ჯერზე, როცა ის გამოიყენებოდა. ამ გზით ჩვენ გამოვრიცხეთ შეუმოწმებელი ან მოძველებული კოდის გამოყენება საწარმოო გარემოში. ბუნებრივია, კოდი შევიდა მთავარ ფილიალში მხოლოდ ტესტირების, განხილვისა და დამტკიცების შემდეგ.

ბრინჯი. 4. როლების ავტომატური ტესტირება GitLab CI/CD-ში.

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

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

ამიტომ, უწყვეტი ტესტირების გარდა, ჩვენ ვამოწმებთ წარმოების გარემოს კონფიგურაციის შეუსაბამობებზე. ჩვენ ავირჩიეთ უმარტივესი ვარიანტი: CMS კონფიგურაციის კოდის გაშვება „მშრალი გაშვების“ რეჟიმში, ანუ ცვლილებების გამოყენების გარეშე, მაგრამ დაგეგმილ და რეალურ კონფიგურაციას შორის ყველა შეუსაბამობის შეტყობინებით. ჩვენ ეს განვახორციელეთ ყველა Ansible სათამაშო წიგნის პერიოდულად გაშვებით „-შემოწმების“ ოფციით წარმოების სერვერებზე. როგორც ყოველთვის, Ansible AWX პასუხისმგებელია სათამაშო წიგნის გაშვებაზე და განახლებაზე (იხ. სურ. 5):

ბრინჯი. 5. ამოწმებს კონფიგურაციის შეუსაბამობებს Ansible AWX-ში.

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

ჩვენ ახლა გვაქვს მნიშვნელოვანი ტესტირების ფენა, რომელიც შედგება Ansible AWX/GitLab/Molecule-სგან (სურათი 6).

ბრინჯი. 6. ტესტის მართვა.

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

დღეს არ არსებობს "საიდუმლო ცოდნა" სერვერებისა და გარემოს პარამეტრებში. ყველა საჭირო ფუნქცია აისახება სათამაშო წიგნში. აღარ არის კრეატიულობა და ბუნდოვანი ინსტრუქციები: ”დააინსტალირეთ ის, როგორც ჩვეულებრივი Oracle, მაგრამ თქვენ უნდა მიუთითოთ რამდენიმე sysctl პარამეტრი და დაამატოთ მომხმარებლები საჭირო UID-ით. ჰკითხეთ მოქმედ ბიჭებს, იციან".

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

და რა თქმა უნდა, ჩვენ დავაჩქარეთ სერვერების ამოქმედება რამდენიმე დღიდან საათამდე.

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

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

ავტორი: სერგეი არტემოვი, დეპარტამენტის არქიტექტორი DevOps გადაწყვეტილებები "Jet Infosystems"

წყარო: www.habr.com