JupyterHub في إيلوم

Enterprise Feature: JupyterHub is an enterprise feature in Ilum and requires a valid enterprise license to function. It will not work with the standard open-source license.

جدول المحتويات ​

• نظره عامه
• معمار
• مصادقة LDAP والتفويض
• Gitea Integration (أجهزة الكمبيوتر المحمولة التي يتم التحكم فيها بواسطة الإصدار)
• نشر JupyterHub عبر Helm (التكوين والأسرار)
• مشغل Gitea داخل JupyterHub (تفاصيل DevOps)
• دليل تسجيل الدخول لأول مرة للمستخدمين

نظره عامه ​

JupyterHub في إيلوم يوفر بيئة دفتر ملاحظات Jupyter متعددة المستخدمين متكاملة بإحكام مع منصة Ilum. يسمح لعدة مستخدمين بتسجيل الدخول وإنشاء مثيلات Jupyter المعزولة الخاصة بهم على مجموعة Kubernetes، وكلها تدار بواسطة خدمة JupyterHub مركزية. على عكس المستقل JupyterLab (وهو IDE مستند إلى الويب لمستخدم واحد لأجهزة الكمبيوتر المحمولة) ، يعمل JupyterHub كملف طبقة تنسيق متعددة المستخدمين . يحصل كل مستخدم يقوم بتسجيل الدخول على خادم JupyterLab مخصص (مساحة العمل الشخصية الخاصة به) يعمل داخل نظام المجموعة ، بينما يتعامل JupyterHub مع المصادقة والنشر وإدارة الموارد مركزيا. وهذا يعني أنه يمكن لفرق علوم البيانات مشاركة بنية أساسية مشتركة ولكن لا تزال تعمل في بيئات دفاتر ملاحظات منفصلة.

تشمل الميزات الرئيسية التي يضيفها JupyterHub داخل Ilum ما يلي:

• دعم متعدد المستخدمين: يقوم المستخدمون بالمصادقة (عبر بيانات اعتماد LDAP) ويتلقى كل منهم مساحة عمل Jupyter معزولة تعمل في جراب Kubernetes. يدير JupyterHub كبسولات المستخدم هذه ويضمن فصلها بشكل آمن. هذا يلغي الحاجة إلى عمليات تثبيت Jupyter المحلية ويسمح للمؤسسات باستضافة دفاتر الملاحظات للعديد من المستخدمين في مكان واحد.

• تكامل سبارك: يأتي JupyterHub من Ilum مدمجا مسبقا مع Apache Spark. يتم تكوين كل بيئة باستخدام سباركماجيك ويتصل بمجموعة Ilum Spark من خلال إيلوم ليفي وكيل خدمة. هذا يعني أنه يمكنك تشغيل مهام Spark مباشرة من دفاتر ملاحظاتك، باستخدام سحر Sparkmagic ( النسبة المئوية manage_spark , ٪٪شرارة ) لإنشاء جلسات Spark وإدارتها. يتم تنفيذ مهام Spark على نظام المجموعة (وليس على حاوية دفتر الملاحظات)، مع الاستفادة من الواجهة الخلفية لجلسة Spark التفاعلية من Ilum. باستخدام واجهة برمجة التطبيقات المتوافقة مع Livy من Ilum ، يمكن ل Jupyter تشغيل حسابات Spark الثقيلة أثناء تفريغ العمل إلى مجموعة Spark ، ودمج معالجة البيانات الضخمة بسلاسة في دفاتر الملاحظات الخاصة بك.

• التحكم في الإصدار المدمج مع Gitea: يتم دعم مساحة عمل الكمبيوتر المحمول لكل مستخدم بمستودع Git شخصي على خدمة Gitea المتكاملة من Ilum. عند تسجيل الدخول لأول مرة، يتم إنشاء مستودع وتهيئته تلقائيا باستخدام دفاتر ملاحظات القالب وبنية الدليل. يمكن للمستخدمين إصدار التعليمات البرمجية الخاصة بهم وتتبع التغييرات والتعاون عن طريق دفع الالتزامات إلى هذا الريبو. يعد تكامل Git هذا فريدا لإعداد JupyterHub من Ilum - فهو يضمن عدم حفظ محتوى دفتر الملاحظات على قرص فحسب ، بل يتم التحكم فيه أيضا عن طريق الإصدار ويمكن الوصول إليه من خلال واجهة ويب Git.

• الاختلافات عن JupyterLab القياسي: من منظور المستخدم النهائي ، سيشعر العمل في واجهة JupyterHub بنفس شعور JupyterLab العادي (يمكنك كتابة التعليمات البرمجية وتنفيذ الخلايا وتثبيت الحزم وما إلى ذلك). ومع ذلك ، يضيف JupyterHub ميزات المؤسسة: مركزي المصادقه , عزل متعدد المستخدمين , إدارة الموارد المشتركة و التكامل مع Ilum الأخرى خدمات . في Ilum ، JupyterHub ليس مجرد محرر - إنه جزء من نظام بيئي أكبر يتضمن التحكم في الوصول المستند إلى LDAP ومجموعات Spark المشتركة والبنية التحتية المدارة بواسطة DevOps. يتناقض هذا مع JupyterLab المستقل حيث تعمل على موارد محلية بسياق مستخدم واحد. باختصار، JupyterLab هي واجهة المستخدم بينما JupyterHub هي الخدمة التي تجعلها متعددة المستخدمين ومتصلة بموارد نظام مجموعة Ilum .

معمار ​

بنية تكامل JupyterHub في Ilum.

يوضح الرسم البياني أعلاه كيفية اتصال JupyterHub في Ilum بمكونات مختلفة:

• خدمة JupyterHub (Hub Pod): يعمل المركز المركزي في مجموعة Kubernetes كجزء من Ilum. يتضمن عملية JupyterHub ومخصص مشغل Gitea داخل JupyterHub. تم تكوين المركز لاستخدام LDAP لمصادقة المستخدمين، ويولد خوادم دفتر ملاحظات المستخدم عند الطلب.

