Você terá que fazer alterações manualmente para fazê-lo funcionar atrás do proxy reverso. Assumindo que você saiba como fazer isso e o faça depois de criar o app.yml com
Isso pode funcionar:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Em seguida, você editará o app.yml para ficar atrás do proxy reverso.
Recebendo avisos de conteúdo misto quando o discourse está escutando em um socket unix. Instalação nova.
Se bem me lembro, esse é o logo em cache (presumo que você tenha ativado o parâmetro force https). Você poderia verificar na aba de rede/ferramentas de desenvolvedor do navegador?
Por favor, marque isso como resolvido. Tive que forçar a configuração https e (também fazer uma busca e substituição com rake para adicionar o caminho do subdiretório). O principal está executando o Apache junto com muitos outros sites. Para este exemplo.org, temos o WordPress instalado e fazendo proxy reverso do Apache para /forums com o Discourse ouvindo em um websocket.
Em vez do método do @riking no topo?
Você tem um link para um tutorial sobre como fazer isso do jeito “NGINX duplo”?
Infelizmente, não sei nada sobre NGINX, mas o tutorial do @riking parece simples o suficiente, mas se houver uma maneira melhor, agradeceria os detalhes sobre isso.
Olá!\nInstalamos o Discourse clonando arquivos do repositório Git e fizemos o que você sugeriu; mas lidamos com o protocolo SSL usando o Nginx proxy manager (Comentamos a parte de exposição da porta 443 no app.yml).\nEstamos usando o portainer v2.11.0 no qual podemos ver o contêiner Discourse que foi criado com sucesso, mas não conseguimos executar o site e recebemos um erro 502 bad gateway.\n\nAlguma ideia de como podemos corrigir o erro?
Você também removeu os certificados ssl e lets encrypt?
Veja:
Você usa instalação de socket como esta:
Então veja: Como depurar uma instalação do Discourse em subpasta
Não seria razoável configurar o proxy externo para se conectar diretamente ao Discourse em vez do proxy Nginx dentro do contêiner (tendo tudo com proxy duplo)? Ou o proxy Nginx interno atende a uma tarefa importante que um proxy externo não pode lidar?
Olá, o que posso fazer se não houver o arquivo nginx.sock?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
Você incluiu o modelo?
Estou tentando instalar o Discourse no meu Raspberry Pi 4 usando o sistema operacional Dietpi e alguns aplicativos que funcionam com nginx, como o Nextcloud. Estou tentando usar o serviço Cloudflared como um túnel, mas após a conclusão da instalação do Discourse, não consigo encontrar a porta de serviço do Discourse para criar um túnel. Quando me conecto a localhost, a página inicial do Nginx aparece. Onde acesso o site do Discourse?
FYI: Não configurei o certbot porque quero usar o serviço Cloudflared.
Olá, estou tentando instalar o Discourse atrás do GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen, mas não consigo descobrir como fazer isso.
Tentei expor o socket do Discourse para o container nginx-proxy e adicionar uma configuração de localização por virtual host sem sucesso.
Consegui configurar outros serviços atrás desse proxy e só me falta o Discourse. Você teria algum conselho, por favor?
Por curiosidade, quais são os prós e contras entre as duas abordagens a seguir?
Por algumas razões, consigo iniciar o NGINX e servir páginas e iniciar o Discourse sem o NGINX sem problemas. Mas quando uso a primeira abordagem, sempre recebo os seguintes erros.
/var/discourse/shared/web-only/log/rails/production.log
Job exception: Error connecting to Redis on data:6379 (Redis::TimeoutError)
/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Failed to report error: Error connecting to Redis on data:6379 (Redis::TimeoutError) 3 heartbeat: Error connecting to Redis on data:6379
E quando uso a segunda abordagem, nem sequer compila ao executar ./launcher rebuild <app>. Ele me dá um erro como:
I, [2022-09-12T08:54:16.483648 #1] INFO -- : cd /var/www/discourse & git fetch --depth 1 origin tests-passed
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve 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 failed with return #<Process::Status: pid 35 exit 128>
digite ou cole o código aqui
Você está usando um contêiner web_only mas não está executando um contêiner de dados?
Eu não, obrigado.
Modifiquei meu app.yml para que o contêiner do Discourse rode na mesma rede nomeada do meu proxy.
Em seguida, adicionei a configuração _location conforme recomendado pela documentação do nginx-proxy com os valores deste tópico, e tornei o socket do Discourse acessível (no mesmo caminho do host para simplificar).
No entanto, parece haver um problema de permissão em algum lugar, mas não sei qual é: a configuração é capturada pelo nginx, então, ao fazer uma requisição https, recebo este erro:
[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 do contêiner:
# 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 foi um problema devido a contêineres iniciados com e sem sudo.
No entanto, agora tenho isto:
[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>"
e um erro 502 bad gateway.
Na verdade, ambos. Consigo ver ambos em execução ao usar docker ps. Literalmente, a única diferença é habilitar ou desabilitar a seção expose, embora agora que penso sobre isso, me pergunto se preciso comentar a linha expose: também e não a lista de portas dentro dela.
Desculpe pelo post duplo, fiquei confuso anteriormente com outro assunto não relacionado e o socket não estava mais sendo usado devido a um erro na minha configuração.
Aqui está onde estou:
[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>"
Eu fiz chmod 777 shared/standalone/nginx.http.sock para contornar temporariamente esse problema de permissão, e agora recebi:
[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, estou fazendo algumas coisas erradas, mas não sei o quê. Por favor, note que não estou usando NPM, mas sim nginx-proxy, que é um pouco diferente, em particular, ele detecta automaticamente contêineres Docker que definem VIRTUAL_HOST para gerar uma configuração para eles. Portanto, adicionei apenas a parte location / { ... } relacionada ao Discourse e não toquei nos arquivos sites-available com as diretivas listen.
Notei que o contêiner do Discourse está em um loop de reinicialização com o status Restarting (100) 7 seconds ago. Isso ocorre porque ele reclama por não conseguir excluir o socket. De fato, não era um socket real, mas um diretório, suponho que devido a manipulações ruins de montagem de volumes para expô-lo ao contêiner nginx-proxy.
Removi o diretório, reiniciei o Discourse e agora é um socket. No entanto, não consigo expô-lo como um volume para o 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.
Acontece que eu só precisava montar o socket em /tmp/nginx.http.sock em vez de manter o mesmo caminho. Finalmente consegui, parece!
Encontrei o problema de por que expor uma porta em /var/discourse/containers/web_only.yml da seguinte forma não estava funcionando.
expose:
# - "443:443"
# - "80:80"
- "8080:80" # https
De acordo com Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All , foi o SELinux que estava em ação e era necessário permitir que o NGINX acessasse o Discourse executando ou definindo o SELinux em modo Permissivo.
setsebool -P httpd_can_network_connect 1
Agora, o interessante é que, se a configuração do NGINX estiver definida para o caminho raiz, está funcionando bem, mas não quando está definida para um caminho não raiz.
NGINX configurado para encaminhar / para Discourse (funcionando)
# 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 encaminhar /discussions/ para Discourse (não funcionando)
# 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;
}
Neste caso, estou vendo o seguinte… Minha intuição é que, embora o NGINX tenha encaminhado com sucesso o caminho não raiz /discussions/ para o docker do Discourse, o próprio Discourse ainda está carregando páginas de si mesmo e esperando que os ativos estejam no caminho raiz /. Acho que é um requisito executar o Discourse apenas no caminho raiz? @pfaffman você já viu isso 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"
