Docker vs. Config management

A dockert arra szánták, hogy a szervereiden futó alkalmazásokat el tudd szeparálni egymástól. Pl.: Apache, Smtp. A lényeg, hogy ha feltörik az egyiket, akkor csak az egy szolgáltatást tudtak megtámadni. Másik oldalról meg támadás esetén kuka a konténer és indítasz másikat még ki nem javítod a hibát.Az adatbázis részéről nincs tapasztalatom.

A Docker igazi előnyei csak bizonyos típusú alkalmazásoknál jönnek elő, ott is csak akkor, ha bizonyos típusú munkafolyamatok mentén szerveződik a fejlesztés és az üzemeltetés.

Mire gondolok pontosabban?

Az alkalmazás legyen horizontálisan skálázható, működjön úgy, hogy sok kicsi, önálló gépre szétosztva működőképes, illetve lehetőségek szerint a node-ok számának növelésével közel lineárisan növekedjen az áteresztőképesség. Ezzel a klasszikus egygépes alkalmazások marha nagy része kiesik, nem optimális Docker-ben futtatni (bár lehet, de minek).

Az alkalmazás egy-egy node-ja legyen állapotmentes, ne akarjon semmilyen adatot önállóan tárolni. Ezzel a klasszikus relációs adatbázisok, mint a MySQL vagy az Oracle szépen kiesnek, ezeket sem célszerű Docker-ben futtatni (bár szintén lehet).

(Megjegyzés: fejlesztői környezetben, ahol nem zavar, ha az adatbázisodat időnként egyszerűen eldobod, ezek a limitációk úgymond nem számítanak, ezért ott lehet érdemes ilyenekkel szívózni, csak éles rendszerre ne így akard átvinni a dolgokat.)

Az alkalmazást ne zavarja, ha egy-egy node-ját "csak úgy" kikapcsolod és beraksz a helyére egy újat. Kiesik minden, ami nem áll le/indul el legfeljebb pár másodperc alatt, ezekre megint nem ideális a Docker (persze működhet).

A fejlesztési folyamat legyen olyan, hogy az artifact, ami eredményeképpen létrejön, hozzon létre egy új Docker image-et. Ha .war fájlokat kell belekalapálni a Docker-be telepített JBoss-ba, akkor a Docker inkább hátráltatni fog, nem segíteni. Ez egy csomó üzemeltetéssel kapcsolatos terhet ró a fejlesztőkre, amit sokszor inkább nem kérnének, de emiatt bukják a Docker előnyeinek nem-fejlesztéssel-kapcsolatos részét.

Az üzemeltetés legyen olyan, hogy elfogadja, a programok hibásak, és néha jobban megéri egyszerűen újraindítani őket, mint kivizsgálni hogy mi volt a hiba és megoldani azt. Ez nagyon-nagyon nem intuitív szokott lenni az üzemeltetők körében.

Mindemellett az üzemeltetés ne átadott fekete dobozként kezelje a fejlesztések eredményeit, hanem értse, hogy minek kellene történnie bennük, illetve mi történik bennük. Ennek az első felét általában az üzemeltetők nem kérik, a második fele kapcsán meg eléggé gyerekcipőben jár még a Docker.

Szóval akkor mégis, mire jó? Mit lehetne futtatni benne?

Arra jó, hogy egységes kereteket adjon a fejlesztésnek és az üzemeltetésnek, hogy közelebb hozza őket egymáshoz, bizonyos aspektusokat standardizáljon.

Arra is jó, hogy a nagyon kellemes tulajdonságokkal rendelkező alkalmazások (horizontálisan skálázható, állapotmentes, adatokat nem tároló, eldobható/cserélhető node-okból álló, jól monitorozható stb.) alkalmazások egy ideális környezetben fussanak. Ilyen alkalmazás nem sok van, de egy elég jó, erős példa egy webes alkalmazás, amelynek a frontendje állapotot nem tárol, a backendje pedig valami jófajta NoSQL adatbázis.

Ehhez tök jó a Docker. Ritka az ilyesmi...

Nekem az jött le, hogy...

Nézzük ezt a 3 réteget: OS->futtatókörnyezet->alkalmazás

Ha két alkalmazást akarsz futtatni, amiknek eltérő (akár egymást kölcsönösen kizáró) futtatókörnyezet kell, akkor azt gondolhatnád, hogy több OS példány kell, lehet pl. virtualizálni. Nagy divat ez, például SharePoint telepítés arról szól, hogy telepítesz egy tucat szervert, X darabon fut egy frontend IIS (és más semmi), Y darabon fut egy caching szerver (és más semmi), darabon MSSQL (és más semmi), stb. Ebben elég sok az erőforráspazarlás.

És akkor jön a konténer, ami eggyel fentebb, a futtatókörnyezet szintjén vág. Kicsit olyan, mint a virtualizálás, de nem az egész OS-t virtualizálja, kevesebbet eszik, de az alkalmazásnak mindegy, hogy mi fut alatta. Plusz még annyi előnye van, hogy idejében megfogták és szabványosították.

Van olyan (ritkán), hogy egy SW gyártó egy teljes VM image-et ad oda neked, hogy tessék, ez itt a SW/appliance/akármi. Ez egy fekete doboz, vagy hozzáférsz és tudod frissíteni a benne levő OS-t, vagy nem, túl nagy a mérete, sok erőforrást eszik, stb. Egy konténeres alkalmazást több praktikus okból könnyebben lehet terjeszteni.

--

Egy ideje ismerkedem a Dockerrel, de nem igazán sikerült dűlőre jutnom vele, hogy igazából miért is lenne nekem jó.

