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 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 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;
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
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?
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.
Yes, you can bootstrap it elsewhere and then move the data to your production PostgreSQL.
However this will make updates very cumbersome.
ثلاثة أشياء يجب البحث عنها.
أولاً: افتراضيًا، يستمع 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.
هل هناك أي خطر من مسح الجداول الموجودة في حالة استخدام قاعدة بيانات موجودة؟
أيضًا، هل هناك طريقة لإضافة بادئة لجداول 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 العام لمثيل postgres في تكوين app.yml، فعند إعادة بناء التطبيق، أحصل على ما يلي:
فشل
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' فشل مع العودة #<Process::Status: pid 1024 exit 1>
موقع الفشل: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
فشل التنفيذ مع المعلمات {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
فشل التمهيد برمز خروج 1
** فشل التمهيد ** يرجى التمرير لأعلى والبحث عن رسائل خطأ سابقة، قد يكون هناك أكثر من رسالة واحدة.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
a6a71b00bce378aa6334ae1c9fe103778d260bb699fe598f9685689e8b5ce450
فقط لمعرفة ما يحدث، حاولت استخدام عناوين IP الأخرى لمثيل postgres.
إذا استخدمت عنوان IP الخاص لمثيل postgres، أحصل على ما يلي:
فشل
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' فشل مع العودة #<Process::Status: pid 1024 exit 1>
موقع الفشل: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
فشل التنفيذ مع المعلمات {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
فشل التمهيد برمز خروج 1
** فشل التمهيد ** يرجى التمرير لأعلى والبحث عن رسائل خطأ سابقة، قد يكون هناك أكثر من رسالة واحدة.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
7333126c522eb51ace4d55ea89803eea54b96704baab70c322008cf2836ba47a
إذا استخدمت عنوان IP الصادر لمثيل postgres، أحصل على ما يلي:
فشل
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' فشل مع العودة #<Process::Status: pid 1026 exit 1>
موقع الفشل: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
فشل التنفيذ مع المعلمات {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
فشل التمهيد برمز خروج 1
** فشل التمهيد ** يرجى التمرير لأعلى والبحث عن رسائل خطأ سابقة، قد يكون هناك أكثر من رسالة واحدة.
قد يساعد ./discourse-doctor في تشخيص المشكلة.
c588d2b6977b9e7d493b0b59bc694369cb7c2219de67d5886112ed16312626ae
باستخدام جميع عناوين IP المختلفة، تكون الرسائل الفاشلة متشابهة جدًا ولا تتلقى قاعدة بيانات postgres أي بيانات أو اتصالات على الإطلاق. هل لدى أي شخص أي رؤية حول ما أفعله بشكل خاطئ؟
أيضًا، هل مشكلتي ناتجة عن عدم استخدام Cloud SQL Auth Proxy على مثيل الجهاز الافتراضي؟ إذا كان الأمر كذلك، أعتقد أنني سأضطر إلى بناء برنامج نصي لتشغيل الوكيل وتوقيته قبل إعادة بناء التطبيق. هل لدى أي شخص أي رؤية حول ذلك؟
شكرا على وقتكم يا رفاق.
لقد حاولت إعادة البناء عدة مرات أخرى مع التبديل بين عناوين IP ويبدو أن قاعدة بيانات discourse قد تم ملؤها بالجداول في النهاية. لذا أنا الآن أكثر حيرة بشأن ما يحدث
هل يمكن لأحد أن يخبرني عن إصدار Discourse الذي كُتبت له التعليمات الأصلية؟
يجب أن يعمل مع تثبيت قياسي للسنوات الخمس الماضية أو ربما إلى الأبد.
هل تواجه مشكلة؟