اسمي ديمتري سوغروبوف ، أنا مطور في Leroy Merlin. سأخبرك في المقالة عن سبب الحاجة إلى Helm ، وكيف يبسط العمل مع Kubernetes ، وما الذي تغير في الإصدار الثالث ، وكيفية استخدامه لتحديث التطبيقات في الإنتاج دون توقف.
هذا ملخص يستند إلى خطاب في مؤتمر by إذا كنت لا تريد القراءة ، شاهد الفيديو.
لماذا نستخدم Kubernetes في الإنتاج
Leroy Merlin هي الشركة الرائدة في سوق البيع بالتجزئة DIY في روسيا وأوروبا. تضم شركتنا أكثر من مائة مطور و 33 موظف داخلي وعدد كبير من الأشخاص الذين يزورون محلات السوبر ماركت والموقع. من أجل جعلهم جميعًا سعداء ، قررنا التمسك بمعايير الصناعة. تطوير تطبيقات جديدة باستخدام بنية الخدمات المصغرة ؛ استخدام الحاويات لعزل البيئات وتقديمها بشكل صحيح ؛ وللتزامن ، استخدم Kubernetes. أصبح سعر استخدام أوركسترا أرخص بسرعة: عدد المهندسين الذين يمتلكون التكنولوجيا آخذ في الازدياد في السوق ، ويبدو أن مقدمي الخدمة يقدمون خدمة Kubernetes.
كل ما تفعله Kubernetes ، بالطبع ، يمكن القيام به بطرق أخرى ، على سبيل المثال ، عن طريق تلطيخ بعض Jenkins و docker-compose بنصوص ، لكن لماذا تعقد الحياة إذا كان هناك حل جاهز وموثوق؟ لذلك ، أتينا إلى Kubernetes ونستخدمه في الإنتاج منذ عام الآن. لدينا الآن أربع وعشرون مجموعة Kubernetes ، أقدمها يزيد عمره عن عام مع حوالي مائتي كبسولة.
لعنة عدد كبير من ملفات YAML في Kubernetes
لتشغيل خدمة مصغرة في Kubernetes ، سننشئ ما لا يقل عن خمسة ملفات YAML: للنشر ، الخدمة ، الدخول ، ConfigMap ، الأسرار - وإرسالها إلى المجموعة. بالنسبة للتطبيق التالي ، سنكتب نفس حزمة yamliki ، مع الحزمة الثالثة - حزمة أخرى ، وهكذا. بضرب عدد المستندات في عدد البيئات ، نحصل بالفعل على مئات الملفات ، وهذا لا يأخذ بعين الاعتبار البيئات الديناميكية.
قدم آدم ريس ، المشرف الأساسي لشركة هيلم ، مفهوم ""، والتي تبدو كالتالي:
- انسخ YAML - انسخ ملف YAML.
- لصق YAML - الصقه.
- إصلاح المسافات البادئة - إصلاح المسافات البادئة.
- كرر - كرر مرة أخرى.
يعمل الخيار ، ولكن عليك نسخ ملفات YAML عدة مرات. لتغيير هذه الدورة ، توصلوا إلى هيلم.
ما هو دفة
أولا ، هيلم مدير مجموعة، مما يساعدك في العثور على البرامج التي تحتاجها وتثبيتها. لتثبيت ، على سبيل المثال ، MongoDB ، لا تحتاج إلى الانتقال إلى الموقع الرسمي وتنزيل الثنائيات ، فقط قم بتشغيل الأمر helm install stable/mongodb.
ثانياً ، هيلم - محرك القالب، يساعد على تحديد معلمات الملفات. دعنا نعود إلى الموقف مع ملفات YAML في Kubernetes. من الأسهل كتابة نفس ملف YAML ، وإضافة بعض العناصر النائبة إليه ، حيث يقوم Helm باستبدال القيم. أي ، بدلاً من مجموعة كبيرة من yamliks ، ستكون هناك مجموعة من القوالب (القوالب) التي سيتم فيها استبدال القيم الضرورية في الوقت المناسب.
ثالثًا ، هيلم - معالج النشر. باستخدامه ، يمكنك تثبيت التطبيقات والتراجع عنها وتحديثها. دعونا نرى كيف نفعل ذلك.
كيفية استخدام Helm لنشر تطبيقاتك الخاصة
قم بتثبيت عميل Helm على الكمبيوتر ، باتباع المسؤول . ثم سننشئ مجموعة من ملفات YAML. بدلاً من تحديد قيم معينة ، دعنا نترك العناصر النائبة التي سوف يملأها هيلم بالمعلومات في المستقبل. تسمى مجموعة من هذه الملفات مخطط Helm. يمكن إرسالها إلى عميل وحدة تحكم Helm بثلاث طرق:
- تحديد مجلد مع القوالب ؛
- حزمة في أرشيف .tar والإشارة إليه ؛
- ضع القالب في مستودع بعيد وأضف رابطًا إلى المستودع في عميل Helm.
تحتاج أيضًا إلى ملف بقيم - قيم. yaml. سيتم استبدال البيانات من هناك في القالب. دعونا ننشئه أيضًا.
يحتوي الإصدار الثاني من Helm على تطبيق خادم إضافي يسمى Tiller. يتم تعليقه خارج Kubernetes وينتظر الطلبات من عميل Helm ، وعندما يتم استدعاؤه ، فإنه يستبدل القيم الضرورية في القالب ويرسله إلى Kubernetes.
يعتبر Helm 3 أبسط: فبدلاً من معالجة القوالب على الخادم ، تتم الآن معالجة المعلومات بالكامل من جانب عميل Helm وإرسالها مباشرةً إلى Kubernetes API. هذا التبسيط يحسن أمن المجموعة ويسهل مخطط الطرح.
كيف يعمل كل شيء
قم بتشغيل الأمر helm install. حدد اسم إصدار التطبيق ، وأعط المسار إلى القيم. yaml. في النهاية ، سنحدد المستودع الذي يحتوي على الرسم البياني واسم المخطط. في المثال ، هما "lmru" و "bestchart" على التوالي.
helm install --name bestapp --values values.yaml lmru/bestchart
يمكن تنفيذ الأمر مرة واحدة فقط ، عند إعادة التنفيذ بدلاً من install بحاجة الى استخدام upgrade. للتبسيط ، يمكنك تشغيل الأمر بدلاً من أمرين upgrade بمفتاح إضافي --install. عند التنفيذ الأول ، سيرسل Helm أمرًا لتثبيت الإصدار ، وسيقوم بتحديثه في المستقبل.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
مطبات نشر إصدارات جديدة من التطبيق مع Helm
في هذه المرحلة من القصة ، ألعب لعبة Who Wants to Be a Millionaire مع الجمهور ونكتشف كيفية جعل Helm لتحديث إصدار التطبيق. .
عندما درست عمل هيلم ، فوجئت بالسلوك الغريب عند محاولة تحديث إصدارات التطبيقات قيد التشغيل. لقد قمت بتحديث رمز التطبيق ، وحمّلت صورة جديدة إلى سجل عامل التحميل ، وأرسلت الأمر للنشر - ولم يحدث شيء. فيما يلي بعض الطرق غير الجيدة لتحديث التطبيقات. من خلال دراسة كل منها بمزيد من التفصيل ، تبدأ في فهم الهيكل الداخلي للآلة وأسباب هذا السلوك غير الواضح.
الطريقة الأولى: لا تغير المعلومات منذ التشغيل الأخير
على رأي القول هيلم ، "يمكن أن تكون مخططات Kubernetes كبيرة ومعقدة ، لذلك يحاول Helm إبقاء الأمور بسيطة قدر الإمكان." لذلك ، إذا قمت بتحديث أحدث إصدار من صورة التطبيق في سجل عامل الإرساء وقمت بتشغيل الأمر helm upgrade، فلن يحدث شيء. سيعتقد Helm أنه لم يتغير شيء ولا توجد حاجة لإرسال أمر إلى Kubernetes لتحديث التطبيق.
من الآن فصاعدًا ، يتم عرض أحدث علامة كمثال فقط. عند تحديد هذه العلامة ، سيقوم Kubernetes بتنزيل الصورة من سجل docker في كل مرة ، بغض النظر عن معلمة imagePullPolicy. استخدام الأحدث في الإنتاج أمر غير مرغوب فيه ويسبب آثارًا جانبية.
الطريقة الثانية: تحديث LABEL في الصورة
كما هو مكتوب في نفسه ، "لن يقوم Helm بتحديث التطبيق إلا إذا تم تغييره منذ الإصدار الأخير." سيكون الخيار المنطقي لهذا هو تحديث LABEL في صورة عامل الإرساء نفسها. ومع ذلك ، فإن هيلم لا تنظر في صور التطبيق وليست على علم بأي تغييرات تطرأ عليها. وفقًا لذلك ، عند تحديث الملصقات الموجودة في الصورة ، لن يعرف Helm عنها ، ولن يتم تلقي أمر تحديث التطبيق في Kubernetes.
الطريقة الثالثة. استخدم المفتاح --force
دعنا ننتقل إلى الأدلة ونبحث عن المفتاح الصحيح. المفتاح الأكثر منطقية --force. على الرغم من الاسم المعقول ، يختلف السلوك عما هو متوقع. بدلاً من التحديث الإجباري للتطبيق ، فإن الغرض الحقيقي منه هو استعادة إصدار في حالة "فشل". إذا كنت لا تستخدم هذا المفتاح ، فأنت بحاجة إلى تنفيذ الأوامر بالتسلسل helm delete && helm install --replace. بدلاً من ذلك ، يُقترح استخدام المفتاح --force، والذي يقوم بأتمتة التنفيذ المتسلسل لهذه الأوامر. مزيد من المعلومات في هذا . من أجل إخبار Helm بتحديث إصدار التطبيق ، للأسف ، لن يعمل هذا المفتاح.
الطريقة الرابعة. قم بتغيير الملصقات مباشرة في Kubernetes
تحديث التسمية مباشرة في الكتلة باستخدام الأمر kubectl edit - فكرة سيئة. سيؤدي هذا الإجراء إلى عدم تناسق المعلومات بين التطبيق قيد التشغيل والتطبيق الذي تم إرساله للنشر في الأصل. يختلف سلوك Helm أثناء النشر في هذه الحالة عن إصداره: لن يفعل Helm 2 أي شيء ، وسيقوم Helm 3 بنشر إصدار جديد من التطبيق. لفهم السبب ، عليك أن تفهم كيف يعمل هيلم.
كيف يعمل هيلم
لتحديد ما إذا كان أحد التطبيقات قد تغير منذ الإصدار الأخير ، يمكن لـ Helm استخدام:
- تطبيق قيد التشغيل في Kubernetes ؛
- قيم جديدة. yaml والرسم البياني الحالي ؛
- معلومات الإصدار الداخلي لشركة Helm.
الأكثر فضولًا: أين تخزن Helm معلومات الإصدار الداخلي؟بتنفيذ الأمر helm history، سوف نحصل على جميع المعلومات حول الإصدارات المثبتة مع Helm.
هناك أيضًا معلومات مفصلة حول الأنماط والقيم المرسلة. يمكننا أن نطلبها:
في الإصدار الثاني من Helm ، توجد هذه المعلومات في نفس مساحة الاسم حيث يتم تشغيل Tiller (افتراضيًا ، kube-system) ، في ConfigMap ، تم تمييزها بالتسمية "OWNER = TILLER":
في وقت ظهور الإصدار الثالث من Helm ، انتقلت المعلومات إلى الأسرار ، علاوة على ذلك ، إلى نفس مساحة الاسم حيث يتم تشغيل التطبيق. بفضل هذا ، أصبح من الممكن تشغيل العديد من التطبيقات في نفس الوقت في مساحات أسماء مختلفة بنفس اسم الإصدار. في الإصدار الثاني ، كان الأمر يمثل صداعًا شديدًا عندما تكون مساحات الأسماء معزولة ، ولكن يمكن أن تؤثر على بعضها البعض.
يستخدم Helm الثاني ، عند محاولة اكتشاف ما إذا كان التحديث مطلوبًا ، مصدرين فقط للمعلومات: ما تم توفيره له الآن ، والمعلومات الداخلية حول الإصدارات الموجودة في ConfigMap.
يستخدم Helm الثالث إستراتيجية دمج ثلاثية: بالإضافة إلى هذه المعلومات ، فإنه يأخذ في الاعتبار أيضًا التطبيق الذي يتم تشغيله الآن في Kubernetes.
لهذا السبب ، فإن الإصدار القديم من Helm لن يفعل أي شيء ، لأنه لا يأخذ في الاعتبار معلومات التطبيق في الكتلة ، لكن Helm 3 سيتلقى التغييرات ويرسل التطبيق الجديد للنشر.
الطريقة الخامسة: استخدم مفتاح --recreat-pods
بمفتاح --recreate-pods يمكنك تحقيق ما كان مخططًا في الأصل للحصول عليه باستخدام المفتاح --force. ستتم إعادة تشغيل الحاويات ، ووفقًا لـ imagePullPolicy: سياسة دائمًا لأحدث علامة (المزيد عن ذلك في الحاشية أعلاه) ، سيقوم Kubernetes بتنزيل الإصدار الجديد من الصورة وتشغيله. لن يتم ذلك بأفضل طريقة: بدون مراعاة نوع الإستراتيجية للنشر ، سيتم إيقاف تشغيل جميع طبعات التطبيق القديمة بشكل مفاجئ والذهاب لإطلاق نسخ جديدة. أثناء إعادة التشغيل ، لن يعمل النظام ، وسيعاني المستخدمون.
في Kubernetes نفسها ، توجد مشكلة مماثلة أيضًا لفترة طويلة. والآن ، بعد 4 سنوات من الافتتاح ، تم إصلاح المشكلة ، وبدءًا من الإصدار 1.15 من Kubernetes ، تظهر إمكانية إعادة تشغيل القرون.
يقوم Helm ببساطة بإيقاف تشغيل جميع التطبيقات وإطلاق حاويات جديدة في مكان قريب. في الإنتاج ، لا يمكنك القيام بذلك ، حتى لا تتسبب في تطبيق بسيط. هذا مطلوب فقط لاحتياجات التطوير ، ولا يمكن القيام به إلا في بيئات المرحلة.
كيفية تحديث إصدار التطبيق باستخدام Helm؟
سنقوم بتغيير القيم المرسلة إلى هيلم. عادةً ما يتم استبدال هذه القيم بعلامة الصورة. في حالة الأحدث ، والتي غالبًا ما تستخدم للبيئات غير المنتجة ، يعمل التعليق التوضيحي كمعلومات قابلة للتغيير ، وهو أمر غير مفيد لـ Kubernetes نفسه ، وبالنسبة لشركة Helm سيكون بمثابة إشارة لتحديث التطبيق. خيارات تعبئة قيمة التعليقات التوضيحية:
- قيمة عشوائية باستخدام الوظيفة القياسية
{{ randAlphaNum 6 }}.
هناك فارق بسيط: بعد كل نشر باستخدام مخطط بمثل هذا المتغير ، ستكون قيمة التعليق التوضيحي فريدة ، وسيفترض Helm أن هناك تغييرات. اتضح أننا سنعيد تشغيل التطبيق دائمًا ، حتى لو لم نقم بتغيير نسخته. هذا ليس حرجًا ، حيث لن يكون هناك توقف ، ولكن لا يزال غير سار. - أدخل التيار التاريخ و الوقت -
{{ .Release.Date }}.
المتغير هو مثل قيمة عشوائية بمتغير فريد بشكل دائم. - أفضل طريقة للاستخدام اختباري. هذا هو SHA للصورة أو SHA لآخر التزام في git -
{{ .Values.sha }}.
سيحتاجون إلى عدهم وإرسالهم إلى عميل هيلم من جهة الاتصال ، على سبيل المثال في جينكينز. إذا تم تغيير التطبيق ، فسيتغير المجموع الاختباري أيضًا. لذلك ، لن يقوم Helm بتحديث التطبيق إلا عند الحاجة.
دعونا نلخص جهودنا
- يقوم Helm بإجراء تغييرات بأقل الطرق توغلًا ، لذا فإن أي تغيير على مستوى صورة التطبيق في Docker Registry لن ينتج عنه تحديث: لن يحدث أي شيء بعد تنفيذ الأمر.
- مفتاح
--forceتُستخدم لإصلاح الإصدارات المسببة للمشاكل ولا ترتبط بالترقية الإجبارية. - مفتاح
--recreate-podsسيقوم بتحديث التطبيقات بالقوة ، لكنه سيفعل ذلك بطريقة مخربة: سيغلق فجأة جميع الحاويات. سيعاني المستخدمون من هذا الأمر ، لا يستحق القيام بذلك عند البيع. - قم بإجراء تغييرات مباشرة على مجموعة Kubernetes باستخدام الأمر
kubectl editلا تفعل: سنكسر الاتساق ، وسيختلف السلوك اعتمادًا على إصدار Helm. - مع إصدار الإصدار الجديد من Helm ، ظهرت العديد من الفروق الدقيقة. يتم وصف المشكلات في مستودع Helm بلغة واضحة ، وسوف تساعدك على فهم التفاصيل.
- ستؤدي إضافة تعليق توضيحي قابل للتغيير إلى الرسم البياني إلى جعله أكثر مرونة. سيسمح هذا للتطبيق بالطرح بشكل صحيح ، دون توقف.
فكر من فئة "السلام في العالم" ، يعمل في جميع مجالات الحياة: اقرأ التعليمات قبل الاستخدام وليس بعده. فقط الحصول على معلومات كاملة سيكون من الممكن بناء أنظمة موثوقة وإسعاد المستخدمين.
روابط أخرى ذات صلة:
تم تقديم هذا التقرير لأول مرة في بواسطة Mail.ru Cloud Solutions. يرى العروض الأخرى والاشتراك في إعلانات الأحداث في Telegram .
المصدر: www.habr.com