Vývojáři CoreOS představili Rocket, alternativu k technologii Docker (diskuse)

[Harvie.CZ]

Nikdy sem poradne nepochopil k cemu to presne je. Zbezne sem videl nakou prednasku o dockeru a udelal sem si z toho zaver, ze pointa je oddeleni aplikaci za nejakym ucelem (at uz bezpecnost nebo prenositelnost).

Ve chvili kdy sem zjistil, ze prednasejici mel krasne zadockerovanej vim, kterej zabiral "jenom" 300MB me presel zajem. Asi tezko muzem mluvit o prenositelnosti mezi systemama, kdyz si celej system musite pribalit s sebou. A co se tyka bezpecnosti me zrovna nelaka mit pro kazdou aplikaci zvlast celej OS v chrootu.

Co me vsak zarazi je, ze je tahle vec zrejme popularni. takze asi neco spatne chapu nebo nevim... jaka ze je pointa toho celyho dockeru? a proc se o to lidi zajimaj? kde presne to ma vyuziti?

[Jiří J.]

Co me vsak zarazi je, ze je tahle vec zrejme popularni. takze asi neco spatne chapu nebo nevim... jaka ze je pointa toho celyho dockeru? a proc se o to lidi zajimaj? kde presne to ma vyuziti?

To asi proto, že "Docker" je nejznámější jako marketingový pojem, podobně jako "Cloud". Oboje zhruba definují nějakou oblast nápadů a principů, ale staví víceméně na starých známých věcech (v případě dockeru Linux namespacy + cgroupy (a volitelně SELinux, plánovaně seccomp, ...)).

[rws]

Vyhoda je, ze docker se sam stara o obrazy (base-image + dalsi image se specifickym sw).

Idea je, ze se pripravi jeden base image, ten se pripoji do aufs a na jeho zakladu se vytvori specificky imaage napr. s apachem s php. Nebo se na zaklade base image pripravi image s mysql. Pri startu se pak ty rozsirene image pripoji pres aufs, k tomu se pripoji dalsi adresare pro specifickou konfiguraci. Takze mas jeden base image pri vsechny chrooty, pak mas jeden apache image pro vsechny web chrooty a pak mas make images s konfiguracemi. Update resis tak, ze udelas novy base image, k nemu novy apache/mysql/etc image a pak jenom znovu namountujes do aufs, konfigurace zustane. Proc delat chrooty je jasne, proc chroot misto VM je taky jasny, cgroups zvysuji omezeni v chrootu. No a Docker automatizuje tu pripravu a pripojivani obrazu.

[Conscript89]

proc chroot misto VM je taky jasny

Me to jasny neni.

[Max]

Výkon + menší hw nároky + jednodušší údržba?
Zdar Max

[Frack]

proc chroot misto VM je taky jasny

Me to jasny neni.

Výrazně menší pamětový footprint a rychlost (výrazně rychlejší spouštění než u virtuálních mašin, což se v cloudu hodí).

[Conscript89]

Jak moc je vyrazne mensi pametovy footprint? http://fedoraproject.org/wiki/Features/KSM

K te rychlosti se vyjadrit nemuzu, zase mu ale afaik chybi featury jaky ma virtualizace, coz je treba ziva migrace a tak. Ale chapu, docker proste neni univerzalni reseni a tak asi ani neni pro me.

[pavlix]

Jak moc je vyrazne mensi pametovy footprint?

Při troše snahy by se nemusel až tolik lišit od staticky kompilované binárky. Na druhou stranu minimalizace zabrané paměti asi nebude hlavním kriteriem ;). Myslíš si, že se s tím může umělá deduplikace paměti obecně nějak měřit?

K te rychlosti se vyjadrit nemuzu, zase mu ale afaik chybi featury jaky ma virtualizace, coz je treba ziva migrace a tak.

Image pro docker mají být stavěné tak, abys je nastartoval a mohl kdykoli zahodit a jinde nastartovat opět od nuly. V takovém kontextu nevidím pro živou migraci velký důvod. Jak píšeš, není to univerzální tool a jeho účelem není vzít existující systém a narvat ho do dockeru, ale vystavět aplikace na dockeru.

[egro]

chalani z clusterhq v londyne robia flocker, ktorym sa riesi prave otazka live migracie. bol som na par ich prednaskach a vyzera to fakt velmi dobre. https://clusterhq.com/

[dustin]

