Jeśli interesujesz się wirtualizacją i konteneryzacją, prawdopodobnie spotkałeś Podmana i Dockera i możesz się zastanawiać, czym się od siebie różnią.
W tym poście zbadamy różnice między Dockerem a Podmanem i spróbujemy znaleźć, który z nich będzie dla Ciebie właściwym wyborem!
Spis treści:
Doker
Docker to technologia konteneryzacji, która ułatwia zarządzanie zależnościami w ramach projektu na wszystkich poziomach (programowanie i wdrażanie).
Dostępny w systemach Linux, Windows i Mac OS mechanizm Dockera koncentruje się wokół kontenerów i ich aranżacji, i właśnie tym różni się konteneryzacja od wirtualizacji.
Docker ma dwa główne bloki konstrukcyjne: Docker CLI i Docker Daemon.
Demon Dockera:
Jest to stały proces działający w tle, który pomaga zarządzać obrazami, kontenerami, sieciami i woluminami Dockera. Docker używa interfejsu API REST Docker Engine do interakcji z demonem Docker, do którego dostęp uzyskuje się za pośrednictwem protokołu HTTP.
Interfejs wiersza polecenia Dockera:
Źródło obrazu: Redhat
Jest to klient wiersza poleceń Docker do interakcji z demonem Docker. To jest to, czego używasz, gdy uruchamiasz dowolne polecenie Dockera.
Działanie Dockera opiera się na jądrze Linuksa i funkcjach tego jądra, takich jak cgroups i przestrzenie nazw. Funkcje te oddzielają procesy, aby mogły działać niezależnie, ponieważ celem kontenerów jest osobne uruchamianie wielu procesów i aplikacji.
Dzięki temu możliwa jest optymalizacja wykorzystania infrastruktury bez obniżania poziomu bezpieczeństwa w porównaniu z odrębnymi systemami.
Wszystkie narzędzia kontenerowe, takie jak Docker, są dostarczane z modelem wdrażania opartym na obrazach. Model ten upraszcza udostępnianie aplikacji lub zestawu usług w wielu środowiskach.
Ponadto Docker pomaga zautomatyzować wdrażanie aplikacji w środowisku kontenerowym. Dzięki tym różnym narzędziom użytkownicy uzyskują pełny dostęp do aplikacji i mogą przyspieszyć wdrażanie, kontrolować wersje i przypisywać je.
Podman
Podman (POD MANAger) buduje, uruchamia i zarządza kontenerami OCI i obrazami kontenerów. Został opracowany przez firmę Red Hat i pierwotnie przeznaczony dla jej przedsiębiorstwa Linux 8. Służy do zarządzania kontenerami i działa jako oficjalny następca Dockera.
W konsekwencji Red Hat zaprzestał obsługi Dockera, ale zapewnił, że zmiana będzie łatwa dla użytkowników, ponieważ Podman jest oparty na Dockerze, chociaż pierwotnie miał służyć tylko jako narzędzie do debugowania.
Zarządza całym ekosystemem kontenerów za pomocą biblioteki libpod. Ponieważ Podman działa tylko na platformach Linux, REST API i klienci są obecnie w fazie rozwoju, aby umożliwić systemom Mac i Windows wywoływanie usługi.
Jednak obecnie istnieje zdalny klient oparty na Varlink, który działa na platformach Mac lub Windows i umożliwia zdalną komunikację z serwerem Podman opartym na systemie Linux. Biblioteka libpod obsługuje wiele metod bezpiecznego przesyłania obrazów, w tym zaufanie i weryfikację obrazu.
Obsługuje również pody do zarządzania grupami kontenerów razem i wieloma formatami obrazów, w tym formatami obrazów OCI i Docker.
W bardzo małych i łatwych w zarządzaniu środowiskach Podman może nawet służyć jako prekursor Kubernetes. Wypełnia lukę między pojedynczym zarządzaniem poszczególnymi instancjami z wczesnych lat boomu na kontenery a nowoczesną orkiestracją z Kubernetes.
Ambitni użytkownicy kontenerów mogą już cieszyć się kolejnym poziomem dzięki kapsułom. Budowa i działanie klastra Kubernetes nie są już potrzebne. W najprostszym przypadku nowo zaprojektowane strąki można testować i ulepszać w poszczególnych operacjach. Możliwy jest nawet późniejszy transfer do Kubernetes.
Komenda podman generuj kube dostarcza odpowiednie pliki konfiguracyjne. Następnie służą one jako dane wejściowe dla narzędzia Kubernetes kubectl.
Obecne wersje Podmana mogą nawet tworzyć pliki konfiguracyjne dla systemd – gratka dla każdego, kto używa wszechobecnego następcy init do orkiestracji kontenerów.
Podman vs Docker: różnice
Docker szybko stał się koniem hobbystycznym do zarządzania kontenerami. Docker ma jednak wiele zalet, a przede wszystkim szybko rosnący repertuar obrazów, a także wady i możliwe zagrożenia bezpieczeństwa. Co więcej, Docker nie jest już obsługiwany jako kontener dla Kubernetes.
Fakt, że kontenery, w przeciwieństwie do systemów wirtualnych, nie wymagają własnego jądra, jest zwykle postrzegany jako jedna z największych zalet. Stanowi to jednak poważne zagrożenie dla bezpieczeństwa Dockera, ponieważ kontenery Dockera można uruchamiać tylko z uprawnieniami administratora.
Umożliwia procesom działającym w kontenerach dostęp do jądra z uprawnieniami roota, a tym samym atakowanie systemu hosta.
Pierwsze rozróżnienie jest widoczne przy pierwszym użyciu. Podczas gdy Docker wymaga najpierw uruchomienia demona Docker, kontener Podman można uruchomić bezpośrednio z wiersza poleceń. Nie ma więc procesu w tle, a aplikacja jest uruchamiana tylko wtedy, gdy jest to potrzebne.
Z punktu widzenia bezpieczeństwa jest to dobre, ponieważ Podman jest mniej podatny na ataki, jeśli demon nie musi działać 24/7 z uprawnieniami superużytkownika. Podman nie wymaga procesu w tle ze względu na architekturę, która zasadniczo różni się od Dockera.
Podczas gdy Docker podąża za modelem klient-serwer, w którym klient Docker komunikuje się z demonem Dockera za pośrednictwem interfejsu API, Podman podąża za modelem fork-exec. Każdy kontener działa jako proces potomny Podmana.
Przestrzeń nazw użytkownika jest tworzona przy pierwszym użyciu, gdy Podman jest uruchamiany z normalnymi uprawnieniami użytkownika. W przestrzeni nazw użytkownika Podman działa z uprawnieniami roota i ma uprawnienia do montowania systemów plików i tworzenia kontenerów.
W związku z tym kontener Podman ma tylko te prawa, które ma użytkownik wykonujący. Korzystanie z przestrzeni nazw użytkowników oznacza, że każdy użytkownik może tworzyć własne kontenery i zarządzać nimi, ale nie są one widoczne dla innych użytkowników i superużytkownika.
Ponieważ Podman działa niezależnie od Dockera, twórcy mają dużą swobodę i mogą odpowiadać na życzenia społeczności. Interesujące dodatki do Podmana obejmują polecenie montowania/odmontowywania i integrację z systemem.
Host może użyć polecenia mount/unmount do zamontowania systemu plików kontenera, na przykład w celu uzyskania dostępu do plików lub ich zmiany, a następnie ponownego ich odmontowania.
Chociaż monitorowanie kontenerów za pomocą systemd nie działa z powodu demona w Dockerze z Podmanem, kontenery można uruchamiać, monitorować, a nawet restartować za pomocą systemd.
Ponadto Podman udostępnia polecenie podman generowania systemd, które generuje odpowiednią usługę systemową dla odpowiedniego kontenera, zwalniając w ten sposób użytkownika z tworzenia usług systemowych, co oznacza, że dostępna jest integracja z systemem hosta.
Inną istotną różnicą między Podmanem a Dockerem jest to, że ten ostatni nie zmienia reguł zapory sieciowej ani aktualnej instalacji dnsmasq ze względu na możliwość tworzenia sieci wewnętrznej. W przeciwieństwie do tego Docker musi nadpisać reguły zapory, aby umożliwić komunikację między kontenerami.
PodmanDockerArchitektura DemonBez demonówSystem zarządzania usługamidDocker Engine Zgodność z zaporą ogniową Nadpisuje reguły zapory sieciowej Przestrzega reguł zapory sieciowejPlatformaNatywna obsługa systemów LinuxLinux, Windows i Mac
Kiedy należy przeprowadzić migrację z Dockera do Podmana
Jeśli wdrażasz kontenery w środowisku opartym na RHEL, w takim przypadku nie masz wielu opcji poza użyciem Podmana, ponieważ jest on natywny dla RHEL. Możesz także przeprowadzić migrację lub wybrać Podman zamiast Dockera, jeśli masz małe wdrożenia z kilkoma kontenerami.
Jeśli jednak chcesz uzyskać coś bardziej złożonego, miej wiele kontenerów i stos koordynujących kontenerów z docker-compose/podman-compose przez sieć. Lepiej jest używać Dockera, ponieważ znacznie lepiej radzi sobie z siecią.
Podobnie, jeśli dopiero zaczynasz wkraczać w świat kontenerów, w takim przypadku Docker jest lepszą opcją, ponieważ jest stabilny, dobrze ugruntowany z odpowiednią dokumentacją i ma płytką krzywą uczenia się w porównaniu do Podmana, któremu wciąż brakuje stabilności i nie ma dobrze zdefiniowanej dokumentacji.
Migracja z Podmana do Dockera
Jeśli jesteś w wierszu poleceń, dość łatwo jest przełączyć się z Docker Engine na Podmana. Mówiąc najprościej, alias $ przez większość czasu działa jako polecenie docker=podman.
Oczywiście zakłada to, że w systemie jest zainstalowane odpowiednie oprogramowanie. W przypadku Linuksa również nie stanowi to problemu; gotowe pakiety oprogramowania są dostępne dla komercyjnych dystrybucji.
Systemy Windows i macOS nie należą do obsługiwanych systemów operacyjnych. Podejście aliasowe działa, ponieważ wiele poleceń Dockera ma odpowiednik Podmana.
Ale są też wyjątki, ponieważ niektóre polecenia Dockera nie mają odpowiednika w świecie Podmana. Podobnie niektóre polecenia zachowują się inaczej w Dockerze niż we wszechświecie Podmana. W tej chwili ma to wpływ tylko na obsługę woluminów, które zostały już skonfigurowane.
Zmiana jest nieco trudniejsza, gdy używane są narzędzia graficzne, takie jak Docker Desktop. Powinno to szczególnie dotknąć tych programistów, którzy pracują z systemem Windows lub macOS.
Użytkownicy Docker Desktop będą musieli przyzwyczaić się do wiersza poleceń i to samo dotyczy Docker Compose. Istnieje jednak projekt podman-compose. Napisane w Pythonie oprogramowanie służy jako zamiennik Docker Compose.
Ostatnie słowa
Zastąpienie Dockera przez Podmana można uznać za prawie zakończone. Dla użytkowników i administratorów większość aspektów tej zmiany jest łatwa. Wiele funkcji Dockera ma identyczne odpowiedniki w Podmanie.
Prawdziwą korzyścią jest brak pojedynczego procesu demona i uprawnień roota, nie wspominając już o naturalnym wykorzystaniu grup kontenerów. Warto jednak wspomnieć, że Docker pozostaje główną technologią dotyczącą kontenerów, ale najprawdopodobniej w dłuższej perspektywie to się zmieni.
Możesz także zapoznać się z niektórymi poleceniami platformy Docker do zarządzania kontenerami.