Podman czy Docker na VPS: kluczowe różnice w działaniu

Czym faktycznie różnią się Podman i Docker

Podman i Docker uruchamiają te same obrazy OCI (open container initiative) na VPS, więc wybór nie dotyczy tego, jakie oprogramowanie można uruchomić. Różnica tkwi w modelu procesów. Docker uruchamia demona z uprawnieniami root, który zarządza każdym kontenerem, a polecenie docker jest niewielkim klientem, który zleca temu demonowi wykonanie pracy. Podman nie posiada demona: podman run uruchamia kontener jako proces potomny wywołującego go użytkownika, bez konieczności posiadania podwyższonych uprawnień.

Wszystkie pozostałe różnice wynikają z tego faktu. Automatyczne uruchamianie staje się zadaniem systemd, a nie demona. Własność wolumenów jest przekazywana przez przestrzeń nazw użytkownika (user namespace), więc właściciel widoczny za pomocą ls -l na hoście nie jest właścicielem widzianym przez kontener. Porty poniżej 1024 odmawiają powiązania, dopóki nie zostanie zmienione ustawienie jądra systemu. Interfejs wiersza poleceń docker działa poprawnie dzięki wrapperowi, aż do momentu, gdy wymagane jest użycie gniazda (socket) Docker.

Brak demona: co faktycznie działa po uruchomieniu kontenera

Na hoście Docker polecenie pstree -a pokazuje dockerd jako root, containerd obok niego oraz jeden proces containerd-shim-runc-v2 na każdy uruchomiony kontener. Aplikacja jest procesem potomnym tego shim, a shim jest procesem potomnym PID 1. Nic nie łączy kontenera z powłoką, która go uruchomiła. Zatrzymanie demona powoduje utratę płaszczyzny sterowania dla wszystkich kontenerów na maszynie, a przy wyłączonym domyślnym ustawieniu live-restore, polecenie systemctl restart docker restartuje również kontenery.

Podman nie posiada odpowiednika tego procesu. Uruchomienie kontenera tworzy jeden proces conmon (monitor kontenera), który zarządza głównym procesem kontenera i jest własnością użytkownika, który wydał polecenie.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

Polecenie ps powinno wyświetlić conmon działające jako użytkownik zalogowany, a nie jako root, a curl powinno zwrócić 200. Ponieważ żaden centralny serwis nie jest właścicielem kontenera, sudo apt upgrade podman nie zatrzymuje niczego, co już działa, a awaria monitora jednego kontenera nie wpływa na pozostałe.

Brak demona wiąże się również z pewnymi kosztami. Nic nie uruchamia kontenerów automatycznie po restarcie systemu. Mechanizm --restart=always w Dockerze to obietnica, którą demon spełnia podczas rozruchu; w Podmanie zastępuje go systemd, do czego służy sekcja quadlet poniżej.

Gniazdo (socket) to druga strona zagadnienia. /var/run/docker.sock jest punktem końcowym API (interfejsu programowania aplikacji), którego właścicielem jest root. Każdy proces, który może zapisać dane do tego gniazda, może uruchomić uprzywilejowany kontener montujący system plików hosta. Dodanie użytkownika do grupy docker nadaje mu uprawnienia roota okrężną drogą, co warto przeanalizować w kontekście przyznawania każdemu kontu serwisowemu tylko niezbędnych uprawnień. Podman nie udostępnia gniazda, dopóki nie zostanie o to poproszony, a uzyskane gniazdo należy do pojedynczego użytkownika w /run/user/<uid>/podman/podman.sock.

Instalacja Podman na Ubuntu 24.04 i weryfikacja trybu rootless

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

Pakiet uidmap dostarcza newuidmap oraz newgidmap. Są to pomocnicze pliki binarne z ustawionym bitem setuid, które pozwalają zwykłemu użytkownikowi na przypisanie zakresu podrzędnych identyfikatorów (subordinate IDs); bez nich kontenery w trybie rootless nie uruchomią się. Polecenie podman info powinno zwrócić rootless: true.

W sierpniu 2026 roku Ubuntu 24.04 zawiera wersję Podman 4.9, a Debian 13 wersję 5.x. Ta różnica jest istotna, ponieważ pliki quadlet wymagają wersji 4.4 lub nowszej, a pliki quadlet .pod wymagają wersji 5.0. Przed skopiowaniem przykładu z oficjalnej dokumentacji należy wykonać podman --version.

Każdy użytkownik działający w trybie rootless wymaga zakresu podrzędnych identyfikatorów:

grep "$USER" /etc/subuid /etc/subgid

Użytkownik utworzony za pomocą adduser w systemie Ubuntu otrzymuje taki zakres automatycznie. Użytkownik utworzony przez useradd -M lub narzędzie konfiguracyjne często go nie posiada, co skutkuje błędem:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Należy przypisać zakres, a następnie zresetować pamięć masową użytkownika, aby zastosować nowe mapowanie:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

Kolejna niespodzianka przy pierwszym uruchomieniu: Podman nie zakłada domyślnie korzystania z Docker Hub. Krótka nazwa obrazu jest rozwiązywana względem unqualified-search-registries w pliku /etc/containers/registries.conf, a w skrypcie bez przypisanego terminala pobieranie kończy się błędem short-name resolution enforced but cannot prompt without a TTY. Zawsze należy podawać pełną nazwę obrazu. Należy używać docker.io/library/nginx:1.27 zamiast nginx.

Co faktycznie zyskujesz dzięki kontenerom rootless na wynajętym serwerze

Kontener rootless działa wewnątrz przestrzeni nazw użytkownika (user namespace), czyli funkcji jądra, która nadaje procesowi własną, prywatną mapę identyfikatorów użytkowników (UID). Wewnątrz tej przestrzeni superużytkownik kontenera ma UID 0. Na zewnątrz, w systemie VPS, ten sam proces jest zwykłym użytkownikiem, na którego jesteś zalogowany. Uprawnienia root w kontenerze nie są uprawnieniami root w systemie hosta.

To jest rzeczywisty zakres korzyści. Obraz wymagający uruchomienia jako root, aplikacja webowa z luką umożliwiającą zdalne wykonanie kodu (RCE) czy próba ucieczki z kontenera wymagająca uprawnień UID 0 na hoście – wszystkie te przypadki kończą się posiadaniem jedynie uprawnień Twojego nieuprzywilejowanego użytkownika, a nie uprawnień całego systemu. Tryb rootless nie chroni przed błędami w jądrze systemu (kernel bugs) ani przed dostępem do Twoich własnych plików, ponieważ proces po ucieczce działa z Twoimi uprawnieniami i może odczytać wszystko, co Ty. Izolowana jednostka ma co najmniej tak samo duże znaczenie jak mapowanie UID, co łatwiej zauważyć w FreeBSD jail, który otacza całe środowisko użytkownika administrowane jak mała maszyna, zamiast warstwowego obrazu pobranego z rejestru.

Docker również może działać w trybie rootless. dockerd-rootless-setuptool.sh install konfiguruje demona dla każdego użytkownika i działa to poprawnie. Różnica polega na tym, co jest ustawione domyślnie. W przypadku Podman tryb rootless jest aktywny bez dodatkowej konfiguracji, więc pierwszą napotkaną przeszkodą jest kontener, który nie może powiązać się z portem 80, zamiast usługi, która po cichu działała jako root przez dwa lata.

Dlaczego pliki w moich wolumenach mają właściciela o UID 100999?

Wynika to z tej samej przestrzeni nazw użytkownika (user namespace). UID 0 w kontenerze jest mapowany na UID użytkownika w systemie hosta. UID 1 w kontenerze jest mapowany na pierwszy identyfikator w zakresie subuid i kolejne wartości rosną od tego punktu. Przy zakresie zaczynającym się od 100000, UID 1000 w kontenerze staje się 100999 na hoście.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Kontener wyświetla 1000. Lista plików na hoście wskazuje właściciela 100999, ponieważ 100000 plus 1000 minus 1 daje 100999. Nic nie jest uszkodzone, a zwykłe polecenie chown nie rozwiąże problemu, ponieważ użytkownik bez uprawnień nie może zmieniać właściciela plików poza przestrzenią nazw.

Cztery sposoby rozwiązania problemu:

• podman unshare chown 1000:1000 "$PWD/data" wykonuje chown wewnątrz tej samej przestrzeni nazw użytkownika, gdzie liczby mają znaczenie zgodne z interpretacją kontenera.
• -v "$PWD/data:/data:U" prosi Podman o automatyczną korektę właściciela katalogu źródłowego. Należy używać tego na świeżym katalogu, a nie na istniejących danych.
• --userns=keep-id mapuje UID hosta na ten sam UID wewnątrz kontenera, dzięki czemu nowe pliki są tworzone z Twoim UID jako właścicielem.
• Nazwany wolumen, taki jak -v appdata:/data, pozwala uniknąć tego problemu, ponieważ Podman tworzy go wewnątrz własnej pamięci masowej z poprawnie ustawionym właścicielem.

Jeśli spotkałeś się z tym w Docker, jest to ten sam problem na wyższym poziomie. Zmienne PUID i PGID, które udostępnia wiele obrazów ustawiają UID używany przez proces wewnątrz kontenera, a w przypadku bezrootowego Podman ten UID jest mapowany po raz drugi. PUID=1000 wewnątrz bezrootowego kontenera nadal zapisuje pliki na hoście z właścicielem 100999. Wybieraj numery z uwzględnieniem tego drugiego mapowania lub przenieś dane do nazwanego wolumenu i przestań się tym przejmować.

Dwie dodatkowe uwagi dotyczące montowania. Flagi :z oraz :Z widoczne w przykładach dla Fedora i RHEL to opcje zmiany etykiet SELinux; w systemie Ubuntu używany jest AppArmor, więc nie mają one tam zastosowania. Bezrootowy Podman nie może również zamontować katalogu hosta, do którego użytkownik nie ma uprawnień odczytu, co jest zamierzonym zabezpieczeniem, a nie błędem.

Dlaczego bezrootowy Podman odmawia udostępnienia portu 80?

Powiązanie portu o numerze poniżej 1024 wymaga uprawnień, których użytkownik nie posiada. Komunikat błędu wskazuje rozwiązanie:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

Dostępne są dwa rozwiązania. Można obniżyć próg dla całego hosta:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Ostatnie polecenie powinno zwrócić 80. Należy pamiętać, co robi to ustawienie: każdy użytkownik na maszynie może teraz powiązać porty 80 i 443, a nie tylko ten uruchamiający kontenery. Na VPS z jednym administratorem jest to akceptowalny kompromis. Na serwerze współdzielonym z innymi użytkownikami – nie. Drugim rozwiązaniem jest udostępnienie portu 8080 i umieszczenie przed nim reverse proxy, co jest rozwiązaniem zalecanym, jeśli certyfikaty są wydawane i odnawiane przez certbot na nginx.

Bezrootowe udostępnianie portów zmienia również sposób, w jaki aplikacja widzi ruch. Podman 4.x domyślnie używa slirp4netns z obsługą portów rootlesskit, a przekierowane połączenia docierają z nadpisanym adresem źródłowym, przez co logi dostępu rejestrują każdego odwiedzającego jako 10.0.2.100. Podman 5.0 zmienił ustawienie domyślne na pasta, co pozwala zachować rzeczywisty adres klienta. W wersji 4.x --network slirp4netns:port_handler=slirp4netns przywraca prawdziwy adres źródłowy, kosztem pewnego spadku przepustowości.

W tym rozwiązaniu występuje jedna pozytywna cecha. Bezrootowy udostępniony port jest zwykłym gniazdem nasłuchującym, należącym do normalnego procesu, więc reguły firewalla mają do niego zastosowanie. Docker udostępnia porty poprzez tworzenie reguł NAT (network address translation) oraz własnych reguł przekierowań, co jest przyczyną, dla której udostępniony port Dockera ignoruje regułę ufw, która miała go blokować. Podman działający z uprawnieniami roota korzysta z podobnych mechanizmów i dziedziczy ten sam problem. Wersja bezrootowa nie ma tej wady.

Czy moje pliki Docker Compose działają w środowisku Podman?

W większości przypadków tak, na dwa różne sposoby. Pierwszym z nich jest podman-compose, czyli oddzielna implementacja, która odczytuje ten sam plik i steruje interfejsem CLI narzędzia Podman:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

Drugim sposobem jest użycie oryginalnego Docker Compose, który komunikuje się z kompatybilnym z Dockerem API narzędzia Podman poprzez gniazdo użytkownika:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

Polecenia docker compose ps oraz podman ps powinny wyświetlać te same kontenery, ponieważ istnieje tylko jeden ich zestaw. Rozpoznawanie nazw również działa: domyślny backend sieciowy narzędzia Podman, netavark, uruchamia aardvark-dns, dzięki czemu kontenery w sieci zdefiniowanej przez użytkownika odnajdują się nawzajem po nazwach.

Istnieją jednak pewne ograniczenia. Wszystkie elementy montujące /var/run/docker.sock muszą zostać przekierowane na gniazdo Podman lub usunięte. Opcja network_mode: host zachowuje się inaczej w przestrzeni nazw użytkownika. Funkcja depends_on z condition: service_healthy jest obsługiwana w różnym stopniu w zależności od wersji podman-compose. Opcja restart: always nie przetrwa samodzielnie restartu systemu, co zostanie rozwiązane w następnej sekcji. Compose pozostaje dobrym sposobem na opisanie wielokontenerowego stosu w jednym pliku, a w środowisku Podman pełni rolę warstwy translacyjnej. W przypadku stosu, który ma być utrzymywany przez lata, należy przekonwertować go na quadlets i zachować jedną abstrakcję zamiast dwóch.

Pody: koncepcja, dla której Docker nie ma odpowiedzi

Pod to grupa kontenerów współdzielących jedną przestrzeń nazw sieciowych (network namespace). Podman uruchamia niewielki kontener infra, aby utrzymać tę przestrzeń otwartą, a członkowie grupy komunikują się ze sobą przez 127.0.0.1 bez konieczności definiowania sieci przez użytkownika czy korzystania z mechanizmów service discovery.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

Polecenie podman pod ps powinno wyświetlić pod Running z trzema kontenerami, wliczając w to kontener infrastrukturalny (infra container). Kontener web uzyskuje teraz dostęp do Redis pod adresem 127.0.0.1:6379, a nie app-cache:6379. Ze współdzielonej przestrzeni nazw wynikają dwie zasady: porty należy publikować na poziomie poda, a nie poszczególnych członków, oraz żadnych dwóch członków nie może nasłuchiwać na tym samym porcie.

Jest to model znany z Kubernetes, a Podman w pełni go wykorzystuje. podman kube generate app > app.yaml generuje manifest Kubernetes na podstawie aktualnie uruchomionych zasobów (w starszych pakietach używa się polecenia podman generate kube), a podman kube play app.yaml odtwarza go na innym hoście. Quadlet posiada typ jednostki .kube, który uruchamia taki plik jako usługę systemd. Jest to istotnie odmienne podejście do grupowania usług i stanowi najsilniejszy argument za wyborem narzędzia Podman, jeśli w przyszłości planowane jest wdrożenie Kubernetes.

Automatyczny start bez demona: jednostki Quadlet

Quadlet to generator systemd. Przekształca on krótki plik opisujący kontener w rzeczywistą usługę systemd podczas rozruchu. Pliki należy umieszczać w ~/.config/containers/systemd/ dla użytkownika bez uprawnień roota lub w /etc/containers/systemd/ dla roota.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume może być niemal puste, ponieważ to nagłówek sekcji tworzy wolumen:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Nazwa usługi pochodzi od nazwy pliku: caddy.container staje się caddy.service. Nie należy uruchamiać systemctl --user enable caddy. Wygenerowanych jednostek nie można włączać, a systemd zwraca Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Sekcja [Install] odpowiada za uruchomienie kontenera podczas rozruchu, a daemon-reload regeneruje jednostkę po edycji pliku.

Oto ustawienie, które sprawia trudności większości użytkowników:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Należy oczekiwać Linger=yes. Bez włączonego linger, systemd zamyka całą sesję użytkownika po rozłączeniu ostatniego połączenia SSH, co powoduje zatrzymanie wszystkich kontenerów bez uprawnień roota i uniemożliwia ich automatyczny start przy kolejnym rozruchu. Kontenery znikające po wylogowaniu zawsze wynikają z tego powodu.

Ponieważ kontener jest głównym procesem zwykłej jednostki usługi, mają do niego zastosowanie standardowe mechanizmy kontroli systemd. MemoryMax= oraz CPUQuota= w sekcji [Service] działają dokładnie tak samo, jak w przypadku każdej innej usługi zarządzanej przez systemd. Wymaga to cgroup v2 (control group w wersji 2), z której Ubuntu korzysta domyślnie od wersji 22.04. Weryfikację można przeprowadzić za pomocą podman info | grep -i cgroup.

Aktualizacje posiadają własny mechanizm dopasowywania. AutoUpdate=registry wraz z systemctl --user enable --now podman-auto-update.timer sprawdza rejestr pod kątem nowszego obrazu o tym samym tagu, restartuje jednostkę i wycofuje zmiany do poprzedniego obrazu, jeśli nowy kontener nie uruchomi się poprawnie. Warto najpierw wykonać podman auto-update --dry-run, aby sprawdzić, jakie zmiany zostaną wprowadzone. Starsze polecenie podman generate systemd nadal istnieje, lecz jest uznawane za przestarzałe, dlatego dla wszystkich nowych rozwiązań należy stosować quadlety.

Gdzie alias docker działa, a gdzie nie

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker instaluje wrapper /usr/bin/docker, który wywołuje Podman. Bez pliku nodocker każde wywołanie najpierw wyświetla Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.. Wrapper obsługuje polecenia używane codziennie: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Lista elementów, które nie są przenoszone, jest krótsza i bardziej istotna. Tryb Swarm nie posiada odpowiednika, więc stosy Swarm nie mają gdzie zostać wdrożone. Narzędzia komunikujące się z gniazdem Docker wymagają wyeksportowania gniazda Podman, a niektóre z nich nadal wykrywają różnice; provider Docker w Traefik działa po wskazaniu na /run/user/<uid>/podman/podman.sock, podczas gdy Watchtower nie ma zastosowania, ponieważ podman auto-update wykonuje to zadanie. Magazyn danych jest odrębny, więc Podman nie widzi obrazów pobranych wcześniej przez Docker, a podman images na aktywnym hoście Docker na początku pozostaje pusty.

Migracja działającego stosu krok po kroku

1. Utwórz lub wybierz użytkownika bez uprawnień roota, który będzie właścicielem kontenerów, i potwierdź, że posiada on zakres w /etc/subuid.
2. Pobierz ponownie wszystkie obrazy z rejestrów, używając pełnych nazw. Podman posiada własny magazyn obrazów i nie odczyta danych z Docker.
3. Przenieś lokalnie zbudowane obrazy za pomocą docker save app:1.4 | podman load.
4. Zatrzymaj kontener Docker, skopiuj zawartość każdego wolumenu z /var/lib/docker/volumes/<name>/_data, a następnie popraw uprawnienia za pomocą podman unshare chown -R 1000:1000 <path>.
5. Rozstrzygnij kwestię portów: udostępnij porty powyżej 1024 za reverse proxy lub skonfiguruj net.ipv4.ip_unprivileged_port_start.
6. Utwórz jeden plik Quadlet dla każdego kontenera, uruchom systemctl --user daemon-reload i wystartuj każdą usługę.
7. Uruchom sudo loginctl enable-linger <user>, zrestartuj VPS, zaloguj się ponownie i sprawdź, czy podman ps ponownie wyświetla każdą usługę.

Oba silniki nie współdzielą żadnych zasobów: posiadają oddzielne magazyny obrazów i oddzielne sieci. Dzięki temu można uruchamiać oba silniki podczas migracji, a jedynym punktem spornym może być numer portu hosta. Przenieś jedną usługę, monitoruj ją przez dobę, a następnie przenieś kolejną.

Podman czy Docker: co wybrać na VPS?

Pozostań przy Docker, jeśli Twój stos technologiczny opiera się na plikach compose utrzymywanych również przez inne osoby lub jeśli korzystasz z narzędzi komunikujących się z gniazdem Docker. Zgodność z rozwiązaniami używanymi przez większość społeczności jest istotną zaletą, a Docker oferuje jej więcej. Zespół, którego członkowie używają Dockera na swoich laptopach, zyskuje konkretne korzyści z uruchamiania tego samego silnika w środowisku produkcyjnym.

Przejdź na Podman, jeśli VPS obsługuje kilka usług, którymi zarządzasz w pełni samodzielnie, lub jeśli chcesz, aby każda aplikacja działała na koncie użytkownika bez uprawnień, bez konieczności tworzenia grupy docker w systemie. Znaczenie ma również dystrybucja: RHEL i jego pochodne dostarczają Podman jako wspierany silnik, więc na tych systemach Podman jest rozwiązaniem generującym mniej problemów. Jeśli mimo to chcesz używać Docker na takim hoście, ścieżka dnf w systemach Rocky Linux i AlmaLinux rozpoczyna się od usunięcia nakładki podman-docker, która domyślnie przejmuje polecenie docker. Jeśli zarządzasz już pozostałymi elementami za pomocą jednostek systemd, quadlety będą wydawać się brakującym elementem układanki, a nie nowym narzędziem do nauki.

Warto wspomnieć o rozwiązaniu pośrednim. Podman w trybie rootful zachowuje się podobnie do Docker, utrzymuje polecenie docker za pośrednictwem nakładki i nadal eliminuje konieczność działania demona w tle. Traci jednak zalety trybu bez uprawnień (rootless), który realnie wpływa na poziom bezpieczeństwa, dlatego należy traktować to rozwiązanie jako etap przejściowy.

Jeśli dopiero konfigurujesz swój pierwszy host kontenerowy, konfiguracja i zabezpieczanie Docker na świeżym VPS jest krótszą drogą, a zdobyta wiedza nie pójdzie na marne. Obrazy i wolumeny są tymi samymi obiektami w obu silnikach, więc późniejsza migracja wpłynie głównie na sposób nadzorowania usług, a w niewielkim stopniu na pozostałe aspekty.

FAQ

Czy Podman jest bezpośrednim zamiennikiem Docker?

W zakresie wpisywanych poleceń – w dużej mierze tak. Instalacja podman-docker dostarcza wrapper /usr/bin/docker, a run, ps, build, logs oraz exec działają w ten sam sposób. Nie jest to jednak zamiennik demona. Swarm nie posiada odpowiednika, narzędzia łączące się z /var/run/docker.sock muszą zostać przekierowane na gniazdo Podman specyficzne dla użytkownika, a obrazy pobrane przez Docker pozostają niewidoczne dla Podman, ponieważ oba narzędzia przechowują dane w oddzielnych lokalizacjach.

Dlaczego moje kontenery Podman działające bez uprawnień roota zatrzymują się po wylogowaniu z SSH?

Ponieważ systemd kończy sesję użytkownika, a wraz z nią wszystkie usługi użytkownika, gdy zamykana jest ostatnia sesja logowania. Wykonaj sudo loginctl enable-linger <user>, a następnie sprawdź, czy loginctl show-user <user> --property=Linger zwraca Linger=yes. Funkcja linger utrzymuje instancję systemd użytkownika w stanie aktywnym nawet bez aktywnej sesji, co pozwala również na automatyczne uruchamianie kontenerów po restarcie systemu.

Dlaczego pliki w moim wolumenie mają właściciela UID 100999?

Podman w trybie bez roota mapuje UID 0 kontenera na użytkownika hosta, a następnie mapuje UID 1 i wyższe na zakres subuid. Przy zakresie zaczynającym się od 100000, UID 1000 kontenera staje się 100999 na hoście. Można to skorygować z wnętrza przestrzeni nazw za pomocą podman unshare chown 1000:1000 /path/to/data, montować wolumen z flagą :U przy pierwszym uruchomieniu lub użyć --userns=keep-id, aby UID kontenera odpowiadały UID użytkownika hosta.

Czy mogę nadal używać docker-compose.yml z Podman?

Tak, na dwa sposoby. podman-compose odczytuje plik i bezpośrednio steruje CLI Podman. Alternatywnie można włączyć gniazdo kompatybilności za pomocą systemctl --user enable --now podman.socket, ustawić DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock i uruchomić właściwe docker compose w odniesieniu do tego gniazda. Należy spodziewać się problemów z network_mode: host, usługami montującymi gniazdo Docker oraz restart: always, które wymaga jednostki typu quadlet i włączonego linger, aby przetrwać restart systemu.

Czy tryb bez roota rzeczywiście zwiększa bezpieczeństwo kontenerów?

Eliminuje on jedno konkretne ryzyko: proces, który wydostanie się z kontenera bez uprawnień roota, posiada jedynie uprawnienia nieuprzywilejowanego użytkownika, a nie roota. Jest to istotna zaleta i dlatego grupa docker, będąca odpowiednikiem roota, nie ma swojego odpowiednika w Podman bez roota. Nie chroni to jednak przed podatnościami jądra ani przed dostępem do plików, które użytkownik może odczytać, dlatego należy zachować pozostałe środki ochrony stosowane na każdym serwerze.