Myšlenka ok, jen to bude chtít chvíli, aby si to sedlo. Mně osobně vadil způsob práce - opustím ten shell, aplikace se vypne, vše zmizí. Udělat to persistentní bylo docela pracné a dost snadno se na to zapomnělo... a zase je člověk na začátku. Taky mi vadil komplikovaný způsob spouštění více procesů - typicky např. ssh, abych se k "virtuálu" snadno dostal, nebo nějakého monitorovacího softu. Ten chroot OK, ale ta automatická likvidace instance při ukončení procesu mi silně vadila.

Veřejný docker repozitář byl spíše nepoužitelný - všichni dodávali vlastní celý stack imagů a stahovat kvůli drobné aplikaci celý base ubuntu mi nepřišlo rozumné.

Ale chápu, že tohle se časem může vyčistit a dodělat. Stejně jako si sedlo pulseaudio a za pár let si sedne si systemd (noflame ).

[pavlix]

Myšlenka ok, jen to bude chtít chvíli, aby si to sedlo. Mně osobně vadil způsob práce - opustím ten shell, aplikace se vypne, vše zmizí. Udělat to persistentní bylo docela pracné a dost snadno se na to zapomnělo... a zase je člověk na začátku.

Holt se to nesmí člověk snažit používat ke věcem, ke kterým to není určené.

Ten chroot OK, ale ta automatická likvidace instance při ukončení procesu mi silně vadila.

Pokud chceš klasický systémový kontejner, můžeš použít LXC nebo něco takového. Neříkám, že na to nejde při troše snahy Docker použít, ale je to takové drbání se levou nohou za pravým uchem.

Veřejný docker repozitář byl spíše nepoužitelný - všichni dodávali vlastní celý stack imagů a stahovat kvůli drobné aplikaci celý base ubuntu mi nepřišlo rozumné.

Ani to k tomu není určené. Pokud vím, tak fedoráci poskytují pár aplikačních imagů a ty jsou odvozené od nějakého base image, který můžeš použít, pokud chceš stavět vlastní image. U jiných distribucí bych očekával to samé.

[pupala]

Tak k čomu je docker primárne určený? Neviem to nejako jednoznačne a ucelene definovať. Vždy som mal predstavu, že v dockeri beží len samotná aplikácia a poporné knižnice resp. aplikácie, a nie aj samotný systém. Poprosil by som o vnesenie trošky "svetla" do mojej "tmy". Ďakujem

[pavlix]

Sám jsem v tomto ohledu spíše začátečník, ale chápu to tak, že docker image slouží jako portable app, a to především serverová aplikace, takže jako nevývojář bys neměl mít potřebu do toho kontejneru vůbec zasahovat. Persistence se pokud vím řeší tak, že dáš tomu image k dispozici persistentní storage a on sám tedy persistentní být nepotřebuje.

[Frack]

Samotná aplikace tam může běžet asi těžko, když je v tom kontejneru izolovaná od zbytku systému. Nemůže běžet ve vzduchoprázdnu. Kontejner je mnohem blíže VM než samostatně běžící aplikaci. Jen na rozdíl od VM tam člověk nemusí mít celý systém, ale sdílí to kernel s hostujícím systémem a i některé knihovny z hostujícího systému tam snad jdou linkovat. Výsledkem je menší paměťová náročnost, což dělá u většího počtu kontejnerů dost výrazný rozdíl oproti VM.

Cílem je najít střední cestu mezi těžkotonážními VM a instalací aplikace přímo do systému, oproti ní má kontejner výhodu, že zajišťuje stejné prostředí pro vývoj, testování i provoz. To umí i VM, ale s mnohem větší režií.

[pavlix]

Samotná aplikace tam může běžet asi těžko, když je v tom kontejneru izolovaná od zbytku systému. Nemůže běžet ve vzduchoprázdnu.

Přijde mi, že se buď špatně vyjadřuješ, nebo plácáš nesmysly.

Kontejner je mnohem blíže VM než samostatně běžící aplikaci.

To záleží na úhlu pohledu a taky na typu kontejneru. Z pohledu uživatelů aplikací distribuovaných v docker imagích je tomu přesně naopak.

[pupala]

Zle som sa vyjadril. Chcel som povedať, že v dockeri je bežiaca aplikácia a jej podporné aplikácie, ale nebeží v ňom osobitný kernel a všetky libky. Aspoň takúto predstavu som mal ja. Ďakujem za info.

[dustin]

Podpůrné aplikace - to nevím. Již nastartování více procesů v dockeru je boj.

[dementni.lojzik]

Již nastartování více procesů v dockeru je boj.

