Thanks
Anu reference or file need to be removed?
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:
git clone https://github.com/discourse/discourse.gitcd discoursevim 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"
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:..../bin/docker/boot_dev./bin/docker/unicorndocker exec -it discourse_dev /bin/bash -c "cd /src; ./bin/rails db:migrate RAILS_ENV=development"Is there a simpler way to do it, just with environment variables?
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.
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.
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
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;
Мы также можем использовать IP-адрес хоста вместо использования --net=host.
172.17.0.1 — это адрес по умолчанию для хост-машины из сети Docker на Unix-системах.
Использование --net=host ограничивает возможность использования опции -p как аргумента Docker.
DISCOURSE_DB_HOST = 172.17.0.1
Привет,
Спасибо за очень полезное руководство.
К сожалению, при попытке повторить описанные шаги я столкнулся с ошибкой.
Изначально я установил 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 минут). Было бы здорово ускорить этот процесс. Или это известная проблема в данной конфигурации?
Это не поддерживаемая конфигурация.
Если вы создаете образ, собирается гораздо больше компонентов, чем только база данных — например, множество шаблонов предварительно компилируются. Думаю, именно поэтому процесс занимает столько времени.
Да, вы можете выполнить начальную настройку в другом месте, а затем перенести данные в вашу производственную PostgreSQL.
Однако это сделает обновления очень неудобными.
Три вещи, на которые стоит обратить внимание.
Во-первых: по умолчанию 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.
@Falco, есть ли риск удалить существующие таблицы, если я использую уже существующую базу данных?
Также, есть ли способ добавить префикс для таблиц Discourse?
Нет, если только они не конфликтуют с именами Discourse.
Но я считаю, что это плохая идея.
Нет. Я рекомендую использовать отдельную базу данных, если нет веских причин для их объединения.
Какую проблему вы решаете, используя общую базу данных?
Спасибо, я использую AWS RDS. Я только что обнаружил, что на одном экземпляре можно разместить несколько баз данных, поэтому я создал новую базу данных с новым пользователем.
Итак, у меня есть только что установленный экземпляр 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 лет, а возможно, и навсегда.
У вас возникла проблема?