דרך פשוטה ומאובטחת להפוך פריסות קנריות לאוטומטיות עם Helm

פריסה קנרית היא דרך יעילה מאוד לבדוק קוד חדש על תת-קבוצה של משתמשים. זה מפחית באופן משמעותי את עומס התעבורה שיכול להיות בעייתי במהלך תהליך הפריסה, מכיוון שהוא מתרחש רק בתוך תת-קבוצה ספציפית. הערה זו מוקדשת כיצד לארגן פריסה כזו באמצעות 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 הוא ניהול גרסאות ריבוי גרסאות. הגרסה היציבה היא הענף היציב העיקרי שלנו בקוד הפרויקט. אבל עם 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

זה הכל! אם אתה פינג לשירות, אתה יכול לראות שהעדכון הקנרי מנתב תנועה רק חלק מהזמן.

אם אתם מחפשים כלי אוטומציה של פריסה הכוללים את ההיגיון המתואר, שימו לב Deliverybot ו - כלי אוטומציה של Helm ב-GitHub. תרשימי ההגה המשמשים ליישום השיטה המתוארת לעיל נמצאים ב-Github, כאן. באופן כללי, זו הייתה סקירה תיאורטית של איך ליישם אוטומציה של פריסה של גרסאות קנריות בפועל, עם מושגים ודוגמאות ספציפיות.

מקור: www.habr.com