protoze AFAIK zamerem je bezet jedenu aplikaci/proces v jednom kontejneru (vyexportovat porty, mit mikroservisy a bla bla). Nicmene pokud chces vic procesu, tohle nefunguje nebo je tak moc slozite?

[pavlix]

Nastartuješ minimální systemd a jedeš, ne? :D

[kralyk z abclinuxu]

Nastartuješ minimální systemd a jedeš, ne? :D

K tomu je, jsem slyšel, dobré si poslechnout nějaký ten zbortěné harfy tón...

[pavlix]

Jinak systemd byl samozřejmě jenom příklad, vytvářet nové procesy je v dockeru úplně stejně jednoduché jako je vytvářet kdekoli jinde, dělá se to totiž úplně stejně.

[Josef Kufner]

Jsi si jist, že ten smajlík je na místě? Co jsem si tak všiml, tohle je právě jeden z hlavních use-case pro systemd.

[pavlix]

Jsem přesvědčen o tom, že jsem tam ten smajlík dal úmyslně a z dobrého důvodu. O tom, zda to lze označit za jeden z hlavních use case, se dá polemizovat. Já osobně si myslím, že je to především use case pro ten init, který se v distribuci používá.

[pavlix]

Jo, to už zní o něco blíže realitě a týká se to všech kontejnerů. Pokud vím, tak docker balí všechny potřebné knihovny, na druhou stranu o knihovnách nemá smysl říkat, že běží, to náleží spíše procesům. Ten může pokud vím v dockeru klidně běžet jenom jeden nebo si ten jeden může spouštět další. Hlavní rozdíl je skutečně v těch knihovnách, které si tak nese program s sebou jako tomu bylo často zvykem na DOSu nebo na Windows a v té (částečné) izolaci od hlavního systému.

[tacoberu]

Je možné ten Docker pouštět pod obyčejným uživatelem?

[pavlix]

Nezjišťoval jsem, neměl jsem k tomu důvod.

[Integral]

jestli myslis kontejner, tak samozrejme jo :) sluzbu spoustim pod rootem

[washeck]

On ten příklad s vimem je trochu zavádějící. Myslím, že užitečnější představa jsou nějaké specializované aplikace, jako třeba tyto bioinformatické: https://www.biostars.org/p/117401/

Já si to představuju tak, že když chceš třeba udělat cloudovou službu pro bionformatické analýzy, připravíš si image pro každou z těch aplikací (každá může využívat jiný OS, programovací jazyk, atd.), zákazník nahraje data, ty mu pustíš výpočet v kontejneru, uložíš výsledek a kontejner zahodíš.

[aaa]

V Dockeri bezi aplikacia vo svojom prostredi, v podstate vo "vylepsenom chroote". K tomu poskytuje efektivne vytvaranie tychto prostredi podla jednoducheho popisu. Nie je to cely system.

Ja ho vnimam tak (a to mi pomohol vyriesit), ze mozem mat rovnake prostredie pri vyvoji, pri testovani a na produkcii. To normalne nebyva mozne - na testovacom stroji bezia aj dalsie aplikacie na testovanie, pri vyvoji mi bezia X-ka a miestami si nainstalujem extra modul PHP na otestovanie niecoho a potom sa na to moze zabudnut.

Docker mi dava moznost izolovat aplikacie a presne definovat prostredie, v ktorom aplikacie pobezia. To vyrazne obmedzuje chyby sposobene odlisnou konfiguraciou (vy mate v produkcii shell_exec zakazany? Vy nemate modul crash_every_second?)

Docker mi poskytuje izolaciu na tejto urovni, ale ako bezpecnostne opatrenie by som to urcite nepouzival, lebo na to nie je stavany a da sa to obist.

[little.owl]

Ja ho vnimam tak (a to mi pomohol vyriesit), ze mozem mat rovnake prostredie pri vyvoji, pri testovani a na produkcii.

Hlavne pri deployment to do znacne miry odstavuje lokalni adminy, na spusteni Dockeru se toho neda tolik zpackat .

[pavlix]

Jakože to odstiňuje nebezpečný element, jo?

[Josef Kufner]

Z vlastní zkušenosti mohu potvrdit, že čím míň lidí do toho hrabe, tím méně je s tím problémů.

[little.owl]

Cim mene zasahujicich lidi mezi vyvojari a zakaznikem, tim lepe.

[omg]

treba nejake to oddeleni garance kvality, ze.

[little.owl]

QA team obvykle nedela zmeny a reportuje problemy zpet vyvojovemu teamu, takze tam nevidim problem.

