تقريبا. perev.: تقدم مادة المراجعة هذه من Weaveworks استراتيجيات بدء التطبيق الأكثر شيوعًا وتتحدث عن إمكانية تنفيذ أكثرها تقدمًا باستخدام مشغل Kubernetes Flagger. إنه مكتوب بلغة بسيطة ويحتوي على مخططات بصرية تجعل من الممكن حتى للمهندسين المبتدئين فهم المشكلة.
الرسم مأخوذ من مراجعة أخرى لاستراتيجيات التنفيذ التي تم إجراؤها في Container Solutions.واحدة من أكبر المشاكل في تطوير التطبيقات السحابية المحلية اليوم هي نشر النشر. من خلال منهج microservice ، يعمل المطورون بالفعل مع تطبيقات كاملة الوحدات وتصميمها ، مما يتيح للفرق المختلفة كتابة التعليمات البرمجية وإجراء تغييرات على التطبيق في نفس الوقت.
عمليات النشر الأقصر والأكثر تكرارًا لها المزايا التالية:
- يتم تقليل الوقت إلى السوق.
- تصل الميزات الجديدة إلى المستخدمين بشكل أسرع.
- تصل ملاحظات المستخدم إلى فريق التطوير بشكل أسرع. هذا يعني أنه يمكن للفريق استكمال المهام وحل المشكلات بسرعة أكبر.
- تزداد معنويات المطورين: من الممتع العمل مع عدد كبير من الوظائف في التطوير.
ولكن مع زيادة ترددات الإصدار ، تزداد أيضًا فرص التأثير السلبي على موثوقية التطبيق أو تجربة المستخدم. هذا هو السبب في أنه من المهم لفرق العمليات و DevOps بناء العمليات وإدارة استراتيجيات النشر بطريقة تقلل من المخاطر التي يتعرض لها المنتج والمستخدمون. (تعرف على المزيد حول أتمتة خطوط أنابيب CI / CD
هنا .)
في هذا المنشور ، سنناقش استراتيجيات النشر المختلفة في Kubernetes ، بما في ذلك عمليات النشر المتجددة والأساليب الأكثر تقدماً مثل نشرات الكناري وأشكالها المختلفة.
استراتيجيات النشر
هناك عدة أنواع مختلفة من استراتيجيات النشر التي يمكنك استخدامها بناءً على هدفك. على سبيل المثال ، قد تحتاج إلى إجراء تغييرات على بيئة معينة لإجراء مزيد من الاختبارات ، أو لمجموعة فرعية من المستخدمين / العملاء ، أو قد تحتاج إلى إجراء اختبارات محدودة على المستخدمين قبل إتاحة بعض الوظائف
للجمهور .
المتداول (التدريجي ، نشر "المتداول")
هذه استراتيجية نشر قياسية في Kubernetes. تدريجيا ، واحدا تلو الآخر ، يستبدل قرون مع الإصدار القديم من التطبيق مع القرون مع الإصدار الجديد - دون توقف الكتلة.
تنتظر Kubernetes حتى تصبح القرون الجديدة جاهزة للعمل (فحصها
باختبارات الاستعداد ) قبل البدء في انهيار القديمة. في حالة حدوث مشكلة ، يمكن مقاطعة هذا التحديث المتداول دون إيقاف المجموعة بالكامل. في ملف نوع YAML للنشر ، تحل الصورة الجديدة محل الصورة القديمة:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp spec: replicas: 3 template: metadata: labels: app: awesomeapp spec: containers: - name: awesomeapp image: imagerepo-user/awesomeapp:new ports: - containerPort: 8080
يمكن تحديد معلمات التحديث المتداول في ملف البيان:
spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 25% template: ...
إعادة (إعادة الإنشاء)
في هذا النوع الأبسط من النشر ، يتم قتل القرون القديمة دفعة واحدة واستبدالها بأخرى جديدة:
يبدو البيان المقابل شيئًا مثل هذا:
spec: replicas: 3 strategy: type: Recreate template: ...
الأزرق / الأخضر (نشر الأزرق والأخضر)
تتضمن استراتيجية النشر باللون الأزرق والأخضر (تسمى أحيانًا باللون الأحمر / الأسود ، أي باللون الأحمر والأسود) النشر المتزامن للإصدارات القديمة (الخضراء) والجديدة (الزرقاء) من التطبيق. بعد وضع كلا الإصدارين ، يمكن للمستخدمين العاديين الوصول إلى الإصدار الأخضر ، بينما يتوفر الإصدار الأزرق لفريق ضمان الجودة لأتمتة الاختبارات من خلال خدمة منفصلة أو إعادة توجيه المنفذ المباشر:
apiVersion: apps/v1beta1 kind: Deployment metadata: name: awesomeapp-02 spec: template: metadata: labels: app: awesomeapp version: "02"
بعد أن تم اختبار الإصدار الأزرق (الجديد) وتمت الموافقة على إصداره ، تنتقل الخدمة إليه ، ويتم تقليل اللون الأخضر (القديم) إلى الحد الأدنى:
apiVersion: v1 kind: Service metadata: name: awesomeapp spec: selector: app: awesomeapp version: "02" ...
الكناري (نشر الكناري)
تبدو لفائف الكناري باللون الأزرق والأخضر ، ولكن تتم إدارتها بشكل أفضل وتستخدم نهجًا متدرجًا متدرجًا. يتضمن هذا النوع العديد من الاستراتيجيات المختلفة ، بما في ذلك عمليات الإطلاق "الخفية" واختبار A / B.
يتم استخدام هذه الاستراتيجية عندما يكون من الضروري تجربة بعض الوظائف الجديدة ، كقاعدة عامة ، في الواجهة الخلفية للتطبيق. يتمثل جوهر النهج في إنشاء خادمين متطابقين تقريبًا: أحدهما يخدم جميع المستخدمين تقريبًا ، والآخر ، بميزات جديدة ، يخدم فقط مجموعة فرعية صغيرة من المستخدمين ، وبعد ذلك تتم مقارنة نتائجهم. إذا سارت الأمور على نحو سلس ، فإن الإصدار الجديد بدأ يتدرج تدريجياً إلى البنية التحتية بأكملها.
على الرغم من أنه لا يمكن تنفيذ هذه الاستراتيجية إلا باستخدام أدوات Kubernetes ، واستبدال القرون القديمة بأخرى جديدة ، إلا أنها أكثر سهولة وأسهل في استخدام شبكة الخدمة مثل Istio.
على سبيل المثال ، يمكن أن يكون لديك بيانان مختلفان في Git: الإصدار العادي مع علامة 0.1.0 والأخرى "canary" مع علامة 0.2.0. من خلال تغيير الأوزان في بيان عبّارة Istio الافتراضية ، يمكنك التحكم في توزيع حركة المرور بين هاتين النشرتين:
للحصول على معلومات حول تنفيذ عمليات نشر الكناري باستخدام Istio ، راجع
GitOps Workflows باستخدام Istio .
( ملاحظة الترجمة : لقد ترجمنا أيضًا مواد حول لفائف الكناري في Istio هنا .)نشرات الكناري مع Weaveworks Flag
يجعل
Weaveworks Flagger من السهل والكفاءة إدارة النشرات الكنارية.
Flagger بأتمتة العمل معهم. يستخدم Istio أو AWS App Mesh لتوجيه حركة المرور وتبديلها ، وكذلك مقاييس Prometheus لتحليل النتائج. بالإضافة إلى ذلك ، يمكن استكمال تحليل عمليات نشر الكناري بسهول الويب لاختبارات القبول واختبارات الإجهاد وأي أنواع أخرى من الفحوصات.
استنادًا إلى نشر Kubernetes ، وإذا لزم الأمر ، التوسع الأفقي للقرون (HPA) ، تنشئ Flagger مجموعات من الكائنات (نشر Kubernetes وخدمات ClusterIP والخدمات الافتراضية Istio أو App Mesh) لتحليل وتنفيذ عمليات نشر الكناري:
عند تنفيذ
حلقة تحكم ، يقوم Flagger بتحويل حركة المرور تدريجياً إلى خادم الكناري ، مع قياس مؤشرات الأداء الرئيسية في وقت واحد ، مثل النسبة المئوية لطلبات HTTP الناجحة ، ومتوسط مدة الطلب ، وصحة الجهاز. بناءً على تحليل KPI (مؤشرات الأداء الرئيسية) ، ينمو جزء الكناري أو ينهار ، ويتم نشر نتائج التحليل في سلاك. يمكن العثور على وصف وعرض لهذه العملية في
التسليم التدريجي لشبكة التطبيقات .
نشر داكن (مخفي) أو A / B
النشر السري هو تباين آخر في إستراتيجية الكناري (يمكن للفلجر أيضًا أن يعمل معها ، بالمناسبة). الفرق بين عمليات النشر السرية والكنارية هو أن عمليات النشر السرية تتعامل مع الواجهة الأمامية وليس الواجهة الخلفية ، مثل النشرات الكنارية.
اسم آخر لعمليات النشر هذه هو اختبار A / B. بدلاً من فتح الوصول إلى الوظيفة الجديدة لجميع المستخدمين ، يتم تقديمها فقط لجزء محدود منهم. عادةً ، لا يعرف هؤلاء المستخدمون أنهم اختبار رائد (ومن ثم مصطلح "النشر السري").
باستخدام
تبديل الوظائف والأدوات الأخرى ، يمكنك مراقبة كيفية تفاعل المستخدمين مع الميزة الجديدة ، سواء كان ذلك يأسرهم ، أو ما إذا وجدوا واجهة المستخدم الجديدة مربكة ، وأنواع أخرى من المقاييس.
نشرات Flagger و A / B
بالإضافة إلى التوجيه الموزون ، يمكن لـ Flagger أيضًا توجيه حركة المرور إلى خادم الكناري ، اعتمادًا على إعدادات HTTP. لاختبار A / B ، يمكنك استخدام رؤوس HTTP أو ملفات تعريف الارتباط لإعادة توجيه شريحة معينة من المستخدمين. هذا فعال بشكل خاص لتطبيقات الواجهة الأمامية التي تتطلب
تقارب الجلسة للخادم. لمزيد من المعلومات ، راجع وثائق Flagger.
يشكر المؤلف ستيفان برودان ، مهندس Weaveworks (ومؤسس برنامج Flagger) ، على كل هذه النشرات الرائعة.PS من المترجم
اقرأ أيضًا في مدونتنا: