He estado ejecutando Discourse en un clúster de Kubernetes durante un tiempo utilizando la imagen no compatible de Bitnami. Ahora que Bitnami está desaprobando la imagen y yendo detrás de un muro de pago, estoy buscando migrar nuestro servidor a una solución autoalojada en AWS.
Tengo algunas preguntas con las que estaría agradecido si la comunidad pudiera ayudar:
Ya usamos una base de datos Postgres externa para la instalación y esta permanecerá en su lugar. Sin embargo, actualizamos algunas configuraciones a través de la interfaz de usuario y también usando variables de entorno que los scripts de instalación de Bitnami mapean a Discourse, por ejemplo, DISCOURSE_S3_BACKUP_BUCKET se mapea a S3_BACKUP_BUCKET.
¿Es suficiente configurar los ajustes de Discourse en los archivos yaml requeridos o todavía debemos usar variables de entorno?
Si hacemos una copia de seguridad desde la interfaz de usuario, ¿qué restaurará realmente? ¿Actualiza la base de datos?
¿Es mejor crear una base de datos completamente nueva con una instalación limpia y luego hacer una copia de seguridad/restauración?
Si la nueva instalación es una versión posterior de Discourse, ¿causará un problema si se intenta una restauración?
La guía de instalación estándar utiliza Docker. ¿Cómo se monitorean los contenedores en un entorno de producción, ya que parece que la instalación estándar es una sola VM con Docker?
¿Existen documentos que detallen una migración y posibles problemas?
Estoy seguro de que tendré más preguntas a medida que avance la migración, pero cualquier consejo/ayuda que se pueda brindar sería muy apreciado.
Si no estaba ya en tu plan, te recomendaría moverte a una nueva base de datos (en el mismo servidor) para la migración, así no romperás tu sitio existente.
Si por “mejor” te refieres a “¿significará esto que no romperé nuestro sitio existente y lo dejaré en un estado en el que nunca volverá a funcionar?”, la respuesta es sí.
Eso es lo que quieres. El lugar desde el que restauras debe ser igual o más reciente que la versión de la copia de seguridad. Migrará la base de datos después de restaurarla.
Esto podría ser todo lo que necesitas saber y estaremos encantados de ayudarte aquí de forma gratuita. Si deseas atención práctica y específica para tu configuración, puedes contactarme o pedir ayuda en Marketplace.
Además, otra opción sería crear imágenes y lanzarlas en k8s. Lo he hecho un par de veces y he usado GitHub para crear las imágenes.
Mi experiencia coincide. He visto tantos fallos pequeños y extraños a lo largo de los años que siempre mantengo copias de seguridad completas para poder empezar de cero y restaurar el sitio. Confiar en la corrección de problemas in situ eventualmente te fallará.
Al igual que tú, me quedé en apuros cuando Bitnami dejó de ofrecer imágenes y gráficos gratuitos. Tuve que adaptar y migrar tantas implementaciones. Una de ellas fue mi implementación de Discourse. Si te resulta útil, aquí tienes un enlace al gráfico Helm de reemplazo que creé en muy poco tiempo (lo que significa que funciona pero está lejos de ser un diseño ideal). Es un intento de utilizar el “método de instalación oficial” dado que no he visto emerger ningún gráfico Helm “estándar de la comunidad” después de todos estos años. (Supongo que el gráfico de Bitnami fue efectivamente ese estándar, porque pocos de nosotros predijimos este cambio abrupto). En cualquier caso, este nuevo gráfico que estoy ejecutando para una de mis comunidades de investigación es básicamente solo un pod con dos contenedores: el contenedor oficial Docker-in-Docker y un contenedor personalizado basado en python:3, que instala Docker y luego utiliza la instalación oficial de Discourse. Dado que todos los componentes (servidor Discourse, Redis, PostgreSQL) se ejecutan en la caja negra de la imagen construida localmente por el script del lanzador, no hay escalabilidad ni soporte para alta disponibilidad. Logré reducir el tiempo de inactividad debido a que el pod se reinicia en otro nodo (por ejemplo, al vaciar un nodo para actualizaciones del sistema operativo o un fallo de nodo) utilizando docker save para almacenar la imagen construida en el volumen persistente, y luego cargándola si no se encuentra local_discourse/app:latest.
Pero para responder a tu pregunta, no sé cómo monitorizar nada en esta nueva implementación. Estoy ejecutando “en producción”, pero mi comunidad es lo suficientemente pequeña y el uso es lo suficientemente moderado como para que si el foro se desconecta por un tiempo, no es un gran problema. Aun así, estoy muy cerca de abandonar el auto-alojamiento y migrar a un servicio como Communiteq o Discourse.org.
