يعتبر نشر الكناري طريقة فعالة للغاية لاختبار الشفرة الجديدة على مجموعة فرعية من المستخدمين. إنه يقلل بشكل كبير من حمل حركة المرور ، والذي يمكن أن يسبب مشاكل أثناء عملية النشر ، لأنه يحدث فقط داخل مجموعة فرعية معينة. هذا المقال مخصص لكيفية تنظيم عملية نشر مماثلة باستخدام Kubernetes وأتمتة النشر.
من المفترض أنك تعرف شيئًا عن موارد Helm و Kubernetes .
يشمل نشر الكناري البسيط في Kubernetes مصدرين رئيسيين: الخدمة نفسها وأداة النشر. يعمل نشر الكناري من خلال خدمة واحدة ، والتي تتفاعل مع اثنين من الموارد المختلفة التي تخدم حركة المرور التحديث. سيعمل أحد هذه الموارد مع إصدار "الكناري" ، والثاني مع الإصدار الثابت. في هذه الحالة ، يمكننا ضبط عدد إصدارات الكناري من أجل تقليل مقدار حركة المرور المطلوبة للصيانة. على سبيل المثال ، إذا كنت تفضل استخدام Yaml ، فسيظهر هذا في Kubernetes:
kind: Deployment metadata: name: app-canary labels: app: app spec: replicas: 1 ... image: myapp:canary --- kind: Deployment metadata: name: app labels: app: app spec: replicas: 5 ... image: myapp:stable --- kind: Service selector: app: app # Selector will route traffic to both deployments.
من الأسهل تخيل مثل هذا الخيار على kubectl ، وحتى
وثائق Kubernetes تحتوي على برنامج تعليمي كامل حول هذا السيناريو. لكن السؤال الرئيسي في هذا المنشور هو كيف سنعمل على أتمتة هذه العملية باستخدام Helm.
أتمتة نشر الكناري
بادئ ذي بدء ، نحن بحاجة إلى خريطة مخطط Helm ، التي تضمنت بالفعل الموارد التي ناقشناها أعلاه. يجب أن يبدو شيء مثل هذا:
~/charts/app ├── Chart.yaml ├── README.md ├── templates │ ├── NOTES.txt │ ├── _helpers.tpl │ ├── deployment.yaml │ └── service.yaml └── values.yaml
أساس مفهوم Helm هو إدارة الإصدارات متعددة الإصدارات. النسخة المستقرة هي فرعنا الرئيسي المستقر من رمز المشروع. ولكن مع هيلم ، يمكننا نشر إصدار الكناري باستخدام الكود التجريبي الخاص بنا. الشيء الرئيسي هو الحفاظ على تبادل حركة المرور بين إصدار مستقر وإصدار الكناري. سندير كل هذا باستخدام محدد خاص:
selector: app.kubernetes.io/name: myapp
ستشير كل من موارد النشر "canary" والمستقرة إلى هذه التسمية على الوحدات. إذا تم إعداد كل شيء بشكل صحيح ، فعند نشر إصدار الكناري من مخطط Helm الخاص بنا ، سنرى أنه سيتم إرسال حركة المرور إلى الوحدات النمطية التي تم نشرها حديثًا. سيبدو الإصدار الثابت من هذا الأمر كما يلي:
helm upgrade --install myapp \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v1 \ # Goes into app.kubernetes.io/version --set image.tag=stable \ --set replicaCount=5
الآن دعونا تحقق من إصدار الكناري لدينا. لنشر إصدار الكناري ، نحتاج أن نتذكر شيئين. يجب أن يكون اسم الإصدار مختلفًا حتى لا نشمر التحديث على الإصدار الثابت الحالي. يجب أن يكون الإصدار والعلامة مختلفين حتى نتمكن من نشر تعليمات برمجية مختلفة وتحديد الاختلافات حسب تسميات الموارد.
helm upgrade --install myapp-canary \ --namespace default \ --set app.name=myapp \ # Goes into app.kubernetes.io/name --set app.version=v2 \ # Goes into app.kubernetes.io/version --set image.tag=canary \ --set replicaCount=1
هذا كل شيء ، في الواقع! إذا قمت بإجراء اختبار ping للخدمة ، يمكنك أن ترى أن التحديث الكناري يوجه حركة المرور فقط جزء من الوقت.
إذا كنت تبحث عن أدوات أتمتة النشر التي تتضمن المنطق الموصوف ، فقم بمراجعة أدوات
التسليم الآلي و
Helm على GitHub . مخططات Helm المستخدمة لتنفيذ الطريقة الموضحة أعلاه موجودة على جيثب ،
هنا . بشكل عام ، كانت هذه نظرة عامة نظرية حول كيفية تنفيذ نشر إصدارات الكناري في الممارسة ، مع مفاهيم وأمثلة محددة.