Install Discourse for development using Docker

[pfaffman (Jay Pfaffman)]

لقد جربت هذا على جهازيْن الآن وكلاهما يفشل بخطأ في الأذونات.

pfaffman@shinytim:~/src/discourse-repos/discourse$ d/bundle install
Bundler 2.4.2 is running, but your lockfile was generated with 2.4.1. Installing Bundler 2.4.1 and restarting using that version.
Fetching gem metadata from https://rubygems.org/.
Fetching bundler 2.4.1

Retrying download gem from https://rubygems.org/ due to error (2/4): Bundler::PermissionError There was an error while trying to write to `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`. It is likely that you need to grant write permissions for that path.

Retrying download gem from https://rubygems.org/ due to error (3/4): Bundler::PermissionError There was an error while trying to write to `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`. It is likely that you need to grant write permissions for that path.

Retrying download gem from https://rubygems.org/ due to error (4/4): Bundler::PermissionError There was an error while trying to write to `/usr/local/lib/ruby/gems/3.1.0/cache/bundler-2.4.1.gem`. It is likely that you need to grant write permissions for that path.

There was an error installing the locked bundler version (2.4.1), rerun with the `--verbose` flag for more details. Going on using bundler 2.4.2.
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/discourse/mail.git
There was an error while trying to write to `/usr/local/lib/ruby/gems/3.1.0/cache/bundler/git`.
It is likely that you need to grant write permissions for that path.

[topological]

واجهت هذه المشكلة أيضًا.

[Aleksey_Bogdanov]

هل هناك أي تحديثات حول هذا؟

[musli123123]

مرحباً،

أنا جديد تماماً وعديم الخبرة. أحاول إعداد Discourse على بيئة تطوير Ubuntu 22.04 قبل نشره على GitHub ثم على الخادم (ليس لدي فكرة عن كيفية القيام بذلك ولكن هذا لا يهم الآن).

لقد حاولت تثبيت Discourse محلياً باستخدام docker (باستخدام هذا الدليل).

أعتقد أنني قمت بتثبيت docker بشكل صحيح، ولكن عندما أكتب:

sudo d/rails s

أتلقى “GitHub - discourse/mail: A Really Ruby Mail Library لم يتم سحبه بعد. قم بتشغيل bundle install أولاً.”

وعندما أقوم بتشغيل:

sudo d/bundle install

أتلقى:
“جلب GitHub - discourse/mail: A Really Ruby Mail Library
حدث خطأ أثناء محاولة الكتابة إلى
/usr/local/lib/ruby/gems/3.1.0/cache/bundler/git. من المحتمل أن تحتاج
إلى منح أذونات الكتابة لهذا المسار.”

الرجاء تقديم المشورة

[ckjhdmmwxx]

تم إنشاء طلب سحب لإصلاح هذا - Setting bundler version to 2.4.1 which is same as version that generated lockfile to avoid failing script by nkirit · Pull Request #665 · discourse/discourse_docker · GitHub

[david (David Taylor)]

شكرًا على التقارير - يجب إصلاح هذا بواسطة هذا الالتزام

البناء قيد التشغيل وبالتالي يجب دفع صورة discourse_dev:release جديدة في غضون الساعة القادمة. بعد ذلك، ستحتاج إلى d/shutdown_dev و d/boot_dev لتطبيق التغييرات.

[MorphZan]

كيف يمكنني تعيين/منح هذه الحاوية عنوان IP ثابتًا محددًا؟

[zergov (Jonathan Lalande)]

مرحباً! لقد واجهت نفس الخطأ.
تمكنت من إصلاحه بالذهاب إلى app/assets/javascripts وتشغيل yarn قبل تشغيل d/boot_dev --init.
فرضيتي هي أن d/boot_dev --init يفترض أن node_modules موجود في مكان ما أثناء تنفيذه. يفشل هذا لأنه غير موجود إذا قمت للتو باستنساخ المستودع.

[MarcP]

