یک راه ساده و ایمن برای خودکار کردن استقرار قناری ها با Helm

استقرار قناری روشی بسیار مؤثر برای آزمایش کدهای جدید بر روی زیرمجموعه ای از کاربران است. به طور قابل توجهی بار ترافیکی را که می تواند در طول فرآیند استقرار مشکل ساز باشد، کاهش می دهد، زیرا فقط در یک زیر مجموعه خاص رخ می دهد. این یادداشت به نحوه سازماندهی چنین استقراری با استفاده از Kubernetes و اتوماسیون استقرار اختصاص دارد. ما فرض می کنیم که شما چیزی در مورد منابع Helm و Kubernetes می دانید.



یک استقرار ساده قناری در Kubernetes شامل دو منبع کلیدی است: خود سرویس و ابزار استقرار. استقرار 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 و in حتی ساده تر است اسناد Kubernetes حتی یک آموزش کامل در مورد این سناریو وجود دارد. اما سوال اصلی این پست این است که چگونه می‌خواهیم این فرآیند را با استفاده از 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 chart ما خواهیم دید که ترافیک به سمت ماژول های تازه مستقر شده هدایت می شود. نسخه پایدار این دستور به شکل زیر خواهد بود:

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

همین! اگر سرویس را پینگ کنید، می بینید که به روز رسانی قناری فقط بخشی از زمان را به ترافیک می اندازد.

اگر به دنبال ابزارهای اتوماسیون استقرار هستید که شامل منطق توصیف شده باشد، به آن توجه کنید تحویل ربات و ابزارهای اتوماسیون هلم در GitHub. نمودارهای Helm مورد استفاده برای پیاده سازی روش شرح داده شده در بالا در Github هستند. اینجا. به طور کلی، این یک مرور نظری از نحوه پیاده سازی اتوماسیون استقرار نسخه های قناری در عمل با مفاهیم و مثال های خاص بود.

منبع: www.habr.com