Názory k článku
Docker stále v problémech

Možná mi něco uniklo ale nechápu, jak se "Red Hat nakonec zařídil jinak"?

Ta zmínka tam nemusela být, odstraněno. Kdyžtak je to ve zdroji.

uplne stejne jako SUSE, podpora ve stavajicich produktech zmrazena na stare nebo CE verze, v budoucich uz docker nebude.

Oba dva ( RH, teda IBM a SUSE) aktivne prechazi na podman a crio. Vicemene ve RHEL9 a SLES16 po dockeru nezbyde ani ň..

RHEL 8 už obsahuje také podman a cri-o runtime.

jj, SLES taky :D ma reakce byla ze v dalsich major verzich ( a mozna uz i v minor) proste docker jako takovy nebude.

Este by som dodal, ze RH este predtym pracoval na rkt, ktore sa zial moc neuchytilo, lebo to inak bola celkom dobra technologia. Cize ta snaha nahradit docker tam bola uz davno.

A Docker si za to moze sam, chvalili sa ako automaticky zamietaju vsetky pull requesty, ktore by umoznili dockeru lepsie fungovat v kombinacii so systemd: https://static.lwn.net/images/2016/devconf-badge-sm.jpg
V podstate teraz len zbieraju ovocie toho co si v minulosti zasadili. Mali snahu vytlacit distribucie zo serveroveho segmentu, ale to prehnane sebavedomie a arogancia sa im nevyplatila. Asi si neuvedomili, ze docker ako technologia nie je ziadna magia a urobit alternativnu implementaciu nie je zas tak zlozite.

Zostava otazka, co bude do buducna s docker hub, ktory stale ostava de facto standardny repozitar. Tam maju este stale takpovediac nohu vo dverach.

To urcite, Docker si sam muze za to, ze vyslapal cesticku pro nasledovniky. Muze predevsim za to, ze evoluci a praktickymi zkusenostmi z jeho implementace vznikla jina fragmentace daneho ekosystemu, s jinak postavenym rozhranim pro nadstavby pro vetsi clustery, nez na ktere byl puvodne Docker dimenzovan. To asi priste prukopnici radsi nebudou delat nic, a nechaji to na chytre "generaly po bitve", kteri takovehle veci delaji na prvni dobrou.

a nezacal vyslapavat cesticku pro Docker pred nim LXC, OpenVZ, chroot, jail... ? ;-)

3. 10. 2019, 20:30 editováno autorem komentáře

CRI-O, projekt na githubu.

Problém dockeru je podle mne v tom, že toho umí příliš málo a zároveň příliš moc. Když člověk potřebuje kontejner ve smyslu "jail", na to je mnohem lepší LXD. Na jednoduchý vylepšený chroot, ve kterém lze pouze izolovat konkrétní systémovou službu, je mnohem snazší systemd-nspawn. Jako způsob, jak integrovat a balit aplikace tak, aby si je třetí strany mohly co nejsnáze instalovat, bez nároků na virtualizaci sítě, úložišť apod., je zase jednodušší a uživatelsky příjemnější flatpak nebo snap.

Docker sedí tak nějak na průsečíku všech těchto scénářů, ale přitom sám neexceluje v žádném z nich. Jeho hlavní nika v praxi, tj. vývoj, správa a nasazování interních aplikací v korporátech, jde dneska ruku v ruce s cloudovou infrastrukturou a Kubernetem, jenže, jak je v článku řečeno, tím se z Dockeru stává pouhý implementační detail.

V dlouhodobé perspektivě možná Docker skončí podobně, jako kdysi ICQ: ve své době inovativní a úspěšný systém, který odhalil určité možnosti, kterých se pak však chopili silnější hráči a tito postupně přinesli produkty, které možná lépe odpovídaly reálným uživatelským potřebám.

3. 10. 2019, 00:05 editováno autorem komentáře

Jenže podle mě je hlavní výhoda dockeru právě ta vrstevnatost a rozšiřitelnost. Chci aplikaci která potřebuje JBoss není problém stáhnu image z dockerhubu s JBoss, který zase staví na OpenJDK image a ten zase na Alpine. Chci nabízet mojí aplikaci na JBoss napíšu Dockerfile, který vychází z JBoss image. Možná, že tohle lze i v LXD netuším. Na projektu kterém aktuálně dělám používám Kubernetes a dockerové image sestavujeme pomocí mavenu a JIBu a je pravda, že klidně bychom mohli Docker vyměnit za cokoliv jiného co bude mít podporu v K8s.

