Docker Desktop czy Podman? Mniej pamięci może kosztować zgodność narzędzi

Podman może zastąpić Docker Desktop, jeśli projekt korzysta głównie ze standardowych poleceń kontenerowych, a pozostałe narzędzia da się połączyć z jego silnikiem. W opublikowanym teście na Linuksie miał mniejszy narzut pamięci, lecz podobne polecenia nie gwarantują zgodności aplikacji używających socketu Dockera. Przy rozbudowanym środowisku Compose, IDE i testów integracyjnych czas potrzebny na zmianę konfiguracji może przeważyć nad oszczędnością zasobów.

Wydajność zależy też od systemu operacyjnego. Pomiar Docker Engine i Podmana działających bezpośrednio na Linuksie nie pokazuje, ile pamięci zajmą całe środowiska desktopowe ani jak szybko zbudują obraz z plików udostępnionych maszynie wirtualnej na macOS lub Windows. Dlatego wybór dla linuksowej stacji roboczej i wybór dla zespołu używającego różnych systemów wymagają odrębnej oceny.

Co zmierzono: pamięć, start i budowanie obrazu

W teście Leaper na Fedorze 41 zestawiono Docker Engine 27.x z Podmanem 5.4 na tym samym komputerze, a wyniki przedstawiono jako mediany z dziesięciu prób. Budowa wieloetapowego obrazu aplikacji Node.js trwała odpowiednio 38,2 i 40,7 sekundy. Zimny start kontenera Alpine zajął 0,31 i 0,28 sekundy, natomiast narzut pamięci przy bezczynnym kontenerze wyniósł 11,4 i 8,2 MB. W pomiarze przepustowości sieci między kontenerem a hostem wyższy wynik uzyskał Docker: 42,1 wobec 38,7 Gb/s.

W tej konfiguracji Podman zużywał mniej pamięci i szybciej uruchamiał kontener, a Docker Engine szybciej budował wskazany obraz i przesyłał dane w teście sieciowym. Różnica w megabajtach dotyczy narzutu przy bezczynnym kontenerze, nie całkowitego zużycia RAM przez Docker Desktop lub Podman Desktop. Nie można jej więc przemnożyć przez liczbę kontenerów i potraktować jako prognozy oszczędności na laptopie z IDE, bazą danych oraz maszyną wirtualną. Wynik budowania dotyczy z kolei konkretnego obrazu i sposobu pomiaru, a nie każdej przebudowy kodu w codziennej pracy.

Linux: znaczenie architektury i trybu rootless

Dokumentacja Podmana opisuje go jako silnik bez stale działającego demona, z interfejsem poleceń podobnym do Docker CLI i możliwością pracy jako zwykły użytkownik. Przy uruchomieniu rootless powstaje przestrzeń nazw użytkownika, a system musi mieć odpowiednio skonfigurowane zakresy identyfikatorów w plikach /etc/subuid i /etc/subgid. Dla firmy oznacza to możliwość uruchamiania kontenerów bez przyznawania użytkownikowi uprawnień administratora, ale także potrzebę przygotowania stanowisk i sprawdzenia uprawnień do montowanych katalogów.

Na Linuksie trzeba ponadto rozróżnić Docker Engine od Docker Desktop. Instrukcja instalacji Docker Desktop na Linuksie wskazuje, że aplikacja uruchamia maszynę wirtualną, tworzy kontekst desktop-linux i przechowuje obrazy oraz kontenery oddzielnie od silnika działającego bezpośrednio na hoście. Test na Fedorze porównywał właśnie natywne silniki, więc nie mierzył pełnego kosztu Docker Desktop. To ważne także przy migracji: obraz widoczny w dotychczasowym kontekście Dockera nie pojawi się automatycznie w drugim środowisku tylko dlatego, że oba przyjmują podobne polecenia.

macOS i Windows: zgodność zależy od połączenia z silnikiem

