مرحبا بالجميع! اسمي بافيل أغاليتسكي. أعمل كقائد فريق في فريق يقوم بتطوير نظام تسليم Lamoda. في عام 2018 ، تحدثت في مؤتمر HighLoad ++ ، وأريد اليوم تقديم نسخة من تقريري.

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

نشر التطبيقات على VM

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

لماذا تم ذلك؟

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

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

ما هي المزايا التي رأيناها في كل هذا؟

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

ولكن في هذا رأينا أيضًا العديد من أوجه القصور:

1. بالإضافة إلى بيئة الإنتاج ، بيئة التطوير ، هناك بيئات أخرى. على سبيل المثال ، qa والإنتاج المسبق. في ذلك الوقت ، كان لدينا العديد من الخوادم وحوالي 60 خدمة. لهذا السبب ، كان من الضروري لكل خدمة الحفاظ على إصدار الجهاز الظاهري الذي كان ذا صلة به . علاوة على ذلك ، إذا كنت ترغب في تحديث المكتبات أو تثبيت تبعيات جديدة ، فعليك القيام بذلك في جميع البيئات. كان من الضروري أيضًا مزامنة الوقت الذي تنوي فيه نشر الإصدار الجديد التالي من التطبيق الخاص بك مع الوقت الذي يقوم فيه devops بإعداد إعدادات البيئة الضرورية. في هذه الحالة ، من السهل الدخول في موقف تكون فيه بيئتنا مختلفة قليلاً في وقت واحد في جميع البيئات على التوالي. على سبيل المثال ، في بيئة ضمان الجودة ، سيكون هناك بعض إصدارات المكتبات ، وفي الإنتاج - غيرها ، مما سيؤدي إلى مشاكل.
2. صعوبة تحديث تبعيات التطبيق الخاص بك. لا يعتمد عليك ، ولكن على الفريق الآخر. وهي ، من الأمر devops ، الذي يدعم الخادم. يجب عليك تعيين مهمة مناسبة لهم وإعطاء وصف لما تريد القيام به.
3. في ذلك الوقت ، أردنا أيضًا تقسيم المقاطع الكبيرة الضخمة التي كانت لدينا في خدمات صغيرة منفصلة ، لأننا فهمنا أنه سيكون هناك المزيد والمزيد منها. في ذلك الوقت ، كان لدينا بالفعل أكثر من 100 منهم ، وكان من الضروري لكل خدمة جديدة أن تنشئ جهازًا افتراضيًا جديدًا منفصلًا ، والذي يجب أيضًا صيانته ونشره. بالإضافة إلى ذلك ، لا تحتاج إلى سيارة واحدة ، ولكن على الأقل سيارتين. إلى ذلك ، لا يزال يتم إضافة بيئة ضمان الجودة. هذا يسبب مشاكل ويجعل إنشاء وتشغيل أنظمة جديدة أكثر صعوبة ، ومكلفة وتستغرق وقتا طويلا بالنسبة لك.

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

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

التبديل إلى البدوي

البدوي هو منتج HashiCorp. وهي معروفة أيضًا بقراراتها الأخرى:



القنصل هو أداة لاكتشاف الخدمة.

Terraform هو نظام لإدارة الخوادم يسمح لك بتكوينها من خلال تكوين يسمى البنية التحتية ككود.

يسمح لك Vagrant بنشر الأجهزة الافتراضية محليًا أو في السحابة من خلال ملفات التكوين المحددة.

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

ما الذي يتطلبه الأمر لنشر نظامك بالكامل على Nomad؟

1. بادئ ذي بدء ، تحتاج إلى صورة عامل ميناء التطبيق الخاص بك. تحتاج إلى بنائه ووضعه في تخزين صورة عامل الميناء. في حالتنا ، هذا أمر اصطناعي - مثل هذا النظام الذي يسمح لك بدفع مختلف القطع الأثرية من مختلف الأنواع إلى ذلك. يمكنه تخزين المحفوظات ، صور عامل الميناء ، حزم مؤلف PHP ، حزم NPM ، وما إلى ذلك.
2. أنت بحاجة أيضًا إلى ملف تكوين يخبر Nomad ماذا وأين وكيف تريد نشره.

عندما نتحدث عن Nomad ، فإنه يستخدم لغة HCL كتنسيق ملف معلومات ، والذي يمثل لغة تكوين HashiCorp . هذه مجموعة شاملة من Yaml تسمح لك بوصف خدمتك من حيث Nomad.



يتيح لك تحديد عدد الحاويات التي تريد نشرها ، والتي تنقل منها الصور المعلمات المختلفة أثناء النشر. وبالتالي ، يمكنك تغذية ملف Nomad ، ويقوم بتشغيل حاويات في الإنتاج وفقًا لذلك.

