Docker ve Fedoře (diskuse)

[BFU]

Ctvrty dil na tema "Docker a bezpecnost" neexistuje, nebot by do nej nebylo co napsat

[Conscript89]

Tak mohl byt Docker a nebezpecnost

[ikar]

+1

[petrfm]

Hele, to už se dostáváme pomalu ke koncepci ála microsoft windows, ne? Každý program = přibalená série knihoven. Jeden systém = 100x stejná knihovna Zdá se mi to, nebo tohle potírá právě tu výhodu sdílených knihoven, jakou linux přináší?

[Conscript89]

Bohuzel, ale prave ti co propaguji docker tak to berou jako vyhodu.

[petrfm]

To zas bude sraček a nedodělků, jen proto, že se to zavře do kontejneru a nechá se to v něm vyhnít. Jako testovací prostředí OK, ale lenost vládne světu.

[Conscript89]

Me treba doted nikdo nevysvetlil, jak se daji systematicky a rozumne updatovat zakladni knihovny typu glibc, zlib a podobny v pripade nalezeni bezpecnostni diry. Pokud to nejak rozumne jde, tak se zacnu na Docker divat trosku jinak, ale toto je imho broken by design.

[ddffadsf]

Dockerfile je iba subor prikazov spustenych nad base image + "metadata", co s tym. Nie je problem ho znovu zbuildit.

Zvnutra dockeru sa da pustit aktualizacia a ked ta nieco zmeni, tak je asi treba to znovu zbuildit. Suhlasim s tym, ze to neskaluje.

[pavlix]

Nový build.

[smazáno]

novy build a redeploy vsech kontejneru - maintaineri vsech kontejneru, ktere uzivatel pouziva, si musi vsimnout, ze vysla nejaka oprava, prebuildovat a vydat novy obraz - uzivatel pak musi zupdatovat vsechny obrazy a tohle se musi provest tak, aby neprisel o uzivatelska data ... to rozhodne neodpovida na otazku "jak se daji systematicky a rozumne updatovat zakladni knihovny typu glibc, zlib"

[pavlix]

To sice ne, ale víc od dockeru čekat nemůžeš.

[Tomáš2]

špatnej nebo žádnej admin je vždy problém ať už s dockerem nebo bez něj.

Docker (ale klidně i jail) řeší elegantně problém, jak dostat novou aplikaci do produkce na desítkách, stovkách strojích. Dříve jsme používali dpkg balíčky a byly s tím nemalé problémy, pak jsme to jen tarovali a také to nebylo bez chyb. S přechodem na jail se výrazně zvýšila spolehlivost deploye.

To že docker pužívají hostingy jako "vps", to že docker na produkci instalují programátoři, to že většina balíčků ve veřejném hub jsou sračky napsané zase jen programátory je realita, z které ale také nejsem nadšeny.

[petr_p]

Sračky vevnitř jsou jiný problém, který s dockerem nemá mnoho společného. Problém je, že docker neškáluje.

Nahoře se je dotaz, jak se aktualizují knihovny uvnitř kontejneru. Odpověď je, že se sestaví nový obraz z opravených knihoven. Problém je, že takový obraz může mít stovky megabajtů, které se musí při instalaci přenést na každý stroj. Docker sice umí přenášet rozdíly mezi obrazy, ale jen po linii dědičnosti obrazů. Jenže systémové knihovny jsou obvykle schovány v dalekém předku, takže to nemá smysl.

Jiný přístup je v existujícím obraze zaktualizovat jednu knihovnu a rozdistribuovat nový obraz jako poděděný rozdíl. Tohle škáluje při instalaci, ale ne při samotné aktualizaci. Pokud totiž takových obrazů pro různé produkty máte na starost stovky, tak přestává být možné udržet si přehled, který jste už aktualizoval, který ne a který aktualizaci nepotřebuje. Takže jste nakonec tam, kde jste byl před tím s klasickou distribucí s balíčky.

[ddffadsf]

Je mozne si udrzat prehlad, co ste uz aktualizovali a je to mozne aj automatizovat. Proste sa na obraze pusti apt-get update && apt-get upgrade a ked to nieco aktualizuje, tak je treba to rebuildnut.

Treba prenasat aj stovky MB - dnes ma kazdy na serveri aspon 1Gbit a vdaka torrentom sa obraz dost rychlo rozsiri po celom svete.

[Tomáš2]

vidím v tom dvě polopravdy, tenhle měsíc se dostal ven Docker 1.10, který jíž umí znovupoužívat vrstvy i napříč dědičnotí. Druhá je, že ty obrovské obrazy dělají pouze nezkušení programátoři a oficiální docker hub jich je plný. Při používání dockeru jen jako tenkého obalu nad aplikací tohle nenastává a aktualizace je naopak velice rychlá a i na jednom stroji je možné přes routing zajistit bez výpadkový nasazení, v případě použiti dpkg to není možné tak snadno.

Pokud někdo nasazuje docker ve firmách, má (měl by mít) svůj base image, od kterého ostatní dědí a i při aktualizaci se na server nahrává pouze jednou.

Teď mě velice těší iniciativa kolem nfs pro docker, to je důvod proč na produkci běží na jailech pro aplikační servery a docker máme pouze pro vývoj nebo konkrétní aplikace. Při desítkách až stovkách různorodých mikroslužeb na jednom aplikáčí je dediplikace a společná cachovací vrstva neuvěřitelně výhodná a efektivní.

Kontainery přináší jednoduché otestování právě takových aktualizací jako glibc a deklarativní nasazení napříč celou farmou. Zároveň můžeme na systému provozovat i věci nad musl aniž bychom složitě řešili administraci úplně jiného systému nebo konverzi pod glibc (důvodů je víc, ten hlavní jsou C11 thready)

[smazáno]

Presne tak ..

[little.owl]

To že docker pužívají hostingy jako "vps", to že docker na produkci instalují programátoři, to že většina balíčků ve veřejném hub jsou sračky napsané zase jen programátory je realita, z které ale také nejsem nadšeny.

Ta snaha navazet se do programatoru je komicka. Z dobreho programatora se znalosti systemu je jednoduzsi udelat administratora nez naopak, a tim se nezastavam lidi kteri nekam placnou ubastleny docker a pak se vykaslou na udrzbu.

[Tomáš2]

já to nemyslel ve zlém, ano, z programátora můžeš udělat admina. Ale pro správný chod systému je nutné dodržet určitá pravidla, určitou čistotu a to bez zkušeností prostě nedáš. Jeden obrovskej příklad za vše jsou signály, skoro žádný docker správně neošetřuje běžný SIGINT/TERM, natož ty méně běžné.

Stejně tak validace vstupních argumentů, nespouštění služeb pod UID=0, neukládání žádných souborů v containeru a nenechat všude se množit logy.

Pokud programátor zná linux, žádný problém, potkal jsem ale desítky programátorů a opravdu znalost linuxu není častá ;)

[little.owl]

Kazda prace se musi umet a bez praxe to nejde.

Pokud programátor zná linux, žádný problém, potkal jsem ale desítky programátorů a opravdu znalost linuxu není častá ;)

Totez plati od adminech. Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.

V realu nevime nic o lidech, kteri nahrali ty veci do Docker repository, takze nema smyslu delat zavery jestli to byl programator, admin ci preskoleny ucitel telocviku.

[pavlix]

Tech klikacu odkojenych na windows kteri copy-pastovali cosi z Internetu do rootovskeho terminalu, bez poradne znalosti, klidne urcene i pro jinou verzi/distrubuci, a pak kdyz to cele ro*****li tvrdili, jak je Linux na h***o, jsem jiz zazil nekolik.

:D

[Jiří J.]

