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:
git clone https://github.com/discourse/discourse.gitcd discourse-
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"
-
vim bin/docker/boot_dev, find the line starting withdocker 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/unicorn- you may need to run migrations:
docker exec -it discourse_dev /bin/bash -c "cd /src; ./bin/rails db:migrate RAILS_ENV=development" - 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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
Yes, you can bootstrap it elsewhere and then move the data to your production PostgreSQL.
However this will make updates very cumbersome.
2 Mi Piace
Tre cose da cercare.
Uno: per impostazione predefinita, PostgreSQL ascolta su localhost. Modifica l’indirizzo di ascolto nel file postgresql.conf come mostrato di seguito.
listen_addresses = ‘localhost,172.17.0.1’
Due: consiglia a PostgreSQL di accettare connessioni dalle immagini Docker aggiungendo la seguente riga al file pg_hba.conf.
host all all 172.17.0.0/16 scram-sha-256
Riavvia il servizio PostgreSQL dopo le due modifiche precedenti.
Tre: se ancora non riesci a connetterti, controlla il firewall che potrebbe bloccare le connessioni in entrata sulla porta 5432.
2 Mi Piace
@Falco c’è qualche rischio di cancellare le tabelle esistenti nel caso in cui utilizzassi un DB esistente?
Inoltre, c’è un modo per aggiungere un prefisso alle tabelle di discourse?
No, a meno che non siano in conflitto con i nomi di Discourse.
Ma penso che sia una cattiva idea.
No. Ti consiglio di utilizzare un database separato a meno che non ci sia un motivo per cui debbano essere collegati.
Quale problema stai risolvendo condividendo un database?
1 Mi Piace
Grazie, sto usando AWS RDS, ho appena scoperto che posso avere più DB sulla stessa istanza, quindi ho creato un nuovo DB con un nuovo utente.
2 Mi Piace
Ho un’istanza Discourse appena installata in esecuzione tramite docker in una VM su Google Cloud. Attualmente ho abilitato i caricamenti di file e i backup di discourse sui bucket su Google Cloud e queste funzioni funzionano correttamente dopo aver seguito le istruzioni nel thread Configure an S3 compatible object storage provider for uploads. Posso vedere i caricamenti di prova nel bucket e quando guardo gli URL di caricamento, tutti i caricamenti mostrano l’URL corretto dal CDN, quindi sembrano essere estratti correttamente dal bucket.
Ho quindi creato un’istanza PostgreSQL 15.2 su Google Cloud ed eseguito la procedura di configurazione del database descritta nel primo post e configurato anche il file app.yml. La porta predefinita per PostgreSQL su Google Cloud è 5432, quindi ho omesso quelle righe.
Se uso l’indirizzo IP pubblico dell’istanza postgres nella configurazione di app.yml, quando ricostruisco l’app, ottengo quanto segue:
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
Solo per vedere cosa sta succedendo, ho provato a usare gli altri IP dell’istanza postgres.
Se uso l’indirizzo IP privato dell’istanza postgres, ottengo quanto segue:
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
Se uso l’indirizzo IP in uscita dell’istanza postgres, ottengo quanto segue:
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
Usando tutti i diversi IP, i messaggi di errore sono molto simili e il database postgres non riceve alcun dato o connessione. Qualcuno ha qualche idea su cosa sto sbagliando?
Inoltre, il mio problema è causato dal non utilizzo del Cloud SQL Auth Proxy sull’istanza VM? Se è così, dovrò creare uno script per eseguire il proxy e cronometrarlo prima della ricostruzione dell’app. Qualcuno ha qualche idea a riguardo?
Grazie per il tempo ragazzi.
Ho provato a ricostruire alcune altre volte passando da un IP all’altro e sembra che il database di discourse si sia finalmente popolato con le tabelle. Quindi ora sono ancora più perplesso su cosa stia succedendo.
Qualcuno potrebbe dirmi per quale versione di Discourse sono state scritte le istruzioni originali?
Dovrebbe funzionare per un’installazione standard degli ultimi 5 anni o forse per sempre.
Hai un problema?
1 Mi Piace