Dovrai apportare modifiche manuali per farlo funzionare dietro il reverse proxy. Supponendo che tu sappia come farlo e che lo farai dopo aver creato app.yml con
Questo potrebbe funzionare:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Quindi modificheresti app.yml per metterlo dietro il reverse proxy.
Ricezione di avvisi di contenuto misto quando discourse è in ascolto su un socket unix. Installazione pulita.
Se non ricordo male, quello è il logo memorizzato nella cache (presumo che tu abbia abilitato il parametro force https). Potresti controllarlo nella scheda dev tool/network del browser?
Per favore, contrassegna questo come risolto. Ho dovuto forzare l’impostazione https e (anche eseguire una ricerca e sostituzione rake per aggiungere il percorso della sottodirectory). Il principale sta eseguendo Apache insieme a molti altri siti. Per questo esempio.org abbiamo installato WordPress e stiamo facendo da proxy inverso Apache per /forums con Discourse in ascolto su un websocket.
Invece del metodo di @riking in cima?
Hai un link a una guida su come farlo nel modo “doppio NGNIX”?
Purtroppo, non so nulla di NGINX, ma la guida di @riking sembra abbastanza semplice, ma se c’è un modo migliore, apprezzerei i dettagli a riguardo.
Ciao!\nAbbiamo installato Discourse clonando i file dal repository Git e fatto come hai suggerito; ma abbiamo gestito il protocollo SSL utilizzando Nginx proxy manager (abbiamo commentato la parte di esposizione della porta 443 in app.yml).\nStiamo usando portainer v2.11.0 in cui possiamo vedere il container Discourse che è stato creato con successo ma non riusciamo ad eseguire il sito web e riceviamo un errore 502 bad gateway.\n\nQualche idea su come possiamo risolvere l’errore?
Hai rimosso anche i certificati SSL e Let’s Encrypt?
Vedi:
Utilizzi l’installazione socket come questa:
Quindi vedi: Come eseguire il debug di un’installazione di Discourse in una sottocartella
Non sarebbe ragionevole configurare il proxy esterno per connettersi direttamente a Discourse anziché al proxy Nginx all’interno del container (avendo tutto in doppio proxy)? Oppure il proxy Nginx interno svolge un compito importante che un proxy esterno non può gestire?
Ciao, cosa posso fare se non c’è il file nginx.sock?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
Hai incluso il template?
Sto cercando di installare Discourse sul mio Raspberry Pi 4 utilizzando Dietpi OS e alcune app che funzionano con nginx come Nextcloud. Sto cercando di utilizzare il servizio Cloudflared come tunnel, ma dopo che l’installazione di Discourse è completa non riesco a trovare la porta del servizio Discourse per creare un tunnel. Quando mi connetto a localhost, compare la pagina di avvio di Nginx. Dove accedo al sito di Discourse?
P.S.: Non ho configurato certbot perché voglio usare il servizio Cloudflared.
Ciao, sto cercando di installare Discourse dietro GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen ma non riesco a capire come fare.
Ho provato a esporre il socket di Discourse al container nginx-proxy e ad aggiungere una configurazione per posizione per dominio virtuale senza successo.
Ho configurato con successo altri servizi dietro quel proxy e mi manca solo Discourse. Avresti qualche consiglio per favore?
Per curiosità, quali sono i pro e i contro tra i seguenti due approcci?
Per qualche motivo, riesco ad avviare NGINX e servire pagine e avviare Discourse senza NGINX senza problemi. Ma quando uso il primo approccio, ottengo sempre i seguenti errori.
/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 il secondo approccio, non si costruisce nemmeno quando eseguo ./launcher rebuild <app>. Mi darebbe un errore come:
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>
digita o incolla il codice qui
Stai usando un container web_only ma non stai eseguendo un container dati?
Non l’ho fatto, grazie.
Ho modificato il mio app.yml in modo che il container di discourse venga eseguito nella stessa rete denominata del mio proxy.
Quindi ho aggiunto la configurazione _location come consigliato dalla documentazione di nginx-proxy con i valori di questo thread e ho reso disponibile il socket di discourse (allo stesso percorso dell’host per semplicità).
Tuttavia sembra esserci un problema di permessi da qualche parte ma non so bene quale: la configurazione viene rilevata da nginx, poi quando faccio una richiesta https ho questo errore
[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>"
All’interno del container:
# 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
Modifica: questo era un problema dovuto a container avviati con e senza sudo.
Tuttavia ora ho questo:
[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 un errore 502 bad gateway
In realtà entrambi. Riesco a vederli entrambi in esecuzione quando uso docker ps. Letteralmente l’unica differenza è l’abilitazione o la disabilitazione della sezione expose, anche se ora che ci penso mi chiedo se devo anche commentare la riga expose: e non l’elenco delle porte al suo interno.
Mi dispiace per il doppio post, in precedenza ero confuso da un’altra questione non correlata e il socket non veniva più utilizzato a causa di un errore nella mia configurazione.
Ecco dove sono arrivato:
[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>"
Ho eseguito chmod 777 shared/standalone/nginx.http.sock per aggirare temporaneamente questo problema di permessi, e ora ho ottenuto:
[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>"
Ovviamente sto facendo delle cose sbagliate ma non so cosa. Si noti che non sto usando NPM ma nginx-proxy che è un po’ diverso, in particolare rileva automaticamente i container docker che definiscono VIRTUAL_HOST per generare una configurazione per loro. Pertanto ho aggiunto solo la parte location / { ... } relativa a discourse e non ho toccato i file sites-available con le direttive listen.
Ho notato che il container discourse è in un loop di riavvio con stato Restarting (100) 7 seconds ago. Questo perché si lamenta di non poter eliminare il socket. Infatti, non era un vero socket ma una directory, immagino a causa di manipolazioni errate nel montaggio dei volumi per esporlo al container nginx-proxy.
Ho rimosso la directory, riavviato discourse e ora è un socket. Tuttavia non riesco a esporlo come volume 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
A quanto pare, dovevo solo montare il socket in /tmp/nginx.http.sock invece di mantenere lo stesso percorso. Finalmente sembra che ci sia riuscito!
Trovato il problema del perché l’esposizione di una porta in /var/discourse/containers/web_only.yml come segue non funzionava.
exponi:
# - "443:443"
# - "80:80"
- "8080:80" # https
Secondo Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All era SELinux ad essere in gioco e bisognava permettere a NGINX di accedere a Discourse eseguendo o impostando SELinux in modalità Permissive.
setsebool -P httpd_can_network_connect 1
Ora, ciò che è interessante è che se la configurazione di NGINX è impostata sul percorso root funziona bene, ma non quando è impostata su un percorso non root.
NGINX impostato per inoltrare / a Discourse (funzionante)
# 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 impostato per inoltrare /discussions/ a Discourse (non funzionante)
# 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;
}
In questo caso vedo quanto segue… La mia sensazione è che anche se NGINX ha inoltrato con successo il percorso non root /discussions/ al docker di Discourse, Discourse stesso sta ancora caricando le pagine da sé e si aspetta che gli asset siano nel percorso root /. Immagino sia un requisito eseguire Discourse solo nel percorso root? @pfaffman hai già visto questo?
/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"