To, co se běžně prezentuje jako kontejnery, ano. Docker umí údajně využít i unionfs a to už by mohlo být zajímavější - spousta knihoven by se dala "zabalíčkovat" do menšího množství vysokorúrovňových obrazů, nad kterými by se stavěly samotné aplikační kontejnery. V případě bezpečnostního problému by se prostě vytvořil nový image opravené knihovny.

Kromě nevýhody drobné ztráty místa na disku to má nespornou výhodu - vyšší vrstvy můžete "přesunout" na fixnutou verzi až budete chtít, ne s dalším restartem služby nebo stroje. Nad tímhle zajásá každý, kdo musí udržovat closed-source kritické firemní aplikace, které psala banda neandrtálců a které se podaří nastartovat až na 3. pokus a s tou správnou verzí libm.

Kontejnery mají smysl hlavně u služeb, které mají více daemonů, stavových souborů či socketů někde ve /var - dají se schovat do jednoho kontejneru se snadným on/off vypínačem, který nejenže "čistě" zabije všechny související procesy, ale odmountuje všechny mountpointy, uvolní sdílené IPC prostředky, apod.

A co teprve použití takovýchto kontejnerů s btrfs snapshoty -- je libo bezstavové služby?

Nevýhoda? Někdo by musel udržovat vrstvené obrazy podobně jako distribuce udržují balíčky a to se nikomu nechce. Je daleko jednodušší do kontejneru nacpat celou distribuci a v ní spustit jednu službu.

[ddffadsf]

UnionFS sa pouziva, ale tu je problem, ze zalezi na poradi a zdielane subory sa nedaju skryt pod UnionFS. Viacere programy si pridavaju uzivatela do /etc/passwd a tam sa pouziva aj uid. Bolo by treba zaistit, ze nevzniknu konflikty - preto musia instalacne baliky robit nieco vlastne a to uz sa tazko vracia.

Docker ma zakladnu snahu byt bezstavovy a myslim, ze to robi dobre. Btrfs snapshoty? Naco presne?

[Mazarik]

Ano, ale je podla mna treba vidiet, ze teraz je to hype. Podla mna docker ma svoj use-case, kde je lepsie pouzit docker ako napr. virtualizaciu. Az sa to cele usadi, tak verim, ze sa docker bude pouzivat iba tam, kde je to ekonomicke. Pamata si niekto este na hype s Xml? A co pouzivame teraz na vymenu dat? Json, Yaml a tam, kde sa to vyplati aj Xml. Podla mna je to velmi podobne.

[JoHnY3]

Me Docker hype asi nejvic pripomina Ruby (on Rails) hype. Hlavne tim, ze ho vsichni propagatori povazuji za nejvetsi vynalez po splachovacim zachodu. Tretina z nich netusi jak ho vlastne pouzivat, tretina si chybne mysli ze pro nej ma pouziti a tretina tvrde bojuje, aby jim fungoval jak potrebuji.

* Tretiny jsou samozrejme optimisticky odhad, tech co netusi bude pravdepodobne mnohem vic a tech co bojuji vyrazne mene.

[smazáno]

To souhlasi! :)

[lqw]

Nahodou Rails uz z hype davno vyrostly a jsou jednou z top alternativ pro komercni vyvoj webovych aplikaci.

Hype je kolem Node.js a jsem zvedavej kde to skonci az opadne. Velky plus ma kvuli V8, velky minus v nakonzistentnim a neelegantnim JS.\

[Conscript89]

No ja ti nevim, XML se pouziva porad a celkem dost. Je pravda ze json se vyuziva dnes pomerne dost a dava to i smysl, ale v moment kdy chces featury XML (validace, transformace, a jine) tak ho pouzijes (pokud nejsi masochista a nechces si vytvaret vlastni reseni v pripade ostatnich jazyku).

[pavlix]

Tak tam jde spíš asi o ten hype z doby, než to všichni zkusili použít a zjistili, jak je XML těžkopádné.