ProHoster > Blogs > Administrācija > Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Pieeja IaC (InfrastruktÅ«ra kā kods) sastāv ne tikai no koda, kas tiek glabāts repozitorijā, bet arÄ« no cilvēkiem un procesiem, kas ieskauj Å”o kodu. Vai ir iespējams atkārtoti izmantot pieejas no programmatÅ«ras izstrādes lÄ«dz infrastruktÅ«ras pārvaldÄ«bai un aprakstam? BÅ«tu laba ideja paturēt Å”o domu prātā, lasot rakstu.

Angielski versija

Å Ä« ir mana atÅ”ifrējums izrādes par DevopsConf 2019-05-28.

Slaidi un video

Infrastruktūra kā bash vēsture

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Pieņemsim, ka jÅ«s nonākat pie jauna projekta, un viņi jums saka: ā€œMums ir InfrastruktÅ«ra kā kods". Realitātē izrādās InfrastruktÅ«ra kā bash vēsture vai piemēram Dokumentācija kā bash vēsture. Tā ir ļoti reāla situācija, piemēram, lÄ«dzÄ«gu gadÄ«jumu savā runā aprakstÄ«ja Deniss Lisenko Kā nomainÄ«t visu infrastruktÅ«ru un sākt mierÄ«gi gulēt, viņŔ pastāstÄ«ja, kā viņi ieguva saskaņotu infrastruktÅ«ru projektam no bash history.

Ar zināmu vēlmi mēs to varam teikt Infrastruktūra kā bash vēsture tas ir kā kods:

  1. reproducējamība: Varat ņemt bash vēsturi, palaist komandas no turienes, un, starp citu, kā izvadi var iegūt darba konfigurāciju.
  2. versiju veidoÅ”ana: jÅ«s zināt, kas ieradās un ko viņi darÄ«ja, atkal nav fakts, ka tas novedÄ«s pie darba konfigurācijas pie izejas.
  3. stāsts: stāsts par to, kurÅ” ko izdarÄ«ja. tikai jÅ«s to nevarēsit izmantot, ja pazaudēsit serveri.

Ko darīt?

Infrastruktūra kā kods

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Pat tāds dÄ«vains gadÄ«jums kā InfrastruktÅ«ra kā bash vēsture var vilkt aiz ausÄ«m InfrastruktÅ«ra kā kods, bet tad, kad gribēsim izdarÄ«t ko sarežģītāku par veco labo LAMP serveri, nonāksim pie slēdziena, ka Å”is kods ir kaut kā jāpārveido, jāmaina, jāuzlabo. Tālāk mēs vēlētos apsvērt paralēles starp InfrastruktÅ«ra kā kods un programmatÅ«ras izstrāde.

D.R.Y.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

UzglabāŔanas sistēmas izstrādes projektā bija apakÅ”uzdevums periodiski konfigurējiet SDS: mēs izlaižam jaunu laidienu ā€” tas ir jāizlaiž turpmākai pārbaudei. Uzdevums ir ārkārtÄ«gi vienkārÅ”s:

  • piesakieties Å”eit, izmantojot ssh, un izpildiet komandu.
  • kopējiet failu tur.
  • labojiet konfigurāciju Å”eit.
  • sākt pakalpojumu tur
  • ...
  • IENĀKUMS!

AprakstÄ«tajai loÄ£ikai ar bash ir vairāk nekā pietiekami, it Ä«paÅ”i projekta sākuma stadijā, kad tas tikai sākas. Å is nav slikti, ka lieto bash, taču laika gaitā parādās pieprasÄ«jumi izvietot kaut ko lÄ«dzÄ«gu, bet nedaudz atŔķirÄ«gu. Pirmā lieta, kas nāk prātā, ir copy-paste. Un tagad mums jau ir divi ļoti lÄ«dzÄ«gi skripti, kas veic gandrÄ«z vienu un to paÅ”u. Laika gaitā skriptu skaits pieauga, un mēs saskārāmies ar faktu, ka instalācijas izvietoÅ”anai ir noteikta biznesa loÄ£ika, kas jāsinhronizē starp dažādiem skriptiem, tas ir diezgan sarežģīti.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Izrādās, ka ir tāda prakse kā D.R.Y. (Neatkārtojiet sevi). Ideja ir atkārtoti izmantot esoÅ”o kodu. Tas izklausās vienkārÅ”i, bet mēs to nenonācām uzreiz. MÅ«su gadÄ«jumā tā bija banāla ideja: atdalÄ«t konfigurācijas no skriptiem. Tie. biznesa loÄ£ika par to, kā instalācija tiek izvietota atseviŔķi, konfigurācijas atseviŔķi.

