Microsoft SQL Server(ek) Docker-el. Megeri?

Virtualizáció

Sziasztok!

Meg csak most ismerkedem a Docker-el, lattam hogy van ala Microsoft SQL Server on Linux is.

Az infrastrukturankban jeleneleg eleg sok kulonallo VM fut (ESXi alapokon) amik mind egy teljes erteku Win. Server 2012/2016-ot futtatnak, MSSQL szerverrel. Azon elmelekedtem, hogy krealok egy uj VM-et, es migralom a jelenlegi adatbazis VM-eket (vagyis az adatokat) egy-egy Docker-be.

Szerintetek megeri? Abbol a szempontbol, hogy mennyire egyszeru egy uj docker-t inditani, ha pl egy uj szerver kell, megerne... Stabilitasban sem lesz gond?

A masik, ehhez kapcsolodo dolog, hogy ma jelenleg nincs mod Linux host on futo Docker alatt Windows Server 2016 Core-t vagy Nanot futtatni igaz?

Olvastam a Kubernetes-rol, hogy tud valami ilyesmit az 1.5-os verziotol, bar ha jol ertettem, az csak annyit tud, hogy egy clusterben kepes kezelni Linux es Win alapu hostokat... Vagy felreertetem valamit?

Kicsit kodos meg nekem a Docker vilaga, ezert lehet amiket kerdezek, eleg banalisak, elnezest erte!

  • 2202 megtekintés

( Replaced | 2017. 04. 10., h – 19:56 )

"A masik, ehhez kapcsolodo dolog, hogy ma jelenleg nincs mod Linux host on futo Docker alatt Windows Server 2016 Core-t vagy Nanot futtatni igaz?"

nem, ez nem is lesz soha, hiszen a container nem virtualizacio

--
NetBSD - Simplicity is prerequisite for reliability

( uTibor | 2017. 04. 10., h – 20:21 )

Szia,

szerintem adatbázist konténerben tartani nem biztos, hogy a legjobb irány. Az adatokat mindenképp konténeren kivül kell tárolni, mert bár van projekt, ami perzisztens storage-t ígér docker alá https://clusterhq.com/flocker/introduction/, nem merném ezen tárolni az adatokat.

( sj | 2017. 04. 10., h – 21:58 )

az ms sql on linux eleve egy beta quality termek, tehat en eles uzembe nem tennem (ha csak jatszani kell, kiprobalni, az mas). Na most ha ezt meg egy olyan technologiaval sulyosbitod, amivel nem vagy kepben (=docker), az a disaster biztos receptje. IMHO.

Btw. a kubernetes meg egy orkesztracios cucc kontenerekhez, es nem hosztokhoz!

ma jelenleg nincs mod Linux host on futo Docker alatt Windows Server 2016 Core-t vagy Nanot futtatni igaz?

ha megerted, mi a kulonbseg a kontener es egy VM kozott, akkor tudni fogod a valaszt...

> az ms sql on linux eleve egy beta quality termek, tehat en eles uzembe nem tennem (ha csak jatszani kell, kiprobalni, az mas).
mintha olyat is emlegetnének MS oldalról, hogy nem is rakhatod éles üzembe jelenleg. (EULA, vagy valami hasonló tiltja is. vagy annak véget vetettek már?)

--
blogom

( Vamp | 2017. 04. 10., h – 22:22 )

Koszi a valaszokat!

Hasznosak voltak, kezd letisztulni a kep, mire is valo egesz pontosan ez a fajta rendszer...

Megertettem azt is, hogy itt kernelig egyezik minden, aztan valik szet kontenerekre a cucc, eltero kernel (Linux/Windows) soha nem fog menni egyutt. (max valami hardver szintu VM kozbeiktatasaval, ahogy azt teszi a Win is a Hyper-V-vel)

Csak sajnos azt nem tudom, mire tudnam en ezt hasznalni cegen belul... Ahogy nezem, az egyetlen szamomra logikus felhasznalas valami olyan terulet, ahol nagy szukseg lehet automatikus/manualis skalazhatosagra terheltseg vagy barmi egyeb fuggvenyeben. (webkiszolgalok pl)

De ilyen nalunk nincs... Jo lenne valami lista, hogy milyen gyakorlati megvalositasok vannak Docker-el.

> Jo lenne valami lista, hogy milyen gyakorlati megvalositasok vannak Docker-el.

mi (fejlesztők) az egységes környezet egyszerű megteremtésére használjuk.

S akkor nincs abból baj, hogy ki milyen Linuxon (esetleg Winen) dolgozik, ha több projekt, akkor más környezetet kívánnának, etc. Egy Dockerfile-ban le van írva (verziózva a prod kóddal, ez egy hatalmas előny!), s a „Nálam megy, ha nálad nem megy, old meg...” problémák jelentős részét megoldja...

Én még díjaznám, ha egyszer eljutnánk oda, hogy egy ilyen környezetbe csomagolt alkalmazás megy prodba, de nem vagyok telhetetlen... :-)
--
blogom

És onnantól kezdve, hogy a feljesztő mondja meg, miből, milyen verzió fut, a belepakolt komponensek biztonsági fixeit is vagy belerámolja a fejlesztő a konténerbe, vagy likas lesz, mint a rosta, az üzemeltetői oldal meg széttárja a kezét, hogy ez van...

A statikusra linkelt bináris is megoldja a "mindenütt fusson" problémát, csak épp erősen szuboptimális...

ha az a modi, hogy a dev csinal valamit, atdobja a falon az op-nak, hogy sok szerencset vele, az a fucked by design minositett esete.

Nem hinnem, hogy - 1. korben - a sec. fixek felpakolasa az adott csomagkezelo update parancsanal komplikaltabb lenne, ami lehet pl. a Dockerfile RUN-jaban az 1. parancs.