• خادم المستخدم الفردي (JupyterLab Pod): عندما يقوم المستخدم بتسجيل الدخول، يقوم JupyterHub بتشغيل جراب مخصص يقوم بتشغيل خادم Jupyter لمستخدم واحد لهذا المستخدم. يتفاعل المستخدمون مع واجهة Jupyter هذه لتشغيل دفاتر الملاحظات. يتم عزل كل جراب مستخدم ولديه حق الوصول فقط إلى بيانات هذا المستخدم (بما في ذلك مستودع Git الخاص به وأي وحدة تخزين ثابتة لأجهزة الكمبيوتر المحمولة).

• خادم LDAP (المصادقة والتفويض): يتطلب JupyterHub دليل LDAP خارجي (أو خدمة LDAP تم نشرها جنبا إلى جنب مع Ilum) لمصادقة المستخدم. عندما يحاول مستخدم تسجيل الدخول إلى JupyterHub، يتصل المركز بخادم LDAP الذي تم تكوينه للتحقق من اسم المستخدم وكلمة المرور. يسمح فقط للمستخدمين الذين يجتازون مصادقة LDAP (ويستوفون معايير معينة لعضوية المجموعة، إذا تم تعيينها). في الواقع، يعمل LDAP كمصدر وحيد للحقيقة لهويات المستخدمين وبيانات الاعتماد عبر خدمات Ilum.

• خدمة Gitea Git (التحكم في الإصدار): يتضمن Ilum خدمة Git المستضافة داخليا (Gitea). JupyterHub مشغل Gitea يراقب نظام المجموعة بحثا عن أحداث مثل بدء تشغيل جراب المستخدم الجديد. عند تسجيل الدخول الأول للمستخدم ، يستخدم المشغل واجهة برمجة تطبيقات Gitea من أجل توفير مستودع Git وفريق للمستخدم. سيقوم جراب دفتر الملاحظات الخاص بالمستخدم بعد ذلك بإجراء مزامنة تهيئة: يستخدم Git (عبر HTTP) لسحب دفاتر ملاحظات القوالب من الريبو الجديد. تستخدم هذه المزامنة بيانات اعتماد LDAP للمستخدم أو حساب خدمة تم ضبطه للمصادقة على Gitea. بعد التهيئة ، تحتوي بيئة المستخدم على نسخة مسحبة من مستودعه (مع وجود دفاتر ملاحظات مبتدئة في مكانها) ، ويمكن الالتزام بأي تغييرات يقوم بها المستخدم وإعادتها إلى Gitea. (التفاصيل في تكامل Gitea القسم أدناه.)

• Ilum Core Services (Livy-Proxy API): Ilum's core (the central management component of Ilum) provides an API for interactive Spark sessions, exposed via the إيلوم ليفي وكيل service. Jupyter notebooks communicate with this service when the user runs Spark code. The Sparkmagic extension in Jupyter is preconfigured with an endpoint pointing to the Livy-proxy (http://ilum-core:9888 internally). When a user creates a Spark session from the notebook, Sparkmagic contacts Ilum's Livy-proxy, which in turn instructs Ilum Core to launch a Spark driver (and executors) for that user's session. The Spark jobs then run on the مجموعة شرارة . Ilum Core manages these Spark pods and links them to the user's context. In practice, this means a user can click "Create Spark Session" in Jupyter and behind the scenes a full Spark context is provisioned on the cluster – all without leaving the notebook interface.

• واجهة مستخدم Ilum والخدمات الأخرى: تم دمج JupyterHub في واجهة مستخدم Ilum كوحدة نمطية. على سبيل المثال ، من واجهة الويب Ilum ، يمكنك الانتقال إلى الوحدات النمطية > JupyterHub لفتح JupyterHub. يمكن لواجهة مستخدم Ilum اختياريا وكيل JupyterHub بحيث يمكن للمستخدمين الذين قاموا بتسجيل الدخول بالفعل إلى Ilum الوصول بسرعة إلى واجهة Jupyter. (بشكل افتراضي، يحتوي JupyterHub على صفحة تسجيل الدخول الخاصة به وإدارة الجلسة الخاصة به والتي تختلف عن واجهة مستخدم Ilum - على الرغم من استخدام نفس الواجهة الخلفية ل LDAP لبيانات الاعتماد.)

باختصار ، يقع JupyterHub في Ilum على مفترق طرق المصادقة (LDAP) , البيانات والتعليمات البرمجية (جيتا) و الحوسبة (Spark عبر Ilum Core) . تضمن البنية أنه عند بدء تشغيل دفتر ملاحظات: يتم التحقق من صحته مقابل دليل مركزي، مع توفير بيئة دفتر ملاحظات جاهزة للاستخدام مع التحكم في الإصدار، والوصول بنقرة واحدة إلى قوة الحوسبة الموزعة.

مصادقة LDAP والتفويض ​

يستخدم JupyterHub الخاص ب Ilum LDAP لكل من المصادقة (التحقق من بيانات اعتماد المستخدم) والتفويض (التحكم في من يمكنه الوصول إلى الخدمة). هذا يعني أنه يجب أن يكون لدى المستخدمين حساب في دليل LDAP الذي تم تكوينه، وسيقوم JupyterHub ربط ب LDAP للتحقق من اسم المستخدم / كلمة المرور في وقت تسجيل الدخول. هناك بعض الجوانب المهمة لكيفية إعداد تكامل LDAP في Ilum:

• LDAP مطلوب: أنت يجب أن يكون لديك خادم LDAP تم تكوينه for JupyterHub to function in Ilum. Ilum does not support JupyterHub with simple internal accounts or OAuth at this time – the hub is tightly integrated with LDAP for consistency with enterprise deployments. If you don’t already have an LDAP server, you can deploy one (for example, an OpenLDAP instance) as part of your Kubernetes environment. In fact, Ilum’s Helm charts allow you to deploy a test OpenLDAP as a dependency in non-production setups. See the LDAP Security documentation for a comprehensive guide to setting up LDAP, including sample LDIFs and Helm values.

• تكوين Helm ل LDAP: يتم توفير جميع تفاصيل الاتصال والاستعلامات الخاصة ب LDAP عبر قيم Helm. كحد أدنى ، ستحتاج إلى تعيين:

  • عنوان URL لخادم LDAP والاسم المميز الأساسي.
  • ربط الاسم المميز وكلمة المرور (إذا كان LDAP يتطلب حساب خدمة للبحث).
  • قاعدة البحث والفلتر للمستخدمين والسمة التي سيتم استخدامها كاسم مستخدم.
  • قاعدة البحث والفلتر للمجموعات (في حالة استخدام قيود تستند إلى المجموعة).

