1)
Köszi, de az aufst mint mondtam én láttam maga alá fosni csúnyán, uh kösz nem, mi most devmapperre lőttünk első körben de csak megjegyzés, mert
"A lenyeg az, hogy ha van egy megfelelo orchestrationod es mondjuk tegyuk fel valamilyen okbol kifolyolag mondjuk osszefossa magat az egyik geped az overlay/2 vagy barmelyik masik miatt, attol meg a szolgaltatas futni fog a tobbi gepen es atmasznak oda a kontenerek."
.. a lényeg az, hogy ja, ha van elég vas, meg olyan orchestration, ami ezt tudja. Magyarul ha nem random cloudba pakolsz, akkor ez egész üzembiztossága erősen kérdőjeles. Mondhatnám, hogy félkész, bugos szar :) aminek a méregfogát csak azzal lehet kihúzni, hogy sok vasat teszel alá.
2) Tudom, hogy van a kubernetesben ilyen. Arra hoztam példát, hogy kiforratlan :)
3) Igen, saját registryt futtatunk. Valahova tenni kell a saját imageket.
4) Nem, arra gondolok, hogy amikor ilyet akarok csinálni -- a dangling=true azt hivatott filterezni, ami imagere már nincs hivatkozás, ezért nyugodtan lehet rmi-zni. Namost, ha a docker szerint van 63 ilyen, meg 62 ami nem ilyen, akkor elvárnám, hogy ne összesen 82 image legyen, hanem 63+62, lévén ezeknek határozottan diszjunkt halmazoknak kéne lennie. Na jó, több még esetleg lehetne, ha van olyan állapot is, hogy dangling=fassetudja, (de mondjuk akkor meg azt is ki lehetne vezetni) de kevesebb semmiképp. Ha egyébként látod azt is, hogy a "docker images -f dangling=true -q | docker rmi" -- aminek ugye le kéne szedni a danling imageket időnként sír, hogy amit ő megpróbált most leszedni, az nem ment, mert valmi még használja, akkor eljutunk a félkész mellett a bugosig is.
5)
"- docker imagek eseten mar kicsit kacifantosabb a kerdes, alapvetoen csak hivatalos docker inc altal keszitett imageket hasznalok, egy se joskapista altal keszitett. Mind a quay.io es a dockerhub is kinal securityscan szolgaltatast es ezekre is lehet hookokat kesziteni, hogy ha vmelyik komponens serulekeny es van uj verzio akkor csinaljon uj imaget. "
Magyarul bejött egy új problématér, a random imagek security scanje, ami korábban így nem volt. Attól, hogy te ezt outsourceolod, még új problémák, amiket kezelni kell (vesd össze, fizethettél volna valakinek a puppet üzemeltetésért is)
"-- miert akarnam reprodukalni? Erre mondj mar egy peldat pls, lehet hogy csak az en fantaziam tul szegenyes :/ Penzugyi intezeteknel van ilyen esetleg?"
Azért, mert pl van egy verzió egy ügyfélnél belőle, és amikor fél évvel később bugot jelent, akkor jó lenne tudni abban a környezetben javítani, ami nála van. Ahhoz meg az kell, hogy elő tudd állítani azt a környezetet.
---
Egyébként meg a kiforratlant az is jól példázza, hogy én hozom a docker hibáit, te meg mutogatsz arra, hogy de ezt kubernetesben meg lehet oldani. A kiforratlannak az is jó fokmérője, hogy időnként nagyot kell csavarni (pl mikor majd -- ha -- a docker behozza lemaradását orchestration téren, és ezért érdemes lesz arra menni, mondjuk a kubernetesről).
Félre ne érts, egyáltalán nem rossz eszközök ezek, de vannak olyan helyzetek, amikor ezt a fajta rugalmasságot nem lehet elvárni a környezettől.