Podman support

[RHJasonSmith]

Re-evaluate supporting podman in light of the change in docker pricing model

Docker has changed its licensing recently, which is going to cause some (more) friction in the enterprise. In light of these changes, is there a list of hurdles to adopting podman/podman-compose that we can start working on to add support.

Steps to reproduce the issue:

1. alias podman to docker
2. alias podman-compose to docker-compose
3. fin up

Describe the results you received:

Varying failure states depending on platform

Describe the results you expected:

Invisible compatibility, the containers would just run.

[alexdmccabe]

I would also like to see support for this. I set up a fresh Fedora 34 install last week, and attempted to use podman with the podman-docker compatibility package. Docksal didn't work. I didn't keep the error messages, but I'll try to reproduce in a VM or something.

[lmakarov]

Docker Inc. changed licensing terms specifically for Docker Desktop and not the underlying container engine (which is open source and free).

Docksal still supports running docker in a VirtualBox VM mode on Mac and Windows using docker-machine and boot2docker. Unfortunately, both of those projects have been retired/abandoned by Docker Inc. in favor of... Docker Desktop.

What would be the alternative to Docker Desktop in the podman ecosystem?
Is there something like "podman-machine" (~ docker-machine) with a "boot2podman" (~ boot2docker) VirtualBox image?

[RHJasonSmith]

There is, though support across platforms is.... not great.

Up until fairly recently, and arguably still, podman's answer to a native mac client was a remote cli tool to a vm elsewhere. The mac support now works on intel machines if you don't need file sharing or bind mounts. If NFS can be magicified there, then that may be enough.

I've not worked with Windows, but understand that WSL support is decent.

You /can/ run podman within virtualbox/vagrant and remote it
https://www.redhat.com/sysadmin/replace-docker-podman-macos

[lmakarov]

Here's my take on docker vs podman (as a Docksal maintainer):

• podman looks to be a nice concept, but supporting it will very likely require efforts beyond just aliasing binaries. docksal/vhost-proxy, which relies on docker-gen to generate nginx config would be my biggest concern.
• Replacing docker with podman does not solve the Docker Desktop licensing dilemma.
• podman does not yet have the means to support/improve the local development experience (unless you work directly on Linux?). Not until there is tooling in place to provision podman VirtualBox VMs, similar to what docker-machine and boot2docker are/were for. For Windows users, supporting WSL 2 will be a universal solution (regardless of docker vs podman).
• Docker Desktop is the most streamlined and supported (by someone else) experience for Mac and Windows users today.
• Docker Desktop is free for the majority of users. Those not eligible can afford paying for a license (large companies). To be frank, I find Docker's licensing requirements reasonable, even though my own company would need to license Docker Desktop come 2022.
• Let's assume podman comes with a solution for local dev environments on par with what docker offers today. Even then, supporting two container runtimes along with the variety of operating systems (Linux flavors, Mac, Windows WSL1/WSL2) and methods to run Docker locally on them (Docker Desktop vs Virtualbox) will only make it even more difficult to develop, test, and provide support for Docksal users. We'd need to pick one of the other at that point.

TL;DR: What would podman support in Docksal really help with (and whom)?

@RHJasonSmith if the team at RedHat is interested in contributing towards adding AND maintaining podman support in Docksal, I'm open to discussing what that could look like. The contact email is in the head of the Docksal GitHub org :)

[lmakarov]

This better suits in Discussions. Moving.

[SiliconValet]

We're doing some internal discussion here to figure out our best course of action. Personally, I think we may dabble with minikube as a replacement for docker desktop, and that may provide some better integration with how deployments work once they leave the local environment. It also has features that provide a decent parity with Docker Desktop and can provide the abstraction between the container technology and the tooling so that you don't have to revisit this question.

We're

[lmakarov]

I was also looking at minikube as a possible replacement for Docker Desktop / docker-machine + boot2docker.
It ships with both docker and podman runtimes, which would make switching as well as maintenance much simpler.

I have not yet found a way to launch a minikube instance with 0 cluster nodes (so runtime-only without the gigantic K8s overhead).
Doing minikube pause is the only option I found and it is still ugly - all K8s system containers are still technically running and show up in docker ps output. There will likely be other issues with it.

Anyway, let me know if you'd want to organize a brainstorming session. I'll be happy to participate.

BTW there is a more generic discussion about Docksal relying on Docker Desktop happening over here:
#1567