تقريبا. العابرة. : يمثل 16 مايو من هذا العام علامة فارقة في تطوير مدير الحزم لشركة Kubernetes - Helm. في هذا اليوم ، تم تقديم أول إصدار ألفا للنسخة الرئيسية المستقبلية من المشروع - 3.0. سيؤدي إطلاقها إلى إحداث تغييرات كبيرة طال انتظارها في هيلم ، والتي يراودها الكثيرون في مجتمع Kubernetes. نحن أنفسنا نتعامل مع هذه ، ونحن نستخدم Helm بنشاط لنشر التطبيقات: لقد قمنا بدمجها في أداتنا لتنفيذ CI / CD werf ومن وقت لآخر نقدم مساهمة مجدية في التطوير الأولي . تجمع هذه الترجمة 7 ملاحظات من مدونة Helm الرسمية ، والتي تم توقيتها لإصدار Helm 3 alpha الأول وتحكي عن تاريخ المشروع والسمات الرئيسية لـ Helm 3. مؤلفها هو Matt "bacongobbler" Fisher ، موظف في شركة Microsoft وأحد صانعي Helm الرئيسيين. 15 أكتوبر 2015 ، وُلد المشروع ، المعروف الآن باسم هيلم. بعد عام واحد فقط من تأسيسها ، انضم مجتمع Helm إلى Kubernetes ، بينما كان يعمل بنشاط على Helm 2. في يونيو 2018 ،
انضم Helm
إلى CNCF كمشروع احتضان. تقدم سريعًا إلى الوقت الحاضر - والآن أصبح الإصدار الأول من إصدار Helm 3 الجديد في الطريق
(هذا الإصدار تم بالفعل في منتصف مايو - ترجمة تقريبية) .
في هذا المقال ، سأتحدث عن كيفية بدء كل شيء ، وكيف وصلنا إلى المرحلة الحالية ، وأعرض بعض الميزات الفريدة المتوفرة في الإصدار الأول من إصدار Helm 3 ، وأشرح كيف نخطط لمزيد من التطوير.
خلاصة القول:
- تاريخ إنشاء هيلم.
- وداع لطيف لتيلر.
- مستودعات الرسم البياني ؛
- إدارة الإصدار ؛
- التغييرات في تبعيات المخطط ؛
- مخططات المكتبة
- ماذا بعد؟
تاريخ هيلم
الولادة
بدأ Helm 1 كمشروع مفتوح المصدر أنشأه Deis. لقد كنا شركة صغيرة
تمتصها شركة Microsoft في ربيع عام 2017. مشروعنا مفتوح المصدر الآخر ، المسمى أيضًا
deisctl ، لديه أداة
deisctl تم استخدامها (من بين أشياء أخرى) لتثبيت وتشغيل منصة Deis في
مجموعة Fleet . كان الأسطول من أوائل المنصات الخاصة بتنسيق الحاويات في ذلك الوقت.
في منتصف عام 2015 ، قررنا تغيير المسار ونقلنا Deis (في ذلك الوقت أعيدت تسميته إلى Deis Workflow) من Fleet إلى Kubernetes. واحدة من أول من إعادة تصميم
deisctl التثبيت
deisctl . استخدمناها لتثبيت Deis Workflow وإدارتها في مجموعة أسطول.
تم إنشاء Helm 1 في صورة مديري الحزم المعروفين مثل Homebrew و apt و yum. كانت مهمتها الرئيسية هي تبسيط المهام مثل تغليف وتثبيت التطبيقات في Kubernetes. تم تقديم Helm رسميًا في عام 2015 في مؤتمر KubeCon في سان فرانسيسكو.
نجحت محاولتنا الأولى مع هيلم ، ولكن كانت هناك قيود خطيرة. تولى مجموعة من عروض Kubernetes ، بنكهة المولدات ككتل YAML في المقدمة ، وحمل النتائج على Kubernetes.
* ملاحظة العابرة. : من الإصدار الأول من Helm ، تم اختيار بناء جملة YAML لوصف موارد Kubernetes ، وتم دعم قوالب Jinja والبرامج النصية Python عند كتابة التكوينات. لقد كتبنا المزيد عن هذا وجهاز الإصدار الأول من هيلم في الفصل "تاريخ موجز عن هيلم" من هذه المادة .على سبيل المثال ، لاستبدال حقل في ملف YAML ، كان عليك إضافة البنية التالية إلى البيان:
#helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml
من الرائع وجود محركات نماذج اليوم ، أليس كذلك؟
لأسباب عديدة ، تطلب مثبت Kubernetes المبكر هذا قائمة مشفرة من ملفات البيان وأداء سلسلة صغيرة ثابتة فقط من الأحداث. كان من الصعب جدًا استخدام فريق البحث والتطوير Deis Workflow في وقت عصيب عندما حاولوا نقل منتجاتهم إلى هذه المنصة - ومع ذلك ، فقد تم بالفعل زرع بذور الفكرة. كانت محاولتنا الأولى فرصة رائعة للتعلم: لقد أدركنا أننا متحمسون حقًا لإنشاء أدوات عملية تحل المشكلات اليومية لمستخدمينا.
بناءً على تجربة أخطاء الماضي ، بدأنا في تطوير Helm 2.
إنشاء هيلم 2
في نهاية عام 2015 ، اتصل بنا فريق Google. لقد عملوا على أداة مماثلة ل Kubernetes. كان مدير النشر لـ Kubernetes هو منفذ الأداة الحالية التي تم استخدامها لنظام Google Cloud Platform. سألوا: "هل سنقضي بضعة أيام لمناقشة أوجه التشابه والاختلاف؟"
في يناير 2016 ، التقى فريق هيلم ومدير النشر في سياتل لتبادل الأفكار. انتهت المفاوضات بخطة طموحة: الجمع بين كلا المشروعين لإنشاء Helm 2. بالاشتراك مع Deis و Google ،
انضم شباب
SkippBox (أصبح الآن جزءًا من Bitnami - approx. Transl.) إلى فريق التطوير ، وبدأنا العمل على Helm 2.
أردنا الحفاظ على سهولة استخدام Helm ، ولكن أضف ما يلي:
- قوالب الرسم البياني للتخصيص.
- إدارة intracluster للفرق.
- مستودع الرسم البياني من الدرجة الأولى
- شكل حزمة مستقرة مع القدرة على التوقيع ؛
- التزام قوي بالإصدار الدلالي والحفاظ على التوافق العكسي بين الإصدارات.
لتحقيق هذه الأهداف ، تم إضافة عنصر ثانٍ إلى نظام هيلم البيئي. كان يسمى هذا المكون intracluster Tiller وشارك في تثبيت مخططات Helm وإدارتها.
منذ إصدار Helm 2 في عام 2016 ، اكتسبت Kubernetes عددًا من الابتكارات الرئيسية. تم
تقديم التحكم في الوصول المستند إلى
الدور (
RBAC ) ، والذي حل في النهاية محل التحكم في الوصول المستند إلى السمة (ABAC). تم تقديم أنواع جديدة من الموارد (لا تزال عمليات النشر في ذلك الوقت في حالة تجريبية). اخترعت تعريفات الموارد المخصصة (تسمى أصلاً موارد الطرف الثالث أو TPRs). والأهم من ذلك ، ظهرت مجموعة من أفضل الممارسات.
وسط كل هذه التغييرات ، واصل Helm الخدمة بأمانة لمستخدمي Kubernetes. بعد ثلاث سنوات والعديد من الإضافات الجديدة ، أصبح من الواضح أن الوقت قد حان لإجراء تغييرات كبيرة على قاعدة الشفرة حتى يتمكن هيلم من الاستمرار في تلبية الاحتياجات المتزايدة لنظام بيئي نام.
وداع لطيف لتيلر
أثناء تطوير Helm 2 ، قدمنا Tiller كجزء من تكاملنا مع مدير نشر Google. لعب تيلر دورًا مهمًا للفرق العاملة ضمن مجموعة مشتركة: فقد سمح للعديد من المتخصصين الذين يديرون البنية التحتية بالتفاعل مع نفس مجموعة الإصدارات.
منذ أن تم تمكين التحكم في الوصول المستند إلى الأدوار (RBAC) افتراضيًا في Kubernetes 1.6 ، أصبح العمل مع Tiller في الإنتاج أكثر صعوبة. نظرًا للعدد الهائل لسياسات الأمان المحتملة ، كان موقفنا هو اقتراح الأذونات افتراضيًا. سمح هذا للمبتدئين بتجربة Helm و Kubernetes دون الحاجة إلى الغوص في إعدادات الأمان أولاً. لسوء الحظ ، قد يوفر هذا التكوين المتساهل للمستخدم نطاقًا واسعًا للغاية من الأذونات التي لم يكن بحاجة إليها. كان على مهندسي DevOps و SRE تعلم خطوات تشغيلية إضافية من خلال تثبيت Tiller في مجموعة متعددة المستأجرين.
بعد معرفة كيفية استخدام أعضاء المجتمع لـ Helm في مواقف معينة ، أدركنا أن نظام إدارة إصدارات Tiller لا يحتاج إلى الاعتماد على مكون داخل المجموعة للحفاظ على الحالة أو العمل كمحور مركزي به معلومات الإصدار. بدلاً من ذلك ، يمكننا فقط الحصول على معلومات من خادم Kubernetes API ، وإنشاء مخطط من جانب العميل ، وحفظ سجل التثبيت في Kubernetes.
يمكن تنفيذ المهمة الرئيسية لـ Tiller بدون Tiller ، لذلك كان أحد قراراتنا الأولى بخصوص Helm 3 هو الرفض الكامل لـ Tiller.
مع رحيل تيلر ، تم تبسيط نموذج هيلم الأمني بشكل جذري. يدعم Helm 3 الآن جميع أساليب الأمان الحديثة وتحديد الهوية والترخيص لنقاط Kubernetes الحالية. يتم تحديد أذونات Helm باستخدام
ملف kubeconfig . يمكن لمسؤولي الكتلة تقييد حقوق المستخدم بأي مستوى من الدقة. لا تزال الإصدارات مخزنة داخل الكتلة ، ويتم الحفاظ على بقية وظائف هيلم.
مستودعات الرسم البياني
على مستوى عالٍ ، يعد مستودع التخطيطات مكانًا يمكنك من خلاله تخزين المخططات ومشاركتها. يحزم عميل Helm ويرسل المخططات إلى المستودع. ببساطة ، مستودع التخطيط هو خادم HTTP بدائي به ملف index.yaml وبعض المخططات المعبأة.
على الرغم من أن هناك بعض المزايا في أن واجهة برمجة تطبيقات مستودع الرسم البياني تفي بالمتطلبات الأساسية لمستودع التخزين ، إلا أن لها العديد من العيوب:
- مستودعات التخطيطات غير متوافقة مع معظم تطبيقات الأمان المطلوبة في بيئة الإنتاج. يعد وجود API قياسي للمصادقة والترخيص أمرًا بالغ الأهمية في سيناريوهات الإنتاج.
- أدوات Helm لتتبع أصل المخطط ، والتي تستخدم للتوقيع والتحقق من سلامة وأصل المخطط ، هي جزء اختياري من عملية نشر المخطط.
- في سيناريوهات متعدد المستخدمين ، يمكن تحميل نفس المخطط بواسطة مستخدم آخر ، مما يضاعف مقدار المساحة المطلوبة لتخزين نفس المحتوى. تم تطوير مستودعات أكثر ذكاءً لحل هذه المشكلة ، لكنها ليست جزءًا من المواصفات الرسمية.
- يؤدي استخدام ملف فهرس واحد للبحث عن البيانات الأولية وتخزينها والحصول على المخططات إلى تعقيد عملية تطوير تطبيقات آمنة متعددة المستخدمين.
يعد مشروع
Docker Distribution (المعروف أيضًا باسم Docker Registry v2) هو خليفة Docker Registry ويعمل في الواقع كمجموعة من الأدوات لتعبئة صور Docker وإرسالها وتخزينها وتسليمها. تقدم العديد من الخدمات السحابية الكبيرة منتجات قائمة على التوزيع. بفضل هذا الاهتمام المتزايد ، استفاد مشروع التوزيع من سنوات عديدة من التحسينات وأفضل الممارسات في مجال الأمن والاختبار في ظروف "القتال" ، والتي حولته إلى واحد من أنجح الأبطال المجهولين في عالم المصدر المفتوح.
ولكن هل تعلم أن مشروع التوزيع مصمم لتوزيع أي شكل من أشكال المحتوى ، وليس فقط الصور الحاوية؟
بفضل جهود
مبادرة Open Container (أو OCI) ، يمكن وضع مخططات Helm على أي حالة من عمليات التوزيع. حتى الآن ، هذه العملية تجريبية. إن العمل على دعم عمليات تسجيل الدخول والوظائف الأخرى الضرورية لقاعدة هيلم 3 الكاملة لم ينته بعد ، لكننا سعداء للغاية بالتعلم من الاكتشافات التي حققتها فرق OCI و Distribution على مدار السنوات. وبفضل التوجيه والقيادة ، نتعرف على كيفية تشغيل خدمة يمكن الوصول إليها بشكل كبير على نطاق واسع.
يتوفر هنا وصف أكثر تفصيلًا لبعض التغييرات القادمة على مستودعات Helm-charts.
إدارة الإصدار
في Helm 3 ، تتم مراقبة حالة التطبيق داخل كتلة من خلال كائنين:
- كائن تحرير - يمثل مثيل التطبيق ؛
- سر إصدار الإصدار - يمثل الحالة المطلوبة للتطبيق في وقت معين (على سبيل المثال ، إصدار إصدار جديد).
استدعاء
helm install ينشئ كائن إصدار وسرية إصدار الإصدار. يتطلب استدعاء
helm upgrade كائن إصدار (يمكنه تغييره) ويقوم بإنشاء سر إصدار إصدار جديد يحتوي على قيم جديدة وبيان مُعد.
يحتوي كائن الإصدار على معلومات الإصدار ، حيث يكون الإصدار تثبيتًا محددًا لمخطط وقيم مسماة. يصف هذا الكائن بيانات التعريف ذات المستوى الأعلى حول الإصدار. يتم الحفاظ على كائن الإصدار طوال دورة حياة التطبيق بالكامل وهو مالك جميع أسرار إصدار الإصدار ، وكذلك جميع الكائنات التي تم إنشاؤها مباشرة بواسطة مخطط Helm.
سر إصدار الإصدار يربط الإصدار مع سلسلة من المراجعات (التثبيت ، التحديثات ، الاستعادة ، إلغاء التثبيت).
في Helm 2 ، كانت المراجعات متسقة للغاية. تم إنشاء مكالمة
helm install v1 وترقية الترقية اللاحقة v2 وما إلى ذلك. تم طي نسخة الإصدار وسر الإصدار في كائن واحد ، والمعروف باسم المراجعة. تم تخزين Revision's في نفس مساحة اسم Tiller ، مما يعني أن كل إصدار كان "عالميًا" من حيث مساحة الاسم ؛ نتيجة لذلك ، يمكن استخدام مثيل واحد فقط من الاسم.
في Helm 3 ، يرتبط كل إصدار بأسرار إصدار واحد أو أكثر. يصف كائن الإصدار دائمًا الإصدار الحالي المنشور في Kubernetes. يصف كل إصدار سر إصدار واحد فقط من هذا الإصدار. على سبيل المثال ، ستنشئ الترقية سرًا لإصدار إصدار جديد ، ثم تقوم بتعديل كائن الإصدار للإشارة إلى هذا الإصدار الجديد. في حالة الاستعادة ، يمكنك استخدام أسرار إصدار الإصدار السابق لاستعادة الإصدار إلى حالته السابقة.
بعد التخلي عن Tiller ، يخزّن Helm 3 بيانات الإصدار في مساحة اسم واحدة مع الإصدار. يسمح لك هذا التغيير بتثبيت مخطط بنفس اسم الإصدار في مساحة اسم مختلفة ، ويتم حفظ البيانات بين تحديثات / إعادة تمهيد نظام المجموعة في etcd. على سبيل المثال ، يمكنك تثبيت Wordpress في مساحة الاسم "foo" ثم في مساحة الاسم "bar" ، ويمكن أن يطلق على كلا الإصدارين "Wordpress".
تغييرات تبعية المخطط
يمكن تثبيت المخططات التي تم تعبئتها (باستخدام
helm package ) للاستخدام مع Helm 2 مع Helm 3 ، ولكن تمت مراجعة سير عمل تطوير المخطط بشكل كامل ، لذلك يلزم إجراء بعض التغييرات لمواصلة تطوير المخططات باستخدام Helm 3. على وجه الخصوص ، تم تغيير نظام الإدارة الرسم البياني التبعيات.
انتقل نظام إدارة تبعية المخطط من
requirements.yaml .
Chart.lock و
requirements.lock إلى
Chart.yaml و
Chart.lock . هذا يعني أن المخططات التي تستخدم أمر
helm dependency تتطلب بعض التكوين للعمل في Helm 3.
لنلقِ نظرة على مثال. أضف تبعية إلى المخطط في Helm 2 وشاهد التغييرات التي تحدث عند التبديل إلى Helm 3.
في
requirements.yaml Helm 2 ، بدا yaml هكذا:
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
في Helm 3 ، ستنعكس نفس التبعية في
Chart.yaml :
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
لا يزال يتم تحميل
charts/ ووضعها في المخطط
charts/ الدليل ، وبالتالي فإن
charts/ الفرعية في المخطط
charts/ الدليل سوف تستمر في العمل دون تغييرات.
تقديم مخططات المكتبة
يدعم Helm 3 فئة تخطيط تسمى
مخطط المكتبة . يتم استخدام هذا المخطط من قبل المخططات الأخرى ، لكنه لا ينشئ أي قطع أثرية خاصة به. يمكن أن تعلن قوالب مخطط المكتبة عن
define العناصر فقط. يتم تجاهل المحتوى الآخر ببساطة. يتيح ذلك للمستخدمين إعادة استخدام أجزاء التعليمات البرمجية التي يمكن استخدامها في العديد من المخططات ومشاركتها ، وبالتالي تجنب التكرار والالتزام بمبدأ
DRY .
يتم الإعلان عن مخططات المكتبة في قسم
dependencies في ملف
Chart.yaml . لا يختلف تركيبها وإدارتها عن المخططات الأخرى.
dependencies: - name: mylib version: 1.xx repository: quay.io
نحن نتطلع إلى حالات الاستخدام التي سيفتحها هذا المكون لمطوري المخططات ، وكذلك أفضل الممارسات التي قد تنشأ من مخططات المكتبة.
ما التالي؟
Helm 3.0.0-alpha.1 - الأساس الذي بدأنا في إنشاء نسخة جديدة من Helm. في المقالة وصفت بعض الميزات المثيرة للاهتمام من هيلم 3. كثير منهم لا يزالون في المراحل الأولى من التنمية وهذا أمر طبيعي. إن جوهر إصدار alpha هو اختبار الفكرة ، وجمع الملاحظات من المستخدمين الأوائل ، وتأكيد افتراضاتنا.
بمجرد إصدار إصدار alpha
(تذكر أن هذا قد حدث بالفعل - الترجمة تقريبًا) ، سنبدأ في تلقي تصحيحات لـ Helm 3 من المجتمع. من الضروري إنشاء أساس متين يتيح لك تطوير وظائف جديدة واعتمادها ، وسيتمكن المستخدمون من المشاركة في العملية وفتح التذاكر وإجراء التصحيحات.
حاولت في المقالة أن أبرز بعض التحسينات الجدية التي ستظهر في Helm 3 ، لكن هذه القائمة ليست شاملة بأي حال من الأحوال. تتضمن الخطة الشاملة لـ Helm 3 ابتكارات مثل استراتيجيات التحديث المحسنة والتكامل الأعمق مع سجلات OCI واستخدام مخططات JSON للتحقق من قيم المخططات. نخطط أيضًا لمسح قاعدة الشفرة وتحديث الأجزاء التي تم إهمالها خلال السنوات الثلاث الماضية.
إذا شعرت أننا قد فاتنا شيء ما ، فسوف نكون سعداء لسماع أفكارك!
انضم إلى المناقشة في
قنوات Slack لدينا:
#helm-users للأسئلة والتواصل السهل مع المجتمع ؛#helm-dev لمناقشة طلبات السحب والرمز والأخطاء.
يمكنك أيضًا الدردشة في مكالمات مطوّري البرامج العامة الأسبوعية في أيام الخميس الساعة 19:30 بتوقيت مسقط. تكرس الاجتماعات لمناقشة المهام التي يعمل عليها المطورون الرئيسيون والمجتمع ، بالإضافة إلى مناقشة مواضيع الأسبوع. يمكن لأي شخص الانضمام والمشاركة في الاجتماع. الرابط متاح في قناة
#helm-dev Slack.
PS من المترجم
اقرأ أيضًا في مدونتنا: