حزم ومديري الحزم ل k8s

نستخدم جميعًا نوعًا من مديري الحزم ، بما في ذلك سيدة التنظيف Aunt Galya ، التي لديها جهاز iPhone في جيبها تم تحديثه الآن. ولكن لا يوجد اتفاق عام على وظائف مديري الحزم ، وأنظمة تشغيل rpm و dpkg القياسية وأنظمة الإنشاء تسمى مديري الحزم. نحن نقدم للتأمل في موضوع وظائفهم - ما هو ولماذا هناك حاجة إليها في العالم الحديث. وبعد ذلك سنحفر نحو Kubernetes وننظر بعناية في هيلم من حيث هذه الوظائف.


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

ساعدنا إيفان غلوشكوف ( gli ) في ذلك بتقريره عن RIT ++ ، وهو مقطع فيديو ونص من هذا العرض التقديمي المفصّل أدناه.

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

نبذة عن المتحدث: قام إيفان غلوشكوف بتطوير برمجيات لمدة 15 عامًا. تمكنت من العمل في MZ ، في Echo على منصة للتعليق ، والمشاركة في تطوير المجمعين لمعالج Elbrus في MCST. ويشارك حاليًا في مشاريع البنية التحتية في Postmates. يعد Ivan أحد أشهر البرامج الصوتية DevZen التي يتحدثون فيها عن مؤتمراتنا : هنا حول RIT ++ ، وهنا عن HighLoad ++.

مديري الحزمة

على الرغم من أن الجميع يستخدمون نوعًا من مديري الحزم ، إلا أنه لا يوجد اتفاق واحد على ما هو عليه. هناك فهم مشترك ، ولكل منها قناعاتها.

دعونا نتذكر أنواع مديري الحزم التي تتبادر إلى الذهن أولاً:

• مديرو الحزمة القياسية لجميع أنظمة التشغيل: rpm ، dpkg ، portage ، ...
• مديري الحزم للغات البرمجة المختلفة: الشحن ، الكابال ، حديد التسليح 3 ، المزيج ، ...

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


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

التنمية

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

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

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

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

عامل الميناء

هل تعتقد أن Docker هو مدير الحزم أم لا؟

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

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

ما هو ثمن كل الفوائد؟ أولئك الذين يعملون مع Docker يهتمون قليلاً بالتطبيقات الصناعية. لدي تجربة من هذا القبيل ، والسعر مرتفع للغاية في الواقع:

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

على سبيل المثال ، كان لدي مهمة لنقل برنامج واحد لاستخدام Docker. تم تطوير البرنامج على مر السنين من قبل فريق. لقد جئت ، ونحن نفعل كل ما هو مكتوب في الكتب: نحن نرسم قصص المستخدمين ، والأدوار ، ونرى ماذا وكيف ، روتينهم العادي.

أنا أقول:

- عامل الميناء يمكن أن تحل جميع مشاكلك. شاهد كيف يتم ذلك.

- كل شيء سيكون على زر - عظيم! لكننا نريد SSH القيام به داخل حاويات Kubernetes.

- انتظر ، لا SSH في أي مكان.

- نعم ، نعم ، كل شيء على ما يرام ... ولكن هل SSH ممكن؟

من أجل تحويل تصور المستخدمين إلى اتجاه جديد ، يتطلب الأمر الكثير من الوقت ، ويستغرق العمل التعليمي والكثير من الجهد.

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

Kubernetes

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

ومن المثير للاهتمام ، أن جميع العقد Kubernetes تعمل في Kubernetes نفسها من خلال الحاويات ، وجميع التطبيقات الخارجية تعمل من خلال الحاويات - كل شيء يعمل من خلال الحاويات ! هذا هو زائد وناقص.

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

كيفية تثبيت التطبيق؟

تثبيت صورة Docker في التسجيل Docker.

وراء هذه العبارة تكمن في الهاوية. تتخيل - لديك تطبيق مكتوب ، على سبيل المثال ، في روبي ، ويجب عليك وضع صورة Docker في سجل Docker. هذا يعني أنه يجب عليك:

• تحضير صورة عامل الميناء
• فهم كيف يتم ذلك ، على الإصدارات التي يستند إليها ؛
• تكون قادرة على اختباره.
• جمع ، ملء سجل Docker ، الذي ، بالمناسبة ، مثبتة من قبل.

في الحقيقة ، هذا ألم كبير وكبير في سطر واحد.

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

• وصف نشر + جراب ، خدمة + دخول (ربما) ؛
• قم بتشغيل تطبيق kubectl -f resources.yaml ، ونقل جميع الموارد إلى هذا الأمر.

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

هيلم

وأخيرا وصلنا إلى هيلم. هيلم هو أداة متعددة الأغراض. الآن سوف نفكر في ماهية مجالات تطوير حلم والعمل معها.

