Configure Discourse to use a separate PostgreSQL server

Thanks

Anu reference or file need to be removed?

I needed to run development discourse (set up following Install Discourse for development using Docker ) using database from another container. To do so, I had to modify the installation steps as follows:

  1. git clone https://github.com/discourse/discourse.git
  2. cd discourse
  3. vim config/database.yml , on the top of the file, make it into:
development:
  prepared_statements: false
  adapter: postgresql
  #database: <%= ENV['DISCOURSE_DEV_DB'] || 'discourse_development' %>
  database: discourse
  username: discourse
  password: yourdbpassword
  host: postgres
  min_messages: warning
  pool: 5
  timeout: 5000
  checkout_timeout: <%= ENV['CHECKOUT_TIMEOUT'] || 5 %>
  host_names:
    ### Don't include the port number here. Change the "port" site setting instead, at /admin/site_settings.
    ### If you change this setting you will need to
    ###   - restart sidekiq if you change this setting
    ###   - rebake all to posts using: `RAILS_ENV=production bundle exec rake posts:rebake`
    - "localhost"
  1. vim bin/docker/boot_dev, find the line starting with docker run, and add a network definition matching the docker network to which your postgres container is attached to: docker run --network my-docker_network-name -d -p 4305:...
  2. ./bin/docker/boot_dev
  3. ./bin/docker/unicorn
  4. you may need to run migrations: docker exec -it discourse_dev /bin/bash -c "cd /src; ./bin/rails db:migrate RAILS_ENV=development"
  5. visit http://localhost:9292/ and log in with credentials you set up earlier on that database

Is there a simpler way to do it, just with environment variables?

3 лайка

This failed for me. Any suggestions on how to fix it ?
I am able to access DB discourse remotely from command line so the connection to DB looks good

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 274 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
578a8ec702d0025b01a0b8396985b8bfc25c7029769c2960b58693c64609a62a
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

I got the same error with the following lines in the log above:

rake aborted!
PG::ConnectionBad: could not connect to server: Connection refused
        Is the server running on host "127.0.0.1" and accepting
        TCP/IP connections on port 5432?

Currently I am trying to find a fix.

1 лайк

The only way for me to rebuild with external postgres was the command mentioned earlier:

 rebuild app --docker-args --net=host --skip-mac-address

But in this case unicorn is started with default port 3000. Exposing ports is disabled as well. I cannot explain exactly, but something has changed since Sep '17, probably in launcher code.

2 лайка

Hey guys,

what´s the best practice to migrate from docker based postgre db to dedicated?
The setup of the dedicated is described farther up this thread, right, but how can I then move the data from docker to dedicated db ?
Probably with backup & restore, but is there a tutorial for that available ?

Thanks and greetings,

Julian

1 лайк

Ideally, you have discourse stopped.
Dump your database with pg_dump and restore with pg_restore.
see PostgreSQL Restore Database

Before starting up Discourse using the new database, issue as admin:

grant all privileges on database discourse to discourse;
alter schema public owner to discourse;
create extension if not exists hstore;
create extension if not exists pg_trgm;
2 лайка

Мы также можем использовать IP-адрес хоста вместо использования --net=host.
172.17.0.1 — это адрес по умолчанию для хост-машины из сети Docker на Unix-системах.
Использование --net=host ограничивает возможность использования опции -p как аргумента Docker.

DISCOURSE_DB_HOST = 172.17.0.1
4 лайка

Привет,
Спасибо за очень полезное руководство.
К сожалению, при попытке повторить описанные шаги я столкнулся с ошибкой.
Изначально я установил Discourse с помощью launcher для всех компонентов (app/redis/postgres), и всё работало корректно.
Однако при использовании внешнего RDS launcher завершил работу с ошибкой:

root@ip-172-31-42-129:/var/discourse# ./launcher rebuild app
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
cd /pups && git pull && git checkout v1.0.3 && /pups/bin/pups --stdin
docker: Error response from daemon: could not get container for discourse.xxxxxxxx.us-west-2.rds.amazonaws.com: No such container: discourse.xxxxxxxx.us-west-2.rds.amazonaws.com.
See 'docker run --help'.
cat: cids/app_bootstrap.cid: No such file or directory
"docker rm" requires at least 1 argument.
See 'docker rm --help'.

Usage:  docker rm [OPTIONS] CONTAINER [CONTAINER...]

Remove one or more containers
rm: cannot remove 'cids/app_bootstrap.cid': No such file or directory
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

