جوجو في لمحة

في اليوم الآخر صادفت أداة Canonical Juju.

تدعي قصاصات من الإنترنت أنها أداة لإدارة التهيئة مثل Chef أو Ansible أو Puppet.

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

تعد Juju أشبه بأوركسترا VM-agnostic (مثل Nomad أو Kubernetes). على ذلك ، يمكنك وصف تكوين البنية التحتية للتطبيق بشكل تعريفي: ما هي التطبيقات التي نقوم بتشغيلها ، وعلى أي الأجهزة ، وفي عدد النسخ ، وكيف يتم توصيلها بالخدمات الأخرى.
ولكن على عكس Kubernetes ، يمكن أن تعمل ليس فقط مع Docker ، ولكن أيضًا مع أي نوع من الأجهزة الافتراضية.

يقولون أن النواة والوكيل والعميل مكتوبة بلغة Golang - ولم أنظر إليها.

يوصف الجزء المتعلق بالتهيئة نفسها عادة في مزيج من YAML و Python (تقول الأرصفة أنه يمكنك استخدام لغات أخرى إلى جانب بيثون).

كيف يعمل هذا كله؟

إخلاء المسئولية : لا تدعي هذه المقالة أنها وصف كامل ودقيق ، بل أراها كوسيلة لخفض عتبة الدخول لأولئك الذين يرغبون في إلقاء نظرة على Juju والمساعدة في تصفح الوثائق.

الوثائق الكاملة هنا: https://docs.jujucharms.com/

كما هو مكتوب بالفعل أعلاه ، في Juju هناك العديد من المكونات:

• وحدة التحكم هي جزء الخادم الذي يخصص الأجهزة الافتراضية. لدى كل موفر [سحابة] وحدة التحكم الخاصة به (بما في ذلك لموفري الخدمات السحابية تمامًا ، مثل LXD المحلي أو المعدن كخدمة ).
  جهاز التحكم هو تطبيق متآلف من مكون واحد. يجب تشغيل نسخة وحدة تحكم واحدة على الأقل في كل موفر. هناك بعض HA ، لكنني لم الخوض في ذلك.
• وكيل - وضعت على كل آلة افتراضية. هناك نوعان من العوامل - للجهاز وللوحدة. يبدو أن أحدهما يوضع على الجهاز المضيف ، والآخر في الجهاز الظاهري - لم أخوض فيه بالتفصيل أيضًا.
• العميل هو أداة CLI لإدارة كل هذا الاقتصاد.
• واجهة المستخدم الرسومية
• وصف تعريفي لجميع مكونات المستخدم (التطبيقات ، الآلات ، إلخ.)
• رمز مخصص لإعداد آلة افتراضية منفصلة ، ويسمى السحر

(في الواقع ، هناك شجرة أكبر من المكونات ، ولكن بالنسبة لهذه القصة ، سنقوم بتبسيطها حتى يكون من السهل فهم ما هو)

في الوصف التعريفي ، يمكنك إنشاء بنية المكونات التالية تقريبًا (يتم رسم الرسوم البيانية تلقائيًا بواسطة واجهة المستخدم الرسومية):

يقوم جزء الخادم بإنشاء أجهزة افتراضية هناك ، ويسحب التبعيات ، ويقيم العلاقات بينهما ، ويتتبع الإشارات التي تنشأ - يبدو أن كل شيء قياسي تمامًا ، مثل باقي الفرق الموسيقية.

وهنا الوحدات النمطية لتكوين الأجهزة الافتراضية تسمى السحر (وحدة - سحر) ، دعونا نلقي نظرة فاحصة.

يبدو أنني أعرف الشيف ، Ansible و Puppet ، ربما لا يوجد شيء جديد هنا ، لكن هذا ليس كذلك. لم ينشئ منشئو Juju DSL لوصف الموارد في النظام بشكل تعريفي. بدلاً من ذلك ، أنشأوا إطارًا من شأنه أن يسمح لشفرة الثعبان العادية أو الشفرة العادية بأن يكون غير سليم وربطه بوحدة تحكم Juju.

