Yangi yil yaqinlashayotgan edi. Butun mamlakat bo'ylab bolalar allaqachon Santa Klausga xat yuborishgan yoki o'zlari uchun sovg'alar qilishgan va ularning asosiy ijrochisi, yirik chakana sotuvchilardan biri sotuvlar apotheoziga tayyorgarlik ko'rayotgan edi. Dekabr oyida uning ma'lumotlar markaziga yuk bir necha barobar ortadi. Shu bois kompaniya maʼlumotlar markazini modernizatsiya qilishga va xizmat muddati tugab borayotgan uskunalar oʻrniga bir necha oʻnlab yangi serverlarni ishga tushirishga qaror qildi. Bu aylanayotgan qor parchalari fonida ertakni tugatadi va triller boshlanadi.

Uskunalar sotuvlar cho'qqisiga chiqishdan bir necha oy oldin saytga kelgan. Operatsiyalar xizmati, albatta, ularni ishlab chiqarish muhitiga olib kirish uchun serverlarda qanday va nimani sozlashni biladi. Lekin biz buni avtomatlashtirishimiz va inson omilini bartaraf etishimiz kerak edi. Bundan tashqari, serverlar kompaniya uchun muhim bo'lgan SAP tizimlari to'plamini ko'chirishdan oldin almashtirildi.

Yangi serverlarni ishga tushirish qat'iy belgilangan muddatga bog'langan. Va uni ko'chirish milliardlab sovg'alarni jo'natish va tizimlar migratsiyasini xavf ostiga qo'yishni anglatardi. Hatto Ayoz Ota va Santa Klausdan iborat jamoa ham sanani o'zgartira olmadi - siz SAP tizimini yiliga bir marta omborni boshqarish uchun o'tkazishingiz mumkin. 31-dekabrdan 1-yanvargacha chakana sotuvchining jami 20 ta futbol maydonchasi boʻlgan ulkan omborlari 15 soatga oʻz ishini toʻxtatdi. Va bu tizimni ko'chirish uchun yagona vaqt davri. Serverlarni joriy qilishda xatolikka o'rin yo'q edi.

Aniq aytsam: mening hikoyam jamoamiz foydalanadigan vositalar va konfiguratsiyalarni boshqarish jarayonini aks ettiradi.

Konfiguratsiyani boshqarish kompleksi bir necha darajalardan iborat. Asosiy komponent CMS tizimidir. Sanoat ishlarida darajalardan birining yo'qligi muqarrar ravishda noxush mo''jizalarga olib keladi.

OS o'rnatish boshqaruvi

Birinchi daraja - jismoniy va virtual serverlarda operatsion tizimlarni o'rnatishni boshqarish tizimi. U asosiy OS konfiguratsiyalarini yaratadi, inson omilini yo'q qiladi.

Ushbu tizimdan foydalanib, biz keyingi avtomatlashtirish uchun mos OS bilan standart server nusxalarini oldik. "To'kish" paytida ular mahalliy foydalanuvchilarning minimal to'plamini va umumiy SSH kalitlarini, shuningdek, izchil OS konfiguratsiyasini oldilar. Biz serverlarni CMS orqali boshqarishimiz uchun kafolatlangan bo'lishimiz mumkin edi va OS darajasida "pastda" kutilmagan hodisalar yo'qligiga amin edik.

O'rnatishni boshqarish tizimi uchun "maksimal" vazifa serverlarni BIOS/Proshivka darajasidan OT ga avtomatik ravishda sozlashdir. Bu erda ko'p narsa jihozlar va sozlash vazifalariga bog'liq. Heterojen uskunalar uchun siz ko'rib chiqishingiz mumkin REDFISH API. Agar barcha jihozlar bitta sotuvchidan bo'lsa, unda tayyor boshqaruv vositalaridan foydalanish qulayroq bo'ladi (masalan, HP ILO Amplifier, DELL OpenManage va boshqalar).