على سبيل المثال، لتمكين LDAP في Ilum، يمكنك تضمين معلمات مثل ما يلي في أمر Helm upgrade/install (يستخدم هذا المثال قيم العناصر النائبة):

helm upgrade --install ilum ilum/ilum \ 
--set ilum-core.security.type="ldap" \ 
    --set ilum-core.security.ldap.urls[0]="ldap://ilum-openldap:389" \
    --set ilum-core.security.ldap.base="dc=ilum,dc=cloud" \
    --set ilum-core.security.ldap.username="cn=admin,dc=ilum,dc=cloud" \
--set ilum-core.security.ldap.password="<bind-password>" \ 
    --set ilum-core.security.ldap.userMapping.base="ou=people" \
    --set ilum-core.security.ldap.userMapping.filter="uid={0}" \
    --set ilum-core.security.ldap.groupMapping.base="ou=groups" \
    --set ilum-core.security.ldap.groupMapping.filter="(member={0})"

في ما سبق، security.type="LDAP" يحول Ilum إلى وضع LDAP ، وتوفر القيم الأخرى معلومات الاتصال والاستعلامات (عامل تصفية UID ، عامل تصفية المجموعة ، إلخ). يجب تعديلها لتتناسب مع مخطط الدليل وهيكله.

• مجموعات LDAP المسموح بها: عادة ، قد لا ترغب في أن يستخدم كل مستخدم LDAP JupyterHub ، لذلك يدعم JupyterHub من Ilum تقييد الوصول إلى مجموعات معينة. يمكنك تكوين المجموعات المسموح بها في مصادقة JupyterHub LDAP. يتم ذلك من خلال توفير DN الكامل لمجموعة واحدة أو أكثر. لن يتمكن سوى المستخدمين الأعضاء في واحدة على الأقل من هذه المجموعات من تسجيل الدخول. من الناحية الفنية ، يحدد مخطط Helm jupyterhub.hub.config.LDAPAuthenticator.allowed_groups مع أسماء النطاقات للمجموعة التي تحددها. على سبيل المثال، إذا كنت تريد فقط أعضاء في cn=datascientist,ou=subgroups,dc=ilum,dc=cloudللوصول إلى Jupyter، يمكنك توفير هذا الاسم DN. سيقوم JupyterHub بعد ذلك بإجراء استعلام LDAP للتأكد من أن المستخدم الذي يقوم بتسجيل الدخول هو عضو في تلك المجموعة قبل السماح بالوصول. (إذا لم يتم تعيين allowed_groups، فيمكن لأي مستخدم LDAP صالح تسجيل الدخول تلقائيا.)

• تعيين سمات المستخدم: كجزء من تكامل LDAP، يقوم Ilum بتعيين سمات LDAP معينة إلى بيئة Jupyter للمستخدم. على سبيل المثال، يتم استخدام سمة uid كاسم مستخدم JupyterHub (وكاسم دليل لمساحة عمل المستخدم). سمات مثل الاسم الكامل (على سبيل المثال، cn أو displayName) و البريد الإلكتروني ( البريد ) يتم سحبها من LDAP ويمكن استخدامها لتكوين Git الخاص بالمستخدم وفي واجهة مستخدم Ilum. تحت الغطاء ، يسمح تكوين Ilum بتحديد سمات LDAP التي تتوافق مع حقول مستخدم Ilum - على سبيل المثال ، تعيين البريد - > البريد الإلكتروني ، cn - >الاسم الكامل. عندما يقوم المستخدم بتسجيل الدخول، تضمن هذه التعيينات أن بيئة Jupyter "تعرف" اسم المستخدم وبريده الإلكتروني. من الناحية العملية ، قد يقوم مولد JupyterHub بتعيين تكوين عميل Git داخل الحاوية باستخدام هذه المعلومات (بحيث تحمل أي التزامات يقوم بها المستخدم اسمه / بريده الإلكتروني الصحيح). وهذا يعني أيضا أن منصة Ilum يمكنها إظهار الهوية المناسبة لخوادم الكمبيوتر المحمول.

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

Gitea Integration (أجهزة الكمبيوتر المحمولة التي يتم التحكم فيها بواسطة الإصدار) ​

إحدى الميزات البارزة ل JupyterHub في Ilum هي تكاملها المدمج مع جيتيا ، خدمة Git خفيفة الوزن من Ilum. يضمن هذا التكامل التحكم في إصدار دفاتر الملاحظات والتعليمات البرمجية لكل مستخدم من لحظة بدء استخدام Jupyter. في ما يلي كيفية عملها وما يحدث عند تسجيل الدخول الأول للمستخدم:

• مستودع Git الشخصي لكل مستخدم: عند تسجيل الدخول لأول مرة ، سيقوم عميل Gitea (الذي يعمل داخل جراب JupyterHub) بإنشاء ملف مستودع جديد في Gitea للمستخدم. عادة ما يكون هذا الريبو خاصا للمستخدم (على الرغم من أنه يمكنه اختيار مشاركته لاحقا). يمكن إنشاء المستودع تحت Gitea معين منظمة أو مساحة الاسم المخصصة لدفاتر Ilum ، أو ببساطة تحت حساب المستخدم - ولكن في كلتا الحالتين ، يكون المستودع الشخصي للمستخدم لدفاتر وملفات Jupyter الخاصة بهم. من أجل الوضوح التنظيمي، يقوم المشغل أيضا بإنشاء ملف فريق في Gitea وتعيين المستخدم لها ، مما يضمن أن هذا المستخدم (والمسؤولين) فقط لديهم حق الوصول إلى المستودع الجديد. في الواقع ، يحصل كل مستخدم على فريقهم الخاص والريبو على خادم Gitea عند تسجيل الدخول الأول (يتم ذلك لتغليف الأذونات - على سبيل المثال ، يمكن للفريق أن يتوافق مع مجموعة Ilum أو يعمل فقط على عزل الوصول)

