במדריך הזה מתוארות שיטות מומלצות לאינטגרציה רציפה (CI) ולפיתוח רציף (CD) ב-Google Kubernetes Engine (GKE). השיטות המומלצות האלה כוללות מגוון רחב של נושאים, מבקרת מקורות ועד אסטרטגיות פריסה. השיטות המומלצות האלה ספציפיות ל-GKE, אבל עדיין חלות שיטות מומלצות כלליות של CI/CD. מידע נוסף זמין במאמרים בנושא טכנולוגיית DevOps: אינטגרציה רציפה וטכנולוגיית DevOps: פיתוח רציף.
אינטגרציה רציפה (CI)
אינטגרציה רציפה (CI) היא שיטה שבה מפתחים משלבים את כל שינויי הקוד שלהם בחזרה לענף ראשי בתדירות גבוהה ככל האפשר. המטרה היא לאפשר כשלים מהירים יותר על ידי חשיפת בעיות בשלב מוקדם ככל האפשר בתהליך. בדרך כלל, צינורות CI מופעלים על ידי מפתחים שמבצעים שינויים בקוד. הצינור כולל שלבים לאימות השינויים האלה, כמו איתור שגיאות בקוד (linting), בדיקה ובנייה. בדרך כלל, צינור 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, במיוחד אם משתמשים באסטרטגיות פריסה מורכבות יותר כמו פריסות כחולות-ירוקות.
שימוש במתודולוגיית GitOps
GitOps הוא קונספט של תשתית הצהרתית שמאוחסנת במאגרי Git, ושל כלי CI/CD לפריסת התשתית הזו בסביבה. כשמשתמשים במתודולוגיית GitOps, מוודאים שכל השינויים באפליקציות ובאשכולות מאוחסנים במאגרי קוד מקור ונגישים תמיד.
השימוש במתודולוגיות GitOps מספק את היתרונות הבאים:
- אפשר לבדוק את השינויים לפני הפריסה שלהם באמצעות מיזוג או בקשות משיכה.
- יש לכם מיקום יחיד שבו תוכלו לחזור למצב של האפליקציות והאשכולות שלכם בכל נקודת זמן.
- תמונות המצב של האשכולות והאפליקציות מקלות על השחזור במקרה של כשלים.
חלק מהכלים הנפוצים שמשמשים לתשתית הצהרתית הם Terraform של Hashicorp ו-Config Connector של Google Cloud. כדי להתנסות בניהול התשתית באמצעות GitOps וכלים אחרים, מומלץ לעיין במדריך ניהול התשתית כקוד באמצעות Terraform, Cloud Build ו-GitOps. כדי ללמוד איך לנהל אפליקציות בסגנון GitOps, מומלץ לנסות את המדריך בנושא פיתוח רציף (continuous delivery) בסגנון GitOps באמצעות Cloud Build.
קידום של תמונות קונטיינר במקום בנייה מחדש
אין לבנות מחדש קובצי אימג' בקונטיינר כשהם עוברים בשלבים השונים של צינור CI/CD. במהלך הבנייה מחדש יכולים להיווצר הבדלים קלים בין ענפי הקוד. ההבדלים האלה עלולים לגרום לכשל באפליקציה בסביבת הייצור, או להוספה בטעות של קוד שלא נבדק לתמונה של קונטיינר הייצור. כדי לוודא שקובץ אימג' של קונטיינר שבדקתם הוא קובץ אימג' של קונטיינר שאתם פורסים, מומלץ לבצע build פעם אחת ולקדם אותו בסביבות שלכם. ההמלצה הזו מבוססת על ההנחה שאתם שומרים את ההגדרות הספציפיות לסביבה בנפרד מהחבילות.
מומלץ להשתמש בדפוסי פריסה ובדיקה מתקדמים יותר
GKE מאפשר לכם לפרוס ולבדוק את האפליקציות שלכם באמצעות כמה דפוסים. דפוס הפריסה שתבחרו תלוי בעיקר ביעדים העסקיים שלכם. לדוגמה, יכול להיות שתצטרכו לפרוס שינויים ללא השבתה, או לפרוס שינויים בסביבה או בקבוצת משנה של משתמשים לפני שתשיקו תכונה לכלל המשתמשים.
הנה כמה דוגמאות לדפוסי פריסה שזמינים לכם:
יצירה מחדש של פריסה: מצמצמים את קנה המידה של גרסת האפליקציה הקיימת באופן מלא לפני שמגדילים את קנה המידה של גרסת האפליקציה החדשה.
פריסת עדכון הדרגתי: אתם מעדכנים קבוצת משנה של מופעי אפליקציה פעילים במקום לעדכן את כל מופעי האפליקציה הפעילים בבת אחת. לאחר מכן, מעדכנים בהדרגה עוד מופעים של האפליקציה הפועלת עד שכולם מעודכנים.
פריסה כחולה-ירוקה: אתם פורסים קבוצה מקבילה נוספת של מופעים למופעי הייצור הקיימים עם גרסה משודרגת של האפליקציה. כשמוכנים לפרוס, מעבירים את התנועה למופעים החדשים.
קלאסטרים נפרדים לסביבות שונות
הפרדה בין סביבות היא שיקול חשוב בכל יעד פריסה. מומלץ להשתמש באשכולות נפרדים לכל אחת מהסביבות הבאות:
סביבת פיתוח: בסביבה הזו המפתחים פורסים אפליקציות לבדיקה ולניסוי. פריסות כאלה דורשות שילוב עם חלקים אחרים של האפליקציה או המערכת (לדוגמה, מסד נתונים). בדרך כלל יש פחות שערים באשכולות של הסביבה הזו, ולמפתחים יש יותר שליטה על הגדרת האשכולות.
סביבות לפני ייצור (Staging או QA): הסביבות האלה צריכות להיות דומות ככל האפשר לסביבת הייצור. הן משמשות לביצוע בדיקות רחבות היקף של שינויים כמו בדיקות אינטגרציה, עומס, ביצועים או רגרסיה.
סביבת ייצור: בסביבה הזו פועלים עומסי העבודה של הייצור והאפליקציות והשירותים שפונים למשתמשים.
שמירה על סביבות טרום-ייצור קרובות לסביבת הייצור
באופן אידיאלי, אשכולות טרום-ייצור זהים לאשכולות ייצור, אבל מטעמי עלות אפשר להקטין את מספר העותקים של אשכולות טרום-ייצור. שמירה על דמיון בין האשכולות מבטיחה שכל הבדיקות יתבצעו בתנאים זהים או דומים לאלה שקיימים בסביבת הייצור. השוואה בין אשכולות לפני הייצור לבין אשכולות בייצור גם מפחיתה את הסיכוי לכשלים לא צפויים בגלל הבדלים בסביבה כשמבצעים פריסה לייצור.
תשתית דקלרטיבית ו-GitOps עוזרים להשיג שוויון קרוב יותר בין הסביבות, כי קל יותר לשכפל את ההגדרה של האשכול הבסיסי. כדי לוודא שהתנאים בסביבות דומים מבחינת כללי המדיניות וההגדרות, אפשר גם להשתמש בכלים כמו סנכרון תצורות.
הכנה לכשלים בסביבת הייצור
שום כמות של בדיקות לא יכולה להבטיח שהאפליקציה תפעל בצורה תקינה בסביבת הייצור. הכשלים יכולים להיגרם ממקרי קצה עם נתונים שלא נלקחו בחשבון או מדפוסי גישה של המשתמשים שלא נבדקו. חשוב לעקוב אחרי האפליקציה בסביבת הייצור ולהשתמש במנגנונים אוטומטיים להחזרה לגרסה קודמת ולפריסה, כדי שתוכלו להגיב במהירות לבאגים או להפסקות שירות ולתקן אותם. שימוש באסטרטגיות פריסה חזקות יותר מאפשר לצמצם את ההשפעה של בעיות ולמנוע פגיעה במספר גדול של משתמשי קצה כשהן מתעוררות בסביבת הייצור.
סיכום רשימת המשימות
בטבלה הבאה מפורטות המשימות המומלצות לביצוע כשמשתמשים בצינור CI/CD ב-GKE:
| אזור | Tasks |
|---|---|
| אינטגרציה רציפה (CI) |
|
| פיתוח רציף (continuous delivery) |
|