במאמר הזה מוסבר למפעילים של אשכולות ולאדמינים של פלטפורמות איך להטמיע שינויים בבטחה בכמה סביבות באמצעות סנכרון תצורות. הגישה הזו יכולה לעזור לכם להימנע משגיאות שמשפיעות על כל הסביבות שלכם בו-זמנית.
בעזרת סנכרון תצורות אפשר לנהל אשכולות יחידים, אשכולות מרובי דיירים והגדרות Kubernetes מרובות אשכולות באמצעות קבצים שמאוחסנים במאגר Git.
הגדרות יכולות לייצג כמה דברים, כולל:
- אובייקטים סטנדרטיים של GKE, כמו משאבי NetworkPolicies, משאבי DaemonSets או משאבי RoleBindings.
- Google Cloud משאבים, כמו מכונות של Compute Engine או מסדי נתונים של Cloud SQL, באמצעות Config Connector.
- מגבלות על ההגדרה עצמה, באמצעות Policy Controller.
סנכרון תצורות מתאים במיוחד לפריסת הגדרות, מדיניות ועומסי עבודה שנדרשים להפעלת הפלטפורמה שאתם בונים על גבי Google Kubernetes Engine – לדוגמה, סוכני אבטחה, סוכני מעקב ומנהלי אישורים.
אמנם אפשר לפרוס אפליקציות גלויות למשתמשים באמצעות סנכרון תצורות, אבל לא מומלץ לקשר את מחזור החיים של הגרסה שלהן למחזור החיים של הגרסה של עומסי העבודה האדמיניסטרטיביים שצוינו קודם. במקום זאת, מומלץ להשתמש בכלי ייעודי לפריסת אפליקציות, כמו כלי פריסה רציפה, כדי שצוותי האפליקציות יוכלו לנהל את לוח הזמנים לפרסום שלהן.
סנכרון תצורות הוא מוצר רב-עוצמה שיכול לנהל הרבה אלמנטים, ולכן צריך אמצעי הגנה כדי למנוע שגיאות שיש להן השפעה משמעותית. במסמך הזה מתוארות כמה שיטות ליצירת אמצעי הגנה. החלק הראשון עוסק בהשקות מדורגות, והחלק השני מתמקד בבדיקות ובאימותים. בקטע השלישי מוסבר איך לעקוב אחרי הפריסות.
הטמעה של השקות מדורגות באמצעות סנכרון תצורות
בסביבה מרובת אשכולות, לא מומלץ להחיל שינוי בהגדרה על כל האשכולות בו-זמנית. השקה מדורגת, אשכול אחר אשכול, היא בטוחה הרבה יותר כי היא מצמצמת את ההשפעה הפוטנציאלית של כל שגיאה.
יש כמה דרכים להטמיע השקות מדורגות באמצעות סנכרון תצורות:
- משתמשים בתגיות או בהתחייבויות של Git כדי להחיל באופן ידני את השינויים שרוצים על האשכולות.
- משתמשים בענפים של Git כדי להחיל את השינויים באופן אוטומטי כשממזגים את השינויים. אפשר להשתמש בענפים שונים לקבוצות שונות של אשכולות.
- אפשר להשתמש באובייקטים
ClusterSelectorו-NamespaceSelectorכדי להחיל שינויים באופן סלקטיבי על קבוצות משנה של אשכולות או מרחבי שמות.
לכל השיטות להשקה מדורגת יש יתרונות וחסרונות. בטבלה הבאה אפשר לראות באילו מהשיטות האלה אפשר להשתמש בו-זמנית:
| תאימות | תגי Git או קומיטים | ענפים ב-Git | בוררי אשכולות | בוררי מרחבי שמות |
|---|---|---|---|---|
| תגי Git או קומיטים | לא תואם | תואם | תואם | |
| ענפים ב-Git | לא תואם | תואם | תואם | |
| בוררי אשכולות | תואם | תואם | תואם | |
| בוררי מרחבי שמות | תואם | תואם | תואם |
עץ ההחלטות הבא יכול לעזור לכם להחליט מתי להשתמש באחת משיטות ההפצה בשלבים.
שימוש בתגי Git או בהתחייבויות (commit) ל-Git
בהשוואה לשיטות אחרות להפצה מדורגת, השימוש בתגי Git או בהתחייבויות Git מספק את השליטה הגדולה ביותר והוא הבטוח ביותר. אתם יכולים להשתמש בדף סנכרון תצורות במסוף Google Cloud כדי לעדכן כמה אשכולות בו-זמנית. כדאי להשתמש בשיטה הזו אם רוצים להחיל שינויים על האשכולות אחד אחרי השני, ולשלוט בדיוק מתי זה קורה.
בשיטה הזו, אתם 'מצמידים' כל אשכול לגרסה ספציפית (או קומיט או תג) של המאגר. השיטה הזו דומה לשימוש ב-Git commit כתג של קובץ אימג' של קונטיינר.
כדי להטמיע את השיטה הזו, מציינים את ה-commit, התג או הגיבוב בשדה spec.git.revision של RootSync או RepoSync
משאב מותאם אישית.
אם אתם מנהלים את המשאבים המותאמים אישית של RootSync או RepoSync באמצעות כלי כמו Kustomize, תוכלו לצמצם את כמות העבודה הידנית שנדרשת להשקות. בעזרת כלי כזה, צריך לשנות את הפרמטר revision רק במקום אחד, ואז להחיל באופן סלקטיבי את המשאב המותאם אישית החדש RootSync או RepoSync על האשכולות בסדר ובקצב שתבחרו.
בנוסף, אפשר להשתמש במסוף Google Cloud כדי לעדכן את הפרמטר revision של כמה אשכולות ששייכים לאותו צי בו-זמנית. עם זאת, אם יש לכם מערכת אוטומטית לעדכון ההגדרות, לא מומלץ להשתמש במסוף כדי לבצע שינויים בהגדרות. Google Cloud
לדוגמה, ההגדרה הבאה של RootSync מגדירה את סנכרון תצורות לשימוש בתג 1.2.3:
apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
name: root-sync
namespace: config-sync-system
spec:
sourceType: git
sourceFormat: unstructured
git:
repo: git@example.com:gke/config-sync.git
revision: 1.2.3
auth: ssh
אם תפעילו את ההגדרה הזו באשכול, סנכרון תצורות ישתמש בתג 1.2.3 של מאגר example.com:gke/config-sync.git.
כדי לעדכן אשכול, משנים את הערך החדש של האשכול בשדה spec.git.revision. כך תוכלו להגדיר אילו אשכולות יעודכנו ומתי. אם אתם רוצים לבטל שינוי, אתם יכולים לשנות את השדה spec.git.revision בחזרה לערך הקודם שלו.
הדיאגרמה הבאה ממחישה את תהליך ההשקה של שיטה זו. קודם, מבצעים commit של השינויים במאגר סנכרון תצורות, ואז מעדכנים את ההגדרות של RootSync בכל האשכולות:
צעדים מומלצים:
- מומלץ להשתמש במזהי Git commit במקום בתגים. בגלל האופן שבו Git פועל, מובטח שהם לעולם לא ישתנו. לדוגמה,
git push --forceלא יכול לשנות את הקומיט שבו סנכרון תצורות משתמש. הגישה הזו שימושית למטרות ביקורת ולמעקב אחרי הקומיט שבו אתם משתמשים ביומנים. בנוסף, בניגוד לתגים, אין שלב נוסף שצריך לבצע כדי לאשר מזהים. - אם אתם מעדיפים להשתמש בתגי Git במקום במזהי Git commit, אתם יכולים להגן על התגים אם אתם משתמשים בפתרון Git שתומך בהגנה.
- אם רוצים לעדכן כמה אשכולות בו-זמנית, אפשר לעשות זאת במסוףGoogle Cloud . כדי לעדכן כמה אשכולות בבת אחת, הם צריכים להיות חלק מאותו צי (ולהיות באותו פרויקט).
שימוש בהסתעפויות של Git
אם רוצים שהשינויים יחולו על אשכולות ברגע שהם ימוזגו במאגר Git, צריך להגדיר את סנכרון תצורות כך שישתמש בענפי Git במקום בביצועי Git או בתגי Git. בשיטה הזו, יוצרים כמה ענפים לטווח ארוך במאגר Git, ומגדירים את סנכרון תצורות באשכולות שונים כך שיקרא את ההגדרה שלו מענפים שונים.
לדוגמה, דפוס פשוט כולל שני ענפים:
- ענף
stagingלאשכולות שאינם בסביבת ייצור. - ענף
mainלאשכולות ייצור.
לגבי אשכולות שאינם אשכולות ייצור, יוצרים את האובייקט RootSync או RepoSync עם השדה spec.git.branch שמוגדר לערך staging. בסביבות ייצור, יוצרים את האובייקט RootSync או RepoSync עם הפרמטר spec.git.branch שמוגדר לערך main.
לדוגמה, הגדרת RootSync הבאה מגדירה את סנכרון תצורות להשתמש בהסתעפות main:
apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
name: root-sync
namespace: config-sync-system
spec:
git:
repo: git@example.com:gke/config-sync.git
branch: main
auth: ssh
הדיאגרמה הבאה ממחישה את תהליך ההשקה של השיטה הזו:
אפשר להתאים את התבנית הזו לצרכים ספציפיים, להשתמש ביותר משני ענפים או להשתמש בענפים שממופים למשהו אחר מלבד סביבות. אם צריך לבטל שינוי, משתמשים בפקודה git revert כדי ליצור קומיט חדש באותו ענף שמבטל את השינויים מהקומיט הקודם.
צעדים מומלצים:
- כשעובדים עם כמה אשכולות, מומלץ להשתמש לפחות בשני ענפים של Git כדי להבחין בין אשכולות של ייצור לבין אשכולות שאינם של ייצור.
- ברוב הפתרונות של Git אפשר להשתמש בתכונת הענפים המוגנים כדי למנוע מחיקות או שינויים שלא נבדקו בענפים האלה. מידע נוסף זמין במאמרי העזרה של GitHub, GitLab ו-Bitbucket.
שימוש באובייקטים ClusterSelector ו-NamespaceSelector
ענפים ב-Git הם דרך טובה להשקה מדורגת של שינויים בכמה אשכולות, שבסופו של דבר יחולו עליהם אותן מדיניות. עם זאת, אם רוצים להשיק שינוי רק לקבוצת משנה של אשכולות או של מרחבי שמות, צריך להשתמש באובייקטים ClusterSelector ו-NamespaceSelector. המטרה של האובייקטים האלה דומה: הם מאפשרים להחיל אובייקטים רק על אשכולות או על מרחבי שמות עם תוויות ספציפיות.
לדוגמה:
- באמצעות אובייקטים מסוג
ClusterSelector, אפשר להחיל מדיניות שונה על אשכולות, בהתאם למדינה שבה הם נמצאים, עבור משטרי תאימות שונים. - באמצעות אובייקטים של
NamespaceSelector, אתם יכולים להחיל מדיניות שונה על מרחבי שמות שמשמשים צוות פנימי ועל מרחבי שמות שמשמשים קבלן חיצוני.
אובייקטים של ClusterSelector ו-NamespaceSelector מאפשרים גם ליישם מתודולוגיות מתקדמות של בדיקה והפצה, כמו:
- הפצה של מדיניות בגרסת קנרית, שבה פורסים מדיניות חדשה לקבוצת משנה קטנה של אשכולות ומרחבי שמות למשך זמן ארוך כדי לבדוק את ההשפעה של המדיניות.
- בדיקות A/B, שבהן פורסים גרסאות שונות של אותה מדיניות באשכולות שונים כדי לבדוק את ההבדל בהשפעה של גרסאות המדיניות, ואז בוחרים את הגרסה הכי טובה לפריסה בכל מקום.
לדוגמה, נניח שיש ארגון עם כמה אשכולות ייצור.
צוות הפלטפורמה כבר יצר שתי קטגוריות של אשכולות ייצור, בשם canary-prod ו-prod, באמצעות אובייקטים של Cluster ו-ClusterSelector (ראו שימוש ב-ClusterSelectors).
צוות הפלטפורמה רוצה להטמיע מדיניות באמצעות Policy Controller כדי לאכוף את הנוכחות של תווית צוות במרחבי שמות, במטרה לזהות לאיזה צוות כל מרחב שמות שייך. הם כבר השיקו גרסה של המדיניות הזו במצב הרצה יבשה, ועכשיו הם רוצים לאכוף אותה על מספר קטן של אשכולות.
באמצעות אובייקטים של ClusterSelector, הם יוצרים שני משאבי K8sRequiredLabels שונים שמוחלים על אשכולות שונים.
המשאב
K8sRequiredLabelsמוחל על אשכולות מסוגprod, עם פרמטרenforcementActionשמוגדר ל-dryrun:apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-team annotations: configmanagement.gke.io/cluster-selector: prod Spec: enforcementAction: dryrun match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: - key: "team"המשאב
K8sRequiredLabelsמוחל על אשכולות מסוגcanary-prod, ללא הפרמטרenforcementAction, כלומר המדיניות נאכפת בפועל:apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-team annotations: configmanagement.gke.io/cluster-selector: canary-prod spec: match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: - key: "team"
ההערה configmanagement.gke.io/cluster-selector מאפשרת לצוות לאכוף את המדיניות רק באשכולות מסוג canary-prod, וכך למנוע תופעות לוואי לא רצויות שיתפשטו לכל צי הייצור. מידע נוסף על התכונה 'הרצה יבשה' של Policy Controller זמין במאמר בנושא יצירת אילוצים.
צעדים מומלצים:
- משתמשים באובייקטים
ClusterSelectorו-NamespaceSelectorאם רוצים להחיל שינוי בהגדרות רק על קבוצת משנה של אשכולות או מרחבי שמות, ללא הגבלת זמן או למשך זמן רב. - אם אתם מבצעים פריסה של שינוי באמצעות סלקטורים, עליכם להיזהר מאוד. אם אתם משתמשים ב-Git commits, כל שגיאה משפיעה רק על אשכול אחד בכל פעם, כי אתם מבצעים פריסה של אשכול אחרי אשכול. אבל אם משתמשים בענפים של Git, כל שגיאה יכולה להשפיע על כל האשכולות שמשתמשים בענף הזה. אם משתמשים בסלקטורים, השגיאה יכולה להשפיע על כל האשכולות בבת אחת.
הטמעה של בדיקות, ניסויים ואימותים
אחד היתרונות של סנכרון תצורות הוא שהוא מנהל הכול באופן הצהרתי – משאבי Kubernetes, משאבי ענן ומדיניות. כלומר, קבצים במערכת לניהול בקרת גרסאות מייצגים את המשאבים (קבצי Git, במקרה של סנכרון תצורות). המאפיין הזה מאפשר לכם להטמיע תהליכי עבודה לפיתוח שכבר נמצאים בשימוש בקוד המקור של האפליקציה: בדיקות ובדיקות אוטומטיות.
הטמעה של ביקורות
מכיוון שסנכרון תצורות מבוסס על Git, אתם יכולים להשתמש בפתרון Git המועדף עליכם כדי לארח את מאגר סנכרון תצורות. לפתרון Git שלכם כנראה יש תכונה של בדיקת קוד, שבה תוכלו להשתמש כדי לבדוק את השינויים שבוצעו במאגר סנכרון תצורות.
השיטות המומלצות לבדיקת שינויים במאגר זהות לאלה של בדיקת קוד רגילה, והן מפורטות בהמשך:
- תרגול של פיתוח מבוסס-ענף ראשי.
- לעבוד בקבוצות קטנות.
- חשוב לוודא שבדיקת הקוד מתבצעת באופן סינכרוני או לפחות באופן מיידי.
- האדם שבודק ומאשר את השינוי לא יכול להיות אותו אדם שהציע את השינוי.
בגלל הרגישות של בסיס הקוד של סנכרון תצורות, אנחנו ממליצים גם לבצע את ההגדרות הבאות, אם זה אפשרי עם פתרון ה-Git שלכם:
- הגנה על הענפים שנעשה בהם שימוש ישיר באשכולות. אפשר לעיין במסמכי התיעוד של GitHub, GitLab ו-Bitbucket. ב-GitLab אפשר גם להגן על תגים.
- אחרי שמגנים על הענפים, אפשר לשנות את הגדרות האישורים שנדרשים למיזוג שינוי:
- ב-GitHub, מפעילים את האפשרות 'נדרשות ביקורות'.
- ב-GitLab, משתמשים בבעלי קוד כדי להקצות הרשאות אישור על בסיס קובץ או ספרייה. אתם יכולים להשתמש באישורים של בקשות למיזוג כדי לדרוש מאנשים שונים מצוותים שונים לאשר בקשה לפני שהיא ממוזגת.
- ב-Bitbucket, משלבים בודקים שמוגדרים כברירת מחדל עם בדיקות מיזוג שמוגדרות כברירת מחדל. אופציונלי: אפשר להשתמש בפלאגין Code Owners ל-Bitbucket Server שזמין ב-Atlassian Marketplace כדי לקבוע מי יכול לאשר שינויים בחלקים של המאגר.
באמצעות התכונות השונות האלה, אתם יכולים לאכוף אישורים לכל בקשה לשינוי בבסיס הקוד. לדוגמה, אפשר לוודא שכל שינוי יאושר לפחות על ידי חבר בצוות הפלטפורמה (שמפעיל את צי האשכולות) ועל ידי חבר בצוות האבטחה (שאחראי להגדרת מדיניות האבטחה וליישום שלה).
מומלץ לבצע את הפעולה הבאה:
- אפשר לאכוף ביקורת עמיתים על ה-repository ולהגן על ענפי ה-Git שבהם נעשה שימוש באשכולות.
הטמעה של בדיקות אוטומטיות
שיטה מומלצת נפוצה כשעובדים על codebase היא הטמעה של אינטגרציה רציפה. כלומר, אתם מגדירים בדיקות אוטומטיות שיפעלו כשבקשת שינוי נוצרת או מתעדכנת. בדיקות אוטומטיות יכולות לזהות הרבה שגיאות לפני שבקשת השינוי נבדקת על ידי אדם. כך המפתח מקבל משוב מהר יותר. אתם יכולים ליישם את אותו רעיון, באמצעות אותם כלים, במאגר Config Sync.
לדוגמה, כדאי להתחיל בהרצת הפקודה nomos vet באופן אוטומטי על שינויים חדשים. הפקודה הזו מאמתת שהתחביר של מאגר סנכרון תצורות תקין. כדי להטמיע את הבדיקה הזו באמצעות Cloud Build, אפשר לפעול לפי ההוראות במדריך בנושא אימות הגדרות. אפשר לשלב את Cloud Build עם האפשרויות הבאות:
- Bitbucket, באמצעות טריגרים של build.
- GitHub, באמצעות אפליקציית Google Cloud Build GitHub. אפשר להשתמש בטריגרים של build גם ב-GitHub, אבל אפליקציית GitHub היא שיטת השילוב המומלצת.
כפי שאפשר לראות במדריך בנושא אימות הגדרות, הבדיקה מתבצעת באמצעות קובץ אימג' של קונטיינר. לכן, אפשר להטמיע את הבדיקה בכל פתרון של אינטגרציה רציפה שמריץ קונטיינרים, ולא רק ב-Cloud Build.
כדי להדק עוד יותר את לולאת המשוב, אפשר לבקש מהמשתמשים להריץ את הפקודה nomos
vet כוו (hook) של Git לפני ביצוע קומיט.
חשוב לזכור שלחלק מהמשתמשים אין גישה לאשכולות Kubernetes שמנוהלים על ידי סנכרון תצורות, ולכן הם לא יכולים להריץ את האימות המלא מתחנת העבודה שלהם. מריצים את הפקודה nomos vet --clusters "" כדי להגביל את האימות לבדיקות סמנטיות ותחביריות.
מומלץ לבצע את הפעולה הבאה:
- הטמעת בדיקות בצינור לעיבוד נתונים של אינטגרציה רציפה.
- מריצים לפחות את הפקודה
nomos vetעל כל השינויים המוצעים.
מעקב אחרי השקות
גם אם מטמיעים את כל אמצעי ההגנה שמתוארים במסמך הזה, עדיין יכולות להתרחש שגיאות. הנה שני סוגים נפוצים של שגיאות:
- שגיאות שלא גורמות לבעיות בסנכרון תצורות עצמו, אבל מונעות מעומסי העבודה לפעול בצורה תקינה, כמו NetworkPolicy מגביל מדי שמונע מרכיבים של עומס העבודה לתקשר.
- שגיאות שמונעות מ-סנכרון תצורות להחיל שינויים באשכול, כמו מניפסט לא תקין של Kubernetes או אובייקט שנדחה על ידי בקר הרשאות. השיטות שהוסברו קודם אמורות לזהות את רוב השגיאות האלה.
כמעט בלתי אפשרי לזהות את השגיאות שמתוארות בתבליט הראשון שלמעלה ברמה של סנכרון תצורות, כי צריך להבין את המצב של כל עומסי העבודה. לכן, הדרך הכי טובה לזהות את השגיאות האלה היא באמצעות מערכת המעקב הקיימת שלכם, שמספקת לכם התראות כשיש התנהגות חריגה באפליקציה.
כדי לזהות את השגיאות שמתוארות בתבליט השני שלמעלה – שצריכות להיות נדירות אם הטמעתם את כל אמצעי ההגנה – נדרש תהליך הגדרה ספציפי. כברירת מחדל, סנכרון תצורות כותב שגיאות ליומנים שלו (שנמצאים כברירת מחדל ב-Cloud Logging).
השגיאות מוצגות גם בדף המסוף של סנכרון תצורות Google Cloud .
בדרך כלל היומנים או המסוף לא מספיקים כדי לזהות שגיאות, כי סביר להניח שאתם לא עוקבים אחריהם כל הזמן. הדרך הכי פשוטה לאוטומציה של זיהוי שגיאות היא להריץ את nomos status
הפקודה, שמציינת אם יש שגיאה באשכול.
אפשר גם להגדיר פתרון מתקדם יותר עם התראות אוטומטיות על שגיאות. סנכרון תצורות חושף מדדים בפורמט Prometheus. מידע נוסף זמין במאמר בנושא מעקב אחרי סנכרון תצורות.
אחרי שיהיו לכם את מדדי סנכרון ההגדרות במערכת המעקב, תוכלו ליצור התראה שתשלח לכם הודעה כשהמדד gkeconfig_monitor_errors יהיה גדול מ-0. מידע נוסף זמין במאמרים בנושא ניהול מדיניות התראות ב-Cloud Monitoring או בנושא כללי התראות ב-Prometheus.
סיכום של מנגנונים לפריסה בטוחה באמצעות סנכרון תצורות
בטבלה הבאה מפורטים המנגנונים השונים שמתוארים בחלקים הקודמים של המסמך הזה. אף אחד מהמנגנונים האלה לא בלעדי. אתם יכולים לבחור להשתמש בחלק מהם או בכולם, למטרות שונות.
| מנגנון | למה הוא מתאים | למה הוא לא מתאים | תרחיש שימוש לדוגמה |
|---|---|---|---|
| תגיות ומזהים של קומיטים ב-Git | כדי לשלוט בדיוק באילו שינויים באשכול יחולו, אפשר להשתמש במזהי או בתגים ספציפיים של Git commit. | אל תשתמשו במזהי או בתגים של Git commit כדי לתאר הבדלים בין אשכולות לאורך זמן. שימוש בבוררי אשכולות. | כל האשכולות מוגדרים להחלת 12345 Git
commit. אתם מבצעים שינוי באמצעות קומיט חדש, abcdef, שאתם רוצים לבדוק. משנים את ההגדרה של אשכול יחיד כדי להשתמש בהתחייבות החדשה הזו לאימות השינוי. |
| ענפים ב-Git | כדאי להשתמש בכמה ענפים של Git כשרוצים להטמיע את אותו שינוי בכמה סביבות, אחת אחרי השנייה. | אל תשתמשו בכמה ענפים של Git להבדלים ארוכי טווח בין אשכולות. ההסתעפויות יהיו שונות באופן משמעותי ויהיה קשה למזג אותן בחזרה. | קודם ממזגים את השינוי בהסתעפות של סביבת הבדיקה, שבה הוא יזוהה על ידי אשכולות של סביבת הבדיקה. אחר כך ממזגים את השינוי בהסתעפות הראשית, והוא יזוהה על ידי אשכולות הייצור. |
| בוררי אשכול ובוררי מרחב שמות | משתמשים בסלקטורים כדי להבחין בין קלאסטרים ומרחבי שמות לאורך זמן. | אל תשתמשו בכלי הבחירה להפצה מדורגת בכמה סביבות. אם רוצים לבדוק שינוי קודם בסביבת staging ואז לפרוס אותו בסביבת production, צריך להשתמש בענפים נפרדים של Git. | אם צוותי האפליקציות צריכים גישה מלאה לאשכולי פיתוח, אבל גישה לקריאה בלבד לאשכולות ייצור, צריך להשתמש באובייקט ClusterSelector כדי להחיל את מדיניות ה-RBAC הנכונה רק על האשכולות הרלוונטיים. |
| ביקורות עמיתים | כדי לוודא שהצוותים הרלוונטיים מאשרים את השינויים, כדאי להשתמש בביקורות עמיתים. | בודקים אנושיים לא תמיד מוצאים את כל השגיאות, במיוחד פריטים כמו שגיאות תחביר. | הארגון שלכם קבע שצוות האבטחה חייב לבדוק שינויים בהגדרות שמשפיעים על כמה מערכות. חבר צוות האבטחה צריך לבדוק את השינויים. |
| בדיקות אוטומטיות בצינור לעיבוד נתונים של אינטגרציה רציפה | כדאי להשתמש בבדיקות אוטומטיות כדי לזהות שגיאות בשינויים המוצעים. | בדיקות אוטומטיות לא יכולות להחליף באופן מלא בודק אנושי. משתמשים בשניהם. | הפעלת הפקודה nomos vet על כל השינויים המוצעים מאשרת שהמאגר הוא הגדרה תקינה של סנכרון תצורות. |
| מעקב אחרי שגיאות בסנכרון | חשוב לוודא ש-Config Sync באמת מחיל שינויים על האשכולות. | שגיאות סנכרון מתרחשות רק אם Config Sync מנסה להחיל מאגר לא תקין או אם שרת ה-API של Kubernetes דוחה חלק מהאובייקטים. | משתמש עוקף את כל הבדיקות והביקורות שלכם ומבצע שינוי לא תקין במאגר סנכרון תצורות. אי אפשר להחיל את השינוי הזה על האשכולות שלכם. אם אתם עוקבים אחרי שגיאות סנכרון, תקבלו התראה אם תתבצע שגיאה. |
דוגמה לאסטרטגיית השקה
בקטע הזה נשתמש במושגים שהוצגו בשאר המאמר כדי לעזור לכם ליצור אסטרטגיית השקה מקצה לקצה בכל האשכולות בארגון שלכם. האסטרטגיה הזו מניחה שיש לכם צי נפרד לפיתוח, צי נפרד ל-Staging וצי נפרד לייצור (כפי שמוצג בדוגמה 1 לצי – גישה 1).
בתרחיש הזה, מגדירים כל אשכול לסנכרון עם מאגר Git באמצעות קומיט ספציפי של Git. פריסת שינוי בצי נתון היא תהליך שכולל 4 שלבים:
- מעדכנים קודם את האשכול היחיד (ה'קנרי') בצי כדי להשתמש בקומיט החדש.
- כדי לוודא שהכול פועל כמו שצריך, מריצים בדיקות ועוקבים אחרי ההשקה.
- מעדכנים את שאר האשכולות בצי.
- בודקים שוב שהכול פועל כמו שצריך.
כדי לפרוס שינוי בכל האשכולות, חוזרים על התהליך הזה לכל צי. מבחינה טכנית, אפשר להחיל את השיטה הזו על כל קומיט של Git, מכל ענף. עם זאת, אנחנו מציעים לכם לפעול לפי התהליך הבא כדי לזהות בעיות בשלב מוקדם בתהליך הבדיקה:
- כשמישהו פותח בקשה לשינוי במאגר Git של סנכרון תצורות, צריך לפרוס את השינוי הזה לאחד מאשכולי הפיתוח.
- אם בקשת השינוי מתקבלת וממוזגת בענף הראשי, מריצים את הפריסה המלאה בכל צי הרכבים כמו שמתואר קודם.
יכול להיות שחלק מהשינויים יתמקדו רק בצי ספציפי, אבל מומלץ בסופו של דבר לפרוס את כל השינויים בכל הציים. השיטה הזו פותרת את הבעיה של מעקב אחרי הצי שצריך לסנכרן עם הקומיט. חשוב לשים לב במיוחד לשינויים שמטרגטים רק את צי הייצור, כי לא הייתה אפשרות לבצע בדיקות מתאימות בציים הקודמים. לדוגמה, המשמעות היא שתצטרכו לחכות יותר זמן עד שבעיות יצוצו בין הפריסה לאשכולות הקנרי לבין הפריסה לשאר האשכולות.
לסיכום, פריסה מלאה מקצה לקצה נראית כך:
- מישהו פותח בקשה לשינוי.
- מתבצעות בדיקות ואימותים אוטומטיים, ומתבצעת בדיקה ידנית.
- מפעילים משימה באופן ידני כדי לפרוס את השינוי באשכול הגרסה הראשונית (canary) בצי הפיתוח. בקטע הזה מופעלות בדיקות אוטומטיות מקצה לקצה.
- אם הכול בסדר, מאחדים את בקשת השינוי עם הענף הראשי.
- המיזוג מפעיל משימה אוטומטית לפריסת הקומיט החדש של קצה הענף הראשי באשכול קנרי בצי הפיתוח. ב-cluster הזה מופעלות בדיקות אוטומטיות מקצה לקצה (כדי לזהות חוסר תאימות פוטנציאלי בין שתי בקשות לשינוי שנוצרו ומוזגו בערך באותו הזמן).
- הפעולות הבאות מבוצעות אחת אחרי השנייה (מפעילים אותן באופן ידני או אחרי פרק זמן מוגדר מראש כדי לאפשר למשתמשים לדווח על רגרסיות):
- פריסה לכל האשכולות של צי הפיתוח.
- להריץ בדיקות ואימותים באשכולות של צי הפיתוח.
- פריסה לאשכול גרסה ראשונית (canary) של צי ההכנה.
- מריצים בדיקות ואימותים באשכול הקנרי של צי הביניים.
- פריסה לכל האשכולות של צי הבדיקה.
- הרצת בדיקות ואימותים באשכולות של צי השרתים בשלב ההכנה.
- פריסה לאשכול גרסה ראשונית (canary) של ה-Fleet בסביבת הייצור.
- הרצת בדיקות ואימותים באשכול קנרי של צי הייצור.
- פריסה לכל האשכולות של צי הייצור.
- הרצת בדיקות ואימותים באשכולות של צי הייצור.
המאמרים הבאים
- מידע נוסף על מעקב אחרי סנכרון תצורות
- מידע נוסף על ציים
- איך מאמתים את האפליקציה בהתאם למדיניות החברה בצינור עיבוד נתונים של אינטגרציה רציפה