Libelektra: إنشاء عرض توضيحي مباشر لواجهة مستخدم الويب

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

omnidan يمكنك القيام بذلك؟

سيكون منحل elektrad + web جزءًا من هذا أيضًا.

omnidan هل كان لديك وقت للعمل على هذا أو الفيديو؟

لقد صنعت مقطع فيديو بالفعل: https://drive.google.com/open؟id=13dSC0ereCQGusrwlIodaDostW6eEes72

سأحاول إنشاء صورة عامل إرساء مع تثبيت واجهة مستخدم الويب. هل توجد بالفعل صورة عامل إرساء مثبت عليها libelektra؟ أين سنستضيف صورة عامل ميناء؟

شكرا لك الفيديو رائع! إذا كنت تقوم بعمل فيديو آخر في بعض الأحيان ، فإن وجود مقطع فيديو بدون طلاب كمثال سيكون ممتازًا: ابتسم: (على سبيل المثال تحرير / etc / hosts)

ما هو أفضل خيار لدينا لاستضافة الفيديو ، بحيث يعمل تشغيل الفيديو بسلاسة عبر المتصفحات؟ (في الرابط أعلاه لم يتمكن مستعرضان من تشغيله مباشرة.)

لدي تثبيت nextcloud ، يمكننا تجربته هناك.

أم أن الأمر يتعلق فقط بتنسيق الفيديو الموجود به؟

هل هناك بالفعل صورة عامل إرساء مثبت عليها libelektra

انظر البرامج النصية / عامل الإرساء لبناء الصور.

أين سنستضيف صورة عامل ميناء؟

لدينا سجل Docker الخاص بنا على https://hub.libelektra.org ولكن على حد علمي لم يتم توفيره للجمهور بعد. يعرف ingwinlu المزيد عن ذلك.

@ markus2330 قمت بتحميله على youtube (غير مدرج) ، والذي يجب أن يعمل في جميع المتصفحات: https://youtu.be/lLg9sk6Hx-E

لماذا غير مدرج؟

@ markus2330 يمكنني جعله عامًا ، لقد اعتقدت أنك تريد استخدامه فقط للتضمين على موقع الويب.

الجمهور جيد بالنسبة لي. يمكننا تضمينه في ملاحظات الإصدار التالية أو حتى نشره كتعليق على ردود الفعل الحالية لملاحظات الإصدار؟

ما هي رخصة يوتيوب القياسية؟

لا أعرف ، لقد غيرتها إلى CC BY

أعتقد أن صورة عامل إرساء مع تثبيت Elektra كامل (وأحدث) مسبقًا يمكن أن تكون مفيدة جدًا للعديد من حالات الاستخدام (التجريبي) (وليس فقط واجهة مستخدم الويب).

لذلك أنا حريص تمامًا على الحصول على مثل هذه الصورة عامل الإرساء: غمزة:

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

ومع ذلك ، لن تتمكن من الوصول إلى أي ميزات غير موجودة في حزم دبيان حتى الآن.

شكرا على الادخال.

لسوء الحظ ، لا تتضمن حزم دبيان واجهة مستخدم الويب حتى الآن. وسيكون من الصعب إلى حد ما القيام به (أي خبراء تغليف nodejs هنا؟).

ووجود أجزاء من Elektra مثبتة كحزم ، وأجزاء أخرى عن طريق "make install" لا يبدو واضحًا بالنسبة لي (يمكن أن تتعارض الإصدارات بسهولة).

ingwinlu هل من الممكن أن تستضيف صورة Docker في a7 والتي تم إنشاؤها بواسطةomnidan؟ أو هل تفكر في كتابة Dockerfile لواجهة مستخدم الويب بنفسك؟

سيكون امتلاك صورة dockerfile + (ربما في سجل Docker عام إذا أردنا الحفاظ على خصوصية السجل؟) مع تثبيت أحدث إصدار من Elektra أمرًا رائعًا حقًا.

لم يتم تكوين مستودع a7 للوصول العام. وإذا لم يكن نظام البناء بحاجة إليه ، فمن المنطقي وضعه في سجل عامل الإرساء العام.

لذا فإن الخطة هي أن المطورين يعيدون بناء صورهم الخاصة بالعمال؟ أم يجب أن نضع جميع الصور في ريبو عام؟

هل هناك ضرر محتمل إذا سمحنا بالوصول للقراءة فقط؟

لذا فإن الخطة هي أن المطورين يعيدون بناء صورهم الخاصة بالعمال؟

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

أم يجب أن نضع جميع الصور في ريبو عام؟

سيؤدي ذلك إلى إبطاء نظام الإنشاء في تحديثات الصور كثيرًا.

هل هناك ضرر محتمل إذا سمحنا بالوصول للقراءة فقط؟

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

ingwinlu نعم ، تحميلها إلى سجل عام خيارًا جيدًا. أو هل يمكن أن يكون لدينا سجلان؟

omnidan هل يجوز لك كتابة Dockerfile لواجهة مستخدم الويب؟

@ markus2330 أنشأت ملف Dockerfile ودفعته إلى # 2032 PR. لقد أنشأت أيضًا مجموعة elektra في سجل عامل الإرساء (يمكنني إضافتك كمالك إذا أعطيتني معرف عامل الإرساء الخاص بك) ، ونشرت حاوية elektra/web:1.4.0 إلى سجل Docker وقمت بتحديث الوثائق بالمعلومات حول كيفية تشغيل elektra web عبر docker وكيفية إنشاء حاويات / إصدارات جديدة.

ingwinlu ، هل يمكنك استضافة صورة عامل

بالتأكيد.

omnidan يمكنك الدفع إلى: الأحدث أيضًا؟ ثم سأقوم بإعداده للتحقق من الإصدارات الجديدة التي تم دفعها إلى: الأحدث تلقائيًا وإعادة النشر إذا كان هناك تحديث.

@ markus2330 هل يمكنك توجيه إدخال نظام أسماء النطاقات إلى a7. شيء مثل webui أو webdemo ربما ؟.

ingwinlu شكرا جزيلا لك!
يجب أن يشير webui.libelektra.org webdemo.libelektra.org إلى a7 قريبًا.

omnidan قد يكون webui أكثر تشويقًا إذا قمت بإنشاء بعض kdb mount-info و kdb mount --with-recommends /etc/hosts system/hosts hosts بداية جيدة!

ingwinlu ، يمكنك بالفعل استخدام :latest ، فهو يستخدم :1.4 الآن (سيتم نشر :1.5 في آخر مرة عند دمج PR)

أفضل ما إذا كان بإمكاننا الحصول على 1.5 على الفور ، فلا فائدة من اختبار 1.4 الآن. اعتقدت أن الدمج ليس ضروريا؟

omnidan يبدو أنك أسيء فهم كيفية عمل علامة latest : https://medium.com/@mccode/the -misunderstood-docker-tag-latest-af3babfd6375

https://hub.docker.com/r/elektra/web/tags/ لا يعرض latest . تحتاج إلى دفعها صراحة.

شكرا لتوضيح هذا!

هل يمكنك بدء تشغيل صورة عامل الإرساء 1.5.0-beta على a7 حتى يكون لدينا شيء نجربه غدًا في الاجتماع؟

http://a7.complang.tuwien.ac.at : 33334 /

لم أتمكن من عكس الوكيل لأن المنافذ مشفرة (وهذا لن يعمل مع الإعداد الحالي). لاحظ أيضًا أن elektra تعمل كمستخدم جذر في الحاوية مما يجعلني غير مرتاح كالجحيم.

http://webui.libelektra.org : 33334 / يعمل أيضًا! شكرا لك: 100: مرة.

لاحظ أيضًا أن elektra تعمل كمستخدم جذر في الحاوية مما يجعلني غير مرتاح كالجحيم.

