I'm glad they have podman desktop. Personally though, once I realized that I can use the command line version without it (unlike docker in my experience) I uninstalled it as I don't really need the UI / KIND, etc. For me the command line is fine and having something where I don't have to first shell into wsl is great (it just runs it itself behind the scenes). Of course, Linux is generally better for development imo but this is a nice compromise on Windows.
For mac, wouldn't it be just easier to use lima from cli? How does Podman compare to that? Docker unless on Linux has always being a bloat.
Or are there any lightweight hypervisor on top of firecracker alternative? At this point with the way systemd is going, we should just switch back to VM? Everything is just more mature on native OS install. Docker to Linux, just feels kinda like SPA reinventing the html parsing on top of a rendering engine.
Havn't tried Colima, but podman is very simple to use and smells like docker cli.
On Apple Silicon machines however, latest podman version uses VM images which Rosetta doesn't work with, and hence it will use qemu for running amd64 containers. You can fix this by either installing podman 5.5 or create the VM from and older image [1]. My only complaint here is that the stock machine images are pretty large (~1G )
If you use containers to run tools that create files in your host (i.e. build tools), then you can use your host username as the default in the VM (machine init --username $(id -un)), and then run containers with --userns=keep-id. That way the the container command starts with the same username and uid as you host user - this is pretty tricky to get working with docker, from my experience.
We use Bazel as our build tool and we create a lot of images based on shared layers. Bazel produces oci layout directories that contain descriptors and symlinks to the actual layer tars. Podman can start a container "directly" from these directories[2], which speeds up image testing considerably, since it can detect known layers immediately. With docker you have to stream a tarball with all the layers and descriptors to the docker daemon, only for it to discover that it already knows most of the layers.
I used colima cli on M1-M2 Mac. A few memory related settings were required as some of old apps were huge. But apart from that it worked great. Nothing bad podman, just preferred colima.
I'm the same. I just use Docker/Podman from the terminal. I know some people really like the GUI but I've never been able to find a workflow better than the cli with some scripts or compose.
`docker machine` was deprecated in favor of Docker Desktop in order to funnel people towards paid licenses. But there's no real reason Docker on non-Linux should need a GUI.
Since they mention Windows, I believe this is a reference to the fact that you cannot (easily) install the Docker CLI without Docker Desktop. Podman does not have this issue.
my interaction with docker is limited to a make file that has a `docker-compose up` command, would podman work if the rest of my team is still on docker ?
yes "Podman v3.0 and later versions introduced a compatible RESTful API that emulates the Docker API. This allows the standard docker-compose command-line tool to interact with a Podman backend instead of a Docker daemon."
It almost is, the first change you'd see is understanding that each container is a separate process and thus for it to auto start you'd need to generate systemd service files. podman has an autogenerator for this, so it is 'just' two extra commands on the terminal but something easy to miss when you are starting out.
I use podman desktop on Windows for common development stuff as drop in replacement. I switched due to licensing as I guess universities do not fall under the licencing exceptions. I actually also use the docker CLI, particularly docker compose. I was motivated to do the same on one of our Debian vms, because I could more install podmap via standard apt sources, i hoped that it doesn't mess to that much with the IP stack and it is a bit closer to K8s which I still deemed as overkill. However, trying to install e.g. komo.do via podman compose was a total fail. Even after fixing socket locations, etc, I would see weird behavior. So yes, it is a clear 'almost'. However, the critical cases can become easily very frustrating. Again, on my windows laptop with WSL2 it works like a charm, but there I also do not run server deployments that need to work reliably out of the box.
Mostly valid. There are a few gotchas but for most use cases it is drop-in.
I think I've run into issues with the podman socket, and there were some permissions problems I had getting games-on-whales setup in userspace.
I had a brief period of setup pain and then have never looked back, though have occasionally wished that feature parity came a little quicker. Podman is in many ways a delight, simpler in what it does in the general case and yet as powerful as docker or more.
It's got a more modern design while having a drop-in CLI interface to docker (and also if needed a near-drop-in replacement for the docker socket API). This makes it the preferred backend for tools like distrobox.
With Docker, I found rootless setup to be a PITA, despite having experience with unprivileged LXC containers. The manager daemon constantly consumed system resources even when no containers were running. Docker upgrades sometimes refused to run my containers until I chased down whatever storage driver problem they introduced in the latest version.
When the most recent upgrade broke my containers yet again, I decided to give Podman a try. Setup was a breeze. There is no management daemon wasting resources. My containers just worked. Even the little cron script I wrote to query Docker for pending image updates just worked with Podman tools.
I think Podman also makes it easy to map host uids to non-root container uids, which ought to help me reduce attack surface. (I haven't actually tried this feature yet.) Last time I checked, Docker did not.
That's funny. To me one of the whole point of containers is that it's not systemd that's PID1.
Combine that with a distro like Talos, an immutable Linux distro that contains less than ten executables and where none of them is systemd and...
At long last containers and stuff like Talos show a path leading to, in a not-so-distant future, a world where we can be systemd and [ini]/microsoft config files (from a microsoft employee btw) free again.
It's not about running systemd in the container (practically nothing does that, though I myself considered it for a multi-user ssh shell system), but making containers manageable under systemd alongside other units.
Is that a question or a statement? I'm running Kubernetes on Docker Desktop. But every few months Docker Desktop either outright craps out and forces me to wipe everything and rebuild my containers or the latest annoyance is that it keeps giving me popups saying something something couldn't start Ubuntu.... but then seems to work perfectly fine after skipping it 10 times.
I'm glad they have podman desktop. Personally though, once I realized that I can use the command line version without it (unlike docker in my experience) I uninstalled it as I don't really need the UI / KIND, etc. For me the command line is fine and having something where I don't have to first shell into wsl is great (it just runs it itself behind the scenes). Of course, Linux is generally better for development imo but this is a nice compromise on Windows.
For mac, wouldn't it be just easier to use lima from cli? How does Podman compare to that? Docker unless on Linux has always being a bloat.
Or are there any lightweight hypervisor on top of firecracker alternative? At this point with the way systemd is going, we should just switch back to VM? Everything is just more mature on native OS install. Docker to Linux, just feels kinda like SPA reinventing the html parsing on top of a rendering engine.
Havn't tried Colima, but podman is very simple to use and smells like docker cli.
On Apple Silicon machines however, latest podman version uses VM images which Rosetta doesn't work with, and hence it will use qemu for running amd64 containers. You can fix this by either installing podman 5.5 or create the VM from and older image [1]. My only complaint here is that the stock machine images are pretty large (~1G )
If you use containers to run tools that create files in your host (i.e. build tools), then you can use your host username as the default in the VM (machine init --username $(id -un)), and then run containers with --userns=keep-id. That way the the container command starts with the same username and uid as you host user - this is pretty tricky to get working with docker, from my experience.
We use Bazel as our build tool and we create a lot of images based on shared layers. Bazel produces oci layout directories that contain descriptors and symlinks to the actual layer tars. Podman can start a container "directly" from these directories[2], which speeds up image testing considerably, since it can detect known layers immediately. With docker you have to stream a tarball with all the layers and descriptors to the docker daemon, only for it to discover that it already knows most of the layers.
[1] https://docs.podman.io/en/latest/markdown/podman-machine-ini... - machine images https://quay.io/repository/podman/machine-os
[2] podman run oci://<path to oci-layout-dir>
I used colima cli on M1-M2 Mac. A few memory related settings were required as some of old apps were huge. But apart from that it worked great. Nothing bad podman, just preferred colima.
Brew install podman? CLI only, no lima/colima or gui required.
I'm the same. I just use Docker/Podman from the terminal. I know some people really like the GUI but I've never been able to find a workflow better than the cli with some scripts or compose.
Cool for Podman Desktop though.
> unlike docker in my experience
You have piqued my curiosity. What does Docker Desktop do that the CLI cannot?
`docker machine` was deprecated in favor of Docker Desktop in order to funnel people towards paid licenses. But there's no real reason Docker on non-Linux should need a GUI.
Since they mention Windows, I believe this is a reference to the fact that you cannot (easily) install the Docker CLI without Docker Desktop. Podman does not have this issue.
You absolutely can run docker on the CLI in WSL2. The only requirement is you have systemd running in your WSL distro, which is fully supported.
my interaction with docker is limited to a make file that has a `docker-compose up` command, would podman work if the rest of my team is still on docker ?
yes "Podman v3.0 and later versions introduced a compatible RESTful API that emulates the Docker API. This allows the standard docker-compose command-line tool to interact with a Podman backend instead of a Docker daemon."
I've seen podman advertised as a dropin docker replacement. how valid is that assertion?
It almost is, the first change you'd see is understanding that each container is a separate process and thus for it to auto start you'd need to generate systemd service files. podman has an autogenerator for this, so it is 'just' two extra commands on the terminal but something easy to miss when you are starting out.
I use podman desktop on Windows for common development stuff as drop in replacement. I switched due to licensing as I guess universities do not fall under the licencing exceptions. I actually also use the docker CLI, particularly docker compose. I was motivated to do the same on one of our Debian vms, because I could more install podmap via standard apt sources, i hoped that it doesn't mess to that much with the IP stack and it is a bit closer to K8s which I still deemed as overkill. However, trying to install e.g. komo.do via podman compose was a total fail. Even after fixing socket locations, etc, I would see weird behavior. So yes, it is a clear 'almost'. However, the critical cases can become easily very frustrating. Again, on my windows laptop with WSL2 it works like a charm, but there I also do not run server deployments that need to work reliably out of the box.
I wasted my time trying podman and switched to colima. It's the only usable free alternative that's a true drop-in replacement for docker.
colima is great. I've also had good luck with rancher-desktop too.
RD is colima + some other stuff. I prefer vanilla colima (also works on Linux!)
I almost never notice the difference. I know there are some edge cases that will get you, but I've never run into them.
Mostly valid. There are a few gotchas but for most use cases it is drop-in. I think I've run into issues with the podman socket, and there were some permissions problems I had getting games-on-whales setup in userspace.
I had a brief period of setup pain and then have never looked back, though have occasionally wished that feature parity came a little quicker. Podman is in many ways a delight, simpler in what it does in the general case and yet as powerful as docker or more.
Congratulations to the podman team!
Why podman and not Docker?
It's got a more modern design while having a drop-in CLI interface to docker (and also if needed a near-drop-in replacement for the docker socket API). This makes it the preferred backend for tools like distrobox.
I run rootless containers on a low-power system.
With Docker, I found rootless setup to be a PITA, despite having experience with unprivileged LXC containers. The manager daemon constantly consumed system resources even when no containers were running. Docker upgrades sometimes refused to run my containers until I chased down whatever storage driver problem they introduced in the latest version.
When the most recent upgrade broke my containers yet again, I decided to give Podman a try. Setup was a breeze. There is no management daemon wasting resources. My containers just worked. Even the little cron script I wrote to query Docker for pending image updates just worked with Podman tools.
I think Podman also makes it easy to map host uids to non-root container uids, which ought to help me reduce attack surface. (I haven't actually tried this feature yet.) Last time I checked, Docker did not.
So far, I couldn't be happier.
It's free? Can run rootless?
Better integration with systemd
That's funny. To me one of the whole point of containers is that it's not systemd that's PID1.
Combine that with a distro like Talos, an immutable Linux distro that contains less than ten executables and where none of them is systemd and...
At long last containers and stuff like Talos show a path leading to, in a not-so-distant future, a world where we can be systemd and [ini]/microsoft config files (from a microsoft employee btw) free again.
It's not about running systemd in the container (practically nothing does that, though I myself considered it for a multi-user ssh shell system), but making containers manageable under systemd alongside other units.
On Snapdragon / ARM Windows, it is the only game in town -- and it works great too!
docker desktop licensing changes in 2021
It comes preinstalled on RHEL8 and I can't be bothered to swap them.
It supports Kubernetes *.yaml manifests?
Is that a question or a statement? I'm running Kubernetes on Docker Desktop. But every few months Docker Desktop either outright craps out and forces me to wipe everything and rebuild my containers or the latest annoyance is that it keeps giving me popups saying something something couldn't start Ubuntu.... but then seems to work perfectly fine after skipping it 10 times.
Docker took too long to support cgroups v2