Vous devrez apporter des modifications manuelles pour le faire fonctionner derrière le proxy inverse. En supposant que vous sachiez comment faire et que vous le fassiez après avoir créé le fichier app.yml avec
Cela pourrait fonctionner :
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Ensuite, vous modifierez app.yml pour qu’il se trouve derrière le proxy inverse.
Avertissements de contenu mixte lors de l’écoute de discourse sur une socket Unix. Nouvelle installation.
Si je me souviens bien, c’est le logo mis en cache (je suppose que vous avez activé le paramètre force https). Pourriez-vous vérifier cela dans l’onglet réseau des outils de développement du navigateur ?
Veuillez marquer ceci comme résolu. J’ai dû forcer le paramètre https et (également effectuer une recherche et un remplacement rake pour ajouter le chemin du sous-répertoire). Le principal exécute Apache ainsi que de nombreux autres sites. Pour cet exemple.org, nous avons WordPress installé et faisons un proxy inverse Apache pour /forums avec Discourse écoutant sur un websocket.
Au lieu de la méthode de @riking en haut ?
Avez-vous un lien vers un tutoriel sur la façon de le faire de la manière « double NGINX » ?
Malheureusement, je ne connais rien à NGINX, mais le tutoriel de @riking semble assez simple, mais s’il existe une meilleure façon, j’apprécierais les détails à ce sujet.
Salut !
Nous avons installé Discourse en clonant les fichiers du dépôt Git et avons fait ce que vous avez suggéré ; mais nous avons géré le protocole SSL à l’aide de Nginx proxy manager (nous avons commenté la partie d’exposition du port 443 dans app.yml).
Nous utilisons Portainer v2.11.0 dans lequel nous pouvons voir le conteneur Discourse qui est créé avec succès, mais nous ne pouvons pas exécuter le site Web et recevons une erreur 502 Bad Gateway.
Une idée sur la façon dont nous pouvons corriger l’erreur ?
Avez-vous également supprimé les certificats ssl et lets encrypt ?
Voir :
Utilisez-vous une installation de socket comme celle-ci :
Alors regardez : Comment déboguer une installation Discourse dans un sous-dossier
Ne serait-il pas raisonnable de configurer le proxy externe pour se connecter directement à Discourse plutôt qu’au proxy Nginx à l’intérieur du conteneur (ce qui entraîne un double proxy) ? Ou le proxy Nginx interne remplit-il une tâche importante qu’un proxy externe ne peut pas gérer ?
Bonjour, que puis-je faire s’il n’y a pas de fichier nginx.sock ?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
Avez-vous inclus le modèle ?
J’essaie d’installer Discourse sur mon Raspberry Pi 4 en utilisant Dietpi OS et certaines applications fonctionnant avec nginx comme Nextcloud. J’essaie d’utiliser le service Cloudflared comme tunnel, mais une fois l’installation de Discourse terminée, je ne trouve pas le port du service Discourse pour créer un tunnel. Lorsque je me connecte à localhost, la page de démarrage de Nginx s’affiche. Où puis-je accéder au site Discourse ?
Pour information : je n’ai pas configuré certbot car je veux utiliser le service Cloudflared.
Bonjour, j’essaie d’installer Discourse derrière GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen mais je n’arrive pas à comprendre comment faire.
J’ai essayé d’exposer le socket de Discourse au conteneur nginx-proxy et d’ajouter une configuration de localisation par hôte virtuel sans succès.
J’ai réussi à configurer d’autres services derrière ce proxy et il ne me manque que Discourse. Auriez-vous des conseils s’il vous plaît ?
Avez-vous consulté Utiliser Nginx Proxy Manager pour gérer plusieurs sites avec Discourse ?
Par curiosité, quels sont les avantages et les inconvénients des deux approches suivantes ?
Pour certaines raisons, je peux démarrer NGINX et servir des pages, et démarrer Discourse sans NGINX sans problème. Mais lorsque j’utilise la première approche, j’obtiens toujours les erreurs suivantes.
/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
Et lorsque j’utilise la deuxième approche, cela ne compile même pas lors de l’exécution de ./launcher rebuild <app>. Cela me donne une erreur comme :
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>
tapez ou collez le code ici
Utilisez-vous un conteneur web_only sans exécuter de conteneur de données ?
Je n’ai pas, merci.
J’ai modifié mon app.yml pour que le conteneur discourse s’exécute dans le même réseau nommé que mon proxy.
Ensuite, j’ai ajouté la configuration _location comme conseillé par la documentation nginx-proxy avec les valeurs de ce fil, et j’ai rendu le socket discourse accessible (au même chemin que l’hôte pour simplifier).
Cependant, il semble y avoir un problème de permissions quelque part, mais je ne sais pas vraiment quoi : la configuration est prise en compte par nginx, puis lors d’une requête https, j’ai cette erreur
[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>"
À l’intérieur du conteneur :
# 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
Edit : c’était un problème dû au démarrage de conteneurs avec et sans sudo.
Cependant, j’ai maintenant ceci :
[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>"
et une erreur 502 bad gateway
En fait, les deux. Je peux voir les deux en cours d’exécution lorsque j’utilise docker ps. Littéralement, la seule différence est d’activer ou de désactiver la section expose, bien que maintenant que j’y pense, je me demande si je dois également commenter la ligne expose: et non la liste des ports qu’elle contient.
Désolé pour le double post, j’ai été confus précédemment par une autre affaire sans rapport et la socket n’était plus utilisée en raison d’une erreur dans ma configuration.
Voici où j’en suis :
[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>"
J’ai fait chmod 777 shared/standalone/nginx.http.sock pour contourner temporairement ce problème de permission, et maintenant j’ai :
[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>"
Évidemment, je fais des choses mal mais je ne sais pas quoi. Veuillez noter que je n’utilise pas NPM mais nginx-proxy qui est un peu différent, en particulier il détecte automatiquement les conteneurs Docker qui définissent VIRTUAL_HOST pour générer une configuration pour eux. Par conséquent, j’ai seulement ajouté la partie location / { ... } liée à Discourse et je n’ai pas touché aux fichiers sites-available avec les directives listen.
J’ai remarqué que le conteneur Discourse est dans une boucle de redémarrage avec le statut Restarting (100) 7 seconds ago. C’est parce qu’il se plaint de ne pas pouvoir supprimer la socket. En effet, ce n’était pas une socket réelle mais un répertoire à la place, je suppose à cause de mauvaises manipulations de montage de volumes pour l’exposer au conteneur nginx-proxy.
J’ai supprimé le répertoire, redémarré Discourse et c’est maintenant une socket. Cependant, je ne peux pas l’exposer en tant que volume à 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
Il s’avère que j’avais juste besoin de monter la socket dans /tmp/nginx.http.sock au lieu de garder le même chemin. J’ai finalement réussi, semble-t-il !
Problème trouvé quant à l’exposition d’un port dans /var/discourse/containers/web_only.yml comme suit qui ne fonctionnait pas.
expose:
# - "443:443"
# - "80:80"
- "8080:80" # https
Selon Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All , c’était SELinux qui était en cause et il fallait autoriser NGINX à accéder à Discourse en exécutant ou en réglant SELinux en mode permissif.
setsebool -P httpd_can_network_connect 1
Ce qui est intéressant, c’est que si la configuration de NGINX est définie sur le chemin racine, cela fonctionne bien, mais pas lorsqu’elle est définie sur un chemin non racine.
NGINX configuré pour rediriger / vers Discourse (fonctionne)
# 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 configuré pour rediriger /discussions/ vers Discourse (ne fonctionne pas)
# 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;
}
Dans ce cas, je vois ce qui suit… Mon intuition est que même si NGINX a correctement redirigé le chemin non racine /discussions/ vers le docker Discourse, Discourse lui-même charge toujours des pages depuis lui-même et s’attend à ce que les ressources se trouvent au chemin racine /. Est-ce une exigence de faire fonctionner Discourse uniquement au chemin racine ? @pfaffman avez-vous déjà vu cela ?
/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"
