"Pont ez a munkank, hogy el tudjuk donteni, hogy mi a jelenlegi legjobb megoldas, nincs silverbullet, de van jopar megoldas ami mar most eleg mature ahhoz, h nyugodtan rabizd magad."
Egyrészt igen, ez, és éppen azt próbálom magyarázni, hogy vedd már észre, hogy vannak olyan usecasek, ahol a konténeresdi nem jobb, mint valami régi. Nem én jöttem azzal, hogy miért nem konténer ;) A maturity eldöntése meg megint olyan, mint mondtam, hogy szerinted már jó, más szerint meg lehet, hogy még nem elég.
"3) Ok nalatok ez az igeny, ugyan sztem felesleges igeny (jogilag is), de akkor ez van, szivtok is vele amint irtad :) A teljesen sajat infra felett meg korabban leirtam, hogy nagyon kezd eljarni az ido mert nagyon draga es iszonyat felesleges energia es ido megy el a megfelelo uzemeltetesere aminek az ugyfelek megfelelo kiszolgalasaban semmi kezzelfoghato haszna nincs."
Erre megint maradjunk annyiban, hogy szerinted. :) Kissé visszautalva az elejére, "Mert ugyan jol hangzik, de konkretumok nelkul keveset er." :)
"4) Akkor hasznald a megfelelo szavakat es akkor majd megertem mit akarsz mondani. Orulok, h tisztaztuk hogy docker cache != docker registry. A cachet takaritom, a registrybol sohase akarok torolni, hogy barmikor barmelyik verziora rollbackelni tudjak vagy a fentebb leirtaknak megfeleloen bugot tudjak keresni."
Ne haragudj, de én a négyes pont kapcsán sosem ejtettem ki a számon a registry szót, azt te képzelted bele. Én ott indításnak csak egy kopipasztát adtam, amiben "docker images" parancsok voltak, feltételezvén, hogy tudod mit látsz magad előtt. Ráadásul középen úgy tűnt, érted is. A kérdéses példa meg egyébként nem éles renszerből jött, hanem konkrétan egy olyanból, ami buildeli az imageket, szóval a kubernetes ott nem tud gczni.
"5,6) Neked mint devopsnak pont az a feladatod, hogy ne engedj :latest-et hasznalni es enforcold a best practise-eket, jellemzoen toolinggal (pl https://github.com/projectatomic/dockerfile_lint)."
Jaja, azzal a toolinggal, aminek a vaskalapos írói nem akarják engedni, hogy ezt csináljam. Nyilván meg tudom oldani azt a rettenetes műszaki problémát, hogy azt írjak egy docker file FROM részébe, amit nem szégyenlek, csak zavar, hogy a tool szerzői nem értik, hogy azt oda minek, ezért nem megy közvetlenül. A linter meg ne haragudj, de megint nem értem, hogy jön ide. Szerintem nem érted, miről beszélek. Nem lehet ma egy dockerfileba olyat írni, hogy FROM foobar:${TAG} vagy hogy FROM foobar@{HASH}, mert azt a docker build nem helyettesíti be. Azért nem, mert fujj, változó, nem variable. Csak egy átlagos pipeline meg pont tudja, mondjuk amikor dependent imageket buildelsz, hogy most ezt konkrétan miből kéne, és horrible diktu automata testek is futnak, párhuzamosan, szóval ez pont amiatt kell. Nyilván, be lehet helyettesíteni helyette seddel, lehet használni a buildelésre compose-t vagy bármi mást, mert nem egy komoly probléma, csak mikor még jól meg is van ideologizálva, hogy miért nem lehet, az vicces.
"Biztos van olyan alkalmazas ahol kell a legujabb foobar-lib, de azert erre mondjal egy peldat,"
Ne viccelj már, ha te még sose láttál fejlesztőt, aki kaffog, hogy miért LTS, meg pláne RedHat, hát abban minden ősi, akkor valami más bolygón lakunk.
"mert a legtobb esetben van erre egyszeru megoldas es illetve a komponenseket nem klasszikus csomagokbol rakod fel, hanem mondjuk npm eseten ugye packages.json vagy composernel composer.json esatobbi. Amugy meg ha teszem az valami :latest-tel keszult is, az taggelt imagem ott van a registrymben es pont tok ugyanaz ami az ugyfelnel fut."
Úgy látom, megint nem érted. Ha már npm meg ésatöbbi (láthatólag a pipet meg a cpant, amit példának hoztam nem ismered, bocsánat, mert akkor rá jöttél volna, hogy erről beszélek), akkor ott már neked kell figyelni arra, hogy az onnan jövő izékkel mi van, mert azok egy átlagos disztróhoz képest jóval kevésbé fogják ilyen szempontból rendben. Más megvilágításban: egy distró is pont onnan csomagol, ha kihagyod a disztrót, akkor neked "kell disztrót játszani magadnak"
"VMware meg nagyon szep es nagyon jo, csak monjduk rakjal mar ossze egy altalad leirt rendszert 5 perc alatt kodbol, kattintgatas es egyebek nelkul. A komplexitas csokkentese meg pont nem az enterspajzokra jellemzo, hanem a modern infrakra." Egyrészt a vmwarenek tök használható APIjai vannak, úgyhogy akár azt is lehet, másrészt bár az infrastrcture as code egy tök jó szemlélet, de nem mindenható. Arról nem beszélve, hogy olyat konténeresdiből sem fogsz összerakni 5 perc alatt (pláne, ha alá az infrát is neked kell -- tudom tudom, olyan nincs)
"A komplexitas csokkentese meg pont nem az enterspajzokra jellemzo, hanem a modern infrakra."
Megint nem értetted. Így van, az enterspájz komplex. Ott ugyanis sokszor nem jellemző, hogy skálázódási probléma lenne, az jellemző, hogy baszott bonyolult rendszererket kell építeni, mert arra van igény. És ezért a microserviceknek az az előnye, hogy jól skálázhatóak, nem igazán érdekes.
"Ez mar regen nem az early-adopterek utani hullam, de nekem mindegy ha valaki igy latja, hat igy latja. A kiprobalt Puppettel meg semmi baj, ha a tovabbi lehetosegek ellenere dontenek mellette, bar ezt ismerven mind a kettot rettento nehez lenne megertenem :D"
Az a baj, hogy neked van egy saját világod, amit próbálsz mindenhova kivetíteni, és képtelen vagy megérteni, hogy van, ahol vannak más szempontok, meg igények. (Gyanús egyébként, hogy ezen igények nálad is ott vannak, csak nem nagyon veszed észre őket), és hiába írod le, hogy nincs silver bulett, csak nem akarod megérteni, hogy én is csak ennyit mondok :) Hogy ez sem jó így mindenhova, illetve, hogy van, ahol jó lenne, de egyszerűen nem éri meg a befektetett energiát a rá való átállás, mert vagy nincs annyi hozadéka (mert a fujj dolgokat már megoldották a puppetben, és nem kér enni), a lehetséges előnyök meg ott nem annyira relevánsak, vagy legalábbis egyelőre úgy ítélik meg, hogy még túl magas a kockázata annak, hogy 2 év múlva megint alapjairól kelljen baszakodni, vagy hogy folyamatosan sok erőt fog elvinni a tooling változása utáni rohanás. (3 hónapos docker release cycle megvan?). Egy szóval nem mondtam, hogy nem jó, nem előremutató, nyilván mi sem véletlen foglalkozunk vele, hanem azért, mert látjuk az előnyeit is.