بعد اتباع هذا البرنامج التعليمي على Ubuntu 22، ينتهي الأمر d/boot_dev --init بالخرج التالي:

ترحيل قاعدة البيانات...
تم إلغاء rake!
Discourse::Utils::CommandError: /src/lib/discourse.rb:137:in `exec': mkdir: لا يمكن إنشاء الدليل ‘/src/public/plugins/’: رفض الإذن
/src/lib/discourse.rb:171:in `execute_command'
/src/lib/discourse.rb:137:in `exec'
/src/lib/discourse.rb:33:in `execute_command'
/src/lib/plugin/instance.rb:727:in `activate!'
/src/lib/discourse.rb:352:in `block in activate_plugins!'
/src/lib/discourse.rb:349:in `each'
/src/lib/discourse.rb:349:in `activate_plugins!'
/src/config/application.rb:216:in `block in <class:Application>'
/src/lib/plugin.rb:6:in `initialization_guard'
/src/config/application.rb:216:in `<class:Application>'
/src/config/application.rb:75:in `<module:Discourse>'
/src/config/application.rb:74:in `<main>'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/src/.bundle/gems/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/src/Rakefile:7:in `<main>'
(انظر التتبع الكامل عن طريق تشغيل المهمة باستخدام --trace)

هل هذا البرنامج التعليمي لا يزال محدثًا؟

[thoka (Thomas Kalka)]

لتنفيذ الأوامر (d/command) بدون sudo، يجب عليك إضافة نفسك إلى مجموعة docker عبر

sudo adduser $(whoami) docker

وسجل الدخول مرة أخرى.

[GregorSondermeier]

@MarcP

بعد اتباع هذا البرنامج التعليمي على Ubuntu 22، ينتهي الأمر بـ d/boot_dev --init بالخرج التالي:

مرحباً،
أواجه نفس المشكلة بالضبط.

@thoka

لتنفيذ الأوامر (d/command) بدون sudo، يجب عليك إضافة نفسك إلى مجموعة docker عبر

sudo adduser $(whoami) docker

وسجل الدخول مرة أخرى.

لقد فعلت ذلك:
لقد أضفت نفسي إلى مجموعة docker وأعدت تشغيل النظام. لقد تحققت باستخدام الأمر groups من أنني بالفعل جزء من مجموعة docker.

لا يزال هذا الخطأ يظهر.

أنا أستخدم Ubuntu 22.04 وكان لدي بالفعل Docker مثبتًا عبر Docker Desktop لمشاريع أخرى. حساب المستخدم الذي أعمل معه ليس لديه امتيازات إدارية (ليس جزءًا من مجموعة sudo)، ولكن لدي وصول إلى حساب لديه هذه الامتيازات. ومع ذلك، لا يمكنني استخدام هذا الحساب الآخر لعملي اليومي.
هل هذه مشكلة؟

[thoka (Thomas Kalka)]

@GregorSondermeier

أنا على Ubuntu 22.04 وكان لدي بالفعل docker مثبتًا عبر docker desktop لمشاريع أخرى.

همم. هل أنت على جهاز Ubuntu 22.04 فعلي أم تشغله كجهاز افتراضي WSL؟

[GregorSondermeier]

Bare metal. Ubuntu 22.04 قيد التشغيل أصليًا على حاسوبي المحمول في العمل.

لقد لاحظت ما يلي:
مجلد حاوية /src مُثبّت على /home/gregor/repos/discourse على جهازي المضيف:

على جهازي المضيف، بعد سحب مستودع git، ينتمي هذا المجلد إليّ وإلى مجموعتي:

repos $ whoami
gregor
repos $ groups
gregor docker
repos $ pwd
/home/gregor/repos
repos $ ll
[...]
drwxrwxr-x 21 gregor gregor 4096 Mär 24 10:57 discourse/
[...]

