Hirdetés

Keresés

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

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

  • ZeroCool

    csendes tag

    Jó a kérdés. Ezekhez a technológiákhoz értő szakemberek is kevesen vannak még ma Magyarországon szerintem (arányosan). Ez egy viszonylag új technológia és szemlélet. Ezen túl ezeknek a cégeknek van egy kialakult infrastruktúrájuk, és ehhez szervezetük. Ezen technológiák bevezetéséhez egy más szemléletre és infrastruktúrára is szükség van, amire váltani azért egy hosszabb folyamat. Főleg úgy, hogy közben a már meglévő üzletileg kritikus alkalmazásokat is fent kell tartani addig amíg esetlegesen azok is nem állnak át.
    Maga konténerizáció hozza magával a DevOps szemlélet kialakítását is.

    Ugyan soknak tűnik az az idő ami az Instant Payment kialakítására rendelkezésre állt, de ha belegondolsz, hogy szinte az összes rendszert módosítani kell emiatt, és ezzel együtt még esetleg egy új technológiát is be kell vezetni, máris nem tűnik olyan soknak ez az idő, ha biztonságosra és stabilra akarják megcsinálni.

    [ Szerkesztve ]

  • ZeroCool

    csendes tag

    "a konténer arról is szól, hogy ha nagyon elterjed, az üzemeltetőnek nem lesz állása. de nem ez a fő kifogásom ellene, hanem az, hogy úgy látom, tájékozatlanul alkalmazzák. azt hiszik, az mindenre is jó, miközben például a biztonságába vetet hit megalapozatlan." - Ezzel azt akarod mondani, hogy ezeket a konténerizált rendszereket szerinted nem kell üzemeltetni, vagy azt, hogy egy üzemeltető még a tróger programozóknál is trógerebb mert nem hogy megalkotni nem tudja a konténerizációt, de még csak meg sem tudja tanulni használni?

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