🥇 פריסת יישומים על פני אשכולות Kubernetes מרובים עם Helm

כיצד Dailymotion משתמש ב-Kubernetes: פריסת יישומים

אנחנו ב-Dailymotion התחלנו להשתמש ב-Kubernetes בייצור לפני 3 שנים. אבל פריסת יישומים על פני אשכולות מרובים היא מהנה, אז במהלך השנים האחרונות ניסינו לשפר את הכלים וזרימות העבודה שלנו.

מאיפה זה התחיל

כאן נסקור כיצד אנו פורסים את היישומים שלנו על פני אשכולות Kubernetes מרובים ברחבי העולם.

כדי לפרוס מספר אובייקטים של Kubernetes בו-זמנית, אנו משתמשים הגה, וכל התרשימים שלנו מאוחסנים במאגר git אחד. כדי לפרוס ערימת יישומים מלאה ממספר שירותים, אנו משתמשים בתרשים הסיכום שנקרא. בעיקרו של דבר, זהו תרשים שמצהיר על תלות ומאפשר לך לאתחל את ה-API והשירותים שלו בפקודה אחת.

כתבנו גם סקריפט Python קטן על גבי Helm כדי לבצע בדיקות, ליצור תרשימים, להוסיף סודות ולפרוס יישומים. כל המשימות הללו מבוצעות על פלטפורמת CI מרכזית באמצעות תמונת docker.

בואו נגיע לנקודה.

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

זרימת עבודה לפיתוח תרשים

אנו משתמשים בהסתעפות עבור יישומים, והחלטנו ליישם את אותה גישה לתרשימים.

ענף dev משמש ליצירת תרשימים שייבחנו על אשכולות פיתוח.
כאשר מוגשת בקשת משיכה ל אב, הם נבדקים בבימוי.
לבסוף, אנו יוצרים בקשת משיכה לביצוע השינויים בסניף לְדַרבֵּן וליישם אותם בייצור.

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

מאגרי תרשימים בסביבות שונות

ראוי לציין שכאשר מפתחים דוחפים ענף מפתחים, גרסה של התרשים שלהם נדחפת אוטומטית ל-dev Chartmuseum. לפיכך, כל המפתחים משתמשים באותו מאגר מפתחים, ואתה צריך לציין בזהירות את הגרסה שלך של התרשים כדי לא להשתמש בטעות בשינויים של מישהו אחר.

יתר על כן, סקריפט Python הקטן שלנו מאמת אובייקטי Kubernetes מול מפרטי Kubernetes OpenAPI באמצעות קובבל, לפני פרסומם ב-Chartmusem.

תיאור כללי של זרימת העבודה לפיתוח התרשים

הגדרת משימות צינור לפי מפרט gazr.io לבקרת איכות (מוך, בדיקת יחידה).
דחיפה של תמונת docker עם כלי Python הפורסים את היישומים שלנו.
הגדרת הסביבה לפי שם הסניף.
אימות קבצי Kubernetes yaml באמצעות Kubeval.
הגדל אוטומטית את הגרסה של תרשים ואת תרשימי האב שלו (תרשימים התלויים בתרשים המשתנה).
הגשת תרשים למוזיאון תרשים התואם את סביבתו

ניהול הבדלים בין אשכולות

הפדרציה של אשכולות

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

כדי לפתור את הבעיה, התחלנו לנהל את האשכולות באופן עצמאי, מה שפשט מאוד את התהליך (השתמשנו בגרסה הראשונה של הפדרציה; אולי משהו השתנה בשנייה).

פלטפורמה בהפצה גיאוגרפית

הפלטפורמה שלנו מפוזרת כיום על פני 6 אזורים - 3 מקומית ו-3 בענן.

פריסה מבוזרת

ערכי הגה גלובליים

4 ערכי Helm גלובליים מאפשרים לך לזהות הבדלים בין אשכולות. לכל התרשימים שלנו יש ערכי מינימום ברירת מחדל.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

ערכים גלובליים

ערכים אלו עוזרים להגדיר את ההקשר עבור היישומים שלנו ומשמשים למטרות שונות: ניטור, מעקב, רישום, ביצוע שיחות חיצוניות, קנה מידה וכו'.

"ענן": יש לנו פלטפורמת Kubernetes היברידית. לדוגמה, ה-API שלנו נפרס באזורי GCP ובמרכזי הנתונים שלנו.
"env": ערכים מסוימים עשויים להשתנות עבור סביבות שאינן ייצור. לדוגמה, הגדרות משאבים ותצורות קנה מידה אוטומטי.
"אזור": מידע זה עוזר לקבוע את מיקומו של האשכול וניתן להשתמש בו כדי לקבוע נקודות קצה קרובות עבור שירותים חיצוניים.
"clusterName": אם וכאשר אנו רוצים להגדיר ערך עבור אשכול בודד.

הנה דוגמה ספציפית:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

דוגמה לתבנית הגה

ההיגיון הזה מוגדר בתבנית עוזרת כדי למנוע עומס של Kubernetes YAML.

הודעת בקשה

כלי הפריסה שלנו מבוססים על מספר קובצי YAML. להלן דוגמה לאופן שבו אנו מכריזים על שירות וטופולוגיית קנה המידה שלו (מספר העתקים) באשכול.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

הגדרת שירות

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

שלבי הפריסה של ג'נקינס