لا تقلق ، فهو ليس جذرًا (ولكن 999) ولا يمكن حتى الكتابة إلى مفاتيح النظام: could not create configuration directory: Could not create directory "/etc/kdb", because: "Permission denied" uid: 999, euid: 999, gid: 999, egid: 999

نعم ولكن لا يتم إنشاء وكيل لذلك لا https. انها مجرد مزورة للترشح
الآن ولكننا لن نحافظ عليها على هذا النحو على المدى الطويل.

markus2330 [email protected] schrieb am Fr. ، 1. يونيو 2018 ، 10:38:

http://webui.libelektra.org : 33334 / يعمل أيضًا! شكرا 💯 مرات.

لاحظ أيضًا أن elektra يعمل كمستخدم جذر في الحاوية التي
يجعلني غير مرتاح مثل الجحيم.

لا تقلق ، فهو ليس جذرًا (ولكن 999) وليس من الممكن حتى
الكتابة إلى مفاتيح النظام: تعذر إنشاء دليل التكوين: لا يمكن
إنشاء دليل "/ etc / kdb" ، لأن: "الإذن مرفوض" uid: 999 ، euid:
999، gid: 999، egid: 999

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ElektraInitiative/libelektra/issues/1901#issuecomment-393810941 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AEOv-lxXTk85wCl8ipo7okci3PKztfWhks5t4P1jgaJpZM4TRVIf
.

المنافذ مشفرة

المشكلة هنا هي أننا نشغل elektrad و webd في حاوية واحدة ، وهذا مخالف لمبادئ الرصيف. لذلك يمكنني فقط تعديل أحد المنفذين (وهو ما يجب أن يكون كافيًا ، طالما أننا بخير مع تشغيل elektrad: 33333)

لاحظ أيضًا أن elektra تعمل كمستخدم جذر في الحاوية مما يجعلني غير مرتاح كالجحيم.

لقد حرصت تحديدًا على إنشاء مستخدم elektra واستخدامه في Dockerfile ، إلا إذا فعلت شيئًا خاطئًا؟

نعم ، آسف للرسالة المستعجلة (أنا ممتلئ تمامًا بالمواعيد في نهاية هذا الأسبوع + أحدث تصميماتي الرئيسية المكسورة للعلاقات العامة).

هناك مشكلتان كبيرتان في Dockerfile الحالي:

عمليات متعددة :
بينما قلت بالفعل إن القيام بذلك مخالف لـ "المبادئ" ، يُقال بشكل أساسي أنه مبدأ لأنه إذا انتهكت القاعدة ، فأنت بحاجة إلى فهم ما يحدث ولماذا يمثل مشكلة.
تقوم بإنشاء برنامج نصي shell يبدأ عمليتين. يتم تشغيل نص الصدفة هذا عبر PID 1. وهذا نوع خاص لـ Docker حيث يتم استخدامه كنظام "init" الذي تعرفه من أنظمة التشغيل التقليدية. ومن ثم فإن هذا هو معرف المنتج الذي يحتاج إلى التحكم / إعادة التشغيل / تسجيل جميع العمليات الأخرى التي تبدأها.
بالنسبة لحاويات العملية الفردية ، يعد هذا أمرًا تافهًا لأن العملية التي بدأت تفعل ذلك عادةً على أي حال لنفسها. لعملية متعددة تحتاج إلى غلاف.
هناك بعض الوثائق المتاحة https://docs.docker.com/config/containers/multi-service_container/
http://supervisord.org/ شائع جدًا لحل المشكلة أيضًا.
أو يمكنك إلقاء نظرة على كيفية عمل حاويات الصفحة الرئيسية الحالية التي كتبتها الشهر الماضي لتقسيمها إلى حاويات خدمة واحدة.

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

لدي المزيد من الوقت الأسبوع المقبل ويمكنني مساعدتك في إعادة كتابة الملفات إذا واجهتك مشكلة.