Operatsion tizimni jismoniy serverlarga o'rnatish uchun biz operatsiya xizmati bilan kelishilgan o'rnatish profillari to'plamini belgilaydigan taniqli Cobbler-dan foydalandik. Infratuzilmaga yangi server qo'shganda, muhandis serverning MAC manzilini Cobbler'dagi kerakli profilga bog'ladi. Tarmoq orqali birinchi marta yuklanganda, server vaqtinchalik manzil va yangi operatsion tizimni oldi. Keyin u maqsadli VLAN/IP manziliga o'tkazildi va u erda ishlashni davom ettirdi. Ha, VLAN-ni o'zgartirish vaqt talab etadi va muvofiqlashtirishni talab qiladi, lekin u ishlab chiqarish muhitida serverni tasodifiy o'rnatishdan qo'shimcha himoyani ta'minlaydi.

Biz HashiSorp Packer yordamida tayyorlangan shablonlar asosida virtual serverlar yaratdik. Sababi bir xil edi: OSni o'rnatishda yuzaga kelishi mumkin bo'lgan insoniy xatolarning oldini olish. Ammo, jismoniy serverlardan farqli o'laroq, Packer PXE, tarmoqni yuklash va VLAN o'zgarishlariga bo'lgan ehtiyojni yo'q qiladi. Bu virtual serverlarni yaratishni oson va soddalashtirdi.

Guruch. 1. Operatsion tizimlarni o'rnatishni boshqarish.

Sirlarni boshqarish

Har qanday konfiguratsiyani boshqarish tizimi oddiy foydalanuvchilardan yashirilishi kerak bo'lgan, ammo tizimlarni tayyorlash uchun zarur bo'lgan ma'lumotlarni o'z ichiga oladi. Bu mahalliy foydalanuvchilar va xizmat hisoblari uchun parollar, sertifikat kalitlari, turli API tokenlari va boshqalar. Ular odatda "sirlar" deb ataladi.

Agar siz ushbu sirlarni qaerda va qanday saqlashni boshidanoq aniqlamasangiz, axborot xavfsizligi talablarining jiddiyligiga qarab, quyidagi saqlash usullari bo'lishi mumkin:

• to'g'ridan-to'g'ri konfiguratsiyani boshqarish kodida yoki ombordagi fayllarda;
• ixtisoslashtirilgan konfiguratsiyani boshqarish vositalarida (masalan, Ansible Vault);
• CI/CD tizimlarida (Jenkins/TeamCity/GitLab/va hokazo) yoki konfiguratsiyani boshqarish tizimlarida (Ansible Tower/Ansible AWX);
• sirlarni "qo'lda" ham o'tkazish mumkin. Masalan, ular belgilangan joyga joylashtiriladi va keyin ular konfiguratsiyani boshqarish tizimlari tomonidan qo'llaniladi;
• yuqoridagilarning turli xil kombinatsiyalari.

Har bir usulning o'ziga xos kamchiliklari bor. Asosiysi, sirlarga kirish siyosatining yo'qligi: ma'lum sirlardan kim foydalanishi mumkinligini aniqlash mumkin emas yoki qiyin. Yana bir kamchilik - kirish auditining yo'qligi va to'liq hayot aylanishi. Masalan, kodda va bir qator tegishli tizimlarda yozilgan ochiq kalitni qanday tezda almashtirish mumkin?

Biz HashiCorp Vault markazlashtirilgan maxfiy omboridan foydalandik. Bu bizga imkon berdi:

• sirlarni xavfsiz saqlang. Ular shifrlangan va agar kimdir Vault ma'lumotlar bazasiga kirish huquqiga ega bo'lsa ham (masalan, uni zahiradan tiklash orqali), u erda saqlangan sirlarni o'qiy olmaydi;
• sirlarga kirish siyosatini tashkil qilish. Foydalanuvchilar va ilovalar uchun faqat ularga "ajratilgan" sirlar mavjud;
• audit sirlariga kirish. Har qanday sirli harakatlar Vault audit jurnalida qayd etiladi;
• sirlar bilan ishlashning to'liq "hayot tsikli" ni tashkil qilish. Ularni yaratish, bekor qilish, amal qilish muddatini belgilash va hokazo.
• sirlarga kirishni talab qiladigan boshqa tizimlar bilan oson integratsiya;
• shuningdek, uchdan-end shifrlashdan, OT va ma'lumotlar bazasi uchun bir martalik parollardan, vakolatli markazlarning sertifikatlaridan va boshqalardan foydalaning.