محرك القالب

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

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

كل هذا التنوع يؤدي إلى حقيقة أنه يتعين عليك أن تأخذ بيانك الخاص بك لـ Kubernetes ، وانسخه في كل مكان وإصلاحه في كل مكان: استبدل هنا رقمًا واحدًا ، إليك شيء آخر. هذا أصبح غير مريح للغاية.

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

على سبيل المثال ، بيان ل Helm.

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

أبسط أمر بدء تشغيل لتثبيت المخطط هو helm install ./wordpress (folder). لإعادة تعريف بعض المعلمات ، نقول: "أريد إعادة تعريف هذه المعلمات بدقة وتحديد هذه القيم وهذه".

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


صحيح ، سلبيات تظهر:

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

قبل الانغماس في اتجاه Helm - مدير الحزم ، الذي أخبرك له بكل هذا ، دعونا نرى كيف يعمل Helm مع التبعيات.

العمل مع التبعيات

هيلم من الصعب العمل مع التبعيات. أولاً ، هناك ملف requirements.yaml يناسب ما نعتمد عليه. أثناء العمل مع المتطلبات ، يقوم بالمتطلبات. lock - هذه هي الحالة الحالية (الكتلة) لجميع التبعيات. بعد ذلك ، يقوم بتنزيلها إلى مجلد يسمى / المخططات.

هناك أدوات لإدارة: من ، وكيف ، مكان الاتصال - العلامات والشروط ، والتي يتم تحديدها في أي بيئة ، بناءً على المعلمات الخارجية ، للاتصال أو عدم الاتصال ببعض التبعيات.

دعنا نقول أن لديك PostgreSQL لبيئة التدريج (أو RDS للإنتاج ، أو NoSQL للاختبارات). عن طريق تثبيت هذه الحزمة في الإنتاج ، لن تقوم بتثبيت PostgreSQL ، لأنها ليست هناك حاجة - فقط باستخدام العلامات والشروط.

ما هو مثير للاهتمام هنا؟

• هيلم يمزج جميع الموارد من جميع التبعيات والتطبيقات ؛
• نوع -> تثبيت / تحديث

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

مدير الحزمة

يقوم Helm بتثبيت التطبيقات والتبعيات ، ويمكنك إخبار Helm بتثبيت - وسوف يقوم بتثبيت الحزمة. لذلك هذا هو مدير الحزمة.

في الوقت نفسه ، إذا كان لديك مستودع خارجي حيث يمكنك تحميل الحزمة ، فيمكنك الوصول إليها ليس كمجلد محلي ، ولكن قل ببساطة: "من هذا المستودع ، خذ هذه الحزمة ، وقم بتثبيتها بمثل هذه المعلمات".

هناك مستودعات مفتوحة مع الكثير من الحزم. على سبيل المثال ، يمكنك تشغيل: helm install -f prod / values.yaml stable / Wordpress

من المستودع الثابت ، سوف تأخذ وورد وتثبيته لنفسك. يمكنك أن تفعل كل شيء: البحث / الترقية / حذف. لقد تبين أن هيلم هو مدير الحزم.

ولكن هناك سلبيات: جميع التبعيات متعدية يجب أن تدرج في الداخل. هذه مشكلة كبيرة عندما تكون التبعيات متعدية تطبيقات مستقلة وتريد العمل معها بشكل منفصل للاختبار والتطوير.

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



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

التجميع والتغليف

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

Helm لا يسمح لك بتشغيل التطبيق دون صورة Docker. في الوقت نفسه ، لم يتم تكوين Helm للتجميع والتعبئة ، وهذا في الواقع ، لا يعرف كيفية التعامل مع صور Docker.

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

لذلك ، نقول أن هيلم لا يعرف كيفية العمل مع الصور.

التنمية

الصداع القادم هو التنمية. في التطوير ، نريد تغيير رمزنا بسرعة وسهولة. لقد مر الوقت عندما قمت بثقوب الثقوب على بطاقات التثقيب ، وتم الحصول على النتيجة بعد 5 أيام. الجميع معتاد على استبدال حرف واحد بحرف آخر في المحرر والضغط على الترجمة ويعمل البرنامج المعدل بالفعل.

اتضح هنا أنه عند تغيير الكود ، هناك حاجة إلى الكثير من الإجراءات الإضافية: تحضير ملف Docker ؛ تشغيل Docker بحيث يبني الصورة ؛ لدفعها في مكان ما ؛ نشر إلى كتلة Kubernetes. وعندها فقط سوف تحصل على ما تريد في الإنتاج ، ويمكنك التحقق من الكود.

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

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

