External database ENV VARs not documented (external PG Port, external Redis ENV VARs)

Greetings,

I can’t post in the Sysadmin category.

I can configure an external DB using:

DISCOURSE_DB_USERNAME
DISCOURSE_DB_PASSWORD
DISCOURSE_DB_HOST
DISCOURSE_DB_NAME

But I couldn’t find:

DISCOURSE_DB_PORT (External PostgreSQL Port)
DISCOURSE_REDIS_HOST
DISCOURSE_REDIS_USERNAME
DISCOURSE_REDIS_PASSWORD
DISCOURSE_REDIS_NAME (which database, 0,1,2,3, etc)

I’m an engineer at Compose/IBM and I’m attempting to setup Discourse using our production-ready, replicated databases. I’d like to run a web_only instance with external Redis & PostgreSQL

I also couldn’t find configuration parameters for failover support:

We supply two URIs “portals” for connection failover. I don’t have a ton of time to dig through the Discourse codebase and see which client driver you are using.

Lastly, we use SSL (using valid LE certs) for both Redis and PostgreSQL. Is your app configured for SSL support?

Thanks!

P.S. I’m reaching out personally, not officially from IBM/Compose. I enjoy Discourse and have been considering writing an article on how to configure Discourse using our services:

You can see all of the possible global vars documented at:

You can pass in config from your environment, all the settings below are available.
Append DISCOURSE_ and upper case the setting in ENV. For example:
to pass in db_timeout of 200 you would use DISCOURSE_DB_TIMEOUT=200

Я делаю это для приложения docker-compose, и, несмотря на экспорт переменной окружения DISCOURSE_REDIS_HOST (со значением redis), она игнорируется:

name, 'name', name),\n  updated_at,\n  created_at,\n  updated_at\nFROM facebook_user_infos\n")
discourse_1_9cc0cea436ca | rake aborted!
discourse_1_9cc0cea436ca | Redis::CannotConnectError: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
discourse_1_9cc0cea436ca | /usr/local/bundle/gems/redis-4.0.1/lib/redis/client.rb:344:in `rescue in establish_connection'

Мой полный код находится здесь, если вы захотите его изучить. По какой-то причине переменные (которые должны учитываться) не работают. Для контекста: я очень хочу помочь с плагином, но барьеры для входа (настройка базовой среды разработки без установки всего на хост-машину!) огромны. Единственный раз, когда мне удавалось запустить Discourse, я использовал образ Bitnami, но мне говорили (в другом месте), что это не правильный подход. Пожалуйста, помогите — это не должно быть так сложно, особенно когда я жертвую своим свободным временем, потому что хочу помочь :frowning:

Не совсем понимаю, почему у вас возникает эта проблема, но вы столкнетесь с гораздо меньшими трудностями, если воспользуетесь этим рекомендуемым способом: Install Discourse for development using Docker

Также см. Can Discourse ship frequent Docker images that do not need to be bootstrapped? - #6 by fbender

Возможно, я неправильно читаю код, но скрипт bin/docker/boot_dev --init всё ещё взаимодействует с базой данных и зависимостями на хосте.

Что касается второй ветки, на что именно вы хотите, чтобы я обратил внимание? В ней 151 сообщение. Спасибо!

Эта переменная в продакшн-окружении учитывается без проблем.

В среде разработки по умолчанию осуществляется поиск локального экземпляра, что работает корректно, если вы следуете одному из поддерживаемых способов установки для разработки.

Я запускаю его с переменной окружения production, но она не учитывалась. В качестве обходного пути я изменил конфигурацию с помощью sed, и это решило проблему. Однако у меня всё ещё есть множество других проблем, над которыми я работаю.

Например, я начинаю с явного указания не запускать процесс как демон (чтобы контейнер продолжал работать):

bundle exec rails s --port 3000 --no-daemon --environment=production --binding 0.0.0.0

но, похоже, система всё равно решает сделать это! И тогда логически контейнер завершает работу.

discourse_1_f60e0e3f1186 | [358] Puma starting in cluster mode...
discourse_1_f60e0e3f1186 | [358] * Version 3.12.1 (ruby 2.6.3-p62), codename: Llamas in Pajamas
discourse_1_f60e0e3f1186 | [358] * Min threads: 8, max threads: 32
discourse_1_f60e0e3f1186 | [358] * Environment: production
discourse_1_f60e0e3f1186 | [358] * Process workers: 4
discourse_1_f60e0e3f1186 | [358] * Preloading application
discourse_1_f60e0e3f1186 | [358] * Listening on tcp://0.0.0.0:3000
discourse_1_f60e0e3f1186 | [358] * Daemonizing...
docker-compose-discourse_discourse_1_f60e0e3f1186 exited with code 0

Странно, что есть аргументы, инструкции и переменные окружения для разных вещей, но они фактически игнорируются. Трудно понять, чему можно доверять.

Вам нужна среда production или среда development?

Почему нельзя использовать производственную среду для разработки? И что делает Sidekiq? Должен ли он запускаться отдельно для запуска приложения? Например, у меня есть другой контейнер (с той же базовой версией) с командой запуска:

bundle exec sidekiq

Он зависит от основного контейнера Discourse (миграция базы данных, предварительная компиляция статических файлов и т. д.). Всё, кажется, работает, но веб-приложения нет.

Я готов потратить много (дополнительного) времени на это, учитывая, что я ещё ничего не начал, но мне нужно решение, которое не требует установки базы данных на моём хосте. С контейнерами в этом не должно быть необходимости. И снова: приложение compose здесь GitHub - vsoch/discourse-compose: docker-compose with discourse · GitHub, похоже, работает (в логах нет ошибок), но самого приложения нет.

Потому что она кэширует и предварительно компилирует множество вещей, что в основном делает разработку невозможной.

Гид по установке Discourse для разработки с использованием Docker, на который я ссылался выше, решает именно эту задачу.

Sidekiq ставит задачи в очередь и обрабатывает их для последующего выполнения.

Что я упускаю? Команда для --init выполняется на хосте:

Справедливо, но допустим, что я всё равно занимаюсь предварительной компиляцией (это ведь занимает время!), и я хочу запустить сервер. Почему это не работает?

Хорошо, я сдался и выполнил команду --init. Могу подтвердить, что контейнер запущен:

CONTAINER ID        IMAGE                             COMMAND             CREATED             STATUS              PORTS                                                                                            NAMES
d2254e1374f5        discourse/discourse_dev:release   "/sbin/boot"        24 minutes ago      Up 24 minutes       0.0.0.0:1080->1080/tcp, 0.0.0.0:3000->3000/tcp, 0.0.0.0:9292->9292/tcp, 0.0.0.0:9405->9405/tcp   discourse_dev

Однако я не вижу никаких записей о нём ни на одном порту. Я пробовал два браузера, localhost, 127.0.0.1 и 0.0.0.0, но веб-приложения нет. Ошибка: ERR_CONNECTION_RESET. В iptables я не вижу ничего, что могло бы блокировать это:

Chain DOCKER (3 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:9405
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:9292
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:3000
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:socks

Обновление от 10 июля 2019 года

Спасибо всем за помощь — проблема заключалась в необходимости выполнить команду “unicorn”, и теперь у меня всё работает. Мне также пришлось запустить rake admin:create в команде запуска, иначе система требует подтверждения по электронной почте (полный репозиторий здесь). discourse_dev тоже работает.