Ahora he instalado Discourse en 2 máquinas virtuales diferentes.
Estoy siguiendo las instrucciones oficiales de instalación.
Una ejecutándose en Debian 12 en una instancia de VMWare Fusion en un Mac Pro, la otra en Ubuntu 24 en una VM que funciona en TrueNAS.
Ambas están en servidores dedicados que corren en mi red local, con redes puente y tienen direcciones IP accesibles e únicas.
El servidor de TN aloja varias otras aplicaciones en contenedores Docker y todas funcionan y son accesibles vía LAN e Internet, el Mac Pro alberga de forma nativa una wiki.
En ambas, la función de bootstrap se completa, pero no obtengo un sitio funcionando. Sólo aparece ‘el servidor no responde’ en el navegador.
Según docker ps el contenedor “app” está activo y corriendo, escuchando en los puertos 80 y 443, ufw informa que está permitiendo esos puertos.
Durante un tiempo, el sitio en Debian mostraba una página de bienvenida predeterminada de nginx, pero ahora eso ya no responde también.
No soy ningún tipo de desarrollador o mago web, así que no sé cómo solucionar los problemas, consulté a Grok para pedir ayuda, pero hasta ahora nada ha funcionado.
Tengo una dirección IP estática pública y un nombre de dominio que apunta a esa dirección.
Generalmente uso un registro A comodín para dirigir cualquier host a esa IP, pero en mi resolución de problemas encontré una publicación que decía que Discourse puede no funcionar bien con direcciones proxy en Cloudflare DNS, así que creé un registro A dedicado y desactivé el proxy para ese.
¿Estoy usando correctamente el término ‘función de arranque’?
Solo quiero asegurarme de que estamos hablando de lo mismo.
./discourse-setup ES el arranque, ¿verdad?
Entonces, si digo que se arranca, y el contenedor está en ejecución, entonces la prueba de conexión, que sucede al principio de la configuración, ha pasado.
Bueno, más o menos. Crea un app.yml y luego ejecuta ./launcher bootstrap app.
Si lo has ejecutado un montón de veces sin que DNS funcionara correctamente, entonces has alcanzado los límites de tasa con Let’s Encrypt. Las soluciones fáciles son esperar una semana o usar un nombre de dominio diferente.
¿Y no hay nada más ejecutándose en esa máquina?
¿Y cuando ejecutaste discourse-setup no se quejó de no poder conectarse a sí mismo?
Solo lo he ejecutado una vez en cada VM y he usado un nombre de host diferente para cada una.
VM nuevas sin nada más ejecutándose en ellas. En el hardware real hay otras cosas ejecutándose. Pero tienen direcciones IP internas separadas de sus hosts.
Aquí están los errores que encontré en la salida de la instalación, ninguno parece ser un obstáculo:
690:M 30 abr 2025 22:05:22.859 # Advertencia: No se pudo crear el socket de escucha TCP del servidor *:6379: bind: Address already in use
690:M 30 abr 2025 22:05:22.859 # Falló escuchar en el puerto 6379 (TCP), abortando.
109:M 30 abr 2025 21:59:42.411 # ADVERTENCIA La sobreasignación de memoria debe estar habilitada! Sin ella, una guardado en segundo plano o replicación puede fallar bajo condiciones de poca memoria...
30 abr 2025 21:59:41.125 UTC [60] postgres@postgres ERROR: la base de datos "discourse" ya existe
30 abr 2025 21:59:41.274 UTC [63] postgres@discourse ERROR: el rol "discourse" ya existe
AVISO: Especificaciones no resueltas o ambiguas durante Gem::Specification.reset:
stringio (>= 0)
Versiones disponibles/instaladas de esta gema:
- 3.1.7
- 3.1.5
- 3.1.1
AVISO: Limpiando especificaciones no resueltas. Intenta `gem cleanup gem`
Por favor, reporta un error si esto causa problemas.
La configuración 'staticAddonTrees' será predeterminada a true en la próxima versión de Embroider y no se podrá desactivar. Para prepararse, debes establecer 'staticAddonTrees: true' en tu configuración de Embroider.
La configuración 'staticAddonTestSupportTrees' será predeterminada a true en la próxima versión de Embroider y no se podrá desactivar. Para prepararse, debes establecer 'staticAddonTestSupportTrees: true' en tu configuración de Embroider.
El límite de tamaño de pila de Node.js es menor a 2048MB. Configurando --max-old-space-size=2048 y CHEAP_SOURCE_MAPS=1
-e DISCOURSE_SMTP_DOMAIN=discourse.example.com
[ELIDADO] Nota: El generador de código ha desoptimizado el estilo del archivo /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js ya que excede los 500KB.
[ELIDADO] Nota: El generador de código ha desoptimizado el estilo del archivo /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js ya que excede los 500KB.
No estaba pensando en el hecho de que, dado que el puerto 80 ya está en uso y solo tengo una IP externa, aunque la verificación del dominio pasaba durante el proceso de configuración, tuve que modificar los puertos del lado del host para que las cosas funcionaran.
Estoy usando NPM internamente.
Pasos para que funcione:
Cambiar el puerto del lado del host a 7080 para http
Como pasaré tráfico a través de mi gestor de proxy, facilité mi vida y deshabilité los scripts de LE
Actualicé la aplicación
Pasé ‘ext IP:80’ a ‘int IP:7080’ en el proxy inverso, luego el contenedor invirtió los puertos… luego hicieron el Hokey Pokey y se dieron vuelta.