Estoy intentando implementar los contenedores separados, pero con una base de datos remota. He seguido estas instrucciones anteriores y el manual para configurar una base de datos PostgreSQL remota. La configuración funciona, pero me pregunto por qué hay dos referencias idénticas (bajo web_only y data) a la misma base de datos. Esto me hace pensar que estoy haciendo algo mal y que el contenedor web_only ni siquiera está usando el contenedor de datos.
env:
# asegúrate de que la localización exista en el contenedor, es posible que necesites instalarla
LANG: en_US.UTF-8
DISCOURSE_DB_USERNAME: REMOVE
DISCOURSE_DB_PASSWORD: REMOVE
DISCOURSE_DB_HOST: REMOVE.ondigitalocean.com
DISCOURSE_DB_NAME: REMOVE
DISCOURSE_DB_PORT: 25060
DISCOURSE_DB_BACKUP_PORT: 25060
Si estás utilizando una base de datos remota, no necesitas crear el contenedor de datos que contiene la base de datos. Ten en cuenta que necesitas tanto postgres como redis (por lo que es posible que necesites el contenedor de datos para eso).
No sé realmente qué entiendes por dos contenedores, pero si asumes que dos contenedores significan dos instancias separadas de Discourse, entonces estás buscando en la dirección equivocada.
Este artículo ayuda a configurar un contenedor de aplicación y base de datos separados, lo cual es útil para usuarios avanzados que buscan cierta flexibilidad.
Si deseas instalar/alojar dos sitios de Discourse en la misma máquina, tal vez debas consultar sobre la configuración multisitio de Discourse: Multisite configuration with Docker
¿Entonces, qué contenedor estaba ejecutándose? Si asumimos que era el de la aplicación, entonces no. Estás ejecutando una versión antigua de discourse-setup.
Haz un git pull antes de continuar para asegurarte de que estás utilizando la versión más reciente de discourse-setup.
Si tienes el contenedor de datos o web-only en ejecución, entonces debes verificar qué causó que el otro no se iniciara. Por lo general, el contenedor web-only falla al iniciarse porque ya hay un proceso (servidor web) ejecutándose en el puerto 80/443.
Prueba de rendimiento, como dije: ejecuté un foro independiente durante un mes. Cuando quise crear uno nuevo, se exploraron varias opciones:
Intenté ejecutar un contenedor independiente separado en el mismo servidor, pero sin éxito.
Configuración multisitio con Docker: contenedores diferentes para la web y la base de datos, como se describe en Multisite configuration with Docker, pero sin éxito.
Tu configuración de 2 contenedores, tampoco funcionó.
Si solo quieres ejecutar un segundo contenedor independiente, tendrás que modificar los archivos yml para usar un directorio y un puerto diferentes. Posiblemente también debas desactivar Let’s Encrypt.
Solo para que lo sepas, si quieres realizar pruebas de rendimiento, no deberías hacerlo en una máquina de producción. Es mejor crear un VPS separado y usarlo para las pruebas.
Intentar ejecutar dos instancias separadas de Discourse en la misma máquina puede provocar una instalación muy defectuosa, y eso no es lo ideal.
Ese comando creará contenedores de datos y web por separado solo si no existe un archivo app.yml al momento de ejecutarlo. No creará dos contenedores web.
Creo que debería haber dejado esta característica sin documentar. Y, de hecho, no ayuda moverse a una configuración de dos contenedores, así que probablemente no debería estar aquí en absoluto.
Tal vez. Es de gran ayuda y, al igual que discourse-setup, está diseñado para un propósito muy específico: una instalación nueva y muy estándar. Mis scripts de instalación lo han utilizado durante bastante tiempo. Puede ser una forma sencilla de cambiar a dos contenedores si estás dispuesto a hacer una copia de seguridad del contenedor antiguo y restaurarla en el nuevo.
Mi preocupación siempre ha sido que podría ser difícil de dar soporte, ya que personas que no lo entiendan intentarán usarlo y luego no podrán utilizar ninguna documentación, dado que “rebuild app” ya no funcionará, y saber cuándo es necesario reconstruir el contenedor de la base de datos también es complicado. Recientemente, una reconstrucción falló porque se requería Redis 4.0 y se tenía la versión 3.0. Además, también fue necesario actualizar PostgreSQL, lo que exigía seguir una secuencia de pasos, pero había que saber cuándo reconstruir el contenedor de datos y cuándo el contenedor web, y cómo cambiar la ruta de lo recomendado. Todo salió sin contratiempos… para mí, pero intentar explicarle eso a alguien que no sabe qué es bash en un foro sería frustrante para todos.
Creo que lo mejor sería mantener alto el umbral para crear una instalación no estándar, con el fin de proteger a las personas de sí mismas.