במדריך הזה מפורטות שיטות מומלצות לאינטגרציה רציפה (CI) ולפיתוח רציף (CD) ב-Google Kubernetes Engine (GKE). השיטות האלה עוסקות במגוון רחב של נושאים, החל מבקרת מקור ועד לאסטרטגיות פריסה. השיטות המומלצות האלה ספציפיות ל-GKE, ועדיין חלות השיטות המומלצות הכלליות של CI/CD. מידע נוסף זמין במאמרים DevOps טכנולוגי: אינטגרציה רציפה (CI) וDevOps טכנולוגי: פיתוח רציף (continuous delivery).
לרשימת משימות מסוכמת של כל השיטות המומלצות ל-GKE, עיינו בקטע סיכום רשימת המשימות שבתחתית המדריך הזה.
לסקירה כללית של כל השיטות המומלצות ל-GKE, קראו את המאמר שיטות מומלצות ל-GKE.אינטגרציה רציפה (CI)
אינטגרציה רציפה (CI) היא נוהל שבו המפתחים משלבים את כל שינויי הקוד שלהם בחזרה לענף הראשי בתדירות גבוהה ככל האפשר. הוא נועד לאפשר כשלים מהירים יותר על ידי חשיפת בעיות בשלב מוקדם ככל האפשר בתהליך. בדרך כלל, צינורות עיבוד נתונים של CI מופעלים על ידי מפתחים שדוחפים שינויים בקוד. התהליך כולל שלבים לאימות השינויים האלה, כמו ניתוח קוד סטטי, בדיקה ובנייה. בדרך כלל, צינור עיבוד נתונים של CI יוצר פריט שאפשר לפרוס בשלבים מאוחרים יותר של תהליך הפריסה.
יצירת צינורות עיבוד נתונים שמאפשרים איטרציה מהירה
משך הזמן שחולף מהרגע שהמפתח מבצע שינוי בקוד ועד שיש לכם גרסה פעילה של האפליקציה צריך להיות קצר ככל האפשר. המהירות הזו חשובה במיוחד במהלך הפיתוח של הסתעפויות של תכונות, שכוללות איטרציה מהירה של המפתחים. באופן אידיאלי, צינורות עיבוד הנתונים של ה-CI אמורים לפעול תוך פחות מ-10 דקות. אם זה לא אפשרי, צריך ליצור שני סוגים של צינורות עיבוד נתונים של CI:
צינורות עיבוד נתונים מהירים: צינורות עיבוד הנתונים האלה פועלים בדרך כלל תוך 10 דקות או פחות. הצינורות האלה מיועדים להסתעפויות של תכונות, והם לא אמורים להיות מקיפים. צינורות עיבוד נתונים מהירים עלולים לגרום לארטיפקטים לא יציבים.
תהליכים מלאים: התהליכים האלה יכולים להימשך יותר מ-10 דקות, והם מריצים בדיקות מקיפות יותר. צינורות עיבוד נתונים מלאים פועלים בבקשות מיזוג או משיכה, ומתבצע commit להסתעפות הראשית.
בדיקת קובצי האימג' של הקונטיינרים
כחלק מצינורות עיבוד הנתונים של ה-CI, חשוב לוודא שאתם מריצים את כל הבדיקות הנדרשות על הקוד ועל פריטי המידע שנוצרו בתהליך ה-build. הבדיקות האלה צריכות לכלול בדיקות יחידה, בדיקות פונקציונליות, בדיקות שילוב ובדיקות עומס או ביצועים.
חשוב גם לבדוק את המבנה של קובצי האימג' של הקונטיינרים שיצרתם. בדיקת המבנה מבטיחה שכל הפקודות יפעלו כמו שצריך בתוך הקונטיינר. בדיקה גם מאפשרת לכם לוודא שקבצים ספציפיים נמצאים במיקום הנכון ומכילים את התוכן הנכון.
כדי לבדוק את קובצי האימג' של הקונטיינרים, אתם יכולים להשתמש ב-framework של 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. בנייה מחדש יכולה לגרום להבדלים קלים בין הסתעפויות הקוד. ההבדלים האלה עלולים לגרום לכשל באפליקציה בסביבת הייצור, או להוספה בטעות של קוד שלא נבדק לקובץ האימג' של הקונטיינר בסביבת הייצור. כדי לוודא שקובץ האימג' של הקונטיינר שבדקתם הוא קובץ האימג' של הקונטיינר שאתם פורסים, מומלץ ליצור אותו פעם אחת ולקדם אותו בסביבות שלכם. ההנחה היא שאתם שומרים את ההגדרות הספציפיות לסביבה בנפרד מהחבילות.
כדאי להשתמש בתבניות מתקדמות יותר של פריסה ובדיקה
ב-GKE אתם יכולים לפרוס ולבדוק את האפליקציות בכמה דפוסים. דפוס הפריסה שתבחרו תלוי במידה רבה ביעדים העסקיים שלכם. לדוגמה, יכול להיות שתצטרכו לפרוס שינויים בלי זמן השבתה, או לפרוס שינויים בסביבה או בקבוצת משנה של משתמשים לפני שתהפכו תכונה לזמינה לכלל המשתמשים.
אלה כמה מתבניות הפריסה השונות שזמינות לכם:
יצירה מחדש של פריסה: אתם מצמצמים אנכית בהתאם לעומס (scale down) את גרסת האפליקציה הקיימת, לפני שאתם מרחיבים אנכית בהתאם לעומס (scale up) את גרסת האפליקציה החדשה.
פריסת עדכון בהדרגה (rolling): מעדכנים קבוצת משנה של מכונות פעילות של האפליקציה, במקום לעדכן את כולן בבת אחת. לאחר מכן מעדכנים בהדרגה עוד מופעים של האפליקציה שפועלים, עד שכולם מעודכנים.
פריסה כחולה-ירוקה: אתם פורסים קבוצה מקבילה נוספת של מכונות למכונות הייצור הקיימות, עם גרסה משודרגת של האפליקציה. כשתהיו מוכנים לפריסה, תוכלו להעביר את התנועה למכונות החדשות.
אשכולות נפרדים לסביבות שונות
הפרדה בין סביבות היא שיקול חשוב בכל יעד פריסה. באופן אידיאלי, כדאי ליצור אשכולות נפרדים לכל אחת מהסביבות הבאות:
סביבת פיתוח: בסביבה הזו המפתחים פורסים אפליקציות לבדיקה ולניסוי. הפריסות האלה דורשות שילוב עם חלקים אחרים של האפליקציה או המערכת (לדוגמה, מסד נתונים). בדרך כלל, לאשכולות בסביבה הזו יש פחות שערים, ולמפתחים יש יותר שליטה בהגדרות של האשכולות.
סביבות טרום-ייצור (Staging או QA): הסביבות האלה צריכות להיות דומות ככל האפשר לסביבת הייצור. הם משמשים לביצוע בדיקות בקנה מידה גדול של שינויים כמו בדיקות שילוב, עומס, ביצועים או רגרסיה.
סביבת ייצור: בסביבה הזו פועלים עומסי העבודה בסביבת הייצור, והאפליקציות והשירותים שגלויים למשתמשים.
שמירה על סביבות טרום-ייצור קרובות לסביבת הייצור
באופן אידיאלי, אשכולות טרום-ייצור זהים לאשכולות ייצור, אבל מטעמי עלות, אשכולות טרום-ייצור יכולים להיות רפליקות מוקטנות. כך אפשר לוודא שכל הבדיקות מתבצעות באותם תנאים או בתנאים דומים לאלה שבסביבת הייצור. התאמה בין אשכולות טרום-ייצור לאשכולות ייצור גם מפחיתה את הסבירות לכשלים בלתי צפויים בגלל הבדלים בסביבה כשפורסים לייצור.
תשתית הצהרתית ו-GitOps עוזרים להשיג שוויון קרוב יותר בין הסביבות, כי קל יותר לשכפל את ההגדרות של האשכול הבסיסי. כדי לוודא שבסביבות שלכם יש תנאים דומים למדיניות ולהגדרות, אתם יכולים גם להשתמש בכלים כמו סנכרון תצורות.
היערכות לתקלות בסביבת הייצור
שום בדיקה לא יכולה להבטיח שהאפליקציה תפעל כמו שצריך בסביבת הייצור. הכשלים יכולים להיגרם ממקרי קצה עם נתונים שלא נלקחו בחשבון, או מדפוסי גישה של המשתמשים שלא נבדקו. חשוב לעקוב אחרי האפליקציה בסביבת הייצור ולהגדיר מנגנונים אוטומטיים להחזרה למצב קודם ולפריסה, כדי שתוכלו להגיב במהירות ולתקן באגים או הפסקות זמניות בפעילות. שימוש באסטרטגיות פריסה חזקות יותר מאפשר לכם לצמצם את ההשפעה של הבעיות, כך שפחות משתמשי קצה יושפעו כשהבעיות יצוצו בסביבת הייצור.
סיכום רשימת המשימות
בטבלה הבאה מפורטות המשימות שמומלץ לבצע כשמשתמשים בצינור עיבוד נתונים של CI/CD ב-GKE:
| אזור | Tasks |
|---|---|
| אינטגרציה רציפה (CI) |
|
| פיתוח רציף (continuous delivery) |
|