• قوالب دفتر الملاحظات الأولية: يمكن ل Ilum ملء المستودعات الجديدة مسبقا بمحتوى القالب. يتضمن مخطط helm ConfigMaps أو ملفات القوالب التي تحتوي على دفاتر الملاحظات المبتدئة وبنية الدليل وملفات التكوين وهي مفيدة للمستخدمين الجدد. على سبيل المثال، قد تجد IlumIntro.ipynb دفتر ملاحظات أو مثال دفاتر ملاحظات Spark أو تخطيط مجلد معين بمجرد تسجيل الدخول. تأتي هذه الملفات من Kubernetes ConfigMap (المحدد في مخطط Helm) ويتم نسخها إلى بيئة JupyterHub أثناء التهيئة. ذا هب جيت - init - الريبو ستقوم حاوية init بتنفيذ التزام Git لإضافة هذه القوالب إلى مستودع المستخدم عند الإعداد الأول.

First Login Workflow​

عندما يقوم المستخدم بتسجيل الدخول إلى JupyterHub لأول مرة:

1. JupyterHub يصادق المستخدم عبر LDAP.

2. ذا هب يولد جراب دفتر ملاحظات المستخدم . يبدأ هذا الجراب في تشغيل خادم Jupyter أحادي المستخدم.

3. في الوقت نفسه ، مشغل Gitea يكتشف أنه تم إنشاء جراب دفتر ملاحظات Jupyter جديد (لمستخدم من المحتمل ألا يكون لديه مستودع حتى الآن). ثم يستدعي واجهة برمجة تطبيقات Gitea (باستخدام حساب مسؤول خاص) لإعداد المستودع وحقوق الوصول لهذا المستخدم. (إذا لم يكن المستخدم موجودا بعد في قاعدة بيانات Gitea، فقد يقوم المشغل بإنشاء حساب المستخدم أيضا. في كثير من الحالات، يتم تكوين Gitea باستخدام مصادقة LDAP أيضا، بحيث يمكن للمستخدم استخدام نفس بيانات الاعتماد على واجهة الويب Gitea - ولكن قد يتم إنشاء إدخال أولي عبر واجهة برمجة التطبيقات لإرفاقها بالريبو/الفريق.)

4. بمجرد إنشاء الريبو، تقوم عملية init في جراب المستخدم بمزامنة المحتوى . عادة ما يتضمن ذلك إعداد Git داخل حاوية دفتر الملاحظات واستنساخ المستودع الفارغ من Gitea إلى مساحة عمل المستخدم ، ثم نسخ ملفات القوالب فيه ، و git add / commit ، والدفع مرة أخرى إلى Gitea.

في كلتا الحالتين، يتم استخدام بيانات اعتماد LDAP للمستخدم لعملية Git (بحيث يتم إسناد الالتزام إلى المستخدم ومصادقة الدفع). نظرا لأن Gitea يعمل داخليا ، فإن مخطط Helm يعرف عنوان خدمة Gitea (على سبيل المثال ، ilum-gitea-http: 3000) ويستخدم العنوان المقدم اسم مستخدم/كلمة مرور Git لأداء دفع Git. بعد هذه الخطوة ، لم يعد مستودع المستخدم في Gitea فارغا - فهو يحتوي على دفاتر الملاحظات المبتدئة من القالب. سيعرض متصفح ملفات Jupyter الخاص بالمستخدم هذه الملفات على الفور ، لأنه تم سحبها إلى نظام ملفات الجراب. ينتهي خادم المستخدم من التشغيل ويمكن للمستخدم الآن التفاعل مع واجهة مستخدم دفتر الملاحظات. من وجهة نظرهم، يرون مساحة عمل مملوءة مسبقا ويمكنهم البدء في العمل مع الأمثلة المقدمة أو إنشاء دفاتر ملاحظات جديدة.

الاستخدام المستمر والمزامنة: بعد التهيئة لأول مرة، ينتمي المستودع إلى المستخدم. هناك لا توجد مزامنة قسرية مستمرة من القوالب - يتم تطبيق القوالب مرة واحدة فقط. من المتوقع أن يستخدم المستخدمون Git لإدارة عملهم في المستقبل. هذا يعني أن أي دفاتر ملاحظات جديدة يقومون بإنشائها أو التغييرات التي يجرونها لا يتم دفعها تلقائيا إلى Gitea ما لم يلتزموا ويدفعون. يأتي JupyterLab من Ilum مع ملحق JupyterLab Git المثبتة (يمكن الوصول إليها عبر أيقونة Git في الشريط الجانبي) ، مما يجعل من السهل تنفيذ التغييرات والدفع / السحب داخل واجهة Jupyter. يمكن للمستخدمين أيضا فتح محطة طرفية في Jupyter واستخدام أوامر git يدويا. تم تكوين الأصل البعيد بالفعل للإشارة إلى مستودعهم الشخصي على خادم Ilum Gitea.

التعاون والمشاركة: بشكل افتراضي ، يكون مستودع كل مستخدم خاصا به (بالإضافة إلى أي مسؤول في Ilum). إذا أراد المستخدم مشاركة دفتر ملاحظات، فيمكنه منح الوصول عبر Gitea (على سبيل المثال ، قم بدعوة متعاون إلى الريبو أو تصدير دفاتر الملاحظات). يعني هذا التكامل الوثيق ل Git أنه يمكن تطبيق أفضل الممارسات مثل مراجعة التعليمات البرمجية وتتبع الإصدار على أجهزة الكمبيوتر المحمولة.

هيكل المستودع: يمكن تخصيص الهيكل الدقيق للمستودع الذي تمت تهيئته عبر قيم Helm (باستخدام ConfigMaps أو عن طريق إنشاء صورة Jupyter مخصصة). تتمثل الأنماط الشائعة في تضمين مجلد لنماذج دفاتر الملاحظات (على سبيل المثال ، العمل / ). وهذا يعطي المستخدمين الجدد إرشادات ويضمن بنية مشروع متسقة عبر المؤسسة.

نصيحة للمستخدمين:
بعد تسجيل الدخول لأول مرة، يكون خادم دفتر الملاحظات مرتبطا بالفعل بمستودع Git.

عند النقر فوق الزر "حفظ" في Jupyter، يتم حفظ التغييرات الخاصة بك فقط في التخزين الدائم الشخصي (PVC) على نظام المجموعة. وهذا يعني أن جميع عمليات التحرير ودفاتر الملاحظات الجديدة تظل متوفرة في مساحة العمل الخاصة بك، حتى إذا تمت إعادة تشغيل الخادم الخاص بك، طالما لم يتم حذف بيانات المستخدم الخاصة بك.

إذا كنت ترغب في نسخ التغييرات احتياطيا إلى مستودع Git الخاص بك (المستضاف على Gitea) أو مشاركتها مع الآخرين ، فأنت بحاجة إلى استخدام تكامل Git في JupyterLab:

• افتح لوحة Git (على الشريط الجانبي الأيسر).
• قم بتنظيم التغييرات وإضافة رسالة التزام وتنفيذ عملك.
• انقر فوق "دفع" لتحميل التزاماتك إلى خادم Git المركزي.

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

باختصار ، يحول تكامل Gitea في Ilum مساحة عمل Jupyter إلى مستودع مشروع يتم التحكم فيه بواسطة الإصدار من البداية. هذا يشجع على التكاثر والتعاون ، ويتوافق مع GitOps المبادئ (حتى لأجهزة الكمبيوتر المحمولة). يمكن لعلماء البيانات التعامل مع دفاتر الملاحظات على أنها تعليمات برمجية - تنفيذ التغييرات وكتابة رسائل الالتزام واستخدام الفروع أو طلبات السحب للتحديثات الرئيسية - كل ذلك مع البقاء في بيئة Jupyter المريحة.

نشر JupyterHub عبر Helm (التكوين والأسرار) ​

To successfully deploy JupyterHub, you must enable the service and configure the LDAP connection details for both Ilum Core and Gitea.

1. Enable and Configure LDAP​

You must provide your LDAP server details. If you do not have an existing LDAP server, you can enable the bundled OpenLDAP service (which is also disabled by default) for testing purposes.

مثل القيم.yaml configuration:

# 1. Enable the bundled OpenLDAP service (for testing/demo only)
OpenLDAP : 
  تمكين :  صحيح 

# 2. Configure Ilum Core to use LDAP
إيلوم كور : 
  أمن : 
    نوع :  "LDAP" 
    LDAP : 
      # URL of your LDAP server (or the bundled one)
      عناوين URL : 
        - LDAP : إيلوم - OpenLDAP : 389
      قاعدة :  "dc=ilum,dc=cloud"
      اسم المستخدم :  "cn=admin,dc=ilum,dc=cloud"
      شعار :  "Not@SecurePassw0rd" # Change this!
      # User search settings
      خريطة المستخدم : 
        قاعدة :  "ou = الناس" 
        راووق :  "uid = {0}" 
      # Group search settings
      تعيين المجموعة : 
        قاعدة :  "ou=groups"
        راووق :  "(عضو = {0})" 

# 3. Enable JupyterHub
ilum-jupyterhub: 
  تمكين :  صحيح 

# 4. Configure Gitea with LDAP (Required for notebook storage)
جيتا : 
  تمكين :  صحيح 
  جيتا : 
    LDAP : 
      -  اسم :  "LDAP"
        securityProtocol:  "unencrypted"
        مضيف :  "ilum-openldap"
        ميناء :  389
        bindDn:  "cn=admin,dc=ilum,dc=cloud"
        bindPassword:  "Not@SecurePassw0rd"
        userSearchBase:  "ou=people,dc=ilum,dc=cloud"
        userFilter:  "(uid=%s)"
        adminFilter:  "(uid=ilumadmin)"
        usernameAttribute:  "أويد" 
        surnameAttribute:  "sn"
        emailAttribute:  "البريد" 
        synchronizeUsers:  صحيح 
    التكوين : 
      cron: 
        sync_external_users: 
          تمكين :  "صحيح" 
          RUN_AT_START:  صحيح 
          NOTICE_ON_SUCCESS:  صحيح 
          SCHEDULE:  "@every 5m"
          UPDATE_EXISTING:  صحيح 

Enterprise Image Access​

The Ilum Enterprise license grants access to private Docker repositories containing the optimized JupyterHub images required for the platform. To use these images, you must configure a Kubernetes secret to authenticate with the registry.

You can configure ilum-jupyterhub to automatically create this secret using your credentials:

ilum-jupyterhub: 
  imagePullSecret: 
    create:  صحيح 
    # The registry URL provided with your license
    registry:  "registry.ilum.cloud"
    # Your enterprise username
    اسم المستخدم :  "my-enterprise-user"
    # Your enterprise password/token
    شعار :  "my-secret-token"
    البريد الإلكتروني :  " [البريد الإلكتروني محمي] " 

Alternatively, if you have already created a secret in your namespace (e.g., my-reg-cred), you can reference it:

ilum-jupyterhub: 
  imagePullSecret: 
    create:  خطأ 
    اسم :  "my-reg-cred"
    automaticReferenceInjection:  صحيح 

Advanced JupyterHub Configuration​

While the basic configuration enables the service, ilum-jupyterhub offers granular control over its integrations.

JupyterHub Specific LDAP​

By default, JupyterHub can share the global LDAP settings, but you can also configure it independently if needed. This is useful if JupyterHub users are in a different directory or require different search filters.

ilum-jupyterhub: 
  LDAP : 
    تمكين :  صحيح 
    عناوين URL : 
      - LDAP : إيلوم - OpenLDAP : 389
    قاعدة :  "dc=ilum,dc=cloud"
    اسم المستخدم :  "cn=admin,dc=ilum,dc=cloud"
    شعار :  "Not@SecurePassw0rd"
    مسؤولالمستخدمون : 
      -  ilumadmin
      - المشرف 
    userSearchBase:  "ou=people,dc=ilum,dc=cloud"
    userSearchFilter:  "uid = {0}" 
    groupSearchBase:  "ou=groups,dc=ilum,dc=cloud"
    groupSearchFilter:  "(عضو = {0})" 
    allowedGroups:  [ ] 
    userAttribute:  "أويد" 
    fullnameAttribute:  "سي إن " 
    emailAttribute:  "البريد" 
    groupNameAttribute:  "سي إن " 
    groupMemberAttribute:  "member"
    useSsl:  خطأ 
    startTls:  خطأ 
    lookupDn:  صحيح  

Gitea Connection Settings​

ال بوابه section in ilum-jupyterhub controls how the Hub connects to Gitea to provision repositories. This is pre-configured in helm aio to use the internal Gitea, but can be customized.

