mire jó a Docker?

Fórumok

Hali,

Az elmúlt napokban nekiálltam docker-ezni, csináltam mindenféle service-eket dockerrel, automatizáltam kicsit, stb. stb.

De most jön az igazi kérdés: mire jó valójában a docker?

Használják éles service-ek futtatására, vagy a docker használata megáll az alkalmazás dev/teszt fázisában?

Olyat már láttam, hogy külsős fejlesztőknek docker image-ben adtak környezetet, hogy ne a környezet felépítésével töltse a drága projekt időt, hanem egyből érdemi munkát tudjon végezni.

Üzemeltetői szemmel azt próbálom megérteni, hogy miért jobb konténerezni, mint VM-et futtatni.

Az egyetlen valid érv szerintem az, hogy egy VM-nek sokkal nagyobb az overhead-je, mert sok benne a felesleges cucc egy konténerhez képest, tehát ugyanazt a vasat sokkal hatékonyabban ki lehet használni.

Ezen kívül van még más érv, vagy ez már éppen elég?

A "rapid deployment" meg "version control" nekem nem érv, mert ezek szerintem folyamatok, nem technikai szempontok.

Tudtok valós életből vett use case-t mondani, előnyökkel és hátrányokkal, amikor az üzemeltetés örül a Docker-nek és/vagy a konténerek éles szolgáltatást futtatnak?

Köszi.

Hozzászólások

Azért jobb a konténer mert nincs OS ami n-x helyet foglaljon, memóriát zabáljon, nem kell azt n-x frissíteni.
Melóban épp burjánzanak a VM-ek triviális feladatokra, sajnos ott Windows-ozunk, úgyhogy most Remote Desktop Services felé nézelődök.

(rejtett sub)

1 mondatban: natív sebesség mellett kapsz majdnem VM szintű szeparációt, annak nagyon sok előnyével.
Mi productionben arra használjuk, hogy széles palettán mozgó, egzotikus függőségekkel megáldott, csak binárisként terjesztett szoftvereket futtassunk ugyan azon a debian vagy centos hoston. Ez annyira hatékony (nem csak teljesítményben, hanem menedzselhetőségben), hogy ahol nem kell natív performancia ott is úgy megy, hogy a virtuális gépeken konténerből indulnak ezek. Meg így elég egy helyen összereszelni a konténert, az utána fut mindegyik helyen.

Hát... a natív sebességgel vannak fenntartásaim. IO pl. rettenet nálam. Pont múlt héten készítettem egy adatmigráló toolt, a helyileg futó PostgreSQL és a dockerben futó PostgreSQL között közelített futásidőben a különbség. (App mindkét esetben egy helyi gépen futó netcore-s cumó volt.) Lehet, hogy a docker for windowsban van elkúrva valami meg elég régi is, ami fennvan a dev gépen, nem mértem most máshol.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Megfelelően kell kiválasztani a prod ready driverek közül azt amelyik a workloadnak megfelel, vagy external mountot kell tolni. Konténer belső fájlrendszerébe egyébként sem illik üzleti adatot tenni. Ext mount esetén natív az io speed.
A Docker for Windows by definition developer only megoldás, és maximálisan nem javasolt semmiféle éles környezetbe (from doksi).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Rendben, de ettől még igazat írtam. A Docker for windows developer játékszer, ha neked ettől komolyabb elvárásaid vannak (rögtön a teljesítménnyel kezdve), akkor goto Linux.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Security (helyesen használva):
- egy extra réteg védelem a virtuális gépeken belűl, chroot++
- periodikusan eldobható vagy read-only sandbox környezet a támadásoknak kifejezetten kitett (pl külső user kódot is futtató) szolgáltatásoknak

Security (helytelenűl használva):
- virtuális gépek helyettesítése gyors, kis overheaddel rendelkező izolációs réteggel
- security scanner elől vulnerability-elfedés (ha éppen nem fut a konténer, a scanner sem látja, hogy mi van benne)

Operability (helyesen használva):
- futás közbeni in-place upgrade hatékony megvalósítása
- flexibilis service szétosztás hostok között (VM-nél finomabb granularitással), leginkább Swarm, Kubernetes témakör
- függőségeik miatt nehezen összehozható service-ek egy oprendszeren futtatási lehetősége

Operability (helytelenűl használva):
- helyes package-elés, installáció munkaigényének megspórolása (az image-ben elég random directory-ba behányni a fájlokat, függőségeket, nem kell rpm, deb és hasonlók, nem kell service file/init script, filesystem hierarch standardot sem kell betartani)
- üzemeltetési apróságok, mint pl logolás, monitorozás megspórolása ("what happens is Vegas container stays in containers" elv)

---
Régóta vágyok én, az androidok mezonkincsére már!

A "...logolas figyelesenek sporolasa..." temakorben mi pl. lekakkantjuk a container os logjait, az alkalmazaset nyilvan nem. Szoval akar eletbol ellesett is lehet.

Ja, most jut eszembe, vannak olyan image-ink, amelyekben custom forditott holmik vannak, ezek regebben .deb-be kerultek, de igy foloslegesnek veltuk a tulmozgast a temaban. A dockerfile forditja-helyrerakja-takaritja a forditos cuccokat oszt slussz.

Mi mindháromra (dev, teszt, éles) használjuk. Bevált.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Azert kontenerezunk, mert a friss host OS-re (CVE kovetes, amit megkovetel a fo tevekenyseg), nem elerheto az a regi php es ruby, amin a rendszereink egy resze fut. Ellenben egy docker image-ben mar franko. Sot a supervisord egy egyszeru wrapper szkripttel (amit tortenetesen php-nak hivnak) kepes a regi php-t inditani egy-egy szkriptre is.

Ezzel kezdodott tavaly tavasszal, aztan azota:
-hozadek, hogy megszuntek a szervizek ujrainditasanak problemai, intezi a docker-compose,
-uj vm telepitese is atlathatobb lett (eddit is az volt mondjuk, saltstack rulez), de most MEG durvan egyszerubb,
-es igen, oda lehet pattintani a random fejlesztoknek a kornyezetet, amiben fejleszetie kell a cuccot,
-az image-ket vegtelensegig lehet faragni egy akarmilyen gepen, es tuti ugy fog menni mashol is, included OS X.

Ami faj (csak picit), hogy neha random elhal egy-egy kontener, de az unless-stop trukkel ez csak a logokban latszik...

Ha jol rakod ossze, a konfiguracio management 80%-at helyettesiti. Innentol csak a gazdagepek SSH kulcsait, stb. valamint ha cloudozol, a cloud provideren levo cuccokat kell managelni, a szoftverek konfigjat nem. Ezen felul kapsz egy tesztelheto konfiguraciot amit 1:1 tudsz "szallitani" elesbe.

Irtam errol szep hozzan itt.

--
Pásztor János

Én pl. arra használom élesben, hogy az elavult CentOS 6-os hoston tudjak 6-os LibreOffice-t használni programból (Debian testing).
Ezt (egy 2GiB konténer) sokkal könnyebb átverni a rendszergazdákon, mint hogy telepítse a programnak szükséges LibreOffice-t + még 5 másik programot egy szerver környezetre.

A "rapid deployment" meg "version control" nekem nem érv, mert ezek szerintem folyamatok, nem technikai szempontok.

pedig ezek elegge technikai szempontok...

De legyen itt egy masik erv: sokkal egyszerubb az alkalmazas fuggosegek kezelese. Docker nelkul nem annyira trivialis ugyanannak a programnak, lib-nek (kulonosen is ssl-1.0.x vs ssl-1.1.x) kulonfele verzioit feltenni (es frissen tartani!) ugyanarra a gepre, mert egyik alkalmazasnak ssl 1.0 kell, a masiknak meg 1.1 (vo. debian 9-ben is elegge elszabottan csinaltak meg).

Docker eseteben minden image 1 alkalmazast szallit, amiben a neki feltetlen szukseges cuccok pont megfelelo verzioi vannak. Aztan biztonsagi szempontbol sem utolso, hogy a kontenerben futo alkalmazas csak egy minimal kornyezetet er el, amiben nincs semmi egyeb mas telepitve, ami potencialisan tamadasi vektor lehet.

A frissites is egyszerubb: nem te barkobazod ki, hogy az x lib 1.0.2 verziojat lehet-e upgrade-elni 1.0.3-ra, hanem az image keszitoje felelosseget vallal, hogy a) o upgrade-eli a komponenseket, b) amilyen verziokat beletesz, azok egyutt fognak egymassal mukodni.

--
"dolgozni mar reg nem akarok" - HZ 'iddqd' zoli berserk mode-ba kapcsol

Mondok egy példát. Kollégának van egy összerakott - megörökölt rendszere, ubuntu valami régebbin. PHP, SQL, config hegyek. Virtuális gépben.
Ezt viszont a belső security szabályzat miatt fel kellene húznia egy újabb verzióra (jogosan). Megcsinálja szépen az updateket,
és erre természetesen nem működik az alkalmazás, mert az újabb PHP, SQL, akármivel, ami az új rendszeren van, már nem megy,
régi nincs, vagy van, de nem úgy működik. Na, ilyenkor mennyivel jobb lett volna, ha lett volna egy dockerezett alkalmazása,
pontosan azzal a PHP, SQL, stb.-vel összelőve, és innnentől kezdve mindegy, hogy milyen linuxon fut, és az éppen aktuálisan
mi az, amit támogat.

Viszont az OS-t fel tudja updatelni, így legalább az nem lesz lukas. Rendszer ÜZEMELTETŐRŐL beszélünk, nem fejlesztőről.
Hiába sír az üzemeltető, hogy figy, nem kéne már mittomén 4-es PHP-t használni (csak tipp, nem tudom mi van alatta), amikor
ezt kell neki üzemeltetnie.

Ezzel az a gond, hogy ahol regi dolgok maradtak (foleg ennyire) ott jo esellyel mar korabban se volt vagy foglalkozott vele a fejleszto es jobb hijan maradt a regi rendszerben.

Masik reszrol meg lehet mondani hogy fejleszto felelossege, de gyakorlatban fejlesztoket joval kevesbe erdeklik a felhasznalt lib-ek es alkalmazasok frissen, biztonsagosan tartasa es konnyen lehet ugyanaz lesz belole, hogy uzemelteto dolga lesz a kontenerben is frissen tartani a komponenseket. Jobb esetben keszul automatan mindig uj verziokkal uj kontener amibe belekerul pluszba az alkalmazas, majd erre ellenorzesek lefutnak es hiba eseten megy ertesites fejlesztonek.

Nyilván ideális esetben ilyen nem fordul elő. Viszont gondolj bele, ott van egy ilyen rendszer, és a VM-nek át kell menni az ellenőrzésen,
és használni kell tudni. Mert ez a követelmény, oldd meg. Igen, gányolás. Igen, nem kéne csinálni. Igen, a fejlesztőnek javítania/új verziót
kellene adnia. Csakhogy aki üzemeltet (a rendszergazda) ezt maximum javasolhatja, de a döntést nem ő fogja meghozni. Neki üzemeltetnie kell.
Ilyen esetben kb. ez az egyetlen működő megoldás. Átrakja a trágyát egy docker image-be, ezzel együtt létre is jön egy olyan összeállítás, amivel
bármikor elő lehet állítani a szoftvert, viszont szépen el van szeparálva, és bármikor lehet alatta OS-t cserélni. Aztán ha/amikor majd kapnak
szoftver frissítést, akkor már csak a docker image-et frissítik a változásoknak megfelelően.

Persze jobb egy kontenerben azt a par szukseges dolgot regi verzion tartani, mint egy komplett rendszert a fuggosegek miatt.
Attol meg viszont a kontenerben megmarad a regi nem biztonsagos komponens, mivel mukodik friss rendszerben is es konnyen mozgathato, nehezebben fog eljonni az a pillanat amikor kibukik a csontvaz a szekrenybol.
Masik gondnak azt latom ezzel, hogy par ev utan azert lesz akar tobb szaz verzio is hasznalatban ugyanolyan kontenerbol, mert konnyebb lesz sokszor fenntartani egy plusz regebbi verziot is mintsem most ehhez a programhoz, honlaphoz stb.-hez is hozza kelljen nyulni kicsit is, mivel ujabb verzioju kornyezetben nem mukodik rendesen.

Jo alternativa nincs, valakinek idovel meg kell hozni a dontest hogy vagy kolteni kell az alkalmazas utana igazitasara vagy megszuntetni a szolgaltatast.
Docker nelkul ezt segitette olyan hogy megall a szerver amin futott, vagy ha vm-rol van szo akkor konnyebben ra lehet mondani hogy oprendszer annyira regi hogy nem supportalt amiben fut az alkalmazas, docker-el ezeket meguszod ugymond.
Szerencsesebb esetben alkalmazashoz kapcsolodo kliensek rendszeresen frissulnek es idovel elojohetnek olyan dolgok hogy mar a kliens nem fogja tamogatni a regi verziot, vagy csak nem mukodik rendesen vele es akkor jon olyan iranybol a kenyszer a frissitesre.

Azt nem értem, hogy a security frissítést miért is ússza meg bárki Docker esetén? Elmismásolni persze el lehet, de ugyanúgy VM-ben vagy bare metalon sem kötelező frissíteni, csak ajánlott...:)

Ha valaki Docker / container alapú deploymentre áll rá, akkor feltételezem, hogy megvan a folyamata arra, hogy milyen ütemben buildel friss verziót a containerekből, frissített csomagokkal, és azokat hogyan teszteli és deployolja. Mondjátok hogy igen...:)

Update: visszaolvasva értem, hogy van egy hely, ahol a VM-et auditálják, viszont a konténerben futó dolgokat nem, és ez a kiskapu egy nem frissített szoftverre. De ez nem egy hiba a processzben, amit a rendszergazdának munkaköri kötelessége jelenteni? Függetlenül attól, hogy értem azt, hogy sokszor kell (jó esetben átmeneti) kompromisszumot kötni...

igen! :-)

Amugy nyilvan elmeletben / elvben mindenki tamogatja azt, hogy pl. a regebbi lib-ek (felteve, hogy meg az EOL statusz elott vagyunk) is korrektek legyenek. A gond a gyakorlattal szokott lenni, ha a menedzsment azt mondja, hogy nem foglalkoznak olyan dolgokkal, amivel nem termelnek penzt. Ha pedig valaki nem fizet a support-ert v. update-elt verziokert, akkor valahol a zsak a foltjat esetenek latom a kialakult szituaciot...

--
"dolgozni mar reg nem akarok" - HZ 'iddqd' zoli berserk mode-ba kapcsol

Én azt nem értem, miért mindenki a legacy szarok managelését látja mindenki a dockerben?

Mintha fordítva ülnénk a lovon.

Ahogy én látom: annélkül, hogy neked az X szolgáltatáshoz, aminek szüksége van Y & Z komponensekre, mindent kézzel kellene felrántsál, meg azok függőségeit, meg a többit, gyorsan felrántasz 2 docker image-t, a megfelelő konfiggal + adatperzisztenciával (pl. mellé egy mongo + egy postgresl), az X-nek meg egy dockerfile, ami a latest gratest php+modulok image-re berántja még a te kódodat rá egy + layerbe, és ha php, vagy valamelyik modul, vagy a kódod frissül, akkor mehet a friss image build, teszt, deploy. Automatizáltan.

Szóval... ahonnan én nézem, ott pont inkább arra eszköz, hogy a legfrissebb dolgokat tudd együtt tartani, és tesztelve, automatán frissen is tartani. Ha meg valami valahol törik: meg lehet nézni a teszt kimenetét mi tört el, javít, build, teszt, és...

gyorsan felrántasz 2 docker image-t
Igen, így szokott kezdődni, docker hubról lerántani az image-et és hajrá. Aztán mikor valami éppen mégsem működik jól és kénytelen vagy belenézni akkor jön először a levegő után kapkodás, aztán kisvártatva kinyílik az átokláda. :)

Csődkatasztrófa, amiket képesek ilyen image-ekben emberek elkövetni és ráadásul még publikálják is. Nem ritkán az a vége, hogy kénytelen vagy magadnak buildelni az image-eket.
---
Régóta vágyok én, az androidok mezonkincsére már!

#1: nem mondtam, hogy dockerhub-ról kell jönnie az image-nek
#2: ha épp a dockerhub-os image nincs elszabva, akkor amúgy nem mindegy? Úgyis van rendes teszted, aminél kiderül még élesítés előtt, hogy jó lett-e az új verziós image-gel épített szervíz. Ha nem múkodik, akkor nem deployolod production-be, maradsz az előzőn + látod valahol a warn-t, hogy a friss image-gel meg van mukorodva a dolog.

