💥 🛀🏽 🗨️ Kubernetes بروح القرصنة: طريقنا إلى الخدمات الصغيرة ونموذج جاهز للتنفيذ ♐️ 🤸 🥄

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

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

تستند هذه المقالة إلى عرض فيديو في مؤتمر Kubernetes بواسطة Mail.ru Cloud Solutionsإذا كنت لا تريد القراءة ، يمكنك أن ترى .

كيف كنا نعيش قبل Kubernetes: خوادم مطورة ومعادن عارية و Ansible

عشنا ونعيش في وضع من التغييرات والتجارب المستمرة: اختبارات AV واختبار الفرضيات المختلفة. نطلق خدمات جديدة ، إذا لم ينجح شيء ما ، نقطعه.

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

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

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

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

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

كيف وصلنا إلى Kubernetes وقمنا ببناء البنية التحتية عليه

من الواضح أنه لا يمكن للمرء أن يعيش على هذا النحو ، هناك حاجة إلى تنسيق. لقد فهمنا هذا في 2017-2018 ، ثم لم يكن من الواضح من أين تحصل على هذه الأوركسترا. كانت Kubernetes قد بدأت للتو ، وكان هناك HashiCorp Nomad و Rancher و OpenShift. لقد جربنا Nomad ، لم يكن الأمر سيئًا ، لكننا لم نرغب في إعادة كتابة تكوين عامل الميناء إلى تكوينات Nomad.

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

ثم ظهرت Kubernetes على منصة Mail.ru Cloud Solutions كخدمة Mail.ru Cloud Containers. لقد قمنا بالفعل بنقل تخزين S3 الخاص بنا هناك من Amazon ، وقررنا تجربة K8s أيضًا. نشرنا مجموعة في السحابة ، عمل كل شيء.

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

كل مطور لديه Minikube الخاص به في VMware ، والذي يعمل معه. أطلقنا مشاريع جديدة في Kubernetes في سحابة MCS ، وننشر أيضًا MySQL مُدارة ، والتي تصل فورًا مع جميع العبيد والنسخ والنسخ الاحتياطي في S3.

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

كيف تعيش مع حديقة حيوانات التكنولوجيا ولا تعاني

حديقة التكنولوجيا ليست الآن مخيفة كما كانت ، على سبيل المثال ، في عام 2011. من الطبيعي أن تأخذ أدوات وتقنيات متخصصة من أماكن مختلفة وتستخدمها كما تريد. على سبيل المثال ، نستخدم Golang لبعض الأشياء ، ولكن يعمل عالم البيانات في Python ، ولا يمكنك إجبارهم على الكتابة في GO أو PHP.

بشكل عام ، لدينا قاعدتان:

الإرساء: يجب أن تكون هناك حاويات ؛
قابلية الملاحظة: يجب أن تكون هذه الحاويات قابلة للملاحظة.

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

للملاحظة ، لدينا مكدس قياسي: يكتب كل تطبيق سجلات إلى stdout ، حيث يتم نقل كل شيء مركزيًا إلى EFK. أي أن المطور يمكنه القدوم ورؤية السجلات في كيبانا. مقاييس التطبيق التي نسقطها في Prometheus ولوحات المعلومات والتنبيهات كمعيار قياسي في Grafana. Jaeger هي قصة افتتاحية تُظهر من يصل إلى الخدمة إذا لم نكن نعرف أو لا نريد التعامل معها بطرق أخرى.

كيفية تطوير واختبار كل هذا

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

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

هناك لقطات في ZFS ، يمكن لمطور واجهة برمجة التطبيقات (API) تشغيل قاعدة البيانات مباشرة من الإنتاج في غضون ثانيتين. مع الاختبارات الذاتية ، نفس القصة: نبدأ بواجهة برمجة التطبيقات ، وكل شيء يعمل.

هذا ما يبدو عليه تدفق التطوير اليوم:

المطور سعيد ، DevOps والمشرفون سعداء لأن جميع العمليات موحدة ومتكررة وموحدة. لكن هناك شيء واحد.

نظام طبقات الطبقات

كما قال لينوس تورفالدس: "الكلام رخيص. أرني الرمز ". لذلك ، نستخدم نظام طبقات متعدد المستويات. هناك طبقات تافهة: dev ، stage ، prod ، والتي تتبادر إلى الذهن لكل من سيقوم بعمل CI / CD.

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

لحظة أخرى مليئة بالمرح - لا نستخدم تيلر ، استقر على هيلم ، لكننا نستخدمها في الواقع كمحرك نموذج. أي أننا نستخدم فقط قالب الدفة ، فهو يعطي ملف yaml عند الإخراج ، والذي يمكن أن يُنسب إلى Minikube أو مجموعة ، ولا حاجة إلى أي شيء آخر.

كيف يعمل مستودع K8s-helm

كما قلت ، لدينا طبقات واضحة من dev ، prod و stage ، هناك ملف yaml من كل خدمة ، عندما رأينا خدمة جديدة ، أضف الملف.

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

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

ونتيجة لذلك ، تتلخص العملية في ثلاث فرق:

عند وصول مطور جديد ، أعطوه Minikube مجلد أرشيف يحتوي على شهادات ومجال. بشكل عام ، يحتاج فقط kubectl و Helm. يستنسخ المستودع لنفسه ، ويظهر kubectl المسار إلى تكوينه ، ويدير الأمر make_user باسمه. وبالنسبة لجميع الخدمات ، يتم إنشاء نسخ له. علاوة على ذلك ، لم يتم إنشاؤها فقط - هناك قاعدة بيانات تم منحها له ، وصف المطور لها أوراق الاعتماد الخاصة بها ، وكل هذه أوراق الاعتماد تذهب إلى خدمات أخرى.

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

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

تجميع K8s-helm

يتم أيضًا تخزين المستودع نفسه وإدراجه في عمليات CI / CD. لا يوجد شيء مميز هنا - فقط kubectl مع الشهادات و Helm.

في المشروع ، يبدو كما يلي:

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

ثم يأتي CI ، هنا. drone.yml ، ولكن سيحدث نفس الشيء في GitLab أو في مكان آخر.

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

نحن نحب المصادر المفتوحة ، ونريد أن نستثمر في تطوير DevOps ، لذلك قمنا بعمل قالب يمكنك استخدامه وتحميله على github . هناك كل ما تحدثت عنه: يمكنك أن تأخذ ، تشاهد ، تختبر وتقدم. سيكون مفيدًا لكل من يقوم بتنفيذ خدمات متناهية الصغر ، أو يعاني من حقيقة أن الفريق ينفذ خدمات متناهية الصغر ، أو يريد بناء عمليات DevOps حول هذا.

مقالاتنا الأخرى ذات الصلة:

تم إجراء هذا الحديث لأول مرة في مؤتمر Kubernetes بواسطة Mail.ru Cloud Solutions. مشاهدة الفيديو من العروض الأخرى، والاشتراك في الإعلانات الحدث برقية حوالي Kubernetes في المجموعة Mail.ru .

Kubernetes بروح القرصنة: طريقنا إلى الخدمات الصغيرة ونموذج جاهز للتنفيذ