Docker - más szemmel

A Docker menő téma, az ember úgy érzi nem maradhat ki/le, muszáj megtudnia mi ez, mire használható. Az ismerkedéssel messzire még nem jutottam, de ez a meglehetősen tényszerű írás elgondolkoztat, hogy kell-e egyáltalán.

( zeller | 2015. 11. 07., szo – 10:55 )

+1, ráadásul pölö. RHEL7-en khm. "megbízható" működést eddig csak btrfs-sel sikerült csiholni - miközben tudott dolog, hogy a btrfs gyakorlatilag egy jól irányzott paranccsal megfektethető...

By design el van kufva - olvasd el a posztindító által linkelt oldalt, és gondold végig üzemeltetői (ne fejlesztői) fejjel.
Az a dockeres gép, amit gyakorlatilag nem használtak, csak néhány tucatnyi konténer lett buildelve rajta, az megy mint a Dodxa. Még. Amin meg "picit nagyobb" volt a terhelés, az meg olyan szépen atomjaira hullott, hogy öröm volt nézni...
A retek felé ticketet nyitogatni... Nekem nem fáj, hogy sz@r a Docker RHEL-en, legfeljebb lesz Debian/Ubuntu/Gentoo/ajóégtudjamilyen disztró a retek mellett :-P

Nem akarom en vedeni a Dockert, de azert amiket leirt srac eleg sok tulzas van benne. RHEL-be szarul implementaltak az nem jelenti ,hogy minden hol rosszul mukodik. Ertem en ,hogy neked tetszik a technologia de azert ennyire nem kell lehuzni. Jelezem viszonylag nagyterheles alatt sincs gond vele.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

A docker pool, pontosabban a backendje az, ami egy idő után RHEL-en mindig feladja. Van egy halom backend opció:

- aufs --> ilyen nincs a RHEL-hez adott kernelben (meg azt hiszem a vanilla upstream-ben sem), így supportálva kiesik
- devicemapper --> ez a RHEL-ben a default docker pool backend, nameg ez a supportált, cserébe bugos: https://github.com/docker/docker/issues/3182 (sokáig működik rendesen, de leakel a cucc, így a default 100 GB-os pool előbb-utóbb elfogy)
- overlayfs --> ez a RHEL 7.1-ben technology preview állapotban van, így supportálva kiesik
- btrfs --> hát, ez is bugos: https://github.com/docker/docker/pull/15801

A helyes megoldás erre egyébként tényleg az, hogy addig kell a RedHat-et nyomasztani, míg ki nem javítják a devicemapper backend marhaságát. De ez a hozzáállás, hogy ticketet kell nyitni és (sokat) kell várni a megoldásra nem valami jó. Korunk magyar enterprise világában meg nincs megoldás, mert:

1) várni erre nincs idő
2) okos embereket, akik ki tudják javítani a dolgot vagy egynél többféle disztribúciót tudnak menedzselni, esetleg váltogatni is tudnak közöttük, na, ilyeneket nem veszünk fel, mert drágák.

Evvan.

Az uzemeltetok nem gondolkoznak.

A fejlesztok meg gondolom azt talaltak ki, h legyen vmi, amivel flexibilisen lehet fejleszteni.

Amugy ahogy irtak mar korabban masok, lehet. Csak a host OS legyen mas. En azert nem fikaznam a dockert, mert egy epphogy tamogatott fityvasz kornyezetben nem mukodik.

A RHEL7 nem az "épphpgy támogatott fityvasz környezet", még akkor is, ha vannak kellően negatív tapasztalatok ezzel a támogatással kapcsolatban. (És itt nem csak a "nyiss ticketet, aztán büfizünk rá valamit" kérdéskört tekintem támogatásnak, hanem úgy mindenestől az elérhető információk halmazát.)

Ja... Kell a csomagok főverziójában gyakorlatilag fagyasztott RHEL, mert támogatás van hozzá, és kell a Docker, hogy a fejlesztők mehessenek előre az igen gyorsan elavuló (főverzióban szinte biztosan nem változó), OS-komponensként telepített dolgoktól függetlenül :-P
Csak én érzek itt némi ellentmondást...?

FÁltalában a manágerek és a manáger-közeli emberkék félnek attól, hogy fizetős support nélküli, a többségtől eltérő OS-t rakjanak valami alá. Volt szerencsém naaaagy webfarmhoz, ahol Ubuntu volt a default, de volt Gentoo, és az Oracle okán RHEL is.
Szerintem egy RHEL AS4/RHEL5/RHEL6/RHEL7 kupac mellé odapattintani egy Debian-t nem fog rettenet többeltmunkát okozni - a négy RHEL-verzió különbségei sem sokkal kisebbek, mint a friss RHEL/friss Debian eltérés... Azt szoktam mondani, hogy a jó szakember tetszőleges szerszámos ládában megleli a megfelelő fogót meg kalapácsot.

a jó szakember tetszőleges szerszámos ládában megleli a megfelelő fogót meg kalapácsot.