[omg]

docker je urceny ke klasickym IT ojebavkam, ktere vyzaduje management a argumentuje u toho rozpoctem.

pokud ma byt cloud model uspesny, tak je musi umoznit. to znamena, ze musi byt mozne provozovat aplikaci treti strany, nabizet aktualizovany podporovany system a soucasne dat zakaznikovi moznost rict na sve riziko potrebuji starsi verzi.

[smíťa]

Docker a podobné jsou určeny hlavně k provozování SaaS - mám aplikaci, která má určité požadavky na běh (OS, balíčky) a potřebuji ji provozovat na několika aplikačních serverech. Dojde výkon, nebo potřebuji aplikaci na jiné lokalitě - nahodím balík na další server.

Je třeba uvažovat 1 docker aplikace = více strojů. Při uvažování jeden stroj = mnoho docker aplikací nedává koncept moc smysl.

[kos]

Bude ten vlastni kontainer "image" kompatibilni s dim dockerovym?

[Petr Ježek]

Proč ne lepší řešení než docker? Tedy, pokud se jako lepší skutečně prokáže. V podstatě IMHO jde o vylehčení a přímočařost dockeru, což odpovídá filozofii CoreOS.

[Vykook]

CoreOS jsem zkoušel a za 2 dny, kdy jsem s tím prakticky nic nedělal, se BTRFS rozsypal a už jsem nenabootoval. Nakonec ten stroj dostal OpenIndianu a zatím si docela chrochtám.

[Aleš Kapica]

CoreOS jsem zkoušel a za 2 dny, kdy jsem s tím prakticky nic nedělal, se BTRFS rozsypal a už jsem nenabootoval.

Tož to teda klobouk dolů.

[Vykook]

Já jsem v tom nevinně! To ono samo!

[Aleš Kapica]

Je smutné si to přiznat, ale nikdy nic samo. Obvykle je za tím chyba. Ať už moje, nebo někoho jiného. A vzhledem k tomu, že jiným se Btrfs nesype, lze zcela důvodně předpokládat, že jsi buď udělal nějakou botu, nebo máš poškozený hardware..

Není tomu tak dlouho co jsem zaznamenal pozoruhodný fakt, že Btrfs (v režimu raid6) je docela citlivé na diskové chyby. Pokud bych použil softwarový MD raid6 a teprve nad ním Btrfs, tak bych zřejmě nic nezaznamenal, dokud by se to definitivně nepodělalo. To Btrfs však začalo řvát, že mu nesedí checksumy na problémovém disku, prakticky ihned poté co jsem se tam pokusil nakrmit nějaká data.

[kralyk z abclinuxu]

No já jsem teda taky zažil, že btrfs se 'samo' sesypalo. Ale bylo to před několika lety, je dost možné, že už to je mezitím lepší... Nicméně, co se týče FS, imho se vyplatí být konzervativní; z mého pohledu byl btrfs příliš dlouho nestabilní na to, abych mu důvěřoval někdy v nejbližší dekádě...

[Heron]

Já to zažil na jádře 2.6.18, když při btrfs device remove kernel zpanikařil a btrfs bylo ve stavu neslučitelném s daty.

První kernel s btrfs byl 2.6.29, do této 2.6.18 byl backportován. Což je přesný opak toho, co by se mělo s FS v intenzivní fázi vývoje dělat, toto nelze považovat za chybu fs.

[omg]

me se na tom nejvic libi kolik let trvalo nez vsichni sekuritaci a jejich manazeri vyhnili a tahli do prdele a mame tu opet racionalni pozadavky na ucelne vyuziti vykonu.

je to cca 15 let co sekuritaci nacpali vsude hrubou silou shared knihovny a vyhazaly do posledniho kousku vsechny staticky linkovany binarky z pozice ja jsem tady adrchitekt/vyvojar. dalsi 4 roky pak realne neexistoval zpusob jak udelat forenzni analyzu, ani rescue bez funkcni cdromky a pritomnosti on-site nebo jen za cenu obetovani ohromne casti draheho maleho rychleho serveroveho disku ve prospech druhe instalace prave pro potreby rescue. po 4 letech konecne vznikla nahrazka busybox.

no po 15 letech konecne vznika odpovidajici nahrazka za ze systemu vyhozeny staticky binarky a knihovny. o tom proc vznika az nekdy jindy, ale motivace bude stejna jako situace, kdy se pouzivaly pred 10-15 lety na systemech co vzdorovaly aktualizaci.

[pavlix]

Huh?