Any interest in Podman?

dev
20

I took a shot at this for half an hour or so. Podman is command-compatible but not output-compatible, so launcher gets confused when it tries to parse output. (It’s not hard to tell them apart, docker --version replies with podman version 1.0.5 so this is not a serious impediment.)

There is no docker0 network device. The default overlay storage driver in podman is basically the overlay2 implementation and is aliased to it, but the output doesn’t say overlay2 and the output of the docker info command is slightly different. I used --skip-prereqs to bypass the checks. The shared directories were not automatically created; I didn’t investigate why. I ran mkdir -p /var/discourse/shared/standalone/log/var-log to keep moving. Next I saw permission problems from having SELinux enforcing but not configured for /var/discourse.

If you volume mount in a directory into a container and add a :z or :Z the container engines relabeled the content under the volumes to container_file_t.

The podman build documentation says:

The z option tells Podman that two containers share the volume content. As a result, Podman labels the content with a shared content label. Shared volume labels allow all containers to read/write content. The Z option tells Podman to label the content with a private unshared label. Only the current container can use a private volume.

I decided to setenforce 0 for now on this throwaway install and come back to that later, maybe. I changed the volumes to use the lower-case :z like this:

volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared:z
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log:z

With those small modifications, I got discourse to bootstrap. Redis is unhappy that transparent huge pages are supported in the kernel and suggests disabling that, as well as changing memory overcommit settings. Probably lots of other useful debug messages flew by me in the megabytes of log output!

./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers

I hacked the script to not use --restart, and discovered the need for --skip-prereqs also in the start mode, which finally got me to trying docker run at which point:

./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address option not currently supported

So it definitely doesn’t work out of the box, and I don’t know how much work it would be to fix up launcher to work with either docker or podman. Dealing with prereq handling would be “just work” and probably not too hard with an up-front check for podman, but I don’t know how deep the assumptions about networking setup go into configuration down the stack, and it looks like this networking mode is simply not supported by podman.

Based on that concern, I’m planning on not doing the work to make launcher function under podman. I’m just reporting the result of an initial quick experiment.

That said, it’s probably not hard work for someone who knows the stack better. I did all my development work this spring in a manual development install on Fedora 29 with trivial adjustments like using dnf instead of apt-get and some minor package name translations, not using docker or podman at all. I expect someone who knows podman well as well as normal administration of the whole discourse technology stack would probably find it to be a moderate amount of relatively easy work. If I knew what all the work was, then I’d have a better sense of whether it would be the kind of work that would be likely to “rot” and need ongoing maintenance or not. But… I don’t. :roll_eyes:

17 Likes