én is latest írok mindenhova (lustaság), de azért nem tanácsolnám senkinek:
- elvesztettem vele a verzihatóságot. Ha most kiszedek egy évekkel (félévvel) ezelőtti verziót (dehátottmégműködott), akkor a környezet random változhatott alatta. S egy python/java/apache/wildfly/kitudjamilyenfüggőség verzióváltásból előjövő hibát nem veszek észre. (igen, persze, nemkéne ettől eltörnie...)
- s ott akkor a build előtt figyelnem kell a docker pull-ra, vagy a lokális cache frissítésre, vagykitudjamiremég. (bár itt mintha tag-et is felül tudnék írni, de azért no...)

--
blogom

És ha nem megy, akkor máris nem az van benne, amit a fejlesztő elvárt, ergo rá lehet fogni, hogy... És nagyon sokszor jött már szembe olyan, hogy például a RHEL/CentOS vonalon khm. konzervatív módon frissülő csomagok helyett frissebb/más kellene - ezt persze konténerrel meg lehet csinálni, de onnantól kezdve nincs az üzemeltetőnek lehetősége korrekten frissíteni a cuccot - a letöltök valami targézét/bézékettőt/zip-et/jóégtudjamit (egy konténerhez jó esetben csak 45 darabot, szerencsés esetben csak 34 helyről...) és a következő konténerbe már ez kerül... Nos, ez nem igazán tetszetős/jól követhető megoldás - gondolj bele, hogy az összes innen-onnan komponenst valahogy számon kell tartani, a biztonsági riasztásokat és fixeket követni kell... Jobb helyen "erre tartják" az OS szállítóját, hogy csinálja az, és ha luk van,a kkor fixálja is - a sérülékenység súlyától függő gyorsasággal.

például a RHEL/CentOS vonalon khm. konzervatív módon frissülő csomagok helyett

akkor nem redhat kontenerre van szukseg, ennyire egyszeru. Ja, hogy nektek redhat support van, es ezert mindent szognek neztek...

de onnantól kezdve nincs az üzemeltetőnek lehetősége korrekten frissíteni a cuccot

amint irtam, nagyon szar az a felallas (de ezt mar te is latod), ahol a dev es az op egymastol fuggetlenul mukodnek. Masfelol egy normalis kontenerben kb. par processz fut, szo sincs 34 helyrol szedett 45 db 'innen-onnan' komponensrol.

Mivel a preferalt setup az 1 szolgaltatas per kontener (hacsak nincs ra jo okod maskent tenni), igy az is jarhato ut lehet, hogy egyik kontener redhat, masik kontener az masik disztro, amelyik ertelmes verziot szallit az xyz applikaciobol.

Amit eloadtal, az antipatternek es elbaszott folyamatok, ill. szervezesek sorozata, amibe bele van kodolva a frusztracio, es ami akkor is megbosszulja magat, ha nem kontenereztek, hanem maradtok a virtualis gepeknel.

Azonban egy csak egy kicsit is ertelmesen osszerakott szervezetben a dev es az op egymas mellett, egyutt dolgoznak (devops, sot devopsec rulez), es a termek kialakitasaban mar a kezdetektol fogva benne van az uzemeltethetoseg is (sok egyeb massal egyutt)...

Mondj légyszives egy másik, kellően stabil és hosszú távra tervezhető támogatással rendelkező OS-t, amit be lehet rakni konténerbe.
Azért egy funkció is képes 10-20-30 libfiszf@sz csomagot igényelni, ami szerencsétlen esetben főverzióban bőven nem az, vagy nem az lesz, mint amit az alap OS szállítója támogat. Nomostan ilyenkor vagy a fejlesztő veszi magára azt a feladatot, hogy követi az alkalmazásának az összes függőségét, foltozza a csomagokat, ha kell, vagy tojik rá - az ő általa írt kód működik, minden más meg le van nagy ívben tojva.
Az első esetben a fejlesztő többet fog kérni (részéről joggal), hiszen nem csak a saját kódbázisát kell figyelemmel kísérnie, hanem azt is, amit pluszban igényel a támogatással rendelkező rendszer komponensein felül, a másodikban meg idővel szépen felgyűlnek a lukak a konténer által nyújtott szolgáltatásban.
A fejlesztők - tisztelet a kivételnek - lehetőleg a holnap utáni verziót szeretnék élesben használni, ami fejlesztői szempontból érthető, de hosszú távon támogatható rendszer építése esetén nem biztos, hogy hatékonyabb.

> ami szerencsétlen esetben főverzióban bőven nem az, vagy nem az lesz, mint amit az alap OS szállítója támogat.

akkor milyen előnye van annak, hogy RH-t raktok konténerbe, ha pont azt, amire a támogatás van, lecserélitek?

> Nomostan ilyenkor vagy a fejlesztő veszi magára azt a feladatot, hogy követi az alkalmazásának az összes függőségét, foltozza a csomagokat, ha kell, vagy tojik rá - az ő általa írt kód működik.

ha egységes környezet van mindenhol (dev, prod, etc.), akkor:
- vagy a fejlesztőnél is security hiba van, mert a csomag ott is törhető
- vagy a prodban sincs ilyen

a fenti esetet csak az sj által fentebb vázolt, a dev csinal valamit, atdobja a falon az op-nak, hogy sok szerencset vele esetben tudom elképzelni - ami kimondottan szar, senki nem vitatja, hogy szar, s szerintem mindenki (legalábbis én, fejlesztőként, meg akit hallottam ilyet rendesen üzemeltetni) gyűlöli.

itt vagy nagyon elbeszélünk egymás mellett, vagy nem jött át, hogyan lenne jó ez a konténerezősdi.
--
blogom

A szolgáltatást támogatott, frissített komponensekkel kellene megvalósítani. De... A fejlesztői oldal nagyon sokszor prüszköl a "régi" csomagok miatt (főleg akkor, ha külső fejlesztőről van szó...), és ennek a problémának a "megoldására", vagy inkább megkerülésére szeretné tolni a konténerezést - azaz a fejlesztő átdob valamit az üzemeltetőnek scenario lenne számára az ideális.
Ahol ilyen a fejlesztői hozzáállás (azaz nem tud/akar alkalmazkodni a meglévő környezet adta lehetőségekhez), ott biztonsági, üzemeltethetőségi oldalról elő fognak kerülni a problémák. Ha normális a fejlesztői oldal hozzáállása, azaz elfogadják, hogy a megrendelőnél mondjuk RHEL7 van a production gépeken, és az abban lévő főverziókat kell használni minden komponensből (illetve az attól eltérő verziókra a fejlesztőnek/beszállítónak kell vállalnia a támogatást), akkor jól meghatározható esetekben príma tud lenni a konténerezés.

egy sulyos felreertes van a docker koncepciojaban (nalad). A docker image-ek (egyik) jellemzoje az immutable. Ezt azt jelenti, hogy kapsz egy image-et, es azt te nem modositod (technikailag ugyan megteheted, de erosen antipattern, es ugrott a supportod). Kijon egy sec/bug/... fix? Kapsz egy uj image-et.

Hogy eppen ki build-eli az uj image-et, az attol fugg, hogy hazon belul fejlesztik a benne futo app-ot, vagy egy 3. feltol veszitek/kapjatok. Ha ez utobbi, akkor a kulonfele bugfix-ek is a vendor feladata.

A masik feature, hogy pont ezert az mellekes, hogy ti eppen az rh-ba vagytok szerelmesek, az app fejlesztoje valaszt egy minel kisebb footprint-tel rendelkezo disztrot vagy esszeruen azt, amiben a kivant verzioju fuggosegek vannak (az xyz app kedveert ez legyen az ubuntu), es azt hasznalja fel.

Ha normális a fejlesztői oldal hozzáállása, azaz elfogadják, hogy a megrendelőnél mondjuk RHEL7 van a production gépeken, és az abban lévő főverziókat kell használni minden komponensből

most mar erted, miert vagy te is dino. A docker-rel (1. korben) csak annyit kell figyelembe vennie az image keszitojenek, hogy az RH 7-ben milyen kernel verzio van (ha olyan az app, hogy ez egyaltalan szamit valamit).

[A regi kernel (amit az RH 7 szallit) azert is szar, mert bizonyos docker feature-oknek, pl. memoria korlat beallitasa, kell egy min. kernel verzio, ami ugyan nem feltetlen showstopper, de elbukod az RH-hoz valo gorcsos ragaszkodassal].

Meg eleve: vannak docker-re kihegyezett disztrok, pl. core os (ahhoz is van paid support), igy megfontolando egy ilyen beemelese a ceges supportalt linux kornyezetek koze.

Tehát a konténerbe pakolt lomot "majd valaki" követi, figyelemmel kíséri, hogy mikor jön ki egy sérülékenység, azt mikor fixálják (Ha egyáltalán...)... Ez, ahogy írtam is, néhány függőség esetén elviselhető plusz teher - a számosságuk növekedésével viszont a követésre fordítandó idő/erőforrás is nő, amit valakinek csinálnia kell, és akit megint csak valakinek meg kell fizetni.
A fejlesztőnek, akit a megrendelő fizet azt kell figyelembe vennie, hogy a megrendelő mit, milyen feltételekkel, szoftverkörnyezetre kér. Ha valahol RHEL7 van, akkor nagy az esélye annak, hogy a legfrissebb Fedora-n klappoló alkalmazásod nem foga elnyerni a megrendelő tetszését.

A végén meg azt mondod, hogy a meglévő n OS/verzió mellé csak a Docker-es fejlesztés okán tessék felvenni egy (vagy több) másik disztribúciót is az üzemeltetett/támogatott listára...
Nomostan ahol RHEL vonal van, ott talán már kipusztultak, vagy sovány disznó vágtában most pusztulnak kifelé a RHEL5-ök, élesben mennek a 6-os meg a 7-es gépek, azaz három OS-verzió minimum van már, de legyen egy negyedik, meg egy ötödik is akár... Csak azért, hogy a Docker, meg a kényelemszerető fejlesztő igényeit ki lehessen elégíteni.

Ez, ahogy írtam is, néhány függőség esetén elviselhető plusz teher - a számosságuk növekedésével viszont a követésre fordítandó idő/erőforrás is nő, amit valakinek csinálnia kell, és akit megint csak valakinek meg kell fizetni.

nyilvan meg kell fizetni, ha te sem barati kezfogasert dolgozol.

Ha valahol RHEL7 van, akkor nagy az esélye annak, hogy a legfrissebb Fedora-n klappoló alkalmazásod nem foga elnyerni a megrendelő tetszését.

ez a megrendelo ostoba. De hadd mondjam el, en hogy csinalom. Ahany megrendelo, annyi kedvenc disztro. Nyilvanvaloan lehetetlen mindet tamogatni. Ezert a piler kapcsan kivalasztottam egy vallalhato disztrot, az ubuntu-t. Erre megirtam a dockerfile-t (benne a csillio fuggoseggel, pl. mysql (de abbol sem jo akarmelyik, hanem a mariadb-t szeressuk, a stock 5.7 nem jo), valamilyen webszerver, php 7, openssl, libzip, etc), amibol ossze lehet rakni a piler image-et.

A dockerfile elejen van egy apt-get update/upgrade, tehat (a fuggosegek) biztonsagi frissiteseihez mindossze ujra kell build-elni az image-et, utana lehet feltolni a docker hub-ra. Ez annyira eroforras igenyes, hogy akar automatizalni is lehet, mondjuk napi rendszeresseggel*.