Jenže to je právě ono. Na OCI založené kontejnery nabízí v tomhle ohledu to samé (dokonce se dají sestavit z Dockerfile). Ale zatímco na OCI založená CRI-O runtime pro Kubernetes nabízí lightweight řešení které dělá jen co je potřeba, Docker je moloch, který se stará i o základní orchestraci. V podstatě se tam duplikuje spousta funkcionality.

Navíc, OCI kontejnery se dají spouštět i bez roota – viz podman.

no právě, stahovat do produkce veřejné image, které nemáš pod kontrolou a které se ti mění pod rukama není vždy průchozí. Dělat si image zase sám, znamená nějakou práci a nevyužiješ tu dědičnost, protože to stejně uděláš v nějakém nástroji najednou. To je to o čem píše klokan.

V dockeru jsem byl jeden z prvních průkopníků, ale dnes již jsem zpátky u jailů, kvm či jiných pro mě stálic, protože docker některé věci zesložiťuje. Nápad, že si vývojáři budou připravovat vlastní image rychle selhává na jejich schopnostech pracovat s linuxem, na nutnosti udržovat aktualizovanou produkci či jednotné prostředí pro provoz.

stahovat do produkce veřejné image, které nemáš pod kontrolou a které se ti mění pod rukama není vždy průchozí

Hlavně ti vývojáři té image obvykle tomu nedávají takovou extrémní péči, jako vývojáři běžné distribuce. Buďto je to méně stabilní a mění se to pod rukama. Nebo to není aktualizované. Image, který by měl stabilitu a bezpečnost distribuce člověk nenajde.

Jojo, vývojář "dodá" takto aplikaci a admin se pak zblázní na tom cokoliv spravovat, nedejbože ladit.

Dockerfile je v podstatě jenom orchestrace. Takže použijete jinou (vytvoříte baliček se závislostmi a install skripty, vytvoříte Ansible roli nebo něco jiného, co Vám bude vyhovovat). A ve finále nebudete muset řesit, jestli to chcete zrovna deploynout na virtuál, kontejner nebo baremetal.

Úplně stejně ve virtuálu jako Docker? Docker pro Mac není nic jiného, než pěkně zabalená VM s Linuxem.

Podman je, cojávim, plně kompatibilní.

No asi to nakoniec kupi Microsoft. Uz sa o to snazil pred par rokmi, ale Docker sa vtedy tvaril ze to nepotrebuje. Teraz je situacia ina a Microsoft jednak nevie co s peniazmi a jednak ma jasnu strategiu Azure vs Docker.

To je docela možné.

To bych skutecne nevylucoval. Dle nasich testu a nasazeni na nejakych hloupostech microsoft posunul i nativní docker ve windows. V mijuposti fungoval jen pres linux virtualizaci. Ted si clovek muze prakticky nahodit i omezeny windows core system.

Odkoupení Microsoftem je i můj dlouhodobý tip.

Docker na Windows, resp. Windows Containers, provozujeme produkčně už více než rok a až na nějaké porodní bolesti to funguje parádně.

Myslim, ze za to moze velmi zly obchodny model Dockeru a hlavne absolutna ignoracia akejkolvek security, takmer nulova podpora Windowsu a ignoracia systemd.
Preto jeho nasadenie v serioznom firemnom prostredi je nemozne.

Ignorování systemd? To snad ne, chcete, aby všechny kontejnery byly dohromady jedna obrovská binárka, běžící pod PID 1 s právy kernelu a na dálku ovládaná Lennartem? </troll>

Tohle je dobrý blábol. Podpora Windows je na super úrovni v podstatě stačí nainstalovat a jedete. Chce kubernetes zaškrtnete si to v nastavení a jede to. Existují kontejnery pro Windows ale nikdo to nepoužívá. Ono taky proč by měl někdo provozovat Docker na Windows místo Linuxu? A k čemu by měl Docker podporovat systemd?

My Docker na Windows používáme produkčně už přes rok a funguje to krásně :) Důvodem je to, že tam potřebujeme pouštět něco, co na jiné platformy neexistuje. Samozřejmě bysme byli radši, abysme měli všechno na Linuxu, ale člověk míní...:)

K čemu by měl Docker podporovat systemd? Možná kvůli distribucím používajícím systemd?

@martinpoljak
"Možná kvůli distribucím používajícím systemd?"

Což jsou efektivně všechny.

Třeba k tomu, aby stav kontejneru šlo ovládat a monitorovat stejně jako kterékoli jiné služby, a aby šlo omezit privilegia daného kontejneru - jak už to dělá např. systemd-nspawn.