Dotaz: Docker z uživatelského pohledu

[lertimir]

Tak nevím, jestli nevyvolám nějaký flame, ale zkusím se zaptat. Zatím jsem Docker nepoužíval a klasicky, co jsem potřeboval jsem nainstaloval z repozitářů. Ale čím dál více potkávám rady a návody, které místo klasické cesty z repozitáře nebo při nejhorším kompilační cestou ./configure;make;make install doporučují zvolit obraz do Dockeru (v současnosti jsou to Home Assistant a Transmission pro RPi). A než se s tím začnu zabývat, tak bych rád porozuměl proč? Přečetl jsem na diskusích, jak je to fajn pro vývojáře, ale zatím nerozumím tamu jaké plusy a mínusy proti normální prací s repozitářem to nese pro uživatele systému (balíku, programu). Díky.

---

---

Odpovědi

[X]

HomeAssistant je na balicek uz fakt trochu velky. Je to pohodlnejsi pro vyvoj i pro tebe, protoze nepotrebujes deseti strankovy navod na instalaci. a Docker. Predstav si to jako system v systemu. Vsechno mas pohromade a oddelene od zbytku => nelibi, smazes a mas cisto.. u kompilace je to uplny opak. Je to ve vysledku tak male, ze nez vyrabet balicek tak to je rychlejsi si ten jeden,nebo dva soubory vyrobit rucne.

[Migi]

Pokud vývojář neudržuje pro aplikaci balíčky pro všemožné distribuce a současně to nedělá ani žádný distribuční maintainer, nic jiného ti nemusí zbývat.

Současně pokud je aplikace v kontejnerech udělaná správně, poběží ti to zkrátka na každém systému, kde bude dané container runtime podporované. Nezávisle na tom, jaké balíčky používá. Vývojář to napíše jednou, v kontejnerizaci, napíše pro to jeden návod a distribuuje jedním kanálem (např dockerhub). Uživatel má jeden distribuční kanál, jeden postup zprovoznění.

Reálně samozřejmě všichni používají X způsobů jak aplikaci získat, a vzniká u toho X problémů spojených s daným způsobem distribuce (všichni třeba "milujeme" snapy).

TLDR:

1. Pokud je aplikace dostupná v balíčcích ve verzi, která umí to co potřebuješ, používej nadále balíčky.

2. Pokud není splněn bod 1., kontejnery jsou jedním z možných řešení.

[lertimir]

No tohle všechno chápu, ale to je pořád ten vývojářský pohled. Jak aplikaci pohodlně udělám. (snap také nepoužívám) Mě zajímal funcionální pohled uživatele. Jediné co do funkcionálního pohledu zatím bylo "nelíbí smažeš a máš čisto" Zkusím tedy přímější otázky:

1. Nelíbí smažeš a máš čisto - jaký je rozdíl od smazání balíčku dockeru, balíčku v balíčkovacím systému distribuce nebo od make uninstall, pokud instaluji ručně? Nebo je ten rollback větší a smaže vše, co aplikace udělala/zapsala?
2. Jak probíhají aktualizace, rozdíl proti aktualizaci z repozitářů?
3. Přináší docker něco více do bezpečnosti (lepší oddělení procesů, přístupů k disku, a pod)? A nebo omezení, že s některými daty nemůže pracovat?
4. Jaká je výkonová ztráta aplikace v kontejneru?

[čavo]

1) pokiaľ mu to nejak nepovolíš, tak má svoju adresárovú štruktúru, v ktorej beží a pracuje, teda keď ten kontajner zmažeš, tak zrušíš naozaj všetko, čo za ten čas urobil. Je v tom aj nevýhoda, po zastavení a spustení image sa vytvorí nový kontajner, ktorý bude s údajmi na začiatku ako po prvom spustení, všetko ostané sa stratí. Ak chceš nejaké údaje zachovať musís použiť volume.

2) stiahneš nový image a spustíš nový kontajner. Ak máš verziu image ako latest, prípadne iný, ktorý sa priebežne aktualizuje, tak stačí v princípre spustiť nový kontajner on si pri spúšťaní zistí, čí nie je novší vyhovujúci tomu tag-u a následne ho stiahne.

