Docker, nebo Podman: výkon nerozhodne, rozdíl je v architektuře

Při volbě mezi Dockerem a Podmanem rozhoduje především to, jak chcete spravovat kontejnery a zda na engine navazují vaše nástroje. Docker používá daemon, Podman může kontejnery spravovat bez trvale běžícího daemona. Oba podporují provoz bez oprávnění root; rozdíl v samotném výkonu obvykle není dostatečný důvod ke změně.

Pro projekt pevně svázaný s Docker Compose bývá jednodušší zůstat u Dockeru. Podman dává zvláštní smysl na linuxovém serveru, kde mají uživatelé spravovat vlastní kontejnery nebo kde chcete služby popsat pro systemd. Před migrací ale musí obstát celý postup: Compose, síťování, svazky i automatizace.

Daemon a rootless provoz

Klient Dockeru předává požadavky daemonu dockerd, který spravuje kontejnery. Rootless režim tuto architekturu zachovává: dokumentace Dockeru uvádí, že daemon i kontejnery pak běží v uživatelském jmenném prostoru bez oprávnění root. Počítat je proto stále nutné s uživatelskou službou daemona a jejím socketem. Rootless Docker je možnost, pokud potřebujete omezit oprávnění a současně zachovat prostředí postavené na Dockeru.

Manuál Podmanu popisuje engine bez daemona, příkazy podobné Dockeru a možnost spouštět většinu z nich jako běžný uživatel. Kontejnery vytvořené tímto uživatelem nejsou v Podmanu viditelné ostatním účtům ani instanci spuštěné jako root. Oddělené jsou také uživatelské obrazy a úložiště, takže správce musí vědět, pod kterým účtem hledá data a běžící kontejnery.

Rootless provoz závisí na nastavení hostitele, zejména na mapování uživatelských a skupinových ID. U Podmanu má význam i souborový systém: jeho rootless úložiště kontejnerů nelze umístit na NFS a další distribuované systémy, které nerozumějí uživatelským jmenným prostorům. Je-li domovský adresář na NFS, může být úložiště Podmanu nastavené na místním disku. Toto omezení se týká umístění úložiště enginu; samo o sobě neříká, že každá data připojená do kontejneru musejí ležet lokálně.

Podobné příkazy ještě nezaručují stejný postup

Příkazy pro stažení obrazu nebo spuštění jednoduchého kontejneru jsou si blízké. Složitější projekt však může předpokládat konkrétní chování Docker Compose, dostupnost Docker socketu nebo vlastnosti sítě a svazků. Záměna názvu příkazu proto pro posouzení kompatibility nestačí.

Popis příkazu podman compose uvádí, že příkaz předává práci externímu poskytovateli, například Docker Compose nebo podman-compose, a umožňuje mu komunikovat se socketem Podmanu. Záleží tedy také na nainstalovaném poskytovateli. Pokud je dostupný Docker Compose, má podle dokumentace přednost před podman-compose; stejný příkaz tak nemusí v každém prostředí znamenat stejnou sestavu nástrojů.

U existujícího projektu mají při zkušební migraci největší hodnotu tyto kontroly:

• Compose: Spusťte celou sestavu včetně závislostí služeb, kontrol stavu a ukončení. Zjistěte, který poskytovatel Compose příkaz skutečně obsluhuje.
• Síťování: Ověřte komunikaci mezi službami, publikování portů a přístup z hostitele. Zvlášť sledujte chování v rootless režimu, pokud dosavadní sestava běžela s vyššími oprávněními.
• Svazky: Ověřte zápis do připojených adresářů a vlastnictví vytvořených souborů. Při změně uživatelského účtu se může změnit přístup k datům, i když kontejner používá stejný obraz.
• Automatizace: Projděte nástroje, které očekávají Docker socket, jeho API nebo konkrétní výstup příkazů. Úspěšné spuštění kontejneru ještě neověřuje navazující sestavení a nasazení.

Kdy pomůže systemd a Quadlet

Na linuxovém serveru může být důležitější způsob správy služby než způsob jejího spuštění z příkazové řádky. Dokumentace Quadletu popisuje soubory pro kontejnery, sítě a svazky, z nichž se generují jednotky systemd. Fungují jako systémové i uživatelské služby a mohou používat obvyklá nastavení systemd, například závislosti. Quadlet vyžaduje cgroup v2.

Compose soubor se na Quadlet nepřevádí pouhou změnou přípony: služby, sítě a svazky je třeba vyjádřit odpovídajícími definicemi. Pro rootless službu patří soubory do cesty určené pro uživatelské jednotky. Má-li služba běžet i po odhlášení uživatele, musí tomu odpovídat také nastavení uživatelského systemd. Docker lze se systemd provozovat rovněž; u rootless varianty systemd spravuje jeho uživatelský daemon. Podman s Quadletem se hodí tam, kde chcete spravovat definované kontejnery přímo jako služby hostitele.

Co lze vyvodit z měření výkonu

Měření Umeå University z roku 2020 našlo mezi Dockerem a Podmanem malé rozdíly v testech procesoru, paměti a disku. Proběhlo na jednom notebooku a nezahrnovalo síťový výkon. Výsledek podporuje závěr, že od samotné výměny enginu nelze očekávat podstatné zrychlení každé aplikace; není to univerzální záruka stejné rychlosti při jiném úložišti, síti nebo způsobu sestavení obrazu.

Výkon konkrétní služby může více ovlivnit její zátěž, hostitelský souborový systém, připojené adresáře a nastavení rootless síťování. Pro rozhodnutí o migraci proto dává smysl měřit vlastní aplikaci v konfiguraci, kterou hodláte provozovat. Čas startu kontejneru, rychlost sestavení obrazu a odezva aplikace jsou různé veličiny; zlepšení jedné nemusí zlepšit ostatní. Malý rozdíl v izolovaném benchmarku také nevyváží změnu, kvůli níž přestanou fungovat nástroje týmu.

Volba podle prostředí

• Lokální vývoj: Docker je přímá volba pro tým, jehož projekt a doplňkové nástroje už používají Docker Compose. Podman připadá v úvahu, pokud chcete pracovat pod běžným účtem a celá sestava projde zkouškou kompatibility.
• Linuxový server: Podman vyhovuje správě kontejnerů pod oddělenými uživatelskými účty bez trvale běžícího daemona. Pokud provoz závisí na Docker socketu, může být menší změnou rootless Docker.
• Služby pod systemd: Podman s Quadletem nabízí definice kontejnerů jako systémových nebo uživatelských jednotek. Při volbě zohledněte cgroup v2, umístění definic a běh uživatelské služby po odhlášení.
• CI: Rozhodují požadavky runneru, sestavovacích kroků a nástrojů napojených na API enginu. Vyzkoušejte celou pipeline včetně sestavení, testu a úklidu prostředků, nikoli pouze spuštění obrazu.

Jestliže současný provoz funguje, samotné měření rychlosti zpravidla migraci neospravedlní. Důvod ke změně vzniká spíše tehdy, když požadovaný model oprávnění, správa služeb nebo oddělení uživatelů přinese konkrétní provozní výhodu a kompatibilita celého postupu zůstane zachovaná.

Přečtěte si také:

• Lokální LLM, nebo cloud: levnější volbu mění vytížení
• Dva dny doma, nebo kancelář: experiment nenašel pokles výkonu
• Claude Code, nebo Codex: benchmark nezná váš repozitář