*: nyilvan ha az integracios, whatever tesztek zoldek.

A végén meg azt mondod, hogy a meglévő n OS/verzió mellé csak a Docker-es fejlesztés okán tessék felvenni egy (vagy több) másik disztribúciót is az üzemeltetett/támogatott listára...

igen, erosen javallott. De a hoszton futhat a hon szeretett RH7 is egyetlen szolgaltatassal (=docker).

Nomostan ahol RHEL vonal van, ott talán már kipusztultak, vagy sovány disznó vágtában most pusztulnak kifelé a RHEL5-ök, élesben mennek a 6-os meg a 7-es gépek

nem ertelek. Amikor meg csak 5 volt, es kijott a 6, akkor megis miert vettetek fel a tamogatott lstara? Es ha mar igy lett ketfele is, mi volt a motivacio a 7 felvetelere? De ha mar ott a 7 is, miert nem szabadultok meg az 5-tol?

Csak azért, hogy a Docker, meg a kényelemszerető fejlesztő igényeit ki lehessen elégíteni.

ez csak a te szuklatokoruseged. De majd jobban megertelek a fentebbi kerdesre adott valaszod alapjan.

A megrendelő nem ostoba, ő fizetett valamiért, és azt használja, a fejlesztő megtessen alkalmazkodjon ahhoz, ami van. Hiába mész oda egy céghet, akik Oracle-t használnak, hogy de te meg tudod csinálni a fejlesztést MSSQL 2016-ra, nem lesznek rá vevők, úgy gondolom, hogy joggal :)

A docker image frissítése jó dolog, meg az is, hogy lehet így is csinálni. Én viszont azokra a komponensekre is gondolok, amit "valahonnan" szedve csomagol a cucca mellé a fejlesztő (ilyen is van sajnos), na ezekkel nem igazán lehet mit kezdeni.

A piler-rel kapcsolatban írod, hogy a mariadb-t szereti a cuccod. Mi van akkor, ha a megrendelőnél van egy jól összelőtt, szépen muzsikáló Galera fürt, és azt mondja, hogy tessen azt használni? (Ez egy Docker-től független kérdés volt)

Egy plusz szoftverkörnyezet támogatása, követése, a rigolyáinak kiismerése költség, méghozzá folyamatosan felmerülő költség, amit nem biztos, hogy mindenki szeretne megfinanszírozni.
Az 5 és a 6 egymás mellett voltak támogatott rendszerek a RH részéről, és a migrációk miatt természetes volt, hogy párhuzamosan kellett üzemeltetni. Az ötös életciklusának a legvége meg belelógott a hetes elejébe, amikor már hosszabb távra gondolva nem hatosra, hanem hetesre kerültek az új rendszerek, és ezzel párhuzamosan hullottak ki az ötös verziók.

a fejlesztő megtessen alkalmazkodjon ahhoz, ami van

ilyen is van, de erveleseddel szemben (ld. lentebbi kommentemet) pont ez noveli a vendor koltsegeit, es igy a te koltsegeid is.

Hiába mész oda egy céghet, akik Oracle-t használnak, hogy de te meg tudod csinálni a fejlesztést MSSQL 2016-ra, nem lesznek rá vevők, úgy gondolom, hogy joggal :)

bar csak igy lenne (uzemeltetoi oldalrol legalabbis), de nem feltetlen. Lattam madartavlatbol pl. a d**ksport szovetseg rendszeret, aminel a front end linux + php, mig a backend windows szerveren ms sql akarmennyi. Egy epeszu megoldas nyilvan valamilyen homogen rendszerert kialtana (pl. ms sql + iis + asp XOR lamp), de semmikeppen nem egy ilyen oszverert. Ne kerdezd, milyen kanyarok miatt lett ilyen a cucc, de egy biztos: nem feltetlen a megrendelo akarata ervenyesult, ha ez egyaltalan szempont volt. De az is lehet, hogy a megrendelo csak annyit mondott: mukodjon (mondjuk nem o uzemeltette, szoval konnyen hozhatott meg ostoba donteseket - ha valoban igy volt).

Én viszont azokra a komponensekre is gondolok, amit "valahonnan" szedve

irrelevans. Ha van ra supportod a vendortol, akkor neki kell megoldania, hogy minden komponens rendben legyen, opcionalisan mondjuk egy nessus scan eredmenyet melle csatolva igazolaskeppen. Neked meg mindig csak annyi a dolgod, hogy lefuttasd a sajat nessus scan-edet, whatever, es betartasd a szerzodest a vendorral.

Mi van akkor, ha a megrendelőnél van egy jól összelőtt, szépen muzsikáló Galera fürt, és azt mondja, hogy tessen azt használni?

Megnezem, hogy a galera rendben egyutt mukodik-e a piler-rel, aztan az alabbiak valamelyike:
- ha kompatibilis, akkor OK
- ha nem, akkor megvizsgalom, mekkora effort azza tenni
- ha vallalhato, akkor update, es OK
- ha tul sok macera, akkor kerek perec megmondom, hogy a galera nem tamogatott. Ha ragaszkodnak hozza, akkor ugrott a support, nem is akarok bug-okrol hallani.

Egy plusz szoftverkörnyezet támogatása, követése, a rigolyáinak kiismerése költség, méghozzá folyamatosan felmerülő költség, amit nem biztos, hogy mindenki szeretne megfinanszírozni.

de ez nem csak rad igaz, hanem a vendorra is. Pl. korabban kertek postgresql supportot, de annyira komplikalta a dolgot (nem talaltam olyan C sql wrapper lib-et, ami tamogatja a prepared statement-eket), hogy dobtam, igy maradt a mysql.

