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

[Discourse]

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

بما أن Discourse يعمل داخل Docker، فيجب أن تتمكن من تشغيل Discourse مباشرة من دليل المصدر الخاص بك باستخدام حاوية تطوير Discourse.

المزايا: لا حاجة لتثبيت أي تبعيات للنظام، ولا حاجة لأي إعدادات لتجهيز بيئة تطوير بسرعة.

العيوب: سيكون أبطأ قليلاً من بيئة التطوير الأصلية على Ubuntu، وأبطأ بكثير من التثبيت الأصلي على MacOS.

انظر أيضًا Developing Discourse using a Dev Container

الخطوة 1: تثبيت Docker

Ubuntu

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get install -y docker-ce

19.10

sudo apt-get install docker.io
sudo usermod -a -G docker $USER
sudo reboot

Windows WSL: Ubuntu

يمكنك تشغيل الأوامر أعلاه داخل WSL، ولكن يجب أن تكون جميع الملفات داخل نظام ملفات WSL. على سبيل المثال: يعمل بشكل جيد إذا كانت الملفات داخل ~/discourse، لكنه يفشل إذا وُضعت داخل /mnt/c/discourse.

MacOS

صورة تطوير Discourse متاحة فقط لهياكل x86_64. أجهزة Mac M1 قادرة على تشغيل الصورة باستخدام محاكاة البنية، لكن من غير المرجح أن يعمل Discourse بسبب عدم دعم inotify في QEMU.

بدلاً من ذلك، يجب استخدام Install Discourse on macOS for development

الخيار 1: تحميل ملف .dmg معبأ من متجر Docker
الخيار 2: brew install docker

الخطوة 2: تشغيل الحاوية

قم باستنساخ مستودع Discourse إلى جهازك المحلي.

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

(من جذر المصدر الخاص بك)

d/boot_dev --init
    # انتظر أثناء:
    #   - تثبيت التبعيات،
    #   - ترحيل قاعدة البيانات، و
    #   - إنشاء مستخدم مسؤول (ستحتاج إلى التفاعل مع هذا)

# في أحد طرفيات المحادثة:
d/rails s

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

…ثم افتح متصفحًا على http://localhost:3000 و ها أنت ذا! يجب أن ترى Discourse.

روابط رمزية للإضافات

يدعم سير عمل التطوير باستخدام Docker الروابط الرمزية داخل دليل plugins/، مع التحفظ التالي:

عند إنشاء رابط رمزي لإضافة جديدة، يجب إعادة تشغيل حاوية Docker باستخدام:

d/shutdown_dev; d/boot_dev

---

ملاحظات:

• لاختبار البريد الإلكتروني، شغّل MailHog :

  d/mailhog
  

• إذا كانت هناك مجوهرات (gems) مفقودة، شغّل:

  d/bundle install
  

• إذا كانت هناك حاجة لترحيل قاعدة بيانات:

  d/rake db:migrate RAILS_ENV=development
  

• عند الانتهاء، يمكنك اختيار إيقاف حاوية Docker باستخدام:

  d/shutdown_dev
  

• يتم الاحتفاظ بالبيانات بين استدعاءات الحاوية في دليل tmp/postgres الخاص بجذر المصدر الخاص بك. إذا أردت لأي سبب إعادة تعيين قاعدة بياناتك، شغّل:

  sudo rm -fr data
  

• إذا رأيت أخطاء مثل «تم رفض الإذن أثناء محاولة الاتصال بـ Docker»، شغّل:

  run `sudo usermod -aG docker ${USER}`
  sudo service docker restart
  

• إذا كنت ترغب في تعريض المنافذ من الحاوية إلى الشبكة عالميًا (مفعل افتراضيًا)، استخدم:

  d/boot_dev -p
  

• ملف Dockerfile يأتي من discourse/discourse_docker على GitHub، وتحديدًا image/discourse_dev.

تشغيل الاختبارات

d/rake autospec

لتشغيل اختبارات إضافة معينة، يمكنك أيضًا فعل شيء مثل هذا:

d/rake plugin:spec["discourse-follow"]

أو حتى شيء أكثر تحديدًا:

my-machine:~/discourse$ d/shell
discourse@discourse:/src$ RAILS_ENV=test /src/bin/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

---

هذا المستند يتحكم في إصداراته - اقترح التغييرات على GitHub.

[Geoffrey_Challen]

