ugrás a tartalomhoz

Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?

inf3rno · Szep. 4. (H), 00.39
Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?
 
1

Mit értesz méret alatt? Ahogy

MadBence · Szep. 4. (H), 12.53
Mit értesz méret alatt? Ahogy én tudom, a mostani trend az az, hogy minden futó processznek lehet adni saját konténert.
3

Találtam egy kis írást a

inf3rno · Szep. 4. (H), 14.56
Találtam egy kis írást a témában, most olvasom: link. Az világos, hogy van rá lehetőség, hogy minden egyes process külön container-t kapjon. Az a kérdés, hogy mi alapján lehet eldönteni, hogy hány process-nek járjon egy container? Gondolom függhet az alkalmazás működésétől.
5

Miért akarsz processzeket

MadBence · Szep. 4. (H), 17.34
Miért akarsz processzeket direkt összecsoportosítani?
7

Egyelőre nekem pazarlásnak

inf3rno · Szep. 5. (K), 06.05
Egyelőre nekem pazarlásnak tűnik nem így tenni. Gondolom az az érv ellene, hogyha elszáll a container valamiért, és újra kell indítani, akkor csak egy process száll el vele, a többi ugyanúgy dolgozhat tovább. Ennek talán nem minden esetben van jelentősége, szóval azt szeretném átgondolni, hogy mikor lehet fontos így szétszedni, és mikor nem. Persze ha tudsz mondani egyéb szempontot, ami hasznos lehet, akkor hallgatlak. Egyelőre nulla a tapasztalatom ezekkel a containerekkel.
8

VM

janoszen · Szep. 5. (K), 12.02
Ne ugy gondolj a Docker containerre mint egy VM-re. Nem az. Torolj ki a fejedbol mindent amit virtualis gepekrol tudsz, es azt hogy a Dockernek barmi koze lenne a virtualizalashoz.

Egy Docker container eroforrasigenye annyira minimalis, hogy csak nagyon specialis esetben eri meg vele szenvedni hogy kevesebb legyen belole. Ha elo is jon, akkor is inkabb azon fogsz dolgozni, hogy pl. a disk alrendszer legyen gyorsabb, nem fogsz osszetenni tobb alkalmazast egy containerbe.

Itt irtam reszletesen arrol hogy mi van a Docker alatt: https://www.refaktor.hu/nem-kivanatos-alkalmazasok-uzemeltetese-linuxon/
11

Köszi! Elolvasom.

inf3rno · Szep. 5. (K), 13.13
Köszi! Elolvasom. Egyébként azt mondják, hogy a docker nem sandbox és simán ki tud törni egy hacker belőle. link Ez mennyire igaz?
16

Nem

janoszen · Szep. 5. (K), 15.13
Alapvetoen nem... feltetlenul igaz. Egyreszt 2014-es a cikk es azota sok minden fejlodott, masreszt a Dockert onmagaban nem szokas hasznalni. Altalaban valami AppArmorral vagy ilyesmivel megtoldva jon. Ehhez hozzajon hogy a best practice altalaban az, hogy a docker image amit futtatsz ne futtassa rootkent a processt, vagy legalabb UID mapingot csinaljon, mert ugye ami root az root. Hacsak nem allitod at.

Ellenben maradjunk annyiban, hogy nem veletlenul van az, hogy a Google Cloudban vagy AWS-en komplett virtgepet berelsz es abban futtatjak neked a containereket, nem pedig osztott infrastrukturan mukodik. Ha third party imageket akarsz futtatni mindenfele ellenorzes nelkul, akkor arra nem a Docker valo. Containeren belul is lehet olyan csunyasagokat csinalni amik ellen nehez vedekezni ertelmesen, pl. fel lehet zabalni a disk IO-t.
18

Nem akarok, inkább az

inf3rno · Szep. 5. (K), 16.29
Nem akarok, inkább az érdekel, hogyha mondjuk feltörnek egy weboldalt, ami container-ben fut, akkor vajon a teljes szerver kompromittálódik e, vagy csak az adott container. Jobban örülnék az utóbbinak nyilván, ha megoldható. Köszi az info-kat! Beleolvastam a cikkbe, jó anyag, de most el kell ugranom. Később folytatom.
21

