Difference between revisions of "Podman"

From Freephile Wiki
Jump to navigation Jump to search
(Created page with "thumb|right|link=https://podman.io|Podman - the Pod Manager Website: https://podman.io/ Code: see https://github.com/containers/podman Category:Virtua...")
 
m
 
(3 intermediate revisions by the same user not shown)
Line 4: Line 4:
  
 
Code: see https://github.com/containers/podman
 
Code: see https://github.com/containers/podman
 +
 +
Breaking down your container workloads https://podman-desktop.io/docs/onboarding/containers This documentation for Podman Desktop compares various capabilities for runtimes and OS combinations for your containerization workloads.
 +
 +
<br />
 +
 +
==Podman vs Docker==
 +
Podman runs in a fork-exec model, not a client-server model avoiding the overhead of the [[Docker]] daemon that runs continuously and consumes significant resources. Furthermore Podman runs on the host as the local user, not root so it is fundamentally more secure. Speaking of security, since Podman comes from RedHat, it's no surprise that it runs just fine with SELinux set to "enforce" mode. While Docker offers AppArmor as a security layer, it's too lax by default, you have to learn the syntax, and write your own policies, AND it doesn't work with rootless Docker, nor does it offer isolation between containers <ref>https://www.redhat.com/sysadmin/apparmor-selinux-isolation</ref>.
 +
 +
For a good deep dive on the comparison, see the "guide" article on Linode.com https://www.linode.com/docs/guides/podman-vs-docker/ and the discussion of it on Ycombinator https://news.ycombinator.com/item?id=34719137<br />
 +
 +
==Pod security==
 +
Using [https://github.com/containers/udica Udica], you can generate SELinux policies for your containers.
 +
 +
And, the whole "no daemon" model offers many advantages over the Docker daemon model when it comes to security, isolation and auditing.
 +
 +
Unlike [[Docker]], Podman respects firewalls by default.
 +
<br />
 +
 +
==Podman Desktop==
 +
Like Docker Desktop, there is a graphical application called '''Podman Desktop''' (https://podman-desktop.io/) that you can use to build, run, and manage your containers, pods, and other objects. It even allows you to work with Kubernetes from your local environment.
 +
{{References}}
  
 
[[Category:Virtualization]]
 
[[Category:Virtualization]]
 +
[[Category:Kubernetes]]

Latest revision as of 08:45, 14 November 2023

Podman - the Pod Manager

Website: https://podman.io/

Code: see https://github.com/containers/podman

Breaking down your container workloads https://podman-desktop.io/docs/onboarding/containers This documentation for Podman Desktop compares various capabilities for runtimes and OS combinations for your containerization workloads.


Podman vs Docker[edit | edit source]

Podman runs in a fork-exec model, not a client-server model avoiding the overhead of the Docker daemon that runs continuously and consumes significant resources. Furthermore Podman runs on the host as the local user, not root so it is fundamentally more secure. Speaking of security, since Podman comes from RedHat, it's no surprise that it runs just fine with SELinux set to "enforce" mode. While Docker offers AppArmor as a security layer, it's too lax by default, you have to learn the syntax, and write your own policies, AND it doesn't work with rootless Docker, nor does it offer isolation between containers [1].

For a good deep dive on the comparison, see the "guide" article on Linode.com https://www.linode.com/docs/guides/podman-vs-docker/ and the discussion of it on Ycombinator https://news.ycombinator.com/item?id=34719137

Pod security[edit | edit source]

Using Udica, you can generate SELinux policies for your containers.

And, the whole "no daemon" model offers many advantages over the Docker daemon model when it comes to security, isolation and auditing.

Unlike Docker, Podman respects firewalls by default.

Podman Desktop[edit | edit source]

Like Docker Desktop, there is a graphical application called Podman Desktop (https://podman-desktop.io/) that you can use to build, run, and manage your containers, pods, and other objects. It even allows you to work with Kubernetes from your local environment.

References[edit source]