Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?
Mekkora méreteknél érdemes több docker container-be darabolni az alkalmazást?
■ H | K | Sze | Cs | P | Szo | V |
---|---|---|---|---|---|---|
26 | 27 | 28 | 29 | 30 | 31 | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 1 | 2 | 3 | 4 | 5 | 6 |
Mit értesz méret alatt? Ahogy
Találtam egy kis írást a
Miért akarsz processzeket
Egyelőre nekem pazarlásnak
VM
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/
Köszi! Elolvasom.
Nem
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.
Nem akarok, inkább az
Tobbnyire nem
Hogyan?
Követelmény
- 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.
Nem riaszt vissza a sok
Szivas
Oké, ez így világos, viszont
S
Én is ettől tartottam. Ha
Swarm
Még mindig nem értem, hogy
Nem konkrét számra, hanem
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.
Hát ha már ott tartasz, hogy
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á.
Nem mondtam, hogy válts, csak
Recept
Ha jól értem, akkor most az a
Nem
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.
darabolási kérdés, konkrét környezetben
Kell egy syslog szerver, ami mysql-be gyűjti a logokat.
Minden további app/konténer ebbe a log szerverbe küldi a logjait, tehát ő mindenkinek kell majd.
Kell egy DNS (dnsmasq), aki a helyi neveket feloldja.
A legtöbb konténernek rá is szüksége lehet.
Web szerver, flaskre (ez egy pythonos microframework webes alkalmazásokhoz) épülő alkalmazásokkal, részben saját adatbázissal, részben a syslog szerverével dolgozik.
----
+ pár olyan app, aminek a syslog + opcionálisan a dns szolgáltatásra szüksége van.
A ---- utániak mehetnek önállóan? És mi van a ---- előttiekkel?? Miket célszerű közös konténerbe tenni? Mi az, amit a compose segítségével érdemes/kell összefogni? Mi az, ami mehet egyedül is?
A hipszter módi
Loggolásra nem szoktak relációs adatbázist, ma az ELK stack a divatos.
DNS-re Consul (konténeren belül és kívül is működőképes).
A webszolgáltatások elé jöhet egy nginx TLS terminálásra, cachelésre.
Az egy konténer-egy processz
Lognál tekintsünk el picit attól, hogy én logolásra használom. Inkább az a kérdés, hogy van A konténer, aki ír egy B konténer adatbázisába, de ezt az adatbázist egy az A-hoz csak lazán kapcsolódó alkalmazás is olvasgatná, a C konténerből.
C nem futhat, ha A+B nem működik, de pusztán ezért figjam őket össze a composer(?)rel? Mert ilyen alapon az összes többit is be kellene tenni és az egészet egyetlen egységként kezelni... Szabad ilyet?
Pont itt a helye
A loggoláshoz már lehet egy másik gráf.
Így tudod elérni, hogy idális esetben minimális plusz munkával fellőssz egy második, mondjuk QA clustert az egész alkalmazásodból. Vagy ott próbálod ki az új imaget (az új kódoddal) mielőtt kimenne élesbe.
Vagy így lőheti fel minden fejlesztő a saját gépén miniben az egész szolgáltatást.
Pythonra van embedded szerver is, mi az előnye külön választani?
"Don't use in production
Általában szolgáltatásonként
Minél jobban szét tudod választani a különböző service-eket, annál jobban / könnyebben lesz skálázható.
Pl a db szerver egy konténer, web szerver a másik, python (vagy más futtatókörnyezet) a harmadik, stb. Ha a webszervernek kell egy külön db, akkor az célszerű, hogy szintén külön konténer legyen.
Php "vonalon" szokott olyan felállás lenni, hogy web - mysql - php-fpm (+ külön a cli-knek, web kapcsolat nélkül) - pl memcached - pl xy szolgáltatás még.
Ekkor mondjuk web-ből elég egy, ha nagy a terhelés, akkor php-ból könnyen lehet több, legszebb, mikor a mysql kevés, és azt kéne replikálni.. :)
Kicsit elbeszélünk egymás
O.K., hogy egy szolgáltatás/konténer, de mit nevezzünk szolgáltatásnak, mondjuk egy nginx-uwsgi-flask-python app négyesnél, ha az adatbázis szervert önállóan kezeljük?
És ha compose-t használok, akkor mi az, amit egy csoportban kell kezelni? Lásd syslog+mysql a tetején, de sok olyanom van, aminek ezek nélkül nem szabad elindulnia, mert a syslog mindnek kell, épp úgy, ahogy az alkalmazásomnak az nginx,uwsgi, adatbázis.
Mert egyelőre úgy fest, hogy ha van valami olyanom, ami mindenhez is kell, akkor az összes létező konténert be kell tenni vele egy "csoportba". Részben a függőség, részben a hálózati kapcsolatok miatt. Nem?
Lehet.. :)
az nginx "biztosan" önálló, mert - tekintve, hogy webszerver - kiszolgál kvázi statikus tartalmat is (js, css, képek, stb), amihez nem kell a futtató környezet. Nyilván így a statikus fájlokat be kell mountolni ide is. Futtatókörnyezet általában külön, szintén mountolva a szükséges forráskód.
Itt találtam egy példát, nem mysql db van benne, de az most mindegy szerintem. A python-hoz viszont nem tudok jobban hozzászólni, nem használom, de lehet rá sok példát találni.
Olyat is, amikor egyetlen konténerben van nginx-el, tokkal - vonóval, ez szerintem nem annyira szerencsés, mert mi lesz, ha pl 2 vagy több "darab" app-konténert szeretnél majd üzemeltetni, és nginx-ből egy is elég lenne?
Mondjuk a linkelt példából egy kicsit hiányolom a network beállítását, úgy tűnik, hogy default network-ön "mindenki mindenkit" lát, ami felesleges. Pl nginx - db kapcsolat nem kell.
Remélem így már tudtam segíteni.
Compose esetében jobb híján
Ott ugye van egy konfig fájl, abban mondom meg, hogy mely konténerek tartoznak szorosan össze, állitok be hozzájuk privát hálózatot, ha jól értem. Nem ismerem igazán.
Ui: bocs, napok óta fáj a derekam, tele vagyok gyógyszerekkel, a szokásosnál is lassúbb lettem tőle ;)
Igen igen,
- docker-compose verzió, ettől függ, hogy mit hogyan fog értelmezni, itt pl már tiltva van (vagy deprecated?) a konténeren belüli links: -el történő direkt összekötés.
- szolgáltatások, ezen belül:
- apache-php: elég csúnya megoldás így, de egy meglévő dev-szervert akartam "lemásolni", ezért lett egy konténer. Benne:
- context: megmondja, hol található az image, amit fel kell építeni
- dockerfile: Dockerfile saját image-leíró fájlneve
- APACHE_DOCUMENT_ROOT: image-en belül van szerepe, a "hivatalos" apache-php konténerben erre állítja át a docrootot
- ports: megmondjuk, hogy a gazdagép melyik portja felel meg a konténer melyik portjának (sokan nem a 80-ast használják a gazdagépen fejlesztésre, pedig lehet)
- volumes: mount-ok a gazdagépről, itt ez hibás, mert a log kétszer kerül be és nem lehetne egyszerre két helyen...
- kövi service, mysql:
- itt standard "hivatalos" image-et használunk, megmondjuk a pontos verzióját, de nem kell build szekció, mert nem nyúlunk bele.
- MYSQL_ROOT_PASSWORD: értelemszerűen a root user pwd-je lesz erre állítva az adott db szerveren.
- itt is be van mountolva a teljes data könyvtára, így törlés/újrabuildelés után is megmarad a db összes adata
- restart: asszem docker-compose up parancsnál van szerepe, hogy mindenképp felálljon.
- memcached: mert volt a "másolt" dev-szerveren is, viszont könnyedén külön konténerbe tehető "gyári" image-el
- networks: (NEM service!): fentebb már írtam, így nem is kellene megadni.
Hozzáteszem, hogy ez egy több, mint 1 éves példa, van is benne hiba, a v3 - nál biztosan van újabb, de sajnos nem követtem, mert még mindig nem használhatjuk... :(
Az egyes konténereken belül (pl apache-php -ben, a php kódban) így "keresztbe linkelve mindent" az egyes service-ek nevével lehet hivatkozni rájuk, pl a php a mysql szervert így éri el (config részlet):
'hostname' => 'db'
UI: ezért ne kérj bocsánatot, én is csak akkor reagálok, amikor van időm - türelmem - egészségem, és tudom is, hogy a derékfájás milyen... ;)
Lassúság: nem a válaszidőre,
az mind1
Köszi, úgy négy és fél órát
(pontban tíz órakor, a boltban sétálva a helyére ugrott a problémás csigolyám - mondjuk ez most egész jó, ahhoz képest, hogy szinte napra pontosan kilenc éve úgy kiakadt, hogy utána úgy nyolc-tíz hónapot ágyban töltöttem... :( )
Már csak azt kell majd megértenem, hogy a WSGI mit csinál a flask és az nginx között :)
layerek?
Best practice
Gyári, mint Official?
Jé... én emlékszem rosszul, vagy az új feature, hogy azt a kommentet, amire már válaszoltak, nem lehet szerkeszteni? :o
A layerek számának redukálásához szerintem bőven elég, ha a RUN egyetlen parancsot futtat (az ADD, COPY parancsokkal nem lehet mit tenni)
Régi
Szerintem egy "közösségi oldalon" így is kell(ene) lennie.
Pl valaki ír egy szakmai butaságot, válaszolok neki, kifejtve, hogy az miért butaság, ezután ő szerkeszti az eredeti kommentet, hogy már ne legyen butaság -> máris én tűnök hülyének.
Persze a faszbúk és társai direkt megengedik, mert "ettől izgalmasabb", mit sem törődve a konkrétan társadalom- és kommunikációromboló hatásával... (Amikor személyeskedés, sértés van a dologban, sokkal gázosabb ez a szerkesztés - törlés utólag feature.)
+1
Gyári image-ek itt
A build erőforrásigénye nem
Apropó layer: linuxon a jq nevű toolt ismeritek? (docker inspect image-neve | jq ... - szépen lehet szűrni a JSON eredményeket:) )
Nincs
Még érdekes lehet, hogy by default a köztes image-eket is megtartja (tehát fájlba mentve meg vannak), így ha törlöd is a kész image-et és / vagy kiadsz egy
docker-compose up -d --build
parancsot (itt a --build az érdekes, vagy ha törölted), akkor ezeket a meglévő köztes image-eket újra felhasználja -> jóval gyorsabb lesz a build, mint elsőre.Viszont ez jelentős háttértár-helyet fogyaszt, ha pl egy viszonylag kisebb SSD-d van, azon "meglátszik".
Fentebb ami apache-php -s példát írtam, abból az apache-php image kb 700 MB, és közel ekkorák a köztes image-ek is, emiatt máris kicsit célszerű a darabszámukkal spórolni.
Persze le is lehet törölni a köztes image-eket - mert semmi közük a konténer futtatásához -, de a következő alkalommal, amikor újra kell buildelni, akkor lassabb lesz, mert létre kell hoznia.
Kb úgy néz ki, hogy ahány RUN parancs, annyi köztes image.
layerek - olvasnivaló
Szóval találtam egy kis olvasnivalót a layerekkel és egyéb hasonlókkal kapcsolatban: https://docs.docker.com/storage/storagedriver/
--- ez egyre jobb: nem fogom újra írni, volt itt egy duplikált hozzászólás, ahogy a másodikat átszerkesztettem, eltűnt az első... Nem sérült meg az adatbázis? ---
Nem
Azért ez nem semmi időzítés
Ugyanis megnyitottam a témát, láttam, hogy a valójában egyszer beküldött komment két példányban van benn, az újabbat átírtam és mire beküldtem már nem volt meg a régi sem. :)
Ez saccra lehetett úgy 20-30sec.
Egyébként tényleg van valami gubanc a szoftverrel (vagy a mobilommal), mert már sokadszor fordult elő, hogy a "Spamrobot vagy?" captcha valami ocsmány hibaüzenetet dob vissza és nem tudok beküldeni egy kommentet vagy javítást. Ez a duplikátum is úgy jött létre, hogy a captcha-n problémázott, a végén meguntam, kimásoltam a szöveget, majd bemásoltam újként.
dnsmasq dockerben
Saját dns-t használok régóta, most szántam rá magam, hogy kivegyem a virtuális gépből és áttegyem konténerbe.
Belefutottam pár buktatóba, mert nem olvasok, nem gondolkodok... :(
1. Hiába publikálom az 53-as portot, nem lehet elérni. A konténerben futó tcpdump sem látja.
docker run ... -p IP-cím:53:53/udp ... formában kell ugyanis megadni, mert a /udp nélkül tcp portot publikál.
2. A nálam futó docker valami irreleváns, totál fals hibát dob, ha hiszünk a helpnek, hogy csak az egyik portot kell megadni, ha meg akarom mondani, melyik IP-hez kapcsolódjon és a publikus és a belső port azonos. Látszólag elég a -p 127.1.1.53:53, de valójában kell a második :53 is, plusz a /udp, mert nem minden dns kliens képes tcp-n társalogni.
3. Ha a dnsmasq-ot -d kapcsolóval indítom, akkor is előtérben marad, de ez csak debugra való. Így pl. nem vált usert, rootként fut, bármit csinálsz. Ha meg démonként indítod, akkor ugye elmegy háttérbe, a docker meg leállítja a konténert. (Mire erre rájöttem megint...) Szóval kell neki a -k kapcsoló (keep-in-foreground)
4. Ha -k kapcsolóval indul a dnsmasq, akkor elsikkasztja a logokat. Ahhoz, hogy a stderr-re menjen és a docker logs meg tudja mutatni, kell egy --log-facility="-".
5. Docker run parancsban felül lehet írni az entrypointot, de a paramétereket a konténer neve után kell írni, míg az --entrypoint=parancs kapcsolót elé.
... Valami kimaradt, de nem jut eszembe ...
+1: ha arra valaki tud magyarázatot, hogy a dnsmasq miért csinálja, hogy hol a jelenlegi lokális dnst használja, hol az ISP-től kapottat...a lokális a facebook.com-ra 0.0.0.0 címet ad vissza, a szolgáltatóé meg a valódit (nekem a 0.0.0.0 a jó ;) )
darabolás, de nem méret, hanem közös adat kapcsán
Syslog-ng menne konténerbe, de elfelejtettem, hogy szorosan kapcsolódik hozzá a logrotate funkció(*) is.
Elvileg a syslog-ng konténere kapna egy volume-ot, ami a host egyik könyvtárára mutat.
De ugyanezen a könyvtáron tud dolgozni clusterezés nélkül egy másik konténer vagy a host saját szoftverei?
Plusz az is gond, hogy a logrotate újraindítja a syslog szervert, szóval ha konténerből futtatnám, akkor azt hogy??
Saját elképzelés:
1. Syslog-ng mellé telepítem a logrotate-t is és remélem, hogy egy crontabot is tudok onnan működtetni.
2. A syslog-ng konténer használja a host könyvtárat, de a logrotate a host crontabból fut és nem a syslog demont inditja újra a rotálás után, hanem a konténert.
Valamelyik jó?
* = úgy emlékszem, a logrotate egy önálló csomag, nem része a syslog csomagoknak.
Update: tapasztalati úton úgy tűnik, a volume-ok használata elfogadhatóan működik akkor is, ha több konténer vagy a host+konténer használja.