Пожалуйста, подскажите, как решить эту проблему.
Спасибо,
Александр К

Существует ли способ предварительного создания и инициализации базы данных без прохождения шагов миграции? Мы работаем в среде AKS с внешним PostgreSQL, и настройка базы данных, по-видимому, занимает, на мой взгляд, аномально много времени (~8–9 минут). Было бы здорово ускорить этот процесс. Или это известная проблема в данной конфигурации?

1 лайк

Это не поддерживаемая конфигурация.

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

1 лайк

Да, вы можете выполнить начальную настройку в другом месте, а затем перенести данные в вашу производственную PostgreSQL.

Однако это сделает обновления очень неудобными.

2 лайка

Три вещи, на которые стоит обратить внимание.

Во-первых: по умолчанию PostgreSQL слушает только localhost. Измените адрес прослушивания в файле postgresql.conf, как показано ниже.

listen_addresses = ‘localhost,172.17.0.1’

Во-вторых: разрешите PostgreSQL принимать подключения от образов Docker, добавив следующую строку в файл pg_hba.conf.

host all all 172.17.0.0/16 scram-sha-256

Перезапустите службу PostgreSQL после выполнения двух вышеуказанных изменений.

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

2 лайка

@Falco, есть ли риск удалить существующие таблицы, если я использую уже существующую базу данных?
Также, есть ли способ добавить префикс для таблиц Discourse?

Нет, если только они не конфликтуют с именами Discourse.

Но я считаю, что это плохая идея.

Нет. Я рекомендую использовать отдельную базу данных, если нет веских причин для их объединения.

Какую проблему вы решаете, используя общую базу данных?

1 лайк

Спасибо, я использую AWS RDS. Я только что обнаружил, что на одном экземпляре можно разместить несколько баз данных, поэтому я создал новую базу данных с новым пользователем.

2 лайка

Итак, у меня есть только что установленный экземпляр Discourse, работающий через Docker в виртуальной машине на Google Cloud. В настоящее время у меня включены загрузка файлов и резервное копирование Discourse в бакеты Google Cloud, и эти функции работают корректно после следования инструкциям из темы Настройка совместимого с S3 провайдера объектного хранилища для загрузок. Я вижу тестовые загрузки в бакете, и при просмотре URL-адресов загрузок все они показывают правильный URL от CDN, что говорит о том, что данные корректно подтягиваются из бакета.

Затем я создал экземпляр PostgreSQL 15.2 на Google Cloud и выполнил процедуру настройки базы данных, описанную в первом посте, а также настроил файл app.yml. Порт по умолчанию для PostgreSQL на Google Cloud — 5432, поэтому я пропустил соответствующие строки.
Если я использую публичный IP-адрес экземпляра PostgreSQL в конфигурации app.yml, то при пересборке приложения получаю следующее:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
a6a71b00bce378aa6334ae1c9fe103778d260bb699fe598f9685689e8b5ce450

Чтобы понять, что происходит, я попробовал использовать другие IP-адреса экземпляра PostgreSQL.
Если я использую приватный IP-адрес экземпляра PostgreSQL, получаю следующее:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
7333126c522eb51ace4d55ea89803eea54b96704baab70c322008cf2836ba47a

Если я использую исходящий IP-адрес экземпляра PostgreSQL, получаю следующее:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1026 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c588d2b6977b9e7d493b0b59bc694369cb7c2219de67d5886112ed16312626ae

При использовании всех различных IP-адресов сообщения об ошибке очень похожи, и база данных PostgreSQL не получает никаких данных или подключений. У кого-нибудь есть идеи, что я делаю не так?

Кроме того, связана ли моя проблема с тем, что я не использую Cloud SQL Auth Proxy на экземпляре виртуальной машины? Если да, то, полагаю, мне придется написать скрипт для запуска прокси и синхронизировать его с пересборкой приложения. У кого-нибудь есть идеи по этому поводу?

Спасибо за ваше время, ребята.

Я попытался пересобрать ещё несколько раз, переключаясь между IP-адресами, и, похоже, база данных Discourse в конечном итоге заполнилась таблицами. Теперь я ещё больше в тупике и не понимаю, что происходит.

Может ли кто-нибудь сообщить, для какой версии Discourse были написаны исходные инструкции?

Это должно работать при стандартной установке уже последние 5 лет, а возможно, и навсегда.

У вас возникла проблема?

1 лайк