Na macOS i Windows kontenery linuksowe korzystają z warstwy wirtualizacji. W rezultacie czas startu całego środowiska, pamięć maszyny oraz dostęp kontenera do plików projektu mogą mieć większe znaczenie niż narzut pojedynczego procesu zmierzony na natywnym Linuksie. Szczególnie projekt często przebudowywany po zmianie pliku źródłowego obciąża również mechanizm udostępniania katalogów między hostem a maszyną. Opublikowane liczby z Fedory nie rozstrzygają, który zestaw będzie szybszy w takim cyklu pracy.

Instrukcja zgodności Podman Desktop opisuje mapowanie socketu dla narzędzi Dockera oraz uruchamianie aplikacji Compose po skonfigurowaniu odpowiedniego rozszerzenia. Na macOS ustawienie zgodności z narzędziami zewnętrznymi jest domyślnie włączone. Na Windows i Linuksie dokumentacja kieruje użytkownika do zmiennej DOCKER_HOST; wskazuje też typowy socket /var/run/docker.sock na macOS i Linuksie oraz nazwany potok Dockera na Windows. Sama zamiana polecenia docker na podman nie zmienia adresu połączenia zapisanego w innej aplikacji.

Dlatego udany start kontenera w terminalu nie wystarcza jako próba migracji całego projektu. Konfiguracja Compose może używać funkcji zależnych od konkretnego silnika, IDE może łączyć się z API, a biblioteka testów integracyjnych lub skrypt może oczekiwać określonej ścieżki socketu. Warto sprawdzić te zależności na rzeczywistym zestawie usług: budowę obrazu, uruchomienie, montowanie plików, testy i ponowną przebudowę po zmianie kodu. Jeśli narzędzie ma na stałe wpisany adres Dockera, trzeba ustalić, czy pozwala go zmienić i czy po zmianie wykonuje cały potrzebny scenariusz.

Licencja: dwa warunki bezpłatnego użycia

Warunki licencji Docker Desktop dopuszczają bezpłatne użycie w małej firmie zatrudniającej mniej niż 250 osób i osiągającej mniej niż 10 mln USD rocznego przychodu. Oba warunki muszą być spełnione jednocześnie. Zawodowe użycie w organizacji poza tym zakresem wymaga płatnej subskrypcji; osobno wymieniono zastosowania prywatne, edukacyjne i niekomercyjne projekty open source. Warunki Docker Desktop nie są tym samym co licencjonowanie otwartych projektów, w tym Docker Engine.

Dla firmy przekraczającej próg subskrypcja stanowi koszt, który warto zestawić z kosztem zmiany środowiska. Przejście na Podmana może wymagać dostosowania skryptów, konfiguracji IDE, testów i procesu CI, nawet gdy podstawowe obrazy uruchamiają się poprawnie. Znaczenie tej pracy zależy od liczby stanowisk oraz od tego, czy zespół używa prostych poleceń, czy rozbudowanych integracji opartych na API Dockera. Bez tych danych nie da się uczciwie przypisać migracji jednej kwoty ani terminu zwrotu.

Który wybór pasuje do projektu

Podman jest mocnym kandydatem dla zespołu pracującego przede wszystkim na natywnym Linuksie, któremu zależy na trybie rootless i który może skierować swoje narzędzia do właściwego socketu. Docker Desktop może oszczędzić pracy tam, gdzie projekt mocno polega na istniejących integracjach z Dockerem, zwłaszcza na stanowiskach z macOS i Windows. Dostępne pomiary wskazują możliwą korzyść w pamięci, lecz nie wyceniają czasu potrzebnego na usunięcie takich zależności.

Rozstrzygająca jest próba na własnym projekcie: należy porównać pamięć całych uruchomionych środowisk, czas budowy i przebudowy obrazu oraz działanie Compose, IDE i testów integracyjnych po przełączeniu silnika. Gdy te elementy działają bez istotnych zmian, mniejszy narzut Podmana może być realną korzyścią. Gdy połączenia z API i socketem wymagają wielu poprawek, wygoda Docker Desktop może mieć większą wartość niż różnica zmierzona dla bezczynnego kontenera.

Przeczytaj także:

• Lokalny model czy API? Oszczędność znika przy złym wykorzystaniu
• Pinecone czy pgvector? Filtry potrafią zmienić zwycięzcę
• PostgreSQL czy MySQL? Benchmark zmienia zwycięzcę wraz z operacją