Začal jsem používat Podman místo Docker Desktop a je to mnohem rychlejší, než jsem si představoval
Můj notebook má docela spolehlivý zvyk dávat mi vědět, když se spustí Docker Desktop. Ne prostřednictvím oznámení, ani zvuku, ani něčeho tak zdvořilého. Jen ventilátor. Jemný, ale neomylný bzučivý zvuk, který se přibližně překládá jako: démon je vzhůru a hladový.
Používal jsem Docker Desktop dostatečně dlouho na to, abych ho nikdy nezpochybňoval. Bylo to prostě to, co jsem instaloval, když jsem potřeboval kontejnery. Nicméně jeden můj kolega mimochodem zmínil, že přešel na Podman Desktop — jednu z nejlepších alternativ k Dockeru pro správu kontejnerů — a rozhodl jsem se tomu věnovat nějaký čas.
Docker Desktop přesně nic špatného neudělal
Má prostě hodně pocitů ohledně tvé RAM.
Abychom byli spravedliví k Dockeru, nástroj si svou reputaci zasloužil. Když byly kontejnery stále novým a mírně zastrašujícím konceptem, Docker Desktop celý koncept zpřístupnil na macOS a Windows. Není potřeba rozumět linuxovým jádrům, hypervizorům nebo síťování virtuálních strojů, aby se kontejner spustil. Docker zabalil složitost do uhlazeného balíčku, který se postaral o nepříjemné části za vás, a po léta byla tato jednodušší práce neocenitelná.
Docker Desktop však také neustále roste ve svých ambicích. Nyní je zde těžké GUI, integrace Kubernetes, vývojová prostředí, rozšíření a úložiště přihlašovacích údajů, které s vámi občas nesouhlasí. Pro týmy, které se na tyto funkce spoléhají, dává platforma smysl. Pro ty z nás, kteří denně spustíme čtyři nebo pět kontejnerů z terminálu a nemůžeme si vzpomenout, kdy naposledy otevřeli Docker Desktop GUI, je to hodně nástrojů na nošení.
Část této tíhy pochází z architektury pod tím. Na macOS a Windows Docker Desktop spouští kontejnery prostřednictvím Linuxového virtuálního stroje, což samo o sobě není problém. Přesto to znamená, že je vždy zapojena vrstva virtualizace. Docker také závisí na trvalém pozadí běžícím demonu, dockerd, pro správu kontejnerů. Docker Desktop to vše pěkně zvládá, což je součástí jeho přitažlivosti, ale také to znamená, že mezi vámi a kontejnery, které se snažíte spustit, je více pohyblivých částí a větší využití zdrojů na pozadí.
Co dělá Podman Desktop jinak (a proč to vlastně cítíte)
Root? Tady to neděláme
Co mě přitáhlo k Podman Desktopu, bylo, jak okamžitý je. Napíšu podman run, kontejner se spustí a proces se mi nepředstavuje do cesty. Nikdy nesedím a nečekám, až se probudí nějaká běžící služba, protože Podman používá architekturu bez demona. Na Linuxu každý příkaz běží jako vlastní proces přímo pod vaší shellovou relací. Na macOS a Windows Podman komunikuje s lehkým Linuxovým VM přes rychlé SSH připojení, spustí kontejner a pak se odtáhne, jakmile je úloha dokončena.
Tento design má znatelný dopad na systémové prostředky během celého dne. Podman Desktop je na nečinném režimu s pozoruhodně malým zatížením, zatímco démon a GUI Docker Desktopu mají tendenci stále konzumovat paměť i když žádné kontejnery neběží. Rozdíl je obzvlášť patrný, pokud již máte otevřený prohlížeč plný záložek, editor kódu, terminály a půl tuctu běžících aplikací na pozadí, které soutěží o RAM. Není to typ transformace, která by povznesla váš laptop nad stůl, byť snížení tření se po několika dnech pravidelného používání stává snadno patrným.
Nakonec jsem si také začal cenit výchozího bezpečnostního modelu Podmanu. Kontajnery běží hned od začátku bez práv root, což znamená, že fungují pod vaším běžným uživatelským účtem, a ne s vyššími systémovými oprávněními. Pokud se nějaký kontejner pokazí, rozsah škod zůstává mnohem menší, protože proces automaticky nezískává přístup root k systému. Pro většinu lokálního vývoje to nijak viditelně nemění váš každodenní pracovní postup. Nicméně jde o skutečně lepší bezpečnostní postoj, zejména když stahujete třetí strany obrázky, které jste si sami nevytvořili.
Přechod na CLI byl také snazší, než jsem očekával. Podman si zachovává silnou kompatibilitu se strukturou příkazů Dockeru, takže většina mého stávajícího pracovního postupu se přenesla téměř beze změn. Vytvořil jsem alias docker=podman a pokračoval jsem v používání příkazů, které mám už zafixované v paměti: run, ps, images, rmi a ostatní. Během jednoho či dvou dnů jsem prakticky přestal o přechodu vůbec přemýšlet.
Podman Desktop také výrazně vyzrál, zejména na macOS a Windows, kde se nyní čistě integruje s hostitelským systémem a využívá rychlé technologie sdílení souborů jako VirtioFS. Pod povrchem Podman stále spoléhá na Linux VM přes Podman machine, podobně jako Docker Desktop v pozadí. Rozdíl je v tom, že Podman přímo ukazuje více z těchto strojů, což vám umožňuje VM sami upravovat, konfigurovat a spravovat, místo abyste ji schovávali za vrstvami abstrakce. Zlepšení rychlosti, které jsem si všiml, přišlo díky štíhlejšímu hostovskému prostředí a absenci neustále běžícího démona, ne kvůli odstranění virtualizace.
S Podmanem jsou některé nevyhlazené detaily
Tady je to, čeho jsem se vlastně dotkl
Migrace nebyla bezproblémová a raději vám to řeknu hned na začátku, než aby jste se to dozvěděli uprostřed projektu.
Pokud už víte, jak Docker Compose používat dokonale, podpora Compose je pravděpodobně nejtěžší část přechodu. Podman může s Compose pracovat dvěma hlavními způsoby: prostřednictvím podman-compose, komunitní implementace v Pythonu, nebo tím, že nasměrujete oficiální binární soubor docker-compose na API socket Podmanu pomocí proměnné prostředí DOCKER_HOST. Pro jednoduché Compose soubory oba způsoby fungují dobře. Jakmile se však váš setup začne zapojovat složitější síťování, vlastní mosty nebo specifické chování služeb, můžete narazit na mezery. (A pokud spoléháte na nástroje, které automaticky vytvářejí Compose soubory z běžících Docker kontejnerů, očekávejte, že budete muset provést několik ručních úprav).
Kontejnery bez kořenových práv mohou také trochu zkomplikovat připojování svazků. Narazil jsem okamžitě na chyby „permission denied“ u některých bind montáží, dokud jsem nezačal přidávat štítky :Z k mapování svazků nebo nakonfigurovat userns_mode: keep-id, aby kontejnery zdědily správnou uživatelskou identitu z hostitelského stroje. Nic z toho není zásadní problém, ale pokud vaše soubory Compose provádějí víc než jen základní orchestraci služeb, stojí za to si vyhradit čas na vyhlazení místních zvláštností.
Širší ekosystém je stále zcela postaven kolem Dockeru. Když se něco pokazí a začnete procházet Stack Overflow nebo GitHub issues, téměř každé řešení předpokládá, že používáte Docker. Přenesení těchto oprav na Podman obvykle vyžaduje jen drobné úpravy. Občas jsem se však ocitl při zkoumání linuxových sub-user namespaces a konfigurací /etc/subuid, abych pochopil, proč se model oprávnění choval jinak.
Nepřeinstaluji svou svalovou paměť
Stále bych doporučoval Docker Desktop spoustě lidem. Pokud ho váš tým už používá, vaše nástroje na něm závisí, nebo chcete mít nejlépe zdokumentovanou cestu vývoje kontejnerů, není na tom nic špatného zůstat u velryby. Znalost má hodnotu, zvláště když se termíny blíží.
Nicméně už k Docker Desktop nepřistupuji jako k automatickým vstupním dveřím do každého lokálního kontejnerového úkolu. Podman mi připomněl, že některé nástroje působí lépe ne proto, že křičí hlasitěji, ale protože opustí místnost, jakmile práce začne. A to je pravděpodobně nejvyšší pochvala, kterou mohu Podmanu udělit.