Podman Desktop celebrates 3M downloads(podman-desktop.io) |
Podman Desktop celebrates 3M downloads(podman-desktop.io) |
Whereas when I install Docker in WSL it runs inside of my WSL VM.
You have piqued my curiosity. What does Docker Desktop do that the CLI cannot?
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.
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>
Zero problems with Podman Desktop.
Cool for Podman Desktop though.
$ brew install podman-desktop
… play a little …
$ brew remove —zap docker-desktop
Have been happy ever since. No more smells of enshittification. Now if I could just zap slack and figma…
Figma is so slow on my 3-4 year old x64 mbp I couldn’t possibly use it.
( They have a pretty good ratio of seeds that grows into vs seeds that don’t. They also make minimal investment until the project is viable. This does not seem to be a common approach. )
Likewise, I am contributing to Rancher Desktop downloads with such kind of customers.
The only use case I encountered is people who want to run Docker without root or admin permissions and use Podman just as a drop-in replacement.
It lets you define a systemd job with some custom syntax and run it as a systemd service, and even stretches to allow some form of kubernetes YAML to be run as local (single node, rootless) containers!
Real nice.
See previous presentation on HN: https://news.ycombinator.com/item?id=43456934
_But why?_
I mean, if you have one container service only and everything else is ran by systemd, then it makes sense to keep it easy. But other than that, why? Systemd's syntax and docs aren't particularly friendly or easy, so it's not like you gain in simplicity vs just running docker/podman-compose, or even a lightweight orchestrator like Nomad.
> Error: creating container storage: the container name "..." is already in use by [hash]. You have to remove that container to be able to reuse that name: that name is already in use, or use --replace to instruct Podman to do so.
And then you try to run `podman compose up --replace` except that's not a recognized argument, so eventually you figure out that you have to run `podman compose down` to clean whatever state is causing issues. I find that I have to do that every time I CTRL+C quit out of `podman compose up` (even though I always let it clean up and then exit on its own), which is a hassle.
I'm considering going back to using Docker Engine.
[1] https://github.com/containers/podman-compose/issues/1072
Congrats to podman team.
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.
Podman comes with an auto-update flag you can set for containers that uses systemd to do this for you. Takes a bit of reading to get it right but its smooth sailing mostly.
Everything else has been working as a drop-in replacement.
- seamless container logs (journalctl), no weird separate logger
- service start/stop/enable-at-boot no weird separate command
- integration with system/user slices, triggers, cronjobs (timers), exposing containers as first class commands overall!
Basically it's worth seeing container services work with non-container services.
If you don't like systemd, or have no stake in it, sure, have fun without it, but it's definitely added value when you're running services, and want to start containerizing some of them without abandoning all the good tools you are using in favour of docker logs docker run etc.
podman kube play --replace k8s.yaml
podman kube down k8s.yaml
podman kube apply --namespace project -f k8s.yaml
But again, they're talking about Windows, not Linux-in-Windows or virtualized Linux on Windows. Just because you can do something in WSL2 doesn't mean you "can do it on Windows", as much as you "can run systemd and Wayland on Windows" because you could run it inside a Linux VM...
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.
- Install Ubuntu distro in WSL2.
- Create an ssh key pair on the Windows side using ssh-keygen.
In Ubuntu:
- Install Docker engine using Docker's apt-get instructions for Ubuntu.
- Add the ssh public key to ~/.ssh/authorized_keys.
In Windows:
- Run "wsl hostname -I" to get your WSL2 hostname.
- Test "ssh user@wsl-host", using the WSL2 hostname. It should work without prompting for a password.
- Unzip docker.exe somewhere.
- In your user environment variables, set PATH to include the directory with docker.exe, and set DOCKER_HOST to "ssh://user@wsl-host", using the WSL2 hostname.
That should be it; you should now be able to run docker normally from your Windows user, using file context from the Windows side.
The reason we launched Docker Desktop (initially known as "Docker for Mac") was to make the user experience better: easier to install, better integrated with the system (virtualization APIs, keychain, VPNs, etc), and better support for host volumes.
I do think it makes sense to add more GUI features over time, to make Docker more approachable - not everyone is a CLI wizard. But, it shouldn't make the app slower or annoying to use for those who don't need it.
WSL1 yes, but not WSL2, which the parent explicitly mentioned. WSL2 is just virtualization with a fancier name, might as well use VirtualBox and similar at that point.