MSSQL - Java Linuxon felállást már láttam nem egy helyen - de legalább nem nekem kellett a DB-t rugdalnom :) Azt gondolom, közelednek a dolgok egymás felé (én is nézegetem, hogy hol tart most a Docker), de még azért nem vagyok 100%-ban meggyőzve arról, hogy ott, ahol a futó szolgáltatások/rendszerek döntő része nem alkalmas konténerezésre előnyős lenne bevezetni ezt a technológiát.

Szia,

Pár napja kezdtem el kipróbálni a docker-t Windows Server alatt, és pont a MySQL konténerekkel kezdtem, ami könnyen tesztelhető, toszogatható a gazdagépről. Ott akadtam el (én is), hogy az adatbázisokat vagy a host gépen, vagy egy storage-on kell tárolnom, szintén a konténeren kívül, ami igazából megöli az egész értelmét, bár ugye a konténer indításakor fel lehet csatlakoztatni az adatbázis(oka)t. Szóval odáig jutottam, hogy többe kerül a leves mint a hús (ez biztos az én hozzá nem értésem miatt van így)
Azért egy kész (W)AMP konténernek tudnék örülni :) Még jobban, ha meg is tudnám csinálni :)

Koti

Igen, en is azert kezdtem azokkal (bar en egy Ubuntu szerver alatt) mert 1. van belole kesz official MS docker image, 2. konnyen tesztelheto, hogy megy.

De a valaszokbol kiderult, hogy nincs nagy letjogosultsaga a dolognak :)

LAMP-ot szerintem siman ossze tudod hozni, WAMP nem tudom... szerintem minden elemenek van Wines image-e, ki kell probalni.

Bar ugye a ha jol ertelmezem, a kontenerezesnek pont az lenne a lenyege, hogy kulon szedd oket, nyilvan MySQL kiesik, ugyanaz miatt, mint az MSSQL, Apache+PHP-t meg nem tom van-e gyakorlati haszna szetszedni, talan...

Jo lenne valami lista, hogy milyen gyakorlati megvalositasok vannak Docker-el.

lol. Miert akarsz te docker-t? Egyaltalan miert te akarsz docker-t? Miert nem a lead architect/senior it akarki/etc donti el, mi legyen a csapasirany, es miert egy olyanra bizzak a dolgot, akinek fingja nincs rola (ez lennel te)?

Hogy ti mire es hogy tudnatok hasznalni, az erosen fugg attol, hogy mit es mekkora meretekben csinaltok, milyen techmologiakat hasznaltok jelenleg.

Kedves és épületes a hozzászólás első része :)
De hogy válaszoljak is: Szerintem a posztolónak is és nekem is ez csak személyes érdeklődés, nincs kőbe vésve a fejemben, hogy ezt szeretném használni, mert menő. Nem bízta rám sem senki. Ja és igen, belátom hogy nem értek hozzá, ezért kérdezek.
Próbálom feltérképezni, hogy mire lehetne használni a jelenlegi infrastruktúrában, vagy a jövőbeliben. Azt belátom, hogy a lista hülyeség, hiszen olyan image-et készítek és azt rakok bele amit szeretnék, bár én még nem tudom megcsinálni, de ez lenne a célom, hogy én is tudjak készíteni olyan docker image-et amilyet szeretnék.

Koti

Kedves és épületes a hozzászólás első része :)

valoban az, csak nem jutott el a tudatodig. Legalabbis neked. Ugyanis ha eszetlenul es fogalmatlanul (ld. a kerdezo) elkezdesz kontenerezni, annak siras lesz a vege. (OK, ha csak jatszani akarsz vele a gepeden, az mas). Ezert is kerdeztem, hogy miert akar docker-t, mert mar itt eldol, hogy sikersztori lesz belole vagy csufos kudarc (OK, az elobbi nem biztos, de az utobbi garantaltan).

Szerintem a posztolónak

majd a posztolo elmondja, nem vagy te az ugyvedje, sem a szovivoje.

Igen, en is csak erdeklodom, nincs konkret elkepzeles. Lattam ezt a "viszonylag uj" dolgot, amit eddig csak hallomasbol ismertem es elso korben ugy voltam vele, folmerem van-e
egyaltalan arra szukseg, hogy belemeruljek a temaba, szervezzek le oktatast a fonokommel stb... Ha nem lenne gyakorlati haszna, akkor csak penzkidobas...:)

A lista alatt nem azt ertem amugy, hogy "na itt egy lista a contenerekrol, ez erre jo, az meg arra" :) Inkabb olyan otleteket varnek, hogy volt egy ilyen, vagy olyan problemank es ezt dockerel igy oldottuk meg.

Igazabol valaszoltak ra, de ugy van, ahogy irtak. Jelenleg nincs konkret cel, vagy problema, amit meg kene oldani Dockerrel. Teljesen onszorgalom az egesz.

A cegunk nem egy fejleszto ceg, egy "sima" Multi vagyunk, az "IT" itt foleg Citrix XenDesktop+XenApp-ot, VMware-t, Egy csomo adatbazist es egyeb specifikus programot jelent (vallalatiranyitasi rendszer, tel. kozpont, kulonbozo beszallitok mindenfele spec, programjai, idonyilvantartas, epuletgepeszet, e-cimke, stb-stb...)

Valamint alap cuccok halozathoz (DNS, DHCP, AD, ez mind szigoruan Windows server alapokon)

( dotnetlinux | 2017. 04. 11., k – 08:24 )

