طريقة بسيطة وآمنة لأتمتة عمليات نشر الكناري باستخدام Helm

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



يتضمن نشر الكناري البسيط إلى Kubernetes مصدرين رئيسيين: الخدمة نفسها وأداة النشر. يعمل نشر Canary من خلال خدمة واحدة تتفاعل مع مصدرين مختلفين يخدمان حركة مرور التحديث. سيعمل أحد هذه الموارد مع الإصدار "canary"، وسيعمل الثاني مع الإصدار الثابت. في هذه الحالة، يمكننا تنظيم عدد إصدارات الكناري من أجل تقليل مقدار حركة المرور المطلوبة للعرض. على سبيل المثال، إذا كنت تفضل استخدام 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، وفي وثائق كوبيرنيتيس حتى أن هناك برنامجًا تعليميًا كاملاً حول هذا السيناريو. لكن السؤال الرئيسي في هذا المنشور هو كيف سنقوم بأتمتة هذه العملية باستخدام Helm.

أتمتة نشر الكناري

أولاً، نحتاج إلى خريطة مخطط Helm، والتي تتضمن بالفعل الموارد التي ناقشناها أعلاه. يجب أن يبدو مثل هذا:

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

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

selector:
  app.kubernetes.io/name: myapp

ستشير موارد النشر "الكناري" والمستقرة لدينا إلى هذا التصنيف على الوحدات النمطية. إذا تم تكوين كل شيء بشكل صحيح، فعند نشر إصدار الكناري من خريطة مخطط 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

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

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

المصدر: www.habr.com