מה עם סודות?

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

כלי הפריסה שלנו מחלצים ערכים סודיים מ-Vault, וכאשר מגיע זמן הפריסה, הכנס אותם לתוך Helm.

לשם כך, הגדרנו מיפוי בין הסודות ב-Vault לבין הסודות שהאפליקציות שלנו זקוקות להם:

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

הגדרנו כללים כלליים שיש לפעול לפיהם בעת הקלטת סודות בכספת.
אם הסוד חל להקשר או אשכול ספציפי, עליך להוסיף ערך ספציפי. (כאן לאשכול ההקשר1 יש ערך משלו עבור הסיסמה הסודית מחסנית-אפליקציה1).
אחרת הערך משמש כברירת מחדל.
עבור כל פריט ברשימה זו ב סוד קוברנטס הוכנס זוג מפתח-ערך. לכן, התבנית הסודית בתרשימים שלנו היא פשוטה מאוד.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

בעיות ומגבלות

עבודה עם מספר מאגרים

כעת אנו מפרידים בין פיתוח תרשימים ויישומים. המשמעות היא שמפתחים צריכים לעבוד בשני מאגרי git: אחד עבור האפליקציה, ואחד עבור הגדרת הפריסה שלו ל-Kubernetes. 2 מאגרי git פירושם 2 זרימות עבודה, וקל למתחילים להתבלבל.

ניהול תרשימים כלליים הוא טרחה

כפי שכבר אמרנו, תרשימים גנריים שימושיים מאוד לזיהוי תלות ופריסה מהירה של מספר יישומים. אבל אנחנו משתמשים --reuse-valuesכדי להימנע מהעברת כל הערכים בכל פעם שאנו פורסים אפליקציה שהיא חלק מהתרשים הכללי הזה.

בזרימת עבודה רציפה של משלוח, יש לנו רק שני ערכים המשתנים באופן קבוע: מספר ההעתקים ותג התמונה (גרסה). ערכים אחרים ויציבים יותר משתנים באופן ידני, וזה די קשה. יתרה מכך, טעות אחת בפריסת תרשים כללי עלולה להוביל לכשלים חמורים, כפי שראינו מניסיוננו.

עדכון קובצי תצורה מרובים

כאשר מפתח מוסיף אפליקציה חדשה, עליו לשנות מספר קבצים: הצהרת האפליקציה, רשימת הסודות, הוספת האפליקציה כתלות אם היא נכללת בתרשים הכללי.

ההרשאות של ג'נקינס מורחבות מדי בכספת

עכשיו יש לנו אחד AppRole, שקורא את כל הסודות מהכספת.

תהליך החזרה לאחור אינו אוטומטי

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

אנחנו מתקדמים לעבר GitOps

המטרה שלנו

אנו רוצים להחזיר את התרשים למאגר האפליקציה שהוא פורס.

זרימת העבודה תהיה זהה לזו של הפיתוח. לדוגמה, כאשר ענף נדחף למאסטר, הפריסה תופעל אוטומטית. ההבדל העיקרי בין גישה זו לזרימת העבודה הנוכחית יהיה זה הכל ינוהל ב-git (האפליקציה עצמה ואופן פריסתה ב-Kubernetes).

ישנם מספר יתרונות:

הרבה יותר יותר ברור עבור היזם. קל יותר ללמוד כיצד להחיל שינויים בתרשים מקומי.
ניתן לציין את הגדרת פריסת השירות אותו מקום כמו הקוד שירות.
ניהול הסרת תרשימים כלליים. לשירות יהיה מהדורת Helm משלו. זה יאפשר לך לנהל את מחזור החיים של האפליקציה (החזרה, שדרוג) ברמה הקטנה ביותר, כדי לא להשפיע על שירותים אחרים.
היתרונות של git לניהול תרשים: בטל שינויים, יומן ביקורת וכו'. אם אתה צריך לבטל שינוי בתרשים, אתה יכול לעשות זאת באמצעות git. הפריסה מתחילה באופן אוטומטי.
אולי תשקול לשפר את זרימת העבודה בפיתוח שלך עם כלים כמו סקפולד, שאיתו מפתחים יכולים לבדוק שינויים בהקשר קרוב לייצור.

הגירה דו-שלבית

המפתחים שלנו משתמשים בזרימת העבודה הזו כבר שנתיים, אז אנחנו רוצים שההגירה תהיה כמה שיותר ללא כאבים. לכן החלטנו להוסיף שלב ביניים בדרך למטרה.
השלב הראשון הוא פשוט:

אנו שומרים על מבנה דומה להגדרת פריסת יישומים, אך באובייקט בודד בשם DailymotionRelease.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

גרסה אחת לכל אפליקציה (ללא תרשימים כלליים).
תרשימים במאגר git של האפליקציה.

דיברנו עם כל המפתחים, אז תהליך ההגירה כבר החל. השלב הראשון עדיין נשלט באמצעות פלטפורמת CI. בקרוב אכתוב פוסט נוסף על שלב שני: איך עברנו לזרימת עבודה של GitOps עם שטף. אני אספר לכם איך הגדרנו הכל ובאילו קשיים נתקלנו (ריבוי מאגרים, סודות וכו'). עקבו אחר החדשות.

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

מקור: www.habr.com

פרוס יישומים על פני אשכולות Kubernetes מרובים עם Helm