Ugyanabban a cipőben jársz, mint én, kíváncsi vagy, hogy mire jó.
1. STATIKUS többszörözésre: amit egyszer összeraktál, azt több példányban el tudod indítani gyorsan, ha kell. Ad egy bázist, ami már konfiguráltabb, mint egy CentOS-minimal.iso és gyorsabb is indítani, pláne egy másik gépre áttéve.
2. Disztribúciós eszköz lesz belőle. Már most is van olyan, hogy valaki a termékét (lamp, wamp, rdp, stb.) nem "EXE-ben" adja át, hanem egy VM fájlt ad, amit elindítasz egy VMware vagy VirtualPC alatt. Ehelyett gyorsabb (jobb?) a dockerben átadott STATIKUS image.

Kicsit olyan, mint egy processzor. Gyárilag nem raknak bele OS-t, szoftvert, de ha kell bővíteni a gépet, akkor gyorsan bedobsz egy procit pluszba'.

Ha már MSSQL on linux: ne feledd, hogy ez is fizetős, attól, hogy linux :) Telepítéskor kiírja, hogy mikor jár le. Prod környezetben nem használnám, bár 3 enterrel feltelepül és Management Studioval be lehet lépni rá. De ez már a freetds óta megy :)

persze, tudom hogy fizetos, bar ha jol lattam, van express is.

Szerk: Most altom, Express csak windows platformra van...

Ahogy irtad is, tenyleg abban latom ertelmet a docker-nek, ha pl gyorsan kell valami pluszkiszolgalo. (el tudok kepzelni mondjuk akar egy automata scriptet is, ami pl megnovekedett terheles eseten automatikusan hozzaad preconfiguralt Apache+PHP dockereket)

"Statikus" kozegben nem nagyon tudom meg, hogy mire lenne jo. de probalok rajonni, nem maradhat megsem kihasznalatlan! :)

mire jo a docker? Felgyorsitja a folyamatokat. Pl. van egy dns szervered, es ha az atlag aladar adminok 95%-aba tartozol, akkor az bind-et jelent. Amit nem art rendszeresen update-elni a bug-jai miatt.

Hogyan tortenik ez docker eseten? Csinalsz egy image-et az uj bind verzioval, faszan kiteszteled, whatever, majd eljon az elesites napja. Ekkor leallitod a futo kontenert, lehuzod a legfrissebb image-et, majd elinditod az uj kontenert az uj image-bol.

De mi van, ha 1 oraval / 1 nappal / ... kesobb rajossz, hogy valami megsem koser, es kene az elozo bind verzio? Leallitod es eldobod a futo kontenert, majd inditasz egy ujat a korabbi image-bol.

A masik elonye a docker-nek, hogy immutable image-eket biztosit, amit bebi konnyu git-be / gerrit-be / etc. pakolni, annak minden elonyevel. Igy a dockerfile + valamilyen scm atfedest biztosit a konfiguracios cuccokkal (pl. ansible, puppet, etc).

( enpassant v | 2017. 04. 12., sze – 16:26 )

Egy kicsit próbálok segíteni a Docker megértésében.
Egy konténerben általában egy programot csomagolnak be az összes szükséges függőségével és konfigurációjával, de azért kívülről is tovább konfigurálható marad.
Az így összecsomagolt programot könnyen elindíthatod több példányban (akár egy gépen belül is), ezek egymástól elkülönülten (sandbox) fognak futni, mintha külön gépeken mennének.
Nagyon kicsi a plusz erőforrás igénye, alig több, mintha natívan futna az adott program a gépen.
Nagyon jó a fejlesztőknek, mert nem kell törődniük a cél (production) gépen futó egyéb környezettel, mert a szükséges környezetet ők állíthatják össze.
Emiatt nagyon jó az üzemeltetőknek is, mert szintén nem kell törődniük az egyes programok összeférhetőségével.
Az alap operációs rendszernek, ami a docker-be kerül, általában valami nagyon kis erőforrás igényűt választanak, pl. AlpineOS.
Pl. van egy JVM alapú web-es alkalmazásod, amihez kell mondjuk MongoDB. Ekkor becsomagolod a webes alkalmazásod egy olyan csomagba, amiben már benne van a JRE is, így önállóan futni képes. MongoDB-ből van gyári, akár használhatod azt is, de készíthetsz sajátot is. Elindítod a MongoDB-s csomagot (bekonfigurálva az adatbázis helye a gépen), majd elindítod a webprogram csomagot.
Ha több példányban akarod futtatni (minden kliensednek saját program és adatbázis), akkor indíthatsz több mongodb csomagot és több webprogram csomagot.
Ha skálázni akarod a programodat és úgy is van megírva, hogy lehet, akkor egyszerűen elindítasz pl. egy haproxy docker csomagot, majd a webprogramodból annyi példányt, amennyit akarsz (a haproxy-ba beregisztrálva). Így ha jönnek be sorban a kérések, akkor a haproxy szétdobja őket a futó programok között. Ha egyik programod lehal, akkor a többi szépen kiszolgálja a kéréseket.
Röviden és nagy vonalakban ennyi.

Eddig szép... De a fejlesztő által csomagolt MongoDB, vagy épp JVM bugjait ki fogja nyomon követni, ki fogja frissen tartani, ki fogja supportálni? Nem, ne mondd, hogy az alkalmazás fejlesztője, mert néha még a saját motyójának a hibáit se javítja, és/vagy az lesz a mondása, hogy "régi az xyz lib/komponens, frissebb kell". Aztán amikor azt mondja az ember, hogy nincs, mert az nem támogatott, akkor fel van háborodva...

> De a fejlesztő által csomagolt MongoDB, vagy épp JVM bugjait ki fogja nyomon követni, ki fogja frissen tartani, ki fogja supportálni?

A Docker leíró fájlt kell csak frissíteni, majd új csomagot készíteni.
Ezután lehet tesztelni az új motyót és production-be küldeni, de ez a része már ugyanaz, mint nem Docker-es esetben.
Ezt csinálhatja a fejlesztő is, meg az üzemeltető is, illetve sok esetben a fejlesztő egyben az üzemeltető is (devops).
Akár figyelheti az üzemeltető is és figyelmeztetheti a fejlesztőt, hogy célszerű lenne frissebbre váltani.