Endi markaziy autentifikatsiya va avtorizatsiya tizimiga o'tamiz. Busiz qilish mumkin edi, lekin ko'plab tegishli tizimlarda foydalanuvchilarni boshqarish juda ahamiyatsiz. Biz LDAP xizmati orqali autentifikatsiya va avtorizatsiyani sozladik. Aks holda, Vault doimiy ravishda foydalanuvchilar uchun autentifikatsiya tokenlarini chiqarishi va kuzatib borishi kerak edi. Foydalanuvchilarni oʻchirish va qoʻshish esa “men hamma joyda bu foydalanuvchi hisobini yaratdimmi/oʻchirib tashladimmi?” degan savolga aylanadi.

Biz tizimimizga yana bir daraja qo'shamiz: sirlarni boshqarish va markaziy autentifikatsiya/avtorizatsiya:

Guruch. 2. Sirlarni boshqarish.

Konfiguratsiyani boshqarish

Biz asosiy narsaga - CMS tizimiga kirdik. Bizning holatda, bu Ansible va Red Hat Ansible AWX kombinatsiyasi.

Ansible o'rniga Chef, Puppet, SaltStack dan foydalanish mumkin. Biz Ansibleni bir nechta mezonlarga asoslanib tanladik.

• Birinchidan, bu ko'p qirrali. Boshqarish uchun tayyor modullar to'plami ta'sirli. Va agar sizda bu etarli bo'lmasa, siz GitHub va Galaxy-da qidirishingiz mumkin.
• Ikkinchidan, boshqariladigan uskunalarga agentlarni o'rnatish va qo'llab-quvvatlash, ular yukga xalaqit bermasligini isbotlash va "xatcho'plar" yo'qligini tasdiqlashning hojati yo'q.
• Uchinchidan, Ansible kirish uchun past to'siqga ega. Vakolatli muhandis mahsulot bilan ishlashning birinchi kunida ish kitobini tom ma'noda yozadi.

Ammo ishlab chiqarish muhitida faqat Ansible biz uchun etarli emas edi. Aks holda, kirishni cheklash va administrator harakatlarini tekshirish bilan bog'liq ko'plab muammolar paydo bo'ladi. Qanday qilib kirishni cheklash mumkin? Axir, har bir bo'lim uchun "o'z" serverlar to'plamini boshqarish (o'qing: Ansible o'yin kitobini ishga tushirish) kerak edi. Qanday qilib faqat ma'lum xodimlarga Ansible o'yin kitoblarini ishlatishga ruxsat berish mumkin? Yoki Ansible bilan ishlaydigan serverlar va uskunalarda ko'plab mahalliy bilimlarni o'rnatmasdan o'yin kitobini kim ishga tushirganini qanday kuzatish mumkin?

Bunday muammolarning eng katta ulushi Red Hat tomonidan hal qilinadi Ansible Tower, yoki uning ochiq manbali upstream loyihasi Ansible AWX. Shuning uchun biz mijoz uchun uni afzal ko'rdik.

Va CMS tizimimizning portretiga yana bir teginish. Ansible playbook kodlar omborini boshqarish tizimlarida saqlanishi kerak. Bizda bor GitLab CE.

Shunday qilib, konfiguratsiyalar o'zlari Ansible/Ansible AWX/GitLab kombinatsiyasi tomonidan boshqariladi (3-rasmga qarang). Albatta, AWX/GitLab yagona autentifikatsiya tizimi bilan, Ansible playbook esa HashiCorp Vault bilan birlashtirilgan. Konfiguratsiyalar ishlab chiqarish muhitiga faqat Ansible AWX orqali kiradi, unda barcha "o'yin qoidalari" ko'rsatilgan: kim nimani sozlashi mumkin, CMS uchun konfiguratsiyani boshqarish kodini qaerdan olish kerak va hokazo.

