🥇 مقدمة Helm 3

ملحوظة. ترجمة.: يعتبر يوم 16 مايو من هذا العام علامة فارقة في تطوير مدير الحزم لشركة Kubernetes - Helm. في هذا اليوم ، تم تقديم أول إصدار ألفا من الإصدار الرئيسي المستقبلي للمشروع ، 3.0. سيؤدي إطلاقه إلى إحداث تغييرات مهمة طال انتظارها على Helm ، والتي يعلق الكثير من مجتمع Kubernetes عليها آمالًا كبيرة. نحن أنفسنا من بين هؤلاء ، نظرًا لأننا نستخدم Helm بنشاط لنشر التطبيقات: لقد قمنا بدمجها في أداتنا لتنفيذ CI / CD werf ومن حالة إلى أخرى ، نقدم مساهمة مجدية في تطوير المنبع. تجمع هذه الترجمة بين 7 ملاحظات من مدونة Helm الرسمية مخصصة لإصدار ألفا الأول من Helm 3 وتحكي عن تاريخ المشروع والميزات الرئيسية لـ Helm 3. مؤلفها هو Matt "bacongobbler" Fisher ، موظف Microsoft و أحد المشرفين الرئيسيين على هيلم.

في 15 أكتوبر 2015 ، وُلد المشروع المعروف الآن باسم Helm. بعد عام واحد فقط من تأسيسها ، انضم مجتمع Helm إلى Kubernetes أثناء العمل بنشاط على Helm 2. في يونيو 2018 ، انضم إلى CNCF كمشروع احتضان. تقدم سريعًا إلى الحاضر وإصدار ألفا الأول من Helm 3 الجديد في الطريق. (هذا الإصدار قد حدث بالفعل في منتصف شهر مايو - تقريبًا. ترجمة.).

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

خلاصة القول:

تاريخ إنشاء هيلم ؛
وداع العطاء إلى تيلر ؛
مستودعات الرسم البياني
إدارة الإفراج؛
التغييرات في تبعيات الرسم البياني ؛
مخططات المكتبة ؛
ماذا بعد؟

تاريخ هيلم

الولادة

بدأ Helm 1 كمشروع مفتوح المصدر أنشأه Deis. كنا شركة ناشئة صغيرة يمتص مايكروسوفت في ربيع 2017. مشروعنا الآخر مفتوح المصدر ، المسمى أيضًا Deis ، كان لديه أداة deisctlالذي تم استخدامه (من بين أشياء أخرى) لتثبيت وتشغيل منصة Deis في كتلة الأسطول. في ذلك الوقت ، كانت Fleet واحدة من أولى منصات تنسيق الحاويات.

في منتصف عام 2015 ، قررنا تغيير المسار وترحيل Deis (ثم أعيدت تسميته Deis Workflow) من Fleet إلى Kubernetes. واحدة من أولها كانت أداة التثبيت المعاد تصميمها deisctl. استخدمناها لتثبيت وإدارة Deis Workflow على مجموعة الأسطول.

تم إنشاء Helm 1 في صورة وشبه مديري الحزم المعروفين مثل Homebrew و apt و yum. كان هدفه الرئيسي هو تبسيط المهام مثل حزم التطبيقات وتثبيتها في Kubernetes. تم تقديم Helm رسميًا في عام 2015 في مؤتمر KubeCon في سان فرانسيسكو.

نجحت محاولتنا الأولى مع هيلم ، لكنها لم تخلو من قيود جدية. أخذ مجموعة من مظاهر Kubernetes بنكهة المولدات مثل كتل YAML التمهيدية. (المادة الأمامية)* وتحميل النتائج إلى Kubernetes.

* ملحوظة. ترجمة.: من الإصدار الأول من Helm ، تم اختيار بناء جملة YAML لوصف موارد Kubernetes ، وتم دعم قوالب Jinja ونصوص Python عند كتابة التكوينات. لقد كتبنا المزيد عن هذا وعن جهاز الإصدار الأول من Helm بشكل عام في فصل "نبذة تاريخية عن Helm" هذه المادة.

على سبيل المثال ، لاستبدال حقل في ملف YAML ، يمكنك إضافة البنية التالية إلى البيان الخاص بك:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

إنه لأمر رائع أن المحركات القوالب موجودة اليوم ، أليس كذلك؟

