Get best of the week

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

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

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

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



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

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



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

هذا هو REST ، لذلك يمكنك استخدام أي لغات وأدوات للعمل مع واجهة برمجة التطبيقات هذه ، ولكن مكتبات المستخدم ستسهل حياتك كثيرًا. كتب فريقي مكتبتين من هذا القبيل: واحدة لـ Java / OSGi وواحدة لـ Go. لا يتم استخدام الثاني في كثير من الأحيان ، ولكن على أي حال ، هذه الأشياء المفيدة تحت تصرفك. هم مشروع مفتوح المصدر مرخص جزئيا. هناك العديد من هذه المكتبات للغات مختلفة ، لذلك يمكنك اختيار أنسبها.



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

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

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

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

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



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



بعد أن يتحقق النظام من تشغيل جميع النسخ المتماثلة المحدثة ، سيقوم Deployer بتحديث التكوين واجتياز الرمز الصحيح ، الذي سيعيد تكوين الوكيل.



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



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

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

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



بعد أن أبلغت كل القرون عن "صحتها" ، يقوم Deployer بإنشاء عنصر تكوين جديد - التخزين الموزع إلخ ، والذي يتم استخدامه داخل Kubernetes ، بما في ذلك تخزين تكوين موازن التحميل. نكتب البيانات إلى etcd ، وأداة صغيرة ، confd ، تراقب etcd للبيانات الجديدة.

إذا وجد أي تغييرات في التكوين الأولي ، فإنه يقوم بإنشاء ملف إعدادات جديد ويمرره إلى الوكيل. في هذه الحالة ، تتم إعادة تشغيل ha-proxy دون فقدان أي اتصالات ويعالج الحمل بالخدمات الجديدة التي توفر الإصدار الجديد من تطبيقاتنا.



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



هذه أداة تنسيق توزيع Kubernetes مع الميزات التالية:

  • نشر أزرق / أخضر
  • إنشاء موازن تحميل خارجي ؛
  • إدارة واصف النشر
  • إدارة النشر الفعلي
  • الفحوصات الصحية أثناء الانتشار
  • تنفيذ متغيرات البيئة في القرون.

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

يضع بيانات تكوين موازن التحميل في etcd ، لذلك لا يمكنك استخدام ha-proxy مع دعم "خارج الصندوق" ، ولكن من السهل استخدام ملف تكوين الموازن الخاص بك. تم كتابة Amdatu Deployer في Go ، تمامًا مثل Kubernetes نفسها ، ومرخصة من قبل Apache.

قبل استخدام هذا الإصدار من الناشر ، استخدمت واصف النشر التالي ، الذي يحدد المعلمات التي أحتاجها.



أحد المعلمات الهامة لهذا الرمز هو تمكين علامة "useHealthCheck". نحتاج إلى الإشارة إلى أن الفحص الصحي مطلوب أثناء عملية النشر. يمكن إيقاف هذا الخيار عندما يستخدم النشر حاويات طرف ثالث لا تحتاج إلى التحقق منها. يشير هذا الواصف أيضًا إلى عدد النسخ المتماثلة وعنوان URL للواجهة الأمامية التي يحتاجها الوكيل. في النهاية توجد علامة مواصفات podspec pod ، والتي تستدعي Kubernetes للحصول على معلومات حول تكوين المنفذ والصورة وما إلى ذلك. هذا واصف بسيط إلى حد ما بتنسيق JSON.

أداة أخرى جزء من مشروع Amdatu مفتوح المصدر هي Deploymentctl. يحتوي على واجهة مستخدم لواجهة المستخدم لتكوين النشر ، وتخزين محفوظات النشر ويحتوي على رسائل ويب للرد من قبل المستخدمين والمطورين الخارجيين. لا يمكنك استخدام واجهة المستخدم ، لأن Amdatu Deployer نفسه هو REST API ، ولكن هذه الواجهة يمكن أن تجعل من السهل عليك النشر دون تضمين أي API. تمت كتابة Deploymentctl في OSGi / Vertx باستخدام Angular 2.

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