3) Môže pracovať len s vecami, ktoré mu sprístupníš (má vlastný strom súborov, je sieťovo oddelený, môžeš mu obmedziť RAM aj počet CPU, ktoré môže použiť.

4) Predstav si to ako chroot, teda prakticky žiadna. Niečo tam samozrejme, kvôli oddeleniu siete a diskov a kontroly obsadenia RAM a CPU, bude.

[AraxoN]

Teoreticky je to dobrá vec. Prakticky tie obrazy lepí dohromady kde-kto z obrazov, ktoré získal bohviekde. Bezpečnosť tým trpí:

• Pozor na obrazy pro Docker. Třetina z nich obsahuje závažné chyby
• Docker Hub po roce odstranil image těžící Monero, měly pět milonů stažení
• Docker Hub úspěšně napaden, unikla data 190 000 uživatelů

[Max]

Je to problém, protože docker většinou lepí developer, který nerozumí administraci a naseká tam mj. i bezpečnostní chyby.
Dá se ale držet nějakých pravidel, které bezpečnost navýší. Tj. používat třeba oficiální obrazy (Docker Official Images), za které DockerHub ručí.
Zdar Max

[lertimir]

1) Docker není jen o jednom programu. Distribuuje se tak třeba celé řešení. Příkladem budiž třeba Bitwarden. Je to směs tuny aplikací, která lze nasadit relativně na jeden klik.
2) Kromě jednoduchosti nasazení je to i o jejich oddělení, což by mělo značně zvýšit bezpečnost. Zajímavým příkladem je třeba projekt devilbox.org.
3) Tím, že to je kontejner, tak lze provozovat různé verze programů vedle sebe, jeden nad knihovnami z Debianu 5, druhý nad knihovnami z Debianu 11 atd.
4) Pokud postavíš aplikaci nad dockerem a hodíš do Kubernetu, tak ten za tebe vyřeší spoustu věcí. Bude ti hlídat HA, bude ti dělat dynamické horizontální škálování podle zatížení (= když výkon nebude stačit, spustí ti další pod s dalšími zdroji) atd.
5) Autor dokáže díky dockeru dostat svojí aplikaci všude (nemusí řešit balíčkování ani kompatibilitu s jinými verzemi knihoven).

Ptát se na rozdíl mezi balíčkem a dockerem je tedy spíše jen otázka při prvním pohledu na docker. Ve skutečnosti toho nabízí hodně. To, že ho někdo využívá jen pro své zjednodušení (= neřešit balíčkovací systémy apod.) je jeden z těch méně důležitých způsobů využití, který zbytečně přenáší overhead ze strany dodavatele na hw spotřebitele.

Jinak to vypadá, že všechno postupně směřuje ke kontejnerizaci. Dokonce to vypadá, že RedHat částečně zahodí svůj RHEV a vše do budoucna pojede na dockeru, včetně virtualizace. Tj. OpenShift Virtualization (Container Platform), kde je první vrstvou kontejnerizace a v rámci ní až virtualizace. Využívají projektu KubeVirt.
Zdar Max

[MP]

Nesmeruje. Narocnost na navrh/provoz kontejneroveho prostredi je mnohem vetsi, nez narocnost na obdobneho reseni pomoci VM.

[Migi]

Směřuje, ale jinak souhlas. Proto také tak rostou veřejné cloudy, které za tebe všechno pořeší za určitý poplatek. A ty řešíš jen tu aplikaci.

[Max]

Bohužel směřuje. Je to složitější, přibývají další vrstvy, další syntaxe pro učení, ale tak je to se vším. Vyšší složitost nepředurčuje konec. Já to beru tak, že je to celé tak nějak v plenkách a to zjednodušení ještě přijde.
Zdar Max

[lertimir]

Díky to je, co jsem potřeboval, moje otázka je už irelevantní. (začal jsem ji psát dopoledne a pak jsem měl oběd a nějaká jednání a další vývoj vlákna už neviděl)

[Bobprasak]

