( vl | 2021. 05. 07., p – 00:20 )

sokkal inkább egy fejlesztői evolúció, mintsem üzemeltetési evolúció

Leginkább sw deployment evolúció, azaz ahol a kettő összeér egymással.

nem a virtuális gépek utáni lépés

Ez egy réteggel feljebb van.

hanem a szerződött szállító biztosít valamit, aminek hátteret kell adni

Azt a problémát képzeld el, hogy a VM-es világban a sw vendor (a fejlesztők) adják a VM image-et, te meg próbálod futtatni. Ugye érzed, hogy ez miért baromi kényelmetlen? Nem is tipikus, de láttunk már ilyet.

Na ezt a problémát oldjuk meg azzal, hogy máshová húzzuk az interfészt, amit az üzemeltetés ad a fejlesztők által biztosított izének. A VM megoldásokkal az a fő gond, hogy az emulált valami (az x86-os hw) nagyjából meghatározza, hogy mi van az interfész két oldalán, attól lényegileg nem lehet eltérni. Viszont ez sajnos olyan dolgokat rak az alkalmazás oldalára, amiknek az üzemeltetés oldalán kéne lenniük. Hasonlóan az OS package-ek interfésze meg olyan dolgokat tol az üzemeltetés oldalára, amiknek ideális esetben a fejlesztők problémáinak kéne lenniük. Ezér t szívás a VM image szintű terjesztés is, de a klasszikus OS package terjesztés se ideális.

Ezért jött létre ez a konténeresdi. Úgy húzzuk meg az interfészt, amit a konténer kap, hogy azok a dolgok legyenek a fejlesztők reszortjai, amiket ők tudnak jobban, és azok a dolgok, amiknek nem a fejlesztőknél van a helyük, azok meg kívül legyenek. És a konténer így a sw terjesztési megoldást is kezeli: ami bent van, az a fejlesztők feladata, oldják meg otthon, és csá. Ami kint van, azzal meg ne foglalkozzanak, az a környezetet biztosítók feladata. Ezzel rengeteg dolgot, ami hagyományosan egy install guide-ban humán fogyasztásra lenne leírva, azt itt a számítógép megcsinálja helyettünk (ergó scriptben kell valakinek megírnia). Illetve a favágás helyett egy-két szinttel feljebb levő, értelmesebb dolgokkal kell csak az embernek foglalkoznia (jellemzően a "hogyan illeszkedjen az alkalmazás a mi környezetünkbe" kategóriában).