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

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

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

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

ما الفائدة منها؟

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

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

ما هي الفضائل التي نراها في كل هذا؟

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

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

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

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

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

التحول إلى Nomad

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

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

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

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

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

ما الذي تحتاجه بالفعل لنشر نظامك في Nomad؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أسباب مغادرة Nomad

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

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

لكننا واجهنا أيضًا عدة عيوب:

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

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

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

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

الانتقال إلى Kubernetes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ماذا قدم لنا؟

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

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

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

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

النتائج

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

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

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

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

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

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