تلك التعليمات غير المخصصة لـ 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، على النحو التالي.
8025, // mailhog
9229 // chrome remote debug
],
+ "runArgs": [
+ "-p",
+ "127.0.0.1:4200:4200",
+ "-p",
+ "127.0.0.1:3000:3000",
+ "-p",
+ "127.0.0.1:9292:9292",
+ "-p",
+ "127.0.0.1:8025:8025",
+ "-p",
+ "127.0.0.1:9229:9229"
+ ],
"remoteUser": "discourse",
"remoteEnv": {
"RAILS_DEVELOPMENT_HOSTS": ".app.github.dev",
… لكن إذا قمت بذلك، فلن يعمل الأمر داخل 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، فربما لا داعي للتعامل مع حاويات التطوير.