تثبيت Discourse للتطوير باستخدام Docker

مرحباً،

أواجه هذه الرسالة عند محاولة تشغيل d/boot_dev --init

Errno::EACCES: Permission denied @ dir_s_mkdir - tmp
/src/config/boot.rb:23:in `<top (required)>'
/src/config/application.rb:16:in `require'
/src/config/application.rb:16:in `<top (required)>'
/src/Rakefile:7:in `require'
/src/Rakefile:7:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(راجع التتبع الكامل بتشغيل المهمة مع --trace)

هل لديك أي أفكار حول كيفية إصلاحها؟ حاولت البحث عنها في كل مكان لكن لم أجد أي حلول.

تعديل: تم إصلاحها عن طريق تنفيذ chmod -R 777 ~/discourse، لكنني الآن أواجه هذه الرسالة:

gifsicle worker: gifsicle not found; please provide proper binary or disable this worker (--no-gifsicle argument or :gifsicle => false through options)

إعجابَين (2)

هذه ليست مشكلة، فقد أزلنا استخدامها مؤخرًا، والتحذير ليس مصدر قلق. هل تعمل على كود Discourse قديم؟

4 إعجابات

لا، كان الأمر يتعلق بالإصدار الأخير. لكنني اتبعت هذا الدليل من DigitalOcean والآن يعمل بشكل مثالي.

إعجابَين (2)

كيف يمكن استخدام الإضافات في هذا النوع من الإعدادات؟
أحاول اتباع الإرشادات في https://meta.discourse.org/t/install-plugins-in-discourse/19157، لكن الرابط يشير إلى ملف /var/discourse/containers/app.yml، وهو غير موجود في مجلد discourse الخاص بي.

نجحت في إعداد بيئة تطوير لـ Discourse وأصبحت قادرة على اختبار التصحيح الخاص بي، لكن كيف يمكنني دمج هذا التصحيح في نسختي الإنتاجية؟ لقد حاولت بناء base، ثم تشغيل الأمر ./launcher rebuild app --run-image discourse/base:build، لكن يبدو أن هذا لا يؤدي إلى تشغيل مثيل Discourse.

عادةً ما أواجه خطأً يتعلق بغياب مجموعة syslog، لكنني قمت بتعليق هذا الجزء من الكود، ومع ذلك لم أتمكن من الحصول على موقع يعمل. كما لم ألاحظ أي شيء مهم في سجلات Docker.

نحن لا نوثق هذا النوع من الأمور فعليًا، لكن يمكنك إنشاء ملف “diff” ثم تطبيقه باستخدام git في hook بعد استنساخ المستودع. يدعم ملف app.yml الـ hooks.

الحل السريع وغير الرسمي للأنظمة المستضافة ذات الحاوية الواحدة هو ببساطة تعديل الكود في مكانه وتشغيل sv restart unicorn.

إعجابَين (2)

لست متأكدًا مما إذا كان هذا هو المكان الأنسب لطرح هذا السؤال، لكنني لم أستطع إكمال تثبيت Discourse باستخدام Docker على جهاز Apple M1.

بعد تشغيل الأمر d/boot_dev --init، يتم تثبيت جميع التبعيات دون أي مشكلة ظاهرة، ولكن بمجرد الوصول إلى خطوة Migrating database، يتوقف الأمر هناك ويستهلك 100% من أحد أنوية المعالج دون أي تقدم ملحوظ.

حاولت تسجيل الدخول إلى حاوية Docker، ووجدت أن مهمة bundle migrate تعمل بنسبة 100%، لكن لا توجد أي نشاط ظاهر على عملية PostgreSQL.

أي أفكار ستكون موضع تقدير كبير!

إعجاب واحد (1)

أعتقد أن دعم الافتراضية جديد جدًا جدًا، ولا أغترب أنه يمثل مغامرة بعض الشيء.

@pmusaraj / @david هل كانت لديكم أي حظ في جعل docker-dev يعمل على M1؟

5 إعجابات

لم أجربه بعد.

إعجابَين (2)

إذا كان بإمكان أي شخص تشغيل Discourse باستخدام Docker على جهاز Mac M1، فيرجى إخباري. وفي الوقت نفسه، سأحاول اتباع الدليل الآخر! شكرًا لك!

إعجاب واحد (1)

لقد حاولت اليوم لفترة وجيزة، وتوقفت عند نفس الخطوة التي توقفت فيها أنت، ولكن مع ظهور خطأ:

Invalid gemspec in [/usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec]: Malformed version number string specification_version
bundler: failed to load command: rake (/usr/local/bin/rake)

نعم، من فضلك افعل ذلك. هناك العديد من أعضاء الفريق يستخدمون Discourse على جهاز M1 (بما في ذلك أنا) يوميًا، لذا فهو يعمل بشكل ممتاز!

أخبرنا إذا واجهت أي مشاكل.

إعجابَين (2)

شكرًا جزيلاً لك على وقتك ومساعدتك! على الأقل لستُ الوحيد العالق مع هذا الأمر.

مرحبًا، أعتقد أنه يجب علينا إضافة وصف لـ Ember-CLI هنا، بالإضافة إلى اختصار للأوامر أدناه دون الحاجة للدخول إلى حاوية Docker.

ولم أستطع جعل الأمر يعمل بتنفيذ الأوامر أعلاه داخل الحاوية، يبدو أن الحاوية لم تعرض المنفذ 4200.
Screenshot from 2021-05-02 15-48-51

تم التعرض اليدوي للمنفذ 4200 عن طريق تعديل d/boot_dev:

بعد إعادة تشغيل الحاوية، قمت بالوصول إلى localhost:4200 وحصلت على هذا:

discourse@discourse:/tmp$ cat error.dump.cab4cc444229d44fc0fce2deb8695880.log 
=================================================================================

ENV Summary:

  TIME: Sun May 02 2021 08:01:12 GMT+0000 (Coordinated Universal Time)
  TITLE: ember
  ARGV:
  - /usr/bin/node
  - /src/app/assets/javascripts/node_modules/.bin/ember
  - server
  - --proxy
  - http://localhost:3000
  EXEC_PATH: /usr/bin/node
  TMPDIR: /tmp
  SHELL: /bin/bash
  PATH:
  - /tmp/yarn--1619942449179-0.1910991449592403
  - /src/app/assets/javascripts/discourse/node_modules/.bin
  - /home/discourse/.config/yarn/link/node_modules/.bin
  - /src/app/assets/javascripts/node_modules/.bin
  - /home/discourse/.yarn/bin
  - /usr/libexec/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/bin/node_modules/npm/bin/node-gyp-bin
  - /usr/local/sbin
  - /usr/local/bin
  - /usr/sbin
  - /usr/bin
  - /sbin
  - /bin
  PLATFORM: linux x64
  FREEMEM: 8603062272
  TOTALMEM: 41962496000
  UPTIME: 612639
  LOADAVG: 3.32177734375,2.19580078125,1.47900390625
  CPUS:
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  ENDIANNESS: LE
  VERSIONS:
  - ares: 1.15.0
  - brotli: 1.0.7
  - cldr: 35.1
  - http_parser: 2.9.3
  - icu: 64.2
  - modules: 64
  - napi: 7
  - nghttp2: 1.41.0
  - node: 10.23.0
  - openssl: 1.1.1g
  - tz: 2019c
  - unicode: 12.1
  - uv: 1.34.2
  - v8: 6.8.275.32-node.59
  - zlib: 1.2.11

ERROR Summary:

  - broccoliBuilderErrorStack: [undefined]
  - code: ECONNREFUSED
  - codeFrame: [undefined]
  - errorMessage: connect ECONNREFUSED 127.0.0.1:3000
  - errorType: [undefined]
  - location:
    - column: [undefined]
    - file: [undefined]
    - line: [undefined]
  - message: connect ECONNREFUSED 127.0.0.1:3000
  - name: Error
  - nodeAnnotation: [undefined]
  - nodeName: [undefined]
  - originalErrorMessage: [undefined]
  - stack: Error: connect ECONNREFUSED 127.0.0.1:3000
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)

