هل يقدم دوكر وكوبرنيتيس "أفضل هندسة معمارية"؟

مرحبًا ، لقد عدت بمقال آخر. لكن هذه المرة ، أنا في مزاج حل بعض الخرافات.

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

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

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

إذن في هذه المقالة ، سنسافر من الحياة الحقيقية إلى عمليات التطوير إلى الهندسة المعمارية ونعود إلى الحياة الحقيقية.

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

الخطوة الأولى من الحياة الحقيقية إلى سير العمل في التنمية

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

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

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

فكيف تم حل هذه المشكلة؟

الآن تم حل هذه المشكلة بمساعدة Docker و Kubernetes. كلاهما ظهر كالمسيح. حل مستوى التجريد والنهج الإيديولوجي حوالي 80٪ من المشكلة. العقل جيدا ، 80 ٪ هي نسبة جيدة جدا في قطاع التنمية. ال 20 ٪ لا يزال هناك واحد يحتاج إلى أن يكون عبقريا الإبداعية لحلها. ذلك يعتمد على نوع التطبيق وطريقة حلها.

عامل الميناء يحل مشكلة سير العمل في التنمية. يوفر Docker عملية بسيطة ويكفي لمعظم بيئات العمل.

مصدر الصورة: https://cdn-images-1.medium.com/max/800/0*nDrc_jeOKTMS7akB.

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

مقدمة في بيئة التطوير

بادئ ذي بدء ، يجب أن يتألف المشروع من ملف docker-compose.yml. تتمثل ميزة هذا الملف في أنه سيزيل عبء تشغيل التطبيق / الخدمة على الجهاز المحلي. المطور لا يحتاج إلى التفكير في الأمر. في الواقع ، مجرد أمر بسيط لرسو السفن يكفي لبدء تطبيقك. يعالج الأمر أيضًا التبعيات ، ويملأ قاعدة البيانات بتركيبات ، وتحميل الكود المحلي داخل الحاوية ، وتمكين تتبع الكود ، والاستجابة في المنفذ المتوقع.

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

الوقت للاختبار الآلي

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

مصدر الصورة: https://cdn-images-1.medium.com/max/800/0*B5Qn9D5W4lscB86h.

مثل الصندوق الأسود الأصلي ، يقوم الصندوق الأسود للحاوية بتخزين كل شيء. يتم تخزين جميع البيانات الثنائية ، 1 أو 0 ، إلخ في الصندوق الأسود. فكيف يحدث الأتمتة؟ إنه أمر سهل ، لديك مجموعة من الأوامر ويصف عامل الإرساء compost.yml جميع التبعيات. هذا يؤدي إلى الأتمتة والاختبار الموحد. ليست هناك حاجة للتركيز على تفاصيل التنفيذ.

تسليم النظم

مصدر الصورة: https://cdn-images-1.medium.com/max/800/0*DC5Ubn7Y5seJPeSO.

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

هناك خوارزمية لكل هذا. دعنا نسردها باستمرار.

(1) جمع الصور من Dockerfiles.

(2) استخدام مشروع الفوقية لتقديم الصور. يجب أن يتم تسليمها Kubernetes عبر Kube API. معلمات الإدخال المطلوبة هي:

(أ) نقطة نهاية Kube API

(ب) كائن سري يختلف باختلاف السياقات (محلي / صالة عرض / انطلاق / إنتاج)

أسماء النظام وعلامات صور Docker لهذه الأنظمة.

على سبيل المثال ، خذ بعين الاعتبار مشروع التعريف الذي يتكون من جميع الأنظمة والخدمات. وهذا يعني أن المشروع يصف ترتيب النظام البيئي ويصف أيضًا كيفية تسليم التحديثات إليه. لهذا ، سأستخدم Ansible playbooks للتكامل مع Kube API. ولكن ، هناك خيارات أخرى كذلك! عموما ، تحتاج إلى التفكير في اتجاه مركزي لإدارة الهندسة المعمارية. بمجرد أن تكون واثقًا من ذلك ، يمكنك إدارة الخدمات / الأنظمة بسهولة.

