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 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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
Hallo,
vielen Dank für Ihren wirklich tollen Leitfaden.
Leider ist mir bei der Nachbildung ein Fehler unterlaufen.
Zunächst habe ich Discourse mit dem Launcher für alle Komponenten (App/Redis/Postgres) erstellt, und das hat einwandfrei funktioniert.
Beim Versuch mit einer externen RDS-Instanz jedoch ist der Launcher fehlgeschlagen:
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.
Bitte geben Sie mir einen Rat, wie ich dieses Problem lösen kann.
Vielen Dank,
Alexander K
Gibt es eine Möglichkeit, die Datenbank vorab zu erstellen und mit Daten zu füllen, ohne die Migrationsschritte durchlaufen zu müssen? Wir laufen auf AKS mit einer externen PostgreSQL-Datenbank, und die Einrichtung der Datenbank scheint für mich ungewöhnlich lange zu dauern (~8–9 Minuten). Eine Beschleunigung wäre großartig. Oder ist dies ein bekanntes Problem in dieser Konfiguration?
1 „Gefällt mir“
Das ist keine unterstützte Konfiguration.
Wenn du ein Image erstellst, werden deutlich mehr Komponenten als nur die Datenbank erstellt – beispielsweise werden eine Reihe von Templates vorab kompiliert. Ich denke, das liegt einfach daran, wie lange dieser Vorgang dauert.
1 „Gefällt mir“
Ja, Sie können sie woanders initialisieren und die Daten dann in Ihre Produktions-PostgreSQL verschieben.
Dies macht Updates jedoch sehr umständlich.
2 „Gefällt mir“
Drei Dinge, auf die Sie achten sollten.
Erstens: Standardmäßig lauscht PostgreSQL auf localhost. Ändern Sie die Listenadresse in der Datei postgresql.conf wie unten gezeigt.
listen_addresses = ‘localhost,172.17.0.1’
Zweitens: Weisen Sie PostgreSQL an, Verbindungen von Docker-Images zu akzeptieren, indem Sie die folgende Zeile zur Datei pg_hba.conf hinzufügen.
host all all 172.17.0.0/16 scram-sha-256
Starten Sie den PostgreSQL-Dienst nach den beiden obigen Änderungen neu.
Drittens: Wenn Sie immer noch keine Verbindung herstellen können, überprüfen Sie die Firewall, die möglicherweise eingehende Verbindungen an Port 5432 blockiert.
2 „Gefällt mir“
@Falco besteht die Gefahr, dass vorhandene Tabellen gelöscht werden, falls ich eine vorhandene DB verwende? Gibt es außerdem eine Möglichkeit, den Discourse-Tabellen ein Präfix hinzuzufügen?
Nein, es sei denn, sie stehen im Konflikt mit Discourse-Namen.
Aber ich halte es für eine schlechte Idee.
Nein. Ich empfehle Ihnen, eine separate Datenbank zu verwenden, es sei denn, es gibt einen Grund, warum sie verbunden sein müssen.
Welches Problem lösen Sie, indem Sie eine Datenbank teilen?
1 „Gefällt mir“
Danke, ich benutze AWS RDS, ich habe gerade festgestellt, dass ich mehrere Datenbanken auf derselben Instanz haben kann, daher habe ich eine neue Datenbank mit einem neuen Benutzer erstellt.
2 „Gefällt mir“
Ich habe eine neu installierte Discourse-Instanz, die über Docker in einer VM auf Google Cloud läuft. Ich habe derzeit Datei-Uploads und Discourse-Backups in Buckets auf Google Cloud aktiviert, und diese Funktionen funktionieren ordnungsgemäß, nachdem ich die Anweisungen im Thread Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads befolgt habe. Ich kann die Test-Uploads im Bucket sehen und wenn ich mir die Upload-URLs ansehe, werden alle Uploads mit der richtigen URL vom CDN angezeigt, sodass sie korrekt aus dem Bucket zu stammen scheinen.
Ich habe dann eine PostgreSQL 15.2-Instanz auf Google Cloud erstellt und das Datenbank-Setup-Verfahren durchgeführt, das im ersten Beitrag beschrieben ist, und die Datei app.yml konfiguriert. Der Standardport für PostgreSQL auf Google Cloud ist 5432, daher habe ich diese Zeilen weggelassen.
Wenn ich die öffentliche IP-Adresse der Postgres-Instanz in der app.yml-Konfiguration verwende, erhalte ich beim Neuerstellen der App Folgendes:
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Ort des Fehlers: /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
** BOOTSTRAP FEHLGESCHLAGEN ** bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
a6a71b00bce378aa6334ae1c9fe103778d260bb699fe598f9685689e8b5ce450
Nur um zu sehen, was passiert, habe ich versucht, die anderen IPs der Postgres-Instanz zu verwenden.
Wenn ich die private IP-Adresse der Postgres-Instanz verwende, erhalte ich Folgendes:
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1024 exit 1>
Ort des Fehlers: /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
** BOOTSTRAP FEHLGESCHLAGEN ** bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
7333126c522eb51ace4d55ea89803eea54b96704baab70c322008cf2836ba47a
Wenn ich die ausgehende IP-Adresse der Postgres-Instanz verwende, erhalte ich Folgendes:
FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1026 exit 1>
Ort des Fehlers: /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
** BOOTSTRAP FEHLGESCHLAGEN ** bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
c588d2b6977b9e7d493b0b59bc694369cb7c2219de67d5886112ed16312626ae
Bei Verwendung aller verschiedenen IPs sind die fehlgeschlagenen Meldungen alle sehr ähnlich und die Postgres-Datenbank empfängt überhaupt keine Daten oder Verbindungen. Hat jemand eine Einsicht, was ich falsch mache?
Wird mein Problem auch dadurch verursacht, dass ich den Cloud SQL Auth Proxy nicht auf der VM-Instanz verwende? Wenn ja, muss ich wohl ein Skript erstellen, um den Proxy auszuführen und ihn vor dem Neuerstellen der App zu timen. Hat jemand dazu eine Einsicht?
Danke für die Zeit, Leute.
Ich habe versucht, ein paar weitere Male neu zu erstellen, wobei ich zwischen den IPs gewechselt habe, und es scheint, dass die Discourse-Datenbank schließlich mit Tabellen gefüllt wurde. Jetzt bin ich noch mehr ratlos, was vor sich geht.
Könnte mir bitte jemand mitteilen, für welche Version von Discourse die ursprünglichen Anweisungen geschrieben wurden?
Es sollte für eine Standardinstallation der letzten 5 Jahre oder vielleicht für immer funktionieren.
Haben Sie ein Problem?
1 „Gefällt mir“