+1. Aki az rhel-t ismeri, aligha eri nagy meglepetes a debian vonalon, es viszont. Ill. ha a debian/ubuntu nem ad supportot, biztosan vannak olyan it-cegek (legfeljebb nem ebben az orszagban), amelyek vallalnak supportot ezekre is. Mondjuk ezzel egyutt sem hulyeseg az egyen disztro (vagy 2 egyen disztro :-)), es akkor maris van a rendszerben egy kis rugalmassag...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

allitolag nem annyira gaz az rhel kernel. Egy jomunkasember debian ala tesz rhel kernelt. Bar ha az OS egyenre szabott, akkor (igeny szerint) akar a kernel is lehet az (azonos hw-ket feltetelezve), romma tuningolt, custom csomag...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

A jelen esetben tuti szar, mivel epp panaszkodnak ra:)
A tobbi szempont most nem jatszik.

De nyilvan, ha kiveszik az egyenletbol a dockert, akkor teljesen mas a leanyzo fekvese es lehet, hogy az jon ki, hogy az rhel (meg a kernele) k. jo.
Ezert nem ertem, miert eroltetnek a dockert. Van ezer mas lehetoseg, amivel a fejlesztoiket tamogathatjak. Plane miert eroltetik a fejlesztoi kornyezetben?

Persze en nem dolgozom banknal, teljesen mashogy gondolkozom. Nalunk az a cel, hogy mukodjon minden, nem az, hogy mukodjon es rhel legyen alatta:P

( XMI | 2015. 11. 07., szo – 11:00 )

Ez hiánypótló.
Bár azért hozzá tudnék még tenni 1-2 sötét dolgot, pedig még csak eléggé a felszínét kapargattam.
---
Régóta vágyok én, az androidok mezonkincsére már!

Most konkrétan az, hogy egy teljesen saját devicemapper-es storage alrendszere van, ami
1.) 1db monolitikus bináris fájlba pakolja bele a mindent
2.) Ezt a fájlt lefoglalja fixen 100GB-ra (ezt csak a docker daemon commandline paramértereivel lehet változtatni - konfigfájlból nem, ez mondjuk lehet, hogy a RHEL7-es package készítőjének bénasága miatt van így)
3.) Ugyan a file sparse, vagyis nem kezd 100GB-os tényleges helyfoglalással, de nincs hole punching vagyis ha egyszer lefoglalta a helyet, azt a docker image-ek törlése esetén sem tudja visszaadni
4.) És úgy általában nem szeret takarítani maga után a devicemapper fájlban (most lusta vagyok a vonatkozó bugokra linket előásni, nem egyet találtam), szóval intenzívebb használat esetén nem árt egészségügyi takarítás ami a komplett devicemapper fájl törlését jelenti. Akkor persze kell egy saját repo, ahova pusholni tudod az image-eidet, amiket meg akarsz tartani.

Szóval amíg csak kísérletezget vele az ember, addig nagyon király, minden valahogy "magically" működik, de ha kicsit komolyabban akarod használni akkor igen könnyen elillan a varázspor a dobozból, és szembekerülsz vele, hogy milyen szinten el van bonyolítva az egész, mennyire tele van non-standard, átláthatatlan megoldásokkal. Ehhez képest egy openvz azért nagyságrendekkel átláthatóbb volt. És azért nem mondanám, hogy annyival többet tud nála...
---
Régóta vágyok én, az androidok mezonkincsére már!

A dm használatát sajnos nem én találtam ki, hanem az egyik kollégám, Nekem már csak a debugolása jutott, akkor sokkolt le, hogy valójában hogy is működik.
Nem biztos egyébként, hogy nem lehetne normális megoldásokkal ugyanazt a funkcionalitást elérni.
---
Régóta vágyok én, az androidok mezonkincsére már!

( nevergone v | 2015. 11. 07., szo – 11:57 )

Szerintem ez eléggé vihar a biliben dolog. A Docker alapvetően jó dolog és sokmindenre lehet használni. De az mindenkinek a saját felelőssége, hogy mennyire értelmes az, amire használják.
Mi pl. csak arra használjuk, hogy egységes, operációs rendszertől függetlenm könnyen használható futtatókörnyezetet hozzunk létre a fejlesztőknek. Tudom, hogy van Vagrant is, de azt inkább hagyjuk.

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

( Soultrane | 2015. 11. 07., szo – 13:52 )

Szóval nem tudsz róla semmit de véleményed már van, mert valami csicskagyerek kitett egy szép írást.

De persze a szakmai úttörők a hülyék, és csak github csillagokra jó :D Veregesd magad hátba hogy nem állsz be a sok birka közé.

( o_O v | 2015. 11. 07., szo – 19:17 )

Nalam mar be se jon :). Sajnos nemtudtam elolvasni...

UI. most mar bejon :)
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( uid_4263 v | 2015. 11. 07., szo – 22:22 )

Bekonfolt, összelőtt környezet szállítása az ügyfélnek. Arra való. Értsd, nem egy war -t vagy jar -t szállítasz hanem egy dobozt amin meg kell nyomni a zöld gombot hogy működjön. Nekem ez a része a fontos / szimpatikus.

--
arch,debian,openelec,android