عامل الميناء يتيح لك العمل مع الطبقات ، أي للتحقق مما إذا كانت هناك طبقة أو أخرى وترسل الطبقة المفقودة. لكن العالم في أغلب الأحيان سيكون طبقة واحدة كبيرة. في حين أن 2 غيغابايت ستذهب إلى الخادم ، بينما ستذهب إلى Kubernetes مع Docker-registry ، سيتم طرحها بجميع الطرق ، حتى تبدأ أخيرًا - يمكنك شرب الشاي بأمان.

Helm لا يقدم أي مساعدة مع صور Docker الكبيرة. أعتقد أن هذا لا ينبغي أن يكون ، لكن مطوري هيلم يعرفون أفضل من جميع المستخدمين ، ويبتسم ستيف جوبز.



تحولت كتلة مع التنمية أيضا الأحمر.

أتمتة البيئة

الاتجاه الأخير - أتمتة البيئة - هو مجال مثير للاهتمام. قبل عالم Docker (و Kubernetes ، كنموذج مرتبط) ، لم تكن هناك طريقة للقول: "أريد تثبيت تطبيقي على هذا الخادم أو على هذه الخوادم بحيث توجد n نسخ متماثلة و 50 تبعيات ويعمل كل ذلك تلقائيًا!" هكذا ، يمكن للمرء أن يقول ، ما كان ، ولكن لم يكن!

يوفر Kubernetes هذا ومن المنطقي استخدامه بطريقة ما ، على سبيل المثال ، ليقول: "أنا نشر بيئة جديدة هنا وأريد من جميع فرق التطوير التي أعدت تطبيقاتها أن تكون قادرة فقط على النقر على زر وسيتم تثبيت جميع هذه التطبيقات تلقائيًا على البيئة الجديدة" . من الناحية النظرية ، يجب أن يساعد Helm في ذلك ، بحيث يمكن أخذ التكوين من مصدر بيانات خارجي - S3 ، GitHub - من أي مكان.

من المستحسن أن يكون هناك زر خاص في Helm "هل لي جيد بالفعل أخيرًا!" - وسوف تصبح على الفور جيدة. Kubernetes يسمح لك بذلك.

هذا مناسب بشكل خاص لأنه يمكن تشغيل Kubernetes في أي مكان ، ويعمل من خلال واجهة برمجة التطبيقات. من خلال إطلاق minikube محليًا ، إما في AWS أو في Google Cloud Engine ، يمكنك الحصول على Kubernetes من الصندوق مباشرة والعمل بنفس الطريقة في كل مكان: اضغط على زر وكل شيء على ما يرام في الحال.

يبدو أن هيلم بشكل طبيعي يسمح لك بذلك. لأنه خلاف ذلك ، ما هي الفائدة من إنشاء هيلم بشكل عام؟

لكن اتضح ، لا!


لا يوجد أتمتة للبيئة.

البدائل

عندما يكون هناك تطبيق من Kubernetes يستخدمه الجميع (هو الآن في الحقيقة الحل رقم 1) ، ولكن Helm لديه المشكلات التي تمت مناقشتها أعلاه ، لم يستطع المجتمع المساعدة ولكن الاستجابة. بدأت في إنشاء أدوات وحلول بديلة.

محركات القالب

يبدو ، كمحرك للقالب ، حل حلم جميع المشاكل ، ولكن لا يزال المجتمع يخلق بدائل. اسمح لي أن أذكرك بمشاكل محرك القالب: الإعادة وإعادة استخدام الشفرة.

ممثل جيد هنا هو Ksonnet. يستخدم نموذجًا مختلفًا تمامًا للبيانات والمفاهيم ، ولا يعمل مع موارد Kubernetes ، ولكن مع تعريفاته الخاصة:
النموذج الأولي (params) -> المكون -> التطبيق -> البيئات.


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

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

من الناحية النظرية ، هذا مريح. .

, — , , . Ksonnet . Ksonnet Helm , , .. , , , .


, , , , . . , , , 0.1. , .


, — KubePack , .

التنمية

:

1. Helm;
   
2. Helm;
   
3. , ;
   
4. , .
   

1. Helm

— Draft . — , , . Draft — Heroku-style:

• (pack);
• , , Python «Hello, world!»;
• , Docker- ( );
• , , docker-registry, ;
• .

, , .

Helm, Draft Helm-, production ready, , Draft Helm-, . .

, Draft , Helm-. Draft — .

2. Helm

Helm Charts Kubernetes-, Helm Charts. :

• GitKube;
• Skaffold;
• Forge.

Helm, . , , command line interface, Chart , git push .

, docker build, docker push kubectl rollout. , Helm, . .

3.

— . — Metaparticle . , Python, Python , .

, , , sysconfig .. .

, , , - Kubernetes-.