تنفيذ البرامج النصية d/* لجميع الأوامر داخل حاوية docker كمستخدم discourse (انظر هنا). وهذا المستخدم discourse ليس لديه إذن الكتابة إلى المجلد المُثبّت /src.

rake aborted!
Discourse::Utils::CommandError: /src/lib/discourse.rb:137:in `exec': mkdir: cannot create directory ‘/src/public/plugins/’: Permission denied

يمكنني تكرار هذا إذا قمت بتسجيل الدخول إلى الحاوية وحاولت إنشاء مجلدات فيها. إذا قمت بذلك كمستخدم الجذر، فسينجح الأمر.

على جهازي المضيف:

إذا قمت بذلك كمستخدم discourse، فسيفشل الأمر:

ومع ذلك، لا يمكنني ربط هذا معًا تمامًا

[thoka (Thomas Kalka)]

حسناً. أنا أشغل أوبونتو 22.04 داخل WSL في ويندوز:

بعد d/shell:

و

$ docker inspect -f "{{ .Mounts }}" discourse_dev
[{bind  /home/toka/dv/discourse/discourse/data/postgres /shared/postgres_data  delegated true rprivate}
 {bind  /home/toka/dv/discourse/discourse /src  delegated true rprivate}]

[ClawdiaWolf (Claudia)]

@GregorSondermeier

تنفذ البرامج النصية d/* جميع الأوامر داخل حاوية docker كمستخدم discourse (انظر هنا). وهذا المستخدم discourse ليس لديه صلاحيات الكتابة على المجلد /src الذي تم تحميله.

هل معرف المستخدم (UID) الخاص بك على المضيف مختلف عن 1000 بالصدفة؟ إذا كان الأمر كذلك، فهذه هي المشكلة. مستخدم Discourse داخل Docker هو UID 1000، لذا يجب أن تكون ملفات المضيف قابلة للكتابة بواسطة UID 1000.

[GregorSondermeier]

هذا المنشور على Stack Overflow أشارني في نفس الاتجاه الذي سلكته. يمكنني تأكيد أن كلاً من المستخدم gregor الخاص بي على الجهاز المضيف والمستخدم discourse في الحاوية لهما نفس المعرف 1000.

[thoka (Thomas Kalka)]

ما هو ناتج d/exec ls -lan و echo $UID؟

[GregorSondermeier]

بعد تشغيل d/shell:

أرى أن جميع الملفات مملوكة لـ root وليست لـ discourse كما في لقطة الشاشة الخاصة بك.

(كان لدي منشور سابق أظهر nobody/nogroup، وكان مضللاً لأنني عبثت بإنشاء مستخدم ومجموعة discourse على جهازي المضيف، مما لم يؤد إلى أي نجاح. لذلك حذفت المنشور)

[GregorSondermeier]

يشير إلى أن جميع الملفات داخل /src مملوكة للمستخدم الجذر.

(تأتي مجموعة discourse من محاولة سابقة لم تكن مثمرة)

شكراً جزيلاً على مساعدتك بالمناسبة. أشعر ببعض الغباء، لا بد أنني أفتقد بعض المعرفة حول نظام أذونات يونكس.

[GregorSondermeier]

بعد الكثير من البحث والتجريب، تعلمت أن Docker Desktop على Linux هو سبب مشاكل الأذونات.

كما تعلم، يتم تشغيل تطبيق Discourse في حاوية Docker كمستخدم غير جذر، وهو المستخدم discourse. ولكن كما هو مكتوب على سبيل المثال هنا و هنا:

يعمل Docker Desktop على Linux على جهاز افتراضي وستعمل الحاويات داخل هذا الجهاز الافتراضي. في هذه الحالة، لا يمكنك ببساطة تحميل مجلد المضيف بنفس الطريقة في الحاويات، لأنك تحتاج إلى تحميله أولاً في الجهاز الافتراضي.

لذلك، كشخص ليس خبيرًا في Docker بأي حال من الأحوال، أرى طريقتين لمعالجة هذه المشكلة:

(1) التخلي عن Docker Desktop على Linux وتشغيل Docker أصليًا بدلاً من ذلك

يبدو هذا هو الحل الأكثر استدامة حيث أرى أن حاوية Discourse تبدو مصممة للاستخدام بهذه الطريقة. أنا متردد فقط لأنني سأضطر إلى تذكر جميع الأوامر لإدارة صوري وحاوياتي ومواردي. وبصفتي مطور واجهة أمامية، أفضل واجهة مستخدم لإدارة الأشياء. لكن أعتقد أنني يجب أن أتعامل مع هذا كاستثمار لتعلم المزيد عن Docker.

أو

(2) تغيير ملكية المجلدات المحملة في الحاوية

تمكنت من جعل هذا النهج يعمل وتشغيل Discourse بنجاح محليًا من Docker Desktop، ومع ذلك أرى الكثير من التحذيرات في Terminal ولذلك لست متأكدًا من مدى استدامة هذا الحل على المدى الطويل.

يتضمن هذا عدة خطوات:

الخطوة 1: استنساخ المستودع

$ git clone https://github.com/discourse/discourse.git
$ cd discourse

الخطوة 2: تهيئة الحاوية

من داخل مجلد discourse المستنسخ على الجهاز المضيف، قم بتنفيذ:

$ d/boot_dev

ماذا يفعل؟ انظر هنا.
هام: احذف العلامة --init حتى لا يتم فعل أي شيء بعد إنشاء الحاوية.

الخطوة 3: تغيير مالك المجلدات

المستخدم discourse داخل حاوية docker لديه المعرف 1000. يفترض هذا الدليل أن المستخدم الخاص بجهازك المضيف لديه نفس المعرف. قد لا يؤدي ذلك إلى تعطيل الأشياء إذا كان لدى المستخدم الخاص بجهازك المضيف معرف مختلف، ولكن لا يمكنني اختبار ذلك وبالتالي لا يمكنني التحدث عن هذا الموقف. يمكنك معرفة معرفك عن طريق تنفيذ id أو echo $UID في طرفية لينكس.

من جهازك المضيف، قم بتنفيذ:

# افتح طرفية في حاوية docker
$ d/shell

# يجب أن تكون بالفعل في /src، ولكن فقط للتأكد:
$ cd /src

# تغيير مالك /src إلى مستخدم ومجموعة discourse
$ chown 1000:1000 .

# تغيير مالك جميع الملفات والمجلدات داخل /src إلى مستخدم ومجموعة discourse (بشكل غير تكراري)
$ chown 1000:1000 *

# تغيير مالك جميع المجلدات الفرعية تقريبًا بشكل تكراري إلى مستخدم ومجموعة discourse
# أساسًا جميع المجلدات باستثناء 'database'، لأن هذا ينتمي إلى مستخدم ومجموعة 'postgres'
$ chown -R 1000:1000 app bin config d db docs documentation images lib log plugins public script spec test vendor

# التحقق من أن ذلك قد نجح، يجب أن يظهر مستخدم ومجموعة discourse الآن
$ ls -l

# اخرج من الحاوية
$ exit

الخطوة 4: المتابعة كالمعتاد

تابع إعداد الحاوية وبدء Discourse عن طريق تنفيذ ما يلي من جهازك المضيف:

# تثبيت gems
$ d/bundle install

# ترحيل قاعدة البيانات
$ d/rake db:migrate
$ RAILS_ENV=test d/rake db:migrate

# إنشاء مستخدم مسؤول
$ d/rake admin:create

# في طرفية واحدة:
d/rails s

# وفي طرفية منفصلة
d/ember-cli

ملاحظة:
واجهت بعض التحذيرات مثل هذه:
fatal: detected dubious ownership in repository at '/src'
والتي تأتي من شيء المحاكاة الافتراضية لـ Docker Desktop على Linux.

تجاهل هذه التحذيرات، من جهازك المضيف، قم بتنفيذ:

d/exec git config --global --add safe.directory /src

لماذا يعمل Docker Desktop لنظام Linux على جهاز افتراضي؟

Linux