CIETS. par CFM

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Laika gaitā projekts pieauga un dabisks turpinājums bija Ansible parādÄ«Å”anās. Galvenais tās parādÄ«Å”anās iemesls ir tas, ka komandai ir zināŔanas un ka bash nav paredzēts sarežģītai loÄ£ikai. Ansible sāka ietvert arÄ« sarežģītu loÄ£iku. Lai sarežģīta loÄ£ika nepārvērstos haosā, programmatÅ«ras izstrādē ir izstrādāti koda organizÄ“Å”anas principi CIETS. Tāpat, piemēram, Grigorijs Petrovs referātā ā€œKāpēc IT speciālistam vajadzÄ«gs personÄ«gais zÄ«molsā€ izvirzÄ«ja jautājumu, ka cilvēks ir veidots tā, lai viņam bÅ«tu vieglāk operēt ar kādām sociālām vienÄ«bām, programmatÅ«ras izstrādē Ŕīs ir objekti. Ja Ŕīs divas idejas apvienosim un turpināsim tās attÄ«stÄ«t, pamanÄ«sim, ka varam arÄ« izmantot CIETS. lai turpmāk bÅ«tu vieglāk uzturēt un modificēt Å”o loÄ£iku.

Vienotās atbildības princips

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Katra klase veic tikai vienu uzdevumu.

Nav nepiecieÅ”ams jaukt kodu un veidot monolÄ«tus dieviŔķus spageti monstrus. InfrastruktÅ«rai vajadzētu sastāvēt no vienkārÅ”iem Ä·ieÄ£eļiem. Izrādās, ja Ansible rotaļu grāmatu sadala mazos gabaliņos, izlasa Ansible lomas, tad tās ir vieglāk uzturēt.

Atvērtais slēgtais princips

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Atvērts/slēgts princips.

  • Atvērts paplaÅ”ināŔanai: nozÄ«mē, ka entÄ«tijas darbÄ«bu var paplaÅ”ināt, izveidojot jaunus entÄ«tiju veidus.
  • Slēgts izmaiņām: entÄ«tijas darbÄ«bas paplaÅ”ināŔanas rezultātā nevajadzētu veikt nekādas izmaiņas kodā, kas izmanto Ŕīs entÄ«tijas.

Sākotnēji mēs izvietojām testa infrastruktÅ«ru virtuālajās maŔīnās, taču, tā kā izvietoÅ”anas biznesa loÄ£ika bija noŔķirta no ievieÅ”anas, mēs bez problēmām pievienojām izvērÅ”anu baremetall.

Liskova aizstāŔanas princips

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Barbaras Liskovas aizstāŔanas princips. objektiem programmā jābūt aizvietojamiem ar to apakŔtipu gadījumiem, nemainot pareizu programmas izpildi

Ja skatās plaŔāk, tad tā nav neviena konkrēta projekta iezÄ«me, ko tur varētu pielietot CIETS., tas parasti ir par CFM, piemēram, citā projektā ir nepiecieÅ”ams izvietot kastē ievietotu Java lietojumprogrammu virs dažādām Java, lietojumprogrammu serveriem, datu bāzēm, OS utt. Izmantojot Å”o piemēru, es apsvērÅ”u turpmākos principus CIETS.

MÅ«su gadÄ«jumā infrastruktÅ«ras komandā ir vienoÅ”anās, ka, ja esam instalējuÅ”i imbjava vai oraclejava lomu, tad mums ir java binārais izpildāmais fails. Tas ir nepiecieÅ”ams, jo IepriekŔējās lomas ir atkarÄ«gas no Ŕīs uzvedÄ«bas; viņi sagaida Java. Tajā paŔā laikā tas ļauj aizstāt vienu Java ievieÅ”anu/versiju ar citu, nemainot lietojumprogrammas izvietoÅ”anas loÄ£iku.

