Ushbu maqola "Tarmoq infratuzilmangizni qanday nazorat qilish kerak" turkumidagi oltinchi maqoladir. Seriyadagi barcha maqolalarning mazmuni va havolalarni topishingiz mumkin .
Bir nechta mavzularni ortda qoldirib, yangi bobni boshlashga qaror qildim.
Birozdan keyin xavfsizlik xizmatiga qaytaman. Bu erda men oddiy, ammo samarali yondashuvni muhokama qilmoqchiman, men ishonamanki, u yoki bu shaklda ko'pchilik uchun foydali bo'lishi mumkin. Bu avtomatlashtirish muhandisning hayotini qanday o'zgartirishi haqida qisqacha hikoya. Biz shablonlardan foydalanish haqida gaplashamiz. Oxirida mening loyihalarim ro'yxati bor, unda siz bu erda tasvirlangan hamma narsa qanday ishlashini ko'rishingiz mumkin.
Tarmoq uchun DevOps
Skript yordamida konfiguratsiyani yaratish, IT infratuzilmasidagi o'zgarishlarni boshqarish uchun GIT-dan foydalanish, masofaviy "yuklash" - bu g'oyalar DevOps yondashuvini texnik amalga oshirish haqida o'ylaganingizda birinchi bo'lib keladi. Afzalliklari aniq. Lekin, afsuski, kamchiliklari ham bor.
5 yildan ko'proq vaqt oldin bizning dasturchilarimiz bizga, tarmoqchilarga ushbu takliflar bilan kelganlarida, biz xursand bo'lmadik.
Aytishim kerakki, biz 10 ga yaqin turli sotuvchilarning uskunalaridan iborat bo'lgan juda rang-barang tarmoqni meros qilib oldik. Sevimli cli orqali ba'zi narsalarni sozlash qulay edi, ammo boshqalarida biz GUI-dan foydalanishni afzal ko'rdik. Bundan tashqari, "jonli" uskunada uzoq vaqt ishlash bizni real vaqtda boshqarishga o'rgatdi. Masalan, o'zgartirishlar kiritishda men to'g'ridan-to'g'ri klip orqali ishlashni ancha qulay his qilaman. Shunday qilib, men tezda nimadir noto'g'ri ketganini ko'raman va o'zgarishlarni orqaga qaytaraman. Bularning barchasi ularning g'oyalariga zid edi.
Boshqa savollar ham tug'iladi, masalan, interfeys dasturiy ta'minot versiyasidan biroz o'zgarishi mumkin. Bu sizning skriptingiz noto'g'ri "konfiguratsiya" ni yaratishga olib keladi. Men ishlab chiqarishni "yugurish" uchun ishlatishni xohlamayman.
Yoki konfiguratsiya buyruqlari to'g'ri qo'llanilganligini qanday tushunish mumkin va xatolik yuz berganda nima qilish kerak?
Men bu muammolarning barchasini hal qilib bo'lmaydigan deb aytmoqchi emasman. Shunchaki "A" deb aytish, ehtimol "B" deyish mantiqan to'g'ri keladi va agar siz ishlab chiqishda bo'lgani kabi o'zgarishlarni boshqarish uchun bir xil jarayonlardan foydalanmoqchi bo'lsangiz, ishlab chiqarishga qo'shimcha ravishda ishlab chiqarish va sahnalashtirish muhitiga ega bo'lishingiz kerak. Keyin bu yondashuv to'liq ko'rinadi. Lekin bu qancha turadi?
Kamchiliklar amalda tekislangan va faqat afzalliklar qoladigan bitta holat mavjud. Men dizayn ishlari haqida gapiryapman.
Loyiha
So'nggi ikki yil davomida men yirik provayder uchun ma'lumotlar markazini qurish loyihasida ishtirok etyapman. Men ushbu loyihada F5 va Palo Alto uchun javobgarman. Cisco nuqtai nazaridan, bu "uchinchi tomon uskunalari".
Shaxsan men uchun bu loyihada ikkita alohida bosqich bor.
Birinchi bosqich
Birinchi yili men cheksiz band bo'ldim, kechalari va dam olish kunlari ishladim. Boshimni ko‘tarolmadim. Rahbariyat va mijozning bosimi kuchli va doimiy edi. Doimiy rejimda men jarayonni optimallashtirishga harakat qila olmadim. Bu nafaqat jihozlarning konfiguratsiyasi, balki dizayn hujjatlarini tayyorlash edi.
Birinchi sinovlar boshlandi, qancha kichik xato va noaniqliklarga yo'l qo'yilganiga hayron bo'lardim. Albatta, hamma narsa ishladi, lekin nomda etishmayotgan harf bor edi, buyruqda etishmayotgan qator bor edi ... Sinovlar davom etdi va men allaqachon xatolar, testlar va hujjatlar bilan doimiy, kundalik kurashda edim. .
Bu bir yil davom etdi. Loyiha, men tushunganimdek, hamma uchun oson emas edi, lekin asta-sekin mijoz tobora ko'proq qoniqish hosil qildi va bu odatdagi ishlarning bir qismini o'z zimmasiga olishga qodir bo'lgan qo'shimcha muhandislarni yollashga imkon berdi.
Endi biz bir oz atrofga qarashimiz mumkin edi.
Va bu ikkinchi bosqichning boshlanishi edi.
Ikkinchi bosqich
Jarayonni avtomatlashtirishga qaror qildim.
O'sha paytda ishlab chiquvchilar bilan bo'lgan muloqotimdan shuni tushundimki (va biz hurmat qilishimiz kerak, bizda kuchli jamoa bor edi) matn formati, bir qarashda DOS operatsion tizimi olamidan biror narsa kabi ko'rinsa ham, raqamga ega. qimmatli xususiyatlaridan.
Masalan, agar siz GIT va uning barcha hosilalaridan to'liq foydalanmoqchi bo'lsangiz, matn formati foydali bo'ladi. Va men xohlardim.
Xo'sh, siz shunchaki konfiguratsiya yoki buyruqlar ro'yxatini saqlashingiz mumkindek tuyuladi, ammo o'zgartirishlar kiritish juda noqulay. Bundan tashqari, dizayn paytida yana bir muhim vazifa mavjud. Sizning dizayningizni bir butun sifatida tavsiflovchi hujjatlar (past darajadagi dizayn) va maxsus amalga oshirish (Tarmoqni amalga oshirish rejasi) bo'lishi kerak. Va bu holda, shablonlardan foydalanish juda mos variantga o'xshaydi.
Shunday qilib, YAML va Jinja2 dan foydalanilganda, IP manzillari, BGP AS raqamlari, ... kabi konfiguratsiya parametrlariga ega YAML fayli NIP rolini mukammal bajaradi, Jinja2 shablonlari esa dizaynga mos keladigan sintaksisni o'z ichiga oladi, ya'ni u mohiyatan LLD ning aksi.
YAML va Jinja2-ni o'rganish uchun ikki kun kerak bo'ldi. Buning qanday ishlashini tushunish uchun bir nechta yaxshi misollar etarli. Keyin bizning dizaynimizga mos keladigan barcha shablonlarni yaratish uchun taxminan ikki hafta vaqt ketdi: Palo Alto uchun bir hafta va F5 uchun yana bir hafta. Bularning barchasi korporativ githab-da joylashtirilgan.
Endi o'zgartirish jarayoni quyidagicha ko'rindi:
- YAML faylini o'zgartirdi
- shablon yordamida konfiguratsiya faylini yaratdi (Jinja2)
- masofaviy omborda saqlangan
- yaratilgan konfiguratsiyani uskunaga yukladi
- Men xato ko'rdim
- YAML faylini yoki Jinja2 shablonini o'zgartirdi
- shablon yordamida konfiguratsiya faylini yaratdi (Jinja2)
- ...
Avvaliga tahrirlarga ko'p vaqt sarflangani aniq, lekin bir-ikki hafta o'tgach, bu kamdan-kam holga aylandi.
Yaxshi sinov va hamma narsani tuzatish imkoniyati mijozning nomlash konventsiyasini o'zgartirish istagi edi. F5 bilan ishlaganlar vaziyatning keskinligini tushunishadi. Lekin men uchun hammasi juda oddiy edi. Men YAML faylidagi nomlarni o'zgartirdim, uskunadan butun konfiguratsiyani o'chirib tashladim, yangisini yaratdim va uni yukladim. Hamma narsa, jumladan, xatolarni tuzatish 4 kun davom etdi: har bir texnologiya uchun ikki kun. Shundan so'ng men keyingi bosqichga, ya'ni DEV va Staging ma'lumotlar markazlarini yaratishga tayyor edim.
Ishlab chiqish va sahnalashtirish
Sahnalashtirish aslida ishlab chiqarishni butunlay takrorlaydi. Dev - bu asosan virtual uskunada qurilgan juda qisqartirilgan nusxa. Yangi yondashuv uchun ideal vaziyat. Agar men o'tkazgan vaqtimni umumiy jarayondan ajratib qo'ysam, menimcha, ish 2 haftadan ko'p bo'lmagan. Asosiy vaqt - boshqa tomonni kutish va muammolarni birgalikda qidirish. Uchinchi tomonning amalga oshirilishi boshqalar tomonidan deyarli sezilmadi. Hatto biror narsani o'rganish va Habré haqida bir nechta maqola yozish uchun vaqt bor edi :)
Xulosa qilaylik
Xo'sh, menda nima bor?
- Konfiguratsiyani o'zgartirish uchun qilishim kerak bo'lgan narsa - konfiguratsiya parametrlari bilan oddiy, aniq tuzilgan YAML faylini o'zgartirish. Men hech qachon python skriptini o'zgartirmayman va juda kamdan-kam hollarda (faqat xatolik bo'lsa) Jinja2 issiqlik moslamasini o'zgartiraman
- Hujjatlar nuqtai nazaridan, bu deyarli ideal holat. Siz hujjatlarni o'zgartirasiz (YAML fayllari NIP sifatida xizmat qiladi) va ushbu konfiguratsiyani uskunaga yuklaysiz. Shunday qilib, sizning hujjatlaringiz doimo yangilanadi
Bularning barchasi shunga olib keldi
- xato darajasi deyarli 0 ga kamaydi
- Kun tartibining 90 foizi o'tib ketdi
- amalga oshirish tezligi sezilarli darajada oshdi
PAY, F5Y, ACY
Uning qanday ishlashini tushunish uchun bir nechta misollar etarli ekanligini aytdim.
Mana mening ishim davomida yaratilgan narsalarning qisqacha (va, albatta, o'zgartirilgan) versiyasi.
= joylashtirish Palo Adan Yaml = Yamldan Palo Alto
= joylashtirish F5 dan Yaml = F5 dan Yaml (tez orada)
= joylashtirish ACmen dan Yaml = F5 dan Yaml
Men ACY haqida bir necha so'z qo'shaman (ACI bilan adashtirmaslik kerak).
ACI bilan ishlaganlar, bu mo''jiza (va yaxshi ma'noda ham) tarmoqchilar tomonidan yaratilmaganligini bilishadi :). Tarmoq haqida bilgan hamma narsani unuting - bu sizga foydali bo'lmaydi!
Bu biroz bo'rttirilgan, lekin men so'nggi 3 yil davomida ACI bilan ishlayotganimni doimiy ravishda boshdan kechirgan tuyg'uni ifodalaydi.
Va bu holda, ACY nafaqat o'zgarishlarni boshqarish jarayonini qurish imkoniyatidir (bu ACI misolida ayniqsa muhimdir, chunki u sizning ma'lumotlar markazingizning markaziy va eng muhim qismi bo'lishi kerak), balki sizga ham beradi. konfiguratsiyani yaratish uchun qulay interfeys.
Ushbu loyihadagi muhandislar xuddi shu maqsadlar uchun YAML o'rniga ACI ni sozlash uchun Exceldan foydalanadilar. Albatta, Exceldan foydalanishning afzalliklari bor:
- NIPni bitta faylda
- mijozga qarash uchun yoqimli bo'lgan chiroyli belgilar
- ba'zi excel vositalaridan foydalanishingiz mumkin
Ammo bitta minus bor va mening fikrimcha, bu ijobiy tomonlardan ustundir. O'zgarishlarni nazorat qilish va jamoa ishini muvofiqlashtirish ancha qiyinlashadi.
ACY, aslida, men uchinchi tomon uchun ACIni sozlash uchun ishlatgan yondashuvlarning ilovasidir.
Manba: www.habr.com