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

نحن من شركة Exness للتكنولوجيا المالية ، التي تطور خدمات التداول عبر الإنترنت ومنتجات التكنولوجيا المالية لـ B2B و B2C. هناك العديد من الفرق المختلفة في البحث والتطوير لدينا ، في قسم التطوير أكثر من 100 موظف.

نحن نمثل الفريق المسؤول عن النظام الأساسي لجمع وتشغيل التعليمات البرمجية من قبل المطورين لدينا. على وجه الخصوص ، نحن مسؤولون عن جمع وتخزين وتوفير المقاييس والسجلات والأحداث من التطبيقات. نعمل حاليًا على حوالي ثلاثة آلاف حاوية Docker في بيئة المنتج ، وندعم تخزيننا للبيانات الضخمة بسعة 50 تيرابايت وتوفير حلول معمارية مبنية حول بنيتنا التحتية: Kubernetes و Rancher ومزودي الخدمات السحابية العامة المختلفة.

دافعنا

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

لماذا تقف بعض الحاويات بينما يقع البعض الآخر؟ ما الحاوية التي يقع عليها اللوم؟ في الواقع ، خارج الحاويات هي نفسها ، ولكن داخل كل منها Neo الخاص بها.

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

عملاء

لفهم ما يجري في الداخل ، قررنا وضع الوكلاء مباشرة في حاويات.

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

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

يعني الوكلاء أيضًا أدوات تشغيل وصيانة ، وقادرة على العمل في أنظمة تنسيق مختلفة ، ودعم صور مختلفة (Debian ، Alpine ، Centos ، إلخ).

أخيرًا ، يجب على الوكلاء دعم CI / CD بسيط بما في ذلك ملفات Docker. خلاف ذلك ، سوف تنهار السفينة ، لأن الحاويات ستبدأ في تسليمها على سكك "منحنية".

عملية التجميع وصورة الجهاز الهدف

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

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

والنتيجة هي أداة بناء - حاوية نسخة معينة ، والتي تشير إلى إصدارات معينة من التوزيعات وإصدارات معينة من البرامج النصية.

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

لماذا هذا النهج جيد؟

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

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

كيف يعمل إجراء البناء لدينا

يتم بدء التجميع باستخدام أمر واحد ، ويتم تنفيذ العملية في الصورة (مظللة باللون الأحمر). يحتوي المطور على ملف Docker (مظلل باللون الأصفر) ، ونعرضه عن طريق استبدال المتغيرات بالقيم. وعلى طول الطريق نضيف الرؤوس والتذييلات - هؤلاء هم وكلائنا.

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

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

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

بالنسبة للحاوية نفسها ، نحصل على أشجار معالجة مختلفة في Docker و Kubernetes:

يتم تنفيذ الحمولة تحت إشراف S6. انتبه إلى الجامع والأحداث - هؤلاء هم وكلاؤنا المسؤولون عن السجلات والمقاييس. لا تمتلكها Kubernetes ، لكن Docker تمتلكها. لماذا ا؟

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

المقاييس والسجلات

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

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

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

والجانب الأخير - تحتاج إلى تقليل استهلاك الموارد.

لقد اخترنا حل Go مفتوح المصدر يسمى Telegraf. هذا موصل عالمي يدعم أكثر من 140 نوعًا من قنوات الإدخال (الإضافات الإدخال) و 30 نوعًا من الإخراج (الإضافات الإخراج). لقد وضعنا اللمسات الأخيرة عليه ، والآن سنخبرك كيف يتم استخدامه مع Kubernetes كمثال.

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

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

نجمع السجلات من خلال Docker API: يكفي للمطورين وضعها في stdout أو stderr ، ثم سيكتشف Collector ذلك. يتم جمع السجلات عن طريق القطعة مع بعض التأخير لمنع احتقان المضيف المحتمل.

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

تتوفر السجلات في Graylog (للتحليل البصري) ؛
يتم إرسال السجلات والمقاييس والأحداث إلى Clickhouse للتخزين على المدى الطويل.

وبالمثل ، كل شيء يعمل في AWS ، فقط نحن نستبدل Graylog من Kafka بـ Cloudwatch. نرسل السجلات إلى هناك ، وتبين أن كل شيء مريح للغاية: يتضح على الفور لمن تنتمي الكتلة والحاوية. وينطبق الشيء نفسه على Google Stackdriver. وهذا يعني أن مخططنا يعمل معًا في المؤسسة مع كافكا وفي السحابة.

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

يتم تنفيذ نفس العمليات داخل الحاوية ، ويتم تنسيقها باستخدام S6. يتم تشغيل جميع العمليات نفسها داخل الحاوية نفسها.

في النهاية

لقد أنشأنا حلاً كاملاً لتجميع الصور وتشغيلها ، مع خيارات لجمع السجلات والمقاييس وتسليمها:

طورت نهجًا موحدًا لتجميع الصور ، استنادًا إلى قوالب CI المطورة ؛
وكلاء جمع البيانات هي ملحقاتنا لشركة Telegraf. قمنا بتشغيلها بشكل جيد في الإنتاج ؛
نحن نستخدم webhook webhook لتنفيذ حاويات مع وكلاء في القرون.
دمجها في النظام البيئي Kubernetes / Rancher ؛
يمكننا تنفيذ نفس الحاويات في أنظمة تنسيق مختلفة والحصول على النتيجة التي نتوقعها ؛
إنشاء تكوين إدارة حاوية ديناميكي بالكامل.

المؤلف المشارك: Ilya Prudnikov

صور جاهزة للإنتاج لـ k8s