ilum-jupyterhub: 
  بوابه : 
    existingSecret: إيلوم - بوابه - وثائق التفويض 
    البريد الإلكتروني : ilum@ilum 
    مستودع : جوبيتر 
    address:  "ilum-gitea-http:3000"
    عنوان URL :  "http://ilum-gitea-http:3000"
    orgName:  "ilum-jupyterhub"
    operatorImage: 
      اسم :  docker.ilum.cloud/ilum- jupyterhub
      العلامه : جيتا - المشغل - 4.3.1
    سر : 
      اسم : إيلوم - بوابه - وثائق التفويض 
      usernameKey: اسم المستخدم 
      passwordKey: شعار 

SSH Access to Notebook Servers​

Ilum's JupyterHub packaging includes SSH access to single-user notebook pods, enabling power users to connect remotely via SSH for advanced workflows like VS Code Remote development, direct terminal access, or file synchronization. This feature is disabled by default.

SSH Architecture​

SSH access is opt-in and requires external Kubernetes Secrets containing host keys and authorized user keys. These secrets must be created outside of Helm to ensure host fingerprints remain stable across upgrades.

The SSH implementation supports two modes:

• أحسن طريقة (default): All users share a single authorized_keys file from one Kubernetes Secret. One NodePort Service provides SSH access to all user pods.
• perUserطريقة : Each user has a dedicated Secret (e.g., ssh-keys-{username}) with their own authorized_keys. The SSH operator creates a separate NodePort Service for each user, providing isolated SSH endpoints.

Step 1: Generate SSH Keys​

Create host keys (RSA, ECDSA, ED25519) and an authorized_keys file containing public keys of users who may SSH into notebook pods.

ssh-keygen -t rsa -b 4096 -N '' -f ssh_host_rsa_key
ssh-keygen -t ecdsa -b 521 -N '' -f ssh_host_ecdsa_key
ssh-keygen -t ed25519 -N '' -f ssh_host_ed25519_key

# For master mode: combine all user public keys
cat user1.pub user2.pub > authorized_keys

Step 2: Create Kubernetes Secret​

من أجل أحسن mode:

Create a single secret containing host keys and the shared authorized_keys:

kubectl create secret generic ilum-jupyterhub-ssh-keys \
  --from-file=ssh_host_rsa_key=ssh_host_rsa_key \
  --from-file=ssh_host_ecdsa_key=ssh_host_ecdsa_key \
  --from-file=ssh_host_ed25519_key=ssh_host_ed25519_key \
  --from-file=authorized_keys=authorized_keys

من أجل perUser mode:

Create one secret per user following the naming template ssh-keys-{username} (configurable via ssh.perUserSecretNameTemplate):

# Example for user "alice"
kubectl create secret generic ssh-keys-alice \
  --from-file=authorized_keys=alice_authorized_keys

The SSH operator sidecar automatically provisions NodePort Services for every user secret it discovers, enabling per-user SSH endpoints.

Step 3: Enable SSH in Helm Configuration​

Add the following to your القيم.yaml before installing or upgrading:

ilum-jupyterhub: 
  ssh: 
    تمكين :  صحيح 
    طريقة : أحسن # or "perUser" for per-user secrets and services
    keysSecret: إيلوم - jupyterhub- ssh- keys
    خدمة : 
      نوع : NodePort 
      ميناء :  2222
      nodePort :  ""   # Kubernetes will auto-assign if empty
    sshdConfig: 
      customConfig: 
        -  "StrictModes no"  # Required due to Kubernetes volume permissions
    operatorImage: 
      اسم :  docker.ilum.cloud/ilum- jupyterhub
      العلامه :  ssh- المشغل - 4.3.1
    extraEnv: 
      -  اسم :  SSH_IDLE_TIMEOUT
        قيمة :  "3600"  # Optional: terminate idle SSH sessions after 1 hour

مشغل Gitea داخل JupyterHub (تفاصيل DevOps) ​

بالنسبة لمسؤولي نظام المجموعة والمشرفين، من المفيد فهم تنفيذ مشغل Gitea الذي يعمل مع JupyterHub. هذا المكون هو ما يعمل على أتمتة توفير مستودع Git للمستخدمين الجدد:

• ما هذا؟ مشغل Gitea هو مشغل Kubernetes صغير (وحدة تحكم) تم إنشاؤه باستخدام كوبف إطار عمل (Kubernetes Operator Pythonic Framework). يتم تشغيله كجزء من جراب JupyterHub (وليس كنشر منفصل). في الأساس ، عندما تبدأ حاوية JupyterHub ، فإنها تطلق أيضا عملية المشغل (المكتوبة بلغة Python) التي تتصل بخادم Kubernetes API وبواجهة برمجة تطبيقات Gitea.

• ماذا يشاهد؟ إنه يستمع إلى الأحداث المتعلقة ب JupyterHub - على وجه التحديد ، يمكنه مراقبة إنشاء كبسولات دفتر ملاحظات المستخدم أو أحداث Hub عبر واجهة برمجة تطبيقات JupyterHub. يتمثل التصميم الشائع في مراقبة Kubernetes Pods مع تسمية معينة (على سبيل المثال ، تسمية مثل component=singleuser-server أو تعليق توضيحي يضيفه JupyterHub لجرابات المستخدم). عندما يكتشف جراب جديد لمستخدم معين ، فإنه يفسر ذلك على أنه "قام المستخدم X بتسجيل الدخول وبدء تشغيل الخادم الخاص به".

