Great video as always. Good overview of how to use Podman for anyone interested in getting their toes wet. Couple bits of input: 1) Podman isn't exactly a dropin Docker replacement - it works for most things, but doesn't support Docker stacks in swarm mode for instance. Also, Docker can build images without additional tools while Podman requires Buildah to do so. There are other differences as well. As such, it's exactly not a 100% drop-in replacement. 2) Docker containers don't have to run as root - it's up to the image creator to decide how they operate. The container can absolutely switch users and execute commands as non-root if the image creator wants to. Similarly, the Docker daemon can be configured to run without root access. This isn't the default, but it's still possible. 3) You should really avoid using apt to install the docker packages as those are old versions of Docker, and follow the install instructions on the Docker website instead. 4) The -d in your command isn't for daemon mode, but to run a container in detached mode; that is, in the background. You can actually reattach to these containers if you like with the 'podman attach' command. 5) Your tab complete can be fixed by using the full command syntax, e.g. 'podman container stop' then pressing tab. Without passing 'container' to podman as the first arg, the autocomplete behaves weird. I think that's something they may address in the future as the shorthand syntax (without verbosely using 'podman container' every time) is very common and Docker allows it. That said, Podman is still a great alternative in the container landscape and offers some great benefits over Docker if you don't need to run high availability stacks in swarm mode. It's got some room to grow and catch up with Docker, but is looking very promising.
Buildah is not necessary to build containers with Podman. Podman uses buildah's code base under the hood, but you don't need the buildah binary installed to build containers with podman. [root@localhost ~]# find / -name buildah [root@localhost ~]# podman build -f Containerfile STEP 1/2: FROM rhel7 STEP 2/2: CMD ["/bin/bash"] COMMIT --> 0001f1e9700 0001f1e9700d179a611b5f37e59c874a6ad3ac5a197da473648962ff36b7b1f3
"Docker containers don't have to run as root" - true, but the majority of people getting into docker will run them by default with root, which is a bad security practice but defaulting to rootless containers can at least mitigate some issues, something I find really odd why docker devs did not think of this. I agree that developers should take responsibility, but you cannot deny that devs today don't put security as a first priority. "doesn't support Docker stacks in swarm" - it doesn't have to, because Podman has a feature called pods, and in each pod you can run multiple containers, same philosophy as Kubernetes, but I'm not entirely sure about the load balancing features and horizontal scalability. What's fun about Podman pods is that you can import and export them as a Kubernetes yaml file. I'd argue that pods don't need production ready features seeing that the majority are using Kubernetes for that, or even Openshift which is an RedHat orchestrator built on top of Kubernetes. You see the pattern here? Why should they support something that is inferior to the number one orchestrator in the world, and you can have a cool development set-up with podman and minikube to test pre-production. And last bit, about tab completion, I'd argue that it's better it should not be used because when you get used to the tool you type it faster than how much time it takes to reach the tab key, and this also helped me learn kubectl faster. This is just a personal preference though I see the need for auto completion.
@@BrotherPatrix Good points. "devs today don't put security as a first priority" - This is one of my biggest gripes in the "devops" trend. Devs like "just disable SELinux so my app works!" or "give me root so I can install some things!" instead of working with the systems admins to create SELinux policy packages or install whatever else is needed to get the app running. Regarding pods - they're more like a docker-compose.yml file, where you can specify more than one container or volume or whatever to run on a single host, whereas a stack is a set of containers (services) running in a swarm, which is a cluster of one or more nodes (servers running Docker daemon) that can balance the containers (called services) out. If one of the worker nodes in the swarm goes offline, the manager nodes can instruct one of the other workers to pick up the workload and bring the container back online. It's more of a high availability thing than just a pod. There is, however, a thing with Kubernetes and control planes and joining them almost exactly like you would docker nodes - the process is very similar. However, that is not the main goal of Podman - Podman was created and intended for development and smaller servers. For those that want or need orchestration and clustering, there's the 'podman generate kubernetes' command to help with the transition from Podman to Kubernetes. Regarding tab completion - that depends. If you have a container with an egregious name like "main_nginx.1.l25lzk4aitsekosa9nbsx3zll" that's a lot longer to type than something short like "apache". And it's really not that far away if you have average sized hands and keep your fingers on the keyboard. It's just as easy to type "a" as it is to hit tab.
@@NobleKangaroo. I absolutely agree with neglected security, but I can't really blame my co-workers, especially juniors when they have to face hard to work with clients with strict deadlines and not time to educate people in good security practices. Also, not fair of me to compare different orchestrators, especially when docker-compose files are easier to write, but Podman and Kubernetes kinda overshadowed docker-compose and Swarm, because I found them as different solutions to the same problems even if technically they do it differently. It's just a matter of convenience for me, write pods in Podman, generate Kubernetes manifest files and transition them to production. Now that I think about the tab part, because I always use ssh connections I have the luxury to do a podman ps and copy paste the container id to do a podman rm command, but what if I had to run these commands directly at the physical server using the basic terminal emulator... ouch... I guess my argument doesn't really cover all use-cases. Oh, and I do have long fingers so I guess I was a bit inconsiderate... my bad.
Just to be mentioned here, Docker can be run rootless as well. That kind of installation is not yet well supported across all distros, so you may need to adjust few configs manually. But I'm pretty sure, it becomes a default installation mode very soon.
True. I have been hearing this for over a year about docker making rootless mode more accessible. I actually got a phone call from docker to discuss this situation. That's one of the major reasons many companies are still reluctant about using docker
I've been using rootless Docker exclusively on Ubuntu 20.04 and 22.04 for quite some time now. It's definitely at a stage where it should be the default recommended mode.
I thoroughly enjoy Mr. Hammond's content but this is one where I don't agree. First, as you've mentioned Docker can be run rootless - I've been doing this for about a year and it's generally been a non-issue. I would guess it becomes default by end of 2023. The second thing is that it's very rare to run singular containers in typical use cases. I do alias commands to `docker run` in a number of cases but, that's really it. When you're leveraging Docker in a more typical use case most people are leveraging Docker Compose. I realize Podman now supports Compose - but why? Podman is great in theory, but if you're looking for an entire solution to support build, run and orchestration - Podman is much more of a mess of tooling. Finally, I'm not a fan of how RedHat/BlueHat/PurpleHat has, historically, gone about advocating Podman. If you look back at how Dan Walsh (Red Hat) talked about Docker and what Podman was here to do, you can see it's RedHat CYA'ing their enterprise customers of OpenShift. RedHat wanted Docker to have no footprint in their container sandbox, and Podman's original goal was to box Docker out of any RHEL environments. Remember that RHEL wouldn't support Docker and removed it from the repos. So, there's a lot more than meets the eye here and while, again, I think Mr. Hammond puts out fantastic content - this is one area where I don't think he's done due diligence in plaingly calling for everyone to "just use Podman". That's a bit ridiculous for a 10 minute video.
I love to see all the discourse and conversation on here, especially keeping me honest where I fall short and neglect to mention Docker can also run rootless. All the points on Podman are totally agreed, and I would hope this video shares more of an advisory, or just a "so you know" and showcasing its existence, as another option. I realize the dumb clickbait cringe title says "you should use Podman" but I can switch that to "you should _try_ Podman", because at the end of the video I outright say, I don't know if it works better for your own use case than Docker. It totally depends, but you can try it and kick the tires and see how you like it. Either way, sorry for butting in, I super appreciate feedback and all constructive criticism shared here. Huge thanks for watching and helping me learn too!
kubernetes is not a container runtime engine ;) kubernetes is a container orchestration system it uses a container runtime engine like containerd, cri-o under the hood (used to be docker but they removed support for that)
Rootless networking with podman is a very steep learning curve, and still has bugs around netavark and DNS. Still an awesome tool/initiative on non monolith container stack!
There are special files that enable additional levels of tab completion in the shell for each binary where that works. The docker devs have apparently created those files, while the podman devs haven’t yet.
Podman is nice not exact drop in replacement for docker making systemd services for podman is a bit different but onc you do it you can make the service a user service as it doesn't require root to run.
singularity/apptainer is similar to this, but you are user inside the container, too. I guess if you have to be root inside a container that could be nice.
There are some gotchas accessing volumes in rootless mode. It's still entirely possible but very frustrating at times when you are first unable to mount a directory or a file has permissions changed on startup.
But once the user signs out all the podman containers are automatically stopped, I have even tried to create a systemd service but it doesn't work with system services but only works as user service so once I sign out it will be gone, how can I have a container running in background
You have to enable Linger which is with a command called Loginctl I believe. Found it through google. My rootless containers now survive surprise reboots and with no interaction as I desired.
Thanks John! portainer is nice but i mostly ignore it and do everything from cli gives me more control, might be time for me to switch to podman makes me nervous having public facing containers running as root.
The biggest anti-security feature of podman and other RedHat tools is the ability to change the default registry to something other than Docker Hub. It creates dependency confusion attacks where they didn't previously exist.
Your autocompletion problem is most probably due to a shell you are using - which doesn't happen to have Podman autocompletion. Should be easy enough to install that on top of your shell (bash / zsh i.e)
It is NOT a drop in replacement for docker, that’s largely fake news for anything but the most basic usage of docker. Be prepared for things to not work after doing “alias docker=‘podman’”
@@Wahinies I mean Portainer is more well-known I guess so it has an advantage in that. It should also be pretty simple to set up (just as on docker) as podman exposes the docker endpoint.
Sorry John, but podman is rubbish from experience in different environments, and not stable at all, and the amount of flags they add are useless. Docker now can run rootless and more stable than podman
For me it's Buildah that was the dealbreaker. I love buildah, especially the alternate way to make containers with `buildah from` and `buildah mount`. But damn is it slow and inefficient. When working with bigger images (1-2GB), it takes forever to save and push the images, when it pushes it at all. It even creates a whole uncompressed copy of the images when pushing. All that on top of having no build caching whatsoever. When I switched back to regular Docker, my builds went from like 15-20 minutes to 3-5 minutes from scratch, and actually mere seconds when doing simple tweaks. I spent more time working around buildah's limitations than actually developing the container itself... In the end I even had shell scripts to manually add my changes on top of existing images so that build times would be usable. Very cool tech, very not ready for production yet outside of hobbyists.
I don't care about security, I just don't like daemons and don't want to muck up my OS with docker when I just need a container for personal development.
Hi I watched your video's and I want to say your amazing. I'm reaching out to you because somebody hacked my Facebook, Whatsapp, and cashapp and they robbed me. Now they are texting me saying they are gonna kill my mother and my kids. I need your help. I mean really need your help I don't know how to stop this and I can not find out who this is so the cops can do there job. I'm asking I'm just asking can you please help. If not I understand.
Check to make sure your shell's rc init file has the completion added. for bash: podman completion -f /etc/bash_completion.d/podman bash. for zsh: podman completion -f “${fpath[1]}/_podman” zsh. Podman can do some pretty cool things with kubernetes deployment or pod definitions via podman play kube my_deployment.yml
Great video as always. Good overview of how to use Podman for anyone interested in getting their toes wet.
Couple bits of input:
1) Podman isn't exactly a dropin Docker replacement - it works for most things, but doesn't support Docker stacks in swarm mode for instance. Also, Docker can build images without additional tools while Podman requires Buildah to do so. There are other differences as well. As such, it's exactly not a 100% drop-in replacement.
2) Docker containers don't have to run as root - it's up to the image creator to decide how they operate. The container can absolutely switch users and execute commands as non-root if the image creator wants to. Similarly, the Docker daemon can be configured to run without root access. This isn't the default, but it's still possible.
3) You should really avoid using apt to install the docker packages as those are old versions of Docker, and follow the install instructions on the Docker website instead.
4) The -d in your command isn't for daemon mode, but to run a container in detached mode; that is, in the background. You can actually reattach to these containers if you like with the 'podman attach' command.
5) Your tab complete can be fixed by using the full command syntax, e.g. 'podman container stop' then pressing tab. Without passing 'container' to podman as the first arg, the autocomplete behaves weird. I think that's something they may address in the future as the shorthand syntax (without verbosely using 'podman container' every time) is very common and Docker allows it.
That said, Podman is still a great alternative in the container landscape and offers some great benefits over Docker if you don't need to run high availability stacks in swarm mode. It's got some room to grow and catch up with Docker, but is looking very promising.
Buildah is not necessary to build containers with Podman. Podman uses buildah's code base under the hood, but you don't need the buildah binary installed to build containers with podman.
[root@localhost ~]# find / -name buildah
[root@localhost ~]# podman build -f Containerfile
STEP 1/2: FROM rhel7
STEP 2/2: CMD ["/bin/bash"]
COMMIT
--> 0001f1e9700
0001f1e9700d179a611b5f37e59c874a6ad3ac5a197da473648962ff36b7b1f3
@@trevor.viljoen Ahh okay, I thought at one point it was required but that may have changed. Thanks for letting me know.
"Docker containers don't have to run as root" - true, but the majority of people getting into docker will run them by default with root, which is a bad security practice but defaulting to rootless containers can at least mitigate some issues, something I find really odd why docker devs did not think of this. I agree that developers should take responsibility, but you cannot deny that devs today don't put security as a first priority.
"doesn't support Docker stacks in swarm" - it doesn't have to, because Podman has a feature called pods, and in each pod you can run multiple containers, same philosophy as Kubernetes, but I'm not entirely sure about the load balancing features and horizontal scalability. What's fun about Podman pods is that you can import and export them as a Kubernetes yaml file. I'd argue that pods don't need production ready features seeing that the majority are using Kubernetes for that, or even Openshift which is an RedHat orchestrator built on top of Kubernetes. You see the pattern here? Why should they support something that is inferior to the number one orchestrator in the world, and you can have a cool development set-up with podman and minikube to test pre-production.
And last bit, about tab completion, I'd argue that it's better it should not be used because when you get used to the tool you type it faster than how much time it takes to reach the tab key, and this also helped me learn kubectl faster. This is just a personal preference though I see the need for auto completion.
@@BrotherPatrix Good points.
"devs today don't put security as a first priority" - This is one of my biggest gripes in the "devops" trend. Devs like "just disable SELinux so my app works!" or "give me root so I can install some things!" instead of working with the systems admins to create SELinux policy packages or install whatever else is needed to get the app running.
Regarding pods - they're more like a docker-compose.yml file, where you can specify more than one container or volume or whatever to run on a single host, whereas a stack is a set of containers (services) running in a swarm, which is a cluster of one or more nodes (servers running Docker daemon) that can balance the containers (called services) out. If one of the worker nodes in the swarm goes offline, the manager nodes can instruct one of the other workers to pick up the workload and bring the container back online. It's more of a high availability thing than just a pod. There is, however, a thing with Kubernetes and control planes and joining them almost exactly like you would docker nodes - the process is very similar. However, that is not the main goal of Podman - Podman was created and intended for development and smaller servers. For those that want or need orchestration and clustering, there's the 'podman generate kubernetes' command to help with the transition from Podman to Kubernetes.
Regarding tab completion - that depends. If you have a container with an egregious name like "main_nginx.1.l25lzk4aitsekosa9nbsx3zll" that's a lot longer to type than something short like "apache". And it's really not that far away if you have average sized hands and keep your fingers on the keyboard. It's just as easy to type "a" as it is to hit tab.
@@NobleKangaroo. I absolutely agree with neglected security, but I can't really blame my co-workers, especially juniors when they have to face hard to work with clients with strict deadlines and not time to educate people in good security practices.
Also, not fair of me to compare different orchestrators, especially when docker-compose files are easier to write, but Podman and Kubernetes kinda overshadowed docker-compose and Swarm, because I found them as different solutions to the same problems even if technically they do it differently. It's just a matter of convenience for me, write pods in Podman, generate Kubernetes manifest files and transition them to production.
Now that I think about the tab part, because I always use ssh connections I have the luxury to do a podman ps and copy paste the container id to do a podman rm command, but what if I had to run these commands directly at the physical server using the basic terminal emulator... ouch... I guess my argument doesn't really cover all use-cases. Oh, and I do have long fingers so I guess I was a bit inconsiderate... my bad.
Just to be mentioned here, Docker can be run rootless as well. That kind of installation is not yet well supported across all distros, so you may need to adjust few configs manually. But I'm pretty sure, it becomes a default installation mode very soon.
True. I have been hearing this for over a year about docker making rootless mode more accessible. I actually got a phone call from docker to discuss this situation. That's one of the major reasons many companies are still reluctant about using docker
I've been using rootless Docker exclusively on Ubuntu 20.04 and 22.04 for quite some time now. It's definitely at a stage where it should be the default recommended mode.
I thoroughly enjoy Mr. Hammond's content but this is one where I don't agree. First, as you've mentioned Docker can be run rootless - I've been doing this for about a year and it's generally been a non-issue. I would guess it becomes default by end of 2023. The second thing is that it's very rare to run singular containers in typical use cases. I do alias commands to `docker run` in a number of cases but, that's really it. When you're leveraging Docker in a more typical use case most people are leveraging Docker Compose. I realize Podman now supports Compose - but why? Podman is great in theory, but if you're looking for an entire solution to support build, run and orchestration - Podman is much more of a mess of tooling.
Finally, I'm not a fan of how RedHat/BlueHat/PurpleHat has, historically, gone about advocating Podman. If you look back at how Dan Walsh (Red Hat) talked about Docker and what Podman was here to do, you can see it's RedHat CYA'ing their enterprise customers of OpenShift. RedHat wanted Docker to have no footprint in their container sandbox, and Podman's original goal was to box Docker out of any RHEL environments. Remember that RHEL wouldn't support Docker and removed it from the repos.
So, there's a lot more than meets the eye here and while, again, I think Mr. Hammond puts out fantastic content - this is one area where I don't think he's done due diligence in plaingly calling for everyone to "just use Podman". That's a bit ridiculous for a 10 minute video.
I love to see all the discourse and conversation on here, especially keeping me honest where I fall short and neglect to mention Docker can also run rootless. All the points on Podman are totally agreed, and I would hope this video shares more of an advisory, or just a "so you know" and showcasing its existence, as another option. I realize the dumb clickbait cringe title says "you should use Podman" but I can switch that to "you should _try_ Podman", because at the end of the video I outright say, I don't know if it works better for your own use case than Docker. It totally depends, but you can try it and kick the tires and see how you like it.
Either way, sorry for butting in, I super appreciate feedback and all constructive criticism shared here. Huge thanks for watching and helping me learn too!
@@_JohnHammond Podman also has a lot of issues, just try stable Debian the one in the repos is completely broken and forget about podman-compose.
kubernetes is not a container runtime engine ;) kubernetes is a container orchestration system it uses a container runtime engine like containerd, cri-o under the hood (used to be docker but they removed support for that)
The video editing was unexpected, but it was a really nice surprise I have to say!
Watching John's videos is a lifestyle.
🍷🗿
📠, no 🖨️
Rootless networking with podman is a very steep learning curve, and still has bugs around netavark and DNS. Still an awesome tool/initiative on non monolith container stack!
Super easy with slirp4netns the biggest pain was figuring out some permissions and what hostname environment variable one of my containers wanted.
There are special files that enable additional levels of tab completion in the shell for each binary where that works. The docker devs have apparently created those files, while the podman devs haven’t yet.
I don't think thats the case, he probably only installed/configured the zsh plugin for docker not the podman one
Nice, thanks John!
Shared to a few of my colleagues.
That visual effects are awesome
There is a solution for monitoring podman?
never used docker learning containerization now, i think podman might be the better option?
Any thoughts about Pods, the GUI for Podman?
I was going to launch my first docker this week…might as well play with podman too.
What terminal are you using? This autocompletion preview is pretty cool!
Thank you great video! I am switching to podman on my dev machine and kaniko on my k8s clusters.
interesting video but i feel like docker has also supported rootless mode for a while
I suggest you use ´docker ps -a´ to see stopped containers.;)
Can you make a video on LXC/LXD any how they compare to docker/podman?
Podman is nice not exact drop in replacement for docker making systemd services for podman is a bit different but onc you do it you can make the service a user service as it doesn't require root to run.
even you can use a wrapper like compose, podman-compose :)
Loved the video editing :-D
8:00 maybe something to do with bash completion rules
What about the restart always or until stopped? Can podman restart your containers after a reboot without having a demon service running?
You have a video about your setup, it's super cool! May I ask you to make a video about the books you studied from?
Hi John.. .
Like the new style in editing...
And finally some background music..
Top notch as always..
singularity/apptainer is similar to this, but you are user inside the container, too. I guess if you have to be root inside a container that could be nice.
Podman does not have a swarm mode, when you need to deploy a small cluster. Best regards.
There are some gotchas accessing volumes in rootless mode. It's still entirely possible but very frustrating at times when you are first unable to mount a directory or a file has permissions changed on startup.
But once the user signs out all the podman containers are automatically stopped, I have even tried to create a systemd service but it doesn't work with system services but only works as user service so once I sign out it will be gone, how can I have a container running in background
You have to enable Linger which is with a command called Loginctl I believe. Found it through google. My rootless containers now survive surprise reboots and with no interaction as I desired.
Is there something similar to docker-compose?
What happened to rocket?
What about if i want to see the interaction with the container?
Like the requests and all that stuff 🤔
Thanks John! portainer is nice but i mostly ignore it and do everything from cli gives me more control, might be time for me to switch to podman makes me nervous having public facing containers running as root.
its really awesome to build custom kali vm's with podman. gonna install kali again soon.
The biggest anti-security feature of podman and other RedHat tools is the ability to change the default registry to something other than Docker Hub. It creates dependency confusion attacks where they didn't previously exist.
thx. great intro to Podman.
John doesn't need any creative thumbnail
He will manage thumbnails by his face shot
Your autocompletion problem is most probably due to a shell you are using - which doesn't happen to have Podman autocompletion. Should be easy enough to install that on top of your shell (bash / zsh i.e)
Yep! This is achieved through podman-completion.
It is NOT a drop in replacement for docker, that’s largely fake news for anything but the most basic usage of docker.
Be prepared for things to not work after doing “alias docker=‘podman’”
you had me at demon-less
Preach!
You should be using CRI-O in production.
John is a Saint for this Kind of Stuff. Keep being awesome
we need podman-compose next
cool
thanks
I think it's possible to run Portainer with Podman.
But why though Cockpits got the barebones down
@@Wahinies I mean Portainer is more well-known I guess so it has an advantage in that. It should also be pretty simple to set up (just as on docker) as podman exposes the docker endpoint.
Podman is better than docker for a lot of situations.
Techno John
It's better than docker
I thought you will explain uid mapping than just said no root, sure "no root"
i'm a podman
Sorry John, but podman is rubbish from experience in different environments, and not stable at all, and the amount of flags they add are useless.
Docker now can run rootless and more stable than podman
For me it's Buildah that was the dealbreaker.
I love buildah, especially the alternate way to make containers with `buildah from` and `buildah mount`. But damn is it slow and inefficient. When working with bigger images (1-2GB), it takes forever to save and push the images, when it pushes it at all. It even creates a whole uncompressed copy of the images when pushing. All that on top of having no build caching whatsoever.
When I switched back to regular Docker, my builds went from like 15-20 minutes to 3-5 minutes from scratch, and actually mere seconds when doing simple tweaks. I spent more time working around buildah's limitations than actually developing the container itself... In the end I even had shell scripts to manually add my changes on top of existing images so that build times would be usable.
Very cool tech, very not ready for production yet outside of hobbyists.
@@maxpoulin64 I agree with you, buildah is impressive tool but podman i have bad experience with it
sandman >>> podman
Why?
Its a megaman reference
I literally don't understand a words he's speaking why am I watching this
I don't care about security, I just don't like daemons and don't want to muck up my OS with docker when I just need a container for personal development.
i didnt understand a word in the first sentence
Hi I watched your video's and I want to say your amazing. I'm reaching out to you because somebody hacked my Facebook, Whatsapp, and cashapp and they robbed me. Now they are texting me saying they are gonna kill my mother and my kids. I need your help. I mean really need your help I don't know how to stop this and I can not find out who this is so the cops can do there job. I'm asking I'm just asking can you please help. If not I understand.
Nice
💖💖
inside the container u are root. but what is running ur container isnt root.
It’s pronounced DEE-mun, not DAY-mun. And as we’re not in the navy, “tack” should really be “minus” (no, not dash, which is - or -).
Sadly podman is slow af. No thanks. Maybe one day when they can actually build images without it taking ten years
hahahahaha
First
Check to make sure your shell's rc init file has the completion added. for bash: podman completion -f /etc/bash_completion.d/podman bash. for zsh: podman completion -f “${fpath[1]}/_podman” zsh. Podman can do some pretty cool things with kubernetes deployment or pod definitions via podman play kube my_deployment.yml
Waste of time