How to Replace Docker with Podman on a Mac(redhat.com)
redhat.com
How to Replace Docker with Podman on a Mac
https://www.redhat.com/sysadmin/replace-docker-podman-macos
89 comments
Does this actually work for you? I tried it and networking was broken out of the box – it couldn’t even pull a container image. I didn’t have time to spend digging into it, however, and would not rule out that being an artifact of our VPN.
Networking is working just fine over here; I rebuilt the machine to be using the latest (Sept 4) FCOS stream, but it was fine on the previous version (Aug 21) as well.
Are you using short names to pull your images, i.e. 'requarks/wiki:latest' rather than the full path 'docker.io/requarks/wiki:latest'? (Note: official images in Docker Hub are under the 'library/' namespace, e.g. 'library/fedora')
Other networking issues, like the port publishing through the host bridging by default without needing to pass '--network' I believe are slated for the upcoming 3.3.2 patch release.
Are you using short names to pull your images, i.e. 'requarks/wiki:latest' rather than the full path 'docker.io/requarks/wiki:latest'? (Note: official images in Docker Hub are under the 'library/' namespace, e.g. 'library/fedora')
Other networking issues, like the port publishing through the host bridging by default without needing to pass '--network' I believe are slated for the upcoming 3.3.2 patch release.
One issue still apparently is that it can’t mount volumes. Though I haven’t had to do that yet. When you attempt to mount a volume it will attempt to do it from within the virtual machine not your machine.
The issue to watch is here: https://github.com/containers/podman/issues/8016
To be clear volumes are supported, what aren't are "bind mounts" which are not recommended over named volumes: https://docs.docker.com/storage/volumes/ https://docs.docker.com/storage/bind-mounts/
To be clear volumes are supported, what aren't are "bind mounts" which are not recommended over named volumes: https://docs.docker.com/storage/volumes/ https://docs.docker.com/storage/bind-mounts/
This is a known issue and is in the process of being figure out how to proceed: https://github.com/containers/podman/issues/8016
Good to know - I’ll give it another run when I have more time later this week.
If this is using the macOS native virtualization, then, yes, networking will be broken while a vpn is active.
This is a known issue that also was present in the Docker for Apple Silicon public preview where they eventually fixed it by dropping built-in virtualization for qemu
This is a known issue that also was present in the Docker for Apple Silicon public preview where they eventually fixed it by dropping built-in virtualization for qemu
I think also this podman blog post from a few days ago is relevant: https://podman.io/blogs/2021/09/06/podman-on-macs.html
That tl;dr worked great.
I'll have to see if there's a Nix package for it tomorrow morning for work.
I'll have to see if there's a Nix package for it tomorrow morning for work.
Does this work with compose? Probably not but just wondering
The problem with making this work, IIRC, is that Docker Compose doesn't actually "compose" Docker commands, but instead _re-implements_ a bunch of functionality itself through its Python libraries. So you'd actually need to bring your own CLI-compatible Docker Compose implementation for Podman rather than just making your Docker replacement compatible.
Podman solved this by just re-implementing docker’s socket API (which does mean it now requires a daemon to use compose) https://www.redhat.com/sysadmin/podman-docker-compose
In addition to the sibling comment (which mentions that you can use the original docker-compose) such a CLI-compatible reimplementation also exists [0]. It's not always a 100% drop-in replacement, but gets you pretty far in my experience.
[0] https://github.com/containers/podman-compose
[0] https://github.com/containers/podman-compose
Anecdotally I can say that I ran into issues with fairly simple files (2 years ago). I’m going to try out the alternatives before coming back to this.
It more or less works, at least on Linux.
https://www.redhat.com/sysadmin/podman-docker-compose
https://www.redhat.com/sysadmin/podman-docker-compose
podman-compose is a thing but it’s not feature complete.
Is there any practical benefit of Podman over Docker on a Mac? Virtual machine is still needed, so any performance issues are likely to persist (well, maybe Docker for Mac is a bit more buggy, but we can manually setup Docker instead of Podman in a similar way).
Also, I think we are losing here access to the Docker socket on the host (inside the virtual machine it can be emulated using docker-podman).
Also, I think we are losing here access to the Docker socket on the host (inside the virtual machine it can be emulated using docker-podman).
Podman does have a socket that can be started. I use it on Linux so I'm not sure how that works on MacOS but it's API is Docker compatible, thus works with the docker cli and docker-compose as well.
IIRC the podman socket is a planned thing for macOS as it'll be necessary for certain features that rely on the docker socket and don't use SSH, such as VSCode's Remote Containers extension.
However you can create an SSH tunnel to create the socket locally to allow non-podman clients to utilize the socket over SSH with the DOCKER_HOST environment variable.
https://github.com/containers/podman/issues/11397
However you can create an SSH tunnel to create the socket locally to allow non-podman clients to utilize the socket over SSH with the DOCKER_HOST environment variable.
# Get URI
> podman system connection ls
# Create tunnel
> ssh -nNT -L/tmp/podman.sock:/run/user/1000/podman/podman.sock -i ~/.ssh/podman-machine-default ssh://core@localhost:[PORT]
# Export socket location
> export DOCKER_HOST='/tmp/podman.sock'
https://github.com/containers/podman/issues/11397
Socket location is wrong. Use this:
export DOCKER_HOST='unix:///tmp/podman.sock'
The podman socket can be used to connect stuff to podman.
For example, a GUI program or even docker-compose.
However I must admit that I'm having serious troubles with podman+docker-compose (rhel 8.4, podman 3.2.3) so I reverted to podman-compose (which is way lower in quality and completeness).
For example, a GUI program or even docker-compose.
However I must admit that I'm having serious troubles with podman+docker-compose (rhel 8.4, podman 3.2.3) so I reverted to podman-compose (which is way lower in quality and completeness).
Not having to pay Docker Inc to use it is the big advantage along with the security that comes with a solution that isn’t the meal ticket of the company that makes it so it will likely live on community supported for a long time.
> Not having to pay Docker Inc to use it is the big advantage
It’s mind boggling to me how much HN refuses to pay (only for company licensing) for the innovation that is Docker, and would rather find alternatives to the tooling around it.
> solution that isn’t the meal ticket of the company
Usually I’ve seen arguments the other way around - X will do a good job /because/ it’s their core offering.
It’s mind boggling to me how much HN refuses to pay (only for company licensing) for the innovation that is Docker, and would rather find alternatives to the tooling around it.
> solution that isn’t the meal ticket of the company
Usually I’ve seen arguments the other way around - X will do a good job /because/ it’s their core offering.
When software companies switch to subscription-only models (see 1Password) you better not be invested in the software too much or you'll be at their price gouging mercy.
I'll happily pay for software but I won't support subscription-based models, ever.
I'll happily pay for software but I won't support subscription-based models, ever.
You’re conflating consumer and corporate purchasing. By and far, companies prefer subscription based pricing that comes with ongoing support. Consumers also want support and updates, but have an irrational desire to not pay the company/people that provide it…
What is podman’s revenue model?
I am perplexed by the conclusion that charging enterprise customers $5/user-month makes the product’s future less secure.
I am perplexed by the conclusion that charging enterprise customers $5/user-month makes the product’s future less secure.
podman has no revenue model, it is an open source project managed by https://github.com/containers
So without a revenue model, how would they pay someone to maintain it if the current maintainer[s] need to focus on family or paying their mortgage?
It's from RedHat/IBM. They can give this stuff away to developers because they just want to sell OpenShift to deep pocketed Enterprise customers. And really podman is strategically a defensive move so their Enterprise offerings aren't stuck depending on Docker Inc.
Contrast with Docker, whose business is explicitly focused on "developer tools."
Contrast with Docker, whose business is explicitly focused on "developer tools."
So podman is funded ultimately by enterprises which is OK, but now docker wants to fund their products by enterprises that's a problem for some reason...
I could understand this if they were turning the thumbscrews on individuals but all this talk of switching sounds petty and silly and will probably be false economy
I could understand this if they were turning the thumbscrews on individuals but all this talk of switching sounds petty and silly and will probably be false economy
I suspect it's the bait-and-switch approach that annoys people. Podman (and RHEL, through community rebuilds) is free to use even for enterprises; you don't pay for the software itself, you pay for support.
The problem is that red hat wants to monetize on "the big stuff" that is enterprise level software with support, subscription and consulting.
Docker Inc wants to monetize on the basic stuff (e.g. a dumb desktop UI)
Docker Inc wants to monetize on the basic stuff (e.g. a dumb desktop UI)
Exactly, and lots of developers don't need a desktop UI. They just want something that sits in the background and gets out of their way.
Yep.
That's why docker inc is mostly failing and has to come up with this dumb stuff whereas red hat is thriving :)
That's why docker inc is mostly failing and has to come up with this dumb stuff whereas red hat is thriving :)
There was already some bad feeling towards Docker, because they historically haven't fixed bugs or added requested features.
When Docker started asking for money for their desktop offering, it prompted people to start wondering just how valuable that offering was, and to compare it against competing applications. Also, a lot of developers I've spoken to just don't see the point of the Docker Desktop on Mac; they just want something that sits in the background and works without bugging them to update every other week.
Podman fits the use cases people have, it's open source and has more useful features than Docker Desktop currently has.
You're correct in that this sounds petty and silly, but there's history and context to this widespread move to ditch Docker.
When Docker started asking for money for their desktop offering, it prompted people to start wondering just how valuable that offering was, and to compare it against competing applications. Also, a lot of developers I've spoken to just don't see the point of the Docker Desktop on Mac; they just want something that sits in the background and works without bugging them to update every other week.
Podman fits the use cases people have, it's open source and has more useful features than Docker Desktop currently has.
You're correct in that this sounds petty and silly, but there's history and context to this widespread move to ditch Docker.
> I could understand this if they were turning the thumbscrews on individuals but all this talk of switching sounds petty and silly and will probably be false economy
Well, with respect to this post in particular, I don't think Podman is even a "real" replacement for Docker Desktop. RHAT has been pushing it for quite a while, and although they're dogfooding it with their own k8s and Linux distros it's had less uptake outside of Big Blue (the linked article, prominently featured on their web page, is already out of date - not a good look). As many rough edges as my Mac using colleagues described encountering with Docker Desktop, they will see even more if they try to use Podman, so it strikes me as a poor choice here.
Regardless, I think the value proposition of Docker Desktop is questionable. The main thing it does is manage some VM plumbing so you don't have to think about it. Is that worth... much? Even anything at all? In a past life many of us used Vagrant, and it's not like it's that hard to do this stuff yourself.
So really, Docker Desktop is competing on multiple fronts, all of which are open source or at least free. There's old school, with Vagrant/BYO VM, there's "docker alternatives" like podman, and there's the k8s-in-a-box like Rancher Desktop or Minikube (which can expose a docker socket so you can work with docker directly as well).
I'm a Linux user so I don't have a dog in this fight, but if I lived in a world where I needed "run a VM to get a docker for development" it's not obvious to me that Docker Desktop is the best choice at any price point, and the cost is just one more point against it.
Well, with respect to this post in particular, I don't think Podman is even a "real" replacement for Docker Desktop. RHAT has been pushing it for quite a while, and although they're dogfooding it with their own k8s and Linux distros it's had less uptake outside of Big Blue (the linked article, prominently featured on their web page, is already out of date - not a good look). As many rough edges as my Mac using colleagues described encountering with Docker Desktop, they will see even more if they try to use Podman, so it strikes me as a poor choice here.
Regardless, I think the value proposition of Docker Desktop is questionable. The main thing it does is manage some VM plumbing so you don't have to think about it. Is that worth... much? Even anything at all? In a past life many of us used Vagrant, and it's not like it's that hard to do this stuff yourself.
So really, Docker Desktop is competing on multiple fronts, all of which are open source or at least free. There's old school, with Vagrant/BYO VM, there's "docker alternatives" like podman, and there's the k8s-in-a-box like Rancher Desktop or Minikube (which can expose a docker socket so you can work with docker directly as well).
I'm a Linux user so I don't have a dog in this fight, but if I lived in a world where I needed "run a VM to get a docker for development" it's not obvious to me that Docker Desktop is the best choice at any price point, and the cost is just one more point against it.
When I last looked into it, I came away with the feeling that github.com/containers is pretty much RedHat without any official backing.
That’s how Red Hat operates mostly. Time will tell if IBM royally messes this up but Red Hat is an upstream first company. If they need something they will put up the developer time but it will be a community project first that they repackage for RHEL.
Red Hat’s secret sauce so to speak is the stupid amount of ongoing work it takes to actually maintain a distro, not the software itself.
Red Hat’s secret sauce so to speak is the stupid amount of ongoing work it takes to actually maintain a distro, not the software itself.
> Red Hat is an upstream first company
So is IBM from what I've seen.
IBM + RedHat have more contributors working on OSS than Google, surprisingly.
So is IBM from what I've seen.
IBM + RedHat have more contributors working on OSS than Google, surprisingly.
Because the future of the product now depends on the enterprise customers paying enough for it to not only fund the development but also fund the business backing it.
OSS works best when software is needed by many different enterprises that all need it for their business but it isn’t a direct revenue generator. Because then the future is guaranteed since all of those enterprises will contribute patches and it makes financial sense for any of them to take on the maintainership.
Docker Desktop has always been a single point of failure in development terms not being OSS, but the community of users just got slashed not that there’s a price tag attached to it and by charging Docker has basically said that the future of the product now depends on it turning a profit instead of before when it only depended on Docker Inc overall turning a profit.
OSS works best when software is needed by many different enterprises that all need it for their business but it isn’t a direct revenue generator. Because then the future is guaranteed since all of those enterprises will contribute patches and it makes financial sense for any of them to take on the maintainership.
Docker Desktop has always been a single point of failure in development terms not being OSS, but the community of users just got slashed not that there’s a price tag attached to it and by charging Docker has basically said that the future of the product now depends on it turning a profit instead of before when it only depended on Docker Inc overall turning a profit.
No idea how you came to that conclusion. Do you really think they'll survive without a way of using docker on Macs ? This is an extra revenue stream
As a typical mac user there is no practical benefit.
Being on a Mac is so you can avoid lengthy configurations, scripts and commands and instead have something that just works and is seamlessly integrated.
This is the opposite.
You’d probably only want to go this route to make a statement about free open source software. But at that point you may as well run Linux
Being on a Mac is so you can avoid lengthy configurations, scripts and commands and instead have something that just works and is seamlessly integrated.
This is the opposite.
You’d probably only want to go this route to make a statement about free open source software. But at that point you may as well run Linux
The Docker daemon (likely the HyperKit VM) on the Mac has a tendency to burn CPU cycles, even when there are no containers running. It's pretty common for it to sit at 10-20% of a core all day, and sometimes gets pegged at 100% until you quit.
There are countless closed issues in the GitHub issue tracker [1] for similar issues, but the symptoms don't seem to go away for me or many of my colleagues.
It's been a pretty awful experience on Mac for a long time, so any competition is surely welcome.
[1] https://github.com/docker/for-mac/issues/3499
There are countless closed issues in the GitHub issue tracker [1] for similar issues, but the symptoms don't seem to go away for me or many of my colleagues.
It's been a pretty awful experience on Mac for a long time, so any competition is surely welcome.
[1] https://github.com/docker/for-mac/issues/3499
I had the same frustrations until the other day I saw a tip to enable 'Use the new Virtualization framework' under Preferences -> Experimental Features. Since then Docker's background CPU usage has dropped to 1% and I no longer bother stopping it when I'm not using it.
My hopes for this were high, but it just makes my containers crash (until then networking works and it may be faster) on M1/Monterey.
That’s probably why it’s still marked experimental! Works well for me on an M1 Mac running Debian/Ubuntu Arm containers.
Wow, Mac users put up with some bullshit to avoid configuration and have things "just [sometimes, unless you're holding it wrong] work"
I'm happy your platform of choice has no bugs nor quirks. Could you let us know which one it is? We can probably help you find the bullshit you put up with that has become second nature.
This feels like the whole industry is now all going through the same motions…
I tried podman; two hurdles I haven't figured out: 1/ sending the context is incredibly slow on podman, compared to Docker+Buildkit. It's definitely trying to send literally the entire context, like Docker without Buildkit does, but even more slowly… 2/ private registry auth. Haven't really tried too hard, but it's not just "a drop in replacement"; I think I need to somehow auth with podman specifically. (Part of this is our external registry is ACR, and we auth with `az`, but I think `az` is presuming Docker…)
I tried podman; two hurdles I haven't figured out: 1/ sending the context is incredibly slow on podman, compared to Docker+Buildkit. It's definitely trying to send literally the entire context, like Docker without Buildkit does, but even more slowly… 2/ private registry auth. Haven't really tried too hard, but it's not just "a drop in replacement"; I think I need to somehow auth with podman specifically. (Part of this is our external registry is ACR, and we auth with `az`, but I think `az` is presuming Docker…)
You can use `az acr login --name <acrName> --expose-token` to get the token and pass it to the pod man login.
Now there is `podman machine` which makes most of this article outdated.
It is mentioned in the article.
"Fast forward a couple of months, podman-machine is now deprecated in lieu of Vagrant"
"Fast forward a couple of months, podman-machine is now deprecated in lieu of Vagrant"
I assume `podman-machine` is different than `podman machine`
See Marcos install https://podman.io/getting-started/installation
Also there are active issues and PR related to `podman machine`.
See Marcos install https://podman.io/getting-started/installation
Also there are active issues and PR related to `podman machine`.
Yes, Red Hat reused the name - similar to the CoreOS name.
See https://boot2podman.github.io/2020/07/05/boot2docker-depreca... for the reasons why Vagrant was/is a workaround, after docker-machine and podman-machine stopped working.
So is a Vagrant-based alternative the current solution? Vagrant seems like it's long been a 'maintenance only' project for Hashicorp, though not abandoned at least.
Vagrant was a workaround, before the new project got off the ground: https://boot2podman.github.io/2020/07/22/machine-replacement...
Any virtualization solution could be used, with some more typing (like running the shell commands directly). It's not unique to Vagrant.
Any virtualization solution could be used, with some more typing (like running the shell commands directly). It's not unique to Vagrant.
Lima is a new and better option for this, it does not use a bundled Ruby runtime and does not use anything from Oracle. Just Go and QEMU... See https://github.com/lima-vm/lima
Also vagrant by default depends on virtualbox, and that is x86-only so it does not work on your M1 Mac, or your Pinebook : )
I believe there are hypervisor.framework backends for vagrant, but it seems that for whatever reason they haven’t taken off? I’m not exactly sure why they haven’t become the default on Mac, given how much more efficient it presumably is.
I don't think this is correct. They are currently working on a go based replacement (3.0).
While there do exist several alternatives to Docker Desktop, I am a fan of multipass. Something I don't see anyone talking about, the host to guest volume mounting performance can't be beat. The alternatives can't hold a candle to Docker Desktop's solution.
I need this volume mounting to get development code changes into the container in a reasonable time and the alternative performance feels like running on a standard hard drive compared to nvme ssd.
I need this volume mounting to get development code changes into the container in a reasonable time and the alternative performance feels like running on a standard hard drive compared to nvme ssd.
I like Multipass a ton, but as with almost every Docker/VM/Linux config right now, support on the M1 Mac is mixed. (Yes, yes, I know Docker Desktop works on the M1 now. But not all container images do, some run emulated, some break, there are still lots of papercuts.) I’ve had some success with the most recent builds of Multipass, but it isn’t reliable.
For devs who still have access to an Intel Mac, I personally would still use that over an M1 for container/VM/Linux tasks. We’re only a year into the transition so that’s OK, but don’t be caught off guard if you move to an M1 and find your stuff breaking. Incidentally, this is where I find stuff like GitHub Codespaces really nice because I can offload the container bits to a different machine.
For devs who still have access to an Intel Mac, I personally would still use that over an M1 for container/VM/Linux tasks. We’re only a year into the transition so that’s OK, but don’t be caught off guard if you move to an M1 and find your stuff breaking. Incidentally, this is where I find stuff like GitHub Codespaces really nice because I can offload the container bits to a different machine.
That might be a fun project if Hacktoberfest comes back this year, get open source projects building images for arm64. A lot of times it’s easy to do.
That’s actually a great idea!!
Is it possible to setup a mount from within a cloud init?
Yes, I've got the mount with multipass working no problem. That isn't the issue, the issue is it takes a ruby app 5x longer to boot using the sshfs based mounting vs the gRPC FUSE system Docker bundles with Docker Desktop.
Is Vagrant still actively used? I was all over it some 4-5 years ago.
I remember HashiCorp even favoring a newer product they were trying to promote.
I remember HashiCorp even favoring a newer product they were trying to promote.
Yes and its moving to HCL and Go
https://www.hashicorp.com/blog/toward-vagrant-3-0
https://www.hashicorp.com/blog/toward-vagrant-3-0
[deleted]
How does this compare to multipass? I tried multipass out on an Intel Mac yesterday and it worked great until I connected to corporate vpn (anyconnect) and then it all went downhill. Tried some of the workarounds (https://multipass.run/docs/troubleshooting-networking-on-mac...) but no luck. Back to Docker Desktop.
Is there is a solution for using `docker-compose` on mac with podman? I know that podman supports it natively now, and there is `podman-compose`, but I couldn’t find much on getting either working on a mac due to the remote setup.
I tried podman on an intel mac and everything worked except mounting volumes
Volumes are one of those things that Just Don't Work, even in normal Docker. Our product's dev containers run fine in Docker on macOS on M1 but the filesystem permissions get messed up when running the same ones on Linux. It's just a silly root:root permissions issue, but it's irritating the problem was hidden when running on a Mac.
I've run into this too. My solution was to add some code in entrypoint.sh that looks for the UID/GID of mounted files, then creates a group and user to match. We can then exec the real command as that user.
There is some support for id mapping in the 5.12 kernel that we may be able to take advantage of for this case.
Will have to take a look at how to deal with this for things like volumes.
https://man7.org/linux/man-pages/man2/mount_setattr.2.html#N...
https://man7.org/linux/man-pages/man2/mount_setattr.2.html#N...
Does Podman do a better job avoiding bloat in the development workflow? That’s been a major thing with docker for me, it spins up a new layer whenever I try to do send an arbitrary command to a running vm, which with development (PHP) I find this is something I have to do often, so these layers add up quickly
I tried podman on my MBP and didn't get very far :/ https://github.com/containers/podman/issues/11479
See https://news.ycombinator.com/item?id=28379556 for a recent discussion about minikube (the only drop-in replacement for Docker Desktop).
We replaced Docker hub with ghcr + buildah action and we won't ever look back! We are just waiting for more compose support which seems that will happen shortly anyway.
Thanks redhat!
Thanks redhat!
[deleted]
best thing about podman is the -l option, that refers to last image used
for example to see the last conatainer's logs:
podman logs -l
just beautiful!
for example to see the last conatainer's logs:
podman logs -l
just beautiful!
If you're on an M1 you may run into https://github.com/containers/podman/issues/10577 (which is WIP, and may have been resolved by https://github.com/containers/podman/pull/11451).