Salut,\n\nl’équipe a récemment supprimé la prise en charge de la désactivation du long polling via l’interface. Cela a rompu des fonctionnalités requises pour l’image Docker Bitnami, qui utilise Passenger et ne fonctionne pas, voir https://github.com/bitnami/bitnami-docker-discourse/issues/177. L’image Bitnami ne transmet pas directement les paramètres d’environnement, donc cela est cassé jusqu’à ce que quelqu’un étende l’image Bitnami, voir Sign in to GitHub · GitHub sûr, la question s’est posée pour moi, puisque Discourse n’est déjà distribué qu’avec un conteneur Docker : y a-t-il une chance que l’équipe maintienne une image Docker « cloud native » ?\n\nLa grande différence entre l’image Bitnami et la vôtre est le mode de fonctionnement. L’infrastructure moderne s’attend à ce que vous puissiez automatiser l’installation. Généralement, dans k8s, cela se fait avec Helm, mais les déploiements Ansible dans des environnements plus traditionnels avec des VM aboutiraient au même résultat. Donc, ce qui rendrait Discourse comparable à l’image Bitnami plutôt négligée serait d’ajouter une routine d’installation automatique et peut-être même d’adapter le modèle Helm.\n\nPendant que j’y suis, laissez-moi faire part de mes commentaires sur Discourse lui-même et sa « préparation au cloud » :\n\nEn général, lorsque nous avons essayé d’intégrer Discourse dans une configuration reproductible pour un projet client actuel, il est apparu assez rapidement que Discourse n’a jamais été conçu dans l’optique de l’infrastructure moderne. Un exemple est la nécessité d’un stockage NFS partagé. Ce n’est ni fiable ni évolutif. Heureusement, la plupart de ces éléments peuvent déjà être redirigés vers un S3, mais il reste des parties qui sont les plugins.\n\nIl existe trois façons de résoudre le problème des plugins :\n - Code évalué stocké dans la base de données (non recommandé)\n - Conteneurs sidecar pré-packagés (en termes Kubernetes, ils seraient utilisés comme initContainers écrivant dans un emptyDir) écrivant sur un stockage volatile (c’est-à-dire tmpfs) avant le démarrage du conteneur Discourse (recommandé, même si pas super pratique)\n - Une routine d’installation, récupérant les informations actuelles des plugins et leurs commandes d’installation à partir de la base de données au démarrage et une routine de surveillance/écoute pour installer les plugins à l’exécution également (non recommandé, car très lent et sujet aux erreurs)
Je pense que cela a été discuté de manière assez approfondie ici :
Honnêtement, puisque Bitnami l’a résolu facilement, il n’y a pas beaucoup de raisons d’en discuter autant. Ce ne serait pas de la science de fusée de rendre Discourse facilement déployable.
Je voulais juste souligner que nous gérons de nombreux sites Discourse dans des environnements cloud et que nous n’utilisons pas de stockage NFS. Les actifs et les téléchargements sont gérés via un stockage d’objets (S3) tandis que le code source (noyau et plugins) est persisté dans l’image conteneur amorcée.
Ceci a déjà été répondu : Heureusement, la plupart de ces éléments peuvent déjà être redirigés vers un S3, mais il reste des parties qui sont les plugins. Construire un conteneur à l’avance à utiliser est une mauvaise pratique car cela augmente le risque de ne pas mettre à niveau correctement les diagrammes Helm utilisés.
Pouvez-vous s’il vous plaît élaborer sur ce point ? Je ne vois pas comment les plugins nécessitent un stockage NFS partagé.
Je suis vraiment désolé, mais nous avons déjà ce sujet épique à discuter.
Je ne veux pas le scinder. S’il y a des idées, elles devraient être discutées ici :