Configurer Discourse pour utiliser un serveur PostgreSQL séparé

Documentation Auto-hébergement
23

Thanks

Anu reference or file need to be removed?

24

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 « J'aime »
25

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
26

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 « J'aime »
27

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 « J'aime »
28

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 « J'aime »
29

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 « J'aime »
30

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 « J'aime »
31

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

32

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 « J'aime »
33

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 « J'aime »
34

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

However this will make updates very cumbersome.

2 « J'aime »
35

Trois choses à surveiller.

Un : par défaut, PostgreSQL écoute sur localhost. Modifiez l’adresse d’écoute dans le fichier postgresql.conf comme indiqué ci-dessous.

listen_addresses = ‘localhost,172.17.0.1’

Deux : conseillez à PostgreSQL d’accepter les connexions des images Docker en ajoutant la ligne suivante au fichier pg_hba.conf.

host all all 172.17.0.0/16 scram-sha-256

Redémarrez le service PostgreSQL après les deux modifications ci-dessus.

Trois : si vous ne parvenez toujours pas à vous connecter, vérifiez le pare-feu qui pourrait bloquer les connexions entrantes sur le port 5432.

2 « J'aime »
36

@Falco y a-t-il un risque d’effacer les tables existantes si j’utilise une base de données existante ?
Existe-t-il également un moyen d’ajouter un préfixe aux tables Discourse ?

37

Non, à moins qu’elles n’entrent en conflit avec les noms de Discourse.

Mais je pense que c’est une mauvaise idée.

Non. Je vous recommande d’utiliser une base de données distincte, sauf s’il y a une raison pour qu’elles doivent être connectées.

Quel problème résolvez-vous en partageant une base de données ?

1 « J'aime »
38

Merci, j’utilise AWS RDS, je viens de découvrir que je peux avoir plusieurs bases de données sur la même instance, j’ai donc créé une nouvelle base de données avec un nouvel utilisateur.

2 « J'aime »
39

J’ai une instance Discourse nouvellement installée fonctionnant via Docker dans une VM sur Google Cloud. J’ai actuellement activé les téléchargements de fichiers et les sauvegardes Discourse vers des buckets sur Google Cloud, et ces fonctions fonctionnent correctement après avoir suivi les instructions du fil Configurer un fournisseur de stockage d’objets compatible S3 pour les téléchargements. Je peux voir les téléchargements de test dans le bucket et lorsque je regarde les URL de téléchargement, tous les téléchargements affichent la bonne URL depuis le CDN, donc ils semblent être correctement récupérés du bucket.

J’ai ensuite créé une instance PostgreSQL 15.2 sur Google Cloud et j’ai suivi la procédure de configuration de la base de données décrite dans le premier post et configuré le fichier app.yml également. Le port par défaut pour PostgreSQL sur Google Cloud est 5432, j’ai donc omis ces lignes.
Si j’utilise l’adresse IP publique de l’instance postgres dans la configuration app.yml, lorsque je reconstruis l’application, j’obtiens ce qui suit :

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

Juste pour voir ce qui se passe, j’ai essayé d’utiliser les autres adresses IP de l’instance postgres.
Si j’utilise l’adresse IP privée de l’instance postgres, j’obtiens ce qui suit :

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

Si j’utilise l’adresse IP sortante de l’instance postgres, j’obtiens ce qui suit :

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

En utilisant toutes les différentes adresses IP, les messages d’échec sont très similaires et la base de données postgres ne reçoit aucune donnée ni aucune connexion. Quelqu’un a-t-il une idée de ce que je fais mal ?

Mon problème est-il également causé par le fait de ne pas utiliser le Cloud SQL Auth Proxy sur l’instance VM ? Si c’est le cas, je suppose que je devrai créer un script pour exécuter le proxy et le chronométrer avant la reconstruction de l’application. Quelqu’un a-t-il une idée à ce sujet ?

Merci pour votre temps.

40

J’ai essayé de reconstruire plusieurs fois en changeant d’IP et il semble que la base de données discourse ait fini par se peupler de tables. Je suis donc encore plus perplexe quant à ce qui se passe.

41

quelqu’un pourrait-il me dire pour quelle version de Discourse les instructions originales ont été écrites ?

42

Cela devrait fonctionner pour une installation standard depuis 5 ans ou peut-être pour toujours.

Avez-vous un problème ?

1 « J'aime »