[HN Gopher] How to Replace Docker with Podman on a Mac
___________________________________________________________________
How to Replace Docker with Podman on a Mac
Author : molecule
Score : 109 points
Date : 2021-09-08 20:18 UTC (2 hours ago)
(HTM) web link (www.redhat.com)
(TXT) w3m dump (www.redhat.com)
| tambourine_man wrote:
| 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.
| [deleted]
| leetrout wrote:
| Yes and its moving to HCL and Go
|
| https://www.hashicorp.com/blog/toward-vagrant-3-0
| williamsmj wrote:
| My understanding is that this old article is no longer the
| simplest/easiest way of doing this. For that, see
| https://marcusnoble.co.uk/2021-09-01-migrating-from-docker-t....
| tl;dr: $ brew install podman $ podman
| machine init $ podman machine start $ alias
| docker=podman
|
| 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).
| arthurcolle wrote:
| Does this work with compose? Probably not but just wondering
| Spivak wrote:
| podman-compose is a thing but it's not feature complete.
| jagger27 wrote:
| It more or less works, at least on Linux.
|
| https://www.redhat.com/sysadmin/podman-docker-compose
| jeffparsons wrote:
| 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.
| gjs278 wrote:
| hilarious. the article is already outdated. the truth is nobody
| should be using docker. the tools are fickle and nobody knows how
| they actually work. stick with VMs.
| lpasselin wrote:
| Now there is `podman machine` which makes most of this article
| outdated.
| conceptme wrote:
| It is mentioned in the article.
|
| "Fast forward a couple of months, podman-machine is now
| deprecated in lieu of Vagrant"
| lpasselin wrote:
| 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`.
| geerlingguy wrote:
| 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.
| inyorgroove wrote:
| I don't think this is correct. They are currently working
| on a go based replacement (3.0).
| roywashere wrote:
| Also vagrant by default depends on virtualbox, and that is
| x86-only so it does not work on your M1 Mac, or your
| Pinebook : )
| cpitman wrote:
| That's not accurate. There was an older project called
| podman-machine, which is long gone. What you get when you use
| the `podman machine` command is a completely new
| implementation.
| gizdan wrote:
| And it is built into the podman binary, as opposed to being
| a separate project.
| suchar wrote:
| 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).
| Spivak wrote:
| 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.
| gizdan wrote:
| 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.
| demarq wrote:
| 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
| tjscott wrote:
| 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
| mbell wrote:
| 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.
| [deleted]
| inyorgroove wrote:
| 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.
| filmgirlcw wrote:
| 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.
| easton wrote:
| 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.
| filmgirlcw wrote:
| That's actually a great idea!!
| while1fork wrote:
| I replaced docker desktop on my Mac with the CLI brew version and
| set DOCKER_HOST. This is because my 96-core, 0.5 TB RAM Linux
| server can run it just a wee bit faster than an old Mac mini.
| swlkr wrote:
| I tried podman on an intel mac and everything worked except
| mounting volumes
| jagger27 wrote:
| 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.
| haberman wrote:
| 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.
| throwaway234565 wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-08 23:00 UTC)