שיטות מומלצות לאינטגרציה רציפה ולפיתוח רציף ב-Google Kubernetes Engine

במדריך הזה מתוארות שיטות מומלצות לאינטגרציה רציפה ולפיתוח רציף (CI/CD) ב-Google Kubernetes Engine‏ (GKE). השיטות המומלצות האלה כוללות מגוון רחב של נושאים, מבקרת מקורות ועד אסטרטגיות פריסה. השיטות המומלצות האלה ספציפיות ל-GKE, אבל עדיין חלות עליהן שיטות מומלצות כלליות של CI/CD. מידע נוסף זמין במאמרים בנושא טכנולוגיית DevOps: אינטגרציה רציפה וטכנולוגיית DevOps: פיתוח רציף.

סיכום רשימת המשימות שבתחתית המדריך הזה כולל את כל שיטות העבודה המומלצות ל-GKE.

סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.

אינטגרציה רציפה (CI)

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

יצירת צינורות עיבוד נתונים שמאפשרים איטרציה מהירה

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

  • צינורות מהירים: צינורות כאלה פועלים בדרך כלל תוך 10 דקות או פחות. הצינורות האלה מיועדים לענפים של תכונות, והם לא אמורים להיות מקיפים. צינורות מהירים עלולים להוביל לארטיפקטים לא יציבים.

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

בדיקת קובצי אימג' של קונטיינרים

כחלק מצינורות ה-CI, חשוב להריץ את כל הבדיקות הנדרשות בקוד ובארטיפקטים של הבנייה. הבדיקות האלה צריכות לכלול בדיקות יחידה, בדיקות פונקציונליות, בדיקות שילוב ובדיקות עומס או ביצועים.

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

כדי לבדוק את קובצי האימג' בקונטיינר, אפשר להשתמש במסגרת Container Structure Tests.

הגדרת אבטחה בשלבים מוקדמים של צינורות העיבוד

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

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

  • חובה לבקש ממומחים בתחום לבדוק כל קוד שמשולב במאגר הייצור.

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

  • סריקת קובץ האימג' של הקונטיינר שבניתם כדי לאתר נקודות חולשה באמצעות בדיקת נקודות חולשה.

  • למנוע פריסה של תמונות שמכילות נקודות חולשה באשכולות, באמצעות Binary Authorization. כדי להשתמש ב-Binary Authorization, צריך מינוי ל-GKE Enterprise. כדי לספק לכם רמת סמך גבוהה יותר לגבי התמונות שנוצרו, Binary Authorization מאפשר גם לדרוש אישורים מישויות או ממערכות שונות. לדוגמה, האישורים האלה יכולים לכלול את הפרטים הבאים:

    • עבר סריקה של נקודות חולשה
    • עבר את בדיקת בקרת האיכות
    • אישור מבעלי המוצר

פיתוח רציף (continuous delivery)

פיתוח רציף (CD) מאפשר לכם להפיץ קוד בכל שלב. ‫CD פועל על הארטיפקט שנוצר על ידי צינורות CI. צינורות CD יכולים לפעול הרבה יותר זמן מצינורות CI, במיוחד אם משתמשים באסטרטגיות פריסה מורכבות יותר כמו פריסות blue-green.

שימוש במתודולוגיית GitOps

‫GitOps הוא קונספט של תשתית הצהרתית שמאוחסנת במאגרי Git, ושל כלי CI/CD לפריסת התשתית הזו בסביבה שלכם. כשמשתמשים במתודולוגיית GitOps, מוודאים שכל השינויים באפליקציות ובאשכולות מאוחסנים במאגרי מקור ונגישים תמיד.

השימוש במתודולוגיות GitOps מספק את היתרונות הבאים:

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

חלק מהכלים הנפוצים שמשמשים לתשתית הצהרתית הם Terraform של Hashicorp ו-Config Connector של Cloud de Confiance by S3NS. כדי להתנסות בניהול התשתית באמצעות GitOps וכלים אחרים, מומלץ לעיין במדריך ניהול התשתית כקוד באמצעות Terraform, ‏Cloud Build ו-GitOps. כדי ללמוד איך לנהל אפליקציות בסגנון GitOps, מומלץ לנסות את המדריך בנושא פיתוח רציף (continuous delivery) בסגנון GitOps באמצעות Cloud Build.

קידום של תמונות קונטיינר במקום בנייה מחדש

אין ליצור מחדש קובצי אימג' בקונטיינר כשהם עוברים בשלבים השונים של צינור CI/CD. במהלך הבנייה מחדש יכולים להיווצר הבדלים קלים בין ענפי הקוד. ההבדלים האלה עלולים לגרום לכך שהאפליקציה תיכשל בייצור או לגרום להוספה לא מכוונת של קוד שלא נבדק בתמונת מאגר הייצור. כדי לוודא שקובץ אימג' של קונטיינר שבדקתם הוא קובץ אימג' של קונטיינר שאתם פורסים, מומלץ לבצע את ה-build פעם אחת ולקדם אותו בסביבות שלכם. ההמלצה הזו מבוססת על ההנחה שאתם שומרים את ההגדרות הספציפיות לסביבה בנפרד מהחבילות.

מומלץ להשתמש בדפוסי פריסה ובדיקה מתקדמים יותר

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

הנה כמה דוגמאות לדפוסי פריסה שזמינים לכם:

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

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

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

קלאסטרים נפרדים לסביבות שונות

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

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

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

  • סביבת ייצור: בסביבה הזו פועלים עומסי העבודה של הייצור והאפליקציות והשירותים שפונים למשתמשים.

שמירה על סביבות טרום-ייצור קרובות לסביבת הייצור

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

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

הכנה לכשלים בסביבת הייצור

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

סיכום רשימת המשימות

בטבלה הבאה מפורטות המשימות המומלצות לשימוש בצינור CI/CD ב-GKE:

אזור Tasks
אינטגרציה רציפה (CI)
פיתוח רציף (continuous delivery)

המאמרים הבאים