To je imho nesmysl, virtualizace resi problemy se kterejma si kontejnery zatim neumi v x86 poradit (memory management, cpu scheduling, partitioning jw, kloudne sitovani na l2 apod). Kontejner neni nic jinyho nez process na to nezapominejte. Spis se obe technologie budou vhodne doplnovat, kdy na vykonnem hw pobezi spousta virtualek a v nich nejakej kontejner runtime.

[Bobprasak]

Jeste jednou to tu zopakuju kontejner neni druh virtualizace a neni to to zadna vrstva navic. Kontejner je pouze proces obalenej namespacema, cgroupama a pripadne selinux contextem. Nema tudiz takovy moznosti jako je hypervisor kterej komunikuje primo s hw a defakto je to svebytnej os zajistujici prostredi pro vmka. I ten vami zminovanej kubevirt nedela nic jinyho nez jen integruje orchestraci vmka do k8s. Ale to co realne tu vmku spravuje je hypervisor. Vyhodou takoveho reseni je ze muzete zajistit dependency mezi aplikaci co bezi ve vm, blbe se migruje do kontejeru a aplikacnich kontejneru. Muzete vyuzivat vsech tech serepeticek jako jsou proby vic replik apod (pokud to tam vm umi) Nicmene je to porad jedna a ta sama vmka kterou misto virsh start vm poustite treba kubectl scale deployment vm --scale 1.

[Max]

Bohužel jsi to špatně pochopil. Dal jsem i zdroje, aby to bylo jasné. Nikdo netvrdí, že KVM končí. Já jen říkám, že končí RHEV a nastupuje Openshift Virtualization, což je v první řadě kontejnerizace všeho, včetně kvm. Tj. virtuálka uvnitř kontejneru.
Konkrétně pak info třeba tady:
OpenShift virtualization: What's new with virtualization from Red Hat

Role se tedy částečně vyměňují a virtualizační prostředí, které sloužilo pro běh všeho včetně kubernetu, se jakoby zabaluje do kontejneru, který je na prvním místě.
Zdar Max

[Bobprasak]

Ale ta virtualka nebezi "uvnitr" kontejneru, ona se jen jako kontejner spravuje, coz je imho pro pochopeni toho co jsou kontejnery a jak se napr. lisi od virtualek dost zasadni

[Max]

Já o voze, ty o koze. Celou dobu tady mluvím o architektuře (myslel jsem, že je to jasné, minimálně z těch linků, co jsem postnul), ty zase o core implementaci. To je pak jasný, že se nepotkáme.
Zdar Max

Instalací aplikace v dockeru získáš bonusem systém, o kterém nic nevíš a musíš se o něj starat. A můžeš jenom doufat, že se o jeho funkčnost a bezpečnost postaral autor image. Ale když do něj koukneš blíž, tak v lepším případě zjistíš, že je to úplně základní instalace, provedená někdy v dávné minulosti (a která funguje zásadně na něčem jiném, než jsi ty zvyklý) nebo v horším případě je to něco tak šíleně upraveného, že nevíš která bije. Takže za mě je lepší, když to jde, mít vlastní kontejner/VM/něco, do kterého si danou aplikaci nainstaluješ.

[PetebLazar]

Realizovat workflow z větší sady navazujících aplikací (například pro vědecké výpočty) může být pro běžného uživatele značnou výzvou, docker je pro ně svým způsobem blackbox, o němž pouze tuší co do něj má vstupovat a co mohou očekávat na výstupu. V případě, že dockerové řešení nefunguje mají asi relativně malou naději na vyřešení problému, ale procento úspěšných použití dockeru bude asi přesto vyšší než při využití klasického způsobu (instalace nástrojů z repository/githubu/conda/...). Největší výhodou je asi izolace verzí nástrojů v rámci jednotlivých dockerů, případná aktualizace jde na vrub autora a výhodou bývá i přítomnost testovacích dat umožňující ověřit celkovou funkčnost implementace WF v dockeru. V případě sdílení nástrojů v rámci více workflow při klasickém přístupu může nastat problém s nekompatibilitou určité verze sdíleného nástroje. Například výše zmíněná conda (anaconda) tomuto předchází možností vytvoření separátních environmentů s definovanými vlastnostmi (např. verzí Pythonu) pro jednotlivá WF.