"الخطر هو اسمي الأوسط"، كان أوستن باورز، وهو رجل عالمي غامض، يقول. لكن ما يحظى بتقدير كبير من قبل العملاء الخارقين وأجهزة المخابرات لا يناسب على الإطلاق خدمات الكمبيوتر، حيث الملل أفضل بكثير من الخطر.
كما أن Istio، جنبًا إلى جنب مع OpenShift وKubernetes، يجعل نشر الخدمات الصغيرة مملًا حقًا ويمكن التنبؤ به - وهذا رائع. سنتحدث عن هذا وأكثر من ذلك بكثير في المقالة الرابعة والأخيرة من سلسلة Istio.
عندما يكون الملل في محله
في حالتنا، يحدث الملل فقط في المرحلة النهائية، عندما يبقى فقط الجلوس ومشاهدة العملية. ولكن لهذا تحتاج إلى تكوين كل شيء أولاً، وهناك الكثير من الأشياء المثيرة للاهتمام تنتظرك هنا.
عند نشر إصدار جديد من برنامجك، من المفيد النظر في جميع الخيارات لتقليل المخاطر. يعد التشغيل بالتوازي طريقة قوية جدًا ومثبتة للاختبار، ويتيح لك Istio استخدام "خدمة سرية" (نسخة مخفية من الخدمة الصغيرة الخاصة بك) للقيام بذلك دون التدخل في نظام الإنتاج. حتى أن هناك مصطلحًا خاصًا لهذا - "Dark Launch"، والذي بدوره يتم تنشيطه بواسطة وظيفة لها نفس اسم التجسس "Traffic Mirroring".
يرجى ملاحظة أن الجملة الأولى من الفقرة السابقة تستخدم مصطلح "نشر" بدلاً من "إطلاق". يجب أن تكون قادرًا حقًا على نشر الخدمة الصغيرة الخاصة بك - وبالطبع استخدامها - بقدر ما تريد. يجب أن تكون هذه الخدمة قادرة على استقبال حركة المرور ومعالجتها وإنتاج النتائج وكذلك الكتابة في السجلات والمراقبة. ولكن في الوقت نفسه، لا تحتاج هذه الخدمة نفسها بالضرورة إلى إطلاقها في الإنتاج. إن نشر البرامج وإصدارها ليسا نفس الشيء دائمًا. يمكنك النشر وقتما تشاء، ولكن يمكنك النشر فقط عندما تكون جاهزًا.
تنظيم الملل أمر مثير للاهتمام
ألقِ نظرة على قاعدة توجيه Istio التالية، والتي توجه جميع طلبات HTTP إلى توصية الخدمة الصغيرة v1 (جميع الأمثلة مأخوذة من )، مع عكسها في الوقت نفسه مع التوصية v2 microservice:
انتبه إلى الملصق mirror: في الجزء السفلي من الشاشة - وهذا هو ما يحدد انعكاس حركة المرور. نعم، الأمر بهذه البساطة!
ستكون نتيجة هذه القاعدة هي أن نظام الإنتاج الخاص بك (الإصدار 1) سيستمر في معالجة الطلبات الواردة، ولكن الطلبات نفسها سيتم عكسها بشكل غير متزامن إلى الإصدار 2، أي أن النسخ المكررة الكاملة ستذهب إلى هناك. بهذه الطريقة، يمكنك اختبار الإصدار 2 في ظروف حقيقية - على بيانات وحركة مرور حقيقية - دون التدخل بأي شكل من الأشكال في تشغيل نظام الإنتاج. هل هذا يجعل تنظيم الاختبار مملاً؟ نعم بالتأكيد. ولكن يتم ذلك بطريقة مثيرة للاهتمام.
دعونا نضيف الدراما
يرجى ملاحظة أنه من الضروري في كود الإصدار 2 توفير المواقف التي قد تؤدي فيها الطلبات الواردة إلى تغييرات في البيانات. يتم عكس الطلبات نفسها بسهولة وشفافية، ولكن اختيار طريقة المعالجة في الاختبار متروك لك - وهذا أمر مقلق بعض الشيء.
دعونا نكرر نقطة مهمة
يمكن إجراء التشغيل السري مع النسخ المتطابق لحركة المرور (التشغيل الداكن/نسخ الطلب) دون التأثير على الكود بأي شكل من الأشكال.
غذاء للفكر
ماذا لو كان المكان الذي تنعكس فيه الطلبات يرسل بعضها ليس إلى v1، بل إلى v2؟ على سبيل المثال، واحد بالمائة من جميع الطلبات أو الطلبات الواردة من مجموعة معينة من المستخدمين فقط. وبعد ذلك، بعد النظر في كيفية عمل الإصدار 2، قم بنقل جميع الطلبات تدريجيًا إلى الإصدار الجديد. أو العكس، قم بإعادة كل شيء إلى الإصدار v1 إذا حدث خطأ ما في الإصدار v2. أعتقد أنه يسمى نشر الكناري. ، وإذا كانت من أصل روسي، فمن المحتمل أن تحتوي على إشارة إلى )، والآن سننظر في هذا بمزيد من التفصيل.
Canary Deployment في Istio: تبسيط التكليف
بعناية وتدريجيا
إن جوهر نموذج نشر Canary Deployment بسيط للغاية: عندما تقوم بتشغيل إصدار جديد من برنامجك (في حالتنا، خدمة صغيرة)، فإنك تمنح أولاً إمكانية الوصول إليه لمجموعة صغيرة من المستخدمين. إذا سارت الأمور على ما يرام، يمكنك زيادة هذه المجموعة ببطء حتى يبدأ الإصدار الجديد في العمل، أو - إذا لم يحدث ذلك - في النهاية، قم بترحيل جميع المستخدمين إليها. من خلال تقديم إصدار جديد بشكل مدروس وتدريجي وتحويل المستخدمين إليه بطريقة خاضعة للرقابة، يمكنك تقليل المخاطر وزيادة التعليقات إلى أقصى حد.
بالطبع، يعمل Istio على تبسيط عملية نشر Canary من خلال تقديم العديد من الخيارات الجيدة لتوجيه الطلب الذكي. ونعم، كل هذا يمكن القيام به دون لمس كود المصدر الخاص بك بأي شكل من الأشكال.
تصفية المتصفح
أحد أبسط معايير التوجيه هو إعادة التوجيه المستندة إلى المتصفح. لنفترض أنك تريد فقط أن تنتقل الطلبات الواردة من متصفحات Safari إلى الإصدار 2. وإليك كيف يتم ذلك:
دعونا نطبق قاعدة التوجيه هذه ثم نستخدم الأمر curl سنقوم بمحاكاة الطلبات الحقيقية للخدمة المصغرة في حلقة. كما ترون في لقطة الشاشة، فإنهم جميعًا ينتقلون إلى الإصدار 1:
أين توجد حركة المرور على الإصدار الثاني؟ نظرًا لأن جميع الطلبات في مثالنا تأتي فقط من سطر الأوامر الخاص بنا، فهي ببساطة غير موجودة. لكن انتبه إلى السطور السفلية في الشاشة أعلاه: هذا رد فعل على حقيقة أننا قمنا بتنفيذ طلب من متصفح Safari، والذي بدوره أنتج هذا:
قوة غير محدودة
لقد كتبنا بالفعل أن التعبيرات العادية توفر إمكانات قوية جدًا لطلبات التوجيه. ألقِ نظرة على المثال التالي (نعتقد أنك ستفهم ما يفعله):
ربما تكون لديك الآن فكرة عما يمكن أن تفعله التعبيرات العادية.
التصرف بذكاء
يتيح لك التوجيه الذكي، وخاصةً معالجة رؤوس الحزم باستخدام التعبيرات العادية، توجيه حركة المرور بالطريقة التي تريدها. وهذا يبسط إلى حد كبير تنفيذ التعليمات البرمجية الجديدة - فهو بسيط، ولا يتطلب تغيير التعليمات البرمجية نفسها، وإذا لزم الأمر، يمكن إرجاع كل شيء بسرعة كما كان.
يستفد؟
هل أنت متحمس لتجربة Istio وKubernetes وOpenShift على جهاز الكمبيوتر الخاص بك؟ فريق أعدت ممتازة حول هذا الموضوع وجعل جميع الملفات المصاحبة متاحة للجمهور. لذا تفضل ولا تحرم نفسك من أي شيء.
Istio Egress: الخروج من خلال متجر الهدايا التذكارية
باستخدام Istio مع Red Hat OpenShift وKubernetes، يمكنك جعل حياتك مع الخدمات الصغيرة أسهل بكثير. شبكة خدمة Istio مخفية داخل كبسولات Kubernetes، ويتم تشغيل التعليمات البرمجية الخاصة بك (في الغالب) بمعزل عن غيرها. الأداء، وسهولة التغيير، والتتبع، وما إلى ذلك - كل هذا سهل الاستخدام بفضل استخدام الحاويات الجانبية. ولكن ماذا لو كانت الخدمة الصغيرة الخاصة بك بحاجة إلى التواصل مع الخدمات الأخرى الموجودة خارج نظام OpenShift-Kubernetes الخاص بك؟
هذا هو المكان الذي يأتي فيه Istio Egress للإنقاذ. باختصار، فهو يسمح لك ببساطة بالوصول إلى الموارد (اقرأ: "الخدمات") التي لا تشكل جزءًا من نظام Kubernetes pods الخاص بك. إذا لم تقم بإجراء تكوين إضافي، فسيتم توجيه حركة المرور في بيئة Istio Egress فقط داخل مجموعة من القرون وبين هذه المجموعات بناءً على جداول IP الداخلية. ويعمل هذا التشرنق بشكل رائع طالما أنك لا تحتاج إلى الوصول إلى الخدمات من الخارج.
يسمح لك الخروج بتجاوز جداول IP المذكورة أعلاه، إما بناءً على قواعد الخروج أو على نطاق من عناوين IP.
لنفترض أن لدينا برنامج Java الذي يقدم طلب GET إلى httpbin.org/headers.
(يعد httpbin.org مجرد مورد مناسب لاختبار طلبات الخدمة الصادرة.)
إذا قمت بالدخول على سطر الأوامر curl http://httpbin.org/headers، سنرى ما يلي:
أو يمكنك فتح نفس العنوان في المتصفح:
كما ترون، فإن الخدمة الموجودة هناك تقوم ببساطة بإرجاع الرؤوس التي تم تمريرها إليها.
نحن نستبدل الواردات وجهاً لوجه
الآن لنأخذ كود Java الخاص بهذه الخدمة، خارج نظامنا، ونقوم بتشغيله بمفردنا، حيث تم تثبيت Istio. (يمكنك القيام بذلك بنفسك عن طريق الاتصال .) بعد إنشاء الصورة المناسبة وإطلاقها على منصة OpenShift، سنستدعي هذه الخدمة بالأمر curl egresshttpbin-istioegress.$(minishift ip).nip.ioوبعد ذلك سنرى هذا على الشاشة:
عفوا، ماذا حدث؟ كل شيء يعمل للتو. ماذا يعني لم يتم العثور عليه؟ لقد فعلنا ذلك من أجله فقط curl.
توسيع جداول IP إلى الإنترنت بالكامل
يجب إلقاء اللوم (أو الشكر) على Istio على هذا. بعد كل شيء، Istio هي مجرد حاويات جانبية مسؤولة عن الاكتشاف والتوجيه (والكثير من الأشياء الأخرى التي تحدثنا عنها سابقًا). لهذا السبب، تعرف جداول IP فقط ما هو موجود داخل نظام المجموعة الخاص بك. ويقع httpbin.org في الخارج وبالتالي لا يمكن الوصول إليه. وهنا يأتي دور Istio Egress للإنقاذ - دون أدنى تغيير في كود المصدر الخاص بك.
قاعدة الخروج أدناه تجبر Istio على البحث (إذا لزم الأمر، في جميع أنحاء الإنترنت) عن الخدمة المطلوبة، في هذه الحالة، httpbin.org. كما ترون من هذا الملف (egress_httpbin.yml)، فإن الوظيفة هنا بسيطة جدًا:
كل ما تبقى هو تطبيق هذه القاعدة:
istioctl create -f egress_httpbin.yml -n istioegress
يمكنك عرض قواعد الخروج باستخدام الأمر istioctl get egressrules:
وأخيرا، نقوم بتشغيل الأمر مرة أخرى حليقة - ونرى أن كل شيء يعمل:
نحن نفكر بصراحة
كما ترون، يتيح لك Istio تنظيم التفاعل مع العالم الخارجي. بمعنى آخر، لا يزال بإمكانك إنشاء خدمات OpenShift وإدارتها من خلال Kubernetes، مع الاحتفاظ بكل شيء في حجرات يمكن توسيع نطاقها لأعلى ولأسفل حسب الحاجة. وفي الوقت نفسه، يمكنك الوصول بأمان إلى الخدمات الخارجية لبيئتك. ونعم، نكرر مرة أخرى أن كل هذا يمكن القيام به دون لمس الكود الخاص بك بأي شكل من الأشكال.
كان هذا آخر منشور في السلسلة على Istio. ترقبوا - هناك الكثير من الأشياء المثيرة للاهتمام في المستقبل!
المصدر: www.habr.com