Download to read offline
Uploaded byDavid Papp
Continuous Deployment with Containers
- The company uses microservices architecture with 50+ services running across 300+ containers orchestrated by Kubernetes. They have fully automated continuous integration and deployment. - CoreOS is used as the lightweight OS which updates automatically and stores services in read-only containers. Kubernetes provides service discovery, auto-scaling, deployment, rollback and resource management for containers. - The software development process follows a continuous delivery model where code changes are deployed through a pipeline to ensure the software can be reliably released at any time.
More Related Content
Similar to Continuous Deployment with Containers
![[FREE PDF sample] Containerizing Continuous Delivery in Java 1st Edition Dani...](https://cdn.slidesharecdn.com/ss_thumbnails/46134-250214165216-ee5f0794-thumbnail.jpg?width=640&height=640&fit=bounds)
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Continuous Deployment with Containers
- 2. Continuous Deployment withContainers David Papp @pappdav Chief Architect @ghostmonitor
- 3.
- 4. • Established inMay 2015 • The team headcount: 13 • Company profile: E-Commerce analytics
- 5. What technologies dowe use?
- 7.
- 8. • Microservices architecture •50+ different services • 300+ containers • Scaling • Full automation • Continuous Integration • Continuous Deployment
- 9.
- 10. • Lightweight OSbased on Gentoo Linux • Updated with regular automatic OS updates • Has a distributed key-value store at the core • Read-only rootfs. Writeable /etc oAll services are in containers
- 11. •Distributed key/value store •Likea directory tree •JSON/REST API •Uses a Discovery URL
- 12.
- 13.
- 14. • Initial release2014 •Writtenin Go • Developedby Google • Usedby GooglefromGCloud
- 15. • Service discovery •DNS • Environment • Auto scaling for docker • Deployment • Rollback • “Auto rollback” • Healthy • Labels • Resource control • QoS • Namespaces
- 16.
- 18.
- 19.
- 20.
- 21.
- 23. What is ContinuousDelivery?
- 24. Continuous Delivery (CD)is a software engineering approach in which teams keep producing valuable software in short cycles and ensure that the software can be reliably released at any time. Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software 32 “
- 25.
- 26. “released at anytime”
- 28. Deployment pipeline Continuous Deliveryvs Continuous Deployment
- 29. •Commit/Push •Unit test •Integration test •End2endtest •Docker image build •Push registry
- 30.
- 31.
- 32. Shipping My name isEver Given
- 34. Ever Given Codeship2Kubernetes wrapper •Codeship2Kubernetes wrapper • Written in Ruby • Async • Worker • Message queue for Redis • Notification to Slack • Rollback • Template management • Resource control • Version control
- 36.
- 37.
- 38.
Editor's Notes
- #3 Rovid bemutatkozas, ki vagyok hol dolgozom. Mit csinalok mik a feladataim.
- #4 Kik is vagyunk mi? Hatarszunet szamolj 1...2...3
- #5 Egy ujonnan alakult startup ceg vagyunk. 2015 majusa ota dolgozunk a projekten. 13 fo dolgozik a cegnel. Egy E-Commmerce analytics toolt fejlesztunk ami segit a webshopoknak csokkenteni a kosarelhagyast.
- #6 Milyen technologiakat hasznalunk? 1..2..3
- #7 - Ruby - Nodejs - Redis - AWS - S3/CloudFront - EC2 - mongoDB - Codeship - CoreOS Docker Kubernetes GitHuB Monitorozasra: NewRelic Trace
- #8 Hogyan dolgozunk? 1..2..3
- #9 Fontos volt ,hogy skalazhato legyen az alkalmazas mivel mi nem ismerjuk ,hogy az ugyfeleinknek mennyi lattogatoja van es ezt forgalmat nekunk el kell nyelni. Kb. mint a google analytics eseten. Igy jott kepbe a microservices ami kis egysegre bontva egy sokkal konnyebben skalazhato rendszer es nagyfoku dinaminuzmost es sok problemat . De a projekt elejen meg nem igy volt … akkor csak konkretan volt 5 db szervizunk volt. Az meg ugy-e kezzel is eleg konnyen deployolhato es karbantarthato. Miutan a rendszert ujra irtuk teljesen microservices arhictekturara es a megfelelo patterneket betartottuk igy juttunk el a tobb mint 50-hez. 50 kulonbozo service futtatunk tobb mint 300 peldanyba. Ugy-e mar az elejen emlitettem fontos dolog a skalzas es ,hogy ne csak 1 peldanyba tudjon futni valami. A cegnel probalunk minden folyamatot automatizalni ezzel is csokkentve az emberi hiba faktort igy tobb eroforrasunk marad fejlesztesre es nem kell manualis dolgokat elvegezni. Mar az elejen meg kialakitasra es bevezetesre kerult a Continuous Integrationt es a Continuous Deployment. Ez ugy-e folyamatosan novekszik mi is folyamatosan fejlodunk es novekszunk ujabb es ujabb featuroket fejlesztunk a rendszerbe.
- #10 Hasznal valaki itt CoreOS-t (szavazas) ?
- #11 Teljesen lebutitott linux disztribucio ami Gentoo-ra epul. Az uzlemetetesi igenye kicsit es nagyon egyszeru karbantartani a beepitett autoupdate lehetoosegnek hala. Igy a DevOpsok es a SysOP-k munkajat megtudja konnyiteni. Alapbol talalhato benne egy key-value store ami a service discovery feladatot is ellatja es amit etcd-nek hivunk nagyon hasznos eszkoz igy nem kell kulon szenvednunk a service-discovery-vel hanem mar egy meglevo eszkozoket kapunk a kezunkbe. Csomag telepitesre nincs lehetoseg ez kifejezzeten csak Docker kontenerek futtatasara lett kitalalva. A rootfs nem irhato csak az /etc igy az integratias konnyen megorizheto.
- #12 Egy par szo az ETCd-rol ugy-e amit mar az elobb emlitettem egy key-value store de nagyon jol mukodik elosztott kornyezetben. Faformaban tarolja az adatokat. JSON/REST api-n kereszutl lehet belole lekerdezni az adatokat es egy discovery URL-n keresztul talaljak meg egymast vagy akar konkret ip is megadhato.
- #14 A kubernetes szlogenje…1...2...3
- #15 2014-ben keszult el az elso kiadas es most 2016-ban jott ki a stable release. Go-ban irjak es a fejlesztoi Google de most mar nagyon sok community memberje van es biztos vagyok benne ,hogy sok ceg fog moge allni. A google cloud alatt pl ugyan ez a szolgaltas fut. Most nezzuk meg a fontosabb funkciojit…
- #16 Service disovery -> Ez nagyabbol mindenki ismeri es hallot rola ugy-e ennek a szuksegesse akkor jon amikor egy elosztott rendszerben szeretnenk meghivni egy masik servicet viszont szamunkra transparensen nemtudjuk merre van. Megoljda, hogy ha megvaltozik az IP cime vagy a helye a servicenek akkor lekoveti ezeket a valtoztatasokat. A kubernetes ezt tudja DNS es ENVIRONMENT valtozok alapjan. Auto scaling for docker -> Tud autoskalzast dockereken szoval kulonbozo parameterek alapjan eltudja donteni ,hogy abbol mennyi darab szukseges Deployment -> Kapunk egy nagyon jo toolt amivel deployolhatjuk a serviceinket es vissza is tudunk vele allni amennyiben szukseges. Van egy automatikus rollback resze is amennyiben az service amit deployolunk valamilyen hiba miatt nem indul el akkor leallitja a folyamatott es nem is folytatja tovabb. Healthy -> Tudja vizsgalni egy adott service elerheto-e tudunk neki endpointot adni milyen suron nezze…stb Ez azert is hasznos mert ha lehal egy adott pod akkor nekunk nem kell kezzel beavatkozni hanem automatikusan ujrainditja. Resource control -> ez megint egy hasznos tulajdonsag fejlesztok “ellen” Megtudunk adni required es limits resourceokat. Termeszetesen tul tudjuk lepni a limits-t de a requiredben levo ertekeket nem. Ami azt jelenti ,hogy ha egy adott node-n elfogyott a required resource akkor oda nem rak ki a rendszer tobb servicet. QoS tudunk priorizalni ha valamelyik serviceunk fontosabb esetleg jelenleg nem hasznaljuk. Namespaces -> Ez a masik hasznos tulajdonsag ugyan is nekunk az eles es a staging rendszer ugyan abban a kornyezetben fut igy eltudjuk szepralni az egyes kornyezeket viszont resourcecontrollal megsincs problema.
- #17 Fogalmak: Master ami a controller Ez futtatja a jobokat es a tervezett feladatokat. Van egy API-ja ami-n keresztul az egesz cluster vezerelheto. ReplicationController Ez is a master szerveren talalhato. Ez vezerli a POD-okat. NODE az ugynevezettek workerek Ezeken futnak a kontenerek amik az ugynevezettek PODok ezek maguk a dockerek. Van meg egy service nevu dolog ezeken keresztul hivjuk meg a podokat es felel a terheles elosztasert es a service discoveryert is.
- #18 Ez egy bontott abra ,hogy is kell ezt az egesz mukodest elkepzelni. A labelek nagyon fontos reszei a rendszernek mivel ezek hivatkozunk eleg sok helyen. Tudunk egyszerre tobb verziot is akar elesben tartani.
- #20 4 fo kategoriat kulonboztetunk meg. Frontend – ez nginx szerver ami tovabbitja a kereseket az API-nak Amelyik servicenek van kulso laba az elott egy nginx van ,hogy vedjuk a serviceket a tamadasok ellen. API ez fogadja a kulso kereseket uzleti logikba nem igen talalhato meg bennuk. Service -> Az uzleti logika nagyreszet tartalmazza MS vagy MSERVICE a nev limitacio miatt muszaj volt leroviditeni nehany service eseten. Ezek a model servicek ezzek alnak kapcsolatban az adatbazissal vagy elasticsearchel. Nalunk minden egyes mongodb collection egy kulon mservice. Ha ugy alakulna viszonylag konnyen tudjuk cserelni a modelservice mogotti adatbazis motort.
- #21 Ugy-e az eloadasom elejen emlitettem ,hogy volt 5 service akkor igy nezzek ki a rendszer ezt meg konnyen le is tudtam rajzolni kezzel. Nah de most….
- #22 Most mar kulso toolra van szuksegunk ahhoz ,hogy tudjuk mikent is nezki az architekturank.
- #23 Nezzuk meg egy kicsit ki nagyitva ugy jobban latszanak a dolgok azert ha erdekel titeket megmutatom majd nektek a prezentacio vegen nagyban is. Hat eleg nagy pokhalo ilyen tool nelkul eleg nehez debugolni es at latni a rendszer egeszet es akkor most eljuttotunk oda ,hogy tudunk beszelni a …
- #24 Nalunk az a problema ,hogy allandoan deplopyolunk hamar elojott es stabbil megoldasra volt szukseg mivel a szoftverunk gyorsan valtozik akar orak alatt is. Szuksegunk volt arra ,hogy ne legyunk se idohoz se emberhez kotve ha egy uj verziot szeretnenk elesbe allitani. Viszont a legtobb esetben nem mindig van kesz megoldas a mi esetunkben se. Most mar ,hogy latjuk mire kell ez nekunk meg is tudjuk erteni a dolgot. Akkor nezzuk meg egy kicsit a continuous delivery-t mit is takar ez es mire valo.
- #25 Egy par mondatos osszefoglalo mire jon a CD es mik a elonyei. Hagy 10 masodperc szuntet ,hogy eltudjak olvasni.
- #26 Rovid ciklusok, rovid atfutasi ido. Nem 1 nagy release kerul deployolasra hanem sok kicsi. Ezzel is tudjuk csokkenteni sajat hiba lehetosegeinket. Nem telnek el honapok 1-1 release kozott hanem napok esetleg orak.
- #27 Ez egy kicsit eross kifejezes de igaz. A release nem fugg idotol nem kell release idoablakot tartani hanem nagyabbol a nap akar barmelyik napszakaba tudunk release-t kirakni leallas nelkul.
- #28 Varj 5 masodpercet beszed elott. Itt szeretnem abrazoltatni ,hogy kell elkepzelni a folyamatott. Ez egy vegtelen ciklus amit ha jol csinalunk sose szakad meg :D. ( ezt viccnek szantam ) 1. Release 2. build 3. test 4. deploy
- #29 Most akkor terjunk ra a deployment pipeline-ra. Mi ez mikent epitettuk fel hogyan hasznaljuk.
- #30 A folyamat ugy-e minden hol ugy kezdodik ,hogy van egy commit/push ez triggerer valamilyen CI ami lefuttatja a megadott teszteket. Ez a mi esetunkben keves volt es nem szeretunk volna sajat megoldast mert annak karbantartasa elege sok eroforrast elvett volna. Ezert valasztottuk a Codeship-t erre a celra pont akkor jelent meg egy beta programjuk ami kepes Docker-ben elvegezni a teszteket es amennyiben sikeresen lefuttot pusholja a teszteket egy registry-be ( dockerhub, quay ..vagy sajat ) Elege vizualis tipus vagyok szoval nezzuk meg ezt egy abran.
- #31 Mint az elobb is lattuk leirva itt egy folyamat abra ami bemutatja az altalanos folyamatot ettol mi se tertunk el. ( gyors ossze foglalo ) Continuous Delivery Kesz a code -> Unit tesztek futtatasa -> Integrate tesztek futtatasa -> tesztek elfogadasa majd deploy. Nah de mint latjatok van egy nagyon "kicsi" de annal nagyobb kulonbseg a delivery es deployment kozott meg pedig az ,hogy a deployment az elso esetben manualis a masodik esetben viszont egy teljesen automatikus folyamat. Ez a kis lepes viszont eleg sokat munkat tud okozni mind a devopsknak mind a fejlesztoknek. Peldaul ugy-e mikor futassunk migrationt? Mi tortenik ha megszakad a deployment de a migration lefuttatot? Vajon a regi kod hibatlanul tud mukodni az uj scheman. Ez nalunk szerencsere ugy-e pont megoldott mivel schema less adatbazist hasznalunk.
- #33 Most akkor terjunk ra a deployment pipeline-ra. Mi ez mikent epitettuk fel hogyan hasznaljuk.
- #36 A bal oldali a template a jobboldali pedig amit general nekunk a rendszer.