Hola,\n\nel equipo recientemente eliminó la compatibilidad para deshabilitar el sondeo largo a través de la interfaz. Esto rompió la funcionalidad requerida para la imagen docker de bitnami, que utiliza passenger y no funciona, véase https://github.com/bitnami/bitnami-docker-discourse/issues/177. La imagen de bitnami no pasa los parámetros de entorno directamente, por lo que esto está roto hasta que alguien extienda la imagen de bitnami, véase Sign in to GitHub · GitHub supuesto, surgió la pregunta, dado que discourse ya solo se distribuye con un contenedor docker: ¿Existe alguna posibilidad de que el equipo mantenga una imagen docker "cloud native"?\n\nLa gran diferencia entre la imagen de bitnami y la suya es el modo de operación. La infraestructura moderna espera que pueda automatizar la instalación. Por lo general, en k8s se hace con helm, pero las implementaciones de ansible en entornos más tradicionales con VMs también darían el mismo resultado. Por lo tanto, lo que realmente pondría a discourse a la par con la imagen de bitnami, bastante descuidada, sería agregar una rutina de instalación automática e incluso adaptar la plantilla de helm.\n\nYa que estoy aquí, permítanme dejar algunos comentarios sobre discourse en sí y su "preparación para la nube":\n\nEn general, cuando intentamos integrar discourse en una configuración reproducible para un proyecto de cliente actual, demostró bastante rápido que discourse nunca se creó bajo los aspectos de la infraestructura moderna. Un ejemplo es la necesidad de un almacenamiento NFS compartido. Eso no es ni fiable ni escalable. Afortunadamente, la mayor parte de esto ya se puede redirigir a un S3, pero quedan partes que son los plugins.\n\nHay tres formas de resolver el problema de los plugins:\n - Código evaluado almacenado en la base de datos (no recomendado)\n - Contenedores sidecar preempaquetados (en términos de kubernetes se usarían como initContainers escribiendo en un emptyDir) escribiendo en un almacenamiento volátil (es decir, tmpfs) antes del inicio del contenedor discourse (recomendado, aunque no muy cómodo)\n - Una rutina de instalación, que obtiene la información actual de los plugins y sus comandos de instalación de la base de datos al inicio y una rutina de observador/escucha para instalar plugins en tiempo de ejecución también (no recomendado, porque es muy lento y propenso a errores)
Creo que esto se ha discutido de forma bastante exhaustiva aquí:
Honestamente, dado que Bitnami lo resolvió fácilmente, no hay mucho que discutir al respecto. No sería ciencia espacial hacer que Discourse sea fácil de implementar.
Solo quiero señalar que ejecutamos muchos sitios de Discourse en entornos de nube y no usamos almacenamiento NFS. Los activos y las cargas se manejan a través del almacenamiento de objetos (S3) mientras que el código fuente (núcleo y complementos) se persiste en la imagen del contenedor iniciada.
Eso ya se respondió: Afortunadamente, la mayor parte de esto ya se puede redirigir a un S3, pero quedan partes que son los plugins. Construir un contenedor por adelantado para usar es una mala práctica, ya que aumenta el riesgo de no actualizarse correctamente a través de los gráficos de Helm utilizados.
¿Puedes por favor explicar esto? No veo cómo los plugins requieren almacenamiento NFS compartido.
Lo siento mucho, pero ya tenemos este tema épico para discutirlo.
No quiero separar esto. Si hay alguna idea, se debe discutir en: