May Microservices Meetup for Budapest
•Download as PPTX, PDF•
0 likes•153 views
This document discusses continuous deployment with containers. It describes an old deployment process that was chaotic due to being a "one-man-show". The author then outlines a plan to improve deployment by categorizing different service types including API, SERVICE, WORKER and MSERVICE. There are over 50 different services and 1000+ containers across 24 instances that need to be deployed.
Recommended
More Related Content
More from David Papp
Recently uploaded
Recently uploaded (20)
May Microservices Meetup for Budapest
- 1. David Papp pappdav.com - @pappdav Chief Architect, Co-founder -
- 2. Continuous deployment with containers
- 3. Old deployment - “One-man-show”
- 4. Chaos
- 5. Why? No!444 I don’t care! Maybe… OK!
- 6. The plan! :)
- 7. Service types: - API - SERVICE - WORKER - MSERVICE 50+ different service 1000+ containers 24 instances
- 8. Deployment
- 10. Question?
Editor's Notes
- Sziasztok! Papp David vagyok a Recart dolgozom.A kovetkeyo honapba lesz 2 eve. A regi nevunk GhostMonitor volt egy nagyobb brand valtason estunk at. Ha valaki esetleg nem hallot volna meg rolunk akkor azzal foglalkozunk ,hogy a webshopok konverziojat emeleljuk ami jelenti ,hogy minel tobb vasaroljuk legyen. Egy rovid cegtortent ,hogy mi mikent juttotunk el ide. Ugy-e aki nem ismer minket az felteszi a kerdest minek is van nekunk szuksegunk kontenerek vagy-e egyaltalan barmilyen microservices architecktura. Egyreszt gondoljatok bele milyen nehez dolgunk. Nah nem kell sajnalni mineket csak erdemes megerteni a problemankat. . Mi egy SaaS vagyunk amit az ugyfelek igenybe vehetnek. Nah mar most ha egy ugyfel beregisztral akkor mi nemtudunk rola semmit mennyi latogatja van mekkora forgalmat bonyolit le…stb. A mi kis tracking rendszerunk beepul a shopjaba automatan es hasznalja boldogan. Ez ahhoz hasonlo mint a google analytics amint barki betelepithet az oldalaba a legkisebbetol a legnagyobbig es ez meg se omlik ossze . Nah erre a problemara minekunk is fel kell keszulni mert mi sem ismerjuk a masik oldalt. Nagyabbol naponta 20-30 uj regisztracionk van es kb. 2500 aktiv e-commerce shopunk van ami b2b szektorba egy eleg szep szam.
- A meetup elejen volt egy szavazas …. Nah de mi szuksegunk van nekunk kontenerekre… Ugy-e lattuk Andras eloadasabol ok ,hogyan juttotak el herokutol egeszen a kubernetesig nem volt egy konnyu ut. Mi anno a CoreOS beepitett rendszeret a fleetet hasznaltuk ami mar deprecated es nem fejlesztik tovabb ok is bealltak a kubernetes moge. Nah de mi utunk ugy vezetett amikor elkezdtuk a ceget akkor en pl. meg fel allasba nyomtam az elejen es hat szuletett egy MVP termek ami a production readyhez koze se volt viszont minden elkezdi valahol . Ezt ugy kell elkepzelni ,hogy volt egy 5 servicebol allo szorny ami valami microservicere hasonlito dolog volt. Nem vagyok ra buszke de mukodott. Igen am de ez a dolog nem maradhatott igy …
- Ez vagyok en kimas :D. Hat en voltam az egyetlen a cegnel aki deployolni tudot … ez milyen meno mar one-man-show!!!444 Hat ize nem… foleg ,hogy ebben a korszakban en meg nem voltam foallasu a cegnel igy azert meg viccesebb volt igy utolag... Az FTP-nel egy fokkal jobb volt mert mar dockerben volt. De Dockeres kornyezetben ez kb. ugyan annak a szintnek felelt meg. Szerintem igy vissza gondolva egy docker-compose-al jobban jartunk volna. A docker is meg nagyon az elejen jart akkor volt talan a technolgia 1 eves szoval elege gyerek cipo effektus. Nah de ezt ,hogyan is kepzeljuk el ezt a “folyamatott” hat ugy ,hogy jott Davidka fogdta a kis cli toolocskajat es amit ki kellet deployolni azt ujra inditotta mert igy a docker lehuzta a legujabb IMAGET!
- Hat igen ebbol aztan volt boven belso feszultseg egyreszt abbol ,hogy miert csak en tudok deployolni de nem csak ebbol hanem abbol is ,hogy ezt nem volt egy tul stabbil megoldas…. Es valoban nem volt igy vissza gondolva. Ezt azert mondom el ,hogy senki se fusson bele ebbe a hibaba. A startupok azert tudnak dinamikusan fejlodni es elore lepeni mert gyorsak a release ciklusok es gyorsan tudnak reagalni a piac es az ugyfel igenyekre. Persze volt mar tapasztalatom nagy rendszerekben meg hasonlokban de itt mindent 0-rol kellet felepiteni es nem ulhetem bele a joba. De ebben a pillanatban meg eleg messze vagyunk a continiustol is a deloymenttol meg messzebb. De mar tudjuk mi a gond tudjuk es nagyabbol tudjuk merre kellene tovabb menunk ekkora mar eleg sok cikken tul vagyunk amiket elolvastunk a temaban. Nah de hat a nagyszeru otletunket meg kellene osztatnunk az uzleti emberekkel a cegben mi lenne ha …
- O itt Soma a CEO-nk… pontosan nem emlekszem az arcara de szerintem kb. Igy kell elkepzelni. Miutan kozoltuk vele ,hogy ezt amit eddig epitgetunk azt ki kellene dobni a kukaba es az egeszet 0-rol kezdeni… A termek szempontjabol egy jelentos lepesnek tekintheto. Itt kezdet el a jelenegi architectura kirajzolodni. Amivel igazaolni tudtok ,hogy ez szukseges az ,hogy a folyamatosok a release ciklusok akar naponta orankent.
- Mi is volt a tervunk? Hat az ,hogy epitunk egy halal csillagot…de azert utkozben lejjebb adtuk az igenyeket a csillag rombolig majd megelegedtunk egy x-wingnel. Nah de komolyra forditva a szot felismertuk a problemainkat nem csak az ,hogy a jelenlegi folyamatainak es alkalmazasaink rosszak hanem az uzleti oldalt sem tudjuk kiszolgalni a jelenlegi architecturaval. Egy feature belefejlesztese minimum egy honap volt es igazabol barmit elrondhatunk…es a feature fele nem mukodott vagy csak sok hibaval. Itt fektetuk le a rendszereink alapjait van egy core-lib nevezetu cuccunk ami koa nevu framework-re. Erre azert van szuksegunk mert nem minden servicenek van szuksege minden modulra. Plusz igy csak egy helyen kell megjavitani vagy elrontani valamit . Most vezetuk be a kubernetest amibol kijott az elso stabil verzio. Eleg sok kockakazatot vallaltunk fel ahhoz kepest ,hogy kis startup vagyunk de tudtunk mit akarunk elerni. De most jarunk van service-discovery a rendszer boviheto. Van egy modularis felepitesu framework amire tudunk epiteni. Epitettunk is gyorsan lett kb. 20 serviceunk ami beszelgetett egymassal nem voltak duplikalt funkciok. Hanem egy valodi microservice architectura jott letre. Nah de itt jott a fekete leves….ezt mikent akarjuk ki deployolni es itt gondolok arra ,hogy nem kezzel szeretne senki ezeket deployolni es fejben tartani. Plusz most mar tok jo lenne egy staging kornyezett is ahol ki tudjuk tesztelni a featuroket. Igy utolag vissza gondolva szerintem jo iranyba indultunk el viszont orais terhet es bonyolultsagot vettunk a nyakunkba…
- A tervbol vegul ez lett…amikor vegert az ujra iras kb. 20 db servicenel tartottunk. Most kb. 50-nel. 4 fajta service tipust kulonboztettunk meg. API -> Ezek a servicek latszodnak kifele ezzel kommunikalnak a JS-k API-k SERVICE -> business logikat megvalosito szervizek. Itt talalhato a rendszer mukodesenek fobb komponensei WORKER -> Valamit feldolgoznak nincsen endpointjuk. Szigoruan message queue-n keresztul kommunikalnak. Pl. ez vegzi az SQS message feldolgozasat amit betolunk es-be igy juttatunk eladod mongodb-bol es-be. MSERVICE -> Model service reteg. Mindegy egyes adatbazis tablanak van egy darab mservice amin keresztul olvassuk vagy irjuk az adatot. Igy letrehozva egy HTTP reteg az adatabazis folott. Amivel konnyebben tudunk akar DB engine valtani egy adott mservice alatt. Most ott tartunk ,hogy 24 instancen futtatunk korulbelul 1000 db kontenert.
- Nah de eljuttotunk mar oda ,hogy szuksegunk van valami uzembiztos megoldasra. Az a szerencse ,hogy Kubernetesbe egy csomo dolog megvan valositva csak hasznalni kell es nagyon jo alapot ad amire tudunk epitkezni. A jelenlegi deployerunk 4. generaciojat eli ami az jelenti ,hogy 4x irtam ujra eddig. Viszont most mar elege kiforrot szerencsere kezdjuk az elejerol. Elso gen Codeship webhook kommunikacio Egynel tobb servicet nemtudot kirakni Minimalis hibakezeles Nem hasznalt DB-t Kezdetleges template Szinkron deployment Masodik gen Codeship webhook kommunikacio Tudod tobb kulonbozo szervizt kirakni viszont az egymasra futasok problemakat okoztak Kezdetleges hibakazeles Nem hasznalt DB-t Statikus template kezeles Szinkron deployment Harmadik gen Codeship webhook kommunikacio API-worker alapu volt Tobb szintu beallitas kezeles Dinamikus template kezeles DB hasznalat Aszinkron deployment – queue kezeles ( Redis ) Elosztott lockolas Negyedik gen Codeship steps Build resze CLI <> API kommunikacio Lockolas Tobb szintu beallitas kezeles Transzparens Hibas deploy eseten hibas build CI folyamat resze
- Hogyan is epul fel a build es deployment folyamatunk. Deployment resz csak staging es master branch eseten fut le. CI-ra mi codeshipet hasznalunk es itt vannak ugy nevezett steppek. Minden egyes lepes az egy STEP. Kiveve az zold resz ott csak szet bontottam ,hogy jobban ertheto legyen. Szoval eloszor is a fejleszto be commitol valamit a repo-ba arrol kap egy hookot a codeship ami leirok fajlok alapjan megezni mit is kell csinalnia. Az elso lepes ,hogy lehuzza a buildeleshez szukseges dependenciakat. Le buildeli az alap docker image-t ami szukseges a teszteleshez ebben fognak futni majd a tesztek. Van ket parhuzamossan futo taskunk az elso ,hogy letrehozunk egy artifactot a kodbol ami nem tartalmazza a dev dependenciakat es ezt bemasoljuk egy docker image-be. Erre azert van szukseg mert egyreszt csokkenti a security issuek szamat masreszt kisebb docker image-t kapunk es a node-nak nem kell betolteni a sok felesleges dev depdenciat igy akar performanciat is tudunk novelni. Futtatjuk a tesztjeinket amennyiben ez sikeres lefut rajta a codecovarge amit felkuldunk codeclimate-ba amit a jobb oldalon latok. Ha mind a ket parhuzamos task sikeres. Felpusholjuk az artifactes docker image buildet QUAY-ra. Meg taggeljuk a jelenlegi git commit id-val es egy staging vagy masterrel taggel. A deployment elso lepese ,hogy lockoljuk az adott buildet ne tudjon egymasra futni ket deploy. Ez jelenleg 15 perc timeoutot jelent. Ha nemtud a deployment 15 perc alatt lefutni akkor ra fog futni a kovetkezo. De ez meg nem tortent meg. Ha pedig lockolas kozben rafut a deployment akkor addig var a lokcolasnal ami le nem fut. A lockolas utan a kovetkezo lepes ,hogy elkeri a deployment-cli a a deployment-api-tol a templatet. Ez tartalmazza az eroforrast hasznalatott az environment valtozokat amit teljesen szabadon tudjuk modositani es teljesen dinamikus. API-k eseten pl az ingress letrehozasa is itt tortenik. A kovetkezo lepes maga a deployment itt a CLI a kubectl nevu konzolos tool-t hivja segitsegul. Itt egy sima apply fut le modositja a deploymentet. A kubernetes maga megcsinalja ,hogy darabszamtol fuggetlenul leallitja elinditja az ujakat. Deployment monitoring a kubectl-be van lehetoseg ami figyeli ,hogy hol tart a deployment igy a fejleszot Is latja ,hogy hol tart kb. a deploy. A masik funkcioja ,hogy ha nemtud elindulni a service vagy barmi hiba van akkor autorollback lep eletbe igy hibas service nem marad kint. Ez esetben a build failed igy jelezve mindenkinek ,hogy gond van. Ha minden rendben lefuttot akkor unlock lefut. Termesztesen ha fent hiba van az unlock automatikusan lefut exception eseten. Deployment tracking az egyik legfontosabb resz ezzel taggeljuk meg a metrickakat es fogjuk latni ,hogy ha performancia eses , hiba rate …stb akkor tudjuk ,hogy ez a commit okozta hibat sokkal egyszerubben tudunk debugolni.