يلزم تثبيت بيئة في صالة العرض (للفحوصات اليدوية وتصحيح النظام) والتدريج (للبيئات القريبة من التكامل والتكامل) والإنتاج (البيئة الفعلية للمستخدم النهائي).

التسليم المستمر والتكامل

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

فما هو الحل؟ يجب أن تبدأ العملية عندما لا يكون هناك منافسة.

الخطوات:

(1) تحديث فرع الميزة إلى المنبع.

(2) بناء الصور.

(3) اختبار الصور المبنية.

(4) ابدأ وانتظر حتى يتم الانتهاء من الخطوة 2 ويتم تسليم الصور.

(5) في حالة فشل الخطوة 4 ، استرجع النظام البيئي إلى الخطوة السابقة.

(6) الجمع بين ميزة فرع في المنبع. أرسلها إلى المستودع.

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

تمنحك Kubernetes حرية نشر التحديثات في أجزاء. يمكن أن تبدأ اختبارات AB العديدة وتخضع لتحليل المخاطر. Kubernetes يفصل داخليا الخدمات والتطبيقات.

أنظمة التراجع

من بين بعض أهم قدرات إطار عمل معماري قوي ، تتمثل القدرة على التراجع. هناك عدد من الفروق الدقيقة الصريحة والضمنية. دعونا نلقي نظرة عليها:

(1) يجب أن تكون الخدمة قادرة على إعداد بيئتها وكذلك الاستعادة.

(2) إذا كان التراجع غير ممكن ، يجب أن تكون الخدمة متعددة الأشكال. يجب أن يدعم كل من الإصدارات القديمة والجديدة من التعليمات البرمجية.

(3) يجب أن يكون هناك توافق للخلف لأي خدمة بعد التراجع.

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

لذلك تحت أي ظروف يجب أن يتم تشغيل آلية الاستعادة؟

(1) عندما تكون النسبة المئوية لأخطاء التطبيق عالية بعد الإصدار.

(2) بمجرد بدء تلقي الإشارات من نقاط المراقبة الرئيسية.

(3) عندما تفشل اختبارات الدخان.

(4) ويمكن القيام به يدويا.

تدابير أمنية

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

الخطوة التالية ، من سير العمل في التطوير إلى البنية

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

الآن ، حان الوقت لتغيير الهيكل من متآلف إلى Microservices. إنه يوفر فوائد هائلة من الهندسة المعمارية الموجهة نحو الخدمة. على الأقل بالنسبة إلى Docker و Kubernetes ، من الخطأ أيديولوجيًا استخدام بنية متجانسة. سأناقش بالتأكيد بعض النقاط في بنية microservices. لمعرفة العمق في DevOps ، يرجى قراءة هذه المقالة على DevOps.

الآن ، سوف نناقش بسرعة المكونات الأساسية الرئيسية وحلول البنية الجيدة.

المكونات الحرجة

الرقم 1 - خدمة الهوية:

تشير خدمة microservice للهوية إلى "الهوية كخدمة microservice". الخدمات خفيفة الوزن. يوفر نمطية ويمكّن من مرونة التطبيق. خدمة microservice قوية ولها حق الوصول إلى جميع بيانات الملف الشخصي. إنه قادر على توفير كل ما هو مطلوب في صميم جميع التطبيقات.

إذا كنت تريد أن تكون عميلًا لمنصات المؤسسات الرئيسية مثل IBM و Google و Microsoft ، إلخ ، فستتم معالجة الوصول بواسطة خدمات البائع. ولكن ماذا لو كنت تريد الحل الخاص بك؟ ستساعدك القائمة الموجودة في القسم التالي في تحديد ذلك.

رقم 2 - توفير الخدمة الآلية:

الخدمات المبنية مستقلة عن بعضها البعض. وهذا يؤدي إلى سهولة التنمية وأخطاء أقل. كما أنه يساعد في البحث عن خدمات أخرى في نمط ديناميكي وآلي.

Kubernetes يقلل من الحاجة إلى مكونات إضافية. ولكن لا يزال يحتاج المرء إلى أتمتة إضافة آلات جديدة. فيما يلي قائمة بالأدوات:

