Dev Containers is an open standard for configuring a development environment inside a container. This almost entirely eliminates the need to install/configure Discourse-specific tools/dependencies on your local machine, and makes it very easy to keep up-to-date as Discourse evolves over time.
Dev Containers can be used in a number of different IDEs, or directly using their reference CLI. This guide will describe the setup process for VSCode.
In VSCode, use File → Open Folder, then choose the Discourse directory
Open the folder in its Dev Container. This can be done via the popup prompt, or by opening the command palette (Cmd/Ctrl + Shift + P) and searching for “Open folder in container…”
If this is your first time launching a container, you will be prompted to install and start Docker Desktop. Once complete, go back to VSCode re-run “Open folder in container…”
Wait for the container to download and start. When it’s done, the README will appear, and you’ll see the Discourse filesystem in the sidebar.
Run the default build task using Cmd/Ctrl + Shift + B.
This will install dependencies, migrate the database, and start the server. It’ll take a few minutes, especially on the lower-end machines. You’ll see “Build successful” in the terminal when it’s done.
Run the dev/admin/create task. Open the command palette and search for “Tasks: Run Tasks”. It will present a menu of tasks; select dev/admin/create off of that list. You’ll be prompted to enter an email address and a password for your admin user.
Visit http://localhost:3000 in your browser to see your new Discourse instance
All done! You can now make changes to Discourse’s source code and see them reflected in the preview.
Running tests
The first time you run tests, you’ll need to install testing dependencies, including Playwright and the discourse_test DB. You can run the deps/testing task to install those. Open the command palette, select “Tasks: Run Tasks”. It will present a menu of tasks; select deps/testing off of that list.
Every so often, the devcontainer config and the associated container image will be updated. VSCode should prompt you to “rebuild” to apply the changes. Alternatively, you can run “Dev Containers: Rebuild Container” from the VSCode command palette. The working directory, and your Redis/Postgres data will be preserved across rebuilds.
If you’d like to start from scratch with fresh database, you’ll need to delete the discourse-pg and discourse-redis docker volumes. This can be done from the “Remote Explorer” tab of the VSCode sidebar.
Discourse’s sample vscode .vscode/settings.json and .vscode/tasks.json will be copied when you first boot the codespace. From that point forward, if you want to use the latest sample config, you’ll need to manually copy .vscode/settings.json.sample to .vscode/settings.json.
ومع ذلك، عند استخدامه كحاوية تطوير وتشغيل خطوات البناء (Ctrl/Cmd + Shift + B)، فإنه لا ينشئ مسؤولاً.
من خلال إلقاء نظرة سريعة على التعليمات، كان لدي انطباع في البداية أن إنشاء مسؤول أمر شاق للغاية؛ ولكن بعد ذلك أدركت أن كل ما يتطلبه الأمر هو هذا الأمر، تاركاً إياه هنا لمن يواجهون نفس المشكلة:
rake admin:create
(أو، إذا اشتكى من إصدار rake مختلف مطلوب: bundle exec rake admin:create)
على نظام التشغيل Windows 11، إذا كنت لا ترغب في مواجهة مشكلات في نهايات الأسطر، مثل:
[23963 ms] Start: Run in container: /bin/sh -c ./.devcontainer/scripts/start.rb
/usr/bin/env: ‘ruby\r’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
ربما تكون هناك طريقة أفضل، ولكن للعمل على المكونات الإضافية لدي مجلد أشقاء discourse-plugins بجوار مجلد مستودع discourse الرئيسي الخاص بي. هذا يتم تحميله إلى /workspace/plugins حتى أتمكن بعد ذلك من إنشاء روابط رمزية داخل الحاوية.
هذا ما أضفته إلى mounts في devcontainer.json: "source=${localWorkspaceFolder}/../${localWorkspaceFolderBasename}-plugins,target=/workspace/plugins,type=bind"
إذا كنت تستخدم OrbStack (غير تابع) على بيئة macOS المحلية الخاصة بك، وترغب في تشغيل Discourse باستخدام HTTPS مع نطاق مخصص، فقم بتحديث ملف devcontainer.json الخاص بك بالإضافات التالية:
امنح اسمًا للحاوية.
أضف النطاق الفرعي .orb.local إلى متغير البيئة RAILS_DEVELOPMENT_HOSTS (يجب فصل أسماء المضيفين بفاصلة).
ملاحظة: يرجى إخباري إذا كنت تعرف كيف يمكنني تعيين اسم المضيف *.orb.local واسم الحاوية ديناميكيًا، كما هو محدد لـ GitHub Codespaces. لم ينجح معي تعيين القيمة كـ .app.github.dev,.orb.local.
تحديث: بطريقة ما، كنت أفتقد سجلًا في ملف /etc/hosts الخاص بي. بعد إضافة هذا السطر، تمكنت من استخدام النطاق الفرعي .orb.local في الخطوة 2.
مع هذه التغييرات في ملف devcontainer.json، يمكنني الآن تشغيل نسخة Discourse المحلية الخاصة بي على https://discourse.orb.local/
/etc/hosts
أضف هذا السطر إلى ملف /etc/hosts الخاص بك إذا لم يكن موجودًا بالفعل.
##
# Docker و OrbStack
##
127.0.0.1 host.docker.internal
نصيحة إضافية 1
إذا كانت إعدادات شبكتك، أو شبكة VPN الخاصة بشركتك، وما إلى ذلك تتعارض مع نطاقات IP للحاويات الخاصة بـ OrbStack، فقم بتحديث OrbStack الخاص بك بنطاق مختلف.
نصيحة إضافية 2
إذا حذفت الخطوة 1، فسيقوم OrbStack بإنشاء حاوية باسم عشوائي، ولكن لا يزال بإمكانك استخدام HTTPS دون إضافة أي رقم منفذ. العيب هو اسم الحاوية، وبالتالي سيتم تحديث اسم النطاق في كل مرة تقوم فيها بإعادة بناء الحاوية.
تلك التعليمات غير المخصصة لـ VS Code لم تنجح معي للتو على نظام macOS. أنصح مستخدمو macOS الذين يرغبون في التفاعل مع صورة Docker الخاصة بـ Discourse خارج VS Code باستخدام سكريبت Docker القديم boot_dev بدلاً من ذلك.
باستخدام الأمر docker ps، وجدت اسم الحاوية (اسم عشوائي مضحك، مثل peaceful_lumiere). ثم شغلت الأمر docker inspect peaceful_lumiere | jq '.[0].NetworkSettings.Networks.bridge.IPAddress فظهر لي عنوان IP. انتقلت إلى http://<ip>:4200 في المتصفح، لكنه ظل يدور إلى الأبد دون استجابة.
أعتقد أن السبب هو أن خادم التطوير الخاص بـ ember-cli لا يستمع إلى جميع الواجهات؛ بل يستمع فقط إلى http://127.0.0.1:4200 داخل الحاوية.
في النهاية نجحت في جعله يعمل بإضافة قسم runArgs إلى ملف .devcontainer/devcontainer.json، على النحو التالي.
… لكن إذا قمت بذلك، فلن يعمل الأمر داخل VS Code (لأن كلاً من VS Code وحاوية التطوير سيحاولان توجيه المنافذ). قمت بإنشاء ملف منفصل اسمه devcontainer-cli.json واستخدمت الأمر devcontainer --override-config .devcontainer/devcontainer-cli.json، فنجح الأمر.
لكن بعد ذلك أدركت أنني قفزت عبر كل هذه العقبات، ومع ذلك لم أكن أفضل حالاً من استخدام سكريبت boot_dev القديم المتاح. اتباع الخطوات الموثقة هناك أسرع وأسهل من محاولة إجبار devcontainer على فعل الشيء الصحيح عبر سطر الأوامر.
تُصمَّم حاويات التطوير (Dev Containers) في المقام الأول للاستخدام داخل VS Code، أو في أي أداة أخرى ستقوم تلقائيًا بإدارة توجيه المنافذ لك؛ بينما لا يقوم CLI الخاص بـ devcontainer بذلك. لذا، إذا لم تكن ترغب في استخدام VS Code، فربما لا داعي للتعامل مع حاويات التطوير.
يجب أن أذكر أن تعليماتي كانت مخصصة لنظام Linux (وتحديدًا NixOS في حالتي)، لكن لا يوجد سبب يمنع عملها على أنظمة Linux أخرى.
@dfabulich قرأت منشورك وأعتقد أنني فهمت المشكلة. لا ينبغي أن يكون إعادة توجيه المنفذ ضروريًا. تحتاج إلى عنوان IP الخاص بالحاوية. 127.0.0.1 هو localhost (نظامك المحلي، وليس الحاوية).
يجب أن يكون أمر jq قد أعاد عنوان IP ضمن شبكة LAN المحلية يمكنك الوصول إليه دون الحاجة إلى إعادة توجيه المنفذ.
لا، لقد قمت بذلك. عرض jq"172.17.0.2" وبقي http://172.17.0.2:4200 يدور إلى الأبد دون استجابة.
داخل الحاوية، لا يستمع ember-cli على العنوان 0.0.0.0:4200؛ بل يستمع على 127.0.0.1:4200. لذا، إذا حاولت الوصول إليه عبر 172.17.0.2:4200 (أو أي عنوان IP حقيقي لديك)، فلن تصل الطلبات إلى Ember، على الأقل على نظام macOS.
لاحظ أنه على نظام macOS، يعمل Docker Desktop كآلة افتراضية. لا يوجد شيء يُعرف باسم «حاوية Docker خفيفة الوزن على مستوى العملية» على نظام macOS.
لا أعرف بما يكفي عن macOS لأتأكد مما إذا كان Docker يستخدم مساحات أسماء النواة (kernel namespaces) كما يفعل على Linux. لقد أجريت اختبارًا مرة أخرى (ملاحظة: يستغرق تشغيل الخدمة بعض الوقت):
لا يفعل ذلك. يعمل Docker Desktop لنظام macOS فعليًا عبر QEMU. (أو كان كذلك حتى وقت قريب؛ الآن يستخدمون شيئًا جديدًا يشبه QEMU يرتدي قبعة وشاربًا غريبين؛ على أي حال، لا يزال يعمل كآلة افتراضية كاملة (full-fat VM) كتنفيذ له.)
لذا، أنا متأكد من أنه يعمل على جهازك، لكنه لا يعمل على جهاز macOS الخاص بي، وأعتقد أن هذا هو السبب الأرجح لذلك.