في حالتنا ، أدركنا أن مجرد كتابة ملفات HLC متطابقة تمامًا لكل خدمة لن يكون مناسبًا للغاية ، لأن هناك العديد من الخدمات وأحيانًا تريد تحديثها. يحدث أن يتم نشر خدمة واحدة ليس في حالة واحدة ، ولكن في أكثرها اختلافًا. على سبيل المثال ، يحتوي أحد الأنظمة التي لدينا في الإنتاج على أكثر من 100 مثيل في الإنتاج. يتم إطلاقها من نفس الصور ، ولكنها تختلف في إعدادات التكوين وملفات التكوين.

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



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

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



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

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

عندما يتم نشر خدمة Nomad بالفعل في نظام المجموعة الخاص بك ، يبدو ذلك.



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

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

ماذا تكلفة الانتقال من حيث الموارد البشرية كلفنا؟

استغرق الانتقال من الشركة بأكملها إلى نوماد حوالي 5-6 أشهر. لقد غيرنا الخدمة ، ولكن بوتيرة سريعة إلى حد ما. كان على كل فريق إنشاء حاويات خاصة بهم للخدمات.

لقد اعتمدنا مثل هذا النهج بحيث يكون كل فريق مسؤولاً عن صور عامل الميناء لأنظمتهم. توفر Devops أيضًا البنية الأساسية العامة اللازمة للنشر ، أي دعم المجموعة نفسها ودعم نظام CI وما إلى ذلك. وفي ذلك الوقت ، كان لدينا أكثر من 60 نظامًا تم نقلها إلى نوماد ، واتضح أن حوالي 2000 حاوية.

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

أسباب التخلي عن البدوي

ما هي المزايا التي حصلنا عليها من خلال التبديل إلى النشر باستخدام Nomad ورسو السفن أيضًا؟

1. قدمنا نفس الشروط لجميع البيئات. في التنمية ، وتستخدم QA- البيئة ، ما قبل الإنتاج ، إنتاج نفس الصور من الحاويات ، مع نفس التبعيات. وفقًا لذلك ، ليس لديك أي فرصة عملياً أن يتحول الإنتاج إلى ما هو مختلف عما سبق اختباره محليًا أو في بيئة اختبار.
2. وجدنا أيضًا أنه من السهل جدًا إضافة خدمة جديدة . من وجهة نظر النشر ، يتم إطلاق أي أنظمة جديدة بكل بساطة. يكفي أن تذهب إلى المستودع الذي يخزن التكوينات ، أضف التكوين التالي لنظامك هناك ، وأنت جاهز. يمكنك نشر النظام الخاص بك في الإنتاج دون بذل جهد إضافي من devops.
3. تبين أن جميع ملفات التكوين في مستودع مشترك واحد تتم مراقبتها . في تلك اللحظة ، عندما نشرنا أنظمتنا باستخدام خوادم افتراضية ، استخدمنا Ansible ، حيث تكمن التكوينات في نفس المستودع. ومع ذلك ، بالنسبة لمعظم المطورين كان الأمر أكثر صعوبة في التعامل معه. أصبح حجم التهيئة والرمز الذي تحتاج إلى إضافته من أجل نشر الخدمة أصغر بكثير. بالإضافة إلى برامج devops ، من السهل جدًا إصلاحها أو تغييرها. في حالة التحولات ، على سبيل المثال ، في الإصدار الجديد من Nomad ، يمكنهم التقاط جميع ملفات التشغيل الموجودة في نفس المكان وتحديثها بشكل كبير.

لكننا واجهنا أيضًا العديد من أوجه القصور:

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

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

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

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

الذهاب إلى Kubernetes

سأتحدث قليلاً عن المفاهيم الأساسية لل Kubernetes وكيف تختلف عن البدوي.



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

افترض أن لديك تطبيق PHP يتكون من nginx و php-fpm - دائرة كلاسيكية. على الأرجح ، تريد أن تكون حاويات nginx و php-fpm معًا دائمًا. يقوم Kubernetes بهذا عن طريق وصفهم بأنه جراب واحد مشترك. هذا هو بالضبط ما لم نتمكن من الحصول عليه بمساعدة نوماد.

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

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

