Vlákno názorů k článku
Docker stále v problémech od klokan - Problém dockeru je podle mne v tom, že...

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.