People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Beginners Guide to Install Discourse on Ubuntu for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, youāll find the manual instructions there.
Thanks!
I will check it out . .
Docker has been superseded by Podman for RHEL 8.
It sounds natural to start supporting Podman installation not to lose RHEL (and CentOS) customers.
From the Podman official site,
Simply put: āalias docker=podmanā
showing high interoperability against docker.
ROI sounds good?
As the recommended install doesnāt use the repo-supplied docker package Iām not sure this is a consideration either way.
Until docker themselves drop support for a distro weāre fine.
I donāt exactly know how much effort it needs to support Podman, but I thought enterprise customers donāt like āprobably fineā support level.
If running RHEL (CentOS) 8+, youād have to install Docker from an external repo, possibly side by side to Podman and that use case wonāt be supported by RedHat, or simply use Podman to install the docker image but that isnāt supported by Discourse.
Hopefully it gets officially supported.
I reckon this gets more attention as CentOS 8 gets released.
Docker is already supported on CentOS 8 and by extension RHEL 8. Iām not aware of any scenarios where you would run the two side by side, am I missing something?
Itās probably inaccurate to say that docker has been superseded by podman, only that podman now ships by default. After all, who uses the version of docker which ships with the distro?
The onus of support has always been on docker, not Red Hat. As referenced above the recommendation has always been to use the docker package, not that which ships in the distro.
Itās the other way around but the linked RedHat page says,
The
dockerpackage is not shipped or supported by Red Hat for Red Hat Enterprise Linux (RHEL) 8.
The
podmancontainer engine replaceddockeras the preferred, maintained, and supported container runtime of choice for Red Hat Enterprise Linux 8 systems.
I donāt read this as Docker being āsupportedā by RedHat.
If it means, dropping support for RHEL customers, thatās Discourseās choice.
Check the docker repro, they donāt offer RHEL packages, only CentOS.
Podman is meant to be 100% compatible with docker, so really I am not sure we will need to do anything
Perhaps, edit the installation document a bit to add a reference to Podman installation (maybe just say itās supported and youāre supposed to replace the command docker as podman somewhere at the beginning), so people donāt wonder if itās supported or not?
We are not going to take any explicit stand till we test this out
As far as I know, nobody ever in the history of humanity tried installing discourse using podman
I think there is some confusion here. We know about Podman, and several people at the team are rooting for it to become successful because that will be good for the whole FOSS ecosystem, but:
It is not supported.
Our hosting uses Ubuntu / Debian. So we donāt have customers running RHEL at the moment.
Even if itās proven working as-is I would be very wary of any notion of support.
Unless Docker abandons Centos/RHEL itās unnecessary, and even if that were to happen Discourse/Docker wouldnāt be the first app which had requirements at the distro level.
What I find most frustrating here is the amount of speculation vs the amount of work done
If you started with this my reaction would be different
I have used the official Discourse Docker install for the last 30 days on podman, here are the nits I had, here is what I loved about the setup!
The whole premise here is, do work for us, I am unwilling to experiment, I am unwilling to do any work, this is going to be a big problem for you and the community
I dislike this a lot
That crystallises my response pretty well, weāre working with predictable technologies here, thereās no need or room for doomsday proclamations.
Iām not a huge fan of the back-and-forth either and should have probably bitten my tongue rather than engage.
With this statement, I was assuming you had to do some work to get it to work but if itās supposed to be 100% compatible and is just a matter of replacing the command, that would be nice.
I was suggesting that you could guide those who got lost using podman instead of Docker.
I donāt exactly know your development model but I take it itās a community driven one that users are supposed to work first.
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
zoption 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. TheZoption tells Podman to label the content with a private unshared label. Only the current container can use a private volume.
I decided to I changed the setenforce 0 for now on this throwaway install and come back to that later, maybe.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. 