Problēma Å”eit slēpjas apstāklÄ«, ka Ansible to nav iespējams realizēt, kā rezultātā komandas iekÅ”ienē rodas kaut kādas vienoÅ”anās.

Interfeisa segregācijas princips

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Interfeisa atdalÄ«Å”anas princips: ā€œDaudzas klientam specifiskas saskarnes ir labākas nekā viena vispārēja pielietojuma saskarne.

Sākotnēji mēģinājām visu lietojumprogrammu izvietoÅ”anas mainÄ«gumu salikt vienā Ansible rokasgrāmatā, taču to bija grÅ«ti atbalstÄ«t, un pieeja, kad mums ir norādÄ«ts ārējais interfeiss (klients sagaida portu 443), tad infrastruktÅ«ru var salikt no individuālajām Ä·ieÄ£eļi konkrētai Ä«stenoÅ”anai.

Atkarības inversijas princips

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Atkarības inversijas princips. Augstākā līmeņa moduļiem nevajadzētu būt atkarīgiem no zemāka līmeņa moduļiem. Abiem moduļu veidiem jābūt atkarīgiem no abstrakcijām. Abstrakcijām nevajadzētu būt atkarīgām no detaļām. Detaļai jābūt atkarīgai no abstrakcijām.

Šeit piemērs būs balstīts uz antirakstu.

  1. Vienam no klientiem bija privāts mākonis.
  2. Mēs pasÅ«tÄ«jām virtuālās maŔīnas mākoņa iekÅ”pusē.
  3. Taču mākoņa rakstura dēļ lietojumprogrammu izvietoÅ”ana bija saistÄ«ta ar to, kurÅ” hipervizors bija ieslēgts virtuālajā maŔīnā.

Tie. Augsta lÄ«meņa lietojumprogrammu izvietoÅ”anas loÄ£ika plÅ«da ar atkarÄ«bām uz zemākiem hipervizora lÄ«meņiem, un tas nozÄ«mēja problēmas, atkārtoti izmantojot Å”o loÄ£iku. Nedariet to Ŕādā veidā.

Mijiedarbība

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Infrastruktūra kā kods ir ne tikai kods, bet arī attiecības starp kodu un cilvēkiem, mijiedarbība starp infrastruktūras izstrādātājiem.

Autobusu faktors

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Pieņemsim, ka jÅ«su projektā ir Vasja. Vasja zina visu par jÅ«su infrastruktÅ«ru, kas notiks, ja Vasja pēkŔņi pazudÄ«s? Tā ir ļoti reāla situācija, jo viņu var notriekti autobuss. Dažreiz tas notiek. Ja tā notiek un zināŔanas par kodu, tā struktÅ«ru, kā tas darbojas, izskatu un parolēm netiek izplatÄ«tas starp komandu, tad var rasties vairākas nepatÄ«kamas situācijas. Lai samazinātu Å”os riskus un izplatÄ«tu zināŔanas komandā, varat izmantot dažādas pieejas

Pāris Devopsing

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Tas nav kā kā joks, ka admini dzēra alu, mainÄ«ja paroles un pāru programmÄ“Å”anas analogu. Tie. divi inženieri apsēžas pie viena datora, vienas tastatÅ«ras un kopā sāk izveidot infrastruktÅ«ru: izveidot serveri, rakstÄ«t Ansible lomu utt. Izklausās jauki, bet mums tas nederēja. Taču Ŕīs prakses Ä«paÅ”ie gadÄ«jumi darbojās. Atnāk jauns darbinieks, viņa mentors kopā ar viņu uzņemas reālu uzdevumu, strādā un nodod zināŔanas.

Vēl viens Ä«paÅ”s gadÄ«jums ir incidenta izsaukums. Problēmas laikā tiek savākta dežurētāju un iesaistÄ«to grupa, tiek iecelts viens vadÄ«tājs, kurÅ” dalās ar savu ekrānu un izsaka domu gājienu. Citi dalÄ«bnieki seko lÄ«dera domām, izspiego konsoles trikus, pārbauda, ā€‹ā€‹vai nav palaiduÅ”i garām nevienu rindiņu žurnālā, un uzzina jaunas lietas par sistēmu. Å Ä« pieeja darbojās biežāk nekā nē.

