Usando una imagen de Docker construida con un launcher en docker-compose

Hola Mike. Básicamente, lo que haces es usar ./launcher bootstrap para construir la imagen, subirla a un repositorio y luego usar ./launcher start-cmd para ver qué variables de entorno (ENV) deben pasarse a Docker para arrancar todo.

La razón por la que no existe una guía así es que las personas que no tienen el conocimiento más básico de cualquiera de los componentes subyacentes la encontrarán, no podrán entenderla y luego esperarán un tutorial sobre cómo funciona el ingress en el sistema que ellos creen que es la única solución.

Llámame loco, pero tal vez eres la prueba viviente de que hacíamos las cosas así por una razón? :wink:

Gracias, Jay: ya lo había descubierto. Por fin logré que funcionara.

  • Voy a crear un video y una guía con los pasos exactos que seguí, para que la próxima vez no pierda el tiempo intentando resolver esto.

Supongo que parte del problema es que va en contra de la corriente de todas las demás imágenes de Docker disponibles. No es tan plug and play. Requiere más ajustes, conectar y luego ejecutar.

Como dije, el lanzador es una herramienta hermosa y fiable para lo que hace.

En una nota muy positiva, la versión solo web funciona de maravilla; es super rápida en mi clúster y actualizable porque tengo el servidor de compilación.

Cuando tenga tiempo, exploraré la posibilidad de montar un servidor de compilación en mi clúster que permita compilar una imagen de Docker desde el navegador.

Cosas que probé y que dejaron mucho que desear…

  • Imagen de Docker de Bitnami: funcionó como un perro sin patas.
  • Dockerfile de IndieHosts: ni siquiera llegué a la compilación; parecía decidido a construirlo todo, creo que estaba compilando Linux. ¡De nuevo, debe haber una forma más fácil!

Vale, gracias.

Mike.

¡Tenemos esa desventaja del primer movimiento :sunglasses:

El script del lanzador se creó antes de que existieran Docker Compose, Docker Swarm, Kubernetes y todo eso, y… aún funciona. Realmente no hay ninguna razón convincente para que cambiemos a otra cosa. Las “ventajas” de estos sistemas no son ventajas para el principal consumidor de Discourse autoalojado, que son las instalaciones con presupuesto en VPS en la nube.

¡Oh! Siempre me lo pregunté. Y la última vez que lo revisé, instalar docker-compose en Ubuntu requería un paso adicional. Es como si no quisieran que la gente lo usara, a menos que esas personas usen Windows (¿o Mac?).

Es un poco triste escuchar esto como respuesta oficial del equipo de desarrollo. Básicamente están diciendo que si no eres lo suficientemente bueno para entender este proceso no documentado de ejecutar Discourse en producción, entonces quizás no deberías estar ejecutando Discourse en producción.

Bueno, no todos tenemos una amplia experiencia en DevOps, lamentablemente.

@Mike_Sutton Estoy de acuerdo contigo. He estado leyendo los foros durante las últimas semanas tratando de descifrar este asunto. ¿Lograste hacer un video sobre cómo solucionaste el problema?

¿Eso funcionaría? ¿Y qué pasa con las migraciones de la base de datos?

En este escenario, usarías bootstrap para realizar las migraciones mientras se construye la nueva imagen del contenedor.

Hola @lucasbasquerotto

Sí, puedes subir las imágenes de Docker de Discourse a un repositorio y archivar el resto de /var/discourse como se describe en la discusión a continuación, pero no es un método eficiente y no está oficialmente soportado. Recientemente lo probé completamente:

Pero en este caso, el paso de bootstrap debe realizarse en la máquina de producción, lo que, si no me equivoco, anula el propósito de subir una imagen base a un registro de contenedores (ya que esto se haría con la intención de no tener que ejecutar bootstrap en producción, excepto quizás para ejecutar un paso de migración de la base de datos o algo similar).

Esto es lo que hago en sitios que no son Discourse que alojo: normalmente uso Flyway para ejecutar migraciones en la base de datos, junto con otras tareas como vaciar la caché de Redis, pero sin ejecutar otros procesos intensivos, especialmente aquellos que dependen de servicios externos, como la actualización de certificados HTTPS (lo haría en un cronjob, excepto la primera vez, lo cual está bien) o cambios en la base de código (esto sería estático en la imagen, como paquetes, bibliotecas y otras cosas). Parece que Discourse usa Rake, lo cual está bien, pero también hace otras cosas como instalar gemas, generar activos, actualizar la base de datos de MaxMind y quizás otros servicios (lo cual podría romper el paso de reconstrucción si, por ejemplo, el servicio está caído o si cambian la API, lo cual es raro pero podría suceder).

No estoy diciendo que Discourse deba hacerlo así, por supuesto, pero generar una imagen en un entorno de CI y simplemente ejecutar un paso de migración de la base de datos en servidores de staging/producción, junto con la definición de las variables de entorno, es lo que esperaría, y es fácilmente alcanzable con otros softwares como WordPress, MediaWiki, Rocket.Chat, etc. Discourse es el mejor software para foros, en mi opinión, y pueden tener buenas razones para hacerlo de la manera que lo hacen, pero por ahora solo usaría la instalación estándar (o la instalación multicontenedor) para evitar dolores de cabeza y simplemente esperar que nada salga mal con las reconstrucciones.

Parece que el bootstrap aún debería realizarse en un entorno de producción y no en un entorno de CI para generar una imagen base que se use tanto en staging como en producción. Además, no ser una instalación estándar es una gran bandera roja, que puede convertirse en un dolor de cabeza en el futuro a medida que el software reciba actualizaciones.

Hola Mike,

¿Llegaste a documentar tu proceso al final? ¿Sería genial ver el video también?

Saludos,