بالنسبة لحاويات العملية الفردية ، يعد هذا أمرًا تافهًا لأن العملية التي بدأت تفعل ذلك عادةً على أي حال لنفسها.

ingwinlu لسوء الحظ ، لا يبدو أن Node.js يفعل هذا: / أعتقد أنه يمكن حل هذا من خلال تمرير علامة --init عند تشغيل الحاويات. (https://www.elastic.io/nodejs-as-pid-1-under-docker-images/)

أظن أن السبب في ذلك هو أن موقع الواجهة الخلفية مشفر بشكل ثابت إلى شيء مثل المضيف المحلي: 33334 الذي ينكسر في هذه الحالة لأن الحاوية لا تعرضها فعليًا على المضيف المحلي ولكن على اسم المضيف الذي تم إنشاؤه عشوائيًا.

الموقع في الواقع ليس ثابتًا. يتم تقديم العميل دائمًا على نفس المضيف / المنفذ مثل الواجهة الخلفية (webd) ، ويصل ببساطة إلى /api/ على نفس المضيف.

أعتقد أن أفضل طريقة للقيام بذلك هي فصل صور elektrad و webd ، ثم تعيين PORT env var سيعمل أيضًا بشكل صحيح.

node.js على pid 1

لا أثق في --init . لكن عملية التجميع مثل التي تم تقديمها في المقالة تبدو جيدة.

الموقع في الواقع ليس ثابتًا. يتم تقديم العميل دائمًا على نفس المضيف / المنفذ مثل الواجهة الخلفية (webd) ، وهو يصل ببساطة إلى / api / على نفس المضيف.

مرة أخرى لم يكن لدي الوقت لتصحيحه. لقد قمت بإعداد 33334 ليتم تفويضه بالوكيل العكسي على أحد العناوين التي أشرنا إليها إلى a7. أدى ذلك إلى إخفاق في تحميل موقع الويب لأنه لم يتمكن من الوصول إلى العنوان الذي يحتاج إلى تحميله. كان هذا هو الحال أيضًا لفضح 33333: 33333 مباشرة مع 33334 beeing reverse proxy on 443 (https).

حسنًا ، الخطة الجديدة هي:

1. ingwinlu ينشئ docker ووظيفة إنشاء تعمل تلقائيًا على إنشاء الصورة ونشرها على docker.com ( omnidan هل يمكنك منحنا حق الوصول إلى سجل docker.com الخاص بـ elektra؟ هل تحتاج إلى شيء آخر بخلاف أسماء الحسابات ؟)
2. بناءً على تلك الصورة ، يُنشئomnidan (مع المراجعات بواسطةingwinlu) ثلاثة ملفات / صور Docker أخرى تم إنشاؤها بواسطة نفس وظيفة ملحقاتها ):
   
   
   
   1. صورة موسعة مع Elektra الكامل (لجعل واجهة مستخدم الويب أكثر تشويقًا) ،
   
   
   2. صورة موسعة مع elektrad (للعرض التوضيحي الحي ، الجزء 1)
   
   
   3. صورة موسعة مع العميل / الويب (للعرض التوضيحي المباشر ، الجزء 2)
   
   

كمنتج نهائي ، لدينا وظيفة بناء تقوم ببناء أربع صور إلكترا لكل التزام في الماجستير:

1. الحد الأدنى للحد الأدنى (أو مع عرض نطاق ترددي ضئيل)
2. صورة اختبار Elektra كاملة (للأشخاص الذين يجربون استخدام Elektra)
3. صورة تبدأ في elektrad (لعرضنا التجريبي المباشر والأشخاص الذين يجربون واجهة مستخدم الويب)
4. صورة تبدأ في تشغيل العميل / الويب (لعرضنا التوضيحي المباشر والأشخاص الذين يجربون واجهة مستخدم الويب)

هل هذا مناسب لكما؟

هل تحتاج إلى شيء آخر غير أسماء الحسابات؟

أحتاج أسماء مستخدمي Docker Hub ، هذا كل شيء.

بناء على تلك الصورة

