Docker megbízhatóság -vs- LXC

Linux-haladó

Sziasztok!

Több mindent olvastam a Dockerről, elmondom, hogy hol tartok, nyugodtan cáfoljatok meg, ha valamit máshogy gondoltok vagy tudtok:

- A. - Docker-nél érdemes mindig megadni -m kapcsolóval, hogy mennyi memóriát használjon maximum a konténer, ha elszállna a konténer, ne rántsa magával az egész rendszert, hogy korlátlanul elkezd swap-elni, majd betelik akár.

- B. - alapból 1024 a cpu limit -c 1024, és ha 256-ot adok meg, míg más esetben nem adom meg, akkor ilyen arányban tudom megadni, ha több konténer fut a CPU-k elosztását. Tehát ha fut 2 konténer, ahol a CPU limit 512, és fut 1 konténer, ahol nincs megadva (ami 1024), akkor 4 mag esetén az első két konténer kap 1-1 magot, míg a harmadik kap 2 magot, jól értem?

Kérdéseim:

- 1.: Production, nem teszt felhasználásra mennyire megbízhatóak a mások által készített csomagok? Hol olvashatok róla, ha valami baj van a készítővel, vagy a csomaggal?

- 2.: Jól értem, hogy csak olyan csomagot érdemes választani, ami AUTOMATED, tehát jön hozzá frissítés, ha van olyan, amihez nincs?

- 3.: Mi van akkor, ha valami kártékony kód kerül a konténerbe egy frissítés alkalmával? A mások által feltöltött konténereket ellenőrzi valaki?

- 4.: Mennyire érdemes nekem magam elkészíteni a konténereket, ha van pont olyan készen, ami kell?

- 5.: Van-e olyan megoldás, amikor érdemes lenne LXC-t használni, mert a Docker nem a legjobb megoldás?

- 6.: Ha CentOS 6 a host, csak CentOS 6-ra készített Docker konténereket ajánlott és érdemes használni, vagy lehet CentOS 7 is, vagy bármilyen mást host-ra készített 64 bites konténer?

- 7.: A Docker az LXC-hez képest mennyi overhead-et okoz teljesítményben?

- 8.: Ha kell nginx és több változatú PHP, akkor az nginx is külön konténer, a PHP-k is külön konténer, és így érdemes felépíteni?

- 9.: Mi a legjobb megoldás arra, ha több OpenVPN-t szeretnék futtatni: legyen egy kiválasztott konténer, és fusson több példányban, más paraméterekkel, vagy legyen több külön konténer?

Köszönöm.

  • 3131 megtekintés

( janoszen v | 2014. 12. 04., cs – 11:43 )

Alapvetoen azt kell elmondani, hogy mind az LXC mind a Docker ugyanolyan biztonsagos: amilyenre konfiguralod. Mindketto ugyanazokat az API-kat hasznalja a kernelben, a Docker raadasul kepes az LXC eszkozoket hasznalni a kozvetlen kernel hivasok helyett.

1. En hasznalom, sokan masok is. Debian alatt legutobbi infoim szerint nem volt olyan kiraly, Ubuntu alatt egesz jol ment.

2. Ugye itt a CLI toolokrol beszelunk, nem a kernel-beli funkciokrol. Ha biztonsagra vagysz, akkor a kernelt kell rendszeresen frissiteni.

3. Alapvetoen a par alap containeren kivul (ubuntu, ubuntu-cloud, stb) nem erdemes mast valasztani. Telepits magadnak cuccokat ra, ne hasznalj kesz eszkozoket. Mar csak azert sem, mert akkor hogy uzemelteted?

4. Dockerrel rem egyszeru, LXC-vel meg... oprendszert kapsz, ugy mukodik mint egy virtualis gep.

5. Igen, a Docker csomo okossagot csinal, amire neked adott esetben nincs szukseged. Ha sima oprendszerre vagysz mindenfele egyeb okossag nelkul, akkor LXC

6. Ha jol tudom, eleg jol mukodnek egyutt, de en leginkabb Ubuntut hasznalok Ubuntuval, ugy tuti nincs problema.

7. A filerendszer lassabb a plusz okossag miatt, IO intenziv cuccokat ne tegyel ra.