إعدادها سهل للغاية! شكرًا لك.

ومع ذلك، فأنا مندهش من بطء التثبيت المحلي. هل هناك طريقة لتعديل مواصفات الحاوية؟ أتوقع حدوث تباطؤ، لكن ربما ليس بهذا الوضوح…

شكرًا مجددًا.

[seanblue]

أحاول استخدام Docker على نظام Windows 10، ولدي سؤال بخصوص الدليل. لقد قمت بتثبيت Docker وهو قادر على تشغيل حاوية Ubuntu (مع عدم تثبيت أي شيء تقريبًا داخل الحاوية). يذكر دليل Docker هذا فقط أن تقوم باستنساخ المستودع بعد ذلك، لكنني لا أستطيع فعل ذلك لأن الحاوية لا تحتوي على Git مثبتًا.

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

[mentalstring (Paulo)]

@seanblue

يقول دليل Docker هذا فقط انسخ المستودع بعد ذلك، لكنني لا أستطيع فعل ذلك لأن الحاوية لا تحتوي على Git مثبتًا.

أعتقد أن ما يُربكك هو أنك تحاول نسخ المستودع داخل الحاوية، بينما يجب تنفيذ أمر git clone على جهازك. لذا، إذا كان Git مثبتًا محليًا بالفعل، فأنت قريب من جعله يعمل.

[seanblue]

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

هل أملك وصولاً تلقائياً إلى نظام الملفات الخاص بالمضيف من داخل حاوية Docker؟ أعتقد أنني كنت مشوشاً جزئياً بسبب أمر d/boot_dev --init لأنني لم أكن أعرف ما المقصود بـ d/ (على سبيل المثال، لا أرى مجلداً يُسمى d في المستودع، رغم أنني أرى boot_dev).

[mentalstring (Paulo)]

موجود d في المستودع (انتقل لأسفل الصفحة) — إنه ليس مجلدًا بل رابطًا رمزيًا إلى bin/docker. يجب أن تحصل عليه عند استنساخ مستودع git.

لم أستخدم هذا الإعداد بشكل مكثف بنفسي، لكن فهمي هو أنك تقوم بتعديل ملفات المصدر مباشرة في نظام الملفات المضيف (الذي قمت بفحصه للتو)، وتقوم حاويات docker بتركيبه والتشغيل منه. ستقوم سكريبتات d/* بمعظم عمل إعداد docker نيابةً عنك.

[seanblue]

@mentalstring

موجود d في المستودع (انتقل لأسفل الصفحة)، لكنه ليس مجلداً بل رابطاً رمزياً إلى bin/docker.

شكراً على ذلك. لم أفكر حتى في النظر أبعد من المجلدات. أعتقد أن لدي معلومات كافية للقيام بمحاولة أخرى في هذا الشأن.

[seanblue]

ما زلت أرتكب خطأً ما. بين هذا الموضوع، هنا، و هنا، لا يوضح أي منهما أمر docker الذي يجب تشغيله. لقد اعتمدت على docker run -ti -v LocalRepoPath:/src discourse/discourse_dev، الذي قام بتهيئة مجموعة كبيرة من الأشياء وربط المستودع بـ /src. لكن لا يمكنني تشغيل d/boot_dev --init لسبب ما. حتى مجرد تشغيل ls في الدليل الرئيسي للمستودع يعطيني:

ls: لا يمكن الوصول إلى 'adminjs': خطأ في الإدخال/الإخراج
ls: لا يمكن الوصول إلى 'd': خطأ في الإدخال/الإخراج
ls: لا يمكن الوصول إلى 'jsapp': خطأ في الإدخال/الإخراج

هل يعرف أحد ما الذي يحدث هنا؟

[mentalstring (Paulo)]

قد تكون قد بالغت في تعقيد الأمر: فالدليل الموجود في المنشور الأول يحتوي بالفعل على كل ما تحتاجه للبدء.

ستقوم أوامر d/* بكل السحر الخاص بأوامر Docker حتى لا تضطر إلى ذلك. بمجرد استنساخ المستودع، يجب أن يكون الأمران d/boot_dev --init و d/unicorn (الذين تنفذهما على المضيف) كافيين لجعل http://localhost:9292 يعمل. ستقوم هذه السكربتات باستدعاء Docker لتوليد الحاوية وتشغيلها لك. أما أمر d/shutdown_dev فسيوقفها.

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

[seanblue]

تنهد، أفهم. ظننت أنه يجب تشغيلها داخل Docker. ومع ذلك، يبدو أن الأمر d/boot_dev --init لا يعمل على Windows في PowerShell (وهو ما أعتقد أنه السبب في أن دليل Docker هذا يذكر فقط مضيفي Mac و Ubuntu). حاولت تشغيل الأمر في نظام فرعي للينكس (الإصدار 1)، ولكن بالطبع فشل ذلك في خطوة Docker لأنني قمت بتثبيت Docker على Windows وليس على النظام الفرعي للينكس.

---

في الخطوة التالية، حاولت تشغيل الأمر في Git Bash لنظام Windows. لم أتمكن من تشغيل d/boot_dev --init (خطأ “d/boot_dev: هو مجلد”)، لكنني تمكنت من تشغيل bin/docker/boot_dev --init. تقدمت العملية كثيرًا، حيث تم سحب العديد من الملفات، لكنها فشلت بعد ذلك مع:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: استجابة خطأ من الدائم: رفض التثبيت:
المسار المصدر “PathToRepo/data/postgres;C”
غير موجود وغير معروف لدى Docker.

تمكنت من تجاوز ذلك (أعتقد) عن طريق هروب مسار التثبيت، وفقًا لـ:
https://stackoverflow.com/questions/50608301/docker-mounted-volume-adds-c-to-end-of-windows-path-when-translating-from-linux

بعد ذلك، حصلت على هذه الرسالة:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: استجابة خطأ من الدائم: فشل إنشاء وقت تشغيل OCI: container_linux.go:346: تسبب بدء عملية الحاوية في “exec: "C:/Program Files/Git/sbin/boot": stat C:/Program Files/Git/sbin/boot: لا يوجد ملف أو دليل”: غير معروف.

C:/Program Files/Git/sbin/boot لا يوجد في نظام الملفات الخاص بي، لذا أعتقد أن الخطأ ليس مفاجئًا. الشيء الوحيد الذي يذكر sbin/boot في ملف boot_dev هو هذا الجزء من أمر Docker: discourse/discourse_dev:release /sbin/boot.

وهذا هو تقريبًا ما وصلت إليه الآن… لا أعرف حقًا ما الذي يمكنني تجربته في هذه المرحلة.

[mentalstring (Paulo)]

أخشى أن هذا هو أقصى ما أستطيع مساعدتك به، حيث أنني غير ملم بنظام ويندوز.

ربما يتمكن @rishabh من تأكيد ما إذا كان من المفترض أن يعمل هذا على ويندوز أيضًا، وتحديث أي خطوات مفقودة لذلك (أو إضافة ملاحظة إذا لم يعمل).

[seanblue]

@sam هل ما أحاول فعله طريقة مدعومة ولو بشكل بعيد لتشغيل Discourse لأغراض التطوير؟ في موضوع التطوير على Windows ذكرت أنك جربت ذلك، لكن الأمور لم تسر بشكل جيد حتى الآن. تعمل حاويات Ubuntu الأساسية (غير المخصصة لـ Discourse) تقنيًا، لكن الأوامر المحددة في منشور الموضوع الأصلي في هذا الموضوع لا تعمل.

لقد ذكرت لي في الأصل ما يلي:

@sam

إذا كنت تشعر بالجرأة ومريحًا في اختيار الحلقة البطيئة لبناء Insider، فأعتقد أن WSL2 يمكن أن تعمل بشكل مقبول.

وإلا، فإنني أوصي باستخدام آلة افتراضية تقليدية + Docker كطريقة سهلة لأنك ستحصل على المزيد من أدوات الدعم.

يجب أن يعمل Docker النقي، لكنه يتركك بخيارات مرونة أقل.

لذلك، ما لم يكن لديك اقتراح لمساعدتي على تجاوز المشاكل التي أواجهها مع Docker على Windows، فمن الأرجح أن يكون من الأفضل لي التوقف عن الخسارة وتشغيله في آلة افتراضية Ubuntu باستخدام شيء مثل VirtualBox.

[sam (Sam Saffron)]

كثير منا يستخدم الحلقة البطيئة دون أي مشاكل. الألعاب تعمل، وSteam يعمل، وكل شيء يعمل.

أتفهم مخاوفكم هنا، لكنها حقًا ليست مشكلة كبيرة. على أي حال، إذا كان هذا الأمر مخيفًا جدًا بالنسبة لكم، فأوصي باستخدام آلة افتراضية تقليدية مثل Hyper-V أو VirtualBox. قم بتثبيت Docker فيها واستخدم إعدادات التطوير الخاصة بنا عبر Docker.

[seanblue]

لو لم يكن هذا حاسوبي الأساسي (والوحيد)، لانضممتُ إليكم في حلقة التحديثات البطيئة، لكنني لا أستطيع المجازفة بذلك. لذا سأعتمد على آلة افتراضية تقليدية مع Docker. شكرًا مجددًا على النصيحة. آمل أن أتمكن من تشغيل شيء قريبًا.

ما الذي يكفي من مساحة القرص والذاكرة العشوائية لتخصيصها للآلة الافتراضية؟ كنت أفكر ربما في 16 جيجابايت من مساحة القرص و4 جيجابايت من الذاكرة العشوائية، لكنني أردت التحقق أولًا.

[sam (Sam Saffron)]

هذا يكفي على الأرجح، وأفضل طريقة لإيجاد الوصفة المثالية هي التجربة

[seanblue]

حسناً، أنا قريب من جعل هذا يعمل بشكل فعلي. لدي نسخة محلية تعمل باستخدام Docker في آلة افتراضية تعمل بنظام Ubuntu. أفترض أنني يجب أن أشغّل d/boot_dev --init فقط في المرة الأولى، وبعد ذلك سأقوم بتشغيل d/boot_dev فقط. هل هذا دقيق؟ السبب في سؤالي هو أن d/unicorn يعمل عندما أدرج --init، لكنه لا يعمل عندما أغفل --init من d/boot_dev. عندما يفشل في البدء، أحصل على الخطأ:

Could not find aws-partitions-1.270.0 in any of the sources.
Run bundle install to install missing gems.

لكن عند تشغيل bundle install يفشل مع الرسالة:

actionview_precompiler-0.2.2 requires ruby version >= 2.6, which is incompatible with the current version, ruby 2.5.1p57

هل هناك إصدار محدد من Ruby يجب أن أحدث إليه؟ أم أن هناك شيئاً آخر يحدث؟

---

آلتي الافتراضية تعمل بنظام Ubuntu 18.04 (LTS)، وهذه المرة تمكنت من اتباع التعليمات في المنشور الأصلي مباشرة، لذا لا أعرف أين قد أكون أخطأت (إذا كان هناك خطأ ما).

[sam (Sam Saffron)]

@seanblue

لكن عند تشغيل bundle install يفشل مع

لن تستخدم bundle install، بل ستستخدم d/bundle install لأنك تريد تثبيت الحزمة داخل الحاوية، ولا تحتاج الآلة الافتراضية إلى Ruby.

[seanblue]

@sam، منشور: 99، موضوع: 102009

أنت تريد تثبيت الحزمة داخل الحاوية، ولا تحتاج الآلة الافتراضية إلى Ruby.

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

[seanblue]

لقد سحب أحدث إصدار من المستودع، وكالمعتاد يخبرني d/unicorn بـ “شغّل bundle install لتثبيت الجيمات المفقودة.”. ومع ذلك، هذه المرة عندما أشغّل d/bundle install أحصل على ما يلي:

جلب فهرس المصادر من https://rubygems.org/

إعادة محاولة الجلب بسبب خطأ (2/4): Bundler::HTTPError تعذر جلب المواصفات من https://rubygems.org/

إعادة محاولة الجلب بسبب خطأ (3/4): Bundler::HTTPError تعذر جلب المواصفات من https://rubygems.org/

إعادة محاولة الجلب بسبب خطأ (4/4): Bundler::HTTPError تعذر جلب المواصفات من https://rubygems.org/

تعذر جلب المواصفات من https://rubygems.org/

لذا لا يمكنني تشغيل Discourse حاليًا. ليس لدي أي فكرة عما إذا كان هذا مرتبطًا بالسحب (مباشرة أو بشكل غير مباشر) أم أنه شيء غير مرتبط تمامًا. لم يكن البحث عن الخطأ في Google مفيدًا بشكل خاص، لذا لا أعرف كيف أواصل.

[pfaffman (Jay Pfaffman)]

هل تمكنت من الوصول إلى rubygems.org؟