Kodu pārskatīŔana

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Subjektīvi bija efektīvāk izplatīt zināŔanas par infrastruktūru un tās darbību, izmantojot kodu pārskatīŔanu:

  • InfrastruktÅ«ra ir aprakstÄ«ta ar kodu repozitorijā.
  • Izmaiņas notiek atseviŔķā filiālē.
  • ApvienoÅ”anas pieprasÄ«juma laikā varat redzēt infrastruktÅ«ras izmaiņu delta.

Šeit galvenais bija tas, ka recenzentus atlasīja pa vienam, pēc grafika, t.i. ar zināmu varbūtības pakāpi jūs iekāpsiet jaunā infrastruktūras daļā.

Koda stils

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Ar laiku apskatu laikā sāka parādīties ķildas, jo... recenzentiem bija savs stils, un recenzentu rotācija tos kārtoja ar dažādiem stiliem: 2 atstarpes vai 4, camelCase vai snake_case. To nebija iespējams īstenot uzreiz.

  • Pirmā doma bija ieteikt izmantot linteri, galu galā visi ir inženieri, visi ir gudri. Bet dažādi redaktori, OS, nav ērti
  • Tas attÄ«stÄ«jās par robotprogrammu, kas rakstÄ«ja, lai katras problemātiskās darbÄ«bas gadÄ«jumā atslābtu, un pievienoja lintera izvadi. Taču vairumā gadÄ«jumu bija daudz svarÄ«gākas lietas, ko darÄ«t, un kods palika nelabots.

Zaļās celtniecības meistars

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Laiks iet, un mēs esam nonākuÅ”i pie secinājuma, ka saistÄ«bas, kas neiztur noteiktus pārbaudÄ«jumus, nevar ielaist meistarā. Voila! Mēs izgudrojām Green Build Master, kas programmatÅ«ras izstrādē tiek praktizēts jau ilgu laiku:

  • AtseviŔķā filiālē notiek izstrāde.
  • Å ajā pavedienā tiek veikti testi.
  • Ja testi neizdodas, kods nenonāks galvenajā versijā.

Å Ä« lēmuma pieņemÅ”ana bija ļoti sāpÄ«ga, jo... izraisÄ«ja daudz strÄ«du, bet tas bija tā vērts, jo... Atsauksmes sāka saņemt apvienoÅ”anās pieprasÄ«jumus bez stila atŔķirÄ«bām, un laika gaitā problemātisko jomu skaits sāka samazināties.

IaC testēŔana

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Papildus stila pārbaudei varat izmantot arÄ« citas lietas, piemēram, lai pārbaudÄ«tu, vai jÅ«su infrastruktÅ«ra patieŔām var tikt izvietota. Vai arÄ« pārbaudiet, vai infrastruktÅ«ras izmaiņas neradÄ«s naudas zaudējumus. Kāpēc tas varētu bÅ«t vajadzÄ«gs? Jautājums ir sarežģīts un filozofisks, labāk atbildēt ar stāstu, ka Powershell kaut kā bija automātiskais mērogoÅ”anas lÄ«dzeklis, kas nepārbaudÄ«ja robežnosacÄ«jumus => tika izveidots vairāk VM nekā nepiecieÅ”ams => klients iztērēja vairāk naudas nekā plānots. Tas nav Ä«paÅ”i patÄ«kami, taču bÅ«tu pilnÄ«gi iespējams pieÄ·ert Å”o kļūdu agrākos posmos.

Varētu jautāt, kāpēc sarežģīto infrastruktÅ«ru padarÄ«t vēl sarežģītāku? InfrastruktÅ«ras pārbaudes, tāpat kā kods, nav saistÄ«tas ar vienkārÅ”oÅ”anu, bet gan par to, kā zināt, kā jÅ«su infrastruktÅ«rai jādarbojas.

IaC testēŔanas piramīda

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

IaC testÄ“Å”ana: statiskā analÄ«ze

Ja vienlaikus izvietojat visu infrastruktūru un pārbaudāt, vai tā darbojas, iespējams, atklāsiet, ka tas aizņem daudz laika un prasa daudz laika. Tāpēc pamatam ir jābūt tādam, kas darbojas ātri, to ir daudz, un tas aptver daudz primitīvu vietu.

BaŔs ir viltīgs

