How to replace Docker with Podman on a Mac, revisited
Back in March 2021, I wrote about how I replaced Docker with Podman on a Mac using VirtualBox and Vagrant after an old version of podman machine became deprecated. That very same month, a new version of podman machine
was released, which pretty much rendered my article obsolete and caused a bit of confusion.
Using the podman machine
command's functionality is so much easier now, as Brent Baude explains in How Podman runs on Macs and other container FAQs. As I was moving from my VirtualBox/Vagrant setup, I wanted to revisit this topic in case your design is similar to mine. Here are some tips I found when moving over to podman machine
; hopefully, by sharing them I will help some folks out!
From Vagrant to podman machine
I am going to assume you installed podman using Homebrew. The first thing to do is to get the latest version of Podman by running:
$ brew upgrade podman
If you are anything like me and want results fast, go ahead and run these commands after the upgrade:
$ podman machine init
$ podman machine start
When I ran this, the init
command worked like a charm, but the start
command wasn't happy and told me so:
Error: unable to start host networking: "could not find \"gvproxy\" in one of [/usr/local/opt/podman/libexec /opt/homebrew/bin /opt/homebrew/opt/podman/libexec /usr/local/bin /usr/local/libexec/podman /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman]"
After a couple of internet searches, I found a recommendation to add the following line to the ~/.config/containers/containers.conf
file:
helper_binaries_dir=["/usr/local/Cellar/podman/3.4.1/bin","/usr/local/Cellar/podman/3.4.1/libexec"]
NOTE: This is a fairly recent issue, and it may be resolved in newer Podman releases. As you can see, I'm using 3.4.1. This version definitely solved the gvproxy
error, but here's where my Vagrant setup tripped me up. I reran the podman machine start
command, but it still was not happy, saying it was unable to connect due to a failed sshClient
error. I decided to look at my old Vagrant connection by running:
$ podman system connection list
I noticed the Vagrant connection still existed as the default connection. I quickly changed the default and removed the Vagrant connection, but I still got the same error. So, I ran the following command to get more debug information:
$ podman --log-level=debug ps
INFO[0000] podman filtering at log level debug
DEBU[0000] Called ps.PersistentPreRunE(podman --log-level=debug ps)
DEBU[0000] SSH Ident Key "/Users/dmeurer/Dev/images/podman/.vagrant/machines/default/virtualbox/private_key" SHA256:EhLJssA0acBO7LQVx8UrHzQPeVXB2gwn+a+wXdOaCKY ssh-rsa
DEBU[0000] Found SSH_AUTH_SOCK "/private/tmp/com.apple.launchd.b6hyl78H5X/Listeners", ssh-agent signer(s) enabled
Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM
Error: unable to connect to Podman. failed to create sshClient: Connection to bastion host (ssh://vagrant@127.0.0.1:2222/run/podman/podman.sock) failed.: dial tcp 127.0.0.1:2222: connect: connection refused
Since I can't remember what I had for breakfast today, let alone something I did months ago, I went back to my previous article to see if anything I did might force Podman to use that Vagrant private key. Well, sure enough, there it was in step 6! Global variables were still telling Podman to use the Vagrant SSH key setup. All I needed to do was to nuke the CONTAINER_HOST and CONTAINER_SSHKEY lines from my ~/.zshrc
file, and podman machine start
worked as advertised.
Make it a macOS app
Now that podman machine
was working great on my Mac, I wanted to be sure the Seals macOS app I used in the previous article worked. In that article, I created a Bash shell script called pman
to start and stop my VirtualBox and Vagrant setup quickly, and I created an application named Seals to make the script easier to run. The new pman
script needed a couple of tweaks to use podman machine
:
#!/bin/bash
ACTION=$1
case $ACTION in
"down")
echo "Shutting down podman machine"
podman machine stop
;;
"up")
echo "STARTING podman machine"
podman machine start
;;
"init")
echo "CREATING a new podman machine"
podman machine init
;;
esac
I then tried my Seals macOS app, and I got an interesting podman not found
error. So, I opened up Automator on my Mac, chose Open an Existing Document..., and opened up the Seals app.
[ Learn more about the Red Hat OpenShift Container Platform. ]
You may not need to do this depending upon where your Podman executable is located. I created a Podman symlink in a local bin directory, so I had to play around with the first export line to ensure it found my Podman executable.
You'll need to update the paths in the screenshot above to where you saved and named the Bash script. Once I got the path right, my Seals app worked great.
In case you are wondering how I attached the Podman logo to my macOS app, here is the process. I found the Podman logo and created a 128x128 PNG image with GIMP to use as the Application icon with these steps:
- Open the 128x128 PNG in preview and click Edit > Copy.
- Right-click the new application, and click Get Info.
- Select the icon on the top left, and paste the contents of the clipboard.
Now you can use Alfred or Spotlight to quickly launch Podman and free up precious milliseconds of your workday to focus on the things that matter… like an early lunch!
Summary
I hope this will help those folks who are either looking for an easy way to launch Podman on macOS or are using a Vagrant setup similar to the one I documented. The main reason I revisited this topic was that Podman updates made my previous article obsolete, and it is so much easier now to use Podman on a macOS because of podman machine. You no longer need VirtualBox and Vagrant, just Podman! Happy containerizing!!
![Rootless containers using podman](/sysadmin/sites/default/files/styles/card/public/2020-08/grafitti-4719165_1920%20Cropped.jpg?itok=PHq9ORWV)
![Train moving fast down a track with containers](/sysadmin/sites/default/files/styles/card/public/2021-11/train-container-fast.jpg?itok=Sf_sPJXR)
![Author’s photo](/sysadmin/sites/default/files/styles/user_picture_square/public/pictures/2021-02/dave-headshot-2020.png?itok=lDV6tNQE)
Dave Meurer
Dave Meurer currently serves as a Principal Solution Architect on the Red Hat Global Partner Security ISV team, where he owns technical relationships and evangelism with security independent software vendor partners of Red Hat. More about me