• الريبو / إنشاء الفريق: عند مثل هذا الحدث ، سيتفاعل المشغل مع واجهة برمجة تطبيقات REST من Gitea لضمان حصول المستخدم على موارد Git اللازمة:

  • قد يكون إنشاء Gitea حساب المستخدم للمستخدم الذي يقوم بتسجيل الدخول إذا لم يكن موجودا. (إذا تم تكوين Gitea لاستخدام مصادقة LDAP، فقد يتم إنشاء الحساب تلقائيا عند تسجيل الدخول الأول بدلا من ذلك؛ قد يختلف سلوك المشغل اعتمادا على التكوين. في كثير من الحالات، سيتم إنشاء حساب المستخدم في Gitea في المرة الأولى التي يدفع فيها المستخدم أو يسجل الدخول إلى Gitea، لذلك قد لا يقوم المشغل بإنشاء المستخدم بشكل صريح.)

  • سوف إنشاء فريق و / أو مؤسسة لاحتواء مستودع المستخدم منطقيا. على سبيل المثال، قد يكون لدى Ilum منظمة عالمية (مثل ilum-jupyterhub) وسيقوم المشغل بإنشاء فريق داخل تلك المنظمة يحمل اسم المستخدم. الغرض من ذلك هو إدارة أذونات المستودع في Gitea. سيشمل الفريق المستخدم (الذي يربط حساب Gitea الخاص به) وربما لا أي شخص آخر (لسيناريو الريبو الشخصي). يستخدم المشغل بيانات اعتماد مسؤول Gitea (من ilum-jupyter.git.username/password) لتنفيذ هذه الإجراءات عبر واجهة برمجة التطبيقات.

  • بعد ذلك ، هو ينشئ مستودعا في Gitea للمستخدم. من التكوين السابق ، نعلم أن نمط اسم الريبو الافتراضي هو jupyterhub-{اسم المستخدم} . سيقوم المشغل بإنشاء هذا الريبو (مرة أخرى عبر Gitea API) ، وتعيين ملكيته للمستخدم / الفريق المناسب ، وربما تهيئته.

  • ثم تعيين الأذونات - على سبيل المثال ، إذا كنت تستخدم مؤسسة ، فإنها تضمن أن الفريق الذي تم إنشاؤه لديه حق الوصول للكتابة إلى المستودع الجديد وأن المستخدم في هذا الفريق. بهذه الطريقة يمكن للمستخدم (عند المصادقة على Gitea) قراءة / كتابة الريبو الخاص به ، لكن لا يمكن للآخرين (ما لم تتم إضافته). تحدث كل هذه الخطوات في غضون ثوان قليلة بعد حدث بدء الكبسولة.

• التشغيل داخل نظام المجموعة: نظرا لأن المشغل يعمل داخل جراب JupyterHub ، فإنه يتمتع بإمكانية الوصول إلى الشبكة إلى خدمة Gitea (عنوان نظام المجموعة الداخلي) وإلى واجهة برمجة تطبيقات Kubernetes عبر حساب خدمة. يتم تحديد نطاقه فقط إلى مساحة اسم Ilum (سيراقب القرون في مساحة الاسم هذه). لا ينشر أي CRD - من المحتمل أن يكون مجرد مشاهدة الموارد المضمنة مثل Pod أو أحداث Secret. هذا يعني أنك لن ترى نشرا منفصلا ل "gitea-operator". إنه مضمن. يبسط هذا التصميم النشر ولكنه يعني أنه إذا كان جراب JupyterHub معطلا ، فإن المشغل معطل أيضا.

• التسجيل والتصحيح: بالنسبة إلى DevOps ، إذا لم يتم إنشاء مستودع المستخدم أو لم تتم مزامنة القوالب ، فإن أول مكان يجب التحقق منه هو سجلات جراب JupyterHub. عادة ما يسجل المشغل إجراءاته (على سبيل المثال ، "إنشاء مستودع Gitea للمستخدم X" ، أو الأخطاء في حالة فشل استدعاءات واجهة برمجة التطبيقات). قد تكون المشكلات الشائعة هي بيانات الاعتماد التي تم تكوينها بشكل خاطئ (على سبيل المثال ، كلمة مرور git خاطئة ، لذلك لا يمكن المصادقة على Gitea - في مثل هذه الحالة ، سترى خطأ 401/403 في السجلات) ، أو لا يمكن الوصول إلى Gitea. أيضا، إذا كانت كلمة مرور LDAP للمستخدم تحتوي على أحرف خاصة أو إذا قام عامل التشغيل بتمريرها بشكل غير صحيح لاستنساخ Git، فقد تكون هناك مشكلات في ترميز عنوان URL (لذا تأكد من عدم وجود أحرف إشكالية أو التعامل معها). هذه أشياء يجب مراعاتها عند تصحيح الأخطاء.

• أساسيات مشغل Kopf: نظرا لأنه يستخدم Kopf ، فمن المحتمل أن يتم تعريف المشغل بواسطة وظيفة Python المزينة للتفاعل مع الأحداث. يتعامل Kopf مع النموذج المعياري لمشاهدة وجدولة الوظيفة في الأحداث. يسهل هذا الاختيار توسيع منطق المشغل إذا لزم الأمر (على سبيل المثال ، يمكن للمرء تعديله لإنشاء موارد إضافية ، أو لتنظيف المستودعات عند إزالة المستخدمين - على الرغم من أنه قد لا يتم تنفيذ التنظيف التلقائي لتجنب حذف رمز المستخدم).

مشغل Gitea هذا هو في المقام الأول محل اهتمام المشرفين. لن يراها المستخدمون النهائيون العاديون (إنها خلفية بالكامل). ومع ذلك ، من الجيد معرفة أنه موجود: أي أتمتة حول إنشاء Git repo تحدث بسبب هذا المكون. إذا قمت في المستقبل بترقية Ilum أو Gitea ، فيجب عليك التأكد من أن حساب المشغل لا يزال لديه الأذونات الصحيحة. على سبيل المثال ، إذا قمت بتغيير كلمة مرور مسؤول Gitea ، فقم بتحديث سر Helm حتى يستمر المشغل في العمل.

In summary, the Gitea operator automates what would otherwise be a manual DevOps task (provisioning a Git repo for every user and linking it to their environment). It's a أتمتة Kubernetes الأصلية living inside the JupyterHub container. DevOps teams should include this in their mental model of the system: when a new user comes online in JupyterHub, there's an automated process creating repos and teams in Gitea to support that user. If something goes wrong in that process, it can affect the user experience (e.g., user's notebook might start but their Git repo isn't ready). Thus, keep an eye on those logs during initial setup or after major changes.

دليل تسجيل الدخول لأول مرة للمستخدمين ​

يوفر هذا القسم دليلا سريعا للمستخدمين النهائيين الذين يصلون إلى JupyterHub في Ilum لأول مرة.

الوصول إلى JupyterHub: بعد تسجيل الدخول إلى واجهة مستخدم Ilum باستخدام بيانات اعتماد تسجيل الدخول الأحادي الخاصة بك، يجب أن يتم منحك حق الوصول تلقائيا إلى خادم JupyterHub الشخصي الخاص بك. للبدء، انتقل إلى الوحدات النمطية > JupyterHub في واجهة Ilum. يجب أن يؤدي هذا إلى فتح بيئة JupyterHub مباشرة - دون الحاجة إلى تسجيل دخول منفصل.