ApskatÄ«sim triviālu piemēru. atlasiet visus failus paÅ”reizējā direktorijā un kopējiet uz citu vietu. Pirmā lieta, kas nāk prātā:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Ko darīt, ja faila nosaukumā ir atstarpe? Nu, labi, mēs esam gudri, mēs zinām, kā izmantot pēdiņas:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Labi padarÄ«ts? Nē! Ko darÄ«t, ja direktorijā nekā nav, t.i. globÄ“Å”ana nedarbosies.

find . -type f -exec mv -v {} dst/{}.bak ;

Tagad labi izdarīts? Nē... Aizmirsu, kas var būt faila nosaukumā n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statiskās analīzes rīki

Problēma no iepriekŔējā soļa varētu tikt pieÄ·erta, kad mēs aizmirsām citātus, jo dabā ir daudz lÄ«dzekļu, lai to novērstu Shellcheck, kopumā to ir daudz, un, visticamāk, zem sava IDE varat atrast lÄ«nijpārvadātāju savai stekam.

Valoda
Instruments

stipri iesist
Shellcheck

rubīns
RuboCop

pitons
Pylints

ansible
Ansible Lint

IaC testēŔana: vienību testi

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Kā redzējām no iepriekŔējā piemēra, lÄ«kumi nav visvareni un nevar norādÄ«t visas problēmzonas. Turklāt, pēc analoÄ£ijas ar testÄ“Å”anu programmatÅ«ras izstrādē, mēs varam atsaukt atmiņā vienÄ«bu testus. Kas uzreiz nāk prātā, ir Å”unÄ«ts, junit, rspec, pytest. Bet ko darÄ«t ar ansible, chef, saltstack un citiem viņiem lÄ«dzÄ«giem?

PaŔā sākumā mēs runājām par CIETS. un ka mÅ«su infrastruktÅ«rai ir jāsastāv no maziem Ä·ieÄ£eļiem. Viņu laiks ir pienācis.

  1. Infrastruktūra ir sadalīta mazos ķieģeļos, piemēram, Ansible lomas.
  2. Ir izvietota sava veida vide, neatkarīgi no tā, vai tā ir doka vai virtuālā maŔīna.
  3. Šajā testa vidē mēs izmantojam savu Ansible lomu.
  4. Mēs pārbaudām, vai viss strādāja, kā mēs gaidījām (mēs veicam testus).
  5. Mēs izlemjam labi vai nē.

IaC testēŔana: vienību testēŔanas rīki

Jautājums, kādi ir CFM testi? Varat vienkārŔi palaist skriptu vai Ŕim nolūkam varat izmantot gatavus risinājumus:

CFM
Instruments

Iespējams
Testinfra

Šefpavārs
Inspekcija

Šefpavārs
Serverspec

sāls kaudze
Goss

Piemērs testinfra, pārbaudot, ka lietotāji test1, test2 pastāv un ir grupā sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Ko izvēlēties? Jautājums ir sarežģīts un neskaidrs, Å”eit ir piemērs izmaiņām projektos github 2018.ā€“2019. gadam:

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

IaC testēŔanas ietvari

Rodas jautājums: kā to visu apvienot un palaist? Var ņem un dari pats ja ir pietiekams skaits inženieru. Vai arī varat izmantot gatavus risinājumus, lai gan to nav ļoti daudz:

CFM
Instruments

Iespējams
molekula

Šefpavārs
Testa virtuve

Terraform
Terratest

Github projektu izmaiņu piemērs 2018.ā€“2019. gadam:

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Molekula vs. Testa virtuve

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Sākotnēji mēs mēģināju izmantot testkitchen:

  1. Paralēli izveidojiet virtuālo maŔīnu.
  2. Izmantojiet Ansible lomas.
  3. Veiciet pārbaudi.

25-35 lomām tas strādāja 40-70 minūtes, kas bija ilgi.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Nākamais solis bija pāreja uz jenkins/docker/ansible/molecule. Idioloģiski viss ir vienāds

  1. Lint rotaļu grāmatas.
  2. Sakārtojiet lomas.
  3. Palaist konteineru
  4. Izmantojiet Ansible lomas.
  5. Palaist testinfra.
  6. Pārbaudiet idempotenci.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

