ugrás a tartalomhoz

Docker "kedvesség" - process limits

mind1 valami név · Jan. 9. (Sze), 10.14
Ez de fura... a szerveremen nem tudom honnan, be van állítva egy default process limit a usereknek:
ulimit -u
30784

Én úgy tudtam, hogy ez unlimited by default, de most olvasgatva úgy tűnik, az unlimited egy Debian specialitás, egyébként a kernel beállít egy alapértéket. (ettől kezdve nem értem, hogy működhet a fork bomb nevű poén)
No mindegy, a minap az androidos telefonomat sikerült kiakasztani egy ilyen fork bomb segítségével, hogy kis híján a szervizben kötött ki :D
Most docker konténerben akartam kipróbálni, de biztos-ami-biztos inkább megnéztem a konténer limitjeit. És itt jött a meglepetés: a host minden processzének be van állítva limit, kivéve a docker konténert. A konténerből simán megfektethetem a hostot is egy ilyen fork bomb segítségével...
Nem gáz ez egy kicsit?

Update: O.K., lehet limitet adni a konténernek, de ha külön nem gondoskodom róla, akkor bizony limitálatlanul rohangál...
 
1

Valószínűleg még a limit

inf3rno · Jan. 9. (Sze), 11.25
Valószínűleg még a limit elérése előtt elfogy a memória, vagy ilyesmi miatt működhet. Azt írják, hogy minden userre kell limiteket beállítani, akkor nem lehet nagy gond.
2

Sajnos a fork bomb az nem

mind1 valami név · Jan. 9. (Sze), 11.43
Sajnos a fork bomb az nem ilyen állatfaj. Előbb döglik meg a rendszer, mint ahogy elfogyna a memória. Ez benne a poén.
Amit viszont gázosnak tartok a magam részéről, hogy a docker ignorálja a rendszerben beállított limiteket akkor is, ha user mapping segítségével más user alatt fut a root-ja is.
A konténer indításakor (esetleg valahol konfigban?) kell megadni a konténerre vonatkozó limiteket. Ha ez elmarad, akkor a hoston hiába van bármi beállítva, kifekteti a jelek szerint.

Ha van beáldozható virtuális géped (nem konténer), próbáld ki ezt shellből:

:(){ :|: & };:

Ha a usered process limitje (ulimit -u) "unlimited", akkor pár másodperc alatt megdöglik a gép, csak a ki-/bekapcs segít rajta.
Ha simán indítasz mondjuk egy olyat, hogy "docker run --rm -it alpine" és abban próbálod ki, akkor azt hiszem, a host-odat fogod kinyírni vele, nem a konténert.
3

Kipróbálni nem tudom, de

Pepita · Jan. 9. (Sze), 12.58
igencsak érdekelne az eredmény. Ez akár egy szép kis bugreport is lehetne.
Ha simán indítasz mondjuk egy olyat, hogy "docker run --rm -it alpine" és abban próbálod ki, akkor azt hiszem, a host-odat fogod kinyírni vele, nem a konténert.
Ezt kéne tudni a hit helyett. :)
Mondjuk személy szerint én nem aggódom miatta fejlesztői környezetben, de éleset üzemeltetőknek nagyon érdekes lehet.
Windows alatt - ahogy én fejlesztek - nem nagy ügy a linuxos "gazda" VM-et is restartolni ha muszáj, magától a gazdagéptől pedig korlátozott a CPU, RAM, storage, amivel gazdálkodhat.
Amíg úgy fejleszt valaki, hogy csak az épp aktuális projekt konténerei futnak és nincs "közös" konténer projektek között, addig dev környezetben nem para.
Élesben viszont simán megfekteti így egyik alkalmazás az összeset - ha valóban a hostot nyírja ki.
4

Hát konkrétan megjelent

mind1 valami név · Jan. 9. (Sze), 14.21
Hát konkrétan megjelent párezer(!) processz a hoszton. Csak nem vártam meg, hogy megdögöljön a host, még előtte lelőttem.
Viszont a /proc alatt látszik, hogy a docker konténer processzlimit nélkül fut.
Nem hinném, hogy bugreportra érdemes, végülis a dockert nem analfabétáknak találták ki, ha valaki doksi olvasással indít, azért nem érik ilyen kínos meglepetések.
Én is csak azért tettem szóvá, mert meglepett, hogy outofthebox így működik.
7

A win7-nél virtualbox-ról

inf3rno · Jan. 9. (Sze), 16.15
A win7-nél virtualbox-ról megy a docker host OS (nem tudom mit tesznek alája alapból), szóval azon elvileg ki tudnám próbálni, hogy mi lesz.
15

Linux

Pepita · Jan. 10. (Cs), 11.57
Szerintem még ott is Linux (rég használtam win7-en), nem rég jött be, hogy választható windowsos VM is hozzá. (Ezt mondjuk ki se próbáltam, jó nekem a MobyLinuxVM.)
5

Szerintem ez egyaltalan nem

MadBence · Jan. 9. (Sze), 14.27
Szerintem ez egyaltalan nem meglepo. A kontener megorokli a host ulimit-jet.

Ha neked ez ugy van bekonfiguralva, hogy lehessen fork bombot csinalni, akkor azt a kontenerben is meg lehet tenni.
6

Épp ez a gond, hogy nem

mind1 valami név · Jan. 9. (Sze), 14.39
Épp ez a gond, hogy nem örökli...
A hoston mindenhol, mindenkinek be van állítva.