> az lesz a mondása, hogy "régi az xyz lib/komponens, frissebb kell". Aztán amikor azt mondja az ember, hogy nincs, mert az nem támogatott, akkor fel van háborodva...

Ezt a részét nem igazán értem. Mit értesz azon, hogy a frissebb komponens nem támogatott?
Ha ezt, amit egy korábbi hozzászólásnál írtál: a megrendelőnél mondjuk RHEL7 van a production gépeken, és az abban lévő főverziókat kell használni minden komponensből

Akkor pont az ilyen gondokat oldja meg a konténerezés, mert teljesen mindegy, hogy mi van a megrendelőnél, nem függ az azon levő komponensektől, csak más konténerektől illetve a saját konténerében levő függőségektől.

Akkor máshogy kérdezem... Az egyedi komponensek javításait ki fogja követni, figyelemmel kísérni? Egy-két komponens esetén még elmegy, de minél több saját függőséget rak bele a konténerbe a fejlesztő, annál nehezebb lesz a dolog.
A konténerezés nem korrigálja azt, hogy a fejlesztő nem az adott környezetre, hanem saját mondjuk "hasraütéssel" választottra fejleszt - csak ad egy workaroundot arra, hogy gyakorlatilag bármilyen 3rd party kód futhasson egy jól meghatározott sw-környezet helyett. Anno amikor fejlesztési vonallal komolyabb kapcsolatban voltam, volt egy jól definiált lista, hogy milyen szoftverkomponensek vannak, amiket lehet/kell használni.

Ez ugyanaz a problematika kör, mint egy program komponenseinek köre.
Pl. egy Java-s program kis millió külső könyvtárat használ, ami becsomagolva kerül átadásra az ügyfélnek. Ezt általában a fejlesztő cég állítja össze, figyel a licencekre és ezen komponensek frissítésére. Ezen komponensek listáját természetesen át szokta adni az ügyfélnek.
Ebből a szempontból nem nagyon látok különbséget ezen komponensek és a dockerben használt komponensek kezelésében.

Csak lassan oda jutunk, hogy a fejlesztő komplett OS-sel együtt adja az alkalmazást, hozzá a támogatást - amire vagy van elég erőforrása, vagy nincs, vagy supportálja a motyót mondjuk 5 évig, vagy sem, vagy lesz aki javítja ez alatt a 3rd party komponensek hibáit, vagy sem...

pedig ertelmes keretek kozott mukodik a dolog. Barmilyen kicsit is komolyabb cuccrol van szo, van neki system requirements szekcioja a doksiban. Pl. a vmware megoldasa minden hw-t tamogat? Aligha. Vagy van olyan cuccotok, amihez oracle db/rac/... kell, es pont? Biztos lattal mar te is ilyet.

Szoval a jelenseg letezik...

> Viszont ez kellően masszív árnövelő tényező lesz

Mert az szerinted nem kellően masszív árnövelő tényező, hogy:
- a szoftvert (ha dobozos szoftver) minden helyen a helyi specialitásokra kell reszelni
- a teljesen nem difiniálható* környezetből fakadó bugokat kell vadászni

*: persze, RHEL7. csak aztán ilyenkor általában elfelejtik közölni az üzemeltetéstől, hogy ja, ez egy sokéves rendszer, és van rajta ilyen, meg olyan special konfig a másik alkalmazás miatt. Jó esetben van még ott valaki, aki látta azt a gépet települni, s végig tudja követni nagy vonalakban az életét.
--
blogom

Értelmes helyen nem karácsonyfát csinálnak a szerverből... Az, hogy sok éves egy rendszer, az egy dolog - a szoftverkomponensek főverziói adottak végig, ami nem hátrány. Persze létezett olyan is, hogy az alkalmazásba beégetett baromság miatt például egy régi "ls" parancsot kellett felmásolni a helyes működéshez, és beállítani, hogy az alkalmazás azt lássa előbb, ne a frisset - igaz, ezzel szépen bukta az uid/gid - user/csoportnév leképzést, mert a régi kellően buta volt ilyen téren...

A konténerezés nem korrigálja azt, hogy a fejlesztő nem az adott környezetre,

hint: a kontener a jol definialt kornyezet, pont ezert gyerekjatek azt ugy osszerakni es leszallitani, hogy rendben mukodjon, minden a helyen legyen. Mert ugyan kinek jutna eszebe centos 5.9-es image-re epiteni, ha pl. eleg friss libzip verzio kell?

Nem a régi verziókkal van gond, hanem azokkal a komponensekkel, amikből a támogatottnál újabbat rak a konténerbe, amikhez kapcsolódó biztonsági hibákat, javításokat külön kell követni. Na ezeket szokták idővel "elfelejteni" a fejlesztők,pláne akkor, ha már a fejlesztési időszak után, élesben van az alkalmazás, és annak a működését kell támogatni.
Nem egy, nem két olyan rendszer volt a kezem alatt, ahol a szállító explicit kijelentette, hogy a rendszer bizonyos komponensei, vagy épp a teljes OS nem frissíthető, és pont. Aztán persze volt olyan is, hogy kellően kitartóan érvelve amellett, hogy de basszus ugyanaz a lomotok fut 8.3, 8.4, 8.9 meg 8.13 alatt is élesben, a legutolsó teszt meg 8.26-on, és sehol nincs gond, úgyhogy érdemes lenne a 8.26-ra felhúzni mindent... Ez mondjuk sikerült, de volt olyan is, ahol teljesen elzárkózott a fejlesztő a frissítésektől. És ebben a formában mindegy, hogy a supportált csomagból nem enged/akar újabbat felrakni, vagy épp az általa szállítottból nem ad/akar/enged újabbat használni a konténerbe(n).