جهاز سحر

سحر أنفسهم ليست بسيطة جدا. بالتعقيد الهيكلي ، يذكّرون كتب الطهاة أو أدوار الباقي. وفي الواقع ، من المرجح أن يكونوا بمثابة تناظر للموارد ، بدلاً من كتب الطبخ.

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

يصف الجزء التعريفي واجهات تبعية السحر (على سبيل المثال ، يعتمد سحر وورد على mysql ، ويوفر سحر mysql هذه الواجهة) ، وتوافق النظام ، والعلامات ، ومعلمات التكوين (مثل سمات ملفات تعريف الارتباط) وطبقات البرنامج حسب السحر الآخر ( على سبيل المثال ، تتضمن معظم السحر layer:basic ).

في السنانير الحتمية ، يرد وصف لجميع أنواع الأحداث الخارجية. على سبيل المثال ، نقوم install الحزمة الضرورية على حدث install ، ونقوم configure على حدث configure ، start الخدمة في حدث start .

كُلّ هذا مكتوب على ثعبان منتظم مع أخصائيي الديكور (قرأت في مكان ما البيان الذي يمكنك أن تكتبه على أي شيء ، حتى على باش ، لكنني لم أر أي أمثلة).

والمثال الكلاسيكي خفيف الوزن هو NTP: https://github.com/lampkicking/charm-ntp

ومن المثير للاهتمام ، على ما يبدو ، عند تجميع السحر ، يتم الحصول على تطبيق قائم بذاته تمامًا ويمكن تشغيله على الخادم دون تبعية إضافية - في النسخة المترجمة ، رأيت أنه يتضمن محتويات جميع الطبقات المستخدمة من قبله ، بالإضافة إلى tarballs لجميع وحدات Python المستخدمة.

مثال على NTP: https://jaas.ai/ntp/32 (راجع قائمة الملفات على الجانب الأيمن من الصفحة).

ملخص

Juju لديه نهج مثير للاهتمام وغير عادي للغاية لوصف وإنشاء البنية التحتية.

على الأرجح ، لدى juju عتبة دخول أعلى من عتبة الطاهي ، على الأرجح أن أبطأ السحر في التطور مقارنة بكتب الطبخ وكتب اللعب ويتطلب المزيد من مهارات البرمجة.

من ناحية أخرى ، أفترض أن النموذج الذي يتضمن خطافات الأحداث يشجعك على كتابة رمز أكثر صحة.

يبدو لي أن Juju يستهدف أكثر مبرمجي البنية التحتية (أولئك الذين كتبوا العديد من أدوات CLI على python في Linux قبل 5-7 سنوات) ، والذين يحتاجون الآن إلى تكوين الخوادم ، بينما Chef / Ansible - على المسؤولين ، الذين بدلاً من واحد ، الآن أنت بحاجة إلى تكوين مائة أو اثنين من الخوادم.

هل يجب علي استخدام Juju في 2019؟
غير متأكد:

• سوف تقوم بلف التطبيقات الجديدة (السحابية الأصلية) في عامل الإرساء في عامل ميناء وتشغيله على cuber أو ECS
• بالنسبة للتطبيقات "القديمة" ، من المحتمل أن يكون لديك بالفعل برامج نصية للنشر مكتوبة على المجموعة أو الرئيس
• لمشاريع جديدة مع العمارة "القديمة" - ربما. لكن :
• لا أحد تقريبا يعرف عن Juju في RuNet ، هذا هو المقال الأول باللغة الروسية الذي يصف قليلا ما هو عليه

إذا كنت تعمل مع Juju ، فاكتب في التعليقات التي ارتكبت فيها خطأً - بعد كل شيء ، قرأت فقط الاحواض لها لمدة 2-3 ساعات.