Egyébként most megnéztem egy fedora virtuális gépben, ott valóban örökölte a guestként futó hosttól a limiteket. :)
Szóval ez akár egy ubuntu bug is lehet még...
Megnézem a laptopon is, hogy ott van-e eltérés.
8

Ahogy a linkelt stackoverflow

MadBence · Jan. 9. (Sze), 17.46
Ahogy a linkelt stackoverflow valasz is emliti, az ulimit alapbol a soft limiteket mutatja meg, a kontener pedig a hard limiteket latja soft limitkent (soft limit: barmikor allithatod magadnak, sajat hataskorben; hard limit: csak root-kent irhatod folul). A hard limiteket a -H kapcsolo mutatja meg. Kicsit faramuci ez a mukodes, de van ertelme: a valos limit a hard limit, a soft limitet barmikor atlepheted.
9

Csak az a gáz mindezzel, hogy

mind1 valami név · Jan. 9. (Sze), 19.32
Csak az a gáz mindezzel, hogy én a hoston, a /proc/<pid>/limits fájlban néztem a konténer processz limitjeit. És ott mindkettő unlimited volt.
Mellesleg ki is próbáltam a laptopomon: ubuntu alatt simán megdöglik a host egy a konténerben futó fork bombtól... Úgy kettő másodperc után.


Ö... a soft limitet sem léphetem át bármikor. Azt saját hatáskörben megemelhetem a hard limitig.
Legalábbis amikor utoljára tanfolyamra jártam, még ez volt a helyzet.

Update: beállítottam a daemon.json-ben egy userns-remap paramétert, a hozzá tartozó userre a /etc/security/limits.conf fájlban beállítottam pár limitet ehhez a userhez, de ennek ellenére:
# cat /proc/2089/limits
Limit                     Soft Limit           Hard Limit           Units    
Max cpu time              unlimited            unlimited            seconds  
Max file size             unlimited            unlimited            bytes    
Max data size             unlimited            unlimited            bytes    
Max stack size            8388608              unlimited            bytes    
Max core file size        unlimited            unlimited            bytes    
Max resident set          unlimited            unlimited            bytes    
Max processes             unlimited            unlimited            processes
Max open files            1048576              1048576              files    
Max locked memory         65536                65536                bytes    
Max address space         unlimited            unlimited            bytes    
Max file locks            unlimited            unlimited            locks    
Max pending signals       30966                30966                signals  
Max msgqueue size         819200               819200               bytes    
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us
10

a soft limitet sem léphetem

MadBence · Jan. 9. (Sze), 19.47
a soft limitet sem léphetem át bármikor. Azt saját hatáskörben megemelhetem a hard limitig.
Legalábbis amikor utoljára tanfolyamra jártam, még ez volt a helyzet.

Igen, en is ugyanezt probaltam mondani :).

Csak az a gáz mindezzel, hogy én a hoston, a /proc/<pid>/limits fájlban néztem a konténer processz limitjeit. És ott mindkettő unlimited volt.
Ezzel sem ertem mi a problema, valahonnan a kerneltol megkapja ezeket a limiteket, csak ki kell deriteni, hogy honnan.
11

Az a probléma vele, hogy

mind1 valami név · Jan. 9. (Sze), 20.38
Az a probléma vele, hogy gyakorlatilag ignorálja a rendszer default értékeit. A hoston részben a /etc/security/limits.conf-ban is be van állítva egy limit, részben a kernel is ad egy defaultot. És ezek ellenére a konténer unlimited belül is, de a hostról nézve is.
Ugyanez egy fedoran már nem igaz, ott tényleg átvette a rendszertől ezeket az értékeket a docker.
12

Megneztem, nalam is unlimited

MadBence · Jan. 9. (Sze), 23.20
Megneztem, nalam is unlimited a limit, de mindennek oka van, nalam a /lib/systemd/system/docker.service-ben szerepelt egy LimitNPROC=infinity direktiva. Gondolom ubuntuval is ez a helyzet, lehet hogy fedoraban mashogy van felkonfiguralva.
13

Mindennek a rákfenéje a

inf3rno · Jan. 9. (Sze), 23.37
Mindennek a rákfenéje a systemd. :D (nem lehetett kihagyni)
14

Na odáig nem jutottam. A

mind1 valami név · Jan. 10. (Cs), 00.48
Na odáig nem jutottam. A /etc/default/docker-t megnéztem, abban semmi sincs, a unit fájlok valahogy még nem érték el nálam az ingerküszöböt. :D
Kezdem érteni, miért utálják sokan a systemd-t...

Egyébként itt az indoklás:
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
16

Na ez se rossz - jó, hogy van tűzfal a hoston...

mind1 valami név · Jan. 10. (Cs), 17.15
Újabb meglepetés, bár ez érthetőbb, mint az eredeti felvetés.
Ubuntu a host, ufw segítségével konfigurált packet filterrel.
Indítom az nginx konténert, megadom neki, hogy a saját portjait mely host portokhoz csatolja (docker run -p host:container) és nyugodtan hátradőlök, hogy ezeket a portokat úgysem lehet elérni, míg nem engedélyezem a hoston is. Erről egy pillanatra megfeledkeztem és megnyitottam böngészőből a konténerhez tartozó portot és az megnyílt...
Hát igen... nem árt olvasni is, a docker nem mindig úgy működik, ahogy azt elvárnám. :)
(konkrétan a -p opcióval megadott portokat berakja a netfilter nat táblájába, továbbítva őket a konténerhez, anélkül, hogy a tűzfal konfigot piszkálni kellene)