Bu nutqning stenogrammasi ΠΈ .
Bu o'z-o'zidan yozilgan konfiguratsiyani boshqarish tizimidan foydalangan loyihaning hikoyasi va nima uchun Ansible-ga o'tish 18 oy davom etdi.
Kun β -XXX: Boshlanishdan oldin
Dastlab, infratuzilma Hyper-V bilan ishlaydigan ko'plab alohida xostlardan iborat edi. Virtual mashinani yaratish juda ko'p bosqichlarni talab qildi: disklarni to'g'ri joyga qo'yish, DNS-ni ro'yxatdan o'tkazish, DHCP-ni zaxiralash, VM konfiguratsiyasini git omboriga qo'yish. Bu jarayon qisman mexanizatsiyalashgan, lekin masalan, VMlar xostlar o'rtasida qo'lda taqsimlangan. Ammo, masalan, ishlab chiquvchilar git-da VM konfiguratsiyasini tuzatishi va uni VMni qayta ishga tushirish orqali qo'llashi mumkin.
Maxsus konfiguratsiyani boshqarish yechimi
Asl g'oya, menimcha, IaC sifatida ishlab chiqilgan: ko'plab fuqaroligi bo'lmagan VMlar qayta ishga tushirilganda o'z holatini nolga qaytaradi. VM konfiguratsiyasini boshqarish nima edi? Sxematik jihatdan oddiy ko'rinadi:
- VM uchun statik MAC o'rnatildi.
- VM ga CoreOS bilan ISO va yuklash diski ulangan.
- CoreOS xususiylashtirish skriptini IP-ga asoslangan WEB-serverdan yuklab olish orqali ishga tushiradi.
- Skript VM konfiguratsiyasini IP-manzil asosida SCP orqali yuklaydi.
- Systemd birligi fayllarining oyoq kiyimi va bash skriptlarining oyoq kiyimi ishga tushirildi.
Ushbu yechim ko'plab aniq muammolarga ega edi:
- CoreOS ISO eskirgan.
- VMlarni ko'chirish/yaratishda juda ko'p murakkab avtomatlashtirilgan harakatlar va sehr.
- Yangilashda qiyinchilik va dasturiy ta'minotning ma'lum bir versiyasi kerak bo'lganda. Yadro modullari bilan yanada qiziqarli.
- VMlar ma'lumotlarsiz olinmagan, ya'ni. VMlar qo'shimcha foydalanuvchi ma'lumotlari o'rnatilgan disk bilan paydo bo'ldi.
- Kimdir doimiy ravishda tizim birligining bog'liqligini buzardi va CoreOS qayta ishga tushirilganda muzlab qoladi. CoreOS-dagi mavjud vositalar yordamida buni ushlash qiyin edi.
- Sirlarni boshqarish.
- CM yo'q edi. CoreOS uchun bash va YML konfiguratsiyalari mavjud edi.
VM konfiguratsiyasini qo'llash uchun uni qayta ishga tushirishingiz kerak, lekin u qayta yoqilmasligi mumkin. Bu aniq muammo kabi ko'rinadi, lekin doimiy disklar yo'q - jurnallarni saqlash uchun hech qanday joy yo'q. Xo'sh, keling, jurnallar yuborilishi uchun yadro yuklash variantini qo'shishga harakat qilaylik. Lekin yo'q, hammasi qanchalik murakkab.
0-kun: Muammoni tan oling
Bu odatiy rivojlanish infratuzilmasi edi: jenkins, test muhiti, monitoring, ro'yxatga olish. CoreOS k8s klasterlarini joylashtirish uchun mo'ljallangan, ya'ni. muammo CoreOS qanday ishlatilganligi edi. Birinchi qadam stackni tanlash edi. Biz qaror qildik:
- CentOs asosiy taqsimot sifatida, chunki Bu ishlab chiqarish muhitiga eng yaqin taqsimot.
- E'tirof etiladi konfiguratsiyani boshqarish uchun, chunki Bu borada keng ko'lamli tekshiruvlar o'tkazildi.
- Jenkins mavjud jarayonlarni avtomatlashtirish uchun asos sifatida, chunki u allaqachon rivojlanish jarayonlari uchun faol foydalanilgan
- Hyper-V virtualizatsiya platformasi sifatida. Hikoya doirasidan tashqariga chiqadigan bir qator sabablar bor, lekin qisqasi - biz bulutlardan foydalana olmaymiz, biz o'z uskunamizdan foydalanishimiz kerak.
30-kun: Mavjud shartnomalarni tuzatish - Kodeks sifatida shartnomalar
Stack aniq bo'lgach, harakatga tayyorgarlik boshlandi. Mavjud shartnomalarni kod shaklida tuzatish (Kod sifatida shartnomalar!). O'tish qo'l mehnati -> mexanizatsiyalash -> avtomatlashtirish.
1. VM larni sozlash
Ansible bu ishni ajoyib qiladi. Minimal tana harakati bilan siz VM konfiguratsiyasini nazorat qilishingiz mumkin:
- Git omborini yarating.
- Biz VMlar ro'yxatini inventarga, konfiguratsiyalarni o'yin kitoblariga va rollarga joylashtiramiz.
- Biz Ansible-ni ishga tushirishingiz mumkin bo'lgan maxsus jenkins qulini o'rnatmoqdamiz.
- Biz ish yaratamiz va Jenkinsni sozlaymiz.
Birinchi jarayon tayyor. Shartnomalar qat'iy belgilangan.
2. Yangi VM yarating
Bu erda hamma narsa juda qulay emas edi. Linuxdan Hyper-V da VM yaratish unchalik qulay emas. Ushbu jarayonni mexanizatsiyalashga urinishlardan biri:
- Ansbile WinRM orqali Windows xostiga ulanadi.
- Ansible powershell skriptini ishga tushiradi.
- Powershell skripti yangi VM yaratadi.
- Hyper-V/ScVMM yordamida mehmon operatsion tizimida VM yaratishda xost nomi sozlanadi.
- DHCP ijarasini yangilashda VM o'zining xost nomini yuboradi.
- Domen tekshiruvi tomonidagi standart ddns va dhcp integratsiyasi DNS yozuvini sozlaydi.
- Siz o'zingizning inventaringizga VM qo'shishingiz va uni Ansible bilan sozlashingiz mumkin.
3.VM shablonini yarating
Ular bu erda hech narsa ixtiro qilishmadi - ular qadoqlash mashinasini olib ketishdi.
- Git omboriga paketlovchi, kickstart konfiguratsiyasini qo'shing.
- Hyper-v va Packer bilan maxsus jenkins slaveni o'rnatish.
- Biz ish yaratamiz va Jenkinsni sozlaymiz.
Ushbu havola qanday ishlaydi:
- Packer bo'sh VM yaratadi va ISOni oladi.
- VM ishga tushadi, Packer yuklash qurilmasiga floppi yoki http dan kickstart faylimizdan foydalanish buyrug'ini kiritadi.
- Anaconda bizning konfiguratsiyamiz bilan ishga tushirildi va OSning dastlabki konfiguratsiyasi bajarildi.
- Packer VM mavjud bo'lishini kutadi.
- VM ichidagi Packer mahalliy rejimda ishlaydi.
- Ansible β1 bosqichda ishlaydigan rollardan foydalanadi.
- Packer VM shablonini eksport qiladi.
75-kun: Shartnomani buzmasdan o'zgartiring = Test ansible + Testkitchen
Koddagi konventsiyalarni yozib olish etarli bo'lmasligi mumkin. Axir, agar jarayonning nozik tomonlarida biror narsani o'zgartirmoqchi bo'lsangiz, nimanidir buzishingiz mumkin. Shuning uchun, infratuzilma holatida, aynan shu infratuzilmani sinovdan o'tkazish paydo bo'ladi. Jamoa ichidagi bilimlarni sinxronlashtirish uchun biz Ansible rollarini sinab ko'rishni boshladik. Men chuqurroq kirmayman, chunki ... o'sha paytdagi voqealarni tasvirlaydigan maqola bor (spoiler bu oxirgi versiya emas edi va keyinchalik hamma narsa murakkablashdi ).
130-kun: Balki CentOS+ansible kerak emasmi? ehtimol openshift?
Biz tushunishimiz kerakki, infratuzilmani joriy etish jarayoni yagona bo'lmagan va yon kichik loyihalar ham mavjud edi. Misol uchun, bizning ilovamizni openshift rejimida ishga tushirish bo'yicha so'rov keldi va bu bir haftadan ko'proq vaqt davomida izlanishlarga olib keldi bu harakatlanish jarayonini sekinlashtirdi. Natija shuni ko'rsatdiki, openshift barcha ehtiyojlarni qoplamaydi, sizga haqiqiy apparat yoki hech bo'lmaganda yadro bilan o'ynash qobiliyati kerak.
170-kun: Openshift mos emas, keling, Windows Azure Pack bilan imkoniyatdan foydalanaylikmi?
Hyper-V unchalik samimiy emas, SCVMM uni yaxshiroq qilmaydi. Ammo Windows Azure Pack kabi narsa bor, u SCVMM-ga qo'shimcha bo'lib, Azure-ni taqlid qiladi. Lekin, aslida, mahsulot tashlab ketilgan ko'rinadi: hujjatlarda havolalar buzilgan va juda siyrak. Ammo bizning bulutimiz hayotini soddalashtirish variantlarini o'rganish doirasida ular buni ham ko'rib chiqdilar.
250-kun: Windows Azure Pack unchalik yaxshi emas. Biz SCVMM da qolamiz
Windows Azure Pack istiqbolli ko'rinardi, ammo keraksiz xususiyatlar uchun WAP-ni o'zining murakkabligi bilan tizimga kiritmaslikka qaror qilindi va SCVMM-da qoldi.
β360 kun: filni bo'lak-bo'lak eyish
Faqat bir yil o'tgach, ko'chib o'tish uchun platforma tayyor bo'ldi va ko'chirish jarayoni boshlandi. Shu maqsadda S.M.A.R.T o'rnatildi. vazifa. Biz barcha VM-larni tekshirib chiqdik va konfiguratsiyani birma-bir aniqlay boshladik, uni Ansible-da tasvirlab berdik va testlar bilan qamrab oldik.
450-kun: Siz qanday tizimni oldingiz?
Jarayonning o'zi qiziq emas. Bu odatiy holdir, shuni ta'kidlash mumkinki, konfiguratsiyalarning aksariyati nisbatan sodda yoki izomorf edi va Pareto printsipiga ko'ra, VM konfiguratsiyasining 80% 20% vaqtni talab qiladi. Xuddi shu printsipga ko'ra, vaqtning 80% harakatni tayyorlashga va faqat 20% harakatning o'ziga sarflangan.
β540-kun: Final
18 oy ichida nima bo'ldi?
- Shartnomalar kodga aylandi.
- Qo'l mehnati -> Mexanizatsiyalash -> Avtomatlashtirish.
ishoratlar
Manba: www.habr.com