Na ezeket szokták idővel "elfelejteni" a fejlesztők,pláne akkor,

csak kivancsisagbol: hany docker konteneretek megy production-ben?

Nem egy, nem két olyan rendszer volt a kezem alatt, ahol a szállító explicit kijelentette, hogy

en is lattam mar igen szar szerzodeseket, szoval nem hibaztatlak. De ez meg mindig nem technologiai problema, hanem nalatok valakit megvett kilora egy bvfh (bastard vendor from hell), aztan meg minden patch szerdan analis rape-et csinal rajtad a soderes repajaval. Mondom, ez nem a docker vagy eppen akarmilyen virtualizacio, whatever hibaja.

Hála az égnek egy sem, mert amit anno (máshol) teszteltem, az _még_ messze nem volt meggyőző. Ha meg nem olyan a rendszer felépítése, hogy igényli és támogatja a Docker nyújtotta "rugalmasságot", mert pl. dokumentumkezelés (pdf fájlok tömkelege) a rendszer egyik feladata, akkor hála az égnek nem kell ezzel foglalkozni.

En nem akarom vedeni a dockert meg vannak a sajat probelmai amikkel persze szivunk is de tudjuk kezelni. Van egy 1000+ containeres rendszerunk persze sajat SaaS szoval viszonylag nagy tapasztalat van ezen a teren. A security-re visszaterve amugy pontosan tudjuk kb. melyik containerbe milyen biztonsagi hibak vannak. ScreenShot

Ha Te oldaladon ulnek akkor igen nekem is lennenek ketsegeim de igy mindig konyebb kezelni a fejlesztoi kereseket mint maskepp.

Persze SaaS/Startup vilagban inkabb a fejlesztok kiszolgalasa a feladat es a segitese plusz a termek haladjon elore mintsem az ,hogy mennyi idot toltunk egy-egy security problemaval. Plusz nalunk fontos az automatizacio es a docker szamunkra ebben segitseg.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

+1, van, ahol, és amire jó lehet, de nem mindenre és nem minden méretben. Anno az iwiw alatt fizikai vasak voltak, és nfsroot-ról kapták az alapot, a bootp-n meg kernel paraméterben, hogy mi lesz a feladatuk, és annak megfelelően húzták magukra szintén nfs-ről az egyes szolgáltatásokhoz szükséges könyvtárakat, beállításokat.
Erre például baromira jó lett volna a Docker - ha lett volna anno, de nem volt, úgyhogy egy ilyen megoldás lett kitalálva, még bőven azelőtt, hogy arrafelé keveredtem :)

csak csendes jelzés, hogy van aki érti a kétségeket :)

(mondom ezt úgy, hogy épp azzal tökölök, hogy hogyan lehet rendesen előállítani docker imageket, és kerülgetem az olyan vicceseket, hogy nem lehet template a dockerfileban, mert immutable -- miközben természetesen mind latest mozgó célpont, mind az, hogy a random apt-get update honnan mit húz be, én meg sedelhetem bele a dockerfileba, hogy pontosan melyik imageről kéne indulni, ha szeretném, hogy tényleg immutable legyen)

Ja. Csak a dockerfile a fromban nem enged env variablet, vagy akármit (én pl most a @sha hasnel kötöttem ki, mert több okból lehet uj image, nem jo a commit nativan), de ezt "kézzel" kell beletenni, mert a sok gyökér megmagyarázza, hogy ha az parametrizálható akkor nem lesz mindig ugyanolyan. Nyilván meg tudom csinálni, csak idegesítő, hogy ilyeneket kell kerülgetni,mert valami (fogalmatlansággal megspékelt) ideológiai hablaty miatt nem tudja a tool.

ne mondd, hogy az alkalmazás fejlesztője, mert néha még a saját motyójának a hibáit se javítja,

szoval vesztek csillio penzert hw supportot a gepeitekre, rh licenceket ipari mennyisegben az OS supportert, tan meg az rhc* cert-ekbe is oltok nemi suskat, es sikerul olyan szerzodest kotni xy-nal, hogy ne kelljen supportalni a cuccat?

( sj | 2017. 04. 12., sze – 20:30 )

egy masik alkalmazasi lehetoseg: szuksegem volt egy artifactory-ra. A) lehetoseg: csinalsz egy VM-et, es elkezded installalgatni, ami ehhez kell. B) terv: A jfrog-nak van egy docker.bintray.io/jfrog/artifactory-oss nevu image-e a docker hub-on, lehuztam, elinditottam. De kene neki egy http proxy is. Szerinted docker-ben fut az nginx vagy csinaltam neki egy virtualis gepet?

Szoval 2 docker kontenerrel egyutt is csak azert volt az egesz 15 perc, mert jatszottam az artifactory-val, mit, hogy es merre kell rajta beallitani. Virtualis gepeket hasznalva jelentosen tovabb tartott volna a muvelet. Igy meg koszoni a cucc, jol elketyeg mar 3 hete.

Az allitolagos csillio cucc az en esetemben igy nez ki:

# docker top armproxy
PID USER TIME COMMAND
7979 root 0:00 nginx: master process nginx
8019 xfs 1:40 nginx: worker process
8020 xfs 2:10 nginx: worker process

# docker top arm
PID USER TIME COMMAND
1841 root 0:00 /bin/sh -c /entrypoint-artifactory.sh
1884 1030 0:00 {artifactory.sh} /bin/bash /opt/jfrog/artifactory/bin/artifactory.sh
2035 1030 88:50 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Djava.util.logging.config.file=/opt/jfrog/artifactory/tomcat/conf/logging.properties ....