Podman enables running individual containers without requiring a system-wide daemon. This is a really niche need, but the people who now have it available to them are very happy for it :)
The thing I like the most about Podman in comparison to Docker is it's IPv6 support. My ISP puts me behind CG-NAT, so with IPv4 there is no way to reaching my home network. But my ISP gives me IPv6 conectivity and I remeber to try setup my containers with Docker and IPv6 and it didnt work, I migrated to Podman and simply worked. I'm using ever since.
This is true, but there may be some differences in the generated container runtime environment. I've hit a few that needed a few minor changes to their compose files to function as-expected, and I believe they were related to permissions.
This is mostly true, but there are a few exceptions. Linking is not currently supported in podman, which is commonly used in multi container docker compose deployments
Rootless podman is extremely easy to work with for running local test/engineering work, especially as it is trivial to mount one of your directories into it and have access to mounted files with your own UID. No need to deal with root UID, nor namespaces UIDs. Very little overhead / headache to get some promise your scripts/programs reproducible as a full build instruction while still able to do simple stuff.
Great video, thanks. One additional advantage of Podman you did not mention, is it‘s support for GPU-accelerated Vulkan in containers on Apple silicon Macs via slp/krunkit.
in many cases docker desktop is not even free - "Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. Otherwise, it requires a paid subscription for professional use."
Wait there are professionnals using docker desktop when you can setup a docker swarm in less than 10 minutes ? When you can install docker in WSL2 ? When deploying portainer CE is like copy/pasting 1 docker-compose ? Naaah you are kidding me :D
another big difference is how local privileges are handled. enviroment variables do not work in podman-compose, locally mounted volumes do not work and so on. podman just is not production ready yet.... i have struggled days to prove otherwise, but no luck.
Its got some catching up to do, Docker has about 5 years more on it, and a larger team. Thanks for sharing your feedback on it 🙂 I've seen others mention that the compose support isn't perfect yet.
I would really advise against using podman-compose. Instead, you can create a Kubernetes yaml and deploy it using `podman play kube`. You can even let Podman generate a spec for a user service which can then be managed by systemd.
I am new to all containerisation, so i don’t know about environment vars, but I know that podman compose can do (localfolderpath):(containedfolderpath) but you need to ad „:z“ at the end to give explicit instead of implicit permission. (Still works with docker after the change)
podman-compose uses pods behind the scenes. It's better to handle the pods directly. That way you have total control. I don't like the generated pod code podman-compose tends to spit.
Thank you for the video man!! Been wanting to try it out but was unsure. Thank you for the neat breakdown!
Месяц назад+17
I think the video is a bit misleading on some points: - Docker now has rootless mode as well (not daemonless though, yet?) - Podman CLI and Docker CLI are 99% identical, saying that people will have a hard time migrating from Docker to Podman is just false IMHO - Any image can be run using podman or docker. At some point in the video, it says there's more images for Docker. That's incorrect. I think OP means there's more plugins for docker.
Hi! I did try mention that it could be changed from rootless, at 2:03 I could have made it clearer though. I agree that the CLI's are very similar but I still think there can be friction changing tooling, particularly around swarm and compose. On the last point the comparison is meant to be between Quay and DockerHub, there's still some issues with running some images on Podman, others have commented examples like windows containers. But I do agree you could also use Podman to launch it in the Docker environment so again maybe a bit of nuance there. Thanks for the feedback, will try to make points like these more precise going forward 🙂
Месяц назад+4
@betterstack I realize my comment may have sounded a bit harsh. It was only meant as constructive feedback :) Other than that, content and format is great.
Podman not fully support compose, only via separate script, and the external usage of docker compose and buildkit have it's own problems like not everything work as expected, for example networking (docker and podman implementation of it is totally different).
Great video, but I found that one key thing that prevented me from working with Podman was that Docker allowed me to work with windows containers. I had an instance where I needed a container that to leverage the User Certificate Store for windows.
Yeah i use podman for years, previsouly it wasn't has polish as docker, but now it's better fo my use case. If you woek locally on k8s before déploiement podman is a better tools and is quite close to CRI-O.
Also, with podman, you don't have to deal with the docker-in-docker bullshit that sometimes may break your CI/CD pipelines running on container-based worker nodes.
Podman seems good and is a good alternative to containerd, rather than Docker. Is it better to containerd? For me, it tries to reinvent too many things. I just stick to use containerd + Rancher Desktop. As for rootless, you should always configure securityContext and pass uid/gid when running K8S..
Also, podman is meant to be a drop in alias for docker so "being familiar with docker but learning podman" doesn't really make sense. On most systems you can even install a 'podman-docker' package that installs the alias for you
Personally I found podman to be leagues more stable than docker. Docker for me is always breaking every time I go to use it once a month or so. It’s podman usually doesn’t but also is super easy to fix with the reset
Is it though? Are those the most important questions? Memory and CPU will depend on the containers you're running more than anything in the real world... I'd argue the CPU and memory usage differences between these are the among the last things you need to know to make a choice, far more fundamental differences at play.
Containers are delivered by the Linux kernel unshare syscall, creating a your own container (process running in own namespaces). Containers are just Linux processes… You therefore typically would expect few RAM/CPU differences stemming from which way the container was launched.
Podman enables running individual containers without requiring a system-wide daemon. This is a really niche need, but the people who now have it available to them are very happy for it :)
The thing I like the most about Podman in comparison to Docker is it's IPv6 support. My ISP puts me behind CG-NAT, so with IPv4 there is no way to reaching my home network. But my ISP gives me IPv6 conectivity and I remeber to try setup my containers with Docker and IPv6 and it didnt work, I migrated to Podman and simply worked. I'm using ever since.
Any image built for docker will run with podman. The image format is the same as they’re both OCI compatible.
This is true, but there may be some differences in the generated container runtime environment. I've hit a few that needed a few minor changes to their compose files to function as-expected, and I believe they were related to permissions.
This is mostly true, but there are a few exceptions. Linking is not currently supported in podman, which is commonly used in multi container docker compose deployments
Podman can pull images from docker hub and its a one line config change to make that the default for either user or system
@@BennyPowers the podman engine doesn't have linking in its network stack at all
Rootless podman is extremely easy to work with for running local test/engineering work, especially as it is trivial to mount one of your directories into it and have access to mounted files with your own UID. No need to deal with root UID, nor namespaces UIDs.
Very little overhead / headache to get some promise your scripts/programs reproducible as a full build instruction while still able to do simple stuff.
Great video, thanks. One additional advantage of Podman you did not mention, is it‘s support for GPU-accelerated Vulkan in containers on Apple silicon Macs via slp/krunkit.
in many cases docker desktop is not even free - "Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. Otherwise, it requires a paid subscription for professional use."
dunno that sounds like pretty reasonable requirements
Wait there are professionnals using docker desktop when you can setup a docker swarm in less than 10 minutes ?
When you can install docker in WSL2 ?
When deploying portainer CE is like copy/pasting 1 docker-compose ?
Naaah you are kidding me :D
another big difference is how local privileges are handled. enviroment variables do not work in podman-compose, locally mounted volumes do not work and so on. podman just is not production ready yet.... i have struggled days to prove otherwise, but no luck.
Its got some catching up to do, Docker has about 5 years more on it, and a larger team. Thanks for sharing your feedback on it 🙂
I've seen others mention that the compose support isn't perfect yet.
I would really advise against using podman-compose. Instead, you can create a Kubernetes yaml and deploy it using `podman play kube`. You can even let Podman generate a spec for a user service which can then be managed by systemd.
I am new to all containerisation, so i don’t know about environment vars, but I know that podman compose can do (localfolderpath):(containedfolderpath) but you need to ad „:z“ at the end to give explicit instead of implicit permission. (Still works with docker after the change)
podman-compose uses pods behind the scenes. It's better to handle the pods directly. That way you have total control. I don't like the generated pod code podman-compose tends to spit.
Thank you for the video man!!
Been wanting to try it out but was unsure.
Thank you for the neat breakdown!
I think the video is a bit misleading on some points:
- Docker now has rootless mode as well (not daemonless though, yet?)
- Podman CLI and Docker CLI are 99% identical, saying that people will have a hard time migrating from Docker to Podman is just false IMHO
- Any image can be run using podman or docker. At some point in the video, it says there's more images for Docker. That's incorrect. I think OP means there's more plugins for docker.
Hi! I did try mention that it could be changed from rootless, at 2:03 I could have made it clearer though. I agree that the CLI's are very similar but I still think there can be friction changing tooling, particularly around swarm and compose. On the last point the comparison is meant to be between Quay and DockerHub, there's still some issues with running some images on Podman, others have commented examples like windows containers. But I do agree you could also use Podman to launch it in the Docker environment so again maybe a bit of nuance there.
Thanks for the feedback, will try to make points like these more precise going forward 🙂
@betterstack I realize my comment may have sounded a bit harsh. It was only meant as constructive feedback :) Other than that, content and format is great.
Podman not fully support compose, only via separate script, and the external usage of docker compose and buildkit have it's own problems like not everything work as expected, for example networking (docker and podman implementation of it is totally different).
At that point that’s where Kompose comes into play.
Great video, but I found that one key thing that prevented me from working with Podman was that Docker allowed me to work with windows containers. I had an instance where I needed a container that to leverage the User Certificate Store for windows.
Thanks for sharing this pain point, its certainly not one to one with Docker yet but its catching up. Hope they fix this one day!
Their should explicitly say in their docs. Its linux container only right now. I wasted my time when testing something else.
Yeah i use podman for years, previsouly it wasn't has polish as docker, but now it's better fo my use case. If you woek locally on k8s before déploiement podman is a better tools and is quite close to CRI-O.
Also, with podman, you don't have to deal with the docker-in-docker bullshit that sometimes may break your CI/CD pipelines running on container-based worker nodes.
thanks for this video! very nice!
Podman seems good and is a good alternative to containerd, rather than Docker. Is it better to containerd? For me, it tries to reinvent too many things. I just stick to use containerd + Rancher Desktop. As for rootless, you should always configure securityContext and pass uid/gid when running K8S..
Also, podman is meant to be a drop in alias for docker so "being familiar with docker but learning podman" doesn't really make sense. On most systems you can even install a 'podman-docker' package that installs the alias for you
nginx is pronounced as "engine X".
We are using Podman in our enterprise only because docker is paid for us that too 24 USD per month.
You didnt mention the absolutely most important thing : licensing
So no dockercompose in pod man?
There is podman-compose but it's not 1:1. Instead they recommend putting multiple containers into pods if they need to be run together.
Just use k3s tbh. Looks better on your resume too.
Personally I found podman to be leagues more stable than docker. Docker for me is always breaking every time I go to use it once a month or so. It’s podman usually doesn’t but also is super easy to fix with the reset
docker was never the only way to run containers, jails, nspawn-systemd, lxc and so on.
No one says it is. This video is about OCI containers.
Podman is free ?
yes
And it comes with your RHEL installation if you have a recent one.
Which is more RAM hungry?
And CPU intense?
Most important Questions..
Is it though? Are those the most important questions? Memory and CPU will depend on the containers you're running more than anything in the real world... I'd argue the CPU and memory usage differences between these are the among the last things you need to know to make a choice, far more fundamental differences at play.
Containers are delivered by the Linux kernel unshare syscall, creating a your own container (process running in own namespaces). Containers are just Linux processes… You therefore typically would expect few RAM/CPU differences stemming from which way the container was launched.
There is also nerdctl. For me, podman is just plain fickle.
I hope nobody runs WordPress and MySQL containers in one pod
But but but... i run podman inside docker
Podman from RedHat? No thanks, I'm afraid it destiny will same as Centos.
podman >>> docker