Tendrás que hacer cambios a mano para que funcione detrás del proxy inverso. Suponiendo que sabes cómo hacerlo y lo haces después de crear el app.yml con
Esto podría funcionar:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Luego editarías app.yml para que esté detrás del proxy inverso.
Advertencias de contenido mixto al escuchar discourse en un socket unix. Instalación nueva.
Si mal no recuerdo, ese es el logo en caché (supongo que tienes habilitado el parámetro force https). ¿Podrías comprobarlo en la pestaña de red/herramientas de desarrollador del navegador?
Por favor, marque esto como resuelto. Tuve que forzar la configuración de https y (también hacer un reemplazo de búsqueda de rake para agregar la ruta del subdirectorio). El principal está ejecutando Apache junto con muchos otros sitios. Para este ejemplo.org, tenemos WordPress instalado y estamos haciendo un proxy inverso de Apache para /forums con Discourse escuchando en un websocket.
¿En lugar del método de @riking en la parte superior?
¿Tienes un enlace a un tutorial sobre cómo hacerlo de la manera “doble NGINX”?
Lamentablemente, no sé nada de NGINX, pero el tutorial de @riking parece lo suficientemente simple, pero si hay una mejor manera, agradecería los detalles al respecto.
¡Hola!
Instalamos Discourse clonando archivos del repositorio Git e hicimos lo que sugeriste; pero manejamos el protocolo SSL usando Nginx proxy manager (comentamos la parte de exposición del puerto 443 en app.yml).
Estamos usando portainer v2.11.0 en el que podemos ver el contenedor de Discourse que se creó con éxito, pero no podemos ejecutar el sitio web y recibimos un error de 502 bad gateway.
¿Alguna idea de cómo podemos solucionar el error?
¿También eliminaste los certificados SSL y Let’s Encrypt?
Ver:
¿Utiliza la instalación de socket como esta?
Entonces vea: Cómo depurar una instalación de Discourse en subcarpeta
¿No sería razonable configurar el proxy externo para conectarse directamente a Discourse en lugar del proxy Nginx dentro del contenedor (teniendo todo doblemente proxificado)? ¿O el proxy Nginx interno cumple una tarea importante que un proxy externo no puede manejar?
Hola, ¿qué puedo hacer si no existe el archivo nginx.sock?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
¿Incluiste la plantilla?
Estoy intentando instalar Discourse en mi Raspberry Pi 4 usando Dietpi OS y algunas aplicaciones que funcionan con nginx como Nextcloud. Estoy intentando usar el servicio Cloudflared como un túnel, pero después de que la instalación de Discourse se completa, no puedo encontrar el puerto del servicio de Discourse para crear un túnel. Cuando me conecto a localhost, aparece la página de inicio de Nginx. ¿Dónde accedo al sitio de Discourse?
PD: No he configurado certbot porque quiero usar el servicio Cloudflared.
Hola, estoy intentando instalar Discourse detrás de GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen pero no puedo averiguar cómo hacerlo.
Intenté exponer el socket de Discourse al contenedor nginx-proxy y agregar una configuración de ubicación por host virtual sin éxito.
He configurado con éxito otros servicios detrás de ese proxy y solo me falta Discourse. ¿Tendrías algún consejo, por favor?
Por curiosidad, ¿cuáles son los pros y los contras entre los dos enfoques siguientes?
Por alguna razón, puedo iniciar NGINX y servir páginas e iniciar Discourse sin NGINX sin problemas. Pero cuando uso el primer enfoque, siempre obtengo los siguientes errores.
/var/discourse/shared/web-only/log/rails/production.log
Excepción del trabajo: Error al conectar con Redis en data:6379 (Redis::TimeoutError)
/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Error al informar del error: Error al conectar con Redis en data:6379 (Redis::TimeoutError) 3 latido: Error al conectar con Redis en data:6379
Y cuando uso el segundo enfoque, ni siquiera se compila al ejecutar ./launcher rebuild <app>. Me daría un error como:
I, [2022-09-12T08:54:16.483648 #1] INFO -- : cd /var/www/discourse & git fetch --depth 1 origin tests-passed
fatal: no se puede acceder a 'https://github.com/discourse/discourse.git/': No se puede resolver el host: github.com
I, [2022-09-12T08:54:56.561225 #1] INFO -- :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & git fetch --depth 1 origin tests-passed falló con retorno #<Process::Status: pid 35 exit 128>
escribe o pega el código aquí
¿Estás usando un contenedor web_only pero no estás ejecutando un contenedor de datos?
No, gracias.
Modifiqué mi app.yml para que el contenedor de Discourse se ejecute en la misma red con el mismo nombre que mi proxy.
Luego agregué la configuración de _location como se indica en la documentación de nginx-proxy con los valores de este hilo, y expuse el socket de Discourse (en la misma ruta que el host por simplicidad).
Sin embargo, parece que hay un problema de permisos en algún lugar, pero no estoy seguro de cuál es: la configuración es captada por nginx, luego, al hacer una solicitud https, obtengo este error
[crit] 230#230: *21 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: <ip>, server: <domain>, request: "GET / HTTP/1.1", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Dentro del contenedor:
# ls -lah /var/discourse/shared/standalone/
total 12K
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 .
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 ..
drwxr-xr-x 2 root root 4.0K Sep 12 09:19 nginx.http.sock
Editar: este fue un problema debido a contenedores iniciados con y sin sudo.
Sin embargo, ahora tengo esto:
[error] 219#219: *94 no live upstreams while connecting to upstream, client: <client-ip>, server: <domain>, request: "HEAD / HTTP/2.0", upstream: "http://<domain>/", host: "<domain>", referrer: "http://<domain>"
y un error 502 bad gateway
En realidad, ambos. Puedo ver ambos ejecutándose cuando uso docker ps. Literalmente, la única diferencia es habilitar o deshabilitar la sección expose, aunque ahora que lo pienso, me pregunto si también necesito comentar la línea expose: y no la lista de puertos dentro de ella.
Disculpa la doble publicación, anteriormente me confundí con otro asunto no relacionado y el socket ya no se usaba debido a un error en mi configuración.
Aquí es donde estoy:
[crit] 274#274: *7 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Ejecuté chmod 777 shared/standalone/nginx.http.sock para solucionar temporalmente este problema de permisos, y ahora obtengo:
[error] 203#203: *1 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Obviamente estoy haciendo algunas cosas mal, pero no sé qué. Tenga en cuenta que no estoy usando NPM sino nginx-proxy, que es un poco diferente, en particular detecta automáticamente los contenedores de Docker que definen VIRTUAL_HOST para generar una configuración para ellos. Por lo tanto, solo agregué la parte location / { ... } relacionada con discourse y no toqué los archivos sites-available con las directivas listen.
Noté que el contenedor de discourse está en un bucle de reinicio con el estado Restarting (100) 7 seconds ago. Esto se debe a que se queja de no poder eliminar el socket. De hecho, no era un socket real sino un directorio, supongo que debido a malas manipulaciones al montar volúmenes para exponerlo al contenedor nginx-proxy.
Eliminé el directorio, reinicié discourse y ahora es un socket. Sin embargo, no puedo exponerlo como un volumen a nginx-proxy.
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting “/var/discourse/shared/standalone/nginx.http.sock” to rootfs at “/var/discourse/shared/standalone/nginx.http.sock”: mount /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
Resulta que solo necesitaba montar el socket en /tmp/nginx.http.sock en lugar de mantener la misma ruta. ¡Finalmente lo logré, parece!
Se encontró el problema de por qué exponer un puerto en /var/discourse/containers/web_only.yml de la siguiente manera no funcionaba.
expose:
# - "443:443"
# - "80:80"
- "8080:80" # https
Según Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All , era SELinux el que estaba en juego y era necesario permitir que NGINX accediera a Discourse ejecutando o configurando SELinux en modo Permisivo.
setsebool -P httpd_can_network_connect 1
Ahora, lo interesante es que si la configuración de NGINX se establece en la ruta raíz, funciona bien, pero no cuando se establece en una ruta no raíz.
NGINX configurado para reenviar / a Discourse (funciona)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
NGINX configurado para reenviar /discussions/ a Discourse (no funciona)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location /discussions/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
En este caso, estoy viendo lo siguiente… Mi instinto me dice que, aunque NGINX haya reenviado con éxito la ruta no raíz /discussions/ al docker de Discourse, el propio Discourse sigue cargando páginas de sí mismo y esperando que los activos estén en la ruta raíz /. ¿Supongo que es un requisito ejecutar Discourse solo en la ruta raíz? @pfaffman ¿has visto esto antes?
/var/log/nginx/example.com.error.log
2022/10/01 09:33:23 [error] 1954781#1954781: *1 open() "/etc/nginx/html/images/discourse-logo-sketch.png" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /images/discourse-logo-sketch.png HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/discussions/"
2022/10/01 09:33:25 [error] 1954781#1954781: *1 open() "/etc/nginx/html/service-worker.js" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /service-worker.js HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/service-worker.js"
