( Sea-you | 2017. 06. 07., sze – 14:13 )

4) Nyilvan tudom mit latok magam elott, nem kell az oltogatas ;) Megint egy olyan problemat hozol fel amit magadnak csinalsz, mi a francnak buildel ugy a build-toolotok ha a fenti problemat okoz, azert a harom percert ami a cache elonye build kozben (--no-cache)? Fejlesztes kozben nem buildelsz imageket, hogy ez az - egyebkent - jelentos elony meglegyen, ha meg olyan zavaro ahelyett, hogy a cleanupon duhongsz, rakjal ala eleg nagy storaget, hogy ne legyen gond vagy hasznalj valamilyen sidekick gc-t (https://github.com/meltwater/docker-cleanup). Biztos olcsobb mint kezzel takaritgatni vagy cronnal bohockodni.

5,6) "Nem lehet ma egy dockerfileba olyat írni, hogy FROM foobar:${TAG}"

Mert teljesen felesleges es/vagy tobbet art mint hasznal. Valami nagyon el van cseszve azzal a pipeline-nal ahol a FROMot dinamikusan akarod valtoztatgatni, de ha akarod ott a sed nekem mindegy. Ez nem a docker hibaja.

"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." -

Evekkel ezelott ;) Mivel nekem - bizonyos kereteken belul - teljesen mindegy, mivel futtatja a fejleszto az alkalmazasat es az az image minden olyan dependencyt tartalmaz ami kell neki kell, innentol kezdve a problema ismeretlen.

"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" - pipnek es cpannak is van dependency managementje (requirements.txt es Carton) bar cpannal halistennek az elmult 5 evben nem talalkoztam :D A fejleszto felelossege, hogy a megfelelo verziokat pinelje nem az enyem. Sot, o buildel es deployol is, a you wrote your shit, you run your shit jegyeben :) Bar mivel vertikalis csapatok vannak manapsag egyre ritkabb a fejlesztes vs uzemeltetes szeparacio.

" 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ó" Ennel jobb szemlelettel eddig nem talalkoztam. Reprodukalhato, unit tesztelheto, nem kell felesleges - hamar elavulo - dokumentaciot irni hozza estabbi, https://techbeacon.com/infrastructure-code-engine-heart-devops

"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." mert altalaban nem ertik, hogy milyen elonyei vannak a komplexitas csokkentesenek, tobbek kozt ezert se dolgozom mar enterspajzoknak bar ez mellekes :D

Sztem az alapveto kulonbseg a kettonk latasmodja kozott, hogy te enterspajzozol en meg - mar - nem. Tudom milyen agyament f@szsagok mennek a nagy cegeknel es mennyire fontos a politika a szintiszta technikai dontesek helyett (lasd nem az a fontos amit mond, hanem h ki mondja)