=================================================================================

بعد تعديل bin/ember-cli لتغيير المنفذ من 3000 إلى 9292، عمل كل شيء بشكل صحيح.
Screenshot from 2021-05-02 17-55-24

يبدو أن ملف ember-cli Bash غير قادر على العمل مع ENV["UNICORN_PORT"].

إعجاب واحد (1)

إن Ember CLI هو تطور جديد (وقد خُوض من أجله نضال شاق)، ومن المتوقع أن يعلق @eviltrout على ذلك قريبًا.

3 إعجابات

نعم، سيتعين تحديث ذلك. في غضون ذلك، يمكنك تعطيله عن طريق تعيين متغير البيئة NO_EMBER_CLI إلى 1.

5 إعجابات

ربما يكون الأمر واضحًا، لكن هل يمكنك توضيح أين تقوم بتعيين متغير البيئة @eviltrout؟

لقد جربت ذلك في ملف d/unicorn على النحو التالي:

docker exec -it -u discourse:discourse discourse_dev /bin/bash -c "$CMD" -e NO_EMBER_CLI=1

…لكن هذا لم ينجح (لا يزال يظهر لي رسالة “Ember CLI مطلوب في وضع التطوير” على localhost:9292).

d/boot_dev -e NO_EMBER_CLI=1

لقد جربت ذلك اليوم، وواجهت أيضًا بعض المشكلات. كان الخطأ الذي ظهر بسبب أن محاكاة البنية في Docker لا تدعم inotify (الذي نستخدمه بكثرة في تطوير Discourse). لحسن الحظ، أضفت تحذيرًا إلى d/boot_dev عند اكتشاف بنية غير x86_64:

❯ d/boot_dev 
تحذير: بنية Docker ليست x86_64.
من غير المرجح أن يعمل تطوير Discourse باستخدام محاكاة بنية Docker.
يرجى تجربة تثبيت تطوير أصلي.

لقد أضفت الآن أداة مساعدة d/ember-cli، وقمت بتوجيه المنفذ 4200 افتراضيًا. كما تم تحديث المعلومات في أعلى هذا الموضوع. بعد التحديث، قم بتشغيل d/rails s في أحد طرفيات الأوامر، و d/ember-cli في طرفية أخرى. كما قمت بتعيين NO_EMBER_CLI كواحد من المتغيرات التي يتم تمريرها إلى Docker، بحيث تكون متاحة عند الحاجة.

6 إعجابات

@david ربما لا يهم، ولكن فقط للإعلام: يُظهر سكريبت boot_dev خطأً زائفاً في فحص x86_64 عندما قمت بتشغيله بالخطأ دون Docker على… (لكن جزء “هل يعمل خادم Docker؟” صحيح)…

WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.
  ...(snip)...
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
إعجاب واحد (1)

شكرًا لك على هذه الصورة والتعليمات الواضحة جدًا!

لقد حصلت على psql: error: FATAL: Peer authentication failed for user "postgres" عند تشغيل d/boot_dev --init.

على الرغم من أن ملف pg_hba.conf في data/postgres/ كان يحتوي على جميع طرق المصادقة مضبوطة على “trust”، إلا أن هناك ملفًا آخر في /etc/postgresql/13/main/ يحتوي على الإعدادات الافتراضية (“peer” / “md5”).

لقد قمت بتعديل /etc/postgresql/13/main/pg_hba.conf، وغيّرت جميع الطرق إلى trust، ثم نفذت d/shell وشغّلت sv restart postgres لتطبيق التغييرات – وتمكنت من المتابعة بتشغيل d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create يدويًا.

أترك هذا هنا في حال كان مفيدًا لأي شخص آخر!

إعجاب واحد (1)