نقوم هنا بإنشاء خادم HTTP يستجيب فقط لـ / health ، لذا فإن هذا التطبيق يتحقق فقط من الفحص الصحي ولا شيء آخر. في حالة اجتياز الاختيار ، يتم استدعاء بنية JSON الموضحة أدناه. يحتوي على إصدار التطبيق الذي سيتم نشره بواسطة الناشر ، والرسالة التي تراها في أعلى الملف ، ونوع البيانات المنطقية المنطقية - سواء كان تطبيقنا يعمل أم لا.

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

لذلك دعونا نبدأ. أولاً ، نتحقق من وجود أي بودات قيد التشغيل باستخدام الأمر ~ kubectl get pods ، وإذا لم يكن هناك استجابة من عنوان URL للواجهة الأمامية ، فإننا نتأكد من عدم تنفيذ أي عمليات نشر حاليًا.



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



إذا كررت الأمر ~ kubectl get pods الآن ، يمكنك أن ترى أن النظام "يتجمد" لمدة 20 ثانية ، تحدث خلالها إعادة تهيئة الوكيل. بعد ذلك ، يبدأ من أسفل ، ويمكن رؤية النسخة المتماثلة لدينا في سجل النشر.



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



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



يُظهر الأمر ~ kubectl get pods أن نسختين من التطبيق قيد التشغيل حاليًا ، لكن الواجهة الأمامية تُظهر أننا ما زلنا نشغل الإصدار 1.



ينتظر موازن التحميل حتى يتم إجراء الفحص الصحي ، ثم يعيد توجيه حركة المرور إلى الإصدار الجديد. بعد 20 ثانية ، ننتقل إلى curl ونرى أننا نشرنا الآن الإصدار 2 من التطبيق ، وتمت إزالة الإصدار الأول.



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

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



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

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



سيقوم خادم إنشاء خادم البناء بإنشاء صورة Docker ولصقها في Docker Hub أو أي سجل آخر تستخدمه. يدعم Docker hub webhook ، لذا يمكننا بدء النشر عن بعد من خلال Deployer كما هو موضح أعلاه. وبالتالي ، يمكنك أتمتة نشر التطبيق بالكامل في الإنتاج المحتمل.

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



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

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



لذا سيتعين علينا رعاية العقد والقرون. يمكننا بسهولة توسيع نطاق إطلاق العقد الجديدة باستخدام AWS API وآلات مجموعة Scaling لتكوين عدد عقد عمل Kubernetes. يمكنك أيضًا استخدام cloud-init أو نص برمجي مشابه لتسجيل العقد في مجموعة Kubernetes.

يبدأ الجهاز الجديد في مجموعة Scaling ، ويبدأ نفسه كعقدة ، ويسجل في سجل المعالج ويبدأ العمل. بعد ذلك ، يمكنك زيادة عدد النسخ المتماثلة للاستخدام على العقد الناتجة. يتطلب تقليل الحجم مزيدًا من الجهد ، حيث تحتاج إلى التأكد من أن هذه الخطوة لن تؤدي إلى تدمير التطبيقات قيد التشغيل بالفعل بعد إيقاف تشغيل الأجهزة "غير الضرورية". لمنع هذا السيناريو ، تحتاج إلى إحضار العقد إلى الحالة "غير المجدولة". هذا يعني أن المجدول الافتراضي عند جدولة قرون DaemonSet سيتجاهل هذه العقد. لن يقوم المجدول بحذف أي شيء من هذه الخوادم ، ولكنه لن يطلق أي حاويات جديدة هناك. الخطوة التالية هي إزاحة عقدة التصريف ، أي نقل المداخن العاملة منها إلى جهاز آخر ، أو العقد الأخرى التي لديها سعة كافية لذلك.بعد التحقق من عدم وجود المزيد من الحاويات على هذه العقد ، يمكنك إزالتها من Kubernetes. بعد ذلك ، بالنسبة لـ Kubernetes ، يتوقفون ببساطة عن الوجود. بعد ذلك ، تحتاج إلى استخدام AWS API لتعطيل العقد أو الأجهزة غير الضرورية.
يمكنك استخدام Amdatu Scalerd ، وهي أداة أخرى مفتوحة المصدر تشبه API AWS. يوفر CLI لإضافة أو إزالة العقد في كتلة. ميزته المثيرة للاهتمام هي القدرة على تكوين المجدول باستخدام ملف json التالي.



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

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

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



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





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

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


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


أشكركم على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك 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 يورو مقابل سنت واحد؟

More articles:


All Articles