يتم إنشاء التطبيقات "المستندة إلى مجموعة النظراء" (السحابية الأصلية) أو فقط التطبيقات "السحابية" خصيصًا للاستخدام في البنية التحتية السحابية. عادةً ما يتم بناؤها كمجموعة من الخدمات المجهرية غير المتراصة والمغلفة في حاويات ، والتي بدورها تدار بواسطة منصة سحابية. تعد هذه التطبيقات بشكل افتراضي جاهزة للإخفاقات ، مما يعني أنها تعمل بشكل موثوق وقياس حتى في حالة الإخفاقات الخطيرة في مستوى البنية التحتية. الجانب الآخر للعملة هو مجموعة من القيود (العقود) التي تفرضها المنصة السحابية على تطبيقات الحاوية حتى تتمكن من إدارتها تلقائيًا.
وإدراكًا منها للحاجة إلى الانتقال إلى التطبيقات السحابية وأهميتها ، لا تزال العديد من المنظمات لا تعرف من أين تبدأ. في هذا المنشور ، سننظر في عدد من المبادئ ، التي عندها ستدرك إمكانية تطوير تطبيقات الحاوية إمكانات المنصات السحابية وتحقيق التشغيل الموثوق وتوسيع نطاق التطبيقات حتى في حالة حدوث إخفاقات خطيرة على مستوى البنية التحتية لتكنولوجيا المعلومات. الهدف النهائي للمبادئ الموضحة هنا هو معرفة كيفية إنشاء تطبيقات يمكن إدارتها تلقائيًا بواسطة الأنظمة الأساسية السحابية مثل Kubernetes.
مبادئ تصميم البرمجيات
في عالم البرمجة ، يتم فهم المبادئ كقواعد عامة إلى حد ما يجب مراعاتها عند تطوير البرامج. يمكن استخدامها عند العمل مع أي لغة برمجة. كل مبدأ له أهدافه الخاصة ، وعادة ما تكون القوالب والممارسات أداة لتحقيقها. هناك أيضًا عدد من المبادئ الأساسية لإنشاء برامج عالية الجودة ، والتي يتبعها كل الآخرين. فيما يلي بعض الأمثلة على المبادئ الأساسية:
- قبلة (اجعلها بسيطة ، غبية) - لا تعقد ؛
- جافة (لا تكرر نفسك) - لا تكرر ؛
- YAGNI (لست بحاجة إلى ذلك) - لا تنشئ شيئًا لا توجد فيه حاجة فورية ؛
- SoC (الفصل بين المخاوف) - لتقاسم المسؤوليات.
كما ترون ، هذه المبادئ لا تحدد أي قواعد محددة ، ولكنها تنتمي إلى فئة ما يسمى اعتبارات المنطق السليم القائمة على الخبرة العملية التي يشاركها العديد من المطورين والتي يشيرون إليها بانتظام.
بالإضافة إلى ذلك ، هناك
SOLID - مجموعة من المبادئ الخمسة الأولى للبرمجة والتصميم وجوه المنحى ، التي وضعها روبرت مارتن. يتضمن SOLID مبادئ متكاملة بشكل عام ومفتوحة للتفسير ، والتي - عند تطبيقها في تركيبة - تساعد على إنشاء أنظمة برمجية أفضل ودعمها على المدى الطويل.
تنطبق مبادئ SOLID على OOP ويتم صياغتها من حيث المفاهيم والمفاهيم مثل الفئات والواجهات والميراث. وقياسًا على ذلك ، بالنسبة للتطبيقات السحابية ، يمكنك أيضًا صياغة مبادئ التطوير ، ولن يكون العنصر الأساسي هنا هو الطبقة فقط ، بل حاوية. باتباع هذه المبادئ ، يمكنك إنشاء تطبيقات في حاويات تلبي على نحو أفضل أهداف وأهداف المنصات السحابية مثل Kubernetes.
الحاويات المستندة إلى مجموعة النظراء: نهج القبعة الحمراء
اليوم ، أي تطبيق تقريبًا سهل التعبئة في حاويات. ولكن من أجل أن تكون التطبيقات مؤتمتة ومدارة بشكل فعال داخل منصة سحابية مثل Kubernetes ، يلزم بذل جهد إضافي.
استندت الأفكار الواردة أدناه إلى منهجية
تطبيق Twelve-Factor والعديد من الأعمال الأخرى حول الجوانب المختلفة لإنشاء تطبيقات الويب ، من التحكم بالمصادر إلى نماذج المقاييس. تنطبق المبادئ الموضحة فقط على تطوير تطبيقات الحاوية التي تم إنشاؤها على أساس الخدمات المصغرة والتي تم تصميمها لمنصات سحابية مثل Kubernetes. العنصر الأساسي في مناقشتنا هو صورة الحاوية ، ووقت تشغيل الحاوية المستهدفة هو النظام الأساسي لتنسيق الحاوية. الغرض من المبادئ المقترحة هو إنشاء حاويات يمكنك من خلالها ، في معظم الأنظمة الأساسية للتنسيق ، أتمتة مهام الجدولة (الجدولة - اختيار مضيف لتشغيل مثيل الحاوية) ، وتوسيع نطاقه ومراقبته. وترد المبادئ في ترتيب عشوائي.
مبدأ الاهتمام الفردي (SCP)
يشبه هذا المبدأ من نواح كثيرة مبدأ المسؤولية الفردية (
SRP ) ، والذي يعد جزءًا من مجموعة SOLID وينص على أن كل كائن يجب أن يتحمل مسؤولية واحدة ، ويجب أن يتم تضمين هذه المسؤولية بالكامل في الفصل. جوهر برنامج التقويم الاستراتيجي هو أن كل واجب هو سبب للتغيير ، ويجب أن يكون للفصل سبب واحد فقط للتغيير.
في SCP ، بدلاً من كلمة "المسؤولية" ، نستخدم كلمة "قلق" للإشارة إلى مستوى أعلى من التجريد وغرض أوسع للحاوية مقارنة بفئة OOP. وإذا كان هدف SRP هو وجود سبب واحد فقط للتغيير ، فإن لدى SCP رغبة في توسيع إمكانيات إعادة استخدام الحاويات واستبدالها. باتباع SRP وإنشاء حاوية تحل مهمة واحدة وتجعلها مكتملة من الناحية الوظيفية ، فإنك تزيد من فرص إعادة استخدام صورة هذه الحاوية في سياقات التطبيق المختلفة.
ينص مبدأ SCP على أن كل حاوية يجب أن تحل مهمة واحدة وتؤديها بشكل جيد. علاوة على ذلك ، يتم تحقيق SCP في عالم الحاويات بسهولة أكبر من SRP في عالم OOP ، لأن الحاويات عادة ما تؤدي عملية واحدة ، وفي معظم الوقت تحل هذه العملية مهمة واحدة.
إذا كان على microservice حاوية حل العديد من المشاكل في وقت واحد ، ثم يمكن تقسيمها إلى حاويات مهمة واحدة ودمجها في جراب واحد (وحدات نشر منصة حاوية) باستخدام قوالب جانبية وحاويات البداية. بالإضافة إلى ذلك ، تُسهل SCP استبدال الحاوية القديمة (مثل خادم الويب أو وسيط الرسائل) بحاوية جديدة تحل المشكلة نفسها ، لكنها عززت الوظائف أو المقاييس بشكل أفضل.
مبدأ راحة المراقبة (مبدأ المراقبة العالية ، HOP)
عند استخدام الحاويات كطريقة موحدة لتعبئة وإطلاق التطبيقات ، تُعتبر التطبيقات نفسها "صندوقًا أسود". ومع ذلك ، إذا كانت هذه حاويات سحابية ، فيجب عليها أن توفر لوقت التشغيل واجهات برمجة تطبيقات خاصة لمراقبة صحة الحاويات واتخاذ التدابير المناسبة إذا لزم الأمر. بدون هذا ، لن يكون من الممكن توحيد أتمتة تحديث الحاويات وإدارة دورة حياتها ، والتي بدورها ستؤدي إلى تفاقم استقرار نظام البرنامج وسهولة استخدامه.
في الممارسة العملية ، يجب أن يحتوي تطبيق الحاوية ، على الأقل ، على واجهة برمجة التطبيقات لأنواع مختلفة من الفحوصات الصحية: اختبارات الثبات واختبارات الاستعداد. إذا كان التطبيق يدعي أنه أكثر من ذلك ، فعليه توفير وسائل أخرى لمراقبة حالته. على سبيل المثال ، تسجيل الأحداث الهامة من خلال STDERR و STDOUT لتجميع السجلات باستخدام Fluentd و Logstash وغيرها من الأدوات المشابهة. بالإضافة إلى التكامل مع مكتبات التتبع وجمع المقاييس مثل OpenTracing و Prometheus ، إلخ.
بشكل عام ، لا يزال من الممكن اعتبار التطبيق "مربعًا أسود" ، ولكن في نفس الوقت يجب أن يكون مجهزًا بجميع واجهات برمجة التطبيقات التي يحتاجها النظام لرصده وإدارته بأفضل طريقة.
مبدأ توافق دورة الحياة (LCP)
LCP هو نقيض HOP. إذا ذكرت HOP أن الحاوية يجب أن توفر النظام الأساسي مع واجهات برمجة التطبيقات للقراءة ، فإن LCP يتطلب أن يكون التطبيق قادرًا على تلقي المعلومات من النظام الأساسي. علاوة على ذلك ، يجب ألا تتلقى الحاوية الأحداث فحسب ، بل يجب أن تتكيف معها ، بمعنى آخر ، تستجيب لها. ومن هنا جاء اسم المبدأ ، والذي يمكن اعتباره متطلبًا لتزويد النظام الأساسي بواجهة برمجة تطبيقات للكتابة.
تحتوي الأنظمة الأساسية على أنواع مختلفة من الأحداث التي تساعد في إدارة دورة حياة الحاوية. ولكن الأمر متروك للتطبيق لتحديد أي منهم يجب إدراكه وكيفية الرد عليه.
من الواضح أن بعض الأحداث أكثر أهمية من غيرها. على سبيل المثال ، إذا كان التطبيق لا يتسامح مع إيقاف تشغيل الطوارئ ، فإنه ملزم بتلقي إشارة: إنهاء رسائل (SIGTERM) وبدء إجراء الإنهاء في أقرب وقت ممكن من أجل التقاط الإشارة: القتل (SIGKILL) التي تأتي بعد SIGTERM.
بالإضافة إلى ذلك ، يمكن أن تكون الأحداث مثل PostStart و PreStop مهمة لدورة حياة التطبيق. على سبيل المثال ، بعد تشغيل التطبيق ، قد يستغرق الأمر "بعض الوقت" للاحماء قبل أن يتمكن من الاستجابة للطلبات. أو يجب على التطبيق بطريقة ما تحرير الموارد عند إيقاف التشغيل.
مبدأ ثبات صورة الحاوية (مبدأ ثبات الصورة ، IIP)
من المقبول عمومًا أن التطبيقات ذات الحاوية يجب أن تظل دون تغيير بعد التجميع ، حتى لو كانت تعمل في بيئات مختلفة. يتضمن هذا الحاجة إلى تخزين البيانات في وقت التشغيل في وقت التشغيل (بمعنى آخر ، استخدم الأدوات الخارجية لهذا الغرض) ، بالإضافة إلى الاعتماد على التكوينات الخارجية التي تم تكوينها لبيئة تشغيل محددة ، بدلاً من تعديل أو إنشاء حاويات فريدة لكل بيئة. بعد أي تغييرات على التطبيق ، يجب إعادة تجميع صورة الحاوية ونشرها في جميع البيئات المستخدمة. بالمناسبة ، عند إدارة أنظمة تكنولوجيا المعلومات ، يتم استخدام مبدأ مشابه ، يُعرف باسم مبدأ ثبات الخوادم والبنية التحتية.
الهدف من IIP هو منع إنشاء صور حاوية منفصلة لبيئات وقت التشغيل المختلفة واستخدام نفس الصورة في كل مكان جنبًا إلى جنب مع التكوين المناسب لبيئة محددة. يسمح لك اتباع هذا المبدأ بتنفيذ مثل هذه الممارسات الهامة من وجهة نظر أتمتة الأنظمة السحابية مثل التراجع عن التحديثات السابقة للتطبيق.
مبدأ التخلص من العمليات (PDP)
واحدة من أهم خصائص الحاوية هي الزوال: يتم إنشاء مثيل الحاوية بسهولة وتدميرها بسهولة ، بحيث يمكن استبدالها بسهولة بمثيل آخر في أي وقت. يمكن أن يكون هناك العديد من الأسباب لمثل هذا الاستبدال: فشل اختبار الصحة ، وتوسيع نطاق التطبيق ، والنقل إلى مضيف آخر ، أو استنفاد موارد المنصة ، أو حالات أخرى.
نتيجة لذلك ، يجب أن تحافظ تطبيقات الحاوية على حالتها باستخدام بعض الوسائل الخارجية ، أو استخدام الدوائر الموزعة الداخلية مع التكرار لهذا الغرض. بالإضافة إلى ذلك ، يجب أن يتم تشغيل التطبيق بسرعة وإغلاقه بسرعة ، ويكون مستعدًا لفشل الأجهزة المفاجئ.
إحدى الممارسات التي تساعد على تنفيذ هذا المبدأ هي إنشاء حاويات صغيرة. يمكن أن تختار البيئات السحابية مضيفًا تلقائيًا لبدء تشغيل مثيل الحاوية ، وبالتالي كلما كانت الحاوية أصغر ، كلما بدأ تشغيلها بشكل أسرع - سيتم ببساطة نسخها إلى المضيف الهدف عبر الشبكة بشكل أسرع.
مبدأ الاحتواء الذاتي (S-CP)
وفقًا لهذا المبدأ ، في مرحلة التجميع ، يتم تضمين جميع المكونات الضرورية في الحاوية. يجب أن تكون الحاوية مبنية على توقع أن يحتوي النظام على نواة Linux نظيفة فقط ، لذلك يجب وضع جميع المكتبات الإضافية اللازمة في الحاوية نفسها. يجب أيضًا تحديد موقع الأشياء ، مثل وقت تشغيل لغة البرمجة المقابلة ومنصة التطبيق (إذا لزم الأمر) والتبعيات الأخرى التي ستكون مطلوبة أثناء تشغيل تطبيق الحاوية.
يتم إجراء استثناءات فقط للتكوينات التي تختلف من بيئة إلى أخرى ، ويجب توفيرها في وقت التشغيل ، على سبيل المثال من خلال Kubernetes ConfigMap.
يمكن أن يتضمن التطبيق عدة مكونات حاويات ، على سبيل المثال ، حاوية DBMS منفصلة كجزء من تطبيق حاوية الويب. وفقًا لمبدأ S-CP ، لا ينبغي دمج هذه الحاويات في حاوية واحدة ، ولكن يجب صنعها بحيث تحتوي حاوية DBMS على كل ما هو ضروري لقاعدة البيانات للعمل ، وتحتوي حاوية تطبيق الويب على كل ما هو ضروري لتطبيق الويب ، خادم الويب نفسه . نتيجة لذلك ، في وقت التشغيل ، ستعتمد حاوية تطبيق الويب على حاوية DBMS والوصول إليها حسب الحاجة.
مبدأ حجز وقت التشغيل (RCP)
يحدد مبدأ S-CP كيفية تجميع الحاوية وما يجب أن يحتوي عليه ملف الصورة الثنائية. لكن الحاوية ليست مجرد "الصندوق الأسود" ، الذي يحتوي على خاصية واحدة فقط - حجم الملف. في وقت التشغيل ، تحصل الحاوية على أبعاد أخرى: مقدار الذاكرة المستخدمة ، ووقت المعالج ، وموارد النظام الأخرى.
وهنا مبدأ RCP مفيد ، حيث يجب أن تقوم الحاوية بقطع رأس متطلباتها لموارد النظام ونقلها إلى النظام الأساسي. من خلال وجود ملفات تخصيص الموارد لكل حاوية (مقدار موارد وحدة المعالجة المركزية والذاكرة والشبكة ونظام القرص التي يحتاجها) ، يمكن للنظام أن يؤدي على النحو الأمثل الجدولة و autoscaling وإدارة قدرات تكنولوجيا المعلومات ودعم مستويات SLA للحاويات.
بالإضافة إلى تلبية متطلبات موارد الحاوية ، من المهم أيضًا ألا يتجاوز التطبيق الإطار المحدد بواسطةه. خلاف ذلك ، إذا كان هناك نقص في الموارد ، فمن المرجح أن تدرجه المنصة في قائمة التطبيقات التي تحتاج إلى مقاطعتها أو ترحيلها.
عند الحديث عن التركيز على السحابة ، فإننا نعني بشكل أساسي الطريقة التي نعمل بها.
أعلاه ، قمنا بصياغة عدد من المبادئ العامة التي تضع الأساس المنهجي لبناء تطبيقات حاوية عالية الجودة للبيئات السحابية.
لاحظ أنه بالإضافة إلى هذه المبادئ العامة ، ستحتاج أيضًا إلى أساليب وتقنيات إضافية متقدمة للتعامل مع الحاويات. بالإضافة إلى ذلك ، لدينا بعض التوصيات القصيرة الأكثر تحديدًا والتي يجب تطبيقها (أو عدم تطبيقها) اعتمادًا على الموقف:
ندوة عبر الإنترنت على الإصدار الجديد من OpenShift Container Platform - 411 يونيو في 11.00
ما سوف تتعلمه:
- غير قابل للتغيير ريد هات المؤسسة لينكس CoreOS
- فتح شبكة الخدمة
- إطار المشغل
- إطار Knative