akkor talan erdemes lenne a docker oldalan a bemutatkozo rizsat elolvasni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Mindig azt szoktam mondani, hogy ha valakiben felmerul a kerdes, hogy miert is jo neki a Docker, akkor 99.99% esellyel nem jo neki a Docker.

Hatalmas hype van korulotte (ld. Gartner Hype Cycle), rengeteg eszkoz hianyzik ahhoz, hogy normalisan lehessen hasznalni, es az uzleti igenyek nagy reszere nem ez a megfelelo megoldas. Weboldalakra, webalkalmazasokra egy mikroszkoppal merheto reteget kiveve nem tulzottan alkalmas. Ha hatalmas "felhos" alkalmazasokat irsz, ahol fel-le skalazol a mindenfele komponensekbol, nincs permanensen igenyelt darabszam, akkor lehet ilyesmivel jatszani.

Jo pelda lenne erre pl egy build cluster, ahol a kulonbozo jobtipusoknak kulonbozo fele Docker containerek indulnak es minden job egy-egy containerben fut izolalva. De ehhez kell egy scheduler, ami megalmodja, hogy mikor mibol mennyi kell, stb stb. Ez nem annyira trivialis.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A dockert az az LXC, ami hordozhato, de eredetileg arra talaltak ki, hogy futtatsz benne egy parancsot es kesz. Bar mi egesz szep kis IaaS rendszereket alakitottunk/alakitunk ki benne. Csak kell hozza mondjuk supervisord vagy monnit, vagy akarmi hasonlo.

Nekunk bejott.

Én úgy látom elég sok itt a félreértés. A Docker arra jó, hogy nagy mennyiségben tud olyan alkalmazásokat futtatni, melyek webalkalmazások és/vagy nagyon jól skálázódó alkalmazások. Valamint üzemeltetésben van egy nagyon nagy előnye: amikor jönnek a különböző fejlesztők különböző verziójú és egymással pl nem kompatiblis, vagy egy rendszeren nem jól viselkedő libekkel, különböző PHP/Perl/Python/Ruby stb verziókkal küldik az alkalmazásaikat, amiket az ügyfél/diviziók/stb számára futtatni KELL és old meg... Nem csak hype ez, hanem egy teljesen az élet szülte megoldás. A megvalósítás persze hordoz hátrányokat, gyorsan fejlődik, alakul még. Ami a rkt akart választ adni, ők is észbe kaptak, és elkezték modulárisra alakítani a rendszert. Van már multi-host networking, régen is lehetett erre megoldást találni, még 1.7 és 1.8 előtt is.

Akik az állományok, www tartalom, mail stb miatt aggódtak, azoknak mondanám ,hogy van volume management, amivel akár a lokális vagy becsatolt könyvtárakat is lehet a rendszernek átadni. Az 1.8-tól már stabil(nak mondott) plugin/driver alapú volume managementtel pedig lehet mindenféle storaget használni, pl Ceph-et, EMC megoldásait stb. Eddig is volt lehetőség, még a swarm/compose/stb megoldás előtt a Flocker-rel, stb kezelni az "utazó" volume-okat. És lehetne folytatni. Attól, mert a magyar felhasználásra - mivel nincs meg a kultúrája - nem a legmegfelelőbb, attól még ez jó megoldás.

Az meg, hogy ezt üzemeltetni nehéz, IP kiosztásokat stb hogy kezeljük, azoknak pedig a figyelmébe ajánlom, hogy a Dockert nem az 1-2-3 fizikai szerveres környezetekre találták ki. Kit zavar, hogy más az IP éppen? A hostnevhez tartozó IP-t lehet frissíteni belső DNS-ben, lehet elé tenni ADC-t, vagy sima reverse proxykat. És igen, ezt össze kell állítani, meg kell tervezni, meg kell csinálni. Még, aztán már egyre több kész megoldás is van erre.

az OP felvetesere reagalva:
a konfiguracio-menedzsment egyik legnagyobb problemaja, hogy a gyakorlatban nem eleg jol definialt a kiindulasi pont, amire epitesz, hiszen nem eletszeru minden egyes rendszercsomagot CM-ben kezelni. emiatt nem ritka, hogy egy nem menedzselt csomag kepes a fejere allitani amugy mukodo rendszereket. erre szuletett megoldaskent pl. a Vagrant, amivel garantalni lehet, hogy - ha nem is irtuk le pontosan a kornyezetet CM-ben - ket, egymastol fuggetlen gepen ugyanazt az allapotot allitsuk elo a fejlesztoknek.
a Docker par szempontbol elter: egyreszt az UnionFS hasznalata miatt konnyebb osszeallitani a rendszert es kevesebb helyet foglal, masreszt az LXC miatt nincs virtualizalas, csak izolacio, ami gyorsabb, persze mas kerdes, hogy a halozati reteg ebbol a sebessegbol mennyit vesz vissza.

a kontener ilyen szempontbol Maggi kocka (ez legyen az alap), es a te munkamenetedhez passzoloan valaszthatod, hogy utana Puppettel vagy massal rakod ra az alkalmazast, vagy az is egy kontenerreteg lesz, vagy hogy Dockerfile-t adsz a fejlesztonek es/vagy a CM repo cimet. ismerek olyan helyet, ahol az eles alkalmazas is Docker alol fut, mert igy egyseges a pipeline, de olyat is, ahol csak a fejlesztok hasznaljak es tole fuggetlen deploy van VM-ekbe.

Egy kis gondolat ebreszto hogy lehet ezeket osszegyurni, https://www.youtube.com/watch?v=KSo_mcJxFIA