Imagen oficial de Docker con soporte de la comunidad

Desarrollador
21

Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images :+1:. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.

They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.

22

Thanks for creating this thread @pierreozoux!

I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse.

Some background about Helm / Kubernetes:
A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration.

I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.

23

I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners :slight_smile:

If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.

24

¡Hola a todos!

Soy de una comunidad italiana bastante grande que utiliza Discourse como herramienta para su foro.
Aunque nos encanta Discourse, también hemos observado algunas dificultades al implementarlo en Kubernetes mediante ciertos procedimientos “estándar”.

Siento el dolor de los mantenedores :slight_smile: He trabajado en la Open Networking Foundation durante años, y uno de los mayores desafíos ha sido trasladar CORD —una de nuestras plataformas más importantes— de instalaciones basadas en scripts a Dockerfiles/docker-compose e imágenes de Docker alojadas en DockerHub, junto con helm-charts. Aunque existe un temor razonable al hacerlo, y aunque una solución que se adapte a todos los casos nunca existe realmente, puedo decir que hemos visto claramente los beneficios desde los primeros despliegues.

Por lo general, el paso más importante es adoptar la mentalidad de dejar que las herramientas existentes hagan lo que mejor saben hacer :slight_smile: Docker tiene procedimientos de instalación que son estándar, sencillos y ya están bien documentados. Los scripts son algo personalizado que a menudo requiere adaptaciones y mantenimiento adicional.
Además, no hay ninguna razón real por la que no debieras poder utilizar las imágenes originales de Docker y los helm-charts como dependencias de Discourse (es decir, unicorn, postgres, redis, etc.).

Te sugiero abordar primero lo básico (es decir, tener un Dockerfile, docker-compose y una compilación automatizada en DockerHub para cada componente). Una vez hecho esto (con las modificaciones adecuadas de software y documentación), el desarrollo de helm-charts será lo más sencillo.

Estaría muy encantado de ayudar, incluso mediante una llamada para discutir los pros y los contras de las soluciones propuestas anteriormente.