استكشاف أخطاء الوصول وإصلاحها:

• إذا لم تتم إعادة توجيهك تلقائيا إلى خادم Jupyter بعد تسجيل الدخول إلى Ilum، أو رأيت صفحة تسجيل الدخول إلى JupyterHub - فقد يكون هناك خطأ في تكوين شيء ما.
• في هذه الحالة، حاول تسجيل الدخول إلى صفحة JupyterHub باستخدام السمة نفس بيانات اعتماد SSO (Ilum) استخدمتها ل Ilum نفسها.
• إذا كنت لا تزال غير قادر على تسجيل الدخول، أو طلب منك بيانات اعتماد مرارا وتكرارا، فيرجى إبلاغ مسؤول Ilum بهذه المشكلة.
• قد تفتقر أيضا إلى عضوية المجموعة المطلوبة للوصول إلى Jupyter (على سبيل المثال ، مستخدمو Jupyter أو علماء البيانات ). يمكن للمشرف إثبات ملكية حق الوصول ومنحه حسب الحاجة.

بدء تشغيل خادم الكمبيوتر المحمول الخاص بك: بعد تسجيل الدخول بنجاح ، سترى رسالة مثل "بدء تشغيل الخادم الخاص بك" أو تتم إعادة توجيهك إلى صفحة النشر. يقوم JupyterHub الآن بتشغيل خادم دفتر الملاحظات الشخصي الخاص بك داخل نظام المجموعة. هذا يمكن أن يستغرق ~ 30 ثانية إلى بضع دقائق ، خاصة إذا كانت هذه هي المرة الأولى لك (قد يقوم النظام بتهيئة التخزين وإنشاء مستودع Git الخاص بك وسحب صور الحاوية). يرجى التحلي بالصبر - يحدث هذا فقط عند بدء التشغيل الأول أو بعد أن تكون الخدمة خاملة لفترة طويلة. إذا استغرقت العملية وقتا طويلا أو كانت هناك أخطاء، فقد ترى سجلا أو صفحة خطأ - في مثل هذه الحالات، حاول التحديث بعد دقيقة. عادة ، على الرغم من ذلك ، ستهبط تلقائيا في واجهة Jupyter بمجرد أن يصبح الخادم جاهزا.

واجهة JupyterLab: بمجرد تشغيل الخادم الخاص بك ، سيفتح متصفحك JupyterLab واجهه. هذا IDE مستند إلى الويب حيث يمكنك إنشاء دفاتر ملاحظات وكتابة التعليمات البرمجية وفتح محطة طرفية وما إلى ذلك. على يمين الصفحة، سترى متصفح الملفات. يجب أن تلاحظ بعض المجلدات أو دفاتر الملاحظات الموجودة مسبقا هنا - هذه هي قوالب المبتدئين provided by Ilum. For example, you might see a “IlumIntro.ipynb” or a project folder structure. Feel free to open these notebooks to read the instructions or run the example code. They are meant to help you get started with using Spark and other features in Ilum. You can also create new notebooks by clicking the “+” icon or using the Launcher (which appears by default with options like “Python 3 (ipykernel)” or other kernels).

استخدام Spark في دفتر ملاحظات: تتمثل إحدى المزايا الرئيسية ل JupyterHub في Ilum في تشغيل وظائف Spark من أجهزة الكمبيوتر المحمولة.

يتم وصف سير العمل التفصيلي لتشغيل Apache Spark في دفاتر ملاحظات Ilum هنا .

يرجى الرجوع إلى هذا الدليل للحصول على إرشادات خطوة بخطوة حول بدء جلسات Spark وإدارة نقاط النهاية واستخدام سحر Spark في Ilum.

العمل مع Git (حفظ دفاتر الملاحظات): تذكر أن الدليل الرئيسي الخاص بك هو في الواقع مستودع Git مرتبط بخادم Gitea. بعض نصائح الاستخدام:

• عند إنشاء ملفات أو تعديلها، ستشير شارة صغيرة على أيقونة Git (الشريط الجانبي الأيسر) إلى عدد التغييرات. انقر فوق أيقونة Git لفتح لوحة Git. سترى قائمة بالملفات التي تم تغييرها. يمكنك تنظيم التغييرات وتنفيذها برسالة كلها من هذه الواجهة.
• ل ارتكب التغييرات: اكتب رسالة التزام في لوحة Git وانقر فوق أيقونة علامة الاختيار (commit).
• ل دفع إلى الخادم: انقر على رمز السهم لأعلى. بعد الدفع، يتم تخزين عملك بأمان على الخادم. يمكنك الانتقال إلى واجهة الويب Ilum Gitea (يمكن الوصول إليها عبر وحدات > Gitea في Ilum UI) لرؤية المستودع الخاص بك. يجب أن يظهر آخر التزام لك. يضمن تكامل Git عدم فقدان العمل حتى إذا تمت إعادة تدوير خادم الكمبيوتر المحمول.

إيقاف التشغيل وتسجيل الخروج:

• يؤدي تسجيل الخروج إلى قطع اتصالك بخادم Jupyter فقط. إنه كذلك لا قم بإيقاف خادم دفتر الملاحظات أو إيقاف تشغيله على الفور.
• سيستمر خادم دفتر الملاحظات في العمل في الخلفية حتى يتم إلغاء تنشيطه تلقائيا بواسطة النظام بعد فترة من عدم النشاط (يتم تعيين مهلة الخمول بواسطة المسؤول).
• تحذير: أي عمل غير محفوظ في دفاتر ملاحظات مفتوحة (غير ملتزم ب Git أو حفظه) سيكون مفقود إذا تم إيقاف تشغيل الخادم تلقائيا بسبب عدم النشاط.
• في المرة التالية التي تقوم فيها بتسجيل الدخول، ستتم إعادة تشغيل الخادم الخاص بك وستتم استعادة ملفاتك من التخزين المستمر (Git والدليل الرئيسي الخاص بك)، ولكن لن يتم استرداد التغييرات غير المحفوظة/غير المتزامنة.
• أفضل الممارسات: احفظ دائما دفاتر الملاحظات الخاصة بك وقم بإجراء تغييرات على Git قبل تسجيل الخروج أو الابتعاد لفترة أطول.