لعدة أسباب ، تطلب مُثبِّت Kubernetes المبكر هذا قائمة مشفرة من ملفات البيان ولم ينفذ سوى تسلسل صغير وثابت من الأحداث. كان من الصعب جدًا استخدامه لدرجة أن فريق Deis Workflow R & D واجه صعوبة عندما حاولوا نقل منتجهم إلى هذه المنصة - ومع ذلك ، فقد تم بالفعل زرع بذور الفكرة. كانت محاولتنا الأولى فرصة تعليمية رائعة حيث أدركنا أننا متحمسون حقًا لبناء أدوات عملية تحل المشكلات اليومية لمستخدمينا.

بناءً على تجربة أخطاء الماضي ، بدأنا في تطوير Helm 2.

صنع خوذة 2

في نهاية عام 2015 ، اتصل فريق Google بنا. كانوا يعملون على أداة مماثلة لـ Kubernetes. كان Deployment Manager لـ Kubernetes منفذًا لأداة حالية مستخدمة في Google Cloud Platform. سألوا ، "هل نحن على استعداد لقضاء بضعة أيام في مناقشة أوجه التشابه والاختلاف؟"

في يناير 2016 ، التقى فريق Helm and Deployment Manager في سياتل لتبادل الأفكار. توجت المحادثات بخطة طموحة لدمج كلا المشروعين لإنشاء Helm 2. جنبًا إلى جنب مع Deis و Google ، الرجال من SkipBox (الآن جزء من Bitnami - ترجمة تقريبًا.)، وبدأنا العمل على Helm 2.

أردنا الحفاظ على سهولة استخدام Helm ، ولكن أضفنا ما يلي:

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

لتحقيق هذه الأهداف ، تمت إضافة عنصر ثانٍ إلى نظام هيلم البيئي. كان يسمى هذا المكون داخل الكتلة Tiller وكان مسؤولاً عن تثبيت وإدارة مخططات Helm.

منذ إصدار Helm 2 في عام 2016 ، شهدت Kubernetes العديد من الابتكارات الرئيسية. تم إدخال التحكم في الوصول المستند إلى الدور (RBAC) ، والذي حل في النهاية محل التحكم في الوصول المستند إلى السمات (ABAC). تم تقديم أنواع موارد جديدة (كانت عمليات النشر لا تزال في مرحلة تجريبية في ذلك الوقت). تم اختراع تعريفات الموارد المخصصة (كانت تسمى أصلاً موارد الطرف الثالث أو TPRs). والأهم من ذلك ، ظهرت مجموعة من أفضل الممارسات.

وسط كل هذه التغييرات ، استمرت Helm في خدمة مستخدمي Kubernetes بأمانة. بعد ثلاث سنوات والعديد من الإضافات الجديدة ، كان من الواضح أن الوقت قد حان لإجراء تغييرات كبيرة على قاعدة التعليمات البرمجية حتى يتمكن Helm من الاستمرار في تلبية الاحتياجات المتزايدة لنظام بيئي متطور.

وداع عطاء تيلر

أثناء تطوير Helm 2 ، قدمنا Tiller كجزء من تكاملنا مع Google Deployment Manager. لعب Tiller دورًا مهمًا للفرق التي تعمل ضمن مجموعة مشتركة: فقد سمح لمختلف المتخصصين الذين يشغلون البنية التحتية بالتفاعل مع نفس مجموعة الإصدارات.

نظرًا لأن التحكم في الوصول المستند إلى الدور (RBAC) تم تمكينه افتراضيًا في Kubernetes 1.6 ، أصبح العمل مع Tiller في الإنتاج أكثر صعوبة. نظرًا للعدد الهائل من سياسات الأمان الممكنة ، كان موقفنا هو تقديم تكوين مسموح به افتراضيًا. سمح هذا للمبتدئين بتجربة Helm و Kubernetes دون الحاجة إلى الغوص في إعدادات الأمان أولاً. لسوء الحظ ، يمكن أن يمنح هذا التكوين المسموح به المستخدم نطاقًا واسعًا جدًا من الأذونات التي لا يحتاجها. كان على مهندسي DevOps و SRE تعلم خطوات تشغيلية إضافية عند تثبيت Tiller في مجموعة متعددة المستأجرين.

