As iskart noriu ispeti kad cia ieina beveik visa devops engineer'ingo geriausios praktikos (jos yra viesai zinomos ir istirtos per 50000 imoniu worldwide), ir cia tikrai nebus lengva suprasti. As jau taip bandziau abstraguotis ant kiek tik galejau ir tai tikrai nera lengva padaryti. Prasau klausk bet kokio termino kurio nesupranti. Cia yra metodologija ir as cia realiai atpasakoju savo darba. Ne techniniam zmogui tai pakankami didele informacine bomba.
Devops praktikos skirtos pagreitinti produkto gamyba, pastatyti produkta ant konvejerio. Viska automatizuoti iki maksimumo ir sumazinti palaikymo kastus iki minimo, ko maziau human factor, to geriau, nebent nori procesa pagerinti.
- Automatinis infrastrukturos pletimo igyvendinimas naudojant debesu (CLOUD) technologija. (Nuomojames resursus tiek kiek reikia is kitu, siuo atveju is AWS, pvz serveri su tiek ramais ir vieta kiek mums reikia, ir galimybe bet kada pakeisti jo konfiguracija, ir startuoti tiek serveriu kiek mums reikia musu sprendimui automatiniu budu [per API]) Taip pat cloud privalumas yra tame kad utilizuojam resursus iki maksimumo kad ne kapsetu bereikalingi doleriai uz resursu prastova.
- Galimybe pakeitimus (deplojinti) siusti i serveri bet kada, kad ir kas minute stabyliai ir be jokiu baimiu ar riziku.
- Stabilumo uztikrinimas naudojant distributed sistemas. Jeigu kazkas nuluz tai savajame pasitaisys, prisikels (self-healing systems)
- Metrikos - matuot kas vyksta sistemoje ir nuo tu metriku daryti sprendimus automatiniam pletymui (autoscale). Taip pat adaptuoti struktura pagal susiklosciusia situacija. Pvz vienas is produktu feature'u gali but ant tiek paklausus kad ji reikia plesti specifiniu budu, ieskoti kur kas kemsasi ir ieskoti kokius produktus tam naudoti (R&D - research and development)
- Pristatyti irankius programuotojams kurie padetu automatizuoti ju darba iki maksimumo.
- Galu gale bottlneck'u paieska, ieskoti kas kemsasi, dalinti duomenis i grupes ir naudoti skiringas duombazes kad operacijos su kazkokia duomenu grupe ne sulietetu. Ko daugiau duomenu to daugiau viskas kemsasi. Jusu atveju tai ypatingai svarbu kadangi pas jus yra crawleris kuris kemsa duombaze duomenim kiekviena diena.
- Pristatyta Infrastrukturos automatizacija (naudojant industrijos standarta - terraform iranki). Kad visus pakeitimus savo AWS resursose (amazone) tu galetum atsekti, paziuret ju istorija, ir galu gale atsaukti (rollback'int) i praeita konfiguracija jeigu kazkas blogai buvo padaryta. Siuo metu buvo viskas maigoma tiesiog aws dashboard'e. AWS resursai turi tiek parametru ir sarysiu kad per dashboard tiesiog fiziskai neimanoma viska suziuret ir surysti. Yra toks terminas (IaC) Inrastructure-as-code. Butent sita approach mes ir pradejom naudoti. https://en.wikipedia.org/wiki/Infrastructure_as_code
- Buvo suautomatizuoti sie dalykai:
- Subdomeinai cloudflare'e (jus naudojat cloudflare.com valdyti savo domainui)
- AWS VPC - virtual private cloud - jo visi tinklai ir potinkliai buvo automatizuoti, as galiu ikelti musu appsa i skirtingus potinklius ir tureti potinklius musu duombazei, kad juos atskirti tarpusavi. Cia yra privaloma naudojat amazon, be vpc negali sukurti tenai nieko :) Ir tolimesniam pletymui privaloma saugumo atszvelgiu.
- AWS security groups - su juo valdoma ir kokius portus atidaryti i isore.
- Bastion serveris - Kadangi VPC atkirta nu pasaulio priejima i sistema (iskirus web puslapi), tai cia toks kaip ir gateway i sistemos vidu. Galima prideti savo prisijungimus ir pns.
- AWS secrets - ne saugom prisijungimu kode, o naudojam aws secret manager servisa, kad gauti juos saugiai ir niekur tu prisijungimu neuzsviesti netyciom. Istiesu sita approach reiketu naudoti veliau i jusu appse, paciam kode.
- AWS RDS Aurora duomenu bazes klasteris. Pirmas dalykas kodel isvis reikejo klasterio tai failoveris, tai tokia strategija - numirus vienam servui automatiskai prisikels kitas. Siuo atveju numirus jusu duombazei jusu servisas bus nepasiekiamas pakol kazkas nepastebes nuluzymo. Antras dalykas galesite atstatyti duomenu bazes kopija atgal laike be downtime, taip pat galesite padidinti replikos serverio tipa (galinguma) be downtime.Trecias dalykas yra galimybe kurti papildomas taip vadinamas duomenu bazes replikas. Jos leidzia paskirstit apkrova tarp tu repliku (replika tai tiesiog kaip papildomas serveris kuri turi duomenu bazes kopija). Galima netgi kurti jas automatiskai kai CPU apkrova saus virs 70%. Bet deja pasirodo mes to negalim naudoti nes jusu naudojamas sprendimas (Frameworkas) nepalaiko repliku. Dauguma pasaulio frameworku ju palaiko pvz: spring, ruby on rails, django arba net ir symphony. Tad reikia atskirai diegti taip vadinama tarpine stotele (proxy) tarp duomenu bazes ir jusu aplikacijos, kuris skirstis uzklausas skaitymui ir rasymui i atitinkamas replikas. Is mano puses yra nedaziurejimas siuoje vietoje, nes Deivis manes dar klause ar tikrai ne reikes jo appse interkonektoriu, tiesa sakant maniau kad nereikes nes turejo jau veikti viskas out of the box, nes ne esu sutikes frameworku kur replikos butu nepalaikomos. Teko dirbti net su visai niekam nezinomiems frameworkais ir net ten joki bedu nekylo, tai maniau ir su loopback frameworku nekils problemu. Tiesa sakant dar pries imdamasis sito darbo minejau kad as ne esu node.js developeris, as python developeris, ir cia visiskai visko suziuret nu neimanoma, paaiskejo eigoje.
- Duomenu bazes migravimas i AWS RDS AURORA klasteri: Tam prireike konvertuoti esama duombazes schema i aurora duombazes schema, ir poto is tos schemos jau kurti aurora klasteri. Cia gali but biski painoka suprasti bet procesas istiesu uzeme net daugiau negu 8 valandas. As visa nakti prasedejau prie duombazes paruosimo migracijai, ir dar puse dienos ofise su Deiviu kad ja numigruoti.
- Parasyta dokumentacija kaip naudoti terraform iranki.
- Automatizacijo skriptus galima surasti cia: https://bitbucket.org/multiorders/multiorders-devops/src/master/
- Uz visa tai yra 6 dienos. Visa tai yra pazymeta asana board'e: https://app.asana.com/0/1124067998213936/board
- Su Marium sutarem kad pries nutraukiant sutarti uz papildoma 1 diena pabaigsiu esamos duombazes migracija. Nes butu ne sis nei tas moketi uz darba kuri poto negali panaudoti :) Nutraukti norejo sutarti del to kad mano availability buvo labai limited, o jums reikejo greiciau judeti beto suradot lead'a.
Sioje vietoj mes kaikur ne sueinam su Roku. Rokas mano nuomone mazai dirbo su Cloud hosting'ais ir HA sistemom. DEVOPS koncepcija jam irgi svetima. Dirbo tik su standartiniais hostingais ir nori taikyt standartinius sprendimus kurie nesilplecia, arba tinkami iki ten 10000 uzklausu i minute. Resursu kelimas (ramu dadejimas, cpu dadejimas, hdd dadejimas) yra blogas pletimo budamas, dar vadinamas vertikaliu pletymu. Nes kazkada ateis akimirka (o tas kazkada buna labai greitai) kai nesigaus pakelti daugiau resursu (Arba pakelus resursus greiciau jau niekas nebeveiks), o plestis horizontaliai buna per velu nes pas jus tiesiog per daug klientu ir per mazai laiko bus tam, ir cia dazniausiai startuoliai zlunga, nes produktas staiga tiesiog nustoja veikti ir klientai visi iseina :) Tokie puslapiai kaip delfi pvz ir jiems panasios vos ne vos sugeba plestis, del savo delsimo ir vertikalaus pletymo sumokejo labai didele kaina, daznai luzinejo, bet laimei Lietuvos srautui vertikalaus pletymo uzteko, bet jus gi ne ant Lietuvos dirbat, pas jus klientai is viso pasaulio :) Sprendziant pagal jusu duombazes dydi jus tapsit sistema su aukstom apkrovom jau sekanciais metais :) Viska ka parasiau apacioje yra HA pagrindai (https://en.wikipedia.org/wiki/High_availability) [sistemos su auksta apkrova], jusu atveji as isanalizavau ir pletymo planas butu mazdaug toks:
- Skaitymo ir rasymo uzklausu paskirstimas i duombazes replikas su pgpool2 proxy. Tam kad mes galetume plesti skaityma i duomenu baze. T.y. kad mes galetume startuot kad ir 1000 repliku, ir paskirstit uzklausas tarp ju. (Uztruktu dvi dienos)
- Esama aplikacija yra tiesiog patalpinta i serveri tokiu budu kad jos nera kaip is ten iskrapstyt. T.y. jinai nera portable. Tam reikia ja sukisti i Docker konteineri. Kad as galeciau greitai startuoti dar viena aplikacija kitam serveri tiesiog nukopijojant konteineri su visa konfiguracija viduje. Tas yra butinas veiksmas kai jusu sito vienintelio serverio neuzteks srautui atlaikyt.
- Kadangi jus dabar turit tik viena serveri, ateis laikas (ir as manau tai tikrai bus neuzilgo) kai jus net keldami resursus tam vieninteliam serveriui, aplikacija vistiek nuo to greiciau neveiks. Jusu puslapio uzkrovimas bus labai ilgas, uzklausos luzines. Tokiu atveju cia jau totalus batai bus, nes tokiai situacijai sutvarkyti reikia savaites laiko. Reikia tureti sistema (orchestrator vadinasi) kuri apjungia daugybe serveriu tarpusavi, ir kurioje mes galim startuoti tiek aplikaciju tuose serveriose - kiek mums reikia. O tam reikia to vadinamo portability, zingsnio isvardinto pries tai. Siulyciau naudoti Kubernetes orkestratoriu, AWS jau turi toki servisa vadinasi AWS EKS, gatavas Kubernetes klasteris kuris duoda visa ekosistema skirta plesti savo parasytus web servisus skirsai ir isilgai. As va kitam kontrakte diegiu kubernetes klasteri, nes produkto srautas planuojamas 2 miliardu uzklausu i menesi i ju aplikacija, bus puiki proga pernaudot koda.
- Galu gale reikia idiegti automatini aplikacijos pletima. Kad kai ateina srautas (t.y. monitoringo sistema rodo jog CPU ar RAM isnaudojamas daugiau neg 80%) sauna dar desimtis ar kad ir 1000 serveriu. Jusu atveju tai dar nera critical, jusu atveju duomenu baze yra labiau critical, ir duomenu idejimas (importeris) dabar yra tiesiog crucially urgent kuriam mums ir reikia lead developerio, kuris perrasytu sita code spaghetti i atskiras aplikacijas kurios gali bendrauti tarpusavi.
- Monitoringas - turim but informuoti kaip jauciasi sistema ir kada kas ir kur nuluzo
- Logingas - turim zinoti kodel nuluzo programa ir pastoviai stebeti ka programa raso i log failus
- Error tracking - turim matyt ir rinkti klaidas ivykusios jusu aplikacijoje i agregatoriu, i kuri turi reaguoti developeriai. Nes jeigu iskrito 100500 klaidu kazkuriose uzklausose, tai reik sistemos kuri sugebetu indetifikuoti ar cia ta pati klaida ir sugrupuoti jas. Yra toks produktas sentry.io labai tinka startuoliam, patogi sistema butent tam, lengva implementuot.
- Esamoj aplikacijoj nera testu strategijos. T.y turi but parasyti automatizuoti testai, kad jeigu as prisiloginu su tokiu useriu i dashboard'a - testas praejo, Ir tokiu testu turi but viskam, kiekvienam veiksmui. Kai parasai kazkoki kodo gabala, parasai ir testa, ir pries siusdamas pakeitimus i serveri tuos testus reikia praleisti ir jie atskleis ar nieko nesugrioviai. Siuo atveju bet koks pakeitimas jusu kode gali tiesiog sugriauti kita koki nors feature'a. Ir tas tiesiog praeis nepastebeta, o poto jums skambins klientai kurie tai pastebes kur nors sistemos gylumose, ir jums bus sunku atkartoti to kliento veiksmus. Be testu neapsieina nei vienas IT produktas. Galima pradeti polengva, nebutinai sedeti rasyti testus visa savaite, bet per diena juos reiketu parasyti bent jau po 3-4. Su laiku padengsite visa funkcionaluma. Tas beje liecia tiek frontend tiek backend. Buvau jusu kazkokiam frontenderiui nurodes isbandyt Katalon, taip pat ir Deividui, hebra biski pastrygo ten. Taip pat buvau parodes Deividui kaip rasyti testus jo frameworkui, nezinau ar jisai juos raso tiesa sakant, cia reikia gelezines rankos t.y. lead'o kuris stovet ir mustu per galva. Butu gerai tureti code review, kad lead'as tikrintu ar testai parasyti, ar jie praeina, paziuretu pati koda ir duotu bendru rekomendaciju.
- Esama aplikacija yra monolitine - tai yra labai blogai. Monolitine reiskia kad tai yra viena aplikacija kuri daro 100500 dalyku. Netgi turint testus, bus labai dazna situacija kad developeris nugriaus del vienos pataisytos vietos vietos 20 kitu vietu, tai labai stabdo darba. Tai pat developeriai negali nepriklausomai rasyti koda viens nuo kito neuzkabine vienas kito. T.y. jeigu vienas kazka sugriaus ka parase kitas, tai sukelia nepatogumus visai komandai. Tam reikia atskirti aplikacijas i vadinamas mikroaplikacijas, arba kitaip vadinama mikroservisais. Mikroservisai tai pat padeda plestis 100x paprasciau su monolitine aplikacija, downtime galimybe sumazejo iki nulio. Jusu servise gali nustot veikti kazkoks vienas funkcionalumas bet nenulus visa aplikacija. Ir vat butent situoje vietoje anksciau mineti orchestratoriai padeda suvaldyti mikroservisus, nes kai ju daugeja, ju palaikymas patampa labai sunkus sistemos administratoriams, arba man devopsui. Orchestratorius cia labai padeda. Kiekvienas is mikroservisu gi turi turet ir savo konfiguracija, turi atitinkamai plestis, kazkur reikia sitas taisykles ir konfiguracija laikyt. Mikroservisu zooparkas yra irgi problema, bet mikroservisai atnesa tiek nasumo kad dabar tai yra vienintelis budas kaip praplesti IT komandos produktyvuma iki maksimumo.
- Migruoti is Reliacines duombazes i ne realiacine duombaze, kitap vadinama nosql duombaze. Ecommerce case'as labai gerai tinka nosql duomabazes modeliui. Tokia duombaze labai lengvai pleciasi, ir labai gerai sutivarko su rasymo operacijom ir skaitymo operacijom. Taciau tai tik pradzia. Ateis laikas kai kazkokio konkrecios duomenuu grupes reikalaus dar greitesnes prieigos, ir tam reikes traukti duomenu grupe i atskiras duombazes. Kelione su duomenim yra irgi non-endless story, viskas priklauso nuo to kas labiausiai jusu produkte bus naudojama.
Toliau as jau gal nesiplesiu nes prasideda tokia magija kuria as jau i mirtinguju kalba neisversiu. Pvz Rate limiting, resource throttling, crossregion setup, multi-az setup, Delay handling. Tokiems dalykams realizuoti manes cia vieno jau neuzteks, cia reikia samdyti SRE kuris galetu priziureti sistema ir reaguoti i incidentus. Kazkada kai sistema pataps didele jums reikes tokio zmogaus. ir galbut net dar vieno devops. Tiek kiek jus galimybiu turit savo appse tiek aplikaciju realiai ir reikes, galit iskart dalinti 10 feature'u i departamentus. Jeigu aisku appsas bus naudojamas worldwide :) Visa tai yra standartines devops praktikos, istirtos ir isbandytos tukstancius kartu, veda prie to kad nebus techiniu skolu ir visos problemos isnyks, liks tik tai numatyt problemas toli i prieki ir ruosti irankius kad kai ateis apkrova viskas veiktu be priekaistu :) Pasaulis ne idealus bet devops metologija naudojama absoliuciai dauguma startuoliu UK, nes efektyvesnes praktikos kolkas nera.