والمفهوم الأساسي الرابع هو دخول . هذه خدمة يتم تشغيلها في كتلة Kubernetes. وهو بمثابة موازن التحميل الخارجي ، والذي يأخذ على عاتق جميع الطلبات. بسبب واجهة برمجة التطبيقات ، يمكن لـ Kubernetes Ingress تحديد مكان إرسال هذه الطلبات. ويفعل ذلك بمرونة كبيرة. يمكنك القول أن جميع الطلبات لهذا المضيف وعنوان URL هذا يتم إرسالها إلى هذه الخدمة. ونحن نرسل هذه الطلبات القادمة إلى هذا المضيف وإلى عنوان URL آخر إلى خدمة أخرى.

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

إذا قارنا كل هذه المفاهيم مع البدوي ، فيمكننا القول أن المفاهيم الثلاثة الأولى كلها معًا خدمة. والمفهوم الأخير في البدوي نفسه مفقود. استخدمنا موازن خارجي كما هو: يمكن أن يكون haproxy ، nginx ، nginx + وما إلى ذلك. في حالة المكعب ، لا تحتاج إلى تقديم هذا المفهوم الإضافي بشكل منفصل. ومع ذلك ، إذا نظرت إلى Ingress بالداخل ، فهي إما nginx أو haproxy أو traefik ، ولكن كما لو كانت مضمنة في Kubernetes.

جميع المفاهيم التي وصفتها هي الموارد الموجودة في مجموعة Kubernetes. لوصفها في المكعب ، يتم استخدام تنسيق yaml ، وهو أكثر قابلية للقراءة ومألوفًا من ملفات HCl في حالة Nomad. لكن هيكليا يصفون في حالة ، على سبيل المثال ، جراب الشيء نفسه. يقولون - أريد أن نشر مثل هذه القرون هناك وهناك ، مع هذه الصور وكذا ، في مثل هذه الكمية.



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

المفاهيم الأساسية في هيلم

هيلم هو مدير الحزم في Kubernetes. إنه مشابه جدًا لكيفية عمل مديري الحزم بلغات البرمجة. إنها تتيح لك تخزين خدمة تتكون ، على سبيل المثال ، نشر nginx ، ونشر php-fpm ، وتهيئة لـ Ingress ، و configmaps (هذا كيان يسمح لك بتعيين env ومعلمات أخرى لنظامك) في شكل ما يسمى المخططات. في الوقت نفسه ، يعمل هيلم على قمة Kubernetes . أي أن هذا ليس نوعًا من النظام الذي يقف جانباً ، ولكن مجرد خدمة أخرى تعمل داخل المكعب. أنت تتفاعل معها من خلال API من خلال أمر وحدة التحكم. الراحة والسحر هو أنه حتى إذا انفصلت الدفة أو قمت بإزالتها من المجموعة ، فلن تختفي خدماتك ، لأن الدفة تخدم بشكل أساسي فقط لبدء النظام. Kubernetes نفسها هي المسؤولة عن الجهوزية وحالة الخدمات.

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

يضيف هلم بعض المفاهيم الإضافية لنا.

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

القيم هي المتغيرات التي تريد استخدامها لإنشاء التكوينات الخاصة بك من القوالب.

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

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



في الممارسة العملية ، قررنا القيام بشكل مختلف قليلاً عما فعلناه في حالة نوماد. إذا تم تخزين كل من التكوينات للنشر في Nomad في نفس المستودع ، وتم تخزين المتغيرات n التي كانت مطلوبة لنشر خدمتنا ، فقد قررنا هنا تقسيمها إلى مستودعين منفصلين. يتم تخزين فقط المتغيرات n اللازمة للنشر في مستودع النشر ، ويتم تخزين التكوينات أو المخططات في مستودع helm.



ماذا أعطانا؟

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

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

داخل كل مستودع ، تركنا فصلًا في أدلة منفصلة لكل خدمة. بمعنى أن هناك داخل كل دليل قوالب مرتبطة بالمخطط المقابل وتصف تلك الموارد التي يجب نشرها لتشغيل نظامنا. في مستودع النشر ، تركنا enves فقط. في هذه الحالة ، لم نستخدم templating مع jinja ، لأن helm نفسها تعطي templating خارج الصندوق - هذه واحدة من وظائفها الرئيسية.

لقد تركنا البرنامج النصي للنشر ، publish.sh ، الذي يبسط ويوحد الإطلاق للنشر باستخدام الدفة. وبالتالي ، بالنسبة لأي شخص يرغب في النشر ، فإن واجهة النشر تبدو تمامًا كما كانت في حالة النشر عبر Nomad. نفس publish.sh ، واسم خدمتك ، والمكان الذي تريد نشره فيه. هذا يؤدي رأس لبدء من الداخل. وهو ، بدوره ، يجمع التكوينات من القوالب ، ويستبدل القيم اللازمة لملفاتها ، ثم ينشرها ، ويضعها في Kubernetes.

النتائج

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



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

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

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

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