هل هو جاهز بعد؟

شكرًا لك ، اسم مستخدم Docker Hub الخاص بي (معرف Docker) هو markus2330

https://hub.docker.com/u/elektra/ يقول أن elektra / web يحتوي بالفعل على 10k + سحب. هل هو شائع جدًا أم أن إعدادنا يفعل شيئًا خاطئًا؟

ingwinlu هل يمكننا إعادة تشغيل خادم الإنشاء بحيث يتم تحديث "webui.libelektra.org" إلى 1.5؟ أو يمكنك تنفيذ مثل هذه الوظيفة من فضلك؟

لا علاقة للبناء على الإطلاق بـ webui.libelektra.org.

تم إعداده لسحب أحدث علامة 1.5.0-beta دائمًا. لقد قمت بتعديله بحيث يستخدم: الأحدث الآن.

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

هل تقصد أن خادم الإنشاء لا ينشر webui؟ هل هناك أي اختلاف في نشر webui والصفحة الرئيسية؟ وإذا كان الأمر كذلك ، فلماذا؟

تم إعداده لسحب أحدث علامة 1.5.0-beta دائمًا. لقد قمت بتعديله بحيث يستخدم: الأحدث الآن.

شكرا لك! هل يتم تحديثه تلقائيًا؟ متى؟

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

هل تقصد أن خادم الإنشاء لا ينشر webui؟ هل هناك أي اختلاف في نشر webui والصفحة الرئيسية؟

لأنه لم يقم أحد بذلك. أقوم بإعداده بسرعة فقط كما هو موضح في التعليقات أعلاه.

وإذا كان الأمر كذلك ، فلماذا؟

لأن لا أحد كان مهتمًا بفعل ذلك ، على الأقل لست على علم بذلك. هناك أيضًا عدة أسئلة للإجابة عليها أولاً:

• من أين يجب أن نحصل على بطاقات الصور من؟
• كيف يتم إعداد التحميل في السجل العام؟
• كيفية إعداد حقوق الوصول إلى السجل العام؟
• متى يجب تشغيل البنايات؟
• ...

ليس لدي حاليًا أي مصلحة في تنفيذه لأن لدي أمور أكثر إلحاحًا يجب الاهتمام بها.

وإذا كان الأمر كذلك ، فلماذا؟

أشار السؤال إلى سبب وجود اختلافات بين نشر webui والصفحة الرئيسية. يمكننا دفع صور واجهة مستخدم الويب إلى سجلنا الخاص ، ما الذي يجب أن يحل الأسئلة؟

يمكن إجراء الدفع إلى docker.com يدويًا في الوقت الحالي (للإصدارات). ولكن لأتمتة هذا سيكون موضع تقدير كبير.

omnidan هل

يمكن إنشاء الصور الجديدة المنقسمة لرسو السفن (تلك التي تشغل عملية واحدة فقط) ودفعها ونشرها بشكل مماثل في الصفحة الرئيسية. المحتمل.

@ markus2330 لقد https://hub.docker.com/u/elektra/dashboard/teams/ ؟ team=owners الآن

أود أن أقول إننا نحتفظ بـ webui.libelektra.org للحصول على صورة Docker العامة.

ويتم إعادة بناء webdemo.libelektra.org على كل التزام في الماجستير.

ingwinlu ما رأيك؟

لقد غيرتها إلى webdemo.libelektra.org في # 2110 PR

أعتقد أنه يمكننا إغلاق هذا الآن؟

omnidan هل يمكنك تحديث الصفحة الأولى أيضًا؟ أصبحت عبارة "القادمة:" صحيحة الآن: الابتسامة: (يمكن تحسين لقطة الشاشة أيضًا.)

عمل عظيم من قبلكما ، شكرا لك!

@ markus2330 نعم ، يمكننا إغلاق هذا. سأرسل لك سريعًا للعلاقات العامة للصفحة الرئيسية غدًا!

شكرًا لكما أيضًا ، خاصةً