( sj | 2017. 04. 11., k – 21:20 )

például a RHEL/CentOS vonalon khm. konzervatív módon frissülő csomagok helyett

akkor nem redhat kontenerre van szukseg, ennyire egyszeru. Ja, hogy nektek redhat support van, es ezert mindent szognek neztek...

de onnantól kezdve nincs az üzemeltetőnek lehetősége korrekten frissíteni a cuccot

amint irtam, nagyon szar az a felallas (de ezt mar te is latod), ahol a dev es az op egymastol fuggetlenul mukodnek. Masfelol egy normalis kontenerben kb. par processz fut, szo sincs 34 helyrol szedett 45 db 'innen-onnan' komponensrol.

Mivel a preferalt setup az 1 szolgaltatas per kontener (hacsak nincs ra jo okod maskent tenni), igy az is jarhato ut lehet, hogy egyik kontener redhat, masik kontener az masik disztro, amelyik ertelmes verziot szallit az xyz applikaciobol.

Amit eloadtal, az antipatternek es elbaszott folyamatok, ill. szervezesek sorozata, amibe bele van kodolva a frusztracio, es ami akkor is megbosszulja magat, ha nem kontenereztek, hanem maradtok a virtualis gepeknel.

Azonban egy csak egy kicsit is ertelmesen osszerakott szervezetben a dev es az op egymas mellett, egyutt dolgoznak (devops, sot devopsec rulez), es a termek kialakitasaban mar a kezdetektol fogva benne van az uzemeltethetoseg is (sok egyeb massal egyutt)...