(1) KOPS - يساعدك على تثبيت كتلة على AWS أو GCE.

(2) Teraform - يساعدك على إدارة البنية التحتية لأي بيئة.

(3) Ansible - عروض الأتمتة من أي نوع.

أنا شخصياً أوصيك بـ Ansible لأنه يساعدك على العمل مع كلا الخادمين وكذلك كائنات Kubernetes

رقم 3- بوابة مستودع وتتبع المهمة:

باستخدام مستودعات Git ، يمكن التعامل مع المهام بسهولة. الفكرة الأساسية هي امتلاك مستودع صغير. وهو بمثابة تعقب البيئة. يتضمن المحتوى نوع الإصدارات التي سيتم استخدامها لمختلف الخدمات. نظام التحكم في المصدر المفضل لهذا هو "بوابة".

يجب أن يكون هناك مكان عمل مناسب للعمل الجماعي وتخزين الكود لجميع المناقشات المهمة. إذا كنت تريد خدمة مجانية ، فانتقل إلى Redmine. آخر ، جيرا هي خدمة مدفوعة ومفيدة للغاية. بالنسبة لمستودع الشفرات ، يعد Gerrit خيارًا رائعًا مجانًا!

رقم 4- سجل عامل الميناء:

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

نظام إدارة الصور عامل ميناء مهم جدا. يجب أن يدعم النظام أيضًا وصول المستخدمين ومجموعة من المستخدمين. لهذا ، اختر حلًا سحابيًا أو بعض الخدمات المستضافة الخاصة. خيار جيد هو برنامج Vmware Harbour.

رقم 5 - CI / CD وتقديم الخدمات:

خدمة التكامل والتسليم المستمرة فقط هي التي تقوم بتوصيل المكونات التي تمت مناقشتها سابقًا. يشير التسليم المستمر إلى أن الخدمة بسيطة ومحرومة من أي منطق. يجب أن تتفاعل خدمة CI / CD فقط مع أحداث العالم الخارجي مثل التغييرات في مستودع git ، إلخ.

تعد خدمة التكامل مسؤولة عن الاختبار التلقائي للخدمة ، وتقديم الخدمات ، والتراجع ، وإزالة الخدمة ، وبناء الصور.

رقم 6- جمع السجلات وتحليلها:

في أي تطبيق microservice ، من المهم تتبع المشكلة. تتبع ممكن مع مساعدة من قطع الأشجار. لذا ، يمنحك التسجيل والمراقبة رؤية شاملة للنظام.

تتم إتاحة السجلات عن طريق كتابتها إلى STDOUT أو STDERR لعملية الجذر. يجب أن تكون بيانات السجلات متاحة عند الحاجة. يجب أن يحتوي أيضًا على سجلات من الماضي.

الرقم 7- التتبع والمراقبة والتنبيه:

تساعدك أدوات مثل Opentracing و Zipkin في فهم الخطأ. مثل أين ذهبت الخطأ؟ ستساعدك هذه الأدوات في الإجابة على مثل هذه الأسئلة. يحدث الفشل ويعد تعقبهم أمرًا مهمًا.

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

رقم 8- بوابة API مع الدخول الموحد:

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

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

رقم 9- حافلة الحدث:

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

رقم 10- قواعد البيانات والخدمات الحكومية:

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

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

العودة إلى الواقع ، من الهندسة المعمارية إلى الحياة الحقيقية

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

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

نعود الآن إلى عنوان هذا المقال. عامل الميناء و Kubernetes لديهم أفضل الهندسة المعمارية؟ الآن ، بالتأكيد "نعم". ولكن هذا قد يكون أفضل بنية في الوقت الحالي. نسعى جاهدين لتحقيق المزيد ، والسعي لبناء بنية أفضل ، أفضل من الأفضل!

أشارك بعض الروابط المفيدة معكم جميعًا.

Docker Article: Docker Tutorial: Container، VMs، and Docker for Beginners

Docker Video Tutorial: Docker Video Tutorial Series

Kubernetes المادة: الكتاب المقدس Kubernetes للمبتدئين والمطورين

Kubernetes Video Tutorial: Kubernetes Video Tutorial Series