Ddev: Support podman as a docker alternative

Created on 22 May 2020  路  15Comments  路  Source: drud/ddev

Is your feature request related to a problem? Please describe.
For users in the RedHat family, ie. CentOS, Fedora, podman and cgroups v2 is the default and offers
other benefits that docker doesn't.

Describe the solution you'd like
I'd like to use ddev without needing to install docker.

Describe alternatives you've considered
None.

I realize docker-compose is the likely the trickiest part. One thing of note, podman doesn't run as root at all so you'd likely gain some more security.

All 15 comments

You'll still have to install docker-compose; ddev is a wrapper on docker-compose. And if you have to install docker-compose... Why not just install docker?

Why not just install docker?

Because Docker isn't the only container game in town any longer and podman will soon support compatibility with a docker-compose style syntax.

I dont think its possible to use ddev without Docker. Because DDEV is based on Docker. I think, you would need to recreate DDEV from the beginning, to make it running without Docker.

What are the reasons, why you didnt like docker?.

And here you have the install steps for installing docker-compose on linux:
https://docs.docker.com/compose/install/

It should be work on all Linux Distributions.

I dont think its possible to use ddev without Docker. Because DDEV is based on Docker. I think, you would need to recreate DDEV from the beginning, to make it running without Docker.

What are the reasons, why you didnt like docker?.

And here you have the install steps for installing docker-compose on linux:
https://docs.docker.com/compose/install/

It should be work on all Linux Distributions.

There are a few advantages podman has over Docker like supporting cgroups v2 (which Fedora for instance has installed by default), not relying on a daemon and being able to run containers without root.

You can generally go quite far with most Docker based scripts/tools by using:

$ alias docker=podman
# https://github.com/containers/podman-compose
$ alias docker-compose=podman-compose

Since this seemed kind of interesting, I played around a bit with the idea...

By enabling podmans API via:

$ podman system service --timeout 5000

and creating a link for the docker.sock

$ ln -s /$XDG_RUNTIME_DIR/podman/podman.sock /var/run/docker.sock

I got ddev to acknowledge it as Docker, sadly it will complain about the version by this point:

$ ddev start
The docker version currently installed does not meet ddev's requirements: 1.8.2 is less than 18.06.1-alpha1 

This might be worthwhile to look into further and possibly provide a "podman mode" :).

@atomicptr since you know how to build... just change the version requirements in pkg/version/version.go and experiment a little more. It would sure be interesting to know nore.

I'll play around a bit more in depth with this later :).

So... after changing the version requirements and actually creating a link for docker-compose (ddev doesn't seem to be happy with my alias)

$ ln -s /usr/bin/podman-compose /usr/bin/docker-compose

I ran into the next issue,

$ ./ddev-local-build start
2020/05/28 14:54:54 Failed to ensure docker network ddev_default: API error (404): Not Found

The podman API is still experimental and it seems like they haven't added support for networks yet (at least support for the Docker endpoint)

e.g. with podman I get this:

$ curl -s --unix-socket /$XDG_RUNTIME_DIR/podman/podman.sock http://localhost/networks
Not Found

On Docker it does work as expected:

```bash
$ curl -s --unix-socket /var/run/docker.sock http://localhost/networks
[{"Name":"host","Id":"........
````

For pretending that podman = docker this is probably as far as we can go right now, there are other API implementations for podman and there is the official API through libpod https://github.com/containers/libpod

Happy to see experimentation with this in the future. I'm going to close this for now. Thanks for taking the time with it @atomicptr

Thanks for looking at this. As an aside, ddev is the only reason I still have docker installed. Podman does everything else without running as root and daemonless. If I could completely remove docker from my workflow, it would be great.

BTW, docker now has a rootless install; I haven't experimented with it with ddev. https://docs.docker.com/engine/security/rootless/

I came as far as @atomicptr (replacing docker with podman and ignoring ddev's version constraint)
but now with this error:

$ ddev start
Failed to ensure docker network ddev_default: API error (500): {"cause":"open /etc/cni/net.d/ddev_default.conflist: permission denied","message":"open /etc/cni/net.d/ddev_default.conflist: permission denied","response":500}
{"CheckDuplicate":false,"Driver":"bridge","Scope":"","EnableIPv6":false,"IPAM":null,"Internal":false,"Attachable":false,"Ingress":false,"ConfigOnly":false,"ConfigFrom":null,"Options":null,"Labels":null}

I hope there is some interest in a working rootless-mode (e.g. with podman) :+1:

A much more likely and maintainable approach for rootless would be https://docs.docker.com/engine/security/rootless/ I think.

That can work for now. Thank you :+1:
But I'm getting this error at the very beginning:

$ ddev start
Starting my-project... 
get ddevsshagent_dot_ssh: error listing plugins: legacy plugin: error reading dir entries: open /etc/docker/plugins: permission denied 
Failed to start my-project: failed to start ddev-ssh-agent: Failed to run docker-compose [-f /home/me/.ddev/ssh-auth-compose.yaml -p ddev-ssh-agent up --build --force-recreate -d], err='exit status 1', stdout='', stderr='get ddevsshagent_dot_ssh: error listing plugins: legacy plugin: error reading dir entries: open /etc/docker/plugins: permission denied'

For Fedora 31+ it also means to returning back to cgroups v1.
I recommend this article to read more about cgroups. ;)

IIRC Fedora 31+ has some trouble with docker. I don't think it has anything to do with your rootless approach.

I also haven't ever tried the rootless approach I linked, but I imagine it can be done with some help. podman, on the other hand, seems like a very, very difficult reach to support.

@rfay You seem pretty against this. My only offer of advice is that docker isn't the only game in town any longer, and they're way smaller than Red Hat, which is the company behind podman. A lot of government and enterprise happens to be really partial to Red Hat.
Like @FireLizard said, cgroups v2 is also another reason.

It's not that I'm against it. It's that ddev is a multiplatform project that works the same on Linux, Windows, and macOS, and has a single maintainer. Supporting every possible permutation of platforms just isn't possible. Podman is linux only, and really doesn't seem to extend much outside the RedHat ecosystem as far as I know (which isn't much). And it also doesn't have a goal of docker compatibility as far as I know. So if there were loads of users clamoring for podman, and the single maintainer weren't already fully occupied, maybe if there was a huge team developing ddev, maybe that would be different. But it's important to keep things at a scale that they can be maintained.

I hope that helps you understand.

Was this page helpful?
0 / 5 - 0 ratings