Guruch. 3. Konfiguratsiyani boshqarish.

Test boshqaruvi

Bizning konfiguratsiyamiz kod shaklida taqdim etiladi. Shuning uchun biz dasturiy ta'minot ishlab chiquvchilari bilan bir xil qoidalar bilan o'ynashga majburmiz. Biz ishlab chiqarish serverlariga konfiguratsiya kodini ishlab chiqish, uzluksiz sinovdan o'tkazish, yetkazib berish va qo'llash jarayonlarini tashkil qilishimiz kerak edi.

Agar bu darhol bajarilmasa, konfiguratsiya uchun yozilgan rollar qo'llab-quvvatlanmaydi va o'zgartirilmaydi yoki ishlab chiqarishda ishga tushirilmaydi. Bu og'riqning davosi ma'lum va bu loyihada o'zini isbotladi:

• har bir rol birlik testlari bilan qoplangan;
• konfiguratsiyalarni boshqaradigan kodda har qanday o'zgarishlar bo'lsa, testlar avtomatik ravishda amalga oshiriladi;
• konfiguratsiyani boshqarish kodidagi o'zgarishlar faqat barcha testlar va kodni tekshirishdan muvaffaqiyatli o'tgandan keyin ishlab chiqarish muhitiga chiqariladi.

Kodni ishlab chiqish va konfiguratsiyani boshqarish tinchroq va oldindan aytish mumkin bo'ldi. Uzluksiz testlarni tashkil qilish uchun biz GitLab CI/CD asboblar to'plamidan foydalandik va oldik Ansible molekula.

Har doim konfiguratsiyani boshqarish kodida o'zgarishlar bo'lsa, GitLab CI/CD Molecule-ni chaqiradi:

• kod sintaksisini tekshiradi,
• Docker konteynerini ko'taradi,
• o'zgartirilgan kodni yaratilgan konteynerga qo'llaydi,
• rolni idempotentlik uchun tekshiradi va ushbu kod uchun testlarni o'tkazadi (bu erda granularlik aniq rol darajasida, 4-rasmga qarang).

Biz Ansible AWX yordamida konfiguratsiyalarni ishlab chiqarish muhitiga yetkazib berdik. Operatsion muhandislari oldindan belgilangan andozalar orqali konfiguratsiya o'zgarishlarini qo'lladilar. AWX har safar ishlatilganda GitLab master filialidan kodning so'nggi versiyasini mustaqil ravishda "so'ragan". Shunday qilib, biz ishlab chiqarish muhitida sinovdan o'tmagan yoki eskirgan koddan foydalanishni istisno qildik. Tabiiyki, kod faqat sinov, ko'rib chiqish va tasdiqlashdan so'ng master filialiga kirdi.

Guruch. 4. GitLab CI/CD-da rollarni avtomatik sinovdan o'tkazish.

Ishlab chiqarish tizimlarining ishlashi bilan bog'liq muammo ham mavjud. Haqiqiy hayotda faqat CMS kodi orqali konfiguratsiyani o'zgartirish juda qiyin. Favqulodda vaziyatlar muhandis konfiguratsiyani "bu erda va hozir" o'zgartirishi kerak bo'lganda, kodni tahrirlash, sinovdan o'tkazish, tasdiqlash va hokazolarni kutmasdan paydo bo'ladi.

Natijada, qo'lda o'zgartirishlar tufayli, bir xil turdagi uskunalardagi konfiguratsiyada nomuvofiqliklar paydo bo'ladi (masalan, sysctl sozlamalari HA klaster tugunlarida boshqacha tarzda tuzilgan). Yoki uskunadagi haqiqiy konfiguratsiya CMS kodida ko'rsatilganidan farq qiladi.

Shuning uchun, uzluksiz sinovdan tashqari, biz konfiguratsiyadagi nomuvofiqliklar uchun ishlab chiqarish muhitini tekshiramiz. Biz eng oddiy variantni tanladik: CMS konfiguratsiya kodini "quruq ishga tushirish" rejimida ishga tushirish, ya'ni o'zgarishlarni qo'llamasdan, lekin rejalashtirilgan va haqiqiy konfiguratsiya o'rtasidagi barcha tafovutlar haqida xabar berish bilan. Biz buni ishlab chiqarish serverlarida "-check" opsiyasi bilan barcha Ansible o'yin kitoblarini vaqti-vaqti bilan ishga tushirish orqali amalga oshirdik. Har doimgidek, Ansible AWX o'yin kitobini ishga tushirish va yangilab turish uchun javobgardir (5-rasmga qarang):

Guruch. 5. Ansible AWX da konfiguratsiya nomuvofiqliklarini tekshiradi.

Tekshiruvdan so'ng, AWX administratorlarga nomuvofiqlik hisobotini yuboradi. Ular muammoli konfiguratsiyani o'rganadilar va keyin uni sozlangan o'yin kitoblari orqali tuzatadilar. Biz ishlab chiqarish muhitida konfiguratsiyani shunday saqlab turamiz va CMS har doim yangilanadi va sinxronlashtiriladi. Bu "ishlab chiqarish" serverlarida CMS kodi ishlatilganda yoqimsiz "mo''jizalar" ni yo'q qiladi.

Endi bizda Ansible AWX/GitLab/Molecule dan iborat muhim sinov qatlami mavjud (6-rasm).

Guruch. 6. Testlarni boshqarish.

Qiyinmi? Bahslashmayman. Ammo konfiguratsiyani boshqarishning bunday kompleksi server konfiguratsiyasini avtomatlashtirish bilan bog'liq ko'plab savollarga to'liq javob bo'ldi. Endi chakana sotuvchining standart serverlari har doim qat'iy belgilangan konfiguratsiyaga ega. CMS, muhandisdan farqli o'laroq, kerakli sozlamalarni qo'shishni, foydalanuvchilarni yaratishni va o'nlab yoki yuzlab kerakli sozlamalarni bajarishni unutmaydi.

Bugungi kunda serverlar va muhitlar sozlamalarida "maxfiy bilim" yo'q. Barcha kerakli xususiyatlar o'yin kitobida aks ettirilgan. Endi ijodkorlik va noaniq ko'rsatmalar yo'q: "Uni oddiy Oracle kabi o'rnating, lekin siz bir nechta sysctl sozlamalarini belgilashingiz va kerakli UIDga ega foydalanuvchilarni qo'shishingiz kerak. Ishlayotgan yigitlardan so'rang, ular bilishadi".

Konfiguratsiyadagi nomuvofiqliklarni aniqlash va ularni faol ravishda tuzatish qobiliyati xotirjamlikni ta'minlaydi. Konfiguratsiyani boshqarish tizimi bo'lmasa, bu odatda boshqacha ko'rinadi. Muammolar bir kun ishlab chiqarishga "otish" ga qadar to'planadi. Keyin brifing o'tkaziladi, konfiguratsiyalar tekshiriladi va tuzatiladi. Va tsikl yana takrorlanadi

Va, albatta, biz serverlarni ishga tushirishni bir necha kundan bir necha soatgacha tezlashtirdik.

Yangi yil arafasida, bolalar quvonch bilan sovg'alarni ochishayotganda va kattalar qo'ng'iroq chalinayotganda tilaklar bildirayotganda, bizning muhandislarimiz SAP tizimini yangi serverlarga o'tkazdilar. Hatto Santa Klaus ham eng yaxshi mo''jizalar yaxshi tayyorlangan mo''jizalar ekanligini aytadi.

PS Bizning jamoamiz ko'pincha mijozlar konfiguratsiyani boshqarish muammolarini iloji boricha sodda tarzda hal qilishni xohlashlariga duch keladi. Ideal holda, xuddi sehr bilan - bitta vosita bilan. Ammo hayotda hamma narsa murakkabroq (ha, kumush o'qlar yana etkazib berilmadi): siz mijoz jamoasi uchun qulay bo'lgan vositalar yordamida butun jarayonni yaratishingiz kerak.

Muallif: Sergey Artemov, bo'lim arxitektori DevOps yechimlari "Jet Infotizimlari"

Manba: www.habr.com