"Es ebben semmi kiforratlan nincs, de bugok mindenhol elofordulnak es semmi sem tokeletes."
Szerinted, szerintem meg van. És igen, az ubuntu is egy gány egy csomó helyen.
"2) Ez szinten nem kiforratlansagra utal. Ez egy okoszisztema es nem kell mindent a Dockernek megoldania, hiszen van ra megfelelo tooling. Ahogy a logrotate-et sem a syslognak kell megoldania, bar meg tudna ha akarna (nem neztem utana de tutira van olyan megoldas, hogy megcsinalja :))."
De, arra utal, mert a fene sem tudja, hogy most éppen ki a nyerő. Ez az egész ökoszisztéma még kiforratlan, te magad is mondtad, hogy a docker nagyon nyomul a kubernetes tortája irányába. Cserébe alulról rágja szét a systemd, a guglis arcok tolják az rkt-t, és igazából a franc se tudja, mi lesz ebből pár év múlva.
"Ezt hivjak separation of concerns-nek."
Légyszíves és ne oktass ki, hidd el, hogy nem vagyok nyeretlen kétéves.
"3) Van valami kulonosebb oka ennek? Miert nem hasznaltok private repokat DockerHubon vagy Quay.io-n? Erre gondoltam fentebb, hogy minek cseszekedjek ilyenekkel amikor masok szazszor jobban megoldjak helyettem, mikozben nincs jelentos impactja az alkalmazasaim szempontjabol."
Igen, van nálunk ez igény, és pötty. (Segítek, egy igény nem feltétlen műszaki, lehetnek neki jogi okai, vagy akár csak az, hogy mondjuk valaki nem szeretné a komplett szolgáltatásbiztonságát a quay.io-nak adni) Egyébként meg én is ezt mondtam: attól, hogy a problémát mások oldják meg helyett, attól még azok problémák, amiket meg kell oldani. És értem, hogy neked elképzelehetlen, hogy valaki saját infarstruktúrát akarjon üzemeltetni, de ettől ez még valós igény.
"4) lasd 3as pont. Amugy minek torolnek a registrymbol? Nekem teljesen jo ha ott van az osszes verzio amit valaha buildeltem :)"
Elnézést, de kénytelen leszek visszaszúrni, ha már te ezt megengedted magadnak :) Meg kéne ismerni kicsit alaposabban az általad használt toolokat, itt ugyanis szó nincs registryről, itt a dockerd local image cacheéről van szó. Ami olyan szinten bugzik itt, az egyik alapvető higéniás izéjénél, hogy nagyon.
"5) Ez semmiben nem uj problemater csak egy masfajta megoldas ugyanarra a problemara amikor updatelgetned kellett a disztrot amit hasznaltal. Az image forrasa ugyanugy pl debian mint amit a vmeden futtatnal. Tovabbra is ugy teszel, mintha az imagek scratchbol forgatott custom disztrok lennenek, pedig nem igy van."
Kivéve a gyevi bírót ugye. Egyrészt ahány image, annyi distró, másrészt meg ugye pont az dev irányból az egyik fontos pont, hogy ha a libfoobar az ubuntuban régi, akkor még mindig fel lehet tenni az én appomnak megfelelőt mondjuk pip installal, vagy brew-val, vagy valamivel. És akkor azt onnan máris követni kell. Vagy jófej a dev, és oda mást használ, hogy ne legyen gányolva, így lesz a szolgáltatás alatt hol ubuntu, hol alpine, hol gentoo hol az istense tudja mi, és ezt bizony le kell kezelni. Vagy úgy, hogy megtanulod követni, vagy úgy, hogy visszatérünk ground zerora, hogy "kedves dev, azzal főzől, ami az ubuntuban van", csak akkor meg dev szempontból az egyik fontos előnyét veszti el a játék.
"6) Pont ebben brutaljo a docker, hogy _pontosan_ ugyanazt az envet tudod reprodukalni ami az ugyfelnel van, mig egy mutable infranal ez erosen kerdeses. Fogod azt az imaget (nyilvan taggelitek az imageket) ami az ugyfelnel van es reprodukalhatod a hibat."
Igen, ez egy népszerű féltévképzet. :) Vagyis inkább azt mondanám, hogy nem szokás látni, hol vannak a mantra határai. Igen, egy image immutable. Viszont egy dockerfile már nagyon nem az, tipikusan legalább kettő dolog szokott benne nem az lenni. Az egyik a FROM foobar:latest, ahol ugye a latest akármit is jelent (és ironikus módon van is olyan ticket, hogy lehessen már a fromban változót használni, ahol a fogalmatlan magyarázza, hogy de reprodukálhatónak kell lenni, és ott nem lehet változó, mert akkor mutable, az ember meg próbálja elmagyarázni, hogy a pipelineban ő ugyan pontosan tudja, hogy melyik imageből kellene most dolgozni, mert minek a következő stepjében vagyunk, és épp ezt szeretnénk odaírni, csak ezt nem tudjuk, a latest meg ugye mondjuk egy build rendszerben kissé gyorsan mozgó célpont) a másik meg az apt-get install, ami fél év múlva szintén mást fog jelenteni.
És odáig rendben, hogy az imageből reprodukálod, de aztán azt patchelni is kéne. És tudom, hogy van, ahol ezt nyugodtan lehet a frissből, de ez nem mindig van így.
"Szerintem kevered a szezont a fazonnal, a Dockernek vagy barmilyen mas kontenerizacionak (pl rkt) nem az a lenyege, hogy mindent tokeletesen megcsinaljon, erre ott van a Kubernetes es a kismillio egyeb orchestration framework. Alapvetoen par dolgot kell csupan tudnia ami ahhoz kell, hogy fusson az image - ha nagyon leegyszerusitem. Amint fentebb leirtam ez egy okoszisztema, ahogyan a Linux is egy okoszisztema.
Az mas kerdes, hogy a Dockerinc - latvan hogy mekkora business az orchestration - mar jo par eve mozog abba az iranyba is, de az altaluk szallitott megoldasok nem exkluzivak, egyaltalan nem kotelezo hasznalni oket."
Igen, pontosan ez volna a lényeg, hogy lépj egy kicsit hátra, és onnan szemléld mi történik az egészben, ne pedig a példák részleteiben vessz el, azok csak példák. Ez egy új terület, ami még most jött ki abból, hogy az early adopterek után a következő hullám is jönne, (és nekik adott esetben vannak másféle igényeik). Mivel friss terület, viszonylag gyorsan változik, és az ehhez való adoptálódás infrastruktúrális oldalról tud problémás lenni, mindezt úgy, hogy pl a bejáratott puppethez képest nem biztos, hogy fog hozni érdemi előnyöket. Egy csomó dolgot te elütsz azzal, hogy ezt megcsinálják mások a felhőben, de ez nem mindenkinek hihető ugy, meg ilyen alapon eddig is meg lehetett venni mondjuk a vmwaret, ott olyan orchestration van, hogy beszarsz, meg az appok tudta nélkül oldja meg a redundanciát (bizonyos szintig úgy is, ahogy a konténeresdi sose fogja) csak elég drága. Cserébe az adminok köszönik, ismerik, elvannak vele. És pl nincs szükség akármeddig vertikális skálázódásra, mert nem olyan a szolgáltatás. Az enterspize tipikusan nem arról szól, hogy valami nem bírja a terhelést, vagy hirtelen 2 nagyságrendet változik a terhelés, mert tipikusan a komplexitás a baj, nem a teljesítmény.