리버스 프록시 뒤에서 동작하게 하려면 수동으로 변경 사항을 적용해야 합니다. app.yml을 생성한 후 해당 작업을 수행할 줄 안다고 가정할 때, 다음 방법이라면 작동할 수 있습니다:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
그 후 app.yml을 편집하여 리버스 프록시 뒤에서 동작하도록 설정하면 됩니다.
Discourse가 Unix 소켓을 통해 리스닝할 때 혼합 콘텐츠(mixed content) 경고가 발생합니다. 새로 설치한 환경입니다.
제 기억이 맞다면, 그것은 캐시된 로고입니다(force https 매개변수를 활성화했을 것으로 추측됩니다). 브라우저 개발자 도구의 네트워크 탭에서 확인해 보실 수 있을까요?
해결로 표시해 주시겠습니까? https 설정을 강제하고, 서브디렉터리 경로를 추가하기 위해 rake search replace도 실행해야 했습니다. 메인 서버에는 Apache가 실행 중이며, 이 외에도 여러 사이트가 호스팅되고 있습니다. 이 경우 example.org에는 WordPress가 설치되어 있으며, /forums 경로에 대해 Apache 리버스 프록시를 사용하고 있고, Discourse는 웹소켓을 통해 리스닝하고 있습니다.
@riking님의 상단에서 언급한 방법 대신 말인가요?
이중 NGINX 방식으로 설정하는 방법에 대한 튜토리얼 링크가 있으신가요?
불행히도 저는 NGINX에 대해 아무것도 알지 못하지만, @riking님의 튜토리얼은 충분히 간단해 보입니다. 다만 더 나은 방법이 있다면 그 자세한 내용을 알고 싶습니다.
안녕하세요!
Git 저장소에서 파일을 클론하여 Discourse를 설치하고, 제안해 주신 대로 설정을 진행했습니다. 다만 SSL 프로토콜은 Nginx proxy manager를 통해 처리했습니다 (app.yml에서 포트 443 노출 부분을 주석 처리했습니다).
현재 Portainer v2.11.0을 사용 중이며, Discourse 컨테이너가 성공적으로 생성된 것을 확인할 수 있습니다. 하지만 웹사이트를 실행하지 못하고 502 bad gateway 오류가 발생합니다.
이 오류를 수정하는 방법에 대해 아이디어가 있을까요?
SSL과 Let’s Encrypt 인증서도 제거하셨나요?
외부 프록시를 컨테이너 내부의 Nginx 프록시를 거치지 않고 Discourse에 직접 연결하도록 설정하는 것이 더 합리적이지 않을까요? (모든 요청이 이중 프록싱을 거치는 것을 피하는 것) 아니면 내부 Nginx 프록시가 외부 프록시가 처리할 수 없는 중요한 역할을 수행하고 있는 걸까요?
안녕하세요, nginx.sock 파일이 없으면 어떻게 해야 하나요?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
템플릿을 포함했나요?
Dietpi OS를 사용하는 Raspberry Pi 4에 Discourse를 설치하려고 하고 있으며, Nextcloud처럼 nginx와 함께 작동하는 일부 앱이 이미 설치되어 있습니다. Cloudflared 서비스를 터널로 사용하려 했는데, Discourse 설치 완료 후 터널을 생성하기 위해 Discourse 서비스 포트가 어디인지 찾을 수 없습니다. localhost로 접속하면 Nginx 시작 페이지가 표시됩니다. Discourse 사이트는 어디서 접근할 수 있나요?
참고로, Cloudflared 서비스를 사용하려고 하므로 certbot은 설정하지 않았습니다.
안녕하세요, GitHub - nginx-proxy/nginx-proxy: Automated Nginx Reverse Proxy for Docker · GitHub 뒤에 Discourse를 설치하려고 시도하고 있지만 방법을 찾지 못하겠습니다.
discourse의 소켓을 nginx-proxy 컨테이너에 노출하고 가상 호스트별 로케이션 구성을 추가해 보았지만 성공하지 못했습니다.
해당 프록시 뒤에 다른 서비스들은 성공적으로 설정했으며, 현재 Discourse만 남아 있습니다. 조언을 주실 수 있을까요?
호기심에 다음 두 가지 접근 방식의 장단점이 무엇인지 궁금합니다.
어떤 이유에서인지 NGINX를 시작하고 페이지를 서빙하는 것과 NGINX 없이 Discourse를 시작하는 것에는 문제가 없습니다. 하지만 첫 번째 접근 방식을 사용할 때 항상 다음과 같은 오류가 발생합니다.
/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
두 번째 접근 방식을 사용할 경우 ./launcher rebuild <app>을 실행해도 빌드조차 되지 않습니다. 다음과 같은 오류가 표시됩니다:
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>
type or paste code here
web_only 컨테이너를 사용 중인데 data 컨테이너를 실행하지 않고 있나요?
아니요, 감사합니다.
my app.yml 파일을 수정하여 discourse 컨테이너가 내 프록시와 동일한 이름이 지정된 네트워크에서 실행되도록 했습니다.
그 후, 이 스레드의 값으로 nginx-proxy 문서에서 조언한 대로 _location 설정을 추가하고, discourse 소켓을 사용 가능하게 했습니다(간편함을 위해 호스트와 동일한 경로로 설정).
하지만 어딘가에 권한 문제가 있는 것 같지만, 정확히 무엇인지 모르겠습니다: nginx가 설정을 가져오긴 하지만, https 요청을 수행하면 다음과 같은 오류가 발생합니다.
[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>"
컨테이너 내부:
# 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
수정: 이는 sudo를 사용하여 시작되고 시작되지 않은 컨테이너로 인한 문제였습니다.
하지만 지금은 다음과 같은 문제가 있습니다:
[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>"
그리고 502 bad gateway 오류가 발생합니다.
사실 둘 다입니다. docker ps를 실행하면 두 프로세스가 모두 실행 중인 것을 확인할 수 있습니다. 문자 그대로 유일한 차이점은 expose 섹션을 활성화하거나 비활성화하는 것뿐인데, 이제 와서 생각해보니 포트 목록이 아니라 expose: 줄 자체를 주석 처리해야 하는 건 아닌지 의문이 듭니다.
중복 게시에 대해 죄송합니다. 이전에 관련 없는 다른 문제로 혼란을 겪었고, 설정 오류로 인해 소켓이 더 이상 사용되지 않았습니다.
현재 진행 상황은 다음과 같습니다:
[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>"
이 권한 문제를 임시로 우회하기 위해 chmod 777 shared/standalone/nginx.http.sock을 실행했고, 이제 다음과 같은 오류가 발생합니다.
[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>"
분명 무언가를 잘못하고 있는 것 같지만, 그것이 무엇인지 알 수 없습니다. NPM이 아니라 nginx-proxy를 사용하고 있으며, 이는 약간 다르지만, 특히 VIRTUAL_HOST를 정의하는 Docker 컨테이너를 자동으로 감지하여 설정을 생성합니다. 따라서 discourse와 관련된 location / { ... } 부분만 추가했고, listen 지시문이 포함된 sites-available 파일에는 손을 대지 않았습니다.
discourse 컨테이너가 Restarting (100) 7 seconds ago 상태로 재시작 루프에 빠져 있다는 것을 발견했습니다. 이는 소켓을 삭제할 수 없다는 오류 때문이었습니다. 실제로 소켓이 아니라 디렉터리였는데, nginx-proxy 컨테이너에 노출하기 위해 볼륨 마운트를 잘못 조작한 때문인 것 같습니다.
디렉터리를 삭제하고 discourse를 재시작하자 이제 소켓으로 변경되었습니다. 그러나 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
결국, 같은 경로를 유지하는 대신 /tmp/nginx.http.sock에 소켓을 마운트하기만 하면 되는 것이었습니다. 마침내 성공한 것 같습니다!
왜 /var/discourse/containers/web_only.yml에서 다음과 같이 포트를 노출하는 것이 작동하지 않는지 그 문제를 찾았습니다.
expose:
# - "443:443"
# - "80:80"
- "8080:80" # https
https://www.programmerall.com/article/443137626/ 에 따르면 SELinux가 원인이었으며, NGINX가 Discourse에 접근할 수 있도록 허용하려면 setsebool -P httpd_can_network_connect 1을 실행하거나 SELinux를 Permissive(허용) 모드로 설정해야 합니다.
흥미로운 점은 NGINX 설정이 루트 경로로 설정되어 있으면 정상적으로 작동하지만, 루트 경로가 아닌 경로로 설정되어 있으면 작동하지 않는다는 것입니다.
NGINX가 /를 Discourse로 전달하도록 설정 (작동함)
# 443/discussions 요청을 127.0.0.1:8080에서 리스닝 중인 Discourse로 프록시
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가 /discussions/를 Discourse로 전달하도록 설정 (작동하지 않음)
# 443/discussions 요청을 127.0.0.1:8080에서 리스닝 중인 Discourse로 프록시
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;
}
이 경우 다음과 같은 로그가 나타납니다 … 제 직감으로는 NGINX가 루트 경로가 아닌 /discussions/ 경로를 Discourse 도커로 성공적으로 전달했음에도 불구하고, Discourse 자체는 여전히 자사에서 페이지를 로드하고 있으며 에셋이 루트 경로 /에 있다고 기대하는 것 같습니다. 추측컨대 Discourse는 루트 경로에서만 실행해야 하는 요구 사항이 있는 것 같습니다. @pfaffman 이 현상을 전에 본 적 있으신가요?
/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"