8. Ahogy jonak erzed. :) En jelenleg smallwebs szervert epitek Dockerrel ami minden "tarhelynek" ad egy sajat Apache-ot sajat PHP-val, igy eleg konnyu eloallitani kulonbozo verziokat.

9. En egy sima Ubuntu containerben futtatok OpenVPN-t, azon belul tobb OpenVPN szervert. Az Ubuntus csomag szepen tamogatja a tobb szervert. Nyilvan valoan kulonbozo porton, stb. kell figyelnie.

--
Pásztor János
Üzemeltető Macik

4. Dockerrel rem egyszeru, LXC-vel meg... oprendszert kapsz, ugy mukodik mint egy virtualis gep.

hatttooo, virtualis gep != kontener.

6. Ha jol tudom, eleg jol mukodnek egyutt, de en leginkabb Ubuntut hasznalok Ubuntuval, ugy tuti nincs problema.

barmilyen Linux lehet a kontenerben (az azonos architektura, pl. x64, azert kovetelmeny)

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( Cajga | 2014. 12. 04., cs – 12:34 )

Sosem probaltam production-ben hasznalni Docker-t csak jatszadoztam vele kivancsisag vegett.
Ha en jol ertettem, akkor a Docker "mas szinten" mukodik mint az LXC igy osszehasonlitasuknak nem sok ertelme van (hacsaknem Dockerben akarsz full OS-t futtani bar nem erre talaltak ki).
A Docker hasznalhat LXC-t (userspace toolokat) a container kezelesre (regebben az volt a by default) de mostmar sajat libcontainer-je van: http://www.infoq.com/news/2014/03/docker_0_9

En ebbol a cikkbol olvastam utana (alapoknak eleg jo sztem):
https://access.redhat.com/articles/881893

( KaTT v | 2014. 12. 08., h – 09:36 )

Alapvetően, ha DRBD-re akarok szolgáltatásokat rakni (MySQL, Nginx, Postfix, OpenVPN, PHP, Perl, Python), ha elszáll az egyik gép, elindulnak a szolgáltatások a másik gépen. A Docker vagy LXC irányt javasoljátok? Érdemes keverni a kettőt?

Az eredeti terv, hogy LXC lesz. Az LXC alapvetően tetszik.

Mi az, ami Docker-ként kevésbé "szép", mint LXC-vel?

Mi az, ami LXC-vel túlbonyolított és nyilvánvalóan jobb rá a Docker?

Sakk-matt,
KaTT :)

Ha ilyet akarsz epiteni, akkor en mindenkepp LXC-znek, mert a Docker filerendszere arra van kitalalva, hogy inkrementalis valtozasokat taroljon, ergo csomo konyvtarban szet van szorva az egy gephez tartozo adat. Effektive nincs egy "filerendszer". Biztos ki lehet kapcsolni, de akkor pont a Docker ertelmet veszed el.

--
Pásztor János
Üzemeltető Macik

De azt nem is kell, pont az a lényeg, hogy ha kell egy új instance akármilyen okból, akkor az az image registry-ből példányosítható. A Docker containerek normál "root fs"-ét, ami AUFS felett van, én nem is a DRBD fölé tenném emiatt, hanem az simán lehet gép lokális.

Ez persze más szemlélet, mintha a konténereket mini-VM-ként használnánk, ahol fontos az, hogy az egyik fizikai host szétesése esetén ne backupból kelljen újrahúzni, hanem csak indítani a másik hoston.

Az adott feladatot szerintem meg lehet csinálni mindkét módon, a fő kérdés, hogy aki csinálja, melyik működési módot érzi közelebbnek magához.

Én a szinkronban tartást oldom meg a DRDB-vel.
Failover esetén pedig elindulnak a második (, vagy N-edik) gépen az LXC-s szolgáltatások, ami mind DRBD-n van, azonos OS-en.

Ennél nem tudtam jobb megoldást a jelenlegi tudásom alapján, amelynek egy részét az itt és máshol olvasottakból merítettem. Kész elemekből építkezni könnyebb, mint új elemeket kivitelezni, ami nem is célom jelenleg.

Nagyon tetszik a Linux és a nyílt forráskód átláthatósága, testre szabhatósága, rugalmassága, szemben a Windows iránnyal, amikor valami elszáll és nem lehet tudni, mi a megoldás,mert nem lehet kideríteni hagyományos keretek között.

Sakk-matt,
KaTT :)