Tegyük fel - a production azt jelenti, hogy a konténerizált service egy publikus szolgáltatás hostolásában vesz részt (backend vagy frontend igazából mindegy, de utóbbi nyilván cikisebb). Ilyenkor illendő megfelelni bizonyos hardening követelményeknek - ezzel gondolom nem mondok újat. Igényesebb esetben valami CIS profilnak, de legalább bírja ki a service, ha pl selinux enforcing-ra van állítva (elnézést, hogy éppen redhat-es szemüvegen keresztül nézem a problémát). Sajnos ilyen image-et már nagyon ritkán találsz.
---
Régóta vágyok én, az androidok mezonkincsére már!

Mondjuk nem rögtön a "cél"-imagek (ergo bizonyos dolgokhoz kell írj Dockerfile-t és összerakd) , és még kellhet rá emiatt pár layer, de a CI/CD már ugye másik réteg / problémakör...
De reponak azért ott egy registry.access.redhat.com, szépen tagelve, karbantartva, amit akarsz! ;-)

Miért? Nem kell minden alkalommal buildelni és utána már készre gyártott image vár. Cserébe az olyan (és az kerül bele), amit szeretnél.

pl.: https://hub.docker.com/r/nevergone/

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Jó, de akármilyen környezetet is használsz, azt munka előállítani és fenntartani, nem? Annyi, hogy ezt egy helyen megcsinálod, feltöltöd az image-t és máshol máshol már a kész image-t használhatod fel.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Persze, nekem nem is ezzel van bajom, hanem elsősorban az ökoszisztémával ami létrejött körülötte. Finoman szólva nem production minőségű image-eket publikálnak fejlesztők, a másik oldalon pedig bőszen hirdetnek irreális fejlesztési és üzemeltetési effort-megtakarítást ezekre alapozva. A harmadik oldal pedig a managerek, akik mindezt elhiszik, természetesen azonnal bevezettetik, a végén pedig - nyilván - az üzemeltetők a hibásak ha:

a) a követelmények megmaradtak -> nem jönnek a megtakartási számok
b) a követelmények az image-ek minőségéhez lettek igazítva -> valami ordas pofonba sikerült beleszaladni
---
Régóta vágyok én, az androidok mezonkincsére már!

Minden eszközt lehet szarul használni, ez nem feltétlen az eszköz hibája.
Amúgy meg mindenki készíthet image-ket magának teljesen nulláról, nem kötelező semmit sem használni a dockerhub-ról. A nagyobb helyeken így is tesznek.
Plusz szerintem az image-k készítése és karbantartása egyáltalán nem a fejlesztők feladata.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Fejlesztőként hogy a viharba készítenék production-ready image-eket? Eddigi 7 éves szakmai tapasztalatom az, hogy ha egyáltalán gondolni merek a production környezetre, minden oldalról savat öntenek a kivájt szemüregembe. De már az is extrának számít ha DEV/INT környezetre van jogom telepíteni...

Szerintem az rendben van, hogy fejlesztőként nincs jogod a production környezetbe telepíteni (bár az igazán hardcore devops-felfogást terjesztő emberek még ezzel is vitába szállnak).
De ami artifact-ot előállítasz annak végül valahogy alkalmasnak kell lennie production környezetbe telepítésre, nem?!

Vagy akkor kinek a feladata, hogy "fejlesztők" által elkészített akármilyen artifact-ot továbbmasszírozza egy telepíthető csomaggá?

Az én eddigi tapasztalataim alapján ugyanúgy fejlesztőnek nevezzük őt is, legfeljebb más részterülethez ért. Ugyanúgy kódot ír, ugyanúgy commitolja source repoba, ugyanúgy CI-ban buildel, csak éppen nem java-ban dolgozik, hanem ansible-ben, bash-ben, rpm spec fileban vagy - hogy témánál legyünk - dockerfile szintaxisban.
---
Régóta vágyok én, az androidok mezonkincsére már!

A hagyomanyos fejleszto/operator felallasban a fejleszto az alkalmazast fejleszti, es leirja az alkalmazas fuggosegeit. Az operator pedig teremt egy kornyezetet amin fut az alkalmazas. A modernebb felfogasban van 1 vagy ket ember a csapatban, aki ismeri es fejleszti az alkalmazast a programozokkal es tervezi a kornyezetet az SRE-kkel meg az operatorokkal. Jo esetben osszekalapal egy olyan rendszert, ami eljuttatja az alkalmazast az eles kornyezetbe ugy, hogy az az osszes resztvevo felnek megfeleljen. Divatos az a felallas is, hogy az operatori munkat kiszervezik kulsos felnek (EBT, Heroku, random Kubernetes engine), es akkor csak az SRE-vel mukodik kozre a DOE.

-
Advanced testing of Golang applications

De eddig is rakhattad külön VM-be, sőt LXC konténerbe is, ami nem egy eldobható valami, amit egy shell scripttel raksz össze, szóval az adott esetben a Docker csak a szokásos üljünk fel az aktuális hype vonatra. Ha már ilyen legacy dolog, akkor nem sok értelme van a Dockerfileos szerencsétlenkedésnek.
Sőt, Ubuntuék LXDje is megfelelőbb erre a célra.

Miért kéne ugyanabban a konténerben mennie a mysql-nek és a php-nak?

Ha úgyis automatizáltan buildelődik neked az új image, miért fáj neked, hogy ne nyúkájj' a futó image-be?

Debugolni, meg a probléma megértésére, attól még lehet! De ha megértetted, hogy mi a gebasz -> git add changed files && git commit && git push && várszameddig_a_build_befejeződik && megnézedafrissbuildet

Te tényleg beleragadtál a legacy dologba, mintha a Docker csak arról szólna. És igen, ilyenkor csinálunk 5 konténert, ami legacy, cserébe gyorsan és könnyen kezelhető, újraindítható.

(Kapaszkodj meg: LXC-t is használok)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Mivel a konténer nem tartalmaz érzékeny adatot, így elég könnyű és gyors a használata. Plusz vannak eszközök a konténerek együttes kezelésére (pl. docker compose), így az se jelent nehézséget.
Egyéb?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Mi van, ha azt mondom, hogy vannak a világon nem-technológiai szempontok is, és érdemes figyelembe venni őket, akár még üzemeltetőként is? :-)

Köszi mindenkinek a válaszokat, hasznos volt!

Pl. azért jó a Docker, mert könnyen és gyorsan reprodukálhatóvá teszi a környezetet. Ha gond van, akár pár másodperc kieséssel újraindítható egy konténer és ezzel alaphelyzetbe is állt (vagyis ami módosítás volt benne, az elveszett).
Én pl. szeretem, mert egységes környezetet ad a fejlesztéshez, teszteléshez és az éles oldal futtatásához. Gyakorlatilag minden fejlesztő az éles oldalon is használt környezettel dolgozik.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

en azt nem ertem,, mivel jobb mint az LXC/LXD? ugyanugy lightweight, ugyanugy vannak imagek, amit ratolsz az eles szerverre es mar hasznalhatod is, fuggetlenul attol a host gep milyen sw/os.

ami elonyet lattam a dockernek, hogy ott ossze tudsz kombinalni tobbfele imaget egybe, cserebe viszont nincs perzisztens sorage, ha leallitod eltunik az egesz, adatokkal egyutt, ami nem fasza (vagy en nem ertem a lenyeget).

A'rpi

Lehet, hogy nem ugyanarra gondolok, de mondjuk ha kell valami a programodnak, és azzal indul a Dockerfile, hogy apt-get install xxxx, akkor az mitől lesz reprodukálható? Vagy valahogy máshogy oldod meg, hogy bekerüljön az aktuális - 1 PHP verzió, csak akkor mi akadályoz abban, hogy ugyanezt a procedúrát eljátszd Dockerfile nélkül.
Számomra a Docker még mindig csak egy homokozó, amit egy shell script rak össze, ha az úgy van megírva, akkor idempontens lesz a futási eredménye, ha nem úgy, akkor meg nem.

