¿Alguien podría aconsejarme sobre cómo crear una imagen de Docker de Discourse que tenga varios complementos integrados en lugar de instalarlos a través de la interfaz de usuario?
Contexto: queremos utilizar la última compilación de Discourse, es decir, discourse:stable, y por lo que he leído en la guía de instalación y otra documentación, podemos tomar esta imagen base en nuestro propio Dockerfile y luego hacer algo como:
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
Esto añadiría el complemento discourse-chat-integration a la compilación. Luego, en tiempo de ejecución, podemos pasar todas las variables de entorno necesarias, es decir, DISCOURSE_HOSTNAME, DISCOURSE_SMTP_DOMAIN, DISCOURSE_DB_HOST, etc., en lugar de tenerlas codificadas en el archivo app.yml.
Si alguien pudiera aconsejarme sobre lo anterior, se lo agradecería enormemente.
No puedes instalar complementos desde la interfaz de usuario. Los instalas desde el archivo YML. Si estás utilizando algún contenedor no soportado que no construiste tú mismo con el lanzador (launcher), entonces harías algo como lo que sugieres.
Pero ese complemento está en el núcleo (core) (¿pero quizás aún no en la versión estable?).
En realidad, no están codificados en el archivo YML. El archivo yml se utiliza para construir y lanzar el contenedor. Puedes construirlo y luego lanzarlo tú mismo, como quieras. Puedes usar ./launcher start-cmd nombre-del-contenedor (o algo parecido, puedes mirar en el lanzador para ver si me equivoqué).
Así que creo que lo que quieres hacer es seguir usando el lanzador (launcher), añadir el complemento, ejecutar ./launcher bootstrap app en el contenedor, y luego lanzarlo como quieras. Incluso puedes enviarlo a un repositorio desde donde puedas lanzarlo desde otra máquina.
Entonces, lo que estamos buscando hacer es ejecutar Discourse en nuestro clúster de Kubernetes y nos gustaría poder construir la imagen en nuestro flujo de trabajo de CI/CD, de ahí el Dockerfile personalizado. Todas las variables de entorno se suministran luego al pod en ejecución en un ConfigMap y/o Secret. Sé que esta no es una instalación soportada, pero estoy tratando al menos de usar la forma soportada de construir una imagen de Discourse para una versión específica de Discourse para poder controlar cuándo actualizamos.
Al observar el script launcher existente y el samples/web_only.yml, creo que puedo comentar las secciones volumes y links, ya que esto se haría en Kubernetes con un Volumen Persistente y un montaje. Luego agregaríamos los valores de entorno fijos en el web_only.yml, construiríamos el contenedor con el comando de arranque y luego copiaríamos la imagen generada a nuestro propio repositorio.
En cuanto a la versión de Discourse, podemos monitorear cuándo hay una nueva versión disponible en Docker Hub y luego modificar el valor de base_image en el archivo web.template.yml.
Quizás, pero el contenedor necesita hablar con alguna base de datos para construir el contenedor, por lo general. No necesita ser la base de datos real (pero entonces necesitas migrar la base de datos y precompilar los activos en tu canalización).
Puede que estés confundiendo el problema de las actualizaciones de Discourse con las actualizaciones de los recursos en el contenedor base.
Logré que el contenedor se compilara bien sin el hookdb:migrate, no estoy seguro de si funcionará ya que aún no lo he probado, está en la lista de tareas pendientes
Para el valor de base_image, supongo que cambia cuando se lanza una nueva imagen de Docker, así que creo que simplemente tomaré lo que esté en la rama principal, ya que es lo que se llama en el script de lanzamiento.
Gracias Jay. Finalmente logré que mi compilación funcionara, bueno, el pod se inició Cambié mi proceso de compilación de CI/CD para incluir db:migrate usando una base de datos temporal.
¿Necesita ejecutarse siempre un db:migrate al inicio, ya que mi compilación de imagen sería contra una base de datos/redis simulada? Mi enfoque actual es que el db:migrate y la precompilación se realizarían en un initContainer en mi pod.
La imagen discourse/discourse sería ideal de usar si pronto estará lista para producción.
Si te interesan las actualizaciones sin tiempo de inactividad, deberías usar SKIP_POST_DEPLOYMENT_MIGRATIONS y, después de que las pods antiguas hayan desaparecido, realizar la migración de nuevo con algo como rake db:ensure_post_migrations db:migrate.
Muchas gracias por toda la ayuda hasta ahora, Jay.
Tengo otra pregunta
Actualmente estoy configurando varias variables de entorno en nuestro despliegue, por ejemplo, DISCOURSE_BACKUP_LOCATION=s3, y entiendo que Discourse utilizará ese valor en lugar del que se ha establecido a través de la interfaz de usuario y, por lo tanto, se almacena en la tabla site_settings, ¿es correcto? Si es así, ¿hay alguna herramienta/script disponible que me permita verificar qué variables de entorno están configuradas y determinar su equivalente en la configuración del sitio?
El motivo es que estoy buscando migrar una instancia de Discourse en funcionamiento y, para ayudar a minimizar el riesgo, quería no configurar las variables de entorno por ahora en caso de que me faltara alguna en la nueva instancia y tuviera un impacto perjudicial en la nueva instancia. Mi idea era verificar lo que está configurado en la instancia actual, crear la configuración relevante en la tabla, hacer una copia de seguridad/restaurar en la nueva instancia y luego eliminar gradualmente las variables de entorno una por una.
Lógico, quizás no, pero pensé que sería el enfoque más sensato por si acaso una variable de entorno en la instancia en ejecución es diferente/no es compatible con la nueva instancia (en ejecución = versión antigua de Discourse, nueva = última versión de Discourse).
