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: Install Discourse on Ubuntu or Debian 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 a été remplacé par Podman pour RHEL 8.
Il semble naturel de commencer à prendre en charge l’installation de Podman afin de ne pas perdre les clients RHEL (et CentOS).
D’après le site officiel de Podman,
Pour faire simple : ‘alias docker=podman’
ce qui démontre une forte interopérabilité avec Docker.
Le retour sur investissement semble intéressant ?
Comme l’installation recommandée n’utilise pas le paquet Docker fourni par le dépôt, je ne suis pas certain que cela soit une considération dans un sens ou dans l’autre.
Tant que Docker lui-même ne retirera pas le support d’une distribution, nous sommes tranquilles.
Je ne sais pas exactement combien d’efforts il faut pour prendre en charge Podman, mais je pensais que les clients d’entreprise n’aiment pas un niveau de soutien du type « probablement tranquille ».
Si vous exécutez RHEL (CentOS) 8+, vous devrez installer Docker depuis un dépôt externe, éventuellement en parallèle de Podman, et ce cas d’usage ne sera pas pris en charge par Red Hat, ou simplement utiliser Podman pour installer l’image Docker, mais cela n’est pas pris en charge par Discourse.
Espérons que cela sera officiellement pris en charge.
Je pense que cela attirera plus l’attention avec la sortie de CentOS 8.
Docker est déjà pris en charge sur CentOS 8 et, par extension, sur RHEL 8. Je ne connais aucun scénario où vous exécuteriez les deux côte à côte ; aurais-je manqué quelque chose ?
Il est probablement inexact de dire que Docker a été remplacé par Podman ; il s’agit plutôt du fait que Podman est désormais livré par défaut. Après tout, qui utilise la version de Docker fournie avec la distribution ?
La responsabilité du support a toujours incombé à Docker, et non à Red Hat. Comme mentionné ci-dessus, la recommandation a toujours été d’utiliser le paquet Docker, et non celui fourni avec la distribution.
C’est en fait l’inverse, mais la page RedHat liée indique :
Le paquet
dockern’est ni fourni ni pris en charge par Red Hat pour Red Hat Enterprise Linux (RHEL) 8.
Le moteur de conteneurs
podmana remplacédockeren tant que runtime de conteneurs préféré, maintenu et pris en charge pour les systèmes Red Hat Enterprise Linux 8.
Je n’interprète pas cela comme une prise en charge de Docker par Red Hat.
Si cela signifie abandonner le support pour les clients RHEL, c’est le choix de Discourse.
Vérifiez le dépôt Docker, ils ne proposent pas de paquets RHEL, uniquement des paquets CentOS.
Podman est censé être 100 % compatible avec Docker, donc vraiment, je ne suis pas sûr que nous ayons besoin de faire quoi que ce soit.
Peut-être, modifiez un peu le document d’installation pour ajouter une référence à l’installation de Podman (par exemple, indiquez simplement qu’il est pris en charge et que vous devez remplacer la commande docker par podman quelque part au début), afin que les gens ne se demandent pas s’il est pris en charge ou non ?
Nous n’adopterons aucune position explicite tant que nous n’aurons pas testé cela.
À ma connaissance, personne dans l’histoire de l’humanité n’a jamais essayé d’installer Discourse en utilisant Podman.
Je pense qu’il y a une certaine confusion ici. Nous connaissons Podman, et plusieurs membres de l’équipe souhaitent son succès, car cela serait bénéfique pour tout l’écosystème des logiciels libres (FOSS), mais :
Il n’est pas pris en charge.
Notre hébergement utilise Ubuntu / Debian. Nous n’avons donc pas actuellement de clients utilisant RHEL.
Même si cela fonctionne tel quel, je serais très méfiant à l’égard de toute notion de support.
À moins que Docker n’abandonne CentOS/RHEL, cela est inutile, et même si cela devait arriver, Discourse/Docker ne serait pas la première application ayant des exigences au niveau de la distribution.
Ce qui me frustre le plus ici, c’est la quantité de spéculations par rapport au travail accompli.
Si vous aviez commencé par ceci, ma réaction aurait été différente :
J’ai utilisé l’installation Docker officielle de Discourse via Podman au cours des 30 derniers jours. Voici les petits détails qui m’ont gêné et ce que j’ai aimé dans cette configuration !
La prémisse générale ici est : faites le travail pour nous. Je ne suis pas disposé à expérimenter, je ne suis pas disposé à faire le moindre effort. Cela va devenir un gros problème pour vous et pour la communauté.
Je n’aime pas cela du tout.
Cela résume parfaitement ma réponse : nous travaillons avec des technologies prévisibles, il n’y a ni besoin ni place pour des proclamations apocalyptiques.
Je ne suis pas non plus un grand partisan des échanges incessants et j’aurais probablement dû me taire plutôt que de m’engager.
Avec cette affirmation, je supposais que vous deviez effectuer un certain travail pour que cela fonctionne, mais si cela doit être 100 % compatible et qu’il ne s’agit que de remplacer la commande, ce serait bien.
Je suggérais que vous puissiez guider ceux qui se sont perdus en utilisant podman au lieu de Docker.
Je ne connais pas exactement votre modèle de développement, mais je suppose qu’il est piloté par la communauté et que les utilisateurs sont censés travailler en premier.
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. 