Ennyi erővel akkor az LXD, vagy akár az ansible sem reprudukálható.
Itt a reprodukálhatóság nem azt jelenti, amire te gondolsz. Hanem azt, hogy egy „recept” alapján (lásd lejjebb gyu-t) készül egy image, amit bárki letölthet és elindíthat, biztosan ugyanaz lesz benne.
Te úgy beszélsz itt, mintha minden egyes alkalommal image-t kellene buildelni, holott nem.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ja értem, hát akkor megint sokkal jobban járok a Docker nélkül, mert pl. az Ansible ezerszer jobb, mintha egy shell szkriptre bíznám az image összeállítását.
De a reprodukálhatóságot akkor máshogy kéne hívni, mert nem arról van szó, hogy ott a recept, ami alapján bárki ugyanazt ki tudja főzni, hanem hogy volt valaha egy recept, ami alapján xy ezt alkotta.

Gondolom ha több helyen használnád, akkor az ansible-t sem kell minden alkalommal lefuttatnod, hanem csak letöltöd az eredményül kapott kész image-t. Oh wait…

(Amúgy az ansible jó cucc, de nem ugyanaz a kettő. Itt most megint a Docker egy résztulajdonságán akadtál meg, mintha csak az image buildeléséről és terjesztéséről szólna.)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…


Gondolom ha több helyen használnád, akkor az ansible-t sem kell minden alkalommal lefuttatnod, hanem csak letöltöd az eredményül kapott kész image-t.

Megoldható ez is(csináltunk már ilyet). Csak nem túl fontos, azért az elég szép látvány, amikor felhúzod mondjuk 40 gépre az OS-t (nyilván nem egyesével, CD-ről), lefuttatod az Ansible-t, és egy óra múlva minden működik. Ha meg valamit módosítani akarsz, akkor nem kell törölnöd az egész hóbelevancot, hanem újra lefuttatod. Ez az eldobható dolog azt sejteti velem, hogy "annyira szar, hogy jobb, ha nem nyúlsz hozzá, mert bármit csinálsz, összedől". Fejlesztésnél lehet előnye, hogy mindig tiszta környezetről indíts, ezt elhiszem.

Az eldobható és reprodukálható arról is szól, hogy semmi érzékeny adat nincs a konténerben, ezért (is) gyorsan indul, gyorsan leáll. Ez pl. remek dolog a Docker Swarmnál, amikor azt mondom, hogy megnőtt a terhelés és ezért adott konténerből kérek még tízet három szerverre elosztva.
De ez már egy másik történet.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

HA az image ugy van felepitve ES megfeleloen utemezheto.....
mert pl mire egy VM-et deployolsz, majd rainditod az ansiblet majd beleturod a loadbalancerbe, addigra lehet mar lement a peak ami miatt kellene a plusz performance.
illetve csokoltatom a fejlesztoinket, perpill siman IPket hardkodolnak a containerbe....

Nézz meg egy-két docker-entrypoint.sh-t!

Pont ez a lényeg: átvesz pár envvart, esetleg be-bindmountol 1-1 configkönyvtárat még ro-ban, a perzisztenciára szolgáló könyvtár mellé, és ennyi. Ezt kell jól összerakni. Egyszer. Mint ahogy a Dockerfile-t is egyszer rakod össze.
Utána meg ha kell frissen tartani, csak megtriggeled a CI/CD rendszereden a buildet.
Az meg triggerelődhet, mert már valami alattad lévő image frissült.
Valami git repóból jön tartalom, és azon követtek el push-t.
Vagy csak mert valaki kézzel megnyomta a build gombot.

Hacsak nem változik maga a szolgáltatás is gyökeresen akkor a Dockerfile és entrypoint egyszeri munka, amit el kell végezz.

Ez egy indítószkript, ami képes arra, hogy környezeti változók alapján befolyásolja a MySQL indulását. Ilyen hol van az Ansible-ben? Értelmezed is azt, amit írnak neked?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

nem teljesen.

LXC-hez, egyrészt nem tudod megnézni a "Dockerfile"-t, ami összeállítja. Kicsit nehezebb auditálni, hogy mi a retek is van egy konténerben.
Ha ott valami odaír valahova, akkor az oda lesz írva.
Docker esetén, ahogy már írták stateless.
+ van egy imagerepod.
lxc-re nem nagyon láttam még ilyen megoldást. Csak hasonlót, de ott meg nem lxc& nem namespaces: https://wiki.smartos.org/display/DOC/LX+Branded+Zones viszont ez meg megint nem stateless.

Szóval a docker az egy image+repokezelés.
A BSD meg Gentoo meg hasonlók csomagkezelésében annyira nem vagyok járatos, de kb. ahhoz hasonlítsd:
git/svn-ből elő tudod húzni a "forrásfát". Abban kiadhatsz egy make-t, ami letölti az aktuális forráskódot, buildel, stb.
De vannak dolgok, amikből van "bináris terjesztés" is, hogy ne kelljen a fordítással bíbelődnöd és az első használat előtt az X, meg DE build miatt 5 napig csak buildelnie a gépnek.
Na a dockernél is a registry-ből használod az image-t.
Vagy ha komolyabb audit kell, akkor használsz "auditáltabb" registry-t, pl. registry.access.redhat.com.
Majd a többi dolgodat, ami kell szépen megírod dockerfile-ba, és a végeredményt beteszed a saját registrydbe.

A lényeg: az image-ben, a kifejezetten perzisztálásra megjelölt területen kívül minden más olyan, mintha a /tmp-be tetted volna, és a következő indításkor már semmi nyoma.

Szép dolog, hogy az ansible-el is le tudod írni a receptet.
DE
bizonyos esetekben nem hatékony mindig 0-ról buildelni. Ha pl. nagy a load, és a 10 php backend helyett neked skáláznod kéne 15-re, akkor nem jó ötlet az ansible-ben benyomni további 5 hostot, meg újra megbökni a buildet, és reménykedni benne, hogy közben a script jól van megírva, és a másik 10 nem fog addig megmukorodni, ameddig a +5-öt is beállítja az elvárt állapotra.
+ közben még más dolgokat is utána kell állíts, pl. a loadbalancerben/nginx-ben/akárhol a backendek listáját.
helyette csak elböksz még 5 példányt az image-ből, ahogy már írták, szétszórva a node-jaidra, és hadd szóljon.
Ha jól van megcsinálva az automatizmus, akkor közben még a lb hangolás is megtörténik.

Pl. egy openshit-nél már avval se kell nagyon foglalkozz, mert az meg még egy réteg a docker köré, és az meg manageli az egészet, kézzel neked dockerhez max debugoláskor kell nyúlni.

Az LXC teljesen másra való mint a Docker.

LXC: izolált userspace, ami egy "teljes Linux", olcsó VPS szolgáltatók szeretik tolni. Futhat benne több processz, root lehetsz rajta, a szomszédtól meg teljesen el vagy vágva
Docker: izolált userspace, amiben csak egy processz futhat, tehát alkalmazást deployolhatsz vele különböző szempontok szerint "jól", de "teljes Linux" -ot nem.

Az LXC inkább az OpenVZ modern változata.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Ok, lehet hogy nem teljesen korrekt amit írtam, de a Docker by design erre ösztönöz. Persze vannak rá megoldások.

https://stackoverflow.com/questions/19948149/can-i-run-multiple-program…
https://docs.docker.com/config/containers/multi-service_container/

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

"amiben csak egy processz futhat"

Ciki lenne egy PostgreSQL-t futtatni dockerben, akár csak deves játszótér szintjén, ha ez így lenne. Amire te gondolsz, az a service, nem a process.

