Вам придётся внести изменения вручную, чтобы это работало за обратным прокси-сервером. Предполагая, что вы знаете, как это сделать, и сделаете это после создания app.yml с:
Это может сработать:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Затем отредактируйте app.yml, чтобы он работал за обратным прокси-сервером.
Получаю предупреждения о смешанном содержимом, когда Discourse слушает unix-сокет. Чистая установка.
Если я не ошибаюсь, это кэшированный логотип (предполагаю, что вы включили параметр force https). Не могли бы вы проверить это в инструментах разработчика браузера на вкладке Network?
Пожалуйста, отметьте это как решённое. Мне пришлось принудительно включить настройку HTTPS (а также выполнить rake search replace для добавления пути подкаталога). Основной сервер работает под управлением Apache вместе со многими другими сайтами. В данном случае для example.org установлен WordPress, который выполняет обратный прокси-сервер Apache для /forums, при этом Discourse слушает веб-сокет.
Вместо метода @riking в начале?
У вас есть ссылка на пошаговое руководство о том, как сделать это способом «двойной NGINX»?
К сожалению, я ничего не знаю о NGINX, но инструкция от @riking кажется достаточно простой, но если есть лучший способ, я буду признателен за подробности.
Привет!
Мы установили Discourse, клонировав файлы из репозитория Git и выполнив ваши рекомендации. Однако настройку протокола SSL мы осуществили через Nginx Proxy Manager (в файле app.yml закомментировали часть, отвечающую за открытие порта 443).
Мы используем Portainer версии 2.11.0, где видим, что контейнер Discourse успешно создан, но запустить сайт не удаётся: появляется ошибка 502 bad gateway.
Есть ли у вас идеи, как исправить эту ошибку?
Вы также удалили сертификаты SSL и Let’s Encrypt?
Смотрите:
Используете ли вы установку через сокет, как здесь:
Тогда посмотрите: Как отладить установку Discourse в подпапке
Разумно ли настроить внешний прокси для прямого подключения к Discourse, а не к прокси Nginx внутри контейнера (избегая двойного проксирования)? Или внутренний прокси Nginx выполняет важную задачу, которую внешний прокси не может взять на себя?
Здравствуйте, что мне делать, если файла nginx.sock нет?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
Вы включили шаблон?
Я пытаюсь установить Discourse на Raspberry Pi 4 с ОС DietPi, где уже работают приложения на базе nginx, такие как Nextcloud. Я планирую использовать службу Cloudflared для создания туннеля, но после завершения установки Discourse не могу найти порт службы Discourse для создания туннеля. При подключении к localhost отображается стартовая страница Nginx. Где я могу получить доступ к сайту Discourse?
Примечание: я не настраивал certbot, так как хочу использовать службу Cloudflared.
Здравствуйте! Я пытаюсь установить Discourse за прокси-сервером nginx (GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen · GitHub), но не могу понять, как это сделать.
Я пробовал открыть сокет Discourse для контейнера nginx-proxy и добавить конфигурацию локации для каждого виртуального хоста, но безрезультатно.
Мне уже удалось настроить другие сервисы за этим прокси, и теперь остался только Discourse. Не могли бы вы дать какие-нибудь советы?
Из любопытства, каковы плюсы и минусы следующих двух подходов?
По каким-то причинам я могу запустить NGINX и обслуживать страницы, а также запустить Discourse без NGINX без проблем. Но при использовании первого подхода я всегда получаю следующие ошибки.
/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>
введите или вставьте код здесь
Вы используете контейнер web_only, но не запускаете контейнер данных?
Я не стал, спасибо.
Я изменил свой app.yml, чтобы контейнер discourse работал в той же именованной сети, что и мой прокси.
Затем я добавил конфигурацию _location, как рекомендовано в документации nginx-proxy, с значениями из этой темы, и сделал сокет 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, который работает немного иначе: в частности, он автоматически обнаруживает контейнеры Docker, определяющие VIRTUAL_HOST, и генерирует для них конфигурацию. Поэтому я добавил только часть location / { ... }, относящуюся к Discourse, и не трогал файлы в sites-available с директивами listen.
Я заметил, что контейнер 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
Согласно Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All, дело было в SELinux, и нужно было разрешить NGINX доступ к Discourse, запустив команду или установив SELinux в режим Permissive:
setsebool -P httpd_can_network_connect 1
Теперь интересно то, что если конфигурация NGINX настроена на корневой путь, всё работает нормально, но не работает, когда путь задан не как корневой.
NGINX настроен на перенаправление / на Discourse (работает)
# Перенаправление запросов к 443/discussions на Discourse, слушающий на 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 настроен на перенаправление /discussions/ на Discourse (не работает)
# Перенаправление запросов к 443/discussions на Discourse, слушающий на 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;
}
В этом случае я вижу следующее… Моё интуитивное предположение: хотя NGINX успешно перенаправил некорневой путь /discussions/ в Docker-контейнер 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"
