docker zatial nepouzivam, chcem ho pouzivat na weby a databazy (MariaDB, MongoDB) kvoli skalovatelnosti a HA. Dňa št 30. 4. 2015 o 0:34 Branislav Blaskovic <branislav(a)blaskovic.sk> napísal(a):

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cau, On 05/02/2015 12:32 AM, Lukáš Drbal wrote: S rozbehanim dockeru je to takovy, no, https://36.media.tumblr.com/tumblr_m7bjr0xDHj1rbsctpo1_500.jpg. Not true. Engine dockeru, minimalne na cem bezi u nas (neznam ho a ani az tak detailne ho znat asi nepotrebuju), vyuziva cgroups, namespaces a par dalsich drobnosti, aby vyrobil neco, cemu se rika LXC kontejner. Tyhle technologie jsou v kontextu kontejneru na levelu OpenVZ "podrazeny" pod OpenVZ accountovani. Cgroups umi byt nested, jenom je tam trocha bezpecnostniho kodu navic a podobne, beancounters neni treba resit, protoze je Docker by default nepouziva - jenom s OpenVZ backendem, ten by u nas tim padem nechodil. Cili monopol na planovani hw resourcu ma u nas vpsAdmin a ma a porad mit bude mechanismy, jak rozdelit prostredky spravedlive. Nejde to sice uplne na vsech urovnich (ted narazim zrovna napr. na rozdeleni tech ~50-80 GB ZFS ARC v RAM mezi kontejnery), ale na vsech podstatnych to funguje pekne. Ad ARC, on ten mechanismus je proste funkcni i bez nutnosti limitovani velikosti ARC pro CT, setri IO na disky podle chovani vsech procesu v case efektivne. Kdyby to tak nebylo, resil bych to. Nicmene, napsal jsem si tool na analyzu situace a nemame s tim problem, jenom nekterych par kusu CT bude potreba lip rozbalancovat, spis pro klid duse, nez realny benefit. Scheduler po clusteru je dalsi bod na planu vyvoje. To je hate, ktery vyplyva z nepochopeni veci. Docker ma validni use case v momente, kdy potrebuju stejnou (nebo velmi podobnou) konfiguraci deploynout vickrat a pocita se s clusterovanim pres nejake HA nastroje. Je jich hromada na vsech moznych urovnich, od OS levelu po aplikacni level. Takhle se potom da udelat velmi rozsahla infrastruktura. A usetri se fakt hodne prace. Ze ho tak malokdo pouziva, protoze ho zrovnatak nepochopili a snazi se ho napasovat na vsechno, jenom protoze je Docker zrovna cool, mno. Tam mam zas hate-o-meter vytoceny na nad prumer ja. Napr. sirit aplikace ostatnim pres Docker a jeho repositories (registry) mi prijde, mno, http://sotontab.co.uk/wp-content/uploads/2012/02/LOL_Cat___I_Iz_Not_Amus ed_by_Lycan_wolf96.jpg zhruba. Coz mne privadi k myslence, ze budu mit talk na Docker meetupu v Brne ted v kvetnu (poslu separatni mail), abych trosku zchladil nadseni a urovnal veci na pravou miru. Budu povidat prave o tom, co Docker pouziva za technologie vlastne, kde se vzaly a jaky je kontext, v kterem vznikly. Vzhledem k tomu, ze jsem se pohyboval presne v tomhle startup hyped super duper prostredi v dobe, kdy Docker byl vubec oznameny, si myslim, ze mam vcelku prehled o celem kontextu. Lidi, co ho nechapou, si vykladaji veci ruzne po svem a je to potom zabava sledovat. Nekdy to vede k dalsi inovaci, nekdy k vic facepalmum. Ja velmi schvaluju motivaci za Dockerem, tzn. moznost vybuildit system, kde se muzu spolehnout, ze jsou veci presne tak, jak chci. Opakovane, na hromade hardwaru, spravovatelne. Cili zahodit jakykoliv runtime state pri shutdownu, ktery neni potreba mit perzistentni. Presne to je smer, kterym bych chtel, aby se udavaly nase hardware node instalace. Cili nasi zabavou na nejblizsi dobu bude pobalit vsechny komponenty, ktere potrebujeme do repozitaru a celou instalaci pres par jednoduchych nastroju prevest na read-only bootovatelny image. Live system, ktery si osaha hardware, importne ZFS pooly, pripoji se k vpsAdminu, donastavi se a spusti CT. Finalnim cilem je mit celou build pipeline automatizovanou, aby pri commitu do repozitare vypadlo nove .iso, .img a PXE boot soubory, protoze chci automatizovat testovani celeho stacku kvuli vyvoji jadra a ZFS. To cele potom vede k tomu, ze si budeme moct vyvijet vlastni veci, vlastni funkcionalitu, backportovat, co bude potreba, kontejnerizovat, co bude potreba, atd. Bude to chtit dobrovolniky, to samozrejme, ale jakmile OpenVZ projekt pusti ven RHEL7-based jadro, jeho vyvoj bude verejny v gitu a tak nebude problem, abychom mohli celou praci upstreamovat. O tom bych asi taky mohl poslat separatni mail, mozna by se nekdo rad zapojil do vyvoje. Prace je vic, nez trilion a den ma jenom 24h. Bylo by luxusni mit neco k prezentovani na Linux Days 2015. /snajpa R LesTR