ugrás a tartalomhoz

docker vs lxc

mind1 valami név · Jan. 4. (P), 11.05
Láttam, hogy többen használjátok a dockert. Van köztetek olyan, aki az lxc-t is ismeri? Ezek milyen viszonyban vannak egymással?
Annyi "tiszta", hogy a docker az kb. arról szól, hogy egy app/konténer és a konténer addig él, míg az applikáció. Az lxc konténerben több applikáció is futhat, valahol egy chroot és egy virtuális gép közt van.

Viszont amennyire emlékszem, az lxc konténerek update-elése belülről is mehet talán (bemegyek a konténerbe és mondjuk debian esetén egy apt-get upgrade-del letudom a dolgot), míg a docker esetében, ha jól értem, a karbantartóra kell várnom, hogy az image-et update-elje, csak utána tudom lerántani magamhoz a javított verziót.
Ez tényleg így van?
Ha így van, ez jó dolog éles környezetben, hogy esetleg több napos késéssel jön meg egy biztonsági javítás?

----
Mondjuk felmerültek bennem olyan apróságok is, hogy ha van egy webes applikációm, amihez tartozik web szerver, RDBMS, reverse proxy valami middleware (mondjuk egy komolyabb MQ szoftver), az kapásból négy-öt konténer, amiket már nem annyira egyszerű kézben tartani külön management szoftver nélkül.
(asszem, janoszen írta valahol, hogy ha kettőnél több konténer, akkor már kell valami management cucc föléjük)
 
1

Az LXC illetve a Docker is

MadBence · Jan. 4. (P), 13.38
Az LXC illetve a Docker is alapvetoen izolaciot biztosit az alkalmazasok szamara (korabban a Docker egyebkent LXC-t hasznalt, mint kontener backend, illetve lehet hogy ez meg minding tamogatott). Ahogy en tudom, sok kulonbseg nincs a ketto kozott.

Az hogy te hogyan strukturalod az alkalmazasod, az a te dolgod, a kontener lehet egy teljes ubuntu image amiben tobb alkalmazast futtatsz, de akar egy darab binaris allomany, ami minden fuggoseget statikusan linkelve szallit.

Ha ubuntut hasznalsz mint "base" image, akkor az egy ubuntu, nem kell "varnod" semmire, akkor buildeled le ujra az alkalmazasod, amikor akarod (apt-get upgrade meg minden egyeb ugyanugy mukodik, mintha ott ulnel egy teljes erteku ubuntu elott). Folyamatos frissitgetes helyett (mellett) egyebkent inkabb erdemes megszabadulni a lehetseges tamadasi feluletektol.

Docker kontenerbe futas kozben is be tudsz kukkantani, es ha akarod tudod frissiteni, de minek veszodni ezzel, a kontenerek egyik nagy elonye, hogy "eldobhatoak", barmikor ujra kene oket buildelned (ami mar a frissiteseket is tartalmazza).

Igen, tobb kontener mar bonyolultabb tud lenni, de valoszinuleg egy docker-compose is tokeletesen megfelel a nagy atlagnak.
2

Köszi. Azért az, hogy mit

mind1 valami név · Jan. 4. (P), 14.21
Köszi.
Azért az, hogy mit tudok tenni a docker konténerben, erősen függ ezek szerint az image-től is.
Amivel legutóbb próbálkoztam (talán python:3-alpine - de nem biztos), abban még ps sem volt, hogy a processzlistát megnézzem.

A támadási felületektől való megszabadulás alatt nem tudom, mit értesz... én úgy láttam, hogy "official image" van a legtöbb dologhoz, csak mit csinál aki mondjuk egy nginx konténert futtat és pon abban találnak valami veszélyes hibát?
3

Igen, az alpine-alapu

MadBence · Jan. 4. (P), 14.38
Igen, az alpine-alapu image-ek lenyege, hogy baromi kicsik, python eseten tenyleg csak es kizarolag annyit tudnak, hogy pythont futtatnak. Persze van valamennyi flexibilitas, apk-val fel tudsz tenni olyan dolgokat, amikre szukseged lehet (git, etc).

Ha egy kontener tele van mindenfele folosleges dolgokkal (pl. openssh szerver, amikor te egy sql adatbazist szeretnel csak futtatni), akkor az openssh egy tamadasi felulet. Ezt a felismertek a karbantartok is, ezert szoktak ezek az "official" image-ek meglehetosen lebutitottak lenni.

Erdemes megnezni egy-egy tenyleges base image Dockerfile-jat. Pl. itt egy ubuntu. Tenyleg annyi tortenik csak, hogy egy ures (FROM scratch) kontenerbe kitomoritenek egy friss ubuntu image-et, nem rakosgatnak fel semmit extra dolgot.
5

Az Alpine még jobb:

inf3rno · Jan. 5. (Szo), 08.23
Az Alpine még jobb: link
FROM scratch
ADD rootfs.tar.xz /
CMD ["/bin/sh"]
6

Egyébként érdemes Dockert

inf3rno · Jan. 5. (Szo), 08.26
Egyébként érdemes Dockert Vagranttal együtt használni, vagy ez csak olyanoknak jó, akik már megszokták, hogy Vagranttal telepítenek mindent?
7

Szerintem nem

Pepita · Jan. 7. (H), 08.08
Mondjuk én Vagrantot csak nagyon rövid ideig (és muszájból) használtam, de amennyire meg tudom ítélni, Dockerrel több lehetőséged van, legfeljebb szintaktikában van némi eltérés.
Tök feleslegesnek tartom egy plusz réteg beékelését csak megszokásból.
10