(Prodban nyilávn nem érdemes PG-t odarakni, de ez most más kérdés.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nalunk meg igy nez ki egy MySQL cluster Kubernetes alatt.


apiVersion: mysql.presslabs.net/v1alpha1
kind: MysqlCluster
metadata:
name: my-cluster
spec:
replicas: 3
secretName: my-cluster-secret
# backupSchedule: @hourly
# backupUri: s3://bucket_name/
# backupSecretName:

https://github.com/presslabs/mysql-operator

Ez meg azt csinalja amit egy DBA ~csinalna mellette https://github.com/github/orchestrator

Azt a részét ugye érted a működésnek, hogy a Dockerfile a recept az image előállítására. Onnantól kezdve, hogy van egy imaged verziószámmal, mindennel -> reprodukálható
Másik oldalról, mivel a Dockerfile-ba a recept írod le, ezért könnyű magát az image-t is frissíteni, ha jön ki újabb csomag, függőség, etwas.

Másra való a kettő. A docker-nél pont az a lényeg, hogy az image-ben nincs adatod. Build, deploy ciklusok könnyen tudnak menni.
Amit meg perzisztálni kell, azt nem az image-be teszed.
Cserébe gyorsan tudsz frissíteni: lehúzod az új image-t, beletöltöd az adatot, ha nem megy, akkor maradsz a régi image-nél, és majd kitalálod mi a gond az újjal. Ha meg jó, akkor profit.

"en azt nem ertem,, mivel jobb mint az LXC/LXD?"

Lejjebb is írtam, de itt is leírom: az LXC-vel lightweight csinálhatsz komplett Linux környezeteket, ami kevesebbet eszik mint egy hypervisor, így ha VPS szolgáltató vagy, több usert ki tudsz szolgálni ugyanannyi fizikai vas (tehát $$$) segítségével, az userek mégis "VM"-eket kapnak, amikben annyi processzt futtatnak amennyit akarnak
A Dockerben meg egy darab processzt tudsz csak elindítani, tehát 1 app 1 konténer. Nem tudsz vele olcsó VPS -t kreálni, alkalmazást csomagolni viszont igen.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

a valaszodbol csak az derul ki, mivel rosszabb a docker az lxc-nel. en meg mindig azt keresem, hogy mi az amit lxc-vel nem tudsz megoldani, dockerrel igen? mert lxc-ben is futtathasz csak 1 appot, ha akarsz.

masreszt nekem meg mindig nem vilagos, hogy a non-prezisztens docker hol tarolja akkor a konfig beallitasokat, adatokat stb? avagy ez nem is jo masra mint statikus weboldalt hostolni, logok meg mennek remote vagy devnullba? en egyszer letoltottem egy LTSM nn modelt dockerben, 3 napig szamolt, aztan kileptem es eltunt az egesz, az eredmenyekkel egyutt. engem ez nem gyozott meg tulzottam a docker hasznossagarol :(

Erre valo a docker-ben a logdrivers, volume es tarsai amivel perzisztenciat tudsz adni a kontenernek.

Sajnos itt ki is jon, hogy ami a legnagyobb elonye az a legnagyobb hatranya is, megpedig az immutabilitas.
10-bol 9x nem az a baj, hogy az valami elcseszett fuggosege van az app-nak es azert nem indul, hanem azert mert szar a config alatta, vagy mert osszebaszta a sajat adatait.

Nos amit a docker nem old meg, az az app configjanak a kezelese. Mert aki az app configjat beleegeti a kontenerbe az....

Ez a cucc alapvetoen Cloudra van kitalalva, de talan mar on-prem sem rakunk semmit fs-re, mert nem redundans es nehezkes hozzanyulni.
Sokkal inkabb (No)SQL vagy elosztott FS (HDFS, S3). Tudnak redundanciat, geo awareness-t, ACL-t, titkositast, backup-ot meg minden szart ami kell.

LXC-t nem ismerem, de biztos meg lehet vele mindent csinalni amit Dockerrel mert ugyanaz a technologia. Csak a Docker elterjedtebb, tobb image van hozza, nagyobb a hype, stb.

Amugy ha otthon kapalod az egy szem pinceben levo vasadat a PHP weboldaladdal meg a fasza RAID1-eddel, akkor neked nem kell sem Docker, sem LXC. :)

Itt egy docker-compose config (docker konténerek gyüjteménye), amivel tudsz weboldalakat üzemeltetni: https://github.com/nevergone/docker_php_sources/blob/master/examples/do…

Alapból a 127.0.0.1:8080-ra ül rá a webszerver, de ez felülbírálható.

Ui.: fogok ma kicsit beszélni róla itt: https://www.meetup.com/NyirTech/events/250446419/

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Abban kulonbozik, hogy a Docker az nem csak egy kontener futtato kornyezet, hanem alkalmazas csomagolasi technika is. Meg a hozzaadott toolokkal (swarm, docker-compose) egy orhestration engine is. Tehat ha Lxc-t hasznalsz az ugy nez ki, hogy elinditasz egy kontenert, abban valamivel telepited az alkalmazasod (a Canonical torekszik valami image formatumot szabvanyositani nem tudom hol tart), ami fut. Es kb pont. Ezzel szemben dockerrel, fogom az alkalmazasom, amit a fuggosegeivel elore becsomagolok (immutable), majd ezt a csomagot tetszolegesen futtathatom, akar tobb gepen is, lehet a futtatast egy clusterben elosztottan utemezni, tudok hozza halozatot csinalni, meg replikaciot beallitani, meg readyness/liveness probokat irni, ki tudom ajanlani a nagyvilagnak, tudom oket monitorozni, ossze tudom gyujteni a logokat stb. Es meg egy rakas mint tudok csinalni, amit az lxc-vel nem. Es amit lesutottem imaget, az szabvanyos image, es tudom futtatni mas kontener enginekkel, pl rockettal, vagy kubernetesen cri-o-val.

-
Advanced testing of Golang applications

"felhos buzisagok" hat ha megnezem, hogy mitol hasit a kontenerizacio meg hova megy az innovacio nem az lxc jut eszembe hanem ezek a felhos buzisagok.

"meg a windows nem lesz jobb" nem lesz jobb, de ha mindenki a windows moge all be, es ott tortenik a jovo, akkor te is jobban teszed ha windowsozol, persze oda-vissz santit a pelda.

Az latszik, hogy a Kubernetes nyerte az orhectration haborut, es a containerd nyerte a runtime haborut (talan meg cri-o nak van jovoje, de csak productionbe leven nincs human interface), es mindenki open container initiative kompatibilis imaget tol. Aki nem koveti az ipari szabvanyokat az vagy keres maganak sajat teruletet/uzletet/valami kihagyhatatlan egyedi dolgot vagy lehuzhatja a rolot. Csak erdemes osszehasonlitani innovacio/nap a tortenetet. Kuberneteshez minden nap jonnek az uj sdk-k, meg operatorok, security dolgok, volume pluginek, cloud driverek, stb. A CNCF minden nappal hizik egyre tobb komponens van, monitorozas, trafic routing, ... amik megkaptak a kozosseg tamogatasat, amibe toljak a cegek a lovet.

-
Advanced testing of Golang applications

lxc + ansible-el is meg lehet. Csak rohadt nehéz, hogy pl. ugyanaz a verzió legyen mindenből benne!

Tfh. a debian repóba pont behoznak egy 1.0.0.1-es verziójú csomag után egy 1.0.0.2-es csomagot, ami épp csak egy "picikét" javít.
De korábban nem volt sem dokumentálva sem definiálva az elvárt működés.
Neked az 1.0.0.1-re csont nélkül lefuottak a tesztjeid. Menet közben esélyed sem volt belegondolni, hogy az X y komponensének z alkomponensének w alkomponensének v alkomponensében ez történik, amikor épp csak X-et példányosítottad...
De az pont elég ahhoz, hogy eltörjön valamit a saját kódodban.

Ha meg ansible csak annyit mond, hogy apt install blah,... eszedbe jutna, minden egyes csomagot verziószám szerint beledrótozni, hogy apt install blah=1.0.0.1 + ezt az összes függőségből feltett csomagra is?

Hogyan vetsz össze két verziót, hogy mi változott köztük?

Hogyan találod meg, hogy mi tört el?

Amit leírtál abban együttérzek veled, de kicsit előreszaladtál. A doksi is írja, hogy a dockerben a konténer fs -be nem teszünk runtime adatot, hanem kitesszük volume mountra (pl. gitlab working directory). Elég egy docker rm -f konténerneve parancs, és kérdés nélkül zúzza is be az egész konténert (kivéve a volume -ba tett adatokat, ha okos volt az user).

Az LXC-t meg a Dockert nem kell sorrendbe állítani, mert másra használjuk.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Én a helyedben nem a Dockerrel kezdeném a dolog megértését, hanem az egész container technológiával (A docker ennek csak az egyik implementációja).
Ha nagyon röviden kéne összegezni, akkor gondolhatsz a Containerekre úgy mint egy cgroup + Linux namespaces + UnionFS kombóra.
Az UnionFS adta pozitívumokra most nem rétek ki (az kb letudható a layerek szintjén kezelhető cache-elésben), a másik kettő viszont fontos tud lenni: Szeparáció a rendszer többi részétől, illetve erőforrás management. Hasonló technológiák ugyan már jó ideje léteznek (azok is kb a Linux kernel ezen képességeire építenek), viszont nagyon nem volt olyan tool ami egyetemesen ezt képes lett volna biztosítani bármilyen processre. És igen, itt most process-t írok direkt, mert a container szinten futtatott szolgáltatás (lehetőség szerint micro service)-re kb így is kell tekinteni: Egy process amit gyorsan el tudsz indítani (miután a megfelelő container image-et letöltötted) különösebb overhead nélkül, majd megállítani miután az befejeződött.
Erről az oldalról simán tekinthetsz rá úgy mint egy initd-s daemonra ami csak akkor fut ha tényleg van is rá igény (micro-service architektúrában).
És innen indul a containerek, illetve a köréjük épített management eszközök előnyei: Lehetővé teszik egy adott "process" deploymentjét és indítását meglehetősen gyorsan, többé kevésbé biztonságosan (egy container ugyan annyira biztonságos, mint egy kiadott program: Ha nem frissítik, akkor ugyan úgy lyukas lesz, mint egy ementáli).
Ha ez fölé még beleszámolod, hogy a micro-service architektúra kb mire is épít (rövid ideig élő containerek, amik szabványos interface-eken (általában valami REST API) kommunikálnak egymással, on-demand elindítva/leállítva), és hogy milyen további orchestration eszközök érhetőek el hozzá (Docker-swarm, Mesosphere, illetve manapság már inkább Kubernetes, vagy ha valaki nagyon Amazon EC2-re akar támaszkodni akkor esetleg Titus) akkor egy iszonyat jól skálázható rendszert kapsz, ahol alapból adott a High Availabilty, és az auto scale-in/out (feltéve, hogy van elégséges HW amire ki tudsz skálázni)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Azért annyira sok nekem most nem jut eszembe:
- runc (amire a Docker, és a containerd is épít)
- LXC / LXD
- openVZ
- rkt
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Amellett, hogy a docker csak egy implementáció... Egy teljesen más megközelítése a konténerizációnak.
Az image-k, meg az, hogy amit perzisztálni akarsz, azt külön területről mountolod bele, stb. megközelítés egy teljesen új megközelítése azoknak a dolgoknak, amik korábban már zóna/jail/namespace-jelleggel megjelentek.

Mondjuk ezt a "nem frissítik, akkor lyukas lesz" dolgot nagyon nem szeretem, hiszen egy szoftver nem lesz lyukasabb vagy kevésbé lyukasabb az idővel, hanem az a kérdés, hogy a már meglévő lyukakból mennyit ismerünk és foltoztunk be.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

flame on
a címet elolvasva, teljesen jó áruszállító :)
flame off