: , ; , ; ..


, , , - , Python- Kubernetes-. ?

- , . . , , preinstall , - . Kubernetes-, Metaparticle, .

, , Kubernetes- . , , Metaparticle.



Metaparticle, Helm . , .

Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .

Kubernetes , Docker, registry, Kubernetes. . , .

, , , Development . : , , , , — , , , Helm, , .

, .

4. Kubernetes Kubernetes

, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .

Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .

minikube , Docker-compose, . , , Docker-compose — 10 . , .


Docker-compose, , .

, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .

CI/CD, , docker', set-, , — .

CI/CD — , .

ملخص

5 Helm . , . , , . , , , .

Helm

, , Helm . , Helm , . , , , Helm.

, Road Map. Kuberneres Helm community , , Helm V3 .

Tiller, cli

, . Helm :

1. , (cmd ..).
   
2. Tiller — , Kubernetes.
   

Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .

Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .

V3 Tiller .


? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .

Tiller . , Kubernetes Command Line Interface : , , , pre- post-. .

Lua- Chart

, — , lua- . Chart lua-, . . , . , , , .


Lua , , , - , , .

, , . , . Kubernetes, - , , , , . دعونا نرى ما يحدث.

Release- + secret

, , Release- , Release . , Release-, , , CRD, , .

namespace

Release- namespace, , - Tiller' namespace — , .

CRD: controller

, CRD-controller Helm , push-. .

, .


, Helm . , , , . , , . Helm — - Kubernetes. - , , .

, CI/CD , . Slack، لدينا روبوت يقوم بالإبلاغ عند مرور بنية جديدة بشكل رئيسي ، وأن جميع الاختبارات كانت ناجحة. أنت تقول له: "أريد تثبيت هذا في التدريج" - ويثبت ، أنت تقول: "أريد إجراء اختبار هناك!" - ويبدأ. مريح جدا.

لتطوير استخدام Docker- يؤلف أو Telepresence.

إصدارات متعددة من خدمة واحدة

في النهاية ، سنقوم بتحليل الموقف عندما يكون هناك تطبيقان A و B ، يعتمدان على C ، ولكن C من إصدارات مختلفة. تحتاج إلى حل هذه المشكلة:

• من أجل التنمية ، لأنه في الواقع يتعين علينا تطوير الشيء نفسه ، ولكن نسختين مختلفتين ؛
• للنشر
• لتعارض الأسماء ، لأنه في جميع مديري الحزم القياسية ، يمكن أن يؤدي تثبيت حزمتين من الإصدارات المختلفة إلى حدوث مشكلات.

في الواقع ، يقرر Kubernetes كل شيء لنا - تحتاج فقط إلى استخدامه بشكل صحيح.



أود أن أنصح بإنشاء 4 مخططات من حيث Helm ، 3 مستودعات (بالنسبة لمستودع C ، سيكون هذا فقط فرعين مختلفين). الأكثر إثارة للاهتمام ، يجب أن تحتوي جميع عمليات التثبيت الخاصة بـ v1 و v2 على معلومات حول الإصدار أو الخدمة التي تم إنشاؤها داخلها. حل واحد على الشريحة ، الملحق C ؛ يشير اسم الإصدار إلى أن هذا هو الإصدار v1 للخدمة A ؛ يحتوي اسم الخدمة أيضًا على الإصدار. هذا هو أبسط مثال ، يمكنك القيام بذلك بشكل مختلف تمامًا. ولكن الشيء الأكثر أهمية هو أن الأسماء فريدة من نوعها.

والثاني هو التبعية متعدية ، وهنا الأمر أكثر تعقيدًا.


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

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

روابط مفيدة

• مشروع

• GitKube

• هيلم

• Ksonnet

• ملصقات برقية: واحد ، اثنان

• سيج تطبيقات

• KubePack

• Metaparticle

• سكافولد

• هيلم v3

• عامل الميناء يؤلف

• كسينك

• الحضور عن بعد

• بدون طيار

• صياغة

نبذة عن المتحدث إيفان غلوشكوف على جيثب ، على تويتر ، على هبر .

نبأ عظيم

على قناة youtube الخاصة بنا ، فتحنا مقطع فيديو لجميع التقارير حول DevOps من مهرجان RIT ++ . هذه قائمة تشغيل منفصلة ، لكن في القائمة الكاملة لمقاطع الفيديو ، هناك العديد من الأشياء المفيدة من مؤتمرات أخرى.

والأفضل من ذلك ، الاشتراك في القناة والرسالة الإخبارية ، لأنه في العام المقبل سنرى الكثير من المطورين : في مايو ، إطار RIT ++ ؛ في الربيع والصيف والخريف كقسم من HighLoad ++ ، وخريف منفصل DevOpsConf روسيا .