Agar sizning IT infratuzilmangiz juda tez rivojlansa, siz ertami-kechmi tanlovga duch kelasiz: uni qo'llab-quvvatlash uchun inson resurslarini chiziqli ravishda oshirish yoki avtomatlashtirishni boshlash. Bir nuqtaga qadar biz birinchi paradigmada yashadik va keyin Infratuzilma-kodga bo'lgan uzoq yo'l boshlandi.
Albatta, NSPK startap emas, lekin kompaniyada bunday muhit uning mavjudligining birinchi yillarida hukmronlik qilgan va bu juda qiziqarli yillar edi. Ismim , Men 10 yildan ortiq vaqtdan beri mavjudlik talablari yuqori bo'lgan Linux infratuzilmasini qo'llab-quvvatlayman. U 2016 yil yanvar oyida NSPK jamoasiga qo'shildi va afsuski, kompaniya mavjudligining eng boshlanishini ko'rmadi, lekin katta o'zgarishlar bosqichiga keldi.
Umuman olganda, jamoamiz kompaniya uchun 2 ta mahsulot yetkazib beradi, deyishimiz mumkin. Birinchisi, infratuzilma. Pochta ishlashi kerak, DNS ishlashi kerak va domen boshqaruvchilari sizni buzilmasligi kerak bo'lgan serverlarga kirishga ruxsat berishlari kerak. Kompaniyaning IT landshafti juda katta! Bu biznes va missiya uchun muhim tizimlar, ba'zilari uchun mavjudlik talablari 99,999. Ikkinchi mahsulot - serverlarning o'zlari, jismoniy va virtual. Mavjudlarini kuzatib borish kerak, yangilari esa ko'plab bo'limlardan mijozlarga muntazam ravishda etkazib berilishi kerak. Ushbu maqolada men serverning hayot aylanishi uchun javobgar bo'lgan infratuzilmani qanday ishlab chiqqanimizga e'tibor qaratmoqchiman.
Safarning boshlanishi
Sayohatimizning boshida bizning texnologiya to'plamimiz quyidagicha ko'rinardi:
OS CentOS 7
FreeIPA domen kontrollerlari
Avtomatlashtirish - Ansible(+Tower), Cobbler
Bularning barchasi bir nechta ma'lumotlar markazlarida tarqalgan 3 domenda joylashgan edi. Bitta ma'lumot markazida ofis tizimlari va test saytlari, qolganlarida PROD mavjud.
Bir vaqtning o'zida serverlarni yaratish quyidagicha ko'rinardi:
VM shablonida CentOS minimal va talab qilinadigan minimum to'g'ri /etc/resolv.conf ga o'xshaydi, qolganlari Ansible orqali keladi.
CMDB - Excel.
Agar server jismoniy bo'lsa, virtual mashinadan nusxa ko'chirish o'rniga, OS Cobbler yordamida o'rnatildi - maqsadli serverning MAC manzillari Cobbler konfiguratsiyasiga qo'shiladi, server DHCP orqali IP manzilini oladi, keyin esa OS. qo'shiladi.
Dastlab biz Cobbler-da qandaydir konfiguratsiyani boshqarishga harakat qildik. Ammo vaqt o'tishi bilan bu boshqa ma'lumotlar markazlariga ham, VMlarni tayyorlash uchun Ansible kodiga ham konfiguratsiyalarni ko'chirish bilan bog'liq muammolarni keltirib chiqara boshladi.
O'sha paytda ko'pchiligimiz Ansible-ni Bash-ning qulay kengaytmasi sifatida qabul qildik va shell va sed-dan foydalangan holda dizaynlarni kamaytirmadik. Umumiy Bashsible. Bu oxir-oqibat, agar biron sababga ko'ra o'yin kitobi serverda ishlamasa, serverni o'chirish, o'yin kitobini tuzatish va uni qayta ishga tushirish osonroq bo'lishiga olib keldi. Aslida skriptlarning versiyalari, konfiguratsiyalarning ko'chishi yo'q edi.
Misol uchun, biz barcha serverlarda ba'zi konfiguratsiyalarni o'zgartirmoqchi edik:
- Biz mantiqiy segment/ma'lumotlar markazidagi mavjud serverlardagi konfiguratsiyani o'zgartiramiz. Ba'zan bir kunda emas - mavjudlik talablari va katta raqamlar qonuni barcha o'zgarishlarni bir vaqtning o'zida qo'llashga imkon bermaydi. Va ba'zi o'zgarishlar potentsial halokatli va biror narsani qayta ishga tushirishni talab qiladi - xizmatlardan OSning o'zigacha.
- Uni Ansible-da tuzatish
- Biz uni Cobbler-da tuzatamiz
- Har bir mantiqiy segment/ma'lumotlar markazi uchun N marta takrorlang
Barcha o'zgarishlar muammosiz o'tishi uchun ko'plab omillarni hisobga olish kerak edi va o'zgarishlar doimiy ravishda sodir bo'ladi.
- Aniq kodni, konfiguratsiya fayllarini qayta tiklash
- Ichki eng yaxshi amaliyotlarni o'zgartirish
- Voqealarni/baxtsiz hodisalarni tahlil qilish natijalariga ko'ra o'zgarishlar
- Ichki va tashqi xavfsizlik standartlarini o'zgartirish. Masalan, PCI DSS har yili yangi talablar bilan yangilanadi
Infratuzilmaning o'sishi va sayohatning boshlanishi
Serverlar/mantiqiy domenlar/ma'lumotlar markazlari soni o'sdi va ular bilan birga konfiguratsiyalardagi xatolar soni oshdi. Bir nuqtada biz konfiguratsiya boshqaruvini ishlab chiqish kerak bo'lgan uchta yo'nalishga keldik:
- Avtomatlashtirish. Takroriy operatsiyalarda inson xatosidan iloji boricha qochish kerak.
- Takroriylik. Infratuzilmani bashorat qilish mumkin bo'lganda boshqarish ancha oson. Serverlarning konfiguratsiyasi va ularni tayyorlash vositalari hamma joyda bir xil bo'lishi kerak. Bu mahsulot guruhlari uchun ham muhimdir - sinovdan so'ng dastur sinov muhitiga o'xshash tarzda tuzilgan ishlab chiqarish muhitida tugashiga kafolat berilishi kerak.
- Konfiguratsiyani boshqarishga o'zgartirish kiritishning soddaligi va shaffofligi.
Bir nechta vositalarni qo'shish qoladi.
Biz GitLab CE ni kodlar ombori sifatida tanladik, lekin uning o'rnatilgan CI/CD modullari uchun emas.
Sirlar ombori - Hashicorp Vault, shu jumladan. ajoyib API uchun.
Sinov konfiguratsiyasi va muhim rollar - Molecule + Testinfra. Aniq mitogenga ulansangiz, testlar tezroq ketadi. Shu bilan birga, biz avtomatik joylashtirish uchun o'zimizning CMDB va orkestrimizni yozishni boshladik (Cobbler-ning yuqoridagi rasmda), ammo bu mening hamkasbim va ushbu tizimlarning asosiy ishlab chiqaruvchisi kelajakda aytib beradigan mutlaqo boshqa voqea.
Bizning tanlovimiz:
Molekula + Testinfra
Ansible + Tower + AWX
Serverlar dunyosi + DITNET (o'z ishlanmasi)
Paxtakor
Gitlab + GitLab yuguruvchisi
Hashicorp ombori
Aytgancha, mantiqiy rollar haqida. Avvaliga faqat bittasi bor edi, biroq bir necha refaktoringlardan so'ng ularning soni 17 taga yetdi.Men monolitni alohida ishga tushirilishi mumkin bo'lgan idempotent rollarga ajratishni qat'iy tavsiya qilaman; qo'shimcha ravishda teglar qo'shishingiz mumkin. Biz rollarni funksionallik bo'yicha ajratdik - tarmoq, jurnallar, paketlar, apparat, molekula va boshqalar. Umuman olganda, biz quyidagi strategiyaga amal qildik. Men bu yagona haqiqat ekanligini ta'kidlamayman, lekin bu biz uchun ishladi.
- "Oltin tasvir" dan serverlarni nusxalash yomon!Asosiy kamchilik shundaki, siz tasvirlar hozir qanday holatda ekanligini aniq bilmaysiz va barcha o'zgarishlar barcha virtualizatsiya fermalarida barcha tasvirlarga tushadi.
- Standart konfiguratsiya fayllarini minimal darajada foydalaning va boshqa bo'limlar bilan asosiy tizim fayllari uchun javobgar ekanligingizga rozi bo'ling, masalan:
- /etc/sysctl.conf ni bo'sh qoldiring, sozlamalar faqat /etc/sysctl.d/ da bo'lishi kerak. Bir faylda sizning standartingiz, boshqasida ilova uchun moslashtirilgan.
- Tizim birliklarini tahrirlash uchun bekor qilish fayllaridan foydalaning.
- Barcha konfiguratsiyalarni shablonga kiriting va ularni to'liq qo'shing; iloji bo'lsa, o'yin kitoblarida sed yoki uning analoglari yo'q
- Konfiguratsiyani boshqarish tizimi kodini qayta tiklash:
- Vazifalarni mantiqiy ob'ektlarga bo'ling va monolitni rollarga qayta yozing
- Linterlardan foydalaning! Ansible-lint, yaml-lint va boshqalar
- Yondashuvingizni o'zgartiring! Hechqisi yo'q. Tizimning holatini tavsiflash kerak
- Barcha Ansible rollari uchun siz molekulada testlar yozishingiz va kuniga bir marta hisobot yaratishingiz kerak.
- Bizning holatda, testlarni tayyorlashdan so'ng (ulardan 100 dan ortiq) 70000 XNUMX ga yaqin xatoliklar aniqlandi. Uni tuzatish uchun bir necha oy kerak bo'ldi.
Bizning amalga oshirishimiz
Shunday qilib, aniq rollar tayyor, shablonlangan va linterlar tomonidan tekshirilgan. Va hatto gits ham hamma joyda ko'tariladi. Ammo kodni turli segmentlarga ishonchli etkazib berish masalasi ochiq qoldi. Biz skriptlar bilan sinxronlashtirishga qaror qildik. Shunga o'xshaydi:
O'zgarishlar kelgandan so'ng, CI ishga tushiriladi, test serveri yaratiladi, rollar chiqariladi va molekula tomonidan sinovdan o'tkaziladi. Agar hamma narsa yaxshi bo'lsa, kod ishlab chiqarish bo'limiga o'tadi. Ammo biz mashinadagi mavjud serverlarga yangi kodni qo'llamaymiz. Bu bizning tizimlarimizning yuqori darajada mavjudligi uchun zarur bo'lgan o'ziga xos to'xtatuvchidir. Infratuzilma ulkanlashganda esa katta sonlar qonuni kuchga kiradi – o‘zgarish zararsiz ekanligiga ishonchingiz komil bo‘lsa ham, bu dahshatli oqibatlarga olib kelishi mumkin.
Bundan tashqari, serverlarni yaratish uchun ko'plab variantlar mavjud. Biz maxsus Python skriptlarini tanladik. Va CI ansible uchun:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Biz shunday holatga keldik, tizim yashashda va rivojlanishda davom etmoqda.
- 17 Serverni o'rnatish uchun qulay rollar. Rollarning har biri alohida mantiqiy vazifani hal qilish uchun mo'ljallangan (ro'yxatga olish, audit, foydalanuvchi avtorizatsiyasi, monitoring va boshqalar).
- Rol testi. Molekula + TestInfra.
- Shaxsiy ishlanma: CMDB + Orchestrator.
- Serverni yaratish vaqti ~30 minut, avtomatlashtirilgan va amalda vazifa navbatidan mustaqil.
- Barcha segmentlarda infratuzilmaning bir xil holati/nomlanishi - o'yin kitoblari, omborlar, virtualizatsiya elementlari.
- Standartga nomuvofiqliklar to'g'risida hisobotlar yaratish bilan server holatini har kuni tekshirish.
Umid qilamanki, mening hikoyam sayohatning boshida turganlar uchun foydali bo'ladi. Siz qanday avtomatlashtirish to'plamidan foydalanasiz?
Manba: www.habr.com