يتم إنشاء التطبيقات "الموجهة نحو السحابة" (السحابة الأصلية) أو التطبيقات "السحابية" بشكل خاص للعمل في البنى التحتية السحابية. عادة ما يتم بناؤها كمجموعة من الخدمات الصغيرة المقترنة بشكل فضفاض والمعبأة في حاويات ، والتي بدورها تدار بواسطة منصة سحابية. هذه التطبيقات آمنة من الفشل افتراضيًا ، مما يعني أنها تعمل بشكل موثوق وتتوسع حتى في مواجهة الإخفاقات الشديدة على مستوى البنية التحتية. الجانب العكسي للعملة هو مجموعات القيود (العقود) التي تفرضها المنصة السحابية على تطبيقات الحاويات حتى تتمكن من إدارتها تلقائيًا.
إدراكًا تامًا لضرورة وأهمية الانتقال إلى السحابة ، لا تزال العديد من المؤسسات لا تعرف من أين تبدأ. في هذا المنشور ، سنلقي نظرة على عدد من المبادئ التي ، عند تطوير التطبيقات المعبأة في حاويات ، ستسمح لك بإدراك إمكانات الأنظمة الأساسية السحابية وتحقيق تشغيل موثوق به وتوسيع نطاق التطبيقات حتى مع الإخفاقات الشديدة على مستوى البنية التحتية لتكنولوجيا المعلومات. الهدف النهائي للمبادئ الموضحة هنا هو معرفة كيفية إنشاء تطبيقات يمكن إدارتها تلقائيًا بواسطة الأنظمة الأساسية السحابية مثل Kubernetes.
مبادئ تصميم البرمجيات
في عالم البرمجة ، المبادئ هي قواعد عامة إلى حد ما يجب مراعاتها عند تطوير البرمجيات. يمكن استخدامها مع أي لغة برمجة. لكل مبدأ أهدافه الخاصة ، والتي تتحقق عادة من خلال الأنماط والممارسات. هناك أيضًا عدد من المبادئ الأساسية لإنشاء برامج عالية الجودة ، والتي يتبعها الباقي. فيما يلي بعض الأمثلة على المبادئ الأساسية:
- (أبقها بسيطة ، غبية) - لا تعقد ؛
- (لا تكرر نفسك) - لا تكرر نفسك ؛
- (لن تحتاجه) - لا تصنع شيئًا ليس هناك حاجة فورية له ؛
- (فصل الاهتمامات) - لتقاسم المسؤوليات.
كما ترى ، لا تحدد هذه المبادئ أي قواعد محددة ، ولكنها تنتمي إلى فئة ما يسمى باعتبارات الفطرة السليمة القائمة على الخبرة العملية ، والتي يشاركها العديد من المطورين والتي يشيرون إليها بانتظام.
بالإضافة إلى ذلك ، هناك - مجموعة من المبادئ الخمسة الأولى للبرمجة والتصميم الكائني ، صاغها روبرت مارتن. يتضمن SOLID مبادئ تكميلية عامة ومفتوحة للتفسير والتي - عند تطبيقها معًا - تساعد في إنشاء أنظمة برمجية أفضل وصيانتها بشكل أفضل على المدى الطويل.
تنتمي مبادئ SOLID إلى عالم OOP وقد تمت صياغتها بلغة المفاهيم والمفاهيم مثل الفئات والواجهات والميراث. عن طريق القياس ، بالنسبة للتطبيقات السحابية ، يمكن أيضًا صياغة مبادئ التطوير ، ولن يكون سوى العنصر الأساسي هنا فئة ، بل حاوية. باتباع هذه المبادئ ، يمكنك إنشاء تطبيقات حاويات تخدم بشكل أفضل أهداف وغايات الأنظمة الأساسية السحابية مثل Kubernetes.
الحاويات القائمة على السحابة: نهج القبعة الحمراء
اليوم ، يمكن تعبئة أي تطبيق تقريبًا بسهولة نسبيًا في حاويات. ولكن من أجل أتمتة التطبيقات وتنظيمها بشكل فعال داخل منصة سحابية مثل Kubernetes ، يلزم بذل جهود إضافية.
تم استخدام المنهجية التالية كأساس للأفكار والعديد من الأعمال الأخرى في جوانب مختلفة لبناء تطبيقات الويب ، من إدارة كود المصدر إلى نماذج القياس. تنطبق المبادئ الموضحة فقط على تطوير التطبيقات المعبأة في حاويات والتي تم إنشاؤها فوق الخدمات المصغرة والمصممة للأنظمة الأساسية السحابية مثل Kubernetes. العنصر الأساسي في مناقشتنا هو صورة الحاوية ، ووقت التشغيل المستهدف للحاويات هو منصة تزامن الحاوية. الغرض من المبادئ المقترحة هو إنشاء حاويات يمكن من أجلها ، في معظم منصات التنسيق ، أتمتة مهام الجدولة (الجدولة - اختيار مضيف لتشغيل مثيل الحاوية) ، والتحجيم والمراقبة. يتم تقديم المبادئ في أي ترتيب معين.
مبدأ الاهتمام الفردي (SCP)
هذا المبدأ مشابه من نواح كثيرة لمبدأ المسؤولية الفردية. ) ، وهي جزء من مجموعة SOLID وتنص على أن كل كائن يجب أن يتحمل مسؤولية واحدة ، ويجب أن تكون هذه المسؤولية مغلفة بالكامل في فئة. جوهر برنامج SRP هو أن كل مسؤولية هي سبب للتغيير ، ويجب أن يكون للفصل سبب واحد فقط للتغيير.
في SCP ، بدلاً من كلمة "مسؤولية" (مسؤولية) ، نستخدم كلمة "مهمة" (قلق) للإشارة إلى مستوى أعلى من التجريد والغرض الأوسع للحاوية مقارنة بفئة OOP. وإذا كان الهدف من SRP هو الحصول على سبب واحد فقط للتغيير ، فإن الرغبة من وراء SCP هي توسيع إمكانيات إعادة استخدام الحاويات واستبدالها. من خلال اتباع SRP وإنشاء حاوية تقوم بشيء واحد وتقوم به بطريقة كاملة وظيفيًا ، فإنك تزيد من فرص إعادة استخدام صورة الحاوية في سياقات تطبيق مختلفة.
ينص مبدأ SCP على أن كل حاوية يجب أن تحل مهمة واحدة وتقوم بها بشكل جيد. علاوة على ذلك ، من الأسهل تحقيق SCP في عالم الحاويات مقارنة بـ SRP في عالم OOP ، نظرًا لأن الحاويات عادةً ما تشغل عملية واحدة ، وفي معظم الأحيان تحل هذه العملية مهمة واحدة.
إذا احتاجت الخدمة المصغرة المعبأة في حاويات إلى حل عدة مهام في وقت واحد ، فيمكن تقسيمها إلى حاويات ذات مهمة واحدة ودمجها في جراب واحد (وحدة نشر منصة الحاوية) باستخدام قوالب جانبية وحاويات init. بالإضافة إلى ذلك ، يسهل برنامج SCP استبدال حاوية قديمة (مثل خادم ويب أو وسيط رسائل) بأخرى جديدة تؤدي نفس المهمة ولكن بها وظائف أو مقاييس أكثر بشكل أفضل.
مبدأ المراقبة العالية (HOP)
عند استخدام الحاويات كطريقة موحدة لحزم التطبيقات وتشغيلها ، يتم التعامل مع التطبيقات نفسها على أنها "صندوق أسود". ومع ذلك ، إذا كانت حاويات سحابية ، فيجب عليهم توفير واجهات برمجة تطبيقات محددة لوقت التشغيل لمراقبة صحة الحاويات واتخاذ الإجراء المناسب إذا لزم الأمر. بدون ذلك ، لن يكون من الممكن توحيد أتمتة تحديث الحاويات وإدارة دورة حياتها ، والتي بدورها ستؤدي إلى تفاقم استقرار نظام البرنامج وقابليته للاستخدام.
من الناحية العملية ، يجب أن يكون للتطبيق المعبأ في حاويات على الأقل واجهة برمجة تطبيقات لأنواع مختلفة من الفحوصات الصحية: اختبارات الفعالية واختبارات الجاهزية. إذا طالب أحد الطلبات بأكثر من ذلك ، يجب أن يوفر وسائل أخرى لمراقبة حالته. على سبيل المثال ، تسجيل الأحداث المهمة عبر STDERR و STDOUT لتسجيل التجميع باستخدام Fluentd و Logstash وأدوات أخرى مماثلة. بالإضافة إلى التكامل مع مكتبات التتبع والمقاييس مثل OpenTracing و Prometheus وما إلى ذلك.
بشكل عام ، لا يزال من الممكن اعتبار التطبيق "صندوقًا أسود" ، ولكن يجب تزويده بجميع واجهات برمجة التطبيقات التي يحتاجها النظام الأساسي من أجل مراقبته وإدارته بأفضل طريقة ممكنة.
مبدأ توافق دورة الحياة (LCP)
LCP هو نقيض HOP. بينما يقول HOP أن الحاوية يجب أن توفر واجهات برمجة التطبيقات للقراءة إلى النظام الأساسي ، يتطلب LCP أن يكون التطبيق قادرًا على قراءة المعلومات من النظام الأساسي. علاوة على ذلك ، لا ينبغي أن تستقبل الحاوية الأحداث فحسب ، بل يجب أن تتكيف معها أيضًا. ومن هنا جاء اسم المبدأ ، والذي يمكن اعتباره مطلبًا لتوفير واجهات برمجة التطبيقات (APIs) للكتابة على النظام الأساسي.
تحتوي الأنظمة الأساسية على أنواع مختلفة من الأحداث للمساعدة في إدارة دورة حياة الحاوية. لكن الأمر متروك للتطبيق ليقرر أي منهم يدرك وكيف يتفاعل.
من الواضح أن بعض الأحداث أهم من غيرها. على سبيل المثال ، إذا كان التطبيق لا يتسامح مع التعطل جيدًا ، فيجب عليه قبول الإشارة: إنهاء الرسائل (SIGTERM) والبدء في إجراءات الإنهاء الخاصة به في أقرب وقت ممكن من أجل أن يكون في الوقت المناسب للإشارة: اقتل (SIGKILL) الذي يأتي بعد SIGTERM .
بالإضافة إلى ذلك ، يمكن أن تكون الأحداث مثل PostStart و PreStop مهمة لدورة حياة التطبيق. على سبيل المثال ، بعد بدء تشغيل أحد التطبيقات ، قد يستغرق الأمر قدرًا معينًا من الوقت "للإحماء" قبل أن يتمكن من الاستجابة للطلبات. أو يجب أن يقوم التطبيق بإصدار الموارد بطريقة خاصة عند إيقاف تشغيله.
مبدأ ثبات صورة الحاوية (مبدأ ثبات الصورة ، IIP)
من المقبول عمومًا أن تظل التطبيقات المعبأة في حاويات كما هي بعد بنائها ، حتى لو تم تشغيلها في بيئات مختلفة. هذا يستلزم الحاجة إلى خارجية تخزين بيانات وقت التشغيل (بمعنى آخر ، استخدام أدوات خارجية للقيام بذلك) ، والاعتماد أيضًا على التكوينات الخارجية الخاصة بوقت التشغيل ، بدلاً من تعديل أو إنشاء حاويات فريدة لكل بيئة. بعد إجراء أي تغييرات على التطبيق ، يجب إعادة بناء صورة الحاوية ونشرها في جميع البيئات المستخدمة. بالمناسبة ، عند إدارة أنظمة تكنولوجيا المعلومات ، يتم استخدام مبدأ مشابه ، يُعرف باسم مبدأ ثبات الخوادم والبنية التحتية.
الهدف من IIP هو منع إنشاء صور حاوية منفصلة لبيئات وقت تشغيل مختلفة واستخدام نفس الصورة في كل مكان جنبًا إلى جنب مع التكوين المناسب الخاص بالبيئة. يتيح لك اتباع هذا المبدأ تنفيذ مثل هذه الممارسات المهمة من وجهة نظر أتمتة الأنظمة السحابية مثل التراجع (التراجع) والتراجع (التراجع) لتحديثات التطبيق.
مبدأ التخلص من العملية (PDP)
إحدى أهم خصائص الحاوية هي طبيعتها سريعة الزوال: يمكن بسهولة إنشاء مثيل للحاوية وتدميرها بسهولة ، بحيث يمكن استبدالها بسهولة بمثيل آخر في أي وقت. يمكن أن يكون هناك العديد من الأسباب لمثل هذا الاستبدال: فشل اختبار الصحة ، أو توسيع نطاق التطبيق ، أو النقل إلى مضيف آخر ، أو استنفاد موارد النظام الأساسي ، أو مواقف أخرى.
نتيجة لذلك ، يجب أن تخزن التطبيقات المعبأة في حاويات حالتها باستخدام بعض الوسائل الخارجية ، أو تستخدم مخططات داخلية موزعة زائدة عن الحاجة لهذا الغرض. بالإضافة إلى ذلك ، يجب أن يبدأ التطبيق وينتهي بسرعة ، والاستعداد لفشل فادح مفاجئ في الأجهزة.
تتمثل إحدى الممارسات للمساعدة في تنفيذ هذا المبدأ في الحفاظ على الحاويات صغيرة. يمكن للبيئات السحابية أن تختار تلقائيًا مضيفًا لتشغيل مثيل الحاوية عليه ، لذلك كلما كان حجم الحاوية أصغر ، زادت سرعة بدء تشغيله - سيتم نسخه إلى المضيف الهدف عبر الشبكة بشكل أسرع.
مبدأ الاحتواء الذاتي (S-CP)
وفقًا لهذا المبدأ ، في مرحلة التجميع ، يتم تضمين جميع المكونات الضرورية في الحاوية. يجب بناء الحاوية على افتراض أن النظام يحتوي فقط على نواة Linux نقية ، لذلك يجب وضع جميع المكتبات الإضافية الضرورية في الحاوية نفسها. يجب أن تحتوي أيضًا على أشياء مثل وقت تشغيل لغة البرمجة المناسبة ، ومنصة التطبيق (إذا لزم الأمر) ، والاعتمادات الأخرى التي ستكون مطلوبة أثناء تشغيل التطبيق الحاوية.
يتم إجراء الاستثناءات فقط للتكوينات ، والتي تختلف من بيئة إلى أخرى ، ويجب توفيرها في وقت التشغيل ، على سبيل المثال ، من خلال Kubernetes ConfigMap.
يمكن أن يشتمل التطبيق على مكونات متعددة في حاويات ، مثل حاوية DBMS منفصلة كجزء من تطبيق ويب حاوية. وفقًا لمبدأ S-CP ، لا ينبغي دمج هذه الحاويات في واحدة ، ولكن يجب تصنيعها بحيث تحتوي حاوية DBMS على كل ما هو ضروري لتشغيل قاعدة البيانات ، وتحتوي حاوية تطبيق الويب على كل ما هو ضروري لتشغيل الويب التطبيق ، نفس خادم الويب. نتيجة لذلك ، في وقت التشغيل ، ستعتمد حاوية تطبيق الويب على حاوية نظام إدارة قواعد البيانات والوصول إليها حسب الحاجة.
مبدأ الحبس في وقت التشغيل (RCP)
يحدد مبدأ S-CP كيفية بناء الحاوية وما يجب أن يحتويه ملف الصورة الثنائية. لكن الحاوية ليست مجرد "صندوق أسود" له خاصية واحدة فقط - حجم الملف. في وقت التشغيل ، تكتسب الحاوية أيضًا أبعادًا أخرى: مقدار الذاكرة المستخدمة ووقت المعالج وموارد النظام الأخرى.
وهنا يأتي مبدأ RCP في متناول اليد ، حيث يجب على الحاوية قطع رأس متطلباتها من موارد النظام ونقلها إلى النظام الأساسي. من خلال وجود ملفات تعريف موارد لكل حاوية (مقدار موارد وحدة المعالجة المركزية والذاكرة والشبكة والقرص التي تحتاجها) ، يمكن للنظام الأساسي إرسال وقياس تلقائي على النحو الأمثل ، وإدارة سعة تكنولوجيا المعلومات ، والحفاظ على مستويات اتفاقية مستوى الخدمة للحاويات.
بالإضافة إلى تلبية متطلبات الموارد للحاوية ، من المهم أيضًا ألا يتجاوز التطبيق الحدود التي أشار إليها بنفسه. خلاف ذلك ، عند حدوث نقص في الموارد ، من المرجح أن يقوم النظام الأساسي بإدراجه في قائمة التطبيقات التي يجب مقاطعتها أو ترحيلها.
عندما نتحدث عن التركيز على السحابة ، فإننا نعني بشكل أساسي الطريقة التي نعمل بها.
أعلاه ، قمنا بصياغة عدد من المبادئ العامة التي تحدد الأساس المنهجي لبناء تطبيقات حاويات عالية الجودة للبيئات السحابية.
لاحظ أنه بالإضافة إلى هذه المبادئ العامة ، ستحتاج أيضًا إلى طرق وتقنيات متقدمة إضافية للعمل مع الحاويات. بالإضافة إلى ذلك ، لدينا بعض الإرشادات القصيرة التي تكون أكثر تحديدًا ويجب تطبيقها (أو لا يتم تطبيقها) اعتمادًا على الموقف:
- حاول تقليل حجم الصور: قم بإزالة الملفات المؤقتة ولا تقم بتثبيت الحزم غير الضرورية - فكلما كان حجم الحاوية أصغر ، زادت سرعة تجميعها ونسخها إلى المضيف الهدف عبر الشبكة.
- استهدف معرفات مستخدم عشوائية: لا تستخدم الأمر sudo أو أي معرف مستخدم خاص لبدء الحاويات الخاصة بك.
- تسمية المنافذ المهمة: يمكن أيضًا تعيين أرقام المنافذ في وقت التشغيل ، ولكن من الأفضل تحديدها باستخدام الأمر EXPOSE حتى يتمكن الأشخاص والبرامج الأخرى من استخدام صورك بسهولة أكبر.
- تخزين البيانات الثابتة على وحدات التخزين: يجب كتابة البيانات التي يجب أن تبقى بعد تدمير الحاوية إلى وحدات التخزين.
- اكتب البيانات الوصفية للصور: تجعل العلامات والتسميات والتعليقات التوضيحية الصور أسهل في الاستخدام - سيشكرك المطورون الآخرون.
- مزامنة المضيف والصور: تتطلب بعض التطبيقات المعبأة في حاويات مزامنة الحاوية مع المضيف بناءً على سمات معينة ، مثل الوقت أو معرف الجهاز.
- في الختام ، نشارك الأنماط وأفضل الممارسات التي ستساعدك على تنفيذ المبادئ المذكورة أعلاه بشكل أكثر فعالية:
11 يونيو الساعة 11.00
ماذا ستتعلم:
- نظام Red Hat Enterprise Linux CoreOS الثابت
- شبكة خدمة OpenShift
- إطار المشغل
- إطار Knative
المصدر: www.habr.com