Sigo investigando cómo instalar Discourse para mi comunidad interna. Anteriormente, pregunté sobre cómo instalar Discourse con Redis externo y PostgreSQL externo, y cómo gestionar todo en un clúster de Kubernetes. Puedes encontrar los detalles aquí.
Ahora tengo otra duda, ya que me dijeron que también debo crear mi propia imagen de contenedor para usarla con Helm al desplegar, y debido a eso no podré realizar la instalación con la documentación oficial utilizando los scripts proporcionados en la guía de instalación en la nube.
Intenté construir mi propia imagen usando el comando bootstrap, pero no puedo iniciar la imagen de Docker por mi cuenta porque busca las plantillas de Ruby y devuelve un error.
¿Es posible iniciar la imagen del contenedor sin usar los scripts proporcionados? Creo que necesito un poco de ayuda, ya que intenté revisar el script de bash, pero parece un poco demasiado avanzado para mí. Esperaba que quizás alguien más estuviera en una situación similar y pudiera darme algún consejo.
Para dar más contexto y más detalles:
Utilicé el script de lanzamiento con el comando bootstrap para crear mi propia imagen con mis configuraciones.
Luego, la documentación indica que debes ejecutar el lanzamiento con el comando run para crear el contenedor a partir de la imagen.
Al inspeccionar el código del script, descubrí que la instrucción de docker es esta:
Pero no logro traducir todas las variables a un comando que pueda ejecutar solo sin el script. O tal vez todo este camino que estoy intentando es incorrecto desde el principio, pero quería probar antes de preguntar para ver si podía resolverlo sin molestar a nadie.
Cuando intento ejecutar la imagen de docker por mi cuenta, el contenedor se cierra y, al revisar los registros, veo lo siguiente:
Already up to date.
INFO -- : Loading --stdin
/pups/lib/pups/config.rb:23:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
from /pups/lib/pups/cli.rb:27:in `new'
from /pups/lib/pups/cli.rb:27:in `run'
from /pups/bin/pups:8:in `<main>'
Discourse depende de PostgreSQL ejecutándose en un volumen compartido; y muchos otros archivos importantes están en ese volumen compartido (imágenes, archivos subidos, copias de seguridad, registros y más).
Si mantienes la integridad del sistema de archivos del volumen /shared, según los estándares de configuración de Discourse, entonces puedes iniciar y detener una imagen de Docker de Discourse y la aplicación del contenedor con facilidad; sin embargo, no puedes construir la aplicación (hasta donde yo sé) sin los scripts de Discourse (a menos que hagas una ingeniería inversa completa de los scripts y escribas tu propio script basado en los scripts perfectamente funcionales y soportados), porque los scripts son responsables de construir una sofisticada SPA de EmberJS (tecnología del lado del cliente) sobre Ruby on Rails (una tecnología del lado del servidor), por no mencionar la gestión de la configuración de la aplicación principal y todos los complementos. Para ser honesto, es una aplicación bastante sofisticada.
Sí, puedes iniciar un contenedor de Discourse o crear un contenedor de Discourse a partir de una imagen de Discourse sin ningún script, si (y solo si) ya has construido una imagen de Docker de Discourse perfectamente funcional que cumpla con los estándares de configuración de Discourse, incluidos los requisitos de almacenamiento persistente para la base de datos, imágenes y cargas, copias de seguridad, archivos de registro, etc. Hay muchos archivos importantes requeridos para Discourse en el volumen compartido; y por lo tanto no puedes simplemente “tomar una imagen de Docker de Discourse básica” y ejecutarla sin todos los prerrequisitos mencionados anteriormente (¡y no todo lo mencionado anteriormente!)
Gracias por la respuesta, esto es muy útil Ayer leía sobre por qué se necesitan los scripts en este tema y en otros pocos.
Gracias de nuevo por tu explicación más detallada; toda esta información me ayuda a entender cómo crear mi propio flujo de trabajo para cumplir con los estándares necesarios
Puede resultar muy confuso para cualquier persona que (1) no sea desarrolladora de Ruby on Rails y (2) no sea desarrolladora de EmberJS.
Básicamente, estás construyendo una aplicación de Ruby on Rails en producción y empaquetada en Docker (la tecnología del lado del servidor), que sirve como base para una aplicación SPA de EmberJS de clase mundial (la aplicación principal para los usuarios); y además de todo eso, obtienes un sistema completo de gestión de configuración de código abierto para todo el código fuente, mantenido por un equipo muy talentoso y experimentado de personas con conocimientos web, que llevan mucho tiempo programando en este entorno. Además, también puedes obtener alojamiento profesional y desarrollo personalizado, todo dentro del ecosistema empresarial de Discourse.
Acabo de toparme con esto. ¿Estás diciendo que no puedo ejecutar la aplicación y la base de datos en hosts físicamente diferentes que no compartan absolutamente nada?
Ayer leía sobre por qué se necesitan los scripts en este