DEVOXX المملكة المتحدة. Kubernetes في الإنتاج: النشر الأزرق / الأخضر ، والتلقائي ، وأتمتة النشر. الجزء الأول

Kubernetes هي أداة رائعة لتشغيل حاويات Docker في بيئة إنتاج مجمعة. ومع ذلك ، هناك مهام يتعذر على Kubernetes حلها. عند النشر بشكل متكرر في بيئة إنتاج ، نحتاج إلى نشر أزرق / أخضر مؤتمت بالكامل لتجنب وقت التوقف في هذه العملية ، والذي يتطلب أيضًا طلبات HTTP خارجية وتحميل SSL. يتطلب هذا التكامل مع موازن التحميل مثل ha-proxy. مهمة أخرى هي التحجيم شبه التلقائي لمجموعة Kubernetes نفسها عند العمل في السحابة ، على سبيل المثال ، التخفيض الجزئي لمقياس الكتلة في الليل.

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

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



اليوم سنتحدث عن Kubernetes ، على وجه الخصوص ، عن التشغيل الآلي لها. سنلقي نظرة على أساسيات هذا النظام ، ثم ننتقل إلى كيفية دمج Kubernetes في المشاريع في مرحلة التطوير. اسمي بول ، أنا من هولندا ، أعمل في شركة تدعى Luminis Technologies وأنا مؤلف كتاب "Designing Cloud Applications with OSGi" و "Modulating Java 9". ما سأتحدث عنه يختلف تمامًا عن موضوع هذه الكتب.
في العام الماضي ، قضيت معظم وقتي في العمل على منصة بنية تحتية تعتمد على Kubernetes وإنشاء أدوات لها ، بشكل رئيسي على Golang. بالإضافة إلى ذلك ، ما زلت أواصل العمل على كتاب Java 9. هوايتي هي رفع الأثقال. لذلك دعونا نبدأ العمل.

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



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

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



هناك مجموعة كاملة من عقد عمل العقدة التي تحتوي على قرون Pods مع حاويات Docker ، وتخزين موزع إلخ. العقد هي المكان الذي ستعمل فيه حاوياتك. لا تعمل Kubernetes مع حاويات Docker مباشرة ، ولكنها تستخدم تجريدًا يسمى Pod لهذا الغرض. تطلق عقد العمل مجموعة من الحاويات ، وتتأكد العقدة الرئيسية من أنها تعمل. بالإضافة إلى ذلك ، هناك تخزين الموزع من نوع keyd-value ، والذي يخزن جميع المعلومات حول المجموعة. Etcd يتحمل الخطأ ، لذلك يتكون على الأقل من 3 عقد مستقلة. هذا يضمن أن المعالج يعمل دون فقدان الحالة.

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



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

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



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

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

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



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

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

لذلك ، عندما تريد البودات التواصل مع بعضها البعض ، فإنها لا تفعل ذلك مباشرة ، ولكن من خلال الخدمات ، باستخدام عناوين IP الثابتة هذه.



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



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



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

المفهوم المهم التالي الذي سيتم تقديمه هو مساحة الاسم Namespaces.



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

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



ترى ملفات تكوين yaml التي تحتاج إلى إنشائها لواجهة برمجة التطبيقات باستخدام الأمر kubectl. تظهر الشريحة التالية كيف يبدو ملف yaml النموذجي.



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

في أسفل الكود توجد خطوط تمثل مواصفات الموقد. يصف المنافذ وعقد التخزين واسم وصورة خادم الويب والمعلومات الأخرى اللازمة لحاوية Docker الخاصة بنا.

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

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

الآن سترى عرضًا توضيحيًا قصيرًا يوضح عمل kubectl ، وبعد ذلك سنتعمق في عمل موازن التحميل واستخدام واجهة برمجة التطبيقات. لذا ، أدخل الأمر kubectl get pods ، لكن النظام لا يعرض أي مداخن لأننا لم نقم بتشغيل أي شيء حتى الآن. بعد ذلك ، أدخل الأمر ls لعرض قائمة الملفات المتاحة.



الآن أدخل اسم الملف الأول من القائمة ويتم عرض ملف التكوين yaml ، على غرار الملف الذي نظرنا إليه للتو. دعونا نستخدم هذا الملف لإنشاء الموقد بكتابة kubectl إنشاء –f nginx-controller.yaml. نتيجة لذلك ، سنكون قد أنشأنا تحت. بتكرار الأمر kubectl get pods ، يمكنك أن ترى أن هذا يعمل.



ولكن هذا واحد فقط تحت. دعونا نحاول توسيع وحدة التحكم الخاصة بنا عن طريق إنشاء العديد من النسخ المتماثلة. للقيام بذلك ، أدخل الأمر kubectl scale rc nginx - replicas = 5 ، حيث rc هو وحدة تحكم النسخ المتماثل ، و 5 هو العدد المطلوب من المثيلات ، أو النسخ المتماثلة لوحدة التحكم هذه. ترى تقدم إنشاء الحاويات ، وإذا قمت بإعادة إدخال الأمر kubectl get pods بعد بضع ثوانٍ ، يمكنك أن ترى أن معظم الحاويات التي تم إنشاؤها قد بدأت العمل بالفعل.



وبالتالي ، قمنا بزيادة عدد المداخن أو النسخ المتماثلة التي تعمل في مجموعتنا إلى 5 نسخ. أيضًا ، على سبيل المثال ، يمكنك إلقاء نظرة على عنوان IP الذي تم إنشاؤه للنسخة المتماثلة الأولى عن طريق إدخال الأمر kubectl الذي يصف pod nginx-772ia. هذا هو عنوان IP الظاهري المرفق بهذه الحاوية المحددة.



سيتم توفير عمله من خلال الخدمات المذكورة أعلاه. دعونا نرى ما يحدث إذا قمت بتدمير إحدى النسخ المتماثلة العاملة ، لأنه على أي حال ، يجب علينا التأكد من عمل عدد معين من النسخ. أدخل الأمر kubectl delete pod nginx-772ia وأبلغ النظام أنه بموجب هذا المعرف تم حذفه. باستخدام الأمر kubectl get pods ، نرى أن 5 حالات تحكم تعمل مرة أخرى ، وبدلاً من النسخة المتماثلة البعيدة nginx-772ia ، ظهرت نسخة جديدة مع المعرف nginx-sunfn.



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

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

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

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



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

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

توضح الشريحة التالية كيف تتعامل عقدة موازن التحميل مع حركة مرور HTTPS الواردة ، ويقع الوكيل ha-ha على جهاز خارجي أو مجموعة من الآلات تقع خارج مجموعة Kubernetes. يوجد تحميل SSL هنا أيضًا. يكتشف الوكيل العناوين المطلوبة ثم يمرر حركة المرور إلى خدمات Kubernetes ، دون الاهتمام بعناوين IP للمداخن التي يمكن أن تتغير بمرور الوقت. بعد ذلك ، تقوم الخدمات بتمرير حركة المرور إلى منصات تشغيل ذات عناوين IP ديناميكية.



إذا كنت تستخدم AWS ، يمكنك استخدام مفهوم موازنة التحميل ELB. تعمل ميزة Load Load Balancing على إعادة توجيه حركة المرور إلى حالات أمازون الصحية لضمان استقرار التطبيق. هذه الآلية جيدة بشكل خاص إذا كنت بحاجة إلى قابلية موازنة التحميل.



في هذه الحالة ، يتم إرسال حركة المرور أولاً إلى خدمة AWS ، حيث يتم إلغاء تحميل طبقة المقابس الآمنة ، وبعد ذلك تدخل عقدة موازن تحميل ha-proxy.

يمكنك أن تفعل الشيء نفسه إذا كانت مجموعاتك داخل شبكة VPN افتراضية خاصة تمامًا. في هذه الحالة ، يضمن استخدام AWS ELB أمان النظام بشكل كامل. لا تحتاج إلى تنفيذ SSL بين المكونات المختلفة خارج الكتلة. الشيء الوحيد الذي سيتم ربطه بالعالم الخارجي هو وكيلنا.



من الناحية النظرية ، يبدو الأمر بسيطًا للغاية ، ولكن كيف يعمل في الواقع؟ كيف أقوم بإعداد وكيل ha-ha بحيث يعرف عن خدمات Kubernetes؟ إذا نظرت إلى ha-proxy بنفس الطريقة التي نعتبرها nginx ، فستلاحظ أنها لا تزال تستخدم ملفات التكوين الثابتة. لذلك إذا كنت ترغب في إضافة خلفية جديدة إليها ، والتي في هذه الحالة هي خدمات Kubernetes ، فنحن بحاجة إلى تغيير ملف التكوين ، وإعادة تحميل ha-proxy ، وبعد ذلك فقط سيعمل كل شيء كما ينبغي. بالطبع ، لا نريد القيام بذلك يدويًا. لذلك ، يمكنك استخدام أداة صغيرة مفتوحة المصدر تسمى Confd ، والتي تدير ملفات تكوين التطبيق المحلي باستخدام بيانات etcd. إذا حدثت تغييرات في مخزن البيانات الوصفية وما إلى ذلك ، يقوم Confd تلقائيًا بإنشاء قالب تكوين ،الذي يعيد تشكيل الوكيل ha وفقا لظروف العمل الجديدة.

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

26:00 دقيقة.

سيكون المتابعة قريبًا جدًا ...

القليل من الدعاية :)

أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك ، VPS السحابي للمطورين من $ 4.99 ، وهو نظير فريد من نوعه لخوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2697 v3 (6 نوى) 10GB DDR4 480GB SSD 1Gbps من $ 19 أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا و 40 جيجابايت DDR4).

Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ فقط لدينا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV من 199 دولارًا في هولندا!Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960GB SSD 1Gbps 100TB - من 99 دولار! اقرأ عن كيفية بناء مبنى البنية التحتية الفئة c باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