Keresés

Hozzászólok Aktív témák

  • Köszönöm a részletes kifejtést, öröm volt olvasni:R

    Kíváncsi vagyok a másik oldal véleményére is:K

    Off offja: nagyon szeretem ezeket a beszélgetéseket, mert ezekből rengeteget lehet tanulni.

    A kicsire nem adunk... a nagyot meg leszarjuk!

  • ZeroCool

    csendes tag

    Ne haragudj nem akarlak megbántani, de nagyon sok butaságot írsz. Egy kicsit olvass még ennek utána. Olyan érzésem van, hogy soha nem hallottál még arról hogy Virtual Machine, és soha nem láttál egy nagyobb IT infrastruktúrát.

    Első körben a konténerizációnak semmi köze az IG3/AZUR/IP projektekhez. Ez egy eszköz amit a megvalósítást segíti. Van olyan bank aki ezt használja, de legtöbben nem.

    Általában egy nagyobb IT-val rendelkező helyeken nem az van amit írsz, hogy vesznek egy vasat, arra raknak linuxot és akkor telepítsünk rá valamit. Komoly szerverek vannak, amelyeken virtuális gépek futnak, saját operációs rendszerekkel, olyannal amire egy adott rendszernek szükséges van. Na már ezeken a virtuális gépeken saját ökoszisztémát kell kialakítani. Egy virtuális gép a rá telepített operációs rendszerrel már önmagában is egy szignifikáns mértékű erőforrást használ.
    Nézzünk egy egyszerű példát. Van egy JAVA-s alkalmazás, ami 8-as verziót használ. Ennek kell még valamekkora storage és még mondjuk linuxon fut. Van egy másik .NET-es alkalmazásod amihez viszont windows oprendszer kell, több memória .... Mit tett eddig a jó üzemeltető? Csinált még egy VM-et. Ami a saját működéséhez is elvisz megint egy csomó erőforrást.

    Na legfőképpen ezt a problémát oldja fel a konténerizáció. Nem kell "még egy VM". A konténerek a host operációs rendszer minden szolgáltatását igénybe tudják venni, és egy konténerben csak egy szolgáltatás vagyis alkalmazás fut. A konténernek minimális erőforrás igénye van önmagában, mivel a host operációs rendszer erőforrásait használja. Egy konténer önmagában egy egészet képes alkotni, minden környezeti beállítással ami nincs hatással sem a host operációs rendszerre, sem a többi konténerre. Egy konténert el tudsz készíteni úgy, hogy legyen benne 7-es JAVA, a másikat úgy, hogy legyen benne 8-as. Mind a kettőben egy másik alkalmazás fut. Mi történik ha a 8-as JAVA-t upgradelni akarják 11-re? Megteszik, és a többi konténerben futó alkalmazásra semmi hatása nincs. Érted már a lényeget?

    Nem biztonságos? Megint csak írsz valamit, de fogalmad sincs milyen konfigárciós lehetőségek vannak.

    Ezen túl egy elkészített Docker image immutábilis. Egyszóval ha a fejlesztők azt egyszer elkészítik, azt kiadják akkor abban teljesen biztosak lehetnek, hogy nem lesz konfigurációs probléma akkor amikor azt valaki elindítja, mert az fog elindulni amit ők kiadtak.

    Írtál még az orkesztrációs eszközökről. Ezek nélkül is tökéletesen tud futni egy konténer. Mire jó? Hogyan oldod meg most azt, hogy ha egy alkalmazás szervered leáll? Vagy esetleg csak az alkalmazás benne? Most is mindenféle monitorozó eszközt használnak, hogy lássák ha egyáltalán gond van, és fix méretű klasztereket használnak a kiesésmentességre. Az orkesztrációs eszközök ebben segítenek. Ők maguktól el tudnak indítani, illetve leállítani konténereket bizonyos feltételek alapján. Ennek mentén a skálázódás és a kiesésmentesség sokkal jobban menedzselhető. Hirtelen ráugrik 100x annyi felhasználó az alkalmazásra mint 1 perccel azelőtt volt? Elindít még 4 példányt az alkalmazásból, és vígan kiszolgálja a megnövekedett terhelést. Majd amikor vége, akkor leállítja ezeket a példányokat, és máris nem használ el az alkalmazásod annyi erőforrást.
    Egy másik nagyon hasznos szolgáltatás. Hogyan oldod meg a mostani rendszerekkel a kiesés mentes verzió frissítést? Nagyon nehezen, mindenféle loadbalancerek, és szerverek kézi konfigurációjával. Ezek az eszközök egy maguktól megoldják neked. Stabilan.

    Amit még írtál, hogy milyen gyorsan lehet deployolni. Itt is a "nem hiszem". Nem érted a lényeget. Nem egy szövegszerkesztőt akarsz a linux alá feltelepíteni, hanem egy pl. egy banki üzleti alkalmazást. Ez pedig lényegesen gyorsabb mint az alkalmazásszerveres megoldás. Persze a szoftvert is jól kell tervezni.

    Nem egyszerű? Nem is bonyolult, csak hát ez is egy olyan dolog amiről nem 3 youtube videót kell megnézni, hogy hogyan kell, hanem olvasni és tanulni.

    Én azt mondanám, hogy mielőtt legközelebb kioktatod a fejlesztőket egy olyan technológiáról amiről halvány sejtelmed sincs, hogy milyen trógerek és semmirekellőek, azelőtt kicsit tájékozódj. Főleg, hogy több embert is teljesen tévútra terelsz ezzel.

  • Vektast

    tag

    Fasza kis iromány lett! :) Köszi! :C

    ÁR FIX! - erre 10 esetből 8x privátba: "Hallod menyji az ajja.?"

  • hallador

    addikt

    A konténer tesz pár ígéretet, amiből, szerintem, egyet se tart meg.
    például:
    - gyorsan lehet deployolni. nem hiszem, hogy az oprendszer saját csomagkezelőjénél gyorsabban bármi tud deployolni.

    Mert miért is kellene csak oprendszer csomagokat deployolni, a fejlesztők által készített saját fejlesztéseket hogyan szeretnéd teríteni a saját csomagkezelővel?

    - biztonságos1. a konténer szoftverekben is lehet hiba, az interneten olvasott hírek szerint van is.

    Hát ja mint magában az operációs rendszerben is, ennyi erővel nem szabad csak számológépet használni azt nem tudod semmihez csatlakoztatni, sarkított példa, de érthető szerintem.

    - biztonságos2. a konténerekből pillanatok alatt ki lehet törni, tehát hoszt oprendszerbeli védelmet nem ad

    Mint ahogy a rosszul beállított ssh-t is fel lehet törni pillanatok alatt, ami magától semmilyen védelmet nem nyújt. Ezt ne hozd fel mert, ha ez így lenne, akkor a google-től, az amazonon át a Microsoftig senki nem használná ezt a technológiát, de most már ott tartunk, hogy a Cisco, vagy a HP mint hardvergyártó is konténereket használ a frissítésekhez.

    - egyszerű. a konténer maga lehet egyszerű (egyébként nem az), de a használatához mindenféle kiegészítő szoftverek kellenek, amiket egyrészt sok energia megtanulni, üzemeltetni, másrészt ugyanúgy bugosak, mint a konténer.

    Nahát nincs ingyen semmi, meg kell tanulni, hát igen az élet nem olyan mint amit megszoktak otthon van ilyen. Mi az, hogy bug-os? Mond már meg, hogy melyik operációs rendszer az amiben nem volt épp aktuális bug, tudsz ilyet mondani?

    - mindenféle szolgáltatásokat ígér: amiket az alap oprendszer ugyanúgy tud, mint amit a konténer állít magáról.

    Bizony így van, csak ameddig a konténer képes ezt a 10-ed annyi erőforrással megoldani. Addig az operációs rendszer mivel minden egyes feladathoz egy külön kernel kellene, addig a konténer számára nem kell. Pont ez a lényege. Platformfüggetlen a dolog nincs odakötve a kernelhez, vashoz oprendszerhez platformhoz.

    a konténer szerintem egy olyan technológia, ami úgy jött létre, hogy pár programozónak már nagyon viszketett a segge az unalomtól, hogy programozni kellene valamit, hát csináltak egy konténert, ahelyett, hogy megvakarták volna, vagy uram bocsá', megmosták volna. ezzel a húzásukkal ahelyett, hogy a hibák alaprendszerből történő kitakarításába feccölték volna értékes munkaerejüket, újabb hibák rendszerbe pakolása sikeredett. ez egy ilyen "nem elég, hogy dácsiát vettél bmeg, még szét is borítod munka közben" típusú hozzáállás. ezzel párhuzamosan meg kidobják azok munkáját, akik valóban hasznosan áldozták idejüket arra, hogy egy dpkg meg egy apt rendesen működjön.

    Még szerencse, hogy csak szerinted, mert vannak azok a csúnya dolgok, amik keresik az egységesített dolgokat, ahol a dpkg,, yum, bind, meg ki tudja miket nyugodtan elfelejtheted, mert ezt megoldja a rendszer, ezáltal nem is kell neki semmire várnia. Ha az egyik konténer megsemmisül a microservice-en belül, a másik úgy képes elindulni, ha kell, hogy 1 sec-sem esik ki a rendszer üzemeltetésből, na ezt old meg vm-el, vagy teljes virtuális géppel, mindezt úgy, hogy egy fizikai vason futhat akár 40 konténer is. A rugalmasság az ereje, nem a szerinted miért nem jó, hát ja a 2000-es évek elejének vége van, ezt kellene felfogni.

    egyébként ki lehet ezt számolni: ha p1,p2,p3,...,pn a valószínűsége, hogy az i-dik szoftverréteg hibátlanul működik, akkor

    P=p1*p2*...*pn

    a valószínűsége, hogy az egész kóceráj egyben jó lesz, ahol minden pi<1. Következmény: minél több réteged van, ami 1-nél kisebb valószínűséggel hibátlan, az összegük annál labilisabb lesz.

    Igen pont ez a lényege, hogy a konténert nem virtualizáción futtatunk, hanem natív hardveren. Ugye a konténert virtualizálni az valóban két réteg, ha virtualizálni akarom, akkor vannak erre már technológiák amint a HLC - COD , és barátai. Nem fogja elfogadni az érveidet, egy olyan vezető sem, akinek a 0 - 24 órás üzem a lényeg.

    Van amire nem jó a konténer, ilyen a nagy Oracle adatbázis, azt nem illik konténerbe tenni.

    a unix alapfilozófiája: KISS: Keep It Stupid and Simple. sem a konténer, sem a systemd nem ez.

    Meg a unix röpke 50 éves, lehet a múltban élni csak minek. A systemD meg hogy jön ide? Igen újra kell tanulni a Linux management-et, mert a SysV init sem mai gyerek már és nem felel meg a mai kor követelményeinek sem, elég csak arra gondolni, hogy mindenki elkezdte írogatni a kis scriptjeit a saját kis prorgam indításhoz, meg kezeléshez, aztán amennyi Linux disztró annyi féle systemmanagement. Na ennek aztán nagy értelme volt, persze aki szereti a káoszt annak első osztályú volt, de aki meg nem, annak a SystemD-t megtanulni még mindig egyszerűbb lesz, mert a systemctl, vagy a timedatectl a debian-on is ugyanaz lesz, mint a CentOS-en, bezzeg milyen jó volt amikor lehetett nyomni az upstartot, az init-et, a systemd-t, meg mi mindent párhuzamosan?
    Nem mondom, hogy a systemd fenékig tejföl, mivel a Red Hat fejlesztette, de a saját 7-es rendszerükben a SystemD tudásának fele van benne, ellentétben a CoreOS (vagy tisztességes nevén Container OS, by google)-ban minden funkciója elérhető.
    De még mindig jobb mint szerencsétlenkedni minden disztrón a saját dolgaival.

    Persze szigorúan magánvélemény.

    az informatika alaptörvénye pedig ez: ha nem romlott el, ne akard megjavítani. értsd: ha nincs valós igény egy problémára, akkor az nem lesz megoldva. a konténer nem valós igény.

    A mindent akarok, de semmit nem akarok érte tenni otthoni mentalitásból kiindulva igazad van, a való világ szerencsére nem úgy működik, mint magyar köz szféra. Szerencsére.

    Jönnek a süket dumával, hogy gyorsan kell deployolni. Ezt az igényt az hozta elő, hogy trógerül végzik el azokat a munkafolyamatokat, amik a szoftver meghatározásához kellenek, konkrétan a folyamatszervezést és a szoftver tervezését. Nem tudja a megrendelő se, hogy mit akar? nem baj, csinálunk valamit, hátha attól rájön, hogy mit akar, és akkor majd megcsináljuk azt is.

    Vagy inkább a magyaros piros pöttyös talicska bt helyett, van több ezer szerver, vagy több 10 000 konténer, amire nem lehet deployolni értelmes idő alatt kézzel nyomogatva . Addig elmegy a dolog, ameddig annyi szervert üzemeltetsz amennyit meg is tudsz fejben jegyezni, de ha van 5000 fizikai szerver meg 50 000 vm, meg 100 000 konténer, akkor már nem fog menni a dolog amit mondasz...

    Magyarul pazaroljuk a programozók munkáját, mert ha nem tudják, mit kell programozni, biztosan kidobásra ítélt kódot csinálnak, és megspóroltuk a szervezést, a megrendelő interjúztatását, kifaggatását. így a végén a legdrágább munkaerő sorozatos pazarlásával készül el valami. Ha így programozunk, akkor nyilván kell a gyors debloy, hogy a megrendelő két percenként változó igényeit követni lehessen. De ez marhaság, ez csak egy aktuális menedzsment bullshit. Ami ugyanez a kategória: kínosan viszketett már valamelyik yuppie menedzsernek, feszített a hátsója, hát mondott egy ordas baromságot ahelyett, hogy kiment volna a kishelyiségbe, és bedurrantott volna a perem alá. (zárójelben jegyzem meg: ennek a hülyeségnek az értelemszerű következménye egy csomó agilis szoftverfejlesztési módszertan is. hogyan dolgoztassuk a programozót akkor is, ha fingunk nincs arról, milyen feladatot kellene adni neki.)

    Hát ha így működne a google vagy a microsoft akkor már a 2000-es években tönkrementek volna. Azt értem, hogy amit leírsz az otthon így megy, na pont ezért vannak ilyenek, hogy az az csúszik, mert az emberi tényező olyan amilyen. De azért ugye te sem egészen gondoltad komolyan, hogy mindenhol úgy szórják az uniós pénzeket a semmire mint arrafelé?

    Néha felemlegetik az emberek a linuxnál a töredezettséget, hogy miért van kettőnél több desktop, stb. Amikor a konténer szóba kerül, akkor lesz hozzá egy bazi hosszú lista, "orchestration", hogy ceph, kubernetes, meg a fene se tudja, még mi, amik mind megoldanak egy olyan részfeladatot, ami konténer nélkül nincs. rotfl, aki ezeket feltelepíti magának, az csak plusz munkát okoz.

    Hát ja lefordítom azok nyelvére is akik nem egészen értik ezt, tehát szerinted ha búzát aratunk, akkor minden alkalommal kaszát kellene használni azért mert az egyszer bevált, igaz kell hozzá 300* több ember, és 4* annyi idő de végülis működik.
    Ahelyett, hogy kifejlesztünk egy gépet, ami nyilván igénybe vehet több évet is, és a 300 emberrel 600* több terményt tudunk termeszteni, igaz lesznek kisebb sarkok ahova a kombájn nem fér oda, de emiatt ne is használunk kombájnt? Hát?
    Hiszen amúgy a kombájnt egyszer kellett kifejleszteni, az pénzt és időt vett igénybe, se nem éri meg mert hát az mennyibe került? Meg kell hozzá még 3 traktor is kombájnonként ami a terményt elszállítja.

    Levetítve ezeket a banki átutalásos rendszerekre:
    1. konténernek elvben lehet értelme akkor, ha több usert akarsz kiszolgálni egyszerre egy vason.
    2. konténernek lehet elvben értelme akkor, ha több feladatot akarsz ellátni egy géppel, amelyek csak egy töredék gépet használnának ki. (egyébként ez más okból is hamis érv)

    Kérdés mekkora a rendszer amit üzemeltetek, mert ha van 10 fizikai szerverem, amin virtualizálok, akkor rendben van, de ha van 1000 akkor az érveid megbuktak. Ha van 3000 000 user akit ki kell szolgálnod záros határidőn belül, ami nem 3 000 másodperc, az érveit megdőltek stb.

    Ez a két érv ne legyen már igaz egy banki utalásos rendszerre. Ez annyira kritikus rendszer egy bankban, hogy erre vegyenek megfelelő mennyiségű dedikált gépet, és azon ne menjen semmi más. Egy banknak legyen már pénze pár darab márkás szerverre, főleg ilyen otp-k, mikor 1 milliárd eurós adózás utáni nyereséget jelentenek be.

    Na látod Te nem láttál még nagy rendszert elbagatelizálod a dolgot, itt nem pér szerverről van szó, hanem pár 100 szerverről, nyilván bármilyen cég úgy van vele, mint magyarok (persze uniós pénzből az "ingyen van") ugye ismered a jó magyar mondást "ami a tiéd az az enyém is, ami az enyém ahhoz semmi közöd" lefordítom senki nem fog a két szép szemedért feleslegesen pénzt kidobálni, csak azért mert valakinek volt egy jó ötlete, na feljebb fejtegetted a programozókat, ez amit ide felvázoltál szerinted mennyivel jobb?

    3. A konténertechnológia jelenleg jól láthatóan nem hibátlan szoftver.

    Ja ja mert a Windows vagy a Linux az?

    4. Volt már a héten intel proci sebezhetőség?

    Aminek mi köze van a konténerekhez?

    ezek alapján súlyos hiba lenne az átutalási rendszer mellé beengedni ugyanazon gépre bármilyen más szoftvert, pláne idegen felhasználót. következmény: nincs szeparálási igény, a szeparálást a gép fémdoboza adja. akkor meg minek konténer?

    Ezek alapján amit leírtál súlyos hiba számítógépet használni.

    Egy ilyen rendszert úgy lehet jól megcsinálni, hogy fogod az architektúra tervet, amit egy átlagos java architekt tervezett, és kihajigálod az összes réteget, ami nem kell. majd elolvasod Himfy-t, és alkalmazod :) ami marad, azt pure linuxon megvalósítod, és akkor jó lesz.

    Igen, 2000-ben, nem 2019-ben.

    Szerintem

    (#120) UnA

    Ha nem lenne hosszú távú gondolkodás, akkor a több generációs cégek nem léteznének, az, hogy otthon nincsenek ilyen cégek, amik 50 - 100 éve léteznek és gyarapodnak, nem jelenti, hogy máshol sincsenek.

    (#102) rednifegnar

    Mi sem értjük az 5 másodpercet, de szerintem van egy olyan benne, hogy valamelyik kitalálta ezt és azért is meg akarják csinálni. Értelme nem sok van, de el lehet mondani, hogy ezt is "megoldottuk".

    [ Szerkesztve ]

    [HP EliteBook 830 G6, I7 32GB 2TB, HP ProBook 430 G5, I5 32GB 1TB ; Debian Stretch; Linux Mint 19.3, Ubuntu 19.10, OpenSuse Leap 15.1 ; ASUS ZenBook UX333FA I3;]

Hozzászólok Aktív témák