Discourseを別のPostgreSQLサーバーに設定する

Thanks

Anu reference or file need to be removed?

I needed to run development discourse (set up following Beginners Guide to 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

we can also use Hosts ip address instead of using --net=host
172.17.0.1 is the default address for host machine from docker network on unix machines.
Using --net=host restricts us to use -p option as docker argument.

DISCOURSE_DB_HOST = 172.17.0.1
「いいね!」 4

Hi,
Thank you for really great guide.
Unfortunately I got an error while reproducing it.
Initially I created discourse using launcher for all - app/redis/postgres. And it worked fine.
But with external RDS launcher failed:

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.

Please advice how to resolve this issue.
Thank you,
Alexander K

Is there any way to pre-create and seed the database that doesn’t require going through the migration steps? We are running on AKS with external Postgres and the db setup seems to take what I consider to be an abnormally long amount of time (~8-9 minutes). Speeding this up would be great. Or is this a known issue in that configuration?

「いいね!」 1

That’s not a supported configuration.

If you’re building an image, a bunch more stuff than just the database is getting built like a bunch of templates are getting pre-compiled. I think that’s just how long it’s going to take.

「いいね!」 1

Yes, you can bootstrap it elsewhere and then move the data to your production PostgreSQL.

However this will make updates very cumbersome.

「いいね!」 2

確認すべき3つの点があります。

1つ目:デフォルトでは、PostgreSQLはlocalhostでリッスンします。以下に示すように、postgresql.confファイルでリッスンアドレスを変更します。

listen_addresses = ‘localhost,172.17.0.1’

2つ目:pg_hba.confファイルに以下の行を追加して、PostgreSQLにDockerイメージからの接続を受け入れるように指示します。

host all all 172.17.0.0/16 scram-sha-256

上記2つの変更を行った後、PostgreSQLサービスを再起動してください。

3つ目:それでも接続できない場合は、ポート5432での着信接続をブロックしている可能性のあるファイアウォールを確認してください。

「いいね!」 2

既存のDBを使用した場合、既存のテーブルを削除するリスクはありますか?
また、Discourseのテーブルにプレフィックスを追加する方法はありますか?

いいえ、Discourseの名前と競合しない限りはありません。

しかし、それは悪い考えだと思います。

いいえ。接続する必要がある理由がない限り、別のデータベースを使用することをお勧めします。

データベースを共有することで、どのような問題を解決しようとしていますか?

「いいね!」 1

AWS RDSを使用しています。同じインスタンスで複数のDBを作成できることがわかりましたので、新しいユーザーで新しいDBを作成しました。

「いいね!」 2

Google Cloud の VM 上の Docker を介して実行されている Discourse インスタンスを新規にインストールしました。現在、Google Cloud のバケットへのファイルアップロードと Discourse のバックアップが有効になっており、Configure an S3 compatible object storage provider for uploads thread の指示に従って正常に機能しています。バケット内にテストアップロードが表示され、アップロード URL を見ると、すべてのアップロードが CDN から適切な URL を表示しており、バケットから正しくプルされているようです。

次に、Google Cloud で PostgreSQL 15.2 インスタンスを作成し、最初の投稿で概説されているデータベース設定手順を実行し、app.yml ファイルも設定しました。Google Cloud での PostgreSQL のデフォルトポートは 5432 なので、これらの行は省略しました。
app.yml 設定で postgres インスタンスのパブリック IP アドレスを使用すると、アプリの再構築時に次のようになります。

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

何が起こっているかを確認するために、postgres インスタンスの他の IP アドレスを使用してみました。
postgres インスタンスのプライベート IP アドレスを使用すると、次のようになります。

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

postgres インスタンスのアウトバウンド IP アドレスを使用すると、次のようになります。

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 アドレスを使用しても、失敗メッセージはすべて非常に似ており、Postgres データベースにはデータや接続がまったく受信されません。何か間違っている点について、何か洞察はありますか?

また、VM インスタンスで Cloud SQL Auth Proxy を使用していないことが原因でしょうか?もしそうなら、プロキシを実行してアプリの再構築前に時間を計るスクリプトを作成する必要があると思います。これについて何か洞察はありますか?

お時間をいただきありがとうございます。

IPアドレスを切り替えながら数回再構築を試したところ、Discourseデータベースにテーブルが最終的に設定されたようです。そのため、何が起こっているのかさらに分からなくなりました。

元の指示はどのバージョンの Discourse 用に書かれたものか、どなたか教えていただけますか?

過去5年間、あるいはそれ以上、標準的なインストールで機能するはずです。

何か問題がありますか?

「いいね!」 1