Tobbnyire nem

janoszen · Szep. 5. (K), 16.36
Tobbnyire nem, mert akkor en is szarban lennek, de ha lehet akkor ne rootkent fusson a PHP-FPM a containerben.
2

Hogyan?

Hidvégi Gábor · Szep. 4. (H), 13.27
Hogyan és miért merült fel a kérdés?
4

Követelmény

janoszen · Szep. 4. (H), 17.28
Ez nagyon sokrétű kérdés. Az alapfelállás az, hogy mindent darabolj külön containerbe hogy önállóan lehessen skálázni és mozgatni. Viszont van néhány kivétel:

- Ha a szoftvered működéséhez kell egy másik szoftver. Ilyen pl. a PHP-FPM mellé pakolt nullmailer ha olyan a PHP szoftvered.
- Ha valamilyen erőforrásra van szükséged a gazdagépről és agresszív cachelést állítasz be (ez esetben a külön containerek nem biztos hogy látják a módosításokat). Ezzel óvatosan, a mountolás szívásokhoz tud vezetni.
- Ha nem akarsz FastCGI-n loadbalance-olni vagy service discoveryvel foglalkozni pl. nginx és PHP-FPM között. (De ez esetben nagyon szeretnéd megnézni a docker swarmot. Nagyon nagyon. Mert jó.)

Ha ezen akarsz spórolni rossz úton jársz, mi több tucat containert futtatunk egy gépen minden probléma nélkül.
6

Nem riaszt vissza a sok

inf3rno · Szep. 5. (K), 05.59
Nem riaszt vissza a sok container, a kérdés inkább az, hogy egy alkalmazáshoz mennyi kell, hogy tartozzon, és hogy mi mentén érdemes darabolni. De ha az a válasz, hogy minden process kapjon külön container-t, akkor nagyon érdekel, hogy miért éri meg mindez az ezzel járó plusz költség ellenére.
9

Szivas

janoszen · Szep. 5. (K), 12.03
Minel jobban szet tudod darabolni, minel jobban fuggetleni tudod egymastol a komponenseidet, annal boldogabb ember leszel. Ugyanaz mint a kodnal. Laza kapcsolatokat akarsz a komponenseid kozott.
10

Oké, ez így világos, viszont

inf3rno · Szep. 5. (K), 13.12
Oké, ez így világos, viszont ha nagyon szét van darabolva valami, akkor írhatok egy rakás docker scriptet, hogy fellője az egész alkalmazást, esetleg a deploy-hoz is írni kell valamit, hogyha csak az alkalmazás egy része módosult, akkor csak azt indítsa újra. Egy csomó plusz idő és energia lehet mindezt menedzselni.
15

S

janoszen · Szep. 5. (K), 15.10
Nem akarlak elszomoritani, a Docker onmagaban nagyon keves a boldogsaghoz, valamilyen orchestration layerre (Docker Swarm, Kubernetes, Amazon ECS) szukseged lesz ha nem csak egy containert akarsz futtatni. Viszont ezek kezdetlegesek, sokat kell reszelni mire jo lesz. Talan a Docker Swarm all a legkozelebb a keszhez, de az tudja a legkevesebbet.
19

Én is ettől tartottam. Ha

inf3rno · Szep. 5. (K), 16.31
Én is ettől tartottam. Ha csak node-ot nézem, még a pm2 sem túl kiforrott, legalábbis régebben nehéz volt megoldani, hogy ne root-ként fusson a node. A docker-el hasonló lehet a helyzet, maga a tool jó, de valahogy menedzselni kell, biztonságossá tenni, és így tovább. Sajnos ez még nem out of the box jön, az még lesz egy pár év...
22

Swarm

janoszen · Szep. 5. (K), 16.37
Nekem a Swarm es az Amazon ECS van productionben. Nem mondom hogy teljesen hands-off, de sikerult ugyfelnek 3-4 ora alatt osszerakni egy kornyzetet amiben hostolhatja az oldalait es nem szivja meg ha az egyiket felnyomjak.
12

