Hola. Actualicé Discourse Image y Discourse hace unas horas usando ./launcher rebuild app. En el proceso, obtuve algunos errores que se solucionaron eliminando las líneas de instalación de plugins obsoletos de app.yml. No se realizaron otros cambios de configuración. Ahora tengo un contenedor Docker en ejecución que escucha en los puertos TCP 80 y 443, pero nginx dentro del contenedor se niega a aceptar conexiones SSL/TLS. El archivo error.log dentro del contenedor no muestra errores con los certificados, access.log no muestra solicitudes, telnet al puerto 443 muestra rechazo de conexión, el acceso HTTP en el puerto TCP 80 funciona, pero tenemos problemas de autenticación SSO (probablemente sea un problema con las cookies seguras). El reinicio del lanzador y discourse-doctor no ayudan. Reiniciar nginx dentro del contenedor tampoco ayuda. ¿Dónde mirar ahora y qué hacer?
lo hará si ufw está habilitado y no está configurado para permitir conexiones en el puerto https 443
Editar: necesitarás que este puerto esté abierto para que mail-receiver funcione correctamente
No hice nada con la configuración de ufw, iptables, etc. El puerto se abrió exactamente antes de la actualización. ¿Podría la configuración haber cambiado con el proceso de actualización de Discourse?
Absolutamente podría, el contenedor Docker de Discourse debería interponerse ante ufw. Sin embargo, no tener el puerto 443 abierto causa problemas en la comunicación entre diferentes contenedores o problemas con telnet.
¿Qué devuelve .\launcher logs app? (puedes usar MS Word para redactar tu nombre de dominio, etc.)
¿Accedes a tu servidor a través de PuTTy u otro cliente SSH? ¿abriendo el puerto 22?
También estoy viendo este problema en una instancia autoalojada después de una reconstrucción reciente. No hay cambios en la configuración, excepto la propia reconstrucción. Puedo acceder al servidor a través de SSH y esta es la salida de ./launcher logs app.
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/install-ssl
Started runsvdir, PID is 45
ok: run: redis: (pid 55) 0s
supervisor pid: 53 unicorn pid: 76
El contenedor de Docker se está ejecutando, como lo demuestra la salida de docker ps. (id de contenedor omitido)
local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp app
Una nota importante a destacar es que no usamos openSSL para nuestros certificados, debido a que requerimos un emisor específico. Sin embargo, este certificado no ha cambiado y estaba funcionando bien antes de la reconstrucción.
Parece haber una discrepancia entre la IP que espera nginx (IP local) y la que se encuentra asignada al contenedor. ¿Parece que el contenedor podría estar ejecutándose en modo bridge? Aquí están la configuración de red del contenedor.
"Labels": {
"org.opencontainers.image.created": "2025-07-25T21:40:36+00:00"
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "[REDACTED]",
"SandboxKey": "[REDACTED]",
"Ports": {
"443/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "443"
},
{
"HostIp": "::",
"HostPort": "443"
}
],
"5432/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "5432"
},
{
"HostIp": "::",
"HostPort": "5432"
}
],
"80/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "80"
},
{
"HostIp": "::",
"HostPort": "80"
}
]
},
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "[REDACTED]",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"MacAddress": "[REDACTED]",
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "[REDACTED]",
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
}
}
}
Parece que una nueva PR ha introducido un nuevo requisito de variable en app.yml. Esto aún no parece estar documentado, pero necesitas añadir ENABLE_SSL: true a tu archivo app.yml.
Eso suena a un error. SSL ha estado activado por defecto durante algunos años. ¿Puedes enlazar al commit?
Lo veo en el código en la plantilla SSL. Puede que me esté perdiendo algo ya que estoy en mi teléfono y GitHub está teniendo problemas, pero parece que romperá todos los sitios autoalojados.
Es este de aquí, definitivamente un error no intencionado al fusionar la configuración de ssl-on-boot:
He actualizado ENABLE_SSL a 1 por defecto aquí:
Gracias por la detección @tanya_byrne
¡Buen salvamento, Jeff! ¡Gracias!
Gracias por la corrección @featheredtoast
Gracias, chicos. También hemos resuelto el problema.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.