Я делаю это для настройки Discourse: ./discourse-setup, но получаю ошибку, показанную на изображении.
Как исправить эту ошибку? Я использую Ubuntu 18.04
В имени хоста, которое вы ввели, содержится невидимый символ:
Попробуйте снова, но убедитесь, что вводите его корректно. Если вы копируете и вставляете текст, убедитесь, что исходный текст чистый.
Похоже, на этом IP-адресе уже запущен WordPress.
Да, WordPress установлен. Не могу ли я использовать оба на одном сервере?
Это возможно, но непросто. При этом вы не можете использовать discourse-setup. Я рекомендую сначала попробовать на сервере, где не запущены другие службы.
Запуск других веб-сайтов на том же сервере, что и Discourse.
Я выполнил эти шаги, но результатов нет. Между тем я использую WEBMIN.
У кого-нибудь есть другие идеи?
Если инструкции в теме, на которую я ссылался ранее, не работают для вас, то самый простой вариант — запустить Discourse на собственном сервере.
Сделать так, чтобы это работало с Webmin, будет очень сложно.
Я знаю, что это будет сложно, но я не считаю себя любителем. Я попробовал инструкции, на которые вы дали ссылку. Есть ли ещё какие-то ссылки, которые мне стоит прочитать?
По этой проблеме есть несколько тем howto.
Привет, @Murto
Кстати, я считаю, что Discourse как бэкенд-приложение на Rails настраивается гораздо проще, если сконфигурировать Rails для использования unix-сокета вместо TCP/IP-порта, а само приложение Discourse разместить за обратным прокси.
В этом случае TCP/IP-порты открываются только через обратный прокси, а приложение Discourse (и контейнер) работает через unix-сокет. Так вы можете запустить столько экземпляров контейнеров Discourse, сколько захотите, не беспокоясь о конфликтах TCP/IP-сокетов. На мой взгляд, это очень чистый способ запуска Discourse.
На этом сайте множество руководств и уроков, которые помогут вам настроить это, если вы застрянете и захотите немного изменить направление. В дистрибутиве Discourse есть шаблон «socket», который можно использовать для настройки «части конфигурации Discourse»; затем вам останется только настроить обратный прокси (уроков по этому поводу бесчисленное множество), и «вперёд!».
Надеюсь, это поможет.
Мне так и не удалось решить проблему. Не мог бы кто-нибудь подробно объяснить? 
Попробуйте следующее:
netstat -lnptu | grep :443
а затем:
kill -9 PID (замените PID на номер, полученный в результате выполнения предыдущей команды)
Я рекомендую настроить обратный прокси на вашем сервере, доступном из интернета, и настроить его на перенаправление запросов к WordPress или Discourse в зависимости от хоста.
Например, запустите службу nginx, используя порты 80 и 443 на хосте, и настройте его на проксирование запросов к blog.yourdomain к сервису WordPress (либо на внутренний порт вашего хоста, если у вас Apache + WordPress, в этом случае вы можете перенаправить запросы на порт Apache, например 8080, либо использовать FastCGI).
Затем на том же сервере вы можете запустить Discourse, убедившись, что в файле app.yml указаны неиспользуемые порты хоста, например 8081, либо используйте unix-сокет, как предложил @neounix. После этого настройте проксирование запросов к forum.yourdomain на этот порт или на сокет. Для запуска Discourse необходимо выполнить команду ./launch rebuild app в директории Discourse (обычно это /var/discourse).
В этом случае вам не нужно запускать discourse-setup для создания файла подкачки размером 2 ГБ (он в основном используется при обновлениях, которые могут требовать больше памяти, хотя он может и не понадобиться, если у вашего сервера много памяти), а также для создания файла app.yml. Вместо этого вы должны сделать это самостоятельно. Если вы не знаете, что указать в файле app.yml, я рекомендую выполнить рекомендуемую установку на отдельном сервере, даже если только для того, чтобы лучше ознакомиться с Discourse и посмотреть сгенерированный файл app.yml, который вы сможете использовать на вашем общем сервере (не забудьте изменить порты или удалить их, если вы используете подход с unix-сокетом).
Я рекомендую следовать одному из тематических руководств по этой теме (howto), если вы не можете продолжить самостоятельно.
Можете объяснить, как выполнить процесс обратного прокси? Я узнал, что нужно делать, но не знаю, как это сделать.
У меня нет примера под рукой, так как я не использую прокси-сервер перед ними, хотя, кажется, я реализовывал это некоторое время назад. В любом случае, здесь нет ничего секретного; всё должно работать так же, как и с другими обратными прокси-серверами. Ниже приведён обзор того, что следует делать с использованием портов (а не сокетов):
-
Убедитесь, что сервис WordPress запущен на порту, отличном от 80 и 443 (например, 8443), и работает. Сначала вы можете попробовать открыть его доступ в интернет, чтобы проверить работоспособность.
-
Сделайте то же самое для Discourse, сопоставив его с другими портами.
Было:
expose:
- "80:80" # http
- "443:443" # https
Стало (например):
expose:
- "8081:80" # http
- "8444:443" # https
В вашем файле app.yml (если у вас его нет, рекомендую запустить Discourse на отдельной машине, следуя официальному руководству, просто чтобы понять, как это работает, и посмотреть на сгенерированный файл app.yml в /var/discourse/containers/). Вот пример файла app.yml: discourse_docker/samples/standalone.yml at master · discourse/discourse_docker · GitHub
- Установите nginx и добавьте директивы прокси в его конфигурационный файл. Они должны быть похожи на следующий фрагмент:
upstream blog {
server localhost:8080;
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://blog.barinaklar.com$request_uri;
}
}
server {
server_name blog.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://blog;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
upstream forum {
server localhost:8081;
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 80;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
return 301 https://forum.barinaklar.com$request_uri;
}
}
server {
server_name forum.barinaklar.com;
server_tokens off;
listen 443 ssl;
location /.well-known/acme-challenge/ {
root /var/www/certbot;
}
location / {
proxy_pass http://forum;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Это предполагает, что WordPress запущен на порту 8080, а Discourse — на порту 8081. Обязательно настройте фаервол, чтобы заблокировать доступ к этим портам (облачные провайдеры обычно блокируют все порты по умолчанию, кроме 22, поэтому это может быть не нужно).
В этом случае вы сами отвечаете за генерацию SSL/TLS-сертификатов (вы можете сделать это с помощью certbot, запустив его периодически через cron-задачу, поэтому я уже включил пути /.well-known/acme-challenge/ в конфигурацию nginx).
Как я уже говорил выше, это лишь обзор, и возможно, я что-то упустил. Особое внимание следует уделить базовому URL из-за изменения портов (чтобы убедиться, что он не пытается перенаправить пользователя на https://вашдомен:8081 вместо https://вашдомен, и внести необходимые изменения для корректной работы).
Это может быть не нужно, если WordPress запущен в контейнере с портом 80 или 443 внутри контейнера. С Discourse тоже всё должно быть в порядке. Проблема может возникнуть в отношении https: он может перенаправлять на http, так как использует порт http в прокси. Поэтому стоит проверить, происходит ли это, и исправить в случае необходимости.
Спасибо за вашу помощь. Я подам заявку и проинформирую о транзакциях.