Podman czy Docker na VPS: kluczowe różnice techniczne

Różnice między Podman a Docker

Podman i Docker uruchamiają te same obrazy OCI (Open Container Initiative) na serwerze VPS, więc wybór nie dotyczy kompatybilności oprogramowania. Różnica tkwi w modelu procesów. Docker uruchamia demona z uprawnieniami root, który zarządza wszystkimi kontenerami, a polecenie docker jest jedynie niewielkim klientem zlecającym pracę temu demonowi. 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 obsługiwana przez przestrzenie nazw użytkowników (user namespaces), więc właściciel widoczny za pomocą ls -l na hoście nie jest tym samym właścicielem, którego widzi kontener. Porty poniżej 1024 nie mogą zostać powiązane, dopóki nie zostanie zmienione ustawienie jądra systemu. Interfejs wiersza poleceń docker działa poprawnie dzięki wrapperowi, aż do momentu, gdy wymagany jest dostęp do gniazda (socket) Docker.

Brak demona: co faktycznie działa po uruchomieniu kontenera

Na hoście Docker polecenie pstree -a pokazuje dockerd działający jako root, obok niego containerd oraz po jednym containerd-shim-runc-v2 na każdy uruchomiony kontener. Twoja 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, systemctl restart docker restartuje również kontenery.

Podman nie posiada odpowiednika tego procesu. Uruchomienie kontenera tworzy jeden proces conmon (monitor kontenera), który utrzymuje główny proces 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

ps powinno wyświetlić conmon działające jako użytkownik zalogowany, a nie jako root, a curl powinno zwrócić 200. Ponieważ żadna centralna usługa nie jest właścicielem kontenera, sudo apt upgrade podman nie zatrzymuje niczego, co już działa, a awaria monitora jednego kontenera nie powoduje awarii pozostałych.

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

Gniazdo (socket) to druga strona medalu. /var/run/docker.sock jest punktem końcowym API (interfejsu programowania aplikacji), którego właścicielem jest root, a każdy proces mający uprawnienia do zapisu w nim 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 przeczytać w sekcji przyznawanie każdemu kontu serwisowemu tylko niezbędnego dostępu. Podman nie udostępnia żadnego gniazda, dopóki o to nie poprosisz, 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.

Ubuntu 24.04 zawiera Podman 4.9, a Debian 13 zawiera Podman 5.x (stan na sierpień 2026). Ta różnica jest istotna, ponieważ pliki Quadlet wymagają wersji 4.4 lub nowszej, a pliki Quadlet typu .pod wymagają wersji 5.0. Przed skopiowaniem przykładu z oficjalnej dokumentacji należy wykonać podman --version.

Każdy użytkownik korzystający z trybu 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 za pomocą narzędzia konfiguracyjnego 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 wymusić użycie nowego mapowania:

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. Należy zawsze podawać pełną nazwę obrazu. Zaleca się stosowanie docker.io/library/nginx:1.27 zamiast nginx.

Co w praktyce dają kontenery rootless na wynajętym serwerze

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

To realny zysk z tego rozwiązania. Obraz, który wymaga uruchomienia jako root, aplikacja webowa z błędem umożliwiającym zdalne wykonanie kodu (RCE) czy próba ucieczki z kontenera wymagająca uprawnień UID 0 na zewnątrz – wszystkie te przypadki kończą się uzyskaniem uprawnień Twojego nieuprzywilejowanego użytkownika, a nie uprawnień administratora maszyny. Rozwiązanie rootless nie chroni przed błędami w jądrze systemu ani przed dostępem do Twoich plików, ponieważ proces po ucieczce działa z Twoimi uprawnieniami i może odczytać wszystko to, co Ty.

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 domyślnym podejściu. W przypadku Podman tryb rootless jest aktywny domyślnie, więc pierwszą napotkaną trudnością będzie brak możliwości powiązania kontenera z portem 80, zamiast usługi, która przez dwa lata działała jako root bez wiedzy administratora.

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

Jest to spowodowane działaniem 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 z zakresu subuid, a kolejne wartości są zwiększane. Przy zakresie zaczynającym się od 100000, UID 1000 w kontenerze jest widoczny na hoście jako 100999.

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.

Istnieją cztery rozwiązania:

• podman unshare chown 1000:1000 "$PWD/data" uruchamia chown wewnątrz tej samej przestrzeni nazw użytkownika, gdzie liczby mają znaczenie zgodne z interpretacją kontenera.
• -v "$PWD/data:/data:U" poleca Podman automatycznie skorygować uprawnienia katalogu źródłowego. Należy używać tego tylko dla nowych katalogów, a nie dla istniejących danych.
• --userns=keep-id mapuje UID użytkownika na hoście na ten sam UID wewnątrz kontenera, dzięki czemu nowe pliki są tworzone z odpowiednim 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 ustawionymi uprawnieniami.

Jeśli problem ten występował wcześniej w Docker, jest to ten sam mechanizm działający na wyższym poziomie. Zmienne PUID oraz PGID, które udostępnia wiele obrazów określają UID używany przez proces wewnątrz kontenera, a w przypadku rootless Podman ten UID jest mapowany po raz drugi. PUID=1000 wewnątrz kontenera rootless nadal zapisuje pliki na hoście z właścicielem 100999. Należy dobrać wartości liczbowe z uwzględnieniem tego drugiego mapowania lub przenieść dane do nazwanego wolumenu, aby uniknąć dalszych problemów.

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, który korzysta z AppArmor, nie mają one żadnego działania. Rootless Podman nie może również zamontować katalogu hosta, do którego użytkownik nie ma uprawnień odczytu – jest to zamierzone zachowanie, a nie błąd.

Dlaczego bezuprawnieniowy 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. Obniżenie progu 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ć o skutkach tego ustawienia: każdy użytkownik w systemie może teraz powiązać porty 80 oraz 443, a nie tylko ten uruchamiający kontenery. Na serwerze VPS z jednym administratorem jest to akceptowalny kompromis. Na maszynie współdzielonej 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 planowane jest wydawanie i odnawianie certyfikatów przez certbot na nginx.

Udostępnianie portów w trybie bezuprawnieniowym zmienia również sposób widzenia połączeń przez aplikację. Podman w wersji 4.x domyślnie używa slirp4netns z obsługą portów rootlesskit, przez co przekierowane połączenia mają nadpisany adres źródłowy, a dziennik dostępu rejestruje 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 użycie --network slirp4netns:port_handler=slirp4netns przywraca poprawny adres źródłowy, kosztem pewnego spadku przepustowości.

W tym rozwiązaniu występuje jedna zaleta. Udostępniony port w trybie bezuprawnieniowym jest zwykłym gniazdem nasłuchującym, należącym do standardowego procesu, więc reguły firewalla mają do niego pełne zastosowanie. Docker udostępnia porty poprzez tworzenie reguł NAT (network address translation) oraz własnych reguł akceptacji 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 root korzysta z podobnych mechanizmów i dziedziczy ten sam problem. W trybie bezuprawnieniowym ten problem nie występuje.

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

W większości przypadków tak, przy użyciu jednej z dwóch metod. Pierwszą jest podman-compose, 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

Drugą metodą jest użycie standardowego Docker Compose, który komunikuje się z kompatybilnym z Docker API interfejsem 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ć tę samą listę kontenerów, ponieważ istnieje tylko jeden ich zbiór. Rozpoznawanie nazw również działa: domyślny backend sieciowy Podmana, netavark, uruchamia aardvark-dns, dzięki czemu kontenery w sieci zdefiniowanej przez użytkownika mogą odnaleźć się nawzajem po nazwie.

Istnieją jednak pewne ograniczenia. Każdy element montujący /var/run/docker.sock musi zostać przekierowany na gniazdo Podman lub usunięty. network_mode: host zachowuje się inaczej w przestrzeni nazw użytkownika. depends_on wraz z condition: service_healthy jest obsługiwane w różnym stopniu w zależności od wersji podman-compose. restart: always nie przetrwa samodzielnie restartu systemu, co zostanie rozwiązane w kolejnej sekcji. Compose pozostaje dobrym sposobem na opisanie wielokontenerowego stosu w jednym pliku, a w środowisku Podman stanowi warstwę translacji. W przypadku stosu, który ma być utrzymywany przez lata, zaleca się konwersję na format quadlets, aby zarządzać jedną abstrakcją zamiast dwiema.

Pody: koncepcja, na którą 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. Kontener web łączy się teraz z Redis pod adresem 127.0.0.1:6379, zamiast app-cache:6379. Ze współdzielonej przestrzeni nazw wynikają dwie zasady: porty publikuje się na poziomie poda, a nie poszczególnych członków, oraz żaden z 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 uruchomionych zasobów (w starszych pakietach służy do tego 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.

Automatyczne uruchamianie 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 umieszcza się 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 pusty, 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 odpowiada 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 zakończeniu ostatniego połączenia SSH, przez co każdy kontener bez uprawnień roota zostaje zatrzymany i nie uruchamia się ponownie przy starcie systemu. Kontenery, które znikają po wylogowaniu, zawsze wynikają z tego powodu.

Ponieważ kontener jest głównym procesem zwykłej jednostki usługi, mają do niego bezpośrednie zastosowanie mechanizmy kontrolne 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ą mechanizm dopasowania. 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 przywraca poprzedni obraz, jeśli nowy kontener nie uruchomi się poprawnie. Należy 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 na co dzień: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Lista elementów, które nie są przenoszone, jest krótsza, ale bardziej istotna. Tryb Swarm nie posiada odpowiednika, więc stos Swarm nie ma gdzie zostać uruchomiony. 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 za pomocą Docker, a podman images na aktywnym hoście Docker jest początkowo 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 wszystkie usługi.

Oba silniki nie współdzielą żadnych zasobów: posiadają oddzielne magazyny obrazów i odrębne sieci. Dzięki temu można uruchamiać oba rozwiązania jednocześnie podczas migracji, a jedynym punktem spornym pozostaje numer portu hosta. Przenieś jedną usługę, monitoruj ją przez dobę, a następnie przejdź do kolejnej.

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ą Docker na swoich komputerach, zyskuje wymierne korzyści, stosując ten sam silnik w środowisku produkcyjnym.

Przejdź na Podman, jeśli VPS obsługuje kilka usług, którymi zarządzasz samodzielnie, lub jeśli chcesz, aby każda aplikacja działała na koncie użytkownika bez uprawnień, bez obecności 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 już zarządzasz pozostałymi usługami za pomocą jednostek systemd, quadlets będą postrzegane jako brakujący element, a nie nowe narzędzie do nauki.

Warto wspomnieć o rozwiązaniu pośrednim. Podman w trybie rootful zachowuje się podobnie do Docker, obsługuje polecenie docker za pośrednictwem wrappera i eliminuje konieczność działania demona w tle. Traci się jednak zalety trybu rootless, który realnie zmienia poziom bezpieczeństwa, dlatego należy traktować to rozwiązanie jako etap przejściowy.

Jeśli dopiero budujesz swój pierwszy host kontenerowy, konfiguracja Docker i zabezpieczanie świeżego VPS to krótsza droga, a zdobyta wiedza nie będzie zmarnowana. 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 alias /usr/bin/docker, a polecenia run, ps, build, logs oraz exec działają w ten sam sposób. Podman nie jest jednak zamiennikiem demona. Swarm nie posiada odpowiednika, narzędzia łączące się z /var/run/docker.sock muszą zostać przekierowane na gniazdo Podman właściwe dla użytkownika, a obrazy pobrane przez Docker pozostają niewidoczne dla Podman, ponieważ oba narzędzia korzystają z oddzielnych magazynów danych.

Dlaczego moje kontenery rootless Podman 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?

Rootless Podman mapuje UID 0 kontenera na użytkownika hosta, a kolejne UID kontenera (od 1 wzwyż) na zakres subuid. Przy zakresie zaczynającym się od 100000, UID 1000 kontenera staje się 100999 na hoście. Problem można rozwiązać z wnętrza przestrzeni nazw za pomocą podman unshare chown 1000:1000 /path/to/data, montując wolumen z flagą :U przy pierwszym uruchomieniu lub używając --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 liczyć się z trudnościami w przypadku network_mode: host, usług montujących gniazdo Docker oraz restart: always, które wymaga jednostki quadlet i włączonego linger, aby przetrwać restart systemu.

Czy tryb rootless faktycznie zwiększa bezpieczeństwo kontenerów?

Eliminuje on jedno konkretne ryzyko: proces, który wydostanie się z kontenera rootless, posiada 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 rootless Podman. 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 standardowe techniki utwardzania serwera.