من خلال تعلم كيفية استخدام المجتمع لـ Helm في مواقف محددة ، أدركنا أن نظام إدارة الإصدارات في Tiller لا يحتاج إلى الاعتماد على مكون داخل المجموعة للحفاظ على الحالات أو العمل كمحور مركزي لمعلومات الإصدار. بدلاً من ذلك ، يمكننا فقط الحصول على معلومات من خادم Kubernetes API ، وإنشاء مخطط على جانب العميل ، وحفظ سجل تثبيت Kubernetes.

يمكن أن يتم الهدف الرئيسي من Tiller بدون Tiller ، لذلك كان أحد قراراتنا الأولى بشأن Helm 3 هو التخلي تمامًا عن Tiller.

مع رحيل تيلر ، تم تبسيط نموذج أمان هيلم بشكل جذري. يدعم Helm 3 الآن جميع ميزات الأمان والتعريف والتفويض الحديثة لـ Kubernetes اليوم. يتم تعريف أذونات هيلم بـ ملف kubeconfig. يمكن لمسؤولي الكتلة تقييد حقوق المستخدم لأي مستوى من الدقة. لا تزال الإصدارات مخزنة داخل المجموعة ، ويتم الاحتفاظ ببقية وظائف Helm.

مستودعات الرسم البياني

على مستوى عالٍ ، مستودع الرسم البياني هو مكان يمكن فيه تخزين الرسوم البيانية ومشاركتها. يقوم عميل Helm بحزم ويدفع الرسوم البيانية إلى المستودع. ببساطة ، مستودع المخططات هو خادم HTTP بدائي به ملف index.yaml وبعض المخططات المعبأة.

في حين أن هناك بعض المزايا لـ Charts Repository API التي تلبي معظم متطلبات التخزين الأساسية ، إلا أن لها أيضًا بعض العيوب:

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

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

لكن هل تعلم أن مشروع التوزيع مصمم لتوزيع أي شكل من أشكال المحتوى وليس مجرد صور حاوية؟

بفضل الجهود مبادرة الحاويات المفتوحة (أو OCI) ، يمكن وضع مخططات Helm في أي مثيل توزيع. حتى الآن ، هذه العملية تجريبية. لا يزال العمل على دعم تسجيل الدخول والميزات الأخرى المطلوبة للحصول على Helm 3 الكامل مستمرًا ، ولكننا متحمسون للتعلم من الاكتشافات التي قام بها فريق OCI و Distribution على مر السنين. ومن خلال إرشادهم وتوجيههم ، نتعلم كيف يبدو تشغيل خدمة متوفرة للغاية على نطاق واسع.

يتوفر وصف أكثر تفصيلاً لبعض التغييرات القادمة في مستودعات Helm Chart. رابط.

إدارة الإفراج

في Helm 3 ، يتم تعقب حالة التطبيق داخل الكتلة بواسطة كائنين:

تحرير الكائن - يمثل مثيل التطبيق ؛
Release version secret - يمثل الحالة المطلوبة للتطبيق في وقت معين (على سبيل المثال ، إصدار نسخة جديدة).

دعوة helm install يقوم بإنشاء كائن تحرير وسرية إصدار الإصدار. يتصل helm upgrade يتطلب كائن تحرير (يمكن تعديله) وينشئ سرًا لإصدار إصدار جديد يحتوي على القيم الجديدة وبيان جاهز.

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

يرتبط سر إصدار الإصدار بسلسلة من المراجعات (التثبيت والتحديثات والتراجع والحذف).

في Helm 2 ، كانت المراجعات متسقة للغاية. يتصل helm install تم إنشاؤه v1 ، والتحديث اللاحق (الترقية) - v2 ، وما إلى ذلك. تم دمج سر الإصدار والإصدار في كيان واحد يعرف باسم المراجعة. تم الاحتفاظ بالتنقيحات في نفس مساحة الاسم مثل Tiller ، مما يعني أن كل إصدار "عالمي" من حيث مساحة الاسم ؛ نتيجة لذلك ، يمكن استخدام مثيل واحد فقط من الاسم.

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

بعد إهمال Tiller ، يقوم Helm 3 بتخزين البيانات في نفس مساحة الاسم مثل الإصدار. يسمح لك هذا التغيير بتثبيت مخطط يحمل نفس اسم الإصدار في مساحة اسم مختلفة ، ويتم حفظ البيانات بين تحديثات المجموعة / إعادة التشغيل في إلخ. على سبيل المثال ، يمكنك تثبيت WordPress في مساحة الاسم "foo" ثم في مساحة الاسم "bar" ، ويمكن تسمية كلا الإصدارين "wordpress".

يتغير تبعية الرسم البياني

الرسوم البيانية معبأة (باستخدام helm package) للاستخدام مع Helm 2 ، يمكن تثبيته مع Helm 3 ، ومع ذلك فقد تم تعديل سير عمل تطوير المخطط بالكامل لذا يلزم إجراء بعض التغييرات لمواصلة تطوير المخططات باستخدام Helm 3. على وجه الخصوص ، تغير نظام إدارة تبعية الرسم البياني.

تم نقل نظام إدارة التبعية في الرسم البياني من requirements.yaml и requirements.lock في Chart.yaml и Chart.lock. هذا يعني أن المخططات التي استخدمت الأمر helm dependency، تتطلب بعض التهيئة للعمل في Helm 3.

لنلقي نظرة على مثال. دعنا نضيف تبعية إلى المخطط في Helm 2 ونرى التغييرات عند الانتقال إلى Helm 3.

في حلم 2 requirements.yaml بدا مثل هذا:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

في Helm 3 ، ستنعكس نفس التبعية في ملف Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

لا يزال يتم تنزيل الرسوم البيانية ووضعها في الدليل charts/، لذا فإن المخططات الفرعية (مخططات فرعية)، الموجود في الدليل charts/ستواصل العمل دون تغيير.

تقديم مخططات المكتبة

يدعم Helm 3 فئة من المخططات تسمى مخططات المكتبة (مخطط المكتبة). يتم استخدام هذا المخطط من قبل المخططات الأخرى ، ولكنه لا يُنشئ أي عناصر تحريرية من تلقاء نفسه. يمكن لقوالب مخطط المكتبة الإعلان عن العناصر فقط define. يتم تجاهل المحتوى الآخر ببساطة. يتيح ذلك للمستخدمين إعادة استخدام ومشاركة مقتطفات من التعليمات البرمجية التي يمكن استخدامها في العديد من المخططات ، وبالتالي تجنب الازدواجية والالتزام بالمبدأ جاف.

يتم الإعلان عن مخططات المكتبة في القسم dependencies في ملف Chart.yaml. لا يختلف تثبيتها وإدارتها عن المخططات الأخرى.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

ما هي الخطوة التالية؟

Helm 3.0.0-alpha.1 هو الأساس الذي نبدأ على أساسه في إنشاء نسخة جديدة من Helm. لقد وصفت في المقال بعض الميزات المثيرة للاهتمام لبرنامج Helm 3. ولا يزال العديد منها في المراحل الأولى من التطور ، وهذا أمر طبيعي ؛ الهدف من إصدار ألفا هو اختبار الفكرة ، وجمع التعليقات من أوائل المتبنين ، والتحقق من صحة افتراضاتنا.

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

في هذه المقالة ، حاولت تسليط الضوء على بعض التحسينات الرئيسية القادمة إلى Helm 3 ، لكن هذه القائمة ليست شاملة بأي حال من الأحوال. تتضمن الخطة الكاملة لبرنامج Helm 3 ميزات جديدة مثل استراتيجيات التحديث المحسنة ، والتكامل الأعمق مع سجلات OCI ، واستخدام مخططات JSON للتحقق من صحة قيم المخطط. نخطط أيضًا لتنظيف قاعدة الشفرة وتحديث الأجزاء التي تم إهمالها على مدار السنوات الثلاث الماضية.

إذا شعرت أننا فقدنا شيئًا ما ، فنحن نحب أن نسمع أفكارك!

انضم إلى المناقشة في موقعنا قنوات سلاك:

#helm-users للأسئلة والتواصل البسيط مع المجتمع ؛
#helm-dev لمناقشة طلبات السحب والتعليمات البرمجية والأخطاء.

يمكنك أيضًا الدردشة على مكالماتنا الأسبوعية للمطورين العامين يوم الخميس الساعة 19:30 بتوقيت موسكو. الاجتماعات مخصصة لمناقشة المهام التي يعمل عليها المطورون الرئيسيون والمجتمع ، بالإضافة إلى موضوعات المناقشة لهذا الأسبوع. يمكن لأي شخص الانضمام والمشاركة في الاجتماع. الرابط متاح في قناة سلاك #helm-dev.

PS من المترجم

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

مقدمة إلى Helm 3