a teljesség kedvéért legyen itt még egy szempont/alkalmazás:
az Azure IoT Edge szolgáltatás is Docker-re épül és talán már beta állapotban van. A lényege az, hogy sok világszerte elszórt IoT (vagy inkább IIoT) cpu-n tudjál különbözö Azure konténereket (stream analytics, Machine learning,....) telepíteni. Föleg anélkül, hogy fizikailag a gép közelében kellene lenned.

Mivel az Azure-nél (és AWS-nél, IBM-nél) is rájöttek, hogy mégsem megoldható az összes adat felhöbe küldése illetve nagyon költségigényes tud lenni, ezért a peremmegoldások kezdenek vissza térni: ott analizálják az adatokat ahol keletkeznek és csak az eredményt küldik fel a felhöbe.

Dockert akkor használok, amikor (viszonylag ritkán) ábrázolnom kell egy-egy jó bonyolult gráfot. Ehhez van egy R-es eszközkészlet (igraph, plot), ám pusztán emiatt a funkcionalitás miatt nem akartam szanaszét gányolni a saját gépemet, felrámolni mindenféle gigantikus programkönyvtárakat... Így aztán, ha nagy néha kell ez a pár program, fellövöm a dockert, telepítem, ami kell, előállítom a gráf képét, aztán törlöm az egészet (és az egészről írok egy readme-t magamnak, hogy pár hónappal később is gyorsan meg tudjam csinálni). Részletek itt: https://hup.hu/node/157957

lxc:
vagy hasznalsz valami kesz image-t, es utana meg kezzel reszelgeted...
Kicsit nehezebb "dokumentalni" mi van az image-ben. Esetleg orizgeted mint a himes tojast.
Jobb esetben ansible-el vagy valamivel automatizalod az image eloallitasat.
De ha "frissiteni" kell, akkor igy is, ugy is szopo van.

Vagy sajtreszelozol kezzel, vagy...

Szoval, megforditom a kerdest:
- ha az lxc-nel skalazni kell, es ugyanazt a workload-ot szet kellene tobni tovabbi node-okra is, akkor mit csinalsz?
- ha updatelni kell, akkor mit csinalsz?
- mi a "dokumentacioja" az image-d eloallitasanak?

Lxc-nel kb. a fenti szopokorok vannak...

Docker-nel:
Ahogy mar irtak, az "adat" (config & maga az adat, pl. az adatbazis, webkontent, stb.) es az image szet van valasztva.

- ha skalazni kell, ugyanazokat a dataseteket is felmountolod a tobbi node-odra, es a tobbin is kiadsz egy docker run -v mount -v masikmount image/neve:label
- ha updatelni kell, akkor docker build-el a Dockerfile alapjan ujrabuildeled az image-t. Ha valami dockerhub-os image, akkor meg csak ujrainditod es profit.
- Dokumentaciora ott van a Dockerfile. Relative egyszeru szuk lista. Jobbara raepited az imaged - egy masik image-re, vagy valami hivatalos os-base image-re. Meg az image-ben tortenesre ott az entrypoint script. Egy lxc-nel egy komplett init rendszer (systemd-hell?) indul.
Tiszta, atlathato, hogy mi tortenik a konteneredben.

Nincs az, hogy elfelejtettunk ledokumentalni egy lepest, hogy az apt lofutty parancs utan, meg a kezzel meg kell hergelni a foo file-t a baz parancsal, de akkor, amikor epp telihold van es a konzolt Mekka fele kell kozben forditani.
Az osszes lepes az image buildelesehez le van dokumentalva a Dockerfile-ba.

Ha frissul a base-os: nem kell hosszas apt-get update && apt-get upgrade -t vegigvarni, megnezni jo lesz-e, vagy mit kuffant el. Meg, akkor ezt hogy nezed meg? Van egy teszt rendszered is?
Btw.: Honnan tudod, hogy a teszt teljesen szinkronban van a prod rendszerrel es ugyanaz fog benne tortenni?
Docker eseten Ujrabuildeled az image-t, ami meg ra-layerezi magat a friss hivatalos debian base-re. (felteve, hogy valami debian base os-re epulo valamit csinalsz.)

Inditasz belole plusz egy kontenert, akar ugyanazokkal az adatokkal is, mint a tobbinel. (esete/ szoftvere valogatja ugye, hogy a kozos hozzaferes az adathoz dillema hogy van kezelve)
Megnezed, hogy minden rendben. (Akar automatizalni is lehet a tesztelest is!)
Ha minden rendben, akkor ujrarantad a prod kontenereket is a friss verzioju image-el.
LXC-nel kicsit macerasabb ezt megszervezni, es... Kb. a "joindulaton" mulnak dolgok. (pl. a prod es dev / integ rendszerek szinkronja, meg hogy senki nem fog egyikbe se auditalatlanul belenyulni, es dokumentalatlanul megjavitani dolgokat csak az egyikben tesztbol, amit aztan nem dokumental le, nem ir le sehova, csak orul, hogy megy, es elmegy estere kocsmazni!)


- ha az lxc-nel skalazni kell, es ugyanazt a workload-ot szet kellene tobni tovabbi node-okra is, akkor mit csinalsz?

lxc-create egy másik gépen.
LXD-meg már REST API-s, szóval a fantáziád szab határt, hogy hogyan.


- ha updatelni kell, akkor mit csinalsz?

Akár újra is építheted az imagedet, és indulhatsz 0-ról, de szerencsére ez itt nem szükséges (dnf upgrade is megteszi pl.)


- mi a "dokumentacioja" az image-d eloallitasanak?

Shell szkript ez is, mint a Dockerfile.


Ha frissul a base-os: nem kell hosszas apt-get update && apt-get upgrade -t vegigvarni, megnezni jo lesz-e, vagy mit kuffant el. Meg, akkor ezt hogy nezed meg? Van egy teszt rendszered is?

Ha újracsinálsz egy imaget, azon nem kell megnézni valahogy, hogy jó lesz-e?