Nézegettem én is, nem igazán

inf3rno · Jan. 7. (H), 14.16
Nézegettem én is, nem igazán látom értelmét. Az jött lett most a Vagranttal kapcsolatban, hogy mióta van docker, azóta inkább csak arra jó, hogy pl asztali alkalmazásokat teszteljél eltérő oprendszerek alatt, vagy esetleg hogy több böngészőben meg tudd tesztelni a weboldaladat. Egyik se érint túlzottan, úgyhogy nem foglalkozok vele, marad csak a docker helyette fejlesztői környezethez. Azoknak lehet jó, akik virtuális gépekkel csinálták régebben, aztán már megszokták.
8

Közben annyit megnéztem, hogy

mind1 valami név · Jan. 7. (H), 08.39
Közben annyit megnéztem, hogy az alpine tartalmaz ps-t. A python:3-alpine is. Marad az nginx... :)
11

No majd ha nagy Alpine guru

inf3rno · Jan. 7. (H), 14.18
No majd ha nagy Alpine guru leszel, akkor segíthetnél nekem is egy kicsit. Egyelőre még nem aktuális, de néhány hónap múlva én is azzal a disztróval fogok szórakozni egy sort.
12

Hát kicsi a valószínűsége,

mind1 valami név · Jan. 7. (H), 15.00
Hát kicsi a valószínűsége, hogy guru legyek, de mi a kérdés? ;)
A docker-ben elég szépen működget, fizikai vasra biztosan nem tenném, de háromszor meggondolnám azt is, hogy virtuális gépbe telepítsem. :)
13

Egyelőre még semmi, majd csak

inf3rno · Jan. 7. (H), 16.40
Egyelőre még semmi, majd csak lesz kérdés. :-)
4

Kérdeztem már régebben én is.

inf3rno · Jan. 5. (Szo), 08.08
Kérdeztem már régebben én is. :-)
9

Docker management

Pepita · Jan. 7. (H), 08.52
Ahogy Bence is írta, többnyire elég a Docker saját composere, szépen össze lehet linkelni vele "mindenkit", mountolni, stb.
Onnantól kezd érdekessé válni a helyzet, amikor mondjuk a web szerverből (vagy külön alkamazás - konténerből) egyszerre több példányt kell futtatni, terheléselosztással. Akkor kell fölé vmi load balancer.

Lxc-t nem ismerem, Dockerrel kapcsolatban pár dolgot azért tisztáznék.
a docker az kb. arról szól, hogy egy app/konténer és a konténer addig él, míg az applikáció.
Inkább azt mondanám, hogy egy szolgáltatás / konténer, de ez sem kőbe vésett törvény, viszont ajánlott.
Pl egy egyszerű LAMP szervert is meg lehet csinálni egyetlen konténerben is, de célszerű legalább a MySql szervert külön venni, akkor már lesz egy Apache-PHP konténered és egy MySql. Ha esélyes, hogy több példányt szeretnél majd az alkalmazásból, akkor máris kikerül a PHP is (pl fpm). A lényeg, hogy annyira érdemes szétbontani, ami a majdani éles üzemeltetés szempontjából a legoptimálisabb.

Futó Docker konténerbe is "be tudsz nézni", telepíteni / update-elni amit szeretnél, de amikor újra buildeled, csak az lesz benne, amit az image tartalmaz. Magyarul futásidőben ki tudod próbálni, amiket szeretnél, majd ha meg van a döntés, hogy mi hogy legyen, ezeket szépen beírkálod az image-be, rebuild és teszt.

a docker esetében, ha jól értem, a karbantartóra kell várnom, hogy az image-et update-elje
Bármikor eldobhatod a konténeredet, image-t és rebuildelheted. Az lesz benne, amit a dockerfile leír. Többnyire érdemes egy "hivatalos" image-ből kiindulva saját igényed szerinti konténereket építeni. Ha pl a te image-ed ubuntu:latest - ből származik, akkor arra kell várnod, hogy a "karbantartó" feltegye az újonnan kijövő ubuntu image-ét. Ez többnyire igen hamar megy.

Ahogy Bence is írta, az alpine image-ek fő tulajdonsága, hogy kicsik, mondjuk sok más image-re is igaz, hogy csak a legszükségesebb dolgokat tartalmazza.
Én leginkább Apache-PHP-MySql-Memcached-még pár "extra" konténereket használok, ezeknél is azt tapasztalom, hogy mondjuk egy php:7.2-apache - ból kiindulva a saját Dockerfile-om lesz 50 - 100 sor, mire minden számomra szükséges extension és beállítás is benne van. Szóval a "hivatalos" image-ek kiindulásnak nagyon jók, de többnyire kell hozzájuk tenni ahhoz, hogy neked is jó legyen.

SZERK.: kimaradt az élettartam. :)
A Docker konténered addig "él", amíg le nem törlöd. Az image-ed úgyszintén, illetve ha változik az "őt" leíró dockerfile, akkor rebuild esetén változik az image és a konténer is.
Tehát csak rajtad múlik, hogy meddig "él", bármikor nyugodtan eldobhatod. (Ha csak egy konténert törölsz, a tárlolt image-ből pillanatok alatt létre lehet hozni újra, nem kell mindig nulláról buildelni, sőt, rebuild-kor is felhasználja az előző build során cachelt - és használható - köztes image-eket.)