"Tudsz peldat mondani az elsore? Mert ugyan jol hangzik, de konkretumok nelkul keveset er."
Na szóval, ha már docker. Akkor pár pl arra.
1) Rögtön azzal nyitunk, hogy storage driver, melyik ujjamat harapjam.
- aufs - köszi, de én is láttam, amit a neten még sokan, hogy simán összefosta magát. Többször is, úgy, hogy nem nevezném terhelésnek, amit kapott. Az is sokatmondó, hogy a redhates srácok inkább írtak egy saját drivert a devicemapperre, minthogy beengedjék
- szóval devmapper? Hát, az legalább az lvm alatt már jó, cserébe a dockeres arcok huzzák rá az orrukat láthatólag
- overlay / overlay2 - mindkettő fiatal. fiatalabb mint pl a brtfs, amit még nem mertek élesbe engedni, és emlékszünk még, mennyi idő volt, míg az ext4-et kikupáltálták, szóval eleve vannak kétségek. Hogy az overlay2 azért létezik, mert rájöttek, hogy az overlayt fubar cseszték el, az nem növeli az abba vetett hitet, hogy majd pont nekik fog sikerülni gyorsan.
- brtfs - egyrész lásd fent, másrészt ránézésre úgy tűnt, a driver is félkész.
- zfs - az még docker nélkül is véleményes linuxon
Csupa jó választás, és ugye üzembiztonság szempontjából azért nem mindegy.
2) 1.12-ben lett healthcheck (ami elég jippi, mert az egész koncepcióban sok helyen elég fájdalmas, hogy ha a container elindult, akkor az jó, és jön a wait-for-it.sh és társai). Ami azt csinálja, hogy... hogy beleírja a metadatába hogy healthy, sajnos semmi mást, hacsak nem írod meg te magad. Hasznos :) 150 sor alatt meg lehetett csinálni pythonban, hogy listeneljen az api eventekre, és applikálja rá a container restart policyját, érthetetlen, hogy ezt miért nem tudja magától.
3) Nagynehezen eljutottak odáig, hogy lehet törölni a registryből. Micsoda feature :) Igaz, ha jól láttam, kivezetve még nincs, csak api call, és az is csak bemarkolja deletere, de offline kell vinni a registryt, mikor valóban takarítasz, mert annyira jól tervezték meg az adatstruktúrát, hogy nem tudják másképp kezelni azt, hogyha változna a kétlépcsős először megnézzük mit lehet törölni, majd töröljük őket processz közben.
4)
root@host:~# docker images -f dangling=true | wc -l
63
root@host:~# docker images -f dangling=false | wc -l
61
root@host:~# docker images |wc -l
84
és nem, nem azért mert közben változott, azt is rendszeresen látom, hogy egy ilyen után akasztott |xargs docker rmi harákol, hogy fogja valami a layert.
"Minek jatszanek disztributort? Mondjuk fogom a coreost, beallitom amit kell, abbol csinalok egy imaget es azt teritem. Nem nagy cucc legeneralni es rolling deployolni."
Mert az összes használt cucc security követését meg kell oldanod magadnak. Vagy elhiszed annak, akitől az image van, hogy jó -- ezt sajnos én a nagyobb disztribútoroknak is csak módjával tudom, pedig ők rég ezt csinálják, a random app gyártójának csak nagyon nagyon mértékelten, szóval
- vagy valami automatával scannelsz folyamatosan, hogy hol sikerül bent felejteni egy régi vulnerable libet (aztán agyalani azon, hogy hogyan forkolod le a dockerfilet, ha az upstream balfék)
- vagy csinálod magad, és integrálsz be egy csomó upstream repot, változatos formában.
- Bónuszként, ha esetleg szeretnéd tudni fél év múlva is reprodukálni, akkor ki kell találni azt is, hogyan artifactolod el az összes upstreamet a githubtól az ubuntu repojáin át a pipig a cpanig, meg az istentudja miig bezáróan, vagy azt, hogy hogyan követed a verziókat manuálisan.
Ez egyébként jellemző probléma az összes ilyesmire a snappyn át az apkig, ahol izolációval csinálnak securityt, és azt tesz oda a vendor amit akar, nem a docker sajátja.