Én is úgy érzem, hogy a Docker hátrányait, meg hogy mit nem lehet, vagy jó csinálni vele, azok vannak beállítva előnyöknek. Zseniális a marketingje. Talán annyi, hogy ott is tudod használni, ahol egy szolgáltató erre ad lehetőséget, Kubernetesen pl.

"lxc-create egy másik gépen." vagy hordozod valahogy az imaget, vagy a hajadra is kenheted a createt, mert nincs garancia, hogy ugyanaz az a rendszer fog letrejonni. Dockerrel egszer lesul az image, arra megfutnak a tesztek, es utanna azt hordozod korbe by design.

Semmi sem garantalja, hogy a shell script ugyanugy fut le minden egyes alkalommal, szoval abban nem lehet megbizni, ezert kell egy tagelt image, ami garantaltan az ami, es nem valami random kimenet.

Vagy pl hogy kered le lxc-ben az image historyt, hogy mi tortent vele? Dockerrel lehet historyt nezni meg diffet. Hogy csinalsz networkot, mondjuk multi datacenterben? Hogyan csatolsz kulombozo storageket, mondjuk s3, stb. hogyan schedulalod a kontenereket tobb gepen? Persze mindre van valami megoldas, azt kell eszrevenni, hogy a Docker alapbol vagy pluginekkel egyszeruen kinalja ezeket a lehetosegeket. LXC-vel meg lehet osszekalapalni.

-
Advanced testing of Golang applications


hordozod valahogy az imaget,

Ez a dockernél is a registry, ha nem kézzel másolgatod. Ha ugyanarról a webszerverről töltöm le minden gépre, az nem jó? (Vagy használok valami bináris artifactokat kezelő rendszert, ha nagyon profi akarok lenni).

Ha nem garantálható, hogy ugyanúgy fut le mindig, akkor a Dockerfile nevű receptet is a hajadra kenheted, mint az image dokumentációja.

Ja, hát a Docker köré is van egy infrastruktúra, de pl. az LXD köré meg egy ilyen:
https://github.com/openstack/nova-lxd
Itt aztán csinálhatsz hálózatot a konténerjeid köré, tárolhatsz imageket egy központi helyen, stb.

Szerintem félreérted. Dockerfile nem arra van, hogy mindig abból hozd létre az imaget a használat előtt. Az arra van, hogy az imaget legyártsd, majd a már elkészült imaget terjeszted. Viszont a dockerfile-ből vagy létrejön az image, vagy elhal félúton hibával az egész.

Kicsit olyan, mint egy C programnál a makefile: megmondja, hogy hogyan szerkeszd össze az imaget (exe, .so, akármi), aztán te már csak az imaget terjeszted.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én már értem, de ebből a szempontból ugyanaz az LXC meg a Docker. Ami most eszembe jutott, hogy mivel tud(hat) többet a Docker: az overlay fájrendszer miatt építhetsz egy imaget egy másikra. Aztán hogy ebből hogy nem lesz katyvasz 2-3 réteg után, az más kérdés. De talán +1 réteg még egészségesen belefér.

"az nem jó?" de jo, a lenyeg, hogy koppra ugyanaz az image keruljon mindenhova.

"a hajadra kenheted" Hat azert nem ugyanaz a szitu, mert a Docker file reprezentalja az imaget, es van az imagenek history-ja. A ketto elvalaszthatatlan egymastol, mert Docker filebol buildelem az imaget. Fixme, de LXC eseten inditasz egy kontenert, es azon futtatod a bash scriptet, vagy amit szeretnel, de azok nem elvalaszthatatlanok egymastol. Az ket kulon processz. Nem fogod latni az imagebol, hogy azon mi tortent.

Nem mondtam egy szoval sem, hogy lxc-vel nem megoldhato ezek a dolgok. Azt mondtam, hogy Dockerrel nincs semmi masra szukseged csak egy Dockerre. Ott lesz a repository, a network, a volumok, az orhestration reteg, minden. apt-get install docker, semmi mast nem kell csinalni.

"nova-lxd" nem melyedtem bele, tudnal irni egy par parancsot, amivel mondjuk csinalsz egy networkot, es inditasz ket kontenert ami osztozik a neten? Dockerrel igy kell csinalni 0rol:

# apt-get install docker && systemctl start docker
# docker network create test
# docker run --name egy --network test -it alpine sh
# docker run --network test --link egy -t alpine ping egy -c 1

-
Advanced testing of Golang applications


"nova-lxd" nem melyedtem bele, tudnal irni egy par parancsot, amivel mondjuk csinalsz egy networkot, es inditasz ket kontenert ami osztozik a neten? Dockerrel igy kell csinalni 0rol:

OpenStack tutorialt hagy ne írjak most, de akár össze is kattintgathatod a dashboardon. Bár nem olyan vészes, ha van már egy projekted, amiben dolgozhatsz:

openstack network create ....
openstack subnet create ...
openstack server create ...

Sőt, kombinálhatod 1 hálózaton a konténeres és a "kövér" VM-eket is.

"OpenStack tutorialt hagy ne írjak most" nem is vartam, csak biztosra akartam menni (azt hittem tudsz valami trukkot ;)), amikor azt irom: jah hogy kell hozza egy openstack. Es azt ki fogja uzemeltetni? Mi lesz a vendor lockinggal, ha koltozni kell?

-
Advanced testing of Golang applications

1. build
Docker image a megfelelo OS + compiler + fuggoseg + stb verzioval lehuz es fordit. Az eredmeny egy runtime docker image az osszes szukseges fuggoseggel + az elkeszult binaris.

2. deploy
VM-ek felhuz, rajuk a build soran keszult docker image-eket toltod es futtatod, mindez X darab instance-on. Smoke test es ha minden ok, akkor blue-green switch es kint van prodban.

OS, fuggosegek, compiler verziok minden beegetve Dockerfile-ba es kurvara mindegy, hogy milyen hoston fut vagy hogy az AWS hol-mit upgrade-elt.
Config as code, szoval minden verzio trackelve es semmit sem csinalunk kezzel.

Kb 2 millioszor gyorsabb es biztosabb, mint egyesevel telepiteni mindent.

Plusz a Docker mostmar kovet bizonyos iparagi stadardokat, igy meg lehet vele csinalni, hogy a fejleszto tesztelgeti a gepen a kontenert, amit aztan betol egy repo-ba, ahol buildelodik belole egy immutable image, amit aztan minden gond nelkul lehet mondjuk futtatni mas kontener enginen, rkt, cri-o, stb. Hogy ez miert jo, mert pl a Kubernetesnek nincs sajat image formatuma meg kontener runtimeja, hanem gyakorlatilag barmit ala lehet tolni. Hogy miert jo Kubernetesen futtatni barmit, mert "cloud native", hogy miert jo, hogy cloud native, mert cloud native :)

-
Advanced testing of Golang applications

Mindenhol jol jon a docker, ahol:
- szukseg van az alkalmazas es fuggosegek csomagolasara (immutable image)
- ahol szukseg van a processzek egymastol valo elszeparalasara (kontenerizacio)
- ahol az alkalmazas tobb komponensbol all (docker compose)
- ahol az alkalmazast dinamikusan kell tudni skalazni (swarm)
- ahol az alkalmazast nem csak egy helyen kell futtatni (local docker, prod kubernetes)

Az LXC egy system kontener, amibe komplett rendszereket telepitenek altalaban az emberek. Az lxc kontenerek nem jonnek mennek, hanem fut a kontener, valamivel bele van telepitve a rendszer, es az fut. A Docker egy alkalmazas kontener, altalaban nincs is benne mas csak az az egy alkalmazas, ami aztan hol fut hol nem fut, hol itt fut, hol ott fut, hol ezzel a verzioval, hol meg amazzal (canary release), hol lokalisan, hol a cloudban, hol a CI rendszerben.

De egy konkret pelda. A mi alkalmazasunk egy dobozos termek, ami kb 20 komponensbol all, es nem szeretnenk, ha a usernek sokat kene bajlodni a telepitessel beallitasokkal. Eppen ezert a user leszedi a single binaryt, futtat egy start parancsot, ami szepen leszedi az adott verziohoz szukseges komponenseket, megcsinalja az "infrat" es elinditja az alkalmazast adatbazisostul, service discoveristul, UI-ostol, mindenestol. Ugyanezt az alkalmazst futtatjuk as a service. Fogjuk ugynazokat az imageket (amire mondjuk a tesztek is megfutottak), osszelapatoljuk Helm-el, es futtatjuk Dockerrel (na jo containerd-vel Kubernetes schedulerrel) multinode HA kornyezetben. Mindenzt villam gyorsan, hiszen nem kell telepitgetni, konfiguralni, stb. Start -> image leszed (layer fs-nek hala egy jo resze mar meg is van) -> alkalmazas elindul, mindegy melyik fizikai vason.