Még mindig nem értem, hogy

MadBence · Szep. 5. (K), 13.52
Még mindig nem értem, hogy miért akarsz egy konkrét számot meghatározni. Annyi konténer kell, amennyire az alkalmazásnak szüksége van. Egy nagyon minimál node-os alkalmazásnál én csinálnék a node-nak egy konténert, az adatbázisnak egy másikat, meg elé egy nginx-es reverse proxy-t. ez kb bármilyen termék esetén jó kiindulópont (ennél a tech stacknél).
13

Nem konkrét számra, hanem

inf3rno · Szep. 5. (K), 13.57
Nem konkrét számra, hanem ilyesmi receptre vagyok kíváncsi, mint amit írtál. Tegyük fel, hogy megvan ez az alap, és nődögél a node-os alkalmazás. A méret függvényében mikor érdemes bevezetni újabb container-eket?

A redbird-öt nézted már? Talán production ready lehet már az is, legalábbis már 3 éve fejlesztik folyamatosan. Elvileg hasonló a teljesítménye az nginx-hez képest.
14

Hát ha már ott tartasz, hogy

MadBence · Szep. 5. (K), 14.19
Hát ha már ott tartasz, hogy nem bírsz vertikálisan skálázódni, akkor indítasz annyi node konténert amennyi kell ahhoz, hogy stabilan fusson az app, és bekonfiguálod az nginx-et loadbalancingra.

redbird-öt nem használtam még, biztosan jó, de amíg az nginx mindent tud, amire nekem szükségem van, addig nem fogok váltani rá.
20

Nem mondtam, hogy válts, csak

inf3rno · Szep. 5. (K), 16.32
Nem mondtam, hogy válts, csak hogy próbáld ki, ha van egy kis szabad időd.
17

Recept

janoszen · Szep. 5. (K), 15.16
A recept az, hogy a Docker alapvetoen egy init processt indit el a container indulasakor. Ha egynel tobb szolgaltatast csomagolsz egybe, akkor szukseged lesz olyasmire mint a supervisord ami az egyik szolgaltatas leallasa eseten lelovi a masikat is. Ellenkezo esetben elofordul, hogy mondjuk a PHP-FPM lerohad, de a nullmailer miatt tovabb fut a container es az orchestration service is ugy latja hogy minden OK. Szoval minel jobban szet tudod szabdalni, annal kisebb a valoszinusege annak, hogy beleszaladsz ilyen reszlegesen futo containerekbe. Ha mindent egybe csomagolsz, akkor erolkodni kell az init szoftver confolasan, memoriat eszik, es tobb a mozgo alkatresz.
23

Ha jól értem, akkor most az a

inf3rno · Szep. 5. (K), 16.40
Ha jól értem, akkor most az a divat, hogyha lerohad az app a container-ben, akkor újraindul a container, a többi container-ben futó cucc, ami tőle függ, meg vár az újraindításra pl egy adatbázis esetén. Nem kell ennél bonyolultabb kód föléjük, mondjuk ami több container-ben indítja el ugyanazt, és ha az egyik lehal, akkor átadja a kéréseit egy másiknak?
24

Nem

janoszen · Szep. 5. (K), 19.18
Jol erted, ez a divat. Ha az alkalmazas hulyeseget csinal, akkor lesz szives fejbe loni magat, vagy a HEALTHCHECK parancs lesz kedves megmondani hogy az alkalmazas nem viselkedik megfeleloen, es akkor kidobjuk a containert.

A tobb container tipus (service) egyuttmukodese ugy van megoldva, hogy a) egy container tipusbol mindig tobb fut, igy egy ujraindulas nem okoz szolgaltatas kiesest b) a HEALTHCHECK kepes megmondani hogy a container nem indult el normalisan, hogy az orchestration agent ne folytassa a rolloutot c) van monitorozas d) esetleg van autoscaling, hogy ha no a terheles.