Yondashuv IaC (Infratuzilma kod sifatida) nafaqat omborda saqlanadigan koddan, balki ushbu kodni o'rab turgan odamlar va jarayonlardan ham iborat. Dasturiy ta'minotni ishlab chiqishdan infratuzilmani boshqarish va tavsiflashgacha bo'lgan yondashuvlarni qayta ishlatish mumkinmi? Maqolani o'qiyotganingizda ushbu fikrni yodda tutsangiz yaxshi bo'lardi.
Bu mening transkriptim haqida .
Slaydlar va videolar
- Quruq yugurish 2019
Infratuzilma bash tarixi sifatida
Aytaylik, siz yangi loyihaga keldingiz va ular sizga: “Bizda bor Kod sifatida infratuzilma". Aslida bu chiqadi Infratuzilma bash tarixi sifatida yoki masalan Hujjatlar bash tarixi sifatida. Bu juda real vaziyat, masalan, xuddi shunday holat Denis Lisenko tomonidan nutqida tasvirlangan , u bash tarixidan qanday qilib loyiha uchun izchil infratuzilmaga ega bo'lganliklarini aytdi.
Bir oz istak bilan buni aytishimiz mumkin Infratuzilma bash tarixi sifatida bu kodga o'xshaydi:
- takrorlanuvchanlik: Siz bash tarixini olishingiz, u yerdan buyruqlarni ishga tushirishingiz va aytmoqchi, chiqish sifatida ishlaydigan konfiguratsiyani olishingiz mumkin.
- versiyalashtirish: kim kirganini va nima qilganini bilasiz, yana bu sizni chiqishda ishlaydigan konfiguratsiyaga olib borishi haqiqat emas.
- tarix: kim nima qilgani haqidagi hikoya. faqat serverni yo'qotib qo'ysangiz undan foydalana olmaysiz.
Nima qilsa bo'ladi?
Kod sifatida infratuzilma
Hatto bunday g'alati holat Infratuzilma bash tarixi sifatida siz uni quloqlaringizdan tortib olishingiz mumkin Kod sifatida infratuzilma, lekin biz eski yaxshi LAMP serveriga qaraganda murakkabroq narsani qilmoqchi bo'lganimizda, biz ushbu kodni qandaydir tarzda o'zgartirish, o'zgartirish, yaxshilash kerak degan xulosaga kelamiz. Keyinchalik o'rtasidagi parallelliklarni ko'rib chiqmoqchimiz Kod sifatida infratuzilma va dasturiy ta'minotni ishlab chiqish.
QURUQ
Saqlash tizimini ishlab chiqish loyihasida kichik vazifa mavjud edi : biz yangi nashrni chiqarmoqdamiz - uni keyingi sinovdan o'tkazish uchun chiqarish kerak. Vazifa juda oddiy:
- ssh orqali bu yerga kiring va buyruqni bajaring.
- faylni u erda nusxalash.
- bu erda konfiguratsiyani to'g'rilang.
- u erda xizmatni boshlang
- ...
- FOYDA!
Ta'riflangan mantiq uchun bash, ayniqsa, loyihaning dastlabki bosqichlarida, endigina boshlanayotganda, ko'proq etarli. Bu , lekin vaqt o'tishi bilan shunga o'xshash narsalarni joylashtirish uchun so'rovlar bor, lekin biroz boshqacha. Aqlga keladigan birinchi narsa - nusxa ko'chiring. Va endi bizda deyarli bir xil ishni bajaradigan ikkita juda o'xshash skript mavjud. Vaqt o'tishi bilan skriptlar soni o'sib bordi va biz turli xil skriptlar o'rtasida sinxronlashtirilishi kerak bo'lgan o'rnatishni joylashtirish uchun ma'lum bir biznes mantig'i mavjudligiga duch keldik, bu juda murakkab.
Ma'lum bo'lishicha, DRY (O'zingizni takrorlamang) kabi amaliyot mavjud. G'oya mavjud kodni qayta ishlatishdir. Bu oddiy tuyuladi, lekin biz bunga darhol kelmadik. Bizning holatda, bu oddiy fikr edi: konfiguratsiyalarni skriptlardan ajratish. Bular. o'rnatish qanday qilib alohida-alohida, konfiguratsiyalar alohida joylashtirilganligining biznes mantig'i.
CFM uchun SOLID
Vaqt o'tishi bilan loyiha o'sdi va Ansiblening paydo bo'lishi edi. Uning paydo bo'lishining asosiy sababi shundaki, jamoada tajriba bor va bu bash murakkab mantiq uchun mo'ljallanmagan. Ansible ham murakkab mantiqni o'z ichiga boshladi. Murakkab mantiqning xaosga aylanishining oldini olish uchun dasturiy ta'minotni ishlab chiqishda kodni tashkil qilish tamoyillari mavjud SOLID Shuningdek, masalan, Grigoriy Petrov "IT mutaxassisiga nima uchun shaxsiy brend kerak" ma'ruzasida odam shunday yaratilganki, u ba'zi ijtimoiy tuzilmalar bilan ishlash osonroq bo'ladi, degan savolni ko'tardi. ob'ektlardir. Agar biz ushbu ikki fikrni birlashtirib, ularni rivojlantirishda davom etsak, biz ham foydalanishimiz mumkinligini sezamiz SOLID kelajakda ushbu mantiqni saqlash va o'zgartirishni osonlashtirish uchun.
Yagona javobgarlik printsipi
Har bir sinf faqat bitta vazifani bajaradi.
Kodni aralashtirish va monolit ilohiy spagetti yirtqich hayvonlarini qilish kerak emas. Infratuzilma oddiy g'ishtlardan iborat bo'lishi kerak. Ma'lum bo'lishicha, agar siz Ansible o'yin kitobini kichik bo'laklarga ajratsangiz, Ansible rollarini o'qing, keyin ularni saqlash osonroq bo'ladi.
Ochiq yopiq printsip
Ochiq/yopiq printsip.
- Kengaytma uchun ochiq: ob'ektning xatti-harakati yangi ob'ektlar turlarini yaratish orqali kengaytirilishi mumkinligini anglatadi.
- O'zgartirishga yopiq: ob'ektning xatti-harakatlarini kengaytirish natijasida ushbu ob'ektlardan foydalanadigan kodga hech qanday o'zgartirish kiritilmasligi kerak.
Dastlab, biz virtual mashinalarda sinov infratuzilmasini joylashtirdik, ammo joylashtirishning biznes mantig'i amalga oshirishdan alohida bo'lganligi sababli, biz baremetall-ga hech qanday muammosiz o'tishni qo'shdik.
Liskov almashtirish printsipi
Barbara Liskovning almashtirish printsipi. dasturdagi ob'ektlar dasturning to'g'ri bajarilishini o'zgartirmasdan, ularning kichik turlari misollari bilan almashtirilishi kerak.
Agar siz uni kengroq ko'rib chiqsangiz, u erda qo'llanilishi mumkin bo'lgan biron bir loyihaning xususiyati emas SOLID, bu umuman CFM haqida, masalan, boshqa loyihada turli Java, dastur serverlari, ma'lumotlar bazalari, OS va hokazolar ustiga qutili Java dasturini joylashtirish kerak. Ushbu misoldan foydalanib, men boshqa tamoyillarni ko'rib chiqaman SOLID
Bizning holatimizda, infratuzilma jamoasi ichida kelishuv mavjud, agar biz imbjava yoki oraclejava rolini o'rnatgan bo'lsak, unda bizda java ikkilik bajariladigan fayl mavjud. Bu zarur, chunki Yuqoridagi rollar ushbu xatti-harakatlarga bog'liq; ular java-ni kutishadi. Shu bilan birga, bu bizga dasturni joylashtirish mantig'ini o'zgartirmasdan bitta java ilovasini/versiyasini boshqasiga almashtirish imkonini beradi.
Muammo shundaki, buni Ansible-da amalga oshirishning iloji yo'q, buning natijasida jamoa ichida ba'zi kelishuvlar paydo bo'ladi.
Interfeysni ajratish printsipi
Interfeysni ajratish printsipi: “Ko'pgina mijozga xos interfeyslar bitta umumiy maqsadli interfeysdan yaxshiroqdir.
Dastlab, biz ilovalarni joylashtirishning barcha o'zgaruvchanligini bitta Ansible o'yin kitobiga joylashtirishga harakat qildik, ammo buni qo'llab-quvvatlash qiyin edi va bizda tashqi interfeys mavjud bo'lganda (mijoz 443 portni kutmoqda) yondashuvni aniqladik, keyin infratuzilmani individual ravishda yig'ish mumkin. muayyan amalga oshirish uchun g'ishtlar.
Bog'liqlik inversiyasi printsipi
Bog'liqlik inversiyasi printsipi. Yuqori darajadagi modullar quyi darajadagi modullarga bog'liq bo'lmasligi kerak. Ikkala turdagi modul ham abstraktsiyalarga bog'liq bo'lishi kerak. Abstraktsiyalar tafsilotlarga bog'liq bo'lmasligi kerak. Tafsilotlar abstraktsiyalarga bog'liq bo'lishi kerak.
Bu erda misol antipatternga asoslangan bo'ladi.
- Mijozlardan birining shaxsiy buluti bor edi.
- Biz bulut ichida virtual mashinalarga buyurtma berdik.
- Ammo bulutning tabiatiga ko'ra, ilovalarni joylashtirish VM yoqilgan hipervizorga bog'langan.
Bular. Yuqori darajadagi ilovalarni joylashtirish mantig'i gipervisorning quyi darajalariga bog'liqlik bilan oqardi va bu mantiqni qayta ishlatishda muammolarni anglatardi. Bunday qilish kerak emas.
O'zaro aloqalar
Kod sifatida infratuzilma nafaqat kod haqida, balki kod va odamlar o'rtasidagi munosabatlar, infratuzilmani ishlab chiquvchilar o'rtasidagi o'zaro aloqalar haqida hamdir.
Avtobus omili
Faraz qilaylik, sizning loyihangizda Vasya bor. Vasya sizning infratuzilmangiz haqida hamma narsani biladi, agar Vasya to'satdan g'oyib bo'lsa nima bo'ladi? Bu juda real holat, chunki uni avtobus urib yuborishi mumkin. Ba'zan shunday bo'ladi. Agar bu sodir bo'lsa va kod, uning tuzilishi, qanday ishlashi, tashqi ko'rinishlari va parollari haqidagi bilimlar jamoa o'rtasida taqsimlanmagan bo'lsa, unda siz bir qator noxush holatlarga duch kelishingiz mumkin. Ushbu xavflarni minimallashtirish va bilimlarni jamoada tarqatish uchun siz turli xil yondashuvlardan foydalanishingiz mumkin
Juftlikni rivojlantirish
Bu kabi emas , administratorlar pivo ichganligi, parollarni o'zgartirganligi va juft dasturlashning analogi. Bular. ikkita muhandis bitta kompyuterda, bitta klaviaturada o'tirib, infratuzilmangizni birgalikda sozlashni boshlaydilar: serverni o'rnatish, Ansible rolini yozish va hokazo. Bu yoqimli tuyuladi, lekin bu biz uchun ishlamadi. Ammo bu amaliyotning alohida holatlari ishladi. Yangi xodim keladi, uning ustozi u bilan birgalikda haqiqiy vazifani bajaradi, ishlaydi va bilim beradi.
Yana bir alohida holat - hodisa chaqiruvi. Muammo vaqtida navbatchilar va ishtirokchilar guruhi yig'iladi, bitta rahbar tayinlanadi, u o'z ekranini baham ko'radi va fikr poezdini ovoz chiqaradi. Boshqa ishtirokchilar rahbarning fikrlarini kuzatib boradilar, konsoldan hiyla-nayranglar bo'yicha josuslik qiladilar, jurnaldagi qatorni o'tkazib yubormaganliklarini tekshiradilar va tizim haqida yangi narsalarni o'rganadilar. Ushbu yondashuv ko'proq ishladi.
Kodlarni ko'rib chiqish
Subyektiv ravishda, kodni ko'rib chiqish yordamida infratuzilma va uning qanday ishlashi haqida bilimlarni tarqatish samaraliroq bo'ldi:
- Infratuzilma ombordagi kod bilan tavsiflanadi.
- O'zgarishlar alohida filialda sodir bo'ladi.
- Birlashtirish so'rovi paytida siz infratuzilmadagi o'zgarishlarning deltasini ko'rishingiz mumkin.
Bu erda e'tiborga molik jihat shundaki, taqrizchilar birma-bir, jadval bo'yicha tanlab olindi, ya'ni. ma'lum bir ehtimollik darajasi bilan siz infratuzilmaning yangi qismiga ko'tarilasiz.
Kod uslubi
Vaqt o'tishi bilan ko'rib chiqish paytida janjallar paydo bo'la boshladi, chunki ... sharhlovchilarning o'z uslubi bor edi va sharhlovchilarning aylanishi ularni turli uslublar bilan to'pladi: 2 bo'sh joy yoki 4, camelCase yoki snake_case. Buni darhol amalga oshirish mumkin emas edi.
- Birinchi fikr linterdan foydalanishni tavsiya qilish edi, axir, hamma muhandis, hamma aqlli. Ammo turli xil tahrirlovchilar, OS, qulay emas
- Bu har bir muammoli topshiriqni susaytirish uchun yozuvchi va linter chiqishini biriktiruvchi botga aylandi. Ammo ko'p hollarda qilish kerak bo'lgan muhimroq narsalar bor edi va kod tuzatilmagan.
Yashil qurilish ustasi
Vaqt o'tadi va biz ma'lum testlardan o'tmagan majburiyatlarni ustaga kiritish mumkin emas degan xulosaga keldik. Voila! Biz uzoq vaqt davomida dasturiy ta'minotni ishlab chiqishda qo'llanilgan Green Build Master-ni ixtiro qildik:
- Alohida filialda rivojlanish davom etmoqda.
- Ushbu mavzu bo'yicha testlar o'tkazilmoqda.
- Agar testlar muvaffaqiyatsiz bo'lsa, kod uni masterga kiritmaydi.
Bunday qaror qabul qilish juda og'riqli edi, chunki ... ko'p bahs-munozaralarga sabab bo'ldi, lekin bunga arziydi, chunki... Sharhlar uslubda farq qilmasdan qo'shilish bo'yicha so'rovlarni qabul qila boshladi va vaqt o'tishi bilan muammoli joylar soni kamayishni boshladi.
IaC testi
Uslubni tekshirishdan tashqari, siz boshqa narsalardan foydalanishingiz mumkin, masalan, infratuzilmangiz haqiqatda joylashishini tekshirish uchun. Yoki infratuzilmadagi o'zgarishlar pul yo'qotilishiga olib kelmasligini tekshiring. Nima uchun bu kerak bo'lishi mumkin? Savol murakkab va falsafiy, qandaydir tarzda Powershell-da chegara shartlarini tekshirmaydigan avtomatik o'lchovchi borligi haqida hikoya bilan javob bergan ma'qul => zaruratdan ko'ra ko'proq VMlar yaratilgan => mijoz rejalashtirilganidan ko'proq pul sarflagan. Bu juda yoqimli emas, lekin bu xatoni oldingi bosqichlarda qo'lga kiritish juda mumkin edi.
Kimdir so'rashi mumkin, nima uchun murakkab infratuzilmani yanada murakkablashtirasiz? Infratuzilma uchun testlar, xuddi kod uchun bo'lgani kabi, soddalashtirish haqida emas, balki sizning infratuzilmangiz qanday ishlashini bilish uchun.
IaC sinov piramidasi
IaC testi: Statik tahlil
Agar siz bir vaqtning o'zida butun infratuzilmani joylashtirsangiz va uning ishlashini tekshirsangiz, bu juda ko'p vaqt va ko'p vaqt talab qilishini bilib olishingiz mumkin. Shuning uchun, asos tez ishlaydigan narsa bo'lishi kerak, u juda ko'p va u juda ko'p ibtidoiy joylarni qamrab oladi.
Bash qiyin
Keling, arzimas bir misolni ko'rib chiqaylik. joriy katalogdagi barcha fayllarni tanlang va boshqa joyga ko'chiring. Aqlga keladigan birinchi narsa:
for i in * ; do
cp $i /some/path/$i.bak
doneAgar fayl nomida bo'sh joy bo'lsa-chi? Xo'sh, biz aqllimiz, tirnoqlarni qanday ishlatishni bilamiz:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneJuda qoyil? Yo'q! Agar katalogda hech narsa bo'lmasa-chi, ya'ni. globbing ishlamaydi.
find . -type f -exec mv -v {} dst/{}.bak ;Yaxshimisiz? Yo'q ... Fayl nomida nima bo'lishi mumkinligini unutgan n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirStatik tahlil vositalari
Oldingi bosqichdagi muammo biz tirnoqlarni unutganimizda paydo bo'lishi mumkin, buning uchun tabiatda ko'plab vositalar mavjud. , umuman olganda, ularning ko'pi bor va ehtimol siz IDE ostida stekingiz uchun linter topishingiz mumkin.
Til
asbob
bosh
yoqut
python
sezilmaydigan
IaC testi: birlik testlari
Oldingi misoldan ko'rganimizdek, linterlar hamma narsaga qodir emas va barcha muammoli joylarni ko'rsata olmaydi. Bundan tashqari, dasturiy ta'minotni ishlab chiqishda testlarga o'xshab, biz birlik testlarini esga olishimiz mumkin. Darhol aqlga kelgan narsa , , , . Lekin ansible, chef, saltstack va ularga o'xshash boshqalar bilan nima qilish kerak?
Eng boshida biz gaplashdik SOLID va bizning infratuzilmamiz kichik g'ishtlardan iborat bo'lishi kerak. Ularning vaqti keldi.
- Infratuzilma kichik g'ishtlarga bo'linadi, masalan, Ansible rollari.
- Docker yoki VM bo'lsin, qandaydir muhit o'rnatilgan.
- Biz ushbu sinov muhitiga Ansible rolimizni qo'llaymiz.
- Biz hamma narsa biz kutgandek ishlaganligini tekshiramiz (sinovlarni o'tkazamiz).
- Biz yaxshi yoki yo'qligini hal qilamiz.
IaC testi: birliklarni sinovdan o'tkazish vositalari
Savol, CFM uchun testlar nima? Siz shunchaki skriptni ishga tushirishingiz mumkin yoki buning uchun tayyor echimlardan foydalanishingiz mumkin:
CFM
asbob
E'tirof etiladi
bosh
bosh
tuz to'plami
Testinfra uchun misol, foydalanuvchilarni tekshirish test1, test2 mavjud va guruhda sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsNima tanlash kerak? Savol murakkab va noaniq, 2018-2019 yillar uchun github-dagi loyihalardagi o'zgarishlarga misol:
IaC test tizimlari
Savol tug'iladi: qanday qilib barchasini birlashtirib, uni ishga tushirish kerak? mumkin etarli miqdordagi muhandislar mavjud bo'lsa. Yoki siz tayyor echimlarni olishingiz mumkin, garchi ularning soni unchalik ko'p bo'lmasa:
CFM
asbob
E'tirof etiladi
bosh
Terraform
2018-2019 yillar uchun github-dagi loyihalardagi o'zgarishlarga misol:
Molekula vs. Sinov oshxonasi
Dastlab biz :
- Parallel ravishda VM yarating.
- Ansible rollarini qo'llang.
- Tekshirishni o'tkazish.
25-35 rol uchun 40-70 daqiqa ishladi, bu uzoq edi.
Keyingi qadam jenkins/docker/ansible/molekulaga o'tish edi. Idiologik jihatdan hammasi bir xil
- Lint o'yin kitoblari.
- Rollarni bir qatorga qo'ying.
- Konteynerni ishga tushiring
- Ansible rollarini qo'llang.
- Testinfra-ni ishga tushiring.
- Identifikatorni tekshiring.
40 ta rol uchun linting va o'nlab rollar uchun testlar taxminan 15 daqiqa davom eta boshladi.
Nimani tanlash kerakligi ko'plab omillarga bog'liq, masalan, foydalanilgan to'plam, jamoadagi tajriba va boshqalar. Bu erda har bir kishi birlik testi savolini qanday yopish kerakligini o'zi hal qiladi
IaC testi: integratsiya testlari
Infratuzilmani sinovdan o'tkazish piramidasining keyingi bosqichi integratsiya testlari bo'ladi. Ular birlik testlariga o'xshaydi:
- Infratuzilma kichik g'ishtlarga bo'linadi, masalan, Ansible rollari.
- Docker yoki VM bo'lsin, qandaydir muhit o'rnatilgan.
- Ushbu sinov muhiti uchun amal qiling juda ko'p Aqlli rollar.
- Biz hamma narsa biz kutgandek ishlaganligini tekshiramiz (sinovlarni o'tkazamiz).
- Biz yaxshi yoki yo'qligini hal qilamiz.
Taxminan aytganda, biz tizimning alohida elementining ishlashini birlik testlarida bo'lgani kabi tekshirmaymiz, biz server qanday tuzilganligini tekshiramiz.
IaC testi: oxirigacha sinovlar
Piramidaning yuqori qismida bizni End to End testlari kutib oladi. Bular. Biz alohida server, alohida skript yoki infratuzilmamizning alohida g'isht ishlashini tekshirmaymiz. Biz ko'plab serverlar bir-biriga ulanganligini tekshiramiz, infratuzilmamiz biz kutgandek ishlaydi. Afsuski, men hech qachon tayyor qutili echimlarni ko'rmaganman, ehtimol, chunki ... Infratuzilma ko'pincha noyob bo'lib, uni shablon qilish va sinov uchun asos yaratish qiyin. Natijada, har kim o'z echimini yaratadi. Talab bor, lekin javob yo'q. Shuning uchun, men sizga boshqalarni sog'lom fikrlarga undash yoki burnimni ishqalash uchun nima borligini aytaman, chunki hamma narsa bizdan oldin ixtiro qilingan.
Boy tarixga ega loyiha. U yirik tashkilotlarda qo'llaniladi va ehtimol sizning har biringiz bilvosita u bilan kesishgan. Ilova ko'plab ma'lumotlar bazalarini, integratsiyalarni va boshqalarni qo'llab-quvvatlaydi. Infratuzilma qanday ko'rinishini bilish juda ko'p docker-compose fayllari va Jenkins qaysi muhitda qaysi testlarni bajarish kerakligini bilishdir.
Ushbu sxema juda uzoq vaqt davomida ishladi, toki bu doirada biz buni Openshift-ga o'tkazishga harakat qilmadik. Konteynerlar bir xil bo'lib qoladi, lekin ishga tushirish muhiti o'zgardi (yana salom DRY).
Tadqiqot g'oyasi yanada ko'proq davom etdi va openshiftda ular APB (Ansible Playbook Bundle) kabi narsani topdilar, bu sizga infratuzilmani konteynerga qanday joylashtirish bo'yicha bilimlarni to'plash imkonini beradi. Bular. infratuzilmani qanday joylashtirish bo'yicha takrorlanadigan, sinovdan o'tkaziladigan bilim nuqtasi mavjud.
Bularning barchasi biz heterojen infratuzilmaga duch kelmagunimizcha yaxshi eshitildi: testlar uchun bizga Windows kerak edi. Natijada, nimani, qaerda, qanday joylashtirish va sinovdan o'tkazish haqidagi bilimlar jenkinsda.
Xulosa
Kodeks kabi infratuzilma
- Kod omborida.
- Insonning o'zaro ta'siri.
- Infratuzilmani sinovdan o'tkazish.
ishoratlar
- Quruq yugurish 2019
- &
Manba: www.habr.com