Oh man that’s tragic. So sorry to hear 
7 « J'aime »
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam et ce sujet clarifient que cela ne sera jamais résolu, bien que Bitnami l’ait fait…
Au moins, nous avons eu une réponse à notre question, qui est non.
Et si on évitait d’utiliser root en premier lieu ? L’utilisation de fakeroot montre que le principal obstacle réside dans les chemins codés en dur (comme /var). Sinon, à part les divers bugs et problèmes que la configuration actuelle présente, cela pourrait fonctionner.
Il est dommage de voir un logiciel aussi performant avoir une procédure d’installation obligatoire aussi mal conçue, basée sur une incompréhension courante de la conteneurisation. Il est clair pour moi que cela a été fait avec les meilleures intentions ; néanmoins, le résultat est quelque chose qui ne peut être déployé nulle part en dehors d’un environnement de loisir.
1 « J'aime »
Notre image s’exécute en tant qu’utilisateur discourse, et je pense que l’officielle aussi.
Mais bon, c’est super que le monde « corporate » s’y intéresse, car il a beaucoup plus de temps/d’argent que le monde des amateurs 
Je suis sûr que la communauté appréciera votre contribution à l’amélioration de l’écosystème !
1 « J'aime »
Ce n’est certainement pas correct, nous déployons notre image en utilisant nomad sur des flottes de machines, il y a plus de 10000 conteneurs discourse en cours d’exécution sur aws et metal à l’heure actuelle.
3 « J'aime »
Les outils nécessitent les privilèges root pour s’exécuter et doivent avoir accès au répertoire /var de l’hôte.
Je collabore souvent avec des communautés et des entreprises open source pour améliorer leur configuration de conteneurs. Je serais ravi d’aider et/ou d’envisager un financement pour obtenir une configuration conteneurisée plus raisonnable.
Ce n’est pas obligatoire. C’est juste que si vous avez besoin d’aide pour le configurer, c’est la façon de faire. J’ai aidé des clients utilisant gke, eks, ecs, par exemple. N’hésitez pas à me contacter si vous avez besoin d’aide pour vos besoins spécifiques.
/var n’est pas codé en dur ; J’ai travaillé récemment avec quelqu’un qui l’avait dans /var/www/discourse (ce qui semblait être une très mauvaise idée, car cela risquait de servir des données secrètes sur le web, mais c’était une « politique »).
Ce n’est pas mal conçu, c’est mal conçu si vous deviez le concevoir aujourd’hui plutôt qu’il y a une décennie. C’était une bonne conception à l’époque, et cela fonctionne toujours pour gérer leur infrastructure et même pour de nombreuses personnes qui ne connaissent rien à l’administration système.
2 « J'aime »
J’imagine que vous ne vous appuyez pas sur les outils officiels tels que discourse-setup, qui nécessite les privilèges root pour être exécuté, et qui est probablement destiné à une installation locale.
Jetez un œil à la source discourse-setup. Si vous êtes familier avec la configuration et l’optimisation des performances de Discourse, ce n’est pas obligatoire.
Launcher effectue tout le travail pour construire l’image à partir du fichier yml résultant.
2 « J'aime »
Tout peut être fait, mais cela me semble un effort inutile.
- Utilisez
fakerootavant chaque commande /varpeut être modifié en éditant le fichier yaml :sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml--skip-connection-test(trouvé en regardant le code, car le script n’est pas capable de vérifier la connexion s’il y a un proxy inverse)- Je vois quelque chose lié à certbot, je sais déjà que je devrai trouver comment le désactiver car la terminaison SSL est généralement effectuée en externe
- Les ports de
containers/app.ymlpeuvent être modifiés pour utiliser des ports>= 1024, mais cela ne semble pas suffisant :Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
Je ne veux pas être méchant, mais avoir plusieurs services fonctionnant dans un seul conteneur a toujours été une mauvaise conception, car cela signifie avoir peu ou pas de moyen de savoir ce qui se passe avec les services individuels, devoir mettre en place un mécanisme personnalisé d’analyse des journaux en dehors de Docker, pas de healthchecks utiles, ne pas pouvoir facilement s’appuyer sur une base de données externe, etc. Cela peut être fait si c’est le seul service que vous exécutez dans votre entreprise, mais si tous les autres services commencent à le faire, la plupart des avantages de l’utilisation des conteneurs disparaissent.
Je serais heureux d’envoyer des PR et de la documentation pour faire fonctionner Discourse dans un environnement compatible Docker sans accès root, mais découpler les services et avoir une configuration standard serait une tâche ardue sans garantie qu’elle soit intégrée.
Si vous n’êtes pas d’accord avec les aspects fondamentaux de la façon dont Discourse est construit, avez-vous envisagé d’utiliser un produit différent ?
3 « J'aime »
Ok, je comprends mieux.
Discourse a une opinion bien arrêtée sur les outils pour l’auto-hébergement. Cela leur permet de fournir un support efficace à la plupart des administrateurs peu expérimentés qui souhaitent déployer Discourse. Vous pouvez être d’accord ou non, j’étais aussi un peu triste par le passé, mais maintenant je comprends mieux 
Si vous avez un besoin différent d’une mise en route rapide comme la plupart des gens, alors vous êtes largement seul. Une fois que vous le savez, ce n’est pas grave
Nous avons le même besoin d’une image Docker Discourse autonome. Nous l’exécutons sur Kubernetes avec Minio, cela a été un peu pénible pour le faire fonctionner, et cela demande encore beaucoup d’efforts. Nous avons également reçu une aide précieuse de Discourse pour y parvenir.
Notre travail est disponible ici :
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(ce n’est pas assez documenté, ni testé, ni maintenu ou mis à jour à temps, ni automatisé, et probablement un peu personnalisé, c’est ce que c’est)
Si des personnes sont intéressées pour l’améliorer, n’hésitez pas à venir faire des PR, ou à discuter ici : https://matrix.to/#/#libresh:liiib.re
Mais oui, l’équipe Discourse a une opinion bien arrêtée sur la version communautaire de Discourse. Vous pouvez être d’accord ou non, mais ils fournissent la plupart du support aux gens, et d’après ce que j’ai vu, c’est un support incroyable, donc je pense que c’était une bonne décision
6 « J'aime »
Ce sont des aspects fondamentaux de la façon dont Discourse est empaqueté, plus que Discourse lui-même, qui est un excellent logiciel, mais vous avez raison, je devrais envisager différentes solutions.
2 « J'aime »
Vous êtes invités à supprimer les modèles pour postgres et redis (ainsi que ssl et let’s encrypt) et à utiliser les vôtres.
2 « J'aime »
Merci de partager. J’ai également trouvé GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar et des images de bitnami. Le problème principal est que ces solutions ne sont pas officiellement prises en charge. Je me demande si ce ne serait pas une idée d’avoir une configuration Docker alternative prise en charge par la communauté, au lieu d’avoir divers dépôts personnalisés, car il ne serait pas efficace de répartir les efforts sur plusieurs endroits.
1 « J'aime »
Vous avez raison, les paramètres peuvent en effet être modifiés. Si j’arrive à le faire fonctionner sans gros effort, j’essaierai d’envoyer quelques PR pour améliorer les outils ou la documentation existants, comme le faire fonctionner sans root. Cela devrait être compatible avec les opinions de l’équipe de développement, tout en apportant un certain soulagement à certains administrateurs système plus exigeants.
9 ans plus tard, il semble que Docker idiomatique soit couvert par le discourse de Bitnami ?
Mais ailleurs sur ce forum, on affirme qu’il consomme beaucoup de RAM et qu’il n’est pas pris en charge. J’ai été surpris de constater à quel point il y a encore de frictions dans la configuration canonique lorsqu’on essaie de le faire fonctionner dans le cloud.
Beaucoup de services aujourd’hui comme redis, postgres et le stockage compatible s3 sont faciles à configurer et à déplacer entre différents hôtes comme digitalocean, supabase, aws, etc., donc le backend est portable. La VM exécutant Discourse semble également facile à faire évoluer/échanger avec des builds déterministes. Il est dommage qu’il soit si proche de cet idéal mais freiné.
Comme un autre utilisateur l’a dit, c’est surprenant :
La logique évoquée plus tôt dans le fil de discussion selon laquelle rendre cela plus facile pourrait entraver les opportunités commerciales est étrange. Les intérêts commerciaux auront du personnel pour gérer les builds complexes, donc cela touche davantage les développeurs solo que quiconque. Mon cas d’utilisation personnel est que j’administre une très grande communauté (sans profit). Donc, elle ne relève ni du hobbyiste par sa taille, ni du commercial par ses revenus.
1 « J'aime »
Euh… J’envisage de mettre en place un forum/une communauté et j’ai évidemment pensé à utiliser Discourse (parce que j’apprécie l’expérience utilisateur), mais encore une fois, je me heurte à l’obstacle d’une installation/gestion complètement hostile…
Au fil des ans, je me suis tellement attaché à faire fonctionner tout avec un simple fichier docker-compose, en ajoutant quelques éléments supplémentaires (base de données, minio pour le stockage compatible s3 et autres), mais non… Discourse est toujours super hostile dans ce cas.
Je suis désolé, mais avoir un stupide “lanceur” pour démarrer les choses ?
Et puis le processus de mise à niveau indiquant :
> Créez manuellement une nouvelle image de base en exécutant : `./launcher rebuild my_image`
sorry - reconstruire manuellement l’image ? Comme WTF… c’est comme utiliser docker mais sans vraiment l’utiliser…
Est-ce que ./launcher rebuild app fonctionne ? C’est la commande habituelle.
De plus, avez-vous suivi le guide d’installation standard ?
Je n’ai rien de constructif à commenter, alors je vous demande d’essayer de mettre à niveau le serveur Mastodon, Pixelfed, Moodle… Discourse est incroyablement facile.
Une commande manuelle est un obstacle 
2 « J'aime »