-
Advanced testing of Golang applications

Nem olvastam végig minden hozzászólást, de ha még nem írta senki akkor leírom én: az alkalmazás és annak környezete egy mozgatható, portábilis, "atomikus" egység, ami decouple -d az oprendszertől. Plusz, a Dockerfile+build miatt egy ember és gép által is olvasható, megismételhető, ellenőrizhető folyamat révén keletkezik a környezet, tehát tudjuk, hogy milyen php, java, python, milyen konfig és hogyan áll össze ahhoz, hogy az adott app működjön. Amúgy most volt dolgom egy ~70 oldalas "miért jó a docker" thesis -hez, és igaziból rohadt sok okosság le volt benne írva, mégis úgy érzem hogy erről ennél még mindig többet lehetne beszélni.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Meglevő rendszert és folyamatokat persze hogy nehéz átstrukturálni. Bankban láttam Dockerizálást. Dev környezeten dolgoztak vagy egy évig, mire lett belőle valami. Persze ott az egyes deploymentek elég bonyolultak voltak (weblogic + konfigja + belerakott deployment + mellérakott oracle szintén dockerben + az egész összeboronálva, stb).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

"...hogy miért jobb konténerezni, mint VM-et futtatni."

A ket dolognak minimalis koze van egymashoz, igazabol fuggetlenek.

VM-ekkel fuggetlenited magad a vastol, vagyis egyreszt barhova tudsz telepiteni teljesen homogen clustert, masreszt kapsz egy nagy adag redundanciat. Mas szoval "eldobhato" gepeket hasznalsz.
Kontenerekkel fuggetlenited magad attol, ami az op. rendszerre telepitve van. Nem erdekel a kernel, libc, java, stb verzio, az en Docker image-emben 20 ev mulva is az fog futni amit beleegettem es amivel le volt tesztelve a kod.

Utobbit ki tudod hagyni ugy, hogy mindent beleegetsz a VM image-be, de sokkal lassabb es kevesbe flexibilis. Pl. kell egy kernel upgrade es dobhatod a kukaba mindenestul es kezdodhet ujra a build folyamat.

A Docker konténert is nyugodtan viheted hozhatod bármilyen Linuxon, Windowson, macOS -on. Csak magának a Docker runtime-nak a követelményei legyenek meg (asszem kernel 3.16 és felette).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Hogy hátrányt is mondjak, van egy kérdés, amire a Docker nem ad választ (mondjuk az LXC sem). Ha egy szerveren akarsz több független projektet futtatni és azok között kapcsolatot kezelni.
Mondok konkrét példát:
Van egy szervered, amelyen kisebb weboldalakat szolgálsz ki. A szerver 80-as portjára rá van ültetve egy reverse proxy, a bejövő forgalmat az osztja szét a cím alapján az egyes weboldalaknak. Weboldalanként külön szeretnél kezelni webszervert és PHP-t (mondjuk FPM-mel), viszont adatbázis-szerverből csak egyet akarsz fenntartani, amit minden weboldal használna.
Docker compose-sal leírhatsz kapcsolatokat az egyes konténerek között, megmondhatod, hogy melyik induljon el korábban), de egyelőre nincs olyan tool, ami a Docker compose-sal kezelt projektek között kezelne függőségeket vagy bármit.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Fent mutattam egyet, bár lehetséges, hogy nem olyan érthető.
Szóval a docker compose összefog konténereket egységes projectként, de jelenleg nem létezik olyan eszköz, amivel ilyen projektek közti kapcsolat leírható és kezelhető.
Vagyis én nem tudok róla.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

igazából tudsz a composeban definiálni extra networköket, és a containereket hozzá tudod csapni akár több ilyenhez is.
Az viszont igaz, hogy ezeket kénytelen vagy előtte kint megcsinálni, ha több compose projected van.

(viszont azt a valamit dependencia kezelésnek hívni, ami a konténerek között van, az egy kicsit erős :D -- tudom, nem te mondtad rá :) )

Hat ez nem hatrany szerintem, hanem works as design, ami nem illeszkedik az elkepzelesdre. Ha nem hasznalnal dockert, akkor sem lenne fuggosegkezeles a kulonallo projektjeid kozott. Miert varod el egy tooltol, ami X dolgot egysegnek kezel, hogy tobb X-et is egysegnek kezeljen??
Raadasul anti pattern "hivatalosan" a servicek egymasra varasa, mert egy elosztott rendszerben, menet kozben is elofordulhat, hogy valami tonkremegy es az alkalmazasnak tudnia kell ujra csinalni a kapcsolatot. Nem veletlen, hogy a depends_on sem csinal semmi mast, mint a run ordert definialja.
Jah es nem utolso sorban van ra workaround. Es ha nem akarsz uj imaget sutni, hogy menjen a workaroundod, akkor lehet volumekent csatolni a wait for scriptet, es az entrypointtal lehet operalni.

-
Advanced testing of Golang applications

hat sorry ha ugy jott le, hogy izombol vedem a dolgot. Dokumentalt bad practice, es nem docker specifikus ;)

"ha valakinek valami hiányzik belőle" tovabbra is tartom, hogy ez nem egy hianyzo feature, hanem a meghatarozott scopon kivul eso problema. Ha tovabb noveljuk a scopot (pl az emlitett hianycikkel), mindig lesz meg egy kovetkezo. Figyi! Nekem az hianyzik, hogy amikor kiadom a docker stack create parancsot a composomra, akkor ha nincs meg swarm cluster, akkor gyorsan csinal egyet. Es ha ez meglesz, akkor az fog hianyozni, hogy megvarja amig a cloudban elindul az instance, mert a swarm fugg az instancetol. De ha ez megvan, akkor majd az lenne a jo, hogy el is inditana az instancot tetszoleges cloudban. Sot nagyon jo lenne, ha nem csak elinditana az instacot, hanem tudnam konfiguralni is. Meg jobb lenne, ha nem mindig real time konfiguralna, hanem keszithetnek elore imageket, amibol majd elindul az egesz. ... Szerintedd ezek hianyzo featurek, vagy out of scope issuek?

-
Advanced testing of Golang applications

A Kubernetes meg a környezet komplexitását növeli. :)
Szerintem a Kubernetesnek akkor van értelme, ha több gép van és cluster stb., itt viszont egyetlen szerverről szól a történet.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Elosztott rendszereknél az alkalmazásnak kutya kötelessége, hogy kezelje az ilyen eseteket.
Nem várhatja el, hogy amit használni szeretne az mindig fut és rendelkezésre áll.

Az már nem feladata, hogy ha nem megy, akkor kiderítse miért nem megy, elindítsa, újraindítsa, ...

--
Ickenham template engine

Igen is meg nem is. Egyreszt lehet queue based szolgaltatasokat hasznalni tehat ha mondjuk nem erek el egy apit akkor a job visszakerul a queue-ba es a backoff leteltevel ujra probalkozik (https://www.reactivemanifesto.org/) es/vagy lehet service mesht hasznalni mint mondjuk a LinkerD (https://linkerd.io/)

Így van, bizonyos dolgokat egy külső szolgáltatás megcsinálhat az alkalmazás helyett, de arra szerintem mindenképp fel kell készülnie, hogy a hívott oldaltól (adott időn belül) nem kap választ.

Service mesh esetén meg pl. a Linkerd az amitől közvetlenül függ. A linkerd is leállhat; lassulhat, megszakadhat a hálózat, ...

--
Ickenham template engine

Vagy nem értem a problémát, vagy LXC-vel ezt le lehet kezelni. :)

# ls -l /etc/lxc/auto/
total 0
lrwxrwxrwx 1 root root 28 May 13 2015 01-vm-mysql -> /var/lib/lxc/vm-mysql/config
lrwxrwxrwx 1 root root 30 May 15 2015 02-vm-apache1 -> /var/lib/lxc/vm-apache1/config
lrwxrwxrwx 1 root root 30 May 18 2015 03-vm-apache2 -> /var/lib/lxc/vm-apache2/config

és a symlinkek sorrendje megadja az indulás sorrendjét.