كان مهرجان RIT 2018 في Skolkovo كبيرًا ومتنوعًا للغاية. تطوير الهواتف المحمولة ، الواجهة الخلفية ، الواجهة الأمامية ، DevOps ، إدارة المشاريع وحتى علم النفس هي مواضيع لكل ذوق وفي جدول مزدحم من الصباح إلى المساء. تنقسم الموضوعات إلى مسارات منفصلة ، ترتبط المسارات بالصالات. إذا كانت التقارير المتخصصة فقط ذات أهمية ، يمكنك الاستقرار في الغرفة المناسبة. ومع ذلك ، تم استخدام القاعة الرئيسية حسب الحاجة من قبل المتحدثين حول مواضيع مختلفة.
بشكل عام ، كنت مستنيرًا بمعرفة DevOps ، وبعد مشاركة انطباعاتي عن المؤتمر مع زملائي ، قمت بتشكيل قائمة قصيرة من التقارير التي تذكرتها. مرت عدة أشهر ، وما زلت أتذكر جيدًا ما كانوا يتحدثون عنه.
إذن ، 3 تقارير فنية تذكرتها في RIT 2018.
المراقبة و Kubernetes
أدوات المراقبة المستخدمة الآن لا تدعم تطبيقات هندسة الخدمات الصغيرة. كلما زادت ديناميكيات النظام ، زادت صعوبة تكوين المراقبة له. إن المراقبة المريحة لأنظمة العنقود مثل Kubernetes ، التي تجلب الديناميكيات إلى التطرف ، هي مهمة غير تافهة بشكل عام. لماذا ذلك يتحدث ديميتري ستولياروف ، المدير الفني لشركة Flant ، عن أسباب هذا التعقيد وتأثيره على مهمة المراقبة الرئيسية.
تعتمد أنظمة المراقبة التقليدية على العمل مع الخوادم الثابتة ، التي نادرًا ما تتم إضافتها وإزالتها من البنية التحتية للتطبيق. في Kubernetes ، يحدث إنشاء وحذف بيئات الموقد وتطبيقات الخدمة كل ثانية ، لذلك لا يمكن لإجراءات الاكتشاف التلقائي الحالية التعامل مع هذا الحجم.
عدد البيئات نفسها هو أيضا في عشرات ومئات. وبناءً على ذلك ، يزداد مقدار القياس عن بُعد المُرسل بنفس المقدار. ولا تزال بحاجة إلى تخزينها في مكان ما.
هناك مشكلة منفصلة هي اصطدام العوالم المادية والافتراضية: استهلاك الموارد من قبل التطبيقات في Kubernetes سريع الزوال وينعكس من حيث القيود على المداخن. لكن استهلاك موارد الكبسولة له بالفعل تأثير مادي محدد على قدرات الخادم المتاحة. عند النظر إلى الرسوم البيانية ، عليك دائمًا التفكير من وجهة النظر التي تنظر فيها إلى الموارد. من الناحية العملية ، قليل من الناس مهتمون بالقرون الفردية. من المثير للاهتمام استهلاك الموارد من قبل التطبيق ككل ، وهذا يتطلب بالفعل مجموعة مرنة من قرون القياس عن بعد وفقًا لبعض المعايير المحددة من قبل المستخدمين.
وتحتاج إلى زيادة المخطط الناتج عدة مرات لبيئات التطوير / التدريج / prod واسعة النطاق!
ينصح التقرير لأي شخص يجب أن يدعم مجموعة kubernetes.
رابط للعرض التقديمي.
تطوير صندوق التنمية
كان من الممتع للغاية بالنسبة لنا أن نستمع إلى تقرير مكسيم لابشين ، الذي شارك فيه التجربة النادرة لاستخدام ممارسات devo في تطوير المنتجات المعبأة. المنتج المعبأ هو برنامج تقليدي يتم تثبيته وتشغيله وفقًا لقدرات المستخدم.
يقوم Erlyvideo بتطوير خادم دفق الفيديو ، ونحن خادم تكوين خدمات الإنترنت. مشاكلنا تشبه في نواح كثيرة تلك التي تسببت في تحويل ErOlvideo DevOps.
مكسيم يبدأ التقرير بإجابة على أهم سؤال: "ما كل هذا؟" جميع العوامل نفسها التي تدفع إلى إدخال ثقافة DevOps في تطوير الخدمات موجودة أيضًا في الصناعات التي يجري فيها تطوير تقليدي أكثر. ومن المحتمل أن يكون تأثير هذه العوامل في المنتجات المعبأة أكثر إثارة مما هو عليه عند العمل على الخدمة. على سبيل المثال ، كلما قل عدد الإصدارات ، زاد حجم التغييرات التي سيتم نشرها. إذا كنت تطرح خدمة جديدة ، يمكنك التأكد أو مجرد إقناع نفسك أنها آمنة. ولكن إذا قمت بإصدار توزيع منتج بعدد كبير من التغييرات ، فلا يكفي أن تقنع نفسك بأمان التحديث ، فسيتعين عليك أيضًا إقناع مستخدميك بأمانه. تأتي قطع صغيرة ولكن متكررة من التغيير لإنقاذ هنا. وهذه مجرد مشكلة.
يتعمق التقرير في هذا الأمر والعديد من الأسباب الأخرى لاستخدام التسليم المستمر ، ورسم أوجه التشابه والتأكيد على الاختلافات عن العمل الأبسط بشكل عام في وضع CI / CD مع الخدمات.
كيف هذا ممكن؟ في التقرير ، تصف مكسيم مجموعة الممارسات المستخدمة في Erlyvideo لجعل التسليم المستمر لتدفق التغييرات حقيقيًا. ستكون العديد من المناهج مفيدة كما هي ، وسيتطلب شيء ما التكيف مع حقائق عملنا. ولكن ، على أي حال ، يمكن أن تلهم قصة النجاح الرائعة هذه لإعادة التفكير في مشاكلهم وإيجاد حلول في مجموعة متنوعة من ممارسات DevOps.
سيكون التقرير مثيرًا للاهتمام جدًا لرؤية كل من يعمل على توزيع المنتجات.
رابط للعرض التقديمي.
قواعد الشبكات Kubernetes
إن دليل البدء السريع في كل مكان ، ودورة التصادم والبرامج التعليمية "كيفية البدء باستخدام kubernetes" تجعل من السهل نسبيًا القفز إلى هذه السيارة ونشر مجموعة ونشر التطبيق. بالنظر إلى الشعبية المذهلة لهذا الموضوع ، يفعل الكثير. ولكن لا تنس أن Kubernetes ، في جوهره ، نظام معقد إلى حد ما ، ويتطلب الحفاظ عليه معرفة محددة. في Ingram Micro Cloud ، كانت هذه المعرفة مطلوبة عندما أصبح التطبيق التالي غير متاح فجأة عبر الشبكة. من التحقيق في هذا الحادث ، بدأت الرحلة الرائعة لألكسندر خايوروف عبر النظام الفرعي للشبكة.
يطلعنا التقرير على العناصر المعقدة بشكل متزايد من مكدس شبكة Kubernetes ، موضحا كيف يتكون التوجيه الكبير والمعقد من الكتل الأولية. اتضح أنه مثير للاهتمام بشكل خاص عندما يتحدث ألكسندر عن سبب القيام بذلك ، وليس خلاف ذلك ، نمذجة خيارات التنفيذ الافتراضية الأخرى.
هذه هي أبجدية Kubernetes التي سيواجهها معظم المستخدمين. سألت نفسي الأسئلة "لماذا nodePort؟" و "لماذا لا أرى عنوان IP لخدمتي على الواجهة؟"
مثيرة للاهتمام وغنية بالمعلومات.
رابط للعرض التقديمي.