40 lomu pildÄ«Å”ana un duci pārbaudÄ«jumi sāka aizņemt apmēram 15 minÅ«tes.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Tas, ko izvēlēties, ir atkarÄ«gs no daudziem faktoriem, piemēram, izmantotā kaudzes, komandas pieredzes utt. Å”eit katrs pats izlemj, kā aizvērt vienÄ«bas pārbaudes jautājumu

IaC testÄ“Å”ana: integrācijas testi

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Nākamais solis infrastruktÅ«ras testÄ“Å”anas piramÄ«dā bÅ«s integrācijas testi. Tie ir lÄ«dzÄ«gi vienÄ«bas testiem:

  1. Infrastruktūra ir sadalīta mazos ķieģeļos, piemēram, Ansible lomas.
  2. Ir izvietota sava veida vide, neatkarīgi no tā, vai tā ir doka vai virtuālā maŔīna.
  3. Uz Å”o testa vidi attiecas daudz Iespējamās lomas.
  4. Mēs pārbaudām, vai viss strādāja, kā mēs gaidījām (mēs veicam testus).
  5. Mēs izlemjam labi vai nē.

Aptuveni runājot, mēs nepārbaudām atseviŔķa sistēmas elementa veiktspēju kā vienÄ«bu testos, mēs pārbaudām, kā serveris ir konfigurēts kopumā.

IaC testÄ“Å”ana: testi no beigām lÄ«dz beigām

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

PiramÄ«das augÅ”pusē mÅ«s sagaida testi no gala lÄ«dz beigām. Tie. Mēs nepārbaudām atseviŔķa servera, atseviŔķa skripta vai atseviŔķas infrastruktÅ«ras elementa veiktspēju. Mēs pārbaudām, vai daudzi serveri ir savienoti kopā, mÅ«su infrastruktÅ«ra darbojas tā, kā mēs to sagaidām. Diemžēl es nekad neesmu redzējis gatavus kastes risinājumus, iespējams, tāpēc... InfrastruktÅ«ra bieži ir unikāla, un to ir grÅ«ti izveidot un izveidot testÄ“Å”anas sistēmu. Rezultātā katrs rada savus risinājumus. PieprasÄ«jums ir, bet atbildes nav. Tāpēc es jums pastāstÄ«Å”u, kas ir, lai pamudinātu citus padomāt vai ieberzētu degunu par to, ka viss ir izdomāts jau sen pirms mums.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Projekts ar bagātu vēsturi. To izmanto lielās organizācijās, un, iespējams, katrs no jums ir ar to netieÅ”i krustojuÅ”ies. Lietojumprogramma atbalsta daudzas datu bāzes, integrācijas utt. Zinot, kā infrastruktÅ«ra varētu izskatÄ«ties, ir daudz docker-compose failu, un zinot, kurus testus palaist un kurā vidē ir Jenkins.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Å Ä« shēma darbojās diezgan ilgu laiku, lÄ«dz ietvaros pētniecÄ«ba mēs neesam mēģinājuÅ”i to pārsÅ«tÄ«t uz Openshift. Konteineri paliek tie paÅ”i, bet palaiÅ”anas vide ir mainÄ«jusies (labdien, D.R.Y. vēlreiz).

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

PētÄ«juma ideja devās tālāk, un Openshift viņi atrada tādu lietu kā APB (Ansible Playbook Bundle), kas ļauj konteinerā apkopot zināŔanas par infrastruktÅ«ras izvietoÅ”anu. Tie. ir atkārtojams, pārbaudāms zināŔanu punkts par infrastruktÅ«ras izvietoÅ”anu.

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Tas viss izklausÄ«jās labi, lÄ«dz mēs nokļuvām neviendabÄ«gā infrastruktÅ«rā: mums bija nepiecieÅ”ams Windows testiem. Rezultātā zināŔanas par to, ko, kur, kā izvietot un pārbaudÄ«t, ir jenkins.

Secinājumi

Ko es uzzināju, pārbaudot 200 000 infrastruktūras koda līniju

Infrastruktūra kā kods ir

  • Kods repozitorijā.
  • Cilvēka mijiedarbÄ«ba.
  • InfrastruktÅ«ras testÄ“Å”ana.

saites

Avots: www.habr.com

Pievieno komentāru