Blog

Podman 2.0 to narzędzie do tworzenia i zarządzania kontenerami, udostępnione w ósmej wersji systemu EuroLinux. Oprogramowanie jest kompatybilne z Dockerem i oferuje wiele korzyści w zakresie bezpieczeństwa, głównie dzięki możliwości działania z poziomu nieuprzywilejowanego użytkownika (root less) i rezygnacji z procesu daemona (daemon-less).

Jednym z założeń Podmana jest API kompatybilne z Dockerem. Dlatego też prawie wszystkie polecenia CLI (Command Line Interface) z Docker CLI są również dostępne w programie Podman. Poniższe przykładowe polecenia są równoważne:

docker run -itd --name nginx --privileged -v ~/www:/usr/share/nginx/html -p 8090:80 nginx
podman run -itd --name nginx --privileged -v ~/www:/usr/share/nginx/html -p 8090:80 nginx

Z przyzwyczajenia wielu użytkowników Podmana używa również polecenia:

alias docker=podman

Największą różnicą pomiędzy Dockerem i Podmanem jest architektura. Docker działa w oparciu o architekturę klient-serwer, podczas gdy w Podmanie całkowicie zrezygnowano z procesu daemona.

Podczas pracy z Dockerem użytkownik korzysta z Docker CLI, które komunikuje się z daemonem Dockera w tle. Główna logika programu znajduje się w daemonie, który buduje obrazy i operuje na kontenerach. Daemon ten działa z uprawnieniami roota. Oznacza to również, że niewłaściwie skonfigurowany kontener w programie Docker może potencjalnie uzyskać dostęp do systemu plików hosta. Natomiast architektura Podmana pozwala na pracę z poziomu użytkownika, który uruchamia kontener i użytkownik ten nie potrzebuje uprawnień roota do działania programu. Kontenery nieuprzywilejowane mają ogromną przewagę nad kontenerami uruchamianymi z uprawnieniami roota – jeśli atakujący jest w stanie przechwycić kontener i z niego uciec, to intruz ten nadal pozostaje nieuprzywilejowanym użytkownikiem hosta. Takie rozwiązanie tworzy dodatkową warstwę ochronną.

Podman domyślnie obsługuje pliki Dockerfiles, ale pozbawiony jest funkcjonalności Docker Compose. Tutaj pomocny może okazać się niezależny projekt umieszczony na GitHubie, o nazwie podman-compose: https://github.com/containers/podman-compose. Docker jest uruchamiany jako pojedynczy proces i może to prowadzić do tzw. „single point of failure”. Wszystkie procesy „dzieci” są własnością tego jednego procesu – jeśli daemon Docker zawodzi, to wszystkie procesy potomne zostają osierocone.

Do poleceń podman rm i podman rmi możliwe jest dołączenie flagi --all / -a. Dla wielu użytkowników to pomocna funkcjonalność, którą w Dockerze można uzyskać tylko kombinacją kilku poleceń.

Jakie jeszcze zalety posiada Podman?

Podman 2.0:

• może korzystać z popularnych rejestrów kontenerów (takich jak Docker Hub lub Quay.io), ponieważ obrazy tworzone przez Dockera i Podmana są zgodne ze standardem Open Container Initiative (OCI)
• do obsługi działających kontenerów w tle wykorzystuje integrację z systemd, ponieważ jest pozbawiony dodatkowego procesu daemona
• pozwala na tworzenie i zarządzanie Podami, czyli grupą jednego lub więcej kontenerów, które działają razem. Ułatwia to późniejszą migrację obciążenia na Kubernetes i orkiestrację kontenerów Podmana
• może korzystać z separacji UID przy użyciu przestrzeni nazw, co zapewnia dodatkową warstwę izolacji podczas uruchamiania kontenerów, czyli ponownie: bezpieczeństwo
• potrafi wygenerować plik YAML dla Kubernetes tylko na podstawie działającego kontenera (za pomocą polecenia podman generate kube).

Podsumowanie

Podman jest szybszy, wydajniejszy, zajmuje mniej przestrzeni dyskowej i wymaga mniej zależności od Dockera. Docker jest monolitycznym narzędziem, które stara się robić wszystko – co generalnie nie jest najlepszym podejściem w IT. W zastosowaniach biznesowych lepiej stosować bezpieczne i specjalistyczne narzędzia. Między innymi z tego powodu Podman stał się domyślnym silnikiem kontenerowym w EuroLinuksie 8 i w innych systemach Linux klasy Enterprise.