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.
J’ai tenté l’expérience pendant une demi-heure environ. Podman est compatible au niveau des commandes, mais pas au niveau des sorties, ce qui perturbe launcher lorsqu’il tente d’analyser la sortie. (Ce n’est pas difficile de les distinguer : docker --version répond par podman version 1.0.5, ce qui n’est pas un obstacle majeur.)
Il n’existe pas d’appareil réseau docker0. Le pilote de stockage overlay par défaut de Podman est essentiellement l’implémentation overlay2 et lui est aliasé, mais la sortie ne mentionne pas overlay2 et la commande docker info produit une sortie légèrement différente. J’ai utilisé --skip-prereqs pour contourner les vérifications. Les répertoires partagés n’ont pas été créés automatiquement ; je n’ai pas investigué la raison. J’ai exécuté mkdir -p /var/discourse/shared/standalone/log/var-log pour continuer. Ensuite, j’ai rencontré des problèmes de permissions dus au fait que SELinux était activé mais non configuré pour /var/discourse.
Si vous montez un répertoire en volume dans un conteneur et ajoutez :z ou :Z, les moteurs de conteneurs relient le contenu sous les volumes à
container_file_t.
La documentation de build de Podman indique :
L’option
zindique à Podman que deux conteneurs partagent le contenu du volume. En conséquence, Podman étiquette le contenu avec un label de contenu partagé. Les labels de volume partagés permettent à tous les conteneurs de lire et d’écrire dans le contenu. L’optionZindique à Podman d’étiqueter le contenu avec un label privé non partagé. Seul le conteneur actuel peut utiliser un volume privé.
J’ai décidé de lancer J’ai modifié les setenforce 0 pour l’instant sur cette installation jetable et de revenir dessus plus tard, peut-être.volumes pour utiliser le :z en minuscules comme ceci :
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
Avec ces petites modifications, j’ai réussi à amorcer Discourse. Redis n’est pas content que les pages énormes transparentes soient prises en charge dans le noyau et suggère de les désactiver, ainsi que de modifier les paramètres de sur-engagement de mémoire. Probablement beaucoup d’autres messages de débogage utiles m’ont échappé dans les mégaoctets de sortie des journaux !
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
J’ai modifié le script pour ne pas utiliser --restart et découvert le besoin de --skip-prereqs également en mode start, ce qui m’a finalement amené à essayer docker run, moment où :
./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
Donc, cela ne fonctionne certainement pas hors de la boîte, et je ne sais pas combien de travail il faudrait pour adapter launcher afin qu’il fonctionne avec Docker ou Podman. Gérer les prérequis serait « fonctionnel » et probablement pas trop difficile avec une vérification préalable de Podman, mais je ne sais pas à quel point les hypothèses sur la configuration réseau sont profondes dans la pile de configuration, et il semble que ce mode de réseau ne soit tout simplement pas pris en charge par Podman.
Compte tenu de cette préoccupation, je prévois de ne pas effectuer le travail nécessaire pour faire fonctionner launcher sous Podman. Je rapporte simplement les résultats d’une première expérience rapide.
Cela dit, ce n’est probablement pas un travail difficile pour quelqu’un qui connaît mieux la pile. J’ai effectué tout mon travail de développement ce printemps sur une installation manuelle de développement sur Fedora 29 avec des ajustements triviaux comme l’utilisation de dnf au lieu de apt-get et quelques traductions mineures de noms de paquets, sans utiliser Docker ni Podman du tout. Je pense que quelqu’un qui connaît bien Podman ainsi que l’administration normale de toute la pile technologique Discourse trouverait probablement cela être une quantité modérée de travail relativement facile. Si je savais exactement tout le travail impliqué, j’aurais une meilleure idée de savoir s’il s’agirait d’un type de travail susceptible de « pourrir » et nécessiter une maintenance continue ou non. Mais… je ne sais pas. 