Убедитесь, что оба контейнера находятся в одной сети Docker. Если NPM не работает, то проблема (пока) не в конфигурации Discourse.
1 лайк
Я по ошибке забыл про сеть MariaDB в Docker, но после добавления
network_mode: bridge
я всё ещё получаю ошибку npm при подключении к базе данных Discourse;
environment:
DB_MYSQL_HOST: "172.17.0.2" # контейнер с данными — но я получаю ошибку (error connect ECONNREFUSED 172.17.0.2:3306), когда это включено.
# DB_MYSQL_HOST: "db" база данных npm по умолчанию (вне Discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "h4xb0xr1z__0k"
DB_MYSQL_NAME: "npm"
Когда npm и MariaDB запускаются и работают, логи MariaDB в порядке… но npm
error connect ECONNREFUSED 172.17.0.2:3306
Что-то упущено?
1 лайк
Мой файл docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
network_mode: bridge
restart: unless-stopped
ports:
- '80:80' # Публичный порт HTTP
- '443:443' # Публичный порт HTTPS
- '81:81' # Порт административной веб-панели
environment:
DB_MYSQL_HOST: "172.17.0.2" # контейнер с данными — но при включении получаю ошибку ( connect ECONNREFUSED 172.17.0.2:3306 ).
# DB_MYSQL_HOST: "db" база данных npm по умолчанию (вне discourse).
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "mypassword"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
# depends_on:
# - db
db:
image: 'mariadb:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'mypassword'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'mypassword'
volumes:
- ./data/mysql:/var/lib/mysql
У меня запущен discourse с контейнерами data и web-only; сопоставление IP-адресов после npm и maria выглядит так:
IP контейнера с данными: 172.17.0.2
IP контейнера web_only: 172.17.0.3
IP контейнера npm: 172.17.0.5
IP контейнера maria (npm): 172.17.0.4
1 лайк
Привет, @tophee
Можешь дать нам свою рекомендацию по использованию SQLite с NPM, так как это проще и надежнее в работе, чем проблемы с MariaDB?
Я настроил NPM с SQLite, и всё работает отлично: виртуальный хост nginx, SSL и т.д. Но я хочу убедиться, как подключить базу данных Discourse к NPM, так как при настройке NPM вместе с сайтом Discourse я получаю ошибку 502.
мой docker-compose
version: "3"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
network_mode: bridge <-- эта сеть была добавлена, чтобы NPM находился в той же сети, что и Discourse, и они могли видеть друг друга.
ports:
# Публичный порт HTTP:
- '80:80'
# Публичный порт HTTPS:
- '443:443'
# Порт веб-администратора:
- '81:81'
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
Нет, моя рекомендация — использовать стандартную настройку NPM, если вы точно не знаете, что делаете. Именно поэтому я использую стандартную настройку.
Вам не нужен шаг 3, если вы подключаете контейнер Discourse через WebSocket.
Это происходит потому, что
Вы уверены, что 172.17.0.2 — это ваш контейнер базы данных? — В любом случае: вы можете избежать этой проблемы, оставив NPM в собственной сети и подключив Discourse через WebSocket.
2 лайка
Спасибо @tophee за разъяснение. Я всё сделал и исправил, но, похоже, я не использовал WebSocket, а сосредоточился на порте с настройкой NPM и контейнерами Discourse.
Моя проблема с NPM связана с туннелем Argo от CloudFlared. После завершения настройки NPM, SSL и всего остального мне удалось запустить туннель Argo от CloudFlared, но возникла проблема: CloudFlared не может работать как вторичный прокси. Нам нужно отключить NPM, чтобы он не стоял перед исходным веб-сервером. Ошибка, которую я получил от CloudFlare, следующая:
Error 1000: DNS points to prohibited IP
После поиска этой ошибки в CloudFlare я получил следующее:
На вашем исходном сервере работает обратный прокси, который пересылает запрос обратно через прокси Cloudflare. Вместо использования обратного прокси обратитесь к вашему хостинг-провайдеру или администратору сайта, чтобы настроить HTTP-редирект на исходном сервере.
Как можно отключить NPM как обратный прокси?
Моя цель — заставить исходный IP работать без NPM, даже если NPM установлен и функционирует, чтобы CloudFlared мог связываться с нашим сервером.
1 лайк
Удалите NPM. Вся суть NPM заключается в том, чтобы действовать как обратный прокси. Если вам не нужен обратный прокси, отключите его.
Я не совсем понимаю суть вопроса, и это точно не входит в сферу моих знаний. Вам, вероятно, стоит обратиться на форум NPM или в другое место. Это не имеет никакого отношения к Discourse.
2 лайка
Я уже открыл тему там; и я обсуждаю это здесь тоже, и да, я отключил это после двух дней экспериментов; но я бы хотел добавить, как добавить поддержку пользовательского порта с Discourse и NPM здесь, так как эта тема поддерживает только сокет nginx с npm;
Спасибо.
1 лайк
Нет. Поддержка не ограничивается только сокетами, если вы не следуете инструкциям для сокетов. Там указано, что использование сокетов не обязательно:
Когда я последний раз это тестировал, всё работало отлично при использовании порта, как и было предложено.
1 лайк
Эти инструкции помогли мне настроить Discourse с использованием Nginx Proxy Manager.
Однако браузер выдаёт ошибки «смешанного содержимого» при попытке загрузить шрифты и изображения по протоколу http.
Вы можете «принудительно использовать HTTPS» в ссылках с помощью опции здесь:
1 лайк
Вау, это довольно сложная тема с множеством «если» и «но».
Сегодня я тоже попытался настроить всё сам, но, к сожалению, потерпел полное фиаско. Инструкции написаны с благими намерениями, но, на мой взгляд, их не так просто понять.
Когда я работаю с Docker, я обычно хочу, чтобы контейнеры запускались отдельно и были изолированы друг от друга. Не слишком много зависимостей, предварительных условий и «единых точек отказа». Но именно эти проблемы вызывает данный подход: NPM — отличный инструмент. Я не понимаю, почему мне приходится вносить специальные настройки в его конфигурацию Docker из Proxy Manager, чтобы Discourse работал корректно и мог получать сертификаты. Дома я также использую NPM для своего домена DynDNS, чтобы гибко назначать службы и хосты в любое время. И чтобы некоторые из них были доступны публично (Home Assistant, Grafana и т. д.).
Сегодня я хотел объединить свои два экземпляра Discourse. Я специально арендовал облачный сервер у Hetzner в Германии. Поэтому Discourse не был предварительно установлен, как предполагается в инструкциях.
Я бы хотел, чтобы Discourse официально предлагал установку с NPM по умолчанию. Или хотя бы не создавал столько проблем с помощью скрипта ./discourse-setup.
1 лайк
Небольшая инструкция по установке нескольких экземпляров 
В данном случае мы начнем с чистой установки на сервере, а позже, возможно, захотим восстановить старый экземпляр.
Шаг 0: Резервное копирование!!!
Скачайте резервную копию. Она вам понадобится позже.
Шаг 1: NGINX Proxy Manager
mkdir -p /opt/nginx-proxy-manager
cd /opt/nginx-proxy-manager
nano docker-compose.yml
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: always
ports:
- '80:80' # http / зарезервировано!
- '81:81' # порт веб-администратора
- '443:443' # https / зарезервировано!
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
И наконец: docker-compose up -d
(Для ещё более ленивых, как иногда и я, просто используйте casaOS (на любом порту, кроме 80/81/443). Просто убедитесь, что вы используете безопасные учётные данные для входа и дополнительный прокси-хост с вашим SSL-сертификатом для дополнительного уровня безопасности. Вы даже можете настроить правила брандмауэра, если знаете, что делаете.
Шаг 2: Установка Docker на сервер Ubuntu
sudo apt update && apt upgrade -y
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Шаг 3: Подготовка к установке Discourse
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cp /var/discourse/samples/standalone.yml /var/discourse/containers/app1.yml
nano /var/discourse/containers/app1.yml
cp /var/discourse/samples/standalone.yml /var/discourse/containers/app2.yml
nano /var/discourse/containers/app2.yml
Внесите необходимые изменения в файлы app.yml. Это включает разные открытые порты для каждого экземпляра (да, их можно использовать даже для обслуживания), настройки почты и так далее.
Например, app1 получает порты 8080/1443, а app2 — порты 8081/2443 для http/https.
/var/discourse/launcher rebuild app1
/var/discourse/launcher rebuild app2
Шаг 4: И наконец, настройка NGINX Proxy Manager
Посмотрите это видео для базового понимания работы с NGINX Proxy Manager.
Всё, что вам нужно сделать, — указать записи прокси-хоста на каждый экземпляр (http-порт, например, 8080 и 8081, с вашим локальным или публичным IP-адресом, это ваш выбор), и вы сможете получить бесплатные сертификаты Let’s Encrypt для каждого экземпляра и домена. Просто убедитесь, что вы включили принудительное использование SSL и так далее.
Шаг 5: Готово. Выпейте чашечку кофе.
В моём случае всё работает идеально.
Возможны некоторые незначительные проблемы с предварительно установленными зависимостями программного обеспечения, но я уверен, что вы найдёте решение. Не сердитесь на меня за совет по поводу casaOS. Но для тех, кто любит экспериментировать со своими серверами, используя все доступные ресурсы простым, безопасным и защищённым способом, я уверен, что это управление Docker покажется вам интересным.
Шаг 6: В завершение восстановите ваши предыдущие резервные копии.
1 лайк
Могу ли я объединить это с помощью Cloudflare Tunnel для домена?
1 лайк
Конечно, почему бы и нет?
Просто убедитесь, что вы откроете правильный порт и настроите его для своего домена в туннелях Cloudflare.
Лично я не предпочитаю это решение, так как оно делает меня зависимым от Cloudflare, и каждый агент туннеля создаёт дыру 
в моём фаерволе, из-за чего мне кажется, будто я устанавливаю троянского коня.
Управление фаерволом критически важно для администраторов серверов. Вам предстоит выполнить некоторую домашнюю работу, прежде чем открывать сайты в DMZ.