Durante mi breve investigación, también noté que Bitnami (muy famosa en el ámbito de Docker) ha creado algunas imágenes (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). Me preguntaba si se trata de un trabajo independiente que han realizado por su cuenta o si ha sido algo coordinado con ustedes. Podría ser un excelente punto de partida. Si no hubiera una asociación con ellos, lo sugeriría como una posible vía a seguir. No estoy seguro de si lo harían de forma gratuita, pero podría ser una posibilidad.
Por cierto, he abierto un problema en su repositorio para obtener más información sobre el trabajo realizado (https://github.com/bitnami/bitnami-docker-discourse/issues/132).

Por favor, háganme saber sus opiniones y si puedo ayudar de alguna manera.

26

Hola @Luca_Prete, ¿has revisado el trabajo de @pierreozoux más arriba y la respuesta del equipo?

La mayor parte del trabajo de empaquetado de Docker consistiría en igualar lo que hace pups en segundo plano para launcher, incluida la configuración personalizada de Postgres, Sidekiq, etc. @unteem resolvió una necesidad y siguió lo que pups hacía para versiones anteriores de Discourse. Mantener la imagen de Docker actualizada con la versión oficial es un desafío. Sería interesante desentrañar todo el proceso y recorrer ese camino con un enfoque estándar de Docker. Si existe una vía viable para utilizar una configuración estándar, supongo que muchas personas aquí estarían muy contentas.

27

@hellekin gracias.

No lo he hecho. Estoy seguro de que hay mucho allí, pero por lo general tiendo a mantenerme alejado, al menos para el trabajo, de los empleos de usuario único (en contraposición a los apoyados por la comunidad), por la simple razón de que puede volverse difícil mantenerlos más adelante.

La ruta específica realmente depende de algunos detalles de la plataforma.

Lo que veo como una posible solución en tu caso sería empezar a entender cómo funcionarían las imágenes estándar (Postgres, Redis, …) con Discourse sin personalizaciones específicas.

La razón por la que considero esto importante es que te da la capacidad de confiar, en cualquier lugar donde instales Discourse, en servicios estándar externos (que podrían instalarse en hardware físico, en una VM, en algunos contenedores, en k8s en forma de dependencias de gráficos, …).

Cada uno de estos servicios típicamente permite el uso de algunos scripts de inicio para crear una base de datos, etc. No debería ser tan difícil.

Luego, crearía un Dockerfile adecuado (que también se convierte automáticamente en tu guía de inicio rápido para los usuarios que deseen instalar Discourse sin Docker).

A continuación viene el docker-compose.yaml (esto es prácticamente lo mismo que Bitnami expone en su GitHub).

En este punto, deberías poder levantar Discourse en tu portátil en forma de "micro"servicios, utilizando imágenes de dependencias estándar, en unos segundos, con un solo comando, sin ningún script personalizado.

Por último, pero no menos importante, viene la diversión de Kubernetes (unos pocos archivos YAML, posiblemente empaquetados en forma de gráficos Helm), para publicarse en el repositorio oficial y estable, o alternativamente, al menos al principio del proceso, en tu repositorio autoalojado.

28

@unteem no está solo :slight_smile: Trabajamos juntos.
Hacemos esto porque alojamos varias instancias de Discourse.
Empezamos con Docker y ahora ejecutamos en Kubernetes.

Hemos trasladado nuestro trabajo a https://lab.libreho.st/, que es un esfuerzo comunitario (@hellekin también forma parte de ello). Queremos dar más visibilidad a nuestro trabajo en las próximas semanas/meses.

Es realmente un dolor de cabeza mantener esto… Literalmente pasé horas, si no días, en este commit que arregló mis compilaciones:

De todos modos, en realidad estamos trabajando en operadores de Kubernetes. Empezamos con Nextcloud, luego Rocket.Chat, y el siguiente probablemente será Discourse.

Mientras tanto, puedes encontrar el código de las imágenes de Docker que usamos aquí:

Las imágenes en sí están aquí:

Como puedes ver, hemos estado dedicando tiempo a esto recientemente. Así que tenemos etiquetas y pipelines. Necesitamos añadir automatización para tener compilaciones semanales.

Tenemos un gráfico Helm allí:
https://git.indie.host/indiehost/helm-discourse
Pero como puedes ver, no está realmente mantenido.

Lo que puedo decir es que funciona para nosotros :slight_smile: Si quieres compartir el viaje y te sientes aventurero, siéntete libre de unirte a nosotros :slight_smile: Nos divertimos :slight_smile:

Realmente no proporcionamos soporte, no tenemos mucho tiempo para ello, pero si haces un PR, será bienvenido. De verdad desearía que pudiéramos hacer este trabajo bajo el paraguas oficial de Discourse, sería mucho más fácil.
Pero al final del día, empiezo a entender al equipo de Discourse. Solo tienen una herramienta que apoyan para la comunidad, y funciona bien. Ofrecen un buen soporte para usuarios no tan técnicos, y eso es realmente agradable. Si hay un problema, git pull && rebuild, resuelve el 99% de los problemas :slight_smile: Entiendo que apoyar otra herramienta es un gran riesgo, y si no se hace bien o no se mantiene, podría perjudicar al proyecto de alguna manera. De nuevo, muchas gracias al equipo de Discourse por su arduo trabajo :slight_smile:
Mi único problema es que probablemente somos muchos desarrollando nuestra propia solución, y la única forma de colaborar es hacerlo aquí, aguas arriba.

En realidad, una forma de hacerlo sería tener otra imagen en discourse_docker que se llamara super_base, sin runit/anacron/nginx/postgres, y la base estaría basada en super_base, y podríamos reutilizarla para nuestro despliegue en k8s. Creo que funcionaría :slight_smile:

¿Qué opinas?

¿Discourse está usando Kubernetes? Tengo curiosidad :slight_smile:

29

@pierreozoux ¡gracias por la respuesta!

Creo que han hecho un gran trabajo y estaría encantado de contribuir en lo que pueda :slight_smile:

También he tenido más tiempo para revisar mejor el trabajo que hicieron los chicos de Bitnami. La buena noticia es que ya han separado los contenedores. ¿Tuviste oportunidad de verlo? ¿Qué opinas?

Aquí están los archivos Docker utilizados tanto para los contenedores web como para sidekiq: bitnami/discourse Dockerfile

No puedo pegar el enlace al docker-compose, pero puedes encontrarlo fácilmente siguiendo el enlace que añadí en mi publicación anterior del hilo.

En el mismo repositorio también hay un archivo YAML de Kubernetes: https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

Empezando por la imagen Docker, ¿ves algún problema? ¿El software está lo suficientemente “actualizado”?

Lo que parece faltar es el helm-chart, que debería hacerse siguiendo las mejores prácticas adoptadas para los gráficos estables.

¿Qué opinan? ¿Vale la pena unir esfuerzos e integrar sus archivos en su trabajo?

30

Ese es exactamente el mismo cambio realizado por DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub. Si estás haciendo un fork de la imagen, quizás quieras considerar integrar los cambios de ese repositorio de forma concurrente.

Esto es básicamente nuestra motivación para mantener el statu quo.

Agregar cualquier cosa que no usemos internamente solo significa que se romperá y quedará obsoleta poco después, causando más problemas a todos los que dependían de ello. Hemos tenido varios ejemplos de esto en el proyecto.

Si es algo que la comunidad quiere trabajar, está bien.

No, no usamos k8s.

31

Es solo que hay muchas dependencias que mantener actualizadas.

La gente publica bastante regularmente aquí que no funcionan de una manera u otra.

Lo que he estado haciendo es usar launcher para construir imágenes y enviarlas a un repositorio que luego despliego con Kubernetes, y tengo scripts para actualizaciones sin tiempo de inactividad. Es un exceso enorme para los clientes para los que lo he configurado. Estoy alojando 3 millones de visitas mensuales en hardware estándar con una configuración (en su mayoría) normal (solo tiene un proxy inverso de Traefik para varios sitios).

He considerado publicar un conjunto de imágenes con, por ejemplo, varios conjuntos de complementos, pero el problema es que si hay algún problema con ellas, no pueden obtener soporte aquí.

32

¿Hay algún cambio sobre el tema? ¿Existe o habrá una imagen oficial de Discourse que pueda usarse fácilmente para implementaciones en Kubernetes?

33

No habrá. La solución que uso es arrancar la nueva imagen, subirla a un repositorio, luego lanzarla y, finalmente, ejecutar las migraciones posteriores a la actualización una vez que los nuevos pods se inicien.

34

¿Alguna novedad? ¿Sigue sin haber un Helm Chart oficial para instalar Discourse en Kubernetes?

35

No, y eso tampoco está en nuestra hoja de ruta.

Consulta Can Discourse ship frequent Docker images that do not need to be bootstrapped? para obtener contexto.

36

He estado considerando hacer una oferta de ese tipo (y no sería “oficial”), pero necesitaría asegurarme de que no generara problemas de soporte adicionales aquí y me pagara por el tiempo que dediqué a mantenerla y darle soporte. Tengo poca idea de cómo resolver cualquiera de esos problemas, pero si tienes un presupuesto, no dudes en contactarme.

37

Hemos estado alojando discourse con éxito en helm con nuestra propia imagen de docker desde hace algunos meses.
(antes también usábamos nuestra propia imagen, con compose)

Y es con soporte s3/minio.

https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse

(pero definitivamente carece de documentación y de “apertura” para abrir cuentas y contribuir.
Si hay demanda, aquí o en privado, ¡podemos abrir :))

@pfaffman si encuentras gente feliz dispuesta a apoyar tu tiempo, ¡estaremos encantados de colaborar!

Estamos alojando discourse para algunas comunidades pequeñas, principalmente en Francia, parte del movimiento común.
(Como https://forum.chatons.org/ es la más grande que alojamos pro bono)