After docker desktop became unusable, I jumped to colima and never looked back. I still use the docker runtime in it (the non-proprietary part) but it also supports containerd. On Mac it's just a "brew install colima" and then "colima start"
I also install the compose and ecr credentials plug-ins (since I use ecr for my container registry.) It has the full functionality of docker desktop minus the UI, which I never used anyways.
I moved from the Mac platform for all the hoops you have to run though to run containers. On Linux I can do it without a VM. (I also hated window management — hello Sway — and the hardware is cheaper).
I’ve moved from Docker to podman as well on Linux. Love it.
Notable too that the VM it runs on Mac comes with qemu user mode emulation and uses binfmt_misc to run binaries for different architectures so obviates the need for Rosetta.
Edit: to try this out compile a “hello world” binary to say arm64 and riscv64 and amd64 and run it all in the same container (be sure to statically link)
Knew it used qemu but didn't know about binfmt_misc. Very cool. I guess that explains why my coworkers with m1 laptops can run our amd64 containers just fine without changes.
Iirc Docker Desktop uses a proprietary VM now, Colima and Podman Desktop use qemu, and I'm not sure about Orbstack (which has come up several times as a lighter weight alternative within this thread.)
I've been using Colima for the past few months now instead of Docker for Mac and it's running great. Only issue I experience is that there is sometimes a delay after saving before files are synced to the container (using volumes), so when you run a test directly after saving it will still use the old file, or even worse, files that are still in transit, so you have to run your test again a few seconds later.
Been using Orbstack now for a few days and it seems to not have the same file syncing issue, and is faster in every other regard compared to Docker for Mac or Colima.
I haven't experienced any file write delays, have you filed a ticket against the project?
My guess is you're talking about an in-container write with a host system read.
My CI pipelines do this many times a day for code coverage and test results outputs. Those files are tiny though, so I wonder if it has to do with larger file sizes, or perhaps something external to your configuration like samba mounts that isn't playing well with qemus virtual network interface.
We tried to use podman at work (via nix) and ran into all kinds of confusing issues, especially in regards to docker in docker and CI builds. Swapped to using colima (again via nix) for the mac folks and regular docker engine for linux, and things have been much smoother. Definitely recommended if your podman setup is as difficult as ours was.
We also attempted to move to Podman, but it just wasn't ready at the time. Since colima works well for our use case (devs with MacBooks), we haven't had a compelling reason to try Podman again
Curious how this works without a VM, or have they created some sort of linux "shim", a la WSL1.x?
If it's something like WSL1.x it means you're not actually "running linux", which may have subtle repercussions like differences in threading etc since it's really a Darwin system wearing a Linux suit.
That said if you're writing a CRUD app in python, that probably won't matter to you so it's still worth the tradeoff.
“OrbStack uses a lightweight Linux virtual machine with a shared kernel to minimize overhead and save resources, similar to WSL 2 (Windows Subsystem for Linux). This flexible architecture comes with many advantages such as high efficiency, low resource usage, seamless integration with macOS, and more.”
Seems they're maintaining an unpublished fork of the Linux kernel "linux-macvirt" to achieve this. Apparently you have to contact them directly for a copy of the code[1]
I tried to use colima instead of Docker Desktop several months ago on my Mac, but I ran into several difficult issues (i think relating to folder mounts) and gave up.
I've been heavily using bind mounts and volumes in colima so it's likely fixed. I DID encounter bind mount issues in podman, but that was several months ago and might also be resolved. (Edit:typos)
Thanks for sharing this. I got a new M2 mac and installed Podman as I didn’t want the Docker Desktop as well. But ran into multiple issues and gave up and have been begrudgingly putting up with Docker Desktop.
My main complaints are:
* the builds fail randomly
* containers don’t stop when I run docker compose stop from CLI
So, I have to restart Docker Desktop a couple of times to reset everything. Does running the docker runtime with colima also gets into these issues?
Note that these are two different implementations, the standalone docker-compose has different cli arguments and is deprecated for the plugin (which is also a binary executable as you pointed out)
I was under the impression they were sidelining compose in favor of their k8s manifest flavor which.. Well, let's just say I've never been in a compose file and thought "Man, I wish I was writing k8s manifest syntax".
We've been using podman compose for semi-production purposes at our company and that's been our experience as well. It's just... it's really rough, there are a ton of "known" issues, and it's rather unreliable. As a result, I've been really trying to push the "just use the docker daemon in prod instead" (to no avail... yet).
Not op, but the suggestion is likely to use Podman Desktop during local container development. Then switch to the docker runtime in production systems (ec2 etc.)
Podman and Docker Engine are both OCI runtimes. The theory being that containers reproducablly run across different runtimes without changes in behavior.
Half of the point of podman was to avoid the need to run things with root.
Docker compose expects me to have a server running. While I technically could run "podman system service" and configure docker compose to point at a non-standard socket or port in order to run it I would really prefer not to have that kind of headache just to run a script.
Docker compose was also written by docker and exhibits similar levels of shoddiness to docker. The accumulation of bad design decisions by docker is, indeed, why podman exists in the first place. With a little bit of love podman compose could easily surpass docker compose.
FWIW I actually tend to run podman compose inside a podman container. This is so I can containerize the integration tests which orchestrate the app. It's a useful pattern - one I think should be a lot more widely used for several reasons. The systemd service wouldn't work in this context.
I could maybe use some entrypoint magic to run a server when the container starts just so I can use docker compose but still...eww.
Running a podman systemd service might suffice if it was something that could be installed with a snap of two fingers on every environment but if it means fscking around with service files it's definitely not something I'd want to add to a "set up a development environment" README.
I see, interesting.
I guess you are saying that systemd service wouldn't work because it's not available inside the container.
FWIW it's possible to run a rootless podman container with a working systemd inside the container. I've near tried running podman in podman using systemd though.
Is it? I think Podman only works with "docker-compose" (the Python-based tool that can be installed separately from Docker, which Podman is compatible with, which is now deprecated) as opposed to "docker compose" (the Golang-based plugin which is integrated into Docker Engine, which I think Podman is not (yet?) compatible with).
Would love to be proven wrong, as I ended up down quite a rabbit hole with this topic somewhat recently.
The Golang version, aka. Compose v2 can also be used standalone (they even have prebuilt binaries in their GitHub repository) and is compatible with Podman. Behind the scenes both Compose v1 and v2 use the Docker API which is also implemented by Podman (`podman system service`).
In my experience they work fine together most of the time, I have ran into compatibility bugs sometimes, though things seem to be steadily improving.
I use podman compose in my SaaS to automate and make deployment easier for docker containers, it works great in my simple docker compose (image, name, port expose, volume. that’s it). I suppose use case matters, and mine is very simple, but i’ll just toss one more N=1 in the ring.
I think this is on purpose. Podman is suppose to be a stepping stone to OpenShift. They don’t want people using it for anything other than development.
How many workloads that are currently on OpenShift could sit on a RHEL server behind a load balancer and work just as well?
I would wager that the average OpenShift cluster is under 10 nodes, runs COTS software, and a bunch of security and logging apps like Dynatrace and just sits there primarily under utilizes because the COTS vendor is a RH partner and stopped shipping RPMs and said we only support OpenShift moving forward.
Glad to see usability improvements here, but I won't be using it until there's a light theme (asking an application to respect the OS theme is apparently too much these days).
I had to hard facepalm reading the other replies to this. There are people suffering from things like Astigmatism (myself included) who have an extremely hard time, including headaches, using dark themes. People really need to be a bit more empathetic.
Also, as the OP pointed out, people somehow get angry when all you asked is for an app to follow the system's theme. It has been such a huge regression.
As a counter example I too suffer from astigmatism and I prefer dark themes with high contrast. Sometimes I'll pick a theme that doesn't exactly vibe color wise just for the high contrast otherwise it's hard to focus, both mentally and actually reading what's on the screen.
I also zoom in most websites, UIs, code editors and the terminal, so take my personal experience as just another point and nothing definitive.
Yep it is quite possible. For me the realization wasn't until the doctor specifically pointed it out that no lens will 100% correct Astigmatism. Then I googled around and read that dark text on light bg is much easier because the ghosting is less pronounced.
> Also, as the OP pointed out, people somehow get angry when all you asked is for an app to follow the system's theme. It has been such a huge regression.
Was there a time when Podman Desktop supported a light mode? You could change the CSS yourself, which given you only need a light mode, would be pretty trivial.
Please keep in mind that dark themes were introduced as an accessibility feature as well, but not every project can or will prioritize it.
My bad, I did not mean a regression in Podman Desktop specifically, but UI engineering in general. A (couple of?) decades ago it was basically a given that apps will adjust to your system theme (except fancy stuff like Winamp).
Welcome to the club. So many things still don't support a dark theme either. Why aren't dark/light modes standard these days? Super annoying to have to hide a bunch of light mode windows when I'm in a meeting as they reflect brightly off my glasses.
That's because before Mac OS X theming was nearly free for apps, so long as they didn't override colors from the OS widgets.
Once Apple started dictating UI fashion you'll take it as is or inverted. If you have different needs then go pound sand. After a decade or so they suddenly discovered dark modes are a thing.
The move to the web also took some pressure off because you can override colors in your browser ... Unless you have a per-app browser locked inside Electron or similar.
If I recall, Podman really caught fire with this community after Docker started trying to charge more people for software. But then Red Hat (i.e. Podman's sponsor) started trying to charge more people for software too, and also became a pariah with this community. It's hard to keep up.
I used instead of Docker for a while because it came by default on RHEL (I'm using 8).
It has very impressive compatibility with Docker. For 99% of use cases you will not even know you are using Podman. The one case that forced me to uninstall it and use Docker was running `gitlab-runner`'s integration tests which do some funny things with Vagrant and VMWare, and Podman didn't like it. But overall I am very impressed with the compatibility.
There aren't really any advantages to using it for individual users. Being rootless is a huge upside on the server though. At my previous company I accidentally deleted all the containers running on a server because I naively assumed that Docker followed the normal permission model and would only let me delete my containers. Imagine my surprise when I learned that Docker basically runs as root and all users that have access to Docker have root access!
Of course I only made that mistake once, but still... Crazy design.
If you need to use buildx it is a slog to get right. The split between root and rootless is also wrought with forking guides and very confusing to triage. For example, rootless needs more care with capabilities.
Exactly. Red Hat is ending some things others never even considered to offer. Yet, people stand in line with... Oracle, WTF. FUD sadly works.
Especially while RH still making things accessible for people without money and testers, e.g. https://developers.redhat.com/articles/faqs-no-cost-red-hat-..., includes RHEL, Software Collections and Application Streams, Developer Toolset and Compilers, Red Hat Insights access (sic!).
podman and podman-compose became mainstream and replaced docker for me in "server" scenarios on rhel8/rhel9, fedora and derivatives. Glad to see progress on the desktop!
Podman Desktop is getting really good. But the only thing preventing me from using Podman right now is the fact that Docker has BuildKit, and BuildKit has some really nice features like Secret Mounts, Cache Mounts and SSH Mounts.
I've been using it since I migrated our container builds to buildah (docker-dind is spooky) and I needed something Docker-Desktopy without paying for a license. Works great. Even supports Docker Desktop plugins, which was a surprise.
If you're using Linux (especially with Gnome), I can highly recommend Pods[1] as a desktop client for Podman. It's much less cluttered than Podman Desktop, but still supports most of its features.
Can someone link me to what Compose means in this context? Google takes me to https://github.com/containers/podman-compose but I just wanna make sure that's what they are talking about.
You mean the time skew when you have your machine sleep (close the lid), right?
We have fixed this a while back; this was part of CRC almost 2 years back and we backported this to Podman Machine. If you still see this, let me know and I'll have someone look at this again.
I've seen this as recently as a few weeks ago on Podman 4.7.1 on a 2019 16" Intel MacBook Pro running Monterey 12.5.1, although I hadn't recreated my Podman machine VM in a few months so it may have been running an outdated image; certainly not a 2 year old one though. In my case it manifested as TLS failures due to an "expired" certificate.
Yeah it is still happening on fresh podman install as of a month or so. So many of my coworkers ran into the issue there is an internal wiki about it. The hwutil sync command thing works but it’s annoying.
It is a GUI for working with podman, docker, and kubernetes. It is functionally similar to Docker Desktop, which is also just a GUI to work with containers. It is a tool for those that prefer working with containers with a GUI instead of the terminal.
> It is a tool for those that prefer working with containers with a GUI instead of the terminal.
Sort of. In the case of podman desktop, that is true because you can opt to just install the cli podman if you prefer.
But in the world of Docker, they force end-users on Mac (and I think windows) to install docker through docker desktop even if you don't ever touch the GUI. I don't use the GUI ever, but can't find a way to install docker on Mac outside of the GUI. Maybe there's a way, but at least on Docker's website it seems to be the only way and at my company with ~100 devs no one else has figured it out either.
On windows I just use WSL2 with docker installed through the Linux distribution (Ubuntu in my case). This way I get docker on my windows Laptop without the annoying docker desktop
I wanted to build a Windows container image but I really did not want to install Docker Desktop. After some digging around I found my way to the Docker server / client binaries for Windows page that allowed me to do this: https://docs.docker.com/engine/install/binaries/#install-ser...
Did you follow a particular guide for how to do that?
I remember trying a while back, when WSL2 was first released, and I couldn't get it to work; IIRC I couldn't get stuff running in Windows to communicate with stuff running in containers in WSL2, and also vice-versa.
On WSL2, you just install Docker the same way as you would do on Linux. `sudo apt install docker.io` (from Debian/Ubuntu repo) or `curl https://get.docker.com | sh` (from Docker Inc). If you are using different WSL distribution, the standard way to install docker should work just fine. (e.g. `sudo pacman -S docker` works as expected on ArchWSL)
I agree. I do remember that in earlier versions WSL2 this approach didn't work, but currently it's the same as installing docker on a regular Linux distribution
> But in the world of Docker, they force end-users on Mac (and I think windows) to install docker through docker desktop even if you don't ever touch the GUI.
They try. But between homebrew and Colima you can get away with cli tools.
Well the most significant difference [on macOS or Windows] is you must use a VM (by default Podman Machine) so there can be a Linux kernel to run the containers.
This is a significant limitation that you do not have when running on Linux. As I recall there are some other (related?) features that are not implemented on the macOS.
[edited to reflect that I misread the parent and thought they were specifically asking what was different on non-Linux platforms)
Another Electron app that isn't visually integrated with Linux -- under GNOME/Wayland the app does not have native or at least native looking window buttons, it also has sharp edges without a shadow behind the window, as all other apps.
This is a surprise as Podman Desktop development is lead by RedHat, a company not only behind a Linux distro but one that leads the GNOME project.
> Plugins for Visual Studio Code or Eclipse would be nice
Can't you just use the docker plugins and configure the binary of the docker plugin and point it to the podman binary and it should work. Or just alias podman as docker
I also install the compose and ecr credentials plug-ins (since I use ecr for my container registry.) It has the full functionality of docker desktop minus the UI, which I never used anyways.
https://github.com/abiosoft/colima