ml workspace
0.13.2
كل ما في واحد بيئة تطوير على شبكة الإنترنت للتعلم الآلي
البدء • الميزات ولقطات الشاشة • الدعم • الإبلاغ عن خطأ • الأسئلة الشائعة • المشكلات المعروفة • المساهمة
مساحة عمل ML عبارة عن IDE IDE على شبكة الإنترنت متخصصة في التعلم الآلي وعلوم البيانات. من السهل النشر وبدء تشغيلك في غضون دقائق حتى يتم تصميم حلول ML على أجهزتك. مساحة العمل هذه هي الأداة النهائية للمطورين الذين يتم تحميلهم مسبقًا مع مجموعة متنوعة من مكتبات علوم البيانات الشائعة (EG ، TensorFlow ، Pytorch ، Keras ، Sklearn) و Dev Tools (على سبيل المثال ، Jupyter ، VS Code ، Tensorboard) بشكل مثالي ، محسّن ، ودمجها.
تتطلب مساحة العمل تثبيت Docker على جهازك (دليل التثبيت).
إن نشر مثيل مساحة عمل واحدة أمر بسيط مثل:
docker run -p 8080:8080 mltooling/ml-workspace:0.13.2Voilà ، كان ذلك سهلاً! الآن ، ستقوم Docker بسحب أحدث صورة مساحة العمل إلى جهازك. قد يستغرق هذا بضع دقائق ، اعتمادًا على سرعة الإنترنت. بمجرد بدء تشغيل مساحة العمل ، يمكنك الوصول إليها عبر http: // localhost: 8080.
إذا تم بدء تشغيله على جهاز آخر أو مع منفذ مختلف ، فتأكد من استخدام IP/DNS للجهاز و/أو المنفذ المكشوف.
لنشر مثيل واحد للاستخدام الإنتاجي ، نوصي بتطبيق الخيارات التالية على الأقل:
docker run -d
-p 8080:8080
--name " ml-workspace "
-v " ${PWD} :/workspace "
--env AUTHENTICATE_VIA_JUPYTER= " mytoken "
--shm-size 512m
--restart always
mltooling/ml-workspace:0.13.2 يقوم هذا الأمر بتشغيل الحاوية في الخلفية ( -d ) ، ويقوم بتثبيت دليل العمل الحالي في مجلد /workspace ( -v ) ، ويؤمن مساحة العمل عبر رمز مميز ( --env AUTHENTICATE_VIA_JUPYTER ) ، ويوفر 512 ميغابايت من الذاكرة المشتركة ( --shm-size ) لمنع حوادث الاصطدام غير --restart always (انظر إلى القسم المعروف) ، والاحتفاظ بالحاويات حتى على المنظمة. يمكنك العثور على خيارات إضافية لتشغيل Docker هنا وخيارات تكوين مساحة العمل في القسم أدناه.
توفر مساحة العمل مجموعة متنوعة من خيارات التكوين التي يمكن استخدامها عن طريق ضبط متغيرات البيئة (عبر خيار تشغيل Docker: --env ).
| عامل | وصف | تقصير |
|---|---|---|
| workspace_base_url | عنوان URL الأساسي الذي يمكن من خلاله الوصول إلى jupyter وجميع الأدوات الأخرى. | / |
| workspace_ssl_enabled | تمكين أو تعطيل SSL. عند التعيين على TRUE ، يجب تثبيت الشهادة (cert.crt) على /resources/ssl أو ، إن لم يكن كذلك ، تقوم الحاوية بإنشاء شهادة توقيع ذاتيًا. | خطأ شنيع |
| Workspace_auth_user | اسم مستخدم المصادقة الأساسية. لتمكين المصادقة الأساسية ، يجب تعيين كل من المستخدم وكلمة المرور. نوصي باستخدام AUTHENTICATE_VIA_JUPYTER لتأمين مساحة العمل. | |
| Workspace_auth_password | كلمة مرور المستخدم الأساسية. لتمكين المصادقة الأساسية ، يجب تعيين كل من المستخدم وكلمة المرور. نوصي باستخدام AUTHENTICATE_VIA_JUPYTER لتأمين مساحة العمل. | |
| Workspace_port | تكوين المنفذ الرئيسي للحاوية الداخلية لوكيل مساحة العمل. بالنسبة لمعظم السيناريوهات ، لا ينبغي تغيير هذا التكوين ، ويجب استخدام تكوين المنفذ عبر Docker بدلاً من مساحة العمل يجب الوصول إليه من منفذ مختلف. | 8080 |
| config_backup_enabled | النسخ الاحتياطي تلقائيًا واستعادة تكوين المستخدم إلى مجلد /workspace ، مثل .ssh أو .jupyter أو .gitconfig من الدليل الرئيسي للمستخدمين. | حقيقي |
| shared_links_enabled | تمكين أو تعطيل القدرة على مشاركة الموارد عبر الروابط الخارجية. يتم استخدام هذا لتمكين مشاركة الملفات ، والوصول إلى منافذ مساحة العمل الداخلية ، وإعداد SSH سهل القائمة على الأوامر. يتم حماية جميع الروابط المشتركة عبر رمز. ومع ذلك ، هناك بعض المخاطر حيث لا يمكن إبطال الرمز المميز بسهولة بعد المشاركة ولا ينتهي صلاحيته. | حقيقي |
| تشمل _tutorials | إذا كان true ، فسيتم إضافة مجموعة من أجهزة الكمبيوتر المحمولة التعليمية والمقدمة إلى مجلد /workspace في بدء التشغيل ، ولكن فقط إذا كان المجلد فارغًا. | حقيقي |
| max_num_threads | عدد مؤشرات الترابط المستخدمة للحسابات عند استخدام مختلف المكتبات المشتركة (MKL ، OpenBlas ، OMP ، Numba ، ...). يمكنك أيضًا استخدام auto للسماح لمساحة العمل ديناميكيًا بتحديد عدد مؤشرات الترابط بناءً على موارد وحدة المعالجة المركزية المتاحة. يمكن كتابة هذا التكوين من قبل المستخدم من داخل مساحة العمل. بشكل عام ، من الجيد ضبطه على أو أقل من عدد وحدات المعالجة المركزية المتاحة لمساحة العمل. | آلي |
| تكوين Jupyter: | ||
| stowddown_inactive_kernels | قم بإغلاق النواة غير النشطة تلقائيًا بعد مهلة معينة (لتنظيف موارد الذاكرة أو GPU). يمكن أن تكون القيمة إما مهلة في ثوانٍ أو تم ضبطها على true مع قيمة افتراضية تبلغ 48 ساعة. | خطأ شنيع |
| antensicate_via_jupyter | إذا كان true ، فسيتم المصادقة على جميع طلبات HTTP مقابل خادم Jupyter ، مما يعني أنه سيتم استخدام طريقة المصادقة التي تم تكوينها مع Jupyter لجميع الأدوات الأخرى أيضًا. هذا يمكن إلغاء تنشيطه مع false . أي قيمة أخرى ستقوم بتنشيط هذه المصادقة ويتم تطبيقها على أنه رمز عبر Notebookapp.token تكوين Jupyter. | خطأ شنيع |
| Notebook_args | إضافة وخيارات تكوين jupyter والكتابة المرتفعة عبر أسطر الأوامر args. الرجوع إلى هذه النظرة العامة لجميع الخيارات. | |
لاستمرار البيانات ، تحتاج إلى تثبيت وحدة تخزين في /workspace (عبر خيار تشغيل Docker: -v ).
دليل العمل الافتراضي داخل الحاوية هو /workspace ، وهو أيضًا الدليل الجذر لمثيل Jupyter. يهدف دليل /workspace إلى استخدام جميع القطع الأثرية المهمة في العمل. قد تضيع البيانات داخل الدلائل الأخرى للخادم (على سبيل المثال ، /root ) في إعادة تشغيل الحاوية.
نوصي بشدة بتمكين المصادقة من خلال أحد الخيارين التاليين. لكلا الخيارين ، سيُطلب من المستخدم المصادقة للوصول إلى أي من الأدوات المثبتة مسبقًا.
تعمل المصادقة فقط لجميع الأدوات التي يتم الوصول إليها من خلال منفذ مساحة العمل الرئيسية (الافتراضي:
8080). هذا يعمل لجميع الأدوات التي تم تثبيتها مسبقًا وميزة منافذ الوصول. إذا قمت بفضح منفذ آخر للحاوية ، فيرجى التأكد من تأمينه بالمصادقة أيضًا!
قم بتنشيط المصادقة المستندة إلى الرمز المميز بناءً على تنفيذ المصادقة لـ Jupyter عبر متغير AUTHENTICATE_VIA_JUPYTER :
docker run -p 8080:8080 --env AUTHENTICATE_VIA_JUPYTER= " mytoken " mltooling/ml-workspace:0.13.2 يمكنك أيضًا استخدام <generated> للسماح Jupyter بإنشاء رمز عشوائي يتم طباعته على سجلات الحاويات. لن يتم تعيين قيمة true أي رمز ولكن تنشيط أن كل طلب إلى أي أداة في مساحة العمل سيتم فحصه باستخدام مثيل Jupyter إذا تمت مصادقة المستخدم. يتم استخدام هذا لأدوات مثل JupyterHub ، والتي تقوم بتكوين طريقتها الخاصة للمصادقة.
قم بتنشيط المصادقة الأساسية عبر متغير WORKSPACE_AUTH_USER و WORKSPACE_AUTH_PASSWORD :
docker run -p 8080:8080 --env WORKSPACE_AUTH_USER= " user " --env WORKSPACE_AUTH_PASSWORD= " pwd " mltooling/ml-workspace:0.13.2 يتم تكوين المصادقة الأساسية عبر وكيل NGINX وقد تكون أكثر أداءً مقارنة بالخيار الآخر لأنه مع AUTHENTICATE_VIA_JUPYTER سيتم التحقق من كل طلب إلى أي أداة في مساحة العمل عبر مثيل Jupyter إذا تم مصادقة المستخدم (استنادًا إلى ملفات تعريف الارتباط للطلب).
نوصي بتمكين SSL بحيث يمكن الوصول إلى مساحة العمل عبر HTTPS (الاتصالات المشفرة). يمكن تنشيط تشفير SSL عبر متغير WORKSPACE_SSL_ENABLED .
عند التعيين على true ، يجب تركيب ملف cert.crt و cert.key على /resources/ssl أو ، إذا لم تكن ملفات الشهادة غير موجودة ، فإن الحاوية تنشئ شهادات موقعة ذاتيا. على سبيل المثال ، إذا كان /path/with/certificate/files على النظام المحلي يحتوي على شهادة صالحة للمجال المضيف (ملف cert.crt و cert.key ) ، يمكن استخدامه من مساحة العمل كما هو موضح أدناه:
docker run
-p 8080:8080
--env WORKSPACE_SSL_ENABLED= " true "
-v /path/with/certificate/files:/resources/ssl:ro
mltooling/ml-workspace:0.13.2 إذا كنت ترغب في استضافة مساحة العمل في مجال عام ، فإننا نوصي باستخدام Let's Encrypt للحصول على شهادة موثوقة لمجالك. لاستخدام الشهادة التي تم إنشاؤها (على سبيل المثال ، عبر أداة CertBot) لمساحة العمل ، يتوافق privkey.pem مع ملف cert.key و fullchain.pem إلى ملف cert.crt .
عند تمكين دعم SSL ، يجب عليك الوصول إلى مساحة العمل عبر
https://، وليس فوقhttp://.
بشكل افتراضي ، لا تحتوي حاوية مساحة العمل على قيود على الموارد ويمكنها استخدام أكبر عدد ممكن من مورد معين كما يسمح جدولة kernel بالمضيف. يوفر Docker طرقًا للتحكم في مقدار الذاكرة ، أو وحدة المعالجة المركزية التي يمكن أن تستخدمها الحاوية ، عن طريق إعداد أعلام تكوين وقت التشغيل لأمر Docker Run.
تتطلب مساحة العمل على الأقل 2 شرق وحدات المعالجة المركزية و 500 ميغابايت لتشغيل مستقر وتكون قابلة للاستخدام.
على سبيل المثال ، يقيد الأمر التالي مساحة العمل لاستخدام فقط 8 وحدات المعالجة المركزية ، و 16 غيغابايت من الذاكرة ، و 1 غيغابايت من الذاكرة المشتركة (انظر المشكلات المعروفة):
docker run -p 8080:8080 --cpus=8 --memory=16g --shm-size=1G mltooling/ml-workspace:0.13.2لمزيد من الخيارات والوثائق حول قيود الموارد ، يرجى الرجوع إلى دليل Docker الرسمي.
إذا كانت هناك حاجة إلى وكيل ، فيمكنك تمرير تكوين الوكيل عبر متغيرات بيئة HTTP_PROXY و HTTPS_PROXY و NO_PROXY .
بالإضافة إلى صورة مساحة العمل الرئيسية ( mltooling/ml-workspace ) ، فإننا نقدم نكهات الصور الأخرى التي تمد الميزات أو تقلل من حجم الصورة لدعم مجموعة متنوعة من حالات الاستخدام.
الحد الأدنى من النكهة ( mltooling/ml-workspace-minimal ) هي أصغر صورة لدينا تحتوي على معظم الأدوات والميزات الموضحة في قسم الميزات دون معظم مكتبات بيثون التي تم تثبيتها مسبقًا في صورتنا الرئيسية. يمكن تثبيت أي مكتبة Python أو أداة مستبعدة يدويًا أثناء تشغيل المستخدم.
docker run -p 8080:8080 mltooling/ml-workspace-minimal:0.13.2 تعتمد نكهة R ( mltooling/ml-workspace-r ) على صورة مساحة العمل الافتراضية الخاصة بنا وتمتدها مع R-Interpreter ، R-Jupyter kernel ، Rstudio Server (الوصول عبر Open Tool -> RStudio ) ، ومجموعة متنوعة من الحزم الشهيرة من نظام R ecosystem.
docker run -p 8080:8080 mltooling/ml-workspace-r:0.12.1 تعتمد نكهة Spark ( mltooling/ml-workspace-spark ) على صورة مساحة عمل R-Flavor وتمتدها مع وقت تشغيل Spark و Spark-Jupyter kernel و Zeppelin Notebook (Access عبر Open Tool -> Zeppelin ) ، Pyspark ، Hadoop ، Java Kernel ، ومجموعة قليلة من Bibraries & Jupyter.
docker run -p 8080:8080 mltooling/ml-workspace-spark:0.12.1حاليا ، تدعم نقاط GPU فقط CUDA 11.2. يمكن إضافة دعم إصدارات CUDA الأخرى في المستقبل.
تعتمد نكهة GPU ( mltooling/ml-workspace-gpu ) على صورة مساحة العمل الافتراضية الخاصة بنا وتمتد مع إصدارات CUDA 10.1 و GPU جاهزة لمكتبات التعلم الآلي المختلفة (على سبيل المثال ، TensorFlow ، Pytorch ، CNTK ، JAX). تحتوي صورة GPU هذه على المتطلبات الإضافية التالية للنظام:
>=460.32.03 (تعليمات).docker run -p 8080:8080 --gpus all mltooling/ml-workspace-gpu:0.13.2docker run -p 8080:8080 --runtime nvidia --env NVIDIA_VISIBLE_DEVICES= " all " mltooling/ml-workspace-gpu:0.13.2تأتي نكهة GPU أيضًا مع بعض خيارات التكوين الإضافية ، كما هو موضح أدناه:
| عامل | وصف | تقصير |
|---|---|---|
| nvidia_visible_devices | عناصر التحكم التي يمكن الوصول إليها في وحدات معالجة الرسومات داخل مساحة العمل. بشكل افتراضي ، يمكن الوصول إلى جميع وحدات معالجة الرسومات من المضيف داخل مساحة العمل. يمكنك إما استخدام all ، none ، أو تحديد قائمة مفصولة بفاصلة معرفات الجهاز (على سبيل المثال ، 0,1 ). يمكنك معرفة قائمة معرفات الجهاز المتاحة عن طريق تشغيل nvidia-smi على جهاز المضيف. | الجميع |
| cuda_visible_devices | عناصر التحكم التي ستشاهدها تطبيقات GPUS CUDA التي تعمل داخل مساحة العمل. بشكل افتراضي ، ستكون جميع وحدات معالجة الرسومات التي تتمتع بها مساحة العمل التي يمكنها الوصول إليها مرئية. لتقييد التطبيقات ، قدم قائمة مفصولة بفاصلة معرفات الجهاز الداخلي (على سبيل المثال ، 0,2 ) بناءً على الأجهزة المتاحة داخل مساحة العمل (Run nvidia-smi ). بالمقارنة مع NVIDIA_VISIBLE_DEVICES ، سيظل مستخدم مساحة العمل قادرًا على الوصول إلى وحدات معالجة الرسومات الأخرى عن طريق الكتابة فوق هذا التكوين من داخل مساحة العمل. | |
| tf_force_gpu_allow_growth | بشكل افتراضي ، سيتم تخصيص غالبية ذاكرة GPU من خلال التنفيذ الأول لرسم بياني TensorFlow. في حين أن هذا السلوك يمكن أن يكون مرغوبًا في خطوط أنابيب الإنتاج ، إلا أنه أقل استحسانًا للاستخدام التفاعلي. استخدم true لتمكين تخصيص ذاكرة GPU الديناميكي أو false لتوجيه Tensorflow لتخصيص جميع الذاكرة عند التنفيذ. | حقيقي |
تم تصميم مساحة العمل كبيئة تطوير مستخدم واحد. لإعداد متعدد المستخدمين ، نوصي النشر؟ ML HUB. يعتمد ML Hub على JupyterHub مع مهمة تفرخ وإدارة ووكالة أماكن العمل لعدة مستخدمين.
يجعل ML Hub من السهل إعداد بيئة متعددة المستخدمين على خادم واحد (عبر Docker) أو مجموعة (عبر Kubernetes) ويدعم مجموعة متنوعة من سيناريوهات الاستخدام ومقدمي المصادقة. يمكنك تجربة ML Hub عبر:
docker run -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock mltooling/ml-hub:latestلمزيد من المعلومات والوثائق حول ML Hub ، يرجى إلقاء نظرة على موقع github.
يتم الحفاظ على هذا المشروع من قبل بنيامين Räthlein ، لوكاس ماسوش ، وجان كالكان. يرجى فهم أننا لن نتمكن من تقديم الدعم الفردي عبر البريد الإلكتروني. نعتقد أيضًا أن المساعدة أكثر قيمة إذا تمت مشاركتها علنًا حتى يتمكن المزيد من الأشخاص من الاستفادة منها.
| يكتب | قناة |
|---|---|
| تقارير الأخطاء | |
| ؟ طلبات الميزة | |
| ؟ أسئلة الاستخدام | |
| ؟ الإعلانات | |
| ❓ طلبات أخرى |
Jupyter • Desktop واجهة المستخدم الرسومية • مقابل الكود • JupyterLab • تكامل GIT • مشاركة الملفات • منافذ الوصول • Tensorboard • تمديد • مراقبة الأجهزة • SSH Access • التطوير عن بُعد • تنفيذ الوظيفة
تم تجهيز مساحة العمل بمجموعة مختارة من أفضل أدوات تطوير المصادر المفتوحة في فئتها للمساعدة في سير عمل التعلم الآلي. يمكن بدء العديد من هذه الأدوات من قائمة Open Tool من Jupyter (التطبيق الرئيسي لمساحة العمل):
داخل مساحة العمل الخاصة بك ، لديك امتيازات كاملة Root و Sudo لتثبيت أي مكتبة أو أداة تحتاجها عبر Terminal (على سبيل المثال ،
pip،apt-get،conda، أوnpm). يمكنك العثور على المزيد من الطرق لتوسيع مساحة العمل ضمن قسم التوسيع
Jupyter Notebook هو بيئة تفاعلية تعتمد على الويب لكتابة الرمز وتشغيله. اللبنات الرئيسية للبناء من Jupyter هي متصفح الملفات ومحرر دفتر الملاحظات والكرات. يوفر مشاجرة الملفات مدير ملفات تفاعلي لجميع دفاتر الملاحظات والملفات والمجلدات في دليل /workspace .
يمكن إنشاء دفتر ملاحظات جديد من خلال النقر على الزر المنسد New في الجزء العلوي من القائمة واختيار نواة اللغة المطلوبة.
يمكنك تفرخ مثيلات طرفية تفاعلية أيضًا عن طريق تحديد
New -> Terminalفي متصفح الملفات.
يمكّن محرر دفتر الملاحظات المستخدمين من مستندات المؤلف التي تتضمن التعليمات البرمجية الحية ، ونص Markdown ، وأوامر Shell ، ومعادلات اللاتكس ، والأدوات التفاعلية ، والمؤامرات ، والصور. توفر مستندات دفتر الملاحظات سجلًا كاملًا ومكتفيًا لحساب يمكن تحويله إلى تنسيقات مختلفة ومشاركتها مع الآخرين.
تحتوي مساحة العمل هذه على مجموعة متنوعة من ملحقات Jupyter التابعة لجهة خارجية . يمكنك تكوين هذه الامتدادات في تكوين Nbextensions: علامة تبويب
nbextensionsفي متصفح الملفات
يتيح دفتر الملاحظات تشغيل الكود في مجموعة من لغات البرمجة المختلفة. لكل مستند دفتر ملاحظات يتم فتحه للمستخدم ، يبدأ تطبيق الويب نواة تقوم بتشغيل الرمز لهذا الكمبيوتر الدفتري وإرجاع الإخراج. تحتوي مساحة العمل هذه على Python 3 kernel تم تثبيتها مسبقًا. يمكن تثبيت نواة إضافية للوصول إلى لغات أخرى (على سبيل المثال ، R ، Scala ، GO) أو موارد الحوسبة الإضافية (على سبيل المثال ، وحدات معالجة الرسومات ، وحدات المعالجة المركزية ، والذاكرة).
بيثون 2 محروم ولا نوصي باستخدامه. ومع ذلك ، لا يزال بإمكانك تثبيت kernel Python 2.7 عبر هذا الأمر:
/bin/bash /resources/tools/python-27.sh
توفر مساحة العمل هذه وصول VNC المستند إلى HTTP إلى مساحة العمل عبر Novnc. وبالتالي ، يمكنك الوصول والعمل داخل مساحة العمل مع واجهة المستخدم الرسومية المكتبية بالكامل. للوصول إلى واجهة المستخدم الرسومية لسطح المكتب ، انتقل إلى Open Tool ، وحدد VNC ، وانقر فوق الزر Connect . في الحالة التي يُطلب منك كلمة مرور ، استخدم vncpassword .
بمجرد توصيلك ، سترى واجهة المستخدم الرسومية لسطح المكتب يتيح لك تثبيت واستخدام متصفحات الويب كاملة أو أي أداة أخرى متوفرة لـ Ubuntu. ضمن مجلد Tools الموجود على سطح المكتب ، ستجد مجموعة من البرامج النصية للتثبيت التي تجعل من السهل تثبيت بعض أدوات التطوير الأكثر استخدامًا ، مثل Atom أو Pycharm أو R-Runtime أو R-Studio أو Postman (فقط انقر نقرًا مزدوجًا على النص).
الحافظة: إذا كنت ترغب في مشاركة الحافظة بين جهازك ومساحة العمل ، فيمكنك استخدام وظيفة النسخ والزجاج كما هو موضح أدناه:
المهام طويلة الأمد: استخدم واجهة المستخدم الرسومية لسطح المكتب لإعدامات Jupyter طويلة الأمد. من خلال تشغيل دفاتر الملاحظات من متصفح واجهة المستخدم المكتبية لسطح العمل الخاص بك ، سيتم مزامنة جميع الإخراج مع دفتر الملاحظات حتى لو قمت بقطع متصفحك عن دفتر الملاحظات.
Visual Studio Code ( Open Tool -> VS Code ) هو محرر رمز خفيف الوزن مفتوح المصدر ولكنه قوي مع دعم مدمج لمجموعة متنوعة من اللغات ونظام بيئي غني من الامتدادات. فهو يجمع بين بساطة محرر رمز المصدر وأدوات المطورين القوية ، مثل إكمال رمز Intellisense وتصحيح الأخطاء. تدمج مساحة العمل VS Code كتطبيق مستند إلى الويب يمكن الوصول إليه من خلال المتصفح في مشروع Awesome Code-Server. يتيح لك تخصيص كل ميزة حسب رغبتك وتثبيت أي عدد من ملحقات الطرف الثالث.
توفر مساحة العمل أيضًا تكاملًا لـ VS Code في Jupyter مما يتيح لك فتح مثيل VS Code لأي مجلد محدد ، كما هو موضح أدناه:
JupyterLab ( Open Tool -> JupyterLab ) هي واجهة مستخدم الجيل التالي لـ Project Jupyter. إنه يوفر جميع اللبنات الأساسية المألوفة لكتاب Jupyter الكلاسيكي (دفتر ملاحظات ، طرفي ، محرر نصوص ، متصفح الملفات ، المخرجات الغنية ، إلخ) في واجهة مستخدم مرنة وقوية. يأتي مثيل JupyterLab مثبتًا مسبقًا مع بعض الامتدادات المفيدة مثل jupyterlab-toc و jupyterlab-git و juptyterlab-tensorboard.
التحكم في الإصدار هو جانب حاسم في التعاون الإنتاجي. لجعل هذه العملية سلسة قدر الإمكان ، قمنا بدمج امتداد Jupyter مخصص مخصصًا متخصصًا في دفع دفاتر ملاحظات مفردة ، عميل GIT المستند إلى الويب بالكامل (UNGIT) ، أداة لفتح وتحرير مستندات نصية عادي (على سبيل المثال ، .py ، .md ) كدفتر ملاحظات (jupytext) ، بالإضافة إلى أداة اندماج دفتر دفتر (NBDIME). بالإضافة إلى ذلك ، يوفر JupyterLab و VS Code أيضًا عملاء GIT القائم على واجهة المستخدم الرسومية.
لمستودعات الاستنساخ عبر https ، نوصي بالانتقال إلى المجلد الجذر المطلوب والنقر على زر git كما هو موضح أدناه:
قد يطلب هذا بعض الإعدادات المطلوبة ، وبعد ذلك يفتح Ungit ، عميل GIT المستند إلى الويب مع واجهة مستخدم نظيفة وبديهية تجعلها مريحة لمزامنة القطع الأثرية في الكود. داخل UNGIT ، يمكنك استنساخ أي مستودع. إذا كانت المصادقة مطلوبة ، فسوف يتم طلب بيانات الاعتماد الخاصة بك.
للالتزام ودفع دفتر ملاحظات واحد إلى مستودع GIT عن بُعد ، نوصي باستخدام المكون الإضافي GIT المدمج في Jupyter ، كما هو موضح أدناه:
للحصول على المزيد من عمليات GIT المتقدمة ، نوصي باستخدام UNGIT. مع UNGIT ، يمكنك القيام بمعظم إجراءات GIT الشائعة مثل PUSH ، والسحب ، والاندماج ، والفرع ، والعلامة ، والخروج ، وغيرها الكثير.
تعد دفاتر Jupyter رائعة ، لكنها غالبًا ما تكون ملفات ضخمة ، مع تنسيق ملف JSON محدد للغاية. لتمكين الاختلاف السلس والاندماج عبر Git ، تم تثبيت مساحة العمل هذه مع NBDime. يدرك NBDIME هيكل مستندات دفتر الملاحظات ، وبالتالي يتخذ تلقائيًا قرارات ذكية عند نشر دفاتر الملاحظات ودمجها. في حالة وجود تعارضات دمج ، سيتأكد NBDime من أن دفتر الملاحظات لا يزال قابلاً للقراءة بواسطة Jupyter ، كما هو موضح أدناه:
علاوة على ذلك ، تأتي مساحة العمل مثبتة مسبقًا مع JupyText ، وهو مكون إضافي Jupyter يقرأ ويكتب دفاتر كملفات نصية عادي. يتيح لك ذلك فتح وتحرير وتشغيل البرامج النصية أو ملفات Markdown (على سبيل المثال ، .py ، .md ) كدفاتر داخل Jupyter. في لقطة الشاشة التالية ، فتحنا ملف Markdown عبر Jupyter:
بالاقتران مع GIT ، يتيح JupyText تاريخ Diff واضحًا وسهولة دمج تعارضات الإصدار. مع كل من هاتين الأدوات ، يصبح التعاون في أجهزة الكمبيوتر المحمولة Jupyter مع GIT واضحًا.
تحتوي مساحة العمل على ميزة لمشاركة أي ملف أو مجلد مع أي شخص عبر رابط محمي رمز. لمشاركة البيانات عبر رابط ، حدد أي ملف أو مجلد من شجرة دليل Jupyter وانقر على زر المشاركة كما هو موضح في لقطة الشاشة التالية:
سيؤدي ذلك إلى إنشاء رابط فريد محمي عبر رمز يمنح أي شخص لديه الوصول إلى الارتباط لعرض البيانات المحددة وتنزيلها عبر واجهة مستخدم FileBrowser:
لإلغاء تنشيط أو إدارة (على سبيل المثال ، توفير أذونات التحرير) ، افتح FileBrowser عبر Open Tool -> Filebrowser وحدد Settings->User Management .
من الممكن الوصول إلى أي منفذ داخلي مساحة العمل بشكل آمن عن طريق تحديد Open Tool -> Access Port . باستخدام هذه الميزة ، يمكنك الوصول إلى واجهة برمجة تطبيقات REST أو تطبيق الويب الذي يعمل داخل مساحة العمل مباشرة مع متصفحك. تمكن الميزة المطورين من إنشاء واجهات برمجة تطبيقات REST أو تصحيح التصحيح أو تطبيقات الويب مباشرة من مساحة العمل.
إذا كنت ترغب في استخدام عميل HTTP أو مشاركة الوصول إلى منفذ معين ، فيمكنك تحديد خيار Get shareable link . هذا ينشئ رابطًا مميزًا مميزًا يمكن لأي شخص لديه إمكانية الوصول إلى الرابط استخدامه للوصول إلى المنفذ المحدد.
يتطلب تطبيق HTTP حل من مسار URL نسبيًا أو تكوين مسار أساسي (
/tools/PORT/). يتم تأمين الأدوات التي يمكن الوصول إليها بهذه الطريقة بواسطة نظام مصادقة مساحة العمل! إذا قررت نشر أي منفذ آخر للحاوية بنفسك بدلاً من استخدام هذه الميزة لجعل أداة متاحة ، فيرجى التأكد من تأمينها عبر آلية المصادقة!
1234 عن طريق تشغيل هذا الأمر في محطة داخل مساحة العمل: python -m http.server 1234Open Tool -> Access Port ، ومنفذ الإدخال 1234 ، وحدد خيار Get shareable link .Access ، وسترى المحتوى الذي توفره http.server من Python. يوفر SSH مجموعة قوية من الميزات التي تمكنك من أن تكون أكثر إنتاجية مع مهام التطوير الخاصة بك. يمكنك بسهولة إعداد اتصال SSH آمن وبكل كلمة مرور بمساحة عمل عن طريق تحديد Open Tool -> SSH . سيؤدي ذلك إلى إنشاء أمر إعداد آمن يمكن تشغيله على أي جهاز Linux أو MAC لتكوين اتصال SSH بدون كلمة مرور وآمنة إلى مساحة العمل. بدلاً من ذلك ، يمكنك أيضًا تنزيل البرنامج النصي Setup وتشغيله (بدلاً من استخدام الأمر).
يعمل البرنامج النصي إعداد فقط على Mac و Linux. لا يتم دعم Windows حاليًا.
ما عليك سوى تشغيل أمر الإعداد أو البرنامج النصي على الجهاز من حيث تريد إعداد اتصال إلى مساحة العمل وإدخال اسم للاتصال (على سبيل المثال ، my-workspace ). قد تتم أيضًا طلب بعض الإدخال الإضافي أثناء العملية ، على سبيل المثال لتثبيت kernel عن بعد إذا تم تثبيت remote_ikernel . بمجرد إعداد اتصال SSH بدون كلمة المرور ، يمكنك الاتصال بنجاح ، يمكنك الاتصال بشكل آمن بمساحة العمل من خلال تنفيذ ssh my-workspace .
إلى جانب القدرة على تنفيذ الأوامر على جهاز بعيد ، توفر SSH أيضًا مجموعة متنوعة من الميزات الأخرى التي يمكن أن تحسن سير عمل التطوير كما هو موضح في الأقسام التالية.
يمكن استخدام اتصال SSH لمنافذ تطبيق الأنفاق من الجهاز البعيد إلى الجهاز المحلي ، أو العكس. على سبيل المثال ، يمكنك فضح منفذ مساحة العمل الداخلي 5901 (خادم VNC) إلى الجهاز المحلي على المنفذ 5000 من خلال التنفيذ:
ssh -nNT -L 5000:localhost:5901 my-workspaceلفضح منفذ تطبيق من جهازك المحلي إلى مساحة عمل ، استخدم خيار
-R(بدلاً من-L).
بعد إنشاء النفق ، يمكنك استخدام عارض VNC المفضل لديك على جهازك المحلي والاتصال بـ vnc://localhost:5000 (كلمة المرور الافتراضية: vncpassword ). لجعل اتصال النفق أكثر مقاومة وموثوقية ، نوصي باستخدام Autossh لإعادة تشغيل أنفاق SSH تلقائيًا في حالة وفاة الاتصال:
autossh -M 0 -f -nNT -L 5000:localhost:5901 my-workspaceيعد نفق المنافذ مفيدًا جدًا عندما تبدأ أي أداة قائمة على الخادم داخل مساحة العمل التي ترغب في إتاحةها لآلة أخرى. في إعداده الافتراضي ، تحتوي مساحة العمل على مجموعة متنوعة من الأدوات التي تعمل بالفعل على منافذ مختلفة ، مثل:
8080 : منفذ مساحة العمل الرئيسية مع إمكانية الوصول إلى جميع الأدوات المتكاملة.8090 : خادم Jupyter.8054 : VS Code Server.5901 : خادم VNC.22 : SSH Server.يمكنك العثور على معلومات المنفذ عن جميع الأدوات في تكوين المشرف.
لمزيد من المعلومات حول نفق المنافذ/إعادة التوجيه ، نوصي بهذا الدليل.
يتيح SCP نسخ الملفات والأدلة بشكل آمن إلى أو من أو بين آلات مختلفة عبر اتصالات SSH. على سبيل المثال ، لنسخ ملف محلي ( ./local-file.txt ) إلى مجلد /workspace داخل مساحة العمل ، تنفيذ:
scp ./local-file.txt my-workspace:/workspace لنسخ دليل /workspace من my-workspace إلى دليل العمل في الجهاز المحلي ، تنفيذ:
scp -r my-workspace:/workspace .لمزيد من المعلومات حول SCP ، نوصي بهذا الدليل.
RSYNC هي أداة لتحويل الملفات ومزامنتها بكفاءة بين الآلات المختلفة (على سبيل المثال ، عبر اتصالات SSH) من خلال مقارنة أوقات التعديل وأحجام الملفات. سيحدد أمر RSYNC الملفات التي يجب تحديثها في كل مرة يتم تشغيلها ، وهو أكثر كفاءة ومريحة بكثير من استخدام شيء مثل SCP أو SFTP. على سبيل /workspace/remote-project-folder/ ، لمزامنة جميع محتوى المجلد المحلي ( ./local-project-folder/
rsync -rlptzvP --delete --exclude= " .git " " ./local-project-folder/ " " my-workspace:/workspace/remote-project-folder/ "إذا كان لديك بعض التغييرات داخل المجلد على مساحة العمل ، فيمكنك مزامنة هذه التغييرات مرة أخرى إلى المجلد المحلي عن طريق تغيير وسيطات المصدر والوجهة:
rsync -rlptzvP --delete --exclude= " .git " " my-workspace:/workspace/remote-project-folder/ " " ./local-project-folder/ "يمكنك إعادة تشغيل هذه الأوامر في كل مرة تريد مزامنة أحدث نسخة من ملفاتك. سوف تتأكد RSYNC من نقل التحديثات فقط.
يمكنك العثور على مزيد من المعلومات حول RSYNC على صفحة الرجل هذه.
إلى جانب نسخ البيانات ومزامنتها ، يمكن أيضًا استخدام اتصال SSH لتركيب الدلائل من جهاز بعيد في نظام الملفات المحلي عبر SSHFS. على سبيل المثال ، لتركيب دليل /workspace في مساحة my-workspace في مسار محلي (على سبيل المثال /local/folder/path ) ، تنفيذ:
sshfs -o reconnect my-workspace:/workspace /local/folder/pathبمجرد تثبيت الدليل البعيد ، يمكنك التفاعل مع نظام الملفات عن بُعد بنفس الطريقة مع أي دليل وملف محلي.
لمزيد من المعلومات حول SSHFS ، نوصي بهذا الدليل.
يمكن دمج مساحة العمل واستخدامها كوقت تشغيل عن بُعد (يُعرف أيضًا باسم kernel/machine/مترجم عن بُعد) لمجموعة متنوعة من أدوات التطوير الشعبية والمعاصفات ، مثل jupyter أو vs code أو pycharm أو colab أو Atom Hydrogen. وبالتالي ، يمكنك توصيل أداة التطوير المفضلة لديك التي تعمل على جهازك المحلي بجهاز بعيد لتنفيذ التعليمات البرمجية. يتيح ذلك تجربة تطوير ذات جودة محلية مع موارد حسابية مستضافة عن بُعد.
تتطلب هذه التكامل هذه عادةً اتصال SSH بدون كلمة مرور من الجهاز المحلي إلى مساحة العمل. لإعداد اتصال SSH ، يرجى اتباع الخطوات الموضحة في قسم الوصول إلى SSH.
يمكن إضافة مساحة العمل إلى مثيل jupyter باعتباره نواة بعيدة باستخدام أداة Remote_ikernel. إذا قمت بتثبيت REMOTE_IKERNEL ( pip install remote_ikernel ) على الجهاز المحلي الخاص بك ، فإن البرنامج النصي SSH SETUP من مساحة العمل سيقدم لك تلقائيًا خيار إعداد اتصال kernel عن بُعد.
عند تشغيل Kernels على الآلات البعيدة ، سيتم حفظ دفاتر الملاحظات نفسها على نظام الملفات المحلي ، ولكن لن تتمكن kernel من الوصول إلى نظام ملفات الجهاز البعيد فقط. إذا كنت بحاجة إلى مزامنة البيانات ، فيمكنك الاستفادة من RSYNC أو SCP أو SSHFS كما هو موضح في قسم الوصول إلى SSH.
في حال كنت ترغب في إعداد وإدارة النواة عن بُعد يدويًا ، استخدم أداة سطر أوامر Remote_ikernel ، كما هو موضح أدناه:
# Change my-workspace with the name of a workspace SSH connection
remote_ikernel manage --add
--interface=ssh
--kernel_cmd= " ipython kernel -f {connection_file} "
--name= " ml-server (Python) "
--host= " my-workspace " يمكنك استخدام وظيفة سطر أوامر Remote_ikernel لإدراج ( remote_ikernel manage --show ) أو حذف ( remote_ikernel manage --delete <REMOTE_KERNEL_NAME> ) اتصالات النواة البعيدة.
يتيح لك Extension SSH Remote Code - SSH فتح مجلد بعيد على أي جهاز بعيد مع وصول SSH والعمل معه تمامًا كما لو كان المجلد على جهازك الخاص. بمجرد الاتصال بجهاز بعيد ، يمكنك التفاعل مع الملفات والمجلدات في أي مكان على نظام الملفات عن بُعد والاستفادة الكاملة من مجموعة ميزات VS Code (Intellisense ، تصحيح الأخطاء ، ودعم الامتداد). يكتشف ويعمل خارج الصندوق مع اتصالات SSH بدون كلمة مرور كما تم تكوينها بواسطة البرنامج النصي SSH SSH مساحة العمل. لتمكين تطبيق VS Code المحلي للاتصال بمساحة العمل:
يمكنك العثور على ميزات ومعلومات إضافية حول امتداد SSH عن بُعد في هذا الدليل.
يوفر Tensorboard مجموعة من أدوات التصور لتسهيل فهم تجربتك وتصحيحها وتحسينها. ويشمل ميزات التسجيل للرقم ، الرسم البياني ، بنية النموذج ، التضمينات ، وتصور النص والصور. تأتي مساحة العمل مثبتة مسبقًا بامتداد Jupyter_tensorboard الذي يدمج Tensorboard في واجهة Jupyter مع وظائف لبدء مثيلات وإدارتها وإيقافها. يمكنك فتح مثيل جديد لدليل سجلات صالح ، كما هو موضح أدناه:
إذا قمت بفتح مثيل Tensorboard في دليل سجل صالح ، فسترى تصورات بياناتك المسجلة:
يمكن استخدام Tensorboard مع العديد من أطر ML الأخرى إلى جانب TensorFlow. باستخدام مكتبة Tensorboardx ، يمكنك تسجيل الدخول بشكل أساسي من أي مكتبة قائمة على Python. أيضا ، Pytorch لديه تكامل تنسورو لوح مباشر كما هو موضح هنا.
إذا كنت تفضل رؤية Tensorboard مباشرة داخل دفتر الملاحظات الخاص بك ، فيمكنك الاستفادة من جوبتر سحر :
%load_ext tensorboard
%tensorboard --logdir /workspace/path/to/logs
توفر مساحة العمل أداة قائمة على الويب المثبتة مسبقًا لمساعدة المطورين أثناء التدريب النموذجي ومهام التجريب الأخرى للحصول على نظرة ثاقبة على كل ما يحدث على النظام ومعرفة اختناقات الأداء.
NetData ( Open Tool -> Netdata ) هي لوحة معلومات في الوقت الفعلي للأجهزة والأداء التي تصور العمليات والخدمات على أنظمة Linux الخاصة بك. يراقب مقاييس حول وحدة المعالجة المركزية و GPU والذاكرة والأقراص والشبكات والعمليات والمزيد.
النظرات ( Open Tool -> Glances ) هي لوحة معلومات مراقبة الأجهزة المستندة إلى الويب ، ويمكن استخدامها كبديل لـ NetData.
ستظهر لك NetData و Ginances إحصائيات الأجهزة الخاصة بالآلة بأكملها التي تعمل عليها حاوية مساحة العمل.
يتم تعريف الوظيفة على أنها أي مهمة حسابية تعمل لوقت معين لإكمالها ، مثل تدريب النموذج أو خط أنابيب بيانات.
يمكن أيضًا استخدام صورة مساحة العمل لتنفيذ رمز بيثون التعسفي دون بدء أي من الأدوات المثبتة مسبقًا. This provides a seamless way to productize your ML projects since the code that has been developed interactively within the workspace will have the same environment and configuration when run as a job via the same workspace image.
To run Python code as a job, you need to provide a path or URL to a code directory (or script) via EXECUTE_CODE . The code can be either already mounted into the workspace container or downloaded from a version control system (eg, git or svn) as described in the following sections. The selected code path needs to be python executable. In case the selected code is a directory (eg, whenever you download the code from a VCS) you need to put a __main__.py file at the root of this directory. The __main__.py needs to contain the code that starts your job.
You can execute code directly from Git, Mercurial, Subversion, or Bazaar by using the pip-vcs format as described in this guide. For example, to execute code from a subdirectory of a git repository, just run:
docker run --env EXECUTE_CODE= " git+https://github.com/ml-tooling/ml-workspace.git#subdirectory=resources/tests/ml-job " mltooling/ml-workspace:0.13.2For additional information on how to specify branches, commits, or tags please refer to this guide.
In the following example, we mount and execute the current working directory (expected to contain our code) into the /workspace/ml-job/ directory of the workspace:
docker run -v " ${PWD} :/workspace/ml-job/ " --env EXECUTE_CODE= " /workspace/ml-job/ " mltooling/ml-workspace:0.13.2In the case that the pre-installed workspace libraries are not compatible with your code, you can install or change dependencies by just adding one or multiple of the following files to your code directory:
requirements.txt : pip requirements format for pip-installable dependencies.environment.yml : conda environment file to create a separate Python environment.setup.sh : A shell script executed via /bin/bash . The execution order is 1. environment.yml -> 2. setup.sh -> 3. requirements.txt
You can test your job code within the workspace (started normally with interactive tools) by executing the following python script:
python /resources/scripts/execute_code.py /path/to/your/jobIt is also possible to embed your code directly into a custom job image, as shown below:
FROM mltooling/ml-workspace:0.13.2
# Add job code to image
COPY ml-job /workspace/ml-job
ENV EXECUTE_CODE=/workspace/ml-job
# Install requirements only
RUN python /resources/scripts/execute_code.py --requirements-only
# Execute only the code at container startup
CMD [ "python" , "/resources/docker-entrypoint.py" , "--code-only" ]The workspace is pre-installed with many popular interpreters, data science libraries, and ubuntu packages:
conda , pip , apt-get , npm , yarn , sdk , poetry , gdebi ...The full list of installed tools can be found within the Dockerfile.
For every minor version release, we run vulnerability, virus, and security checks within the workspace using safety, clamav, trivy, and snyk via docker scan to make sure that the workspace environment is as secure as possible. We are committed to fix and prevent all high- or critical-severity vulnerabilities. You can find some up-to-date reports here.
The workspace provides a high degree of extensibility. Within the workspace, you have full root & sudo privileges to install any library or tool you need via terminal (eg, pip , apt-get , conda , or npm ). You can open a terminal by one of the following ways:
New -> TerminalApplications -> Terminal EmulatorFile -> New -> TerminalTerminal -> New Terminal Additionally, pre-installed tools such as Jupyter, JupyterLab, and Visual Studio Code each provide their own rich ecosystem of extensions. The workspace also contains a collection of installer scripts for many commonly used development tools or libraries (eg, PyCharm , Zeppelin , RStudio , Starspace ). You can find and execute all tool installers via Open Tool -> Install Tool . Those scripts can be also executed from the Desktop VNC (double-click on the script within the Tools folder on the Desktop VNC).
For example, to install the Apache Zeppelin notebook server, simply execute:
/resources/tools/zeppelin.sh --port=1234 After installation, refresh the Jupyter website and the Zeppelin tool will be available under Open Tool -> Zeppelin . Other tools might only be available within the Desktop VNC (eg, atom or pycharm ) or do not provide any UI (eg, starspace , docker-client ).
As an alternative to extending the workspace at runtime, you can also customize the workspace Docker image to create your own flavor as explained in the FAQ section.
The workspace can be extended in many ways at runtime, as explained here. However, if you like to customize the workspace image with your own software or configuration, you can do that via a Dockerfile as shown below:
# Extend from any of the workspace versions/flavors
FROM mltooling/ml-workspace:0.13.2
# Run you customizations, e.g.
RUN
# Install r-runtime, r-kernel, and r-studio web server from provided install scripts
/bin/bash $RESOURCES_PATH/tools/r-runtime.sh --install &&
/bin/bash $RESOURCES_PATH/tools/r-studio-server.sh --install &&
# Cleanup Layer - removes unneccessary cache files
clean-layer.shFinally, use docker build to build your customized Docker image.
For a more comprehensive Dockerfile example, take a look at the Dockerfile of the R-flavor.
To update a running workspace instance to a more recent version, the running Docker container needs to be replaced with a new container based on the updated workspace image.
All data within the workspace that is not persisted to a mounted volume will be lost during this update process. As mentioned in the persist data section, a volume is expected to be mounted into the /workspace folder. All tools within the workspace are configured to make use of the /workspace folder as the root directory for all source code and data artifacts. During an update, data within other directories will be removed, including installed/updated libraries or certain machine configurations. We have integrated a backup and restore feature ( CONFIG_BACKUP_ENABLED ) for various selected configuration files/folders, such as the user's Jupyter/VS-Code configuration, ~/.gitconfig , and ~/.ssh .
If the workspace is deployed via Docker (Kubernetes will have a different update process), you need to remove the existing container (via docker rm ) and start a new one (via docker run ) with the newer workspace image. Make sure to use the same configuration, volume, name, and port. For example, a workspace (image version 0.8.7 ) was started with this command:
docker run -d
-p 8080:8080
--name "ml-workspace"
-v "/path/on/host:/workspace"
--env AUTHENTICATE_VIA_JUPYTER="mytoken"
--restart always
mltooling/ml-workspace:0.8.7
and needs to be updated to version 0.9.1 , you need to:
docker stop "ml-workspace" && docker rm "ml-workspace"docker run -d -p 8080:8080 --name "ml-workspace" -v "/path/on/host:/workspace" --env AUTHENTICATE_VIA_JUPYTER="mytoken" --restart always mltooling/ml-workspace:0.9.1 If you want to directly connect to the workspace via a VNC client (not using the noVNC webapp), you might be interested in changing certain VNC server configurations. To configure the VNC server, you can provide/overwrite the following environment variables at container start (via docker run option: --env ):
| عامل | وصف | تقصير |
|---|---|---|
| VNC_PW | Password of VNC connection. This password only needs to be secure if the VNC server is directly exposed. If it is used via noVNC, it is already protected based on the configured authentication mechanism. | vncpassword |
| VNC_RESOLUTION | Default desktop resolution of VNC connection. When using noVNC, the resolution will be dynamically adapted to the window size. | 1600x900 |
| VNC_COL_DEPTH | Default color depth of VNC connection. | 24 |
Unfortunately, we currently do not support using a non-root user within the workspace. We plan to provide this capability and already started with some refactoring to allow this configuration. However, this still requires a lot more work, refactoring, and testing from our side.
Using root-user (or users with sudo permission) within containers is generally not recommended since, in case of system/kernel vulnerabilities, a user might be able to break out of the container and be able to access the host system. Since it is not very common to have such problematic kernel vulnerabilities, the risk of a severe attack is quite minimal. As explained in the official Docker documentation, containers (even with root users) are generally quite secure in preventing a breakout to the host. And compared to many other container use-cases, we actually want to provide the flexibility to the user to have control and system-level installation permissions within the workspace container.
The workspace comes preinstalled with various common tools to create isolated Python environments (virtual environments). The following sections provide a quick-intro on how to use these tools within the workspace. You can find information on when to use which tool here. Please refer to the documentation of the given tool for additional usage information.
venv (recommended):
To create a virtual environment via venv, execute the following commands:
# Create environment in the working directory
python -m venv my-venv
# Activate environment in shell
source ./my-venv/bin/activate
# Optional: Create Jupyter kernel for this environment
pip install ipykernel
python -m ipykernel install --user --name=my-venv --display-name= " my-venv ( $( python --version ) ) "
# Optional: Close enviornment session
deactivatepipenv (recommended):
To create a virtual environment via pipenv, execute the following commands:
# Create environment in the working directory
pipenv install
# Activate environment session in shell
pipenv shell
# Optional: Create Jupyter kernel for this environment
pipenv install ipykernel
python -m ipykernel install --user --name=my-pipenv --display-name= " my-pipenv ( $( python --version ) ) "
# Optional: Close environment session
exitvirtualenv :
To create a virtual environment via virtualenv, execute the following commands:
# Create environment in the working directory
virtualenv my-virtualenv
# Activate environment session in shell
source ./my-virtualenv/bin/activate
# Optional: Create Jupyter kernel for this environment
pip install ipykernel
python -m ipykernel install --user --name=my-virtualenv --display-name= " my-virtualenv ( $( python --version ) ) "
# Optional: Close environment session
deactivateconda :
To create a virtual environment via conda, execute the following commands:
# Create environment (globally)
conda create -n my-conda-env
# Activate environment session in shell
conda activate my-conda-env
# Optional: Create Jupyter kernel for this environment
python -m ipykernel install --user --name=my-conda-env --display-name= " my-conda-env ( $( python --version ) ) "
# Optional: Close environment session
conda deactivateTip: Shell Commands in Jupyter Notebooks:
If you install and use a virtual environment via a dedicated Jupyter Kernel and use shell commands within Jupyter (eg !pip install matplotlib ), the wrong python/pip version will be used. To use the python/pip version of the selected kernel, do the following instead:
import sys
!{ sys . executable } - m pip install matplotlibThe workspace provides three easy options to install different Python versions alongside the main Python instance: pyenv, pipenv (recommended), conda.
pipenv (recommended):
To install a different python version (eg 3.7.8 ) within the workspace via pipenv, execute the following commands:
# Install python vers
pipenv install --python=3.7.8
# Activate environment session in shell
pipenv shell
# Check python installation
python --version
# Optional: Create Jupyter kernel for this environment
pipenv install ipykernel
python -m ipykernel install --user --name=my-pipenv --display-name= " my-pipenv ( $( python --version ) ) "
# Optional: Close environment session
exitpyenv :
To install a different python version (eg 3.7.8 ) within the workspace via pyenv, execute the following commands:
# Install python version
pyenv install 3.7.8
# Make globally accessible
pyenv global 3.7.8
# Activate python version in shell
pyenv shell 3.7.8
# Check python installation
python3.7 --version
# Optional: Create Jupyter kernel for this python version
python3.7 -m pip install ipykernel
python3.7 -m ipykernel install --user --name=my-pyenv-3.7.8 --display-name= " my-pyenv (Python 3.7.8) "conda :
To install a different python version (eg 3.7.8 ) within the workspace via conda, execute the following commands:
# Create environment with python version
conda create -n my-conda-3.7 python=3.7.8
# Activate environment session in shell
conda activate my-conda-3.7
# Check python installation
python --version
# Optional: Create Jupyter kernel for this python version
pip install ipykernel
python -m ipykernel install --user --name=my-conda-3.7 --display-name= " my-conda ( $( python --version ) ) "
# Optional: Close environment session
conda deactivateTip: Shell Commands in Jupyter Notebooks:
If you install and use another Python version via a dedicated Jupyter Kernel and use shell commands within Jupyter (eg !pip install matplotlib ), the wrong python/pip version will be used. To use the python/pip version of the selected kernel, do the following instead:
import sys
!{ sys . executable } - m pip install matplotlib Certain desktop tools (eg, recent versions of Firefox) or libraries (eg, Pytorch - see Issues: 1, 2) might crash if the shared memory size ( /dev/shm ) is too small. The default shared memory size of Docker is 64MB, which might not be enough for a few tools. You can provide a higher shared memory size via the shm-size docker run option:
docker run --shm-size=2G mltooling/ml-workspace:0.13.2 In general, the performance of running code within Docker is nearly identical compared to running it directly on the machine. However, in case you have limited the container's CPU quota (as explained in this section), the container can still see the full count of CPU cores available on the machine and there is no technical way to prevent this. Many libraries and tools will use the full CPU count (eg, via os.cpu_count() ) to set the number of threads used for multiprocessing/-threading. This might cause the program to start more threads/processes than it can efficiently handle with the available CPU quota, which can tremendously slow down the overall performance. Therefore, it is important to set the available CPU count or the maximum number of threads explicitly to the configured CPU quota. The workspace provides capabilities to detect the number of available CPUs automatically, which are used to configure a variety of common libraries via environment variables such as OMP_NUM_THREADS or MKL_NUM_THREADS . It is also possible to explicitly set the number of available CPUs at container startup via the MAX_NUM_THREADS environment variable (see configuration section). The same environment variable can also be used to get the number of available CPUs at runtime.
Even though the automatic configuration capabilities of the workspace will fix a variety of inefficiencies, we still recommend configuring the number of available CPUs with all libraries explicitly. على سبيل المثال:
import os
MAX_NUM_THREADS = int ( os . getenv ( "MAX_NUM_THREADS" ))
# Set in pytorch
import torch
torch . set_num_threads ( MAX_NUM_THREADS )
# Set in tensorflow
import tensorflow as tf
config = tf . ConfigProto (
device_count = { "CPU" : MAX_NUM_THREADS },
inter_op_parallelism_threads = MAX_NUM_THREADS ,
intra_op_parallelism_threads = MAX_NUM_THREADS ,
)
tf_session = tf . Session ( config = config )
# Set session for keras
import keras . backend as K
K . set_session ( tf_session )
# Set in sklearn estimator
from sklearn . linear_model import LogisticRegression
LogisticRegression ( n_jobs = MAX_NUM_THREADS ). fit ( X , y )
# Set for multiprocessing pool
from multiprocessing import Pool
with Pool ( MAX_NUM_THREADS ) as pool :
results = pool . map ( lst )If you encounter the following error within the container logs when starting the workspace, it will most likely not be possible to run the workspace on your hardware:
exited: nginx (terminated by SIGILL (core dumped); not expected)
The OpenResty/Nginx binary package used within the workspace requires to run on a CPU with SSE4.2 support (see this issue). Unfortunately, some older CPUs do not have support for SSE4.2 and, therefore, will not be able to run the workspace container. On Linux, you can check if your CPU supports SSE4.2 when looking into the cat /proc/cpuinfo flags section. If you encounter this problem, feel free to notify us by commenting on the following issue: #30.
Requirements : Docker and Act are required to be installed on your machine to execute the build process.
To simplify the process of building this project from scratch, we provide build-scripts - based on universal-build - that run all necessary steps (build, test, and release) within a containerized environment. To build and test your changes, execute the following command in the project root folder:
act -b -j buildUnder the hood it uses the build.py files in this repo based on the universal-build library. So, if you want to build it locally, you can also execute this command in the project root folder to build the docker container:
python build.py --makeFor additional script options:
python build.py --helpRefer to our contribution guides for more detailed information on our build scripts and development process.
Licensed Apache 2.0 . Created and maintained with ❤️ by developers from Berlin.
