במאמר הזה מתואר מסגרת להטמעה של תהליכי אינטגרציה רציפה (CI) ופיתוח רציף (CD) מודרניים בפלטפורמה לפיתוח תוכנה שמיועדת לכמה צוותים ומשתמשת ב-Google Kubernetes Engine.
לאחר מכן תוכלו לבצע איטרציות בפלטפורמה כדי לשפר עוד יותר את הביצועים של הפיתוח והתפעול, כולל מהירות ההפצה, מהימנות הפלטפורמה וזמן ההתאוששות מכשלים.
המסמך הזה הוא חלק מסדרה:
מודרניזציה של CI/CD באמצעות GKE: מסגרת להכנת תוכנה להפצה (המסמך הזה)
CI/CD מודרני עם GKE: בניית מערכת CI/CD (ארכיטקטורת עזר)
המסמך הזה מיועד לאדריכלים ארגוניים ולמפתחי אפליקציות, וגם לצוותי אבטחת IT, DevOps ו-Site Reliability Engineering. כדי להבין את המושגים שמוסברים במסמך הזה, כדאי שיהיה לכם ניסיון מסוים עם כלים ותהליכים אוטומטיים לפריסה.
למה כדאי להשתמש ב-CI/CD מודרני
CI/CD היא גישה לפיתוח תוכנה שמאפשרת לבצע אוטומציה של שלבי הבנייה, הבדיקה והפריסה של פיתוח תוכנה באמצעות מספר כלים ותהליכים שניתנים לחזרה.
בנוסף לאוטומציה של CI/CD, Kubernetes וקונטיינרים מאפשרים לארגונים להשיג שיפורים חסרי תקדים במהירות הפיתוח והפריסה. עם זאת, למרות השימוש הגובר ב-Kubernetes ובקונטיינרים, ארגונים רבים לא ממצים את היתרונות של מהירות השחרור, היציבות והיעילות התפעולית, כי שיטות ה-CI/CD שלהם לא מנצלות את היתרונות של Kubernetes או לא נותנות מענה לדאגות לגבי תפעול ואבטחה.
גישה מודרנית אמיתית ל-CI/CD צריכה לכלול יותר מאוטומציה בלבד. כדי לממש באופן מלא את השיפורים במהירות ובאבטחה, ולהשתמש ביכולות של Kubernetes ושל קונטיינרים, צריך לייעל את תהליך ההצטרפות של האפליקציה, את שיטות העבודה המומלצות של CI/CD ואת התהליכים התפעוליים.
השימוש בתשתית העקבית שמציעה פלטפורמת GKE, בשיטות אחידות של CI/CD ובשיטות מומלצות להטמעה, מאפשר לארגון שלכם ליהנות מהיתרונות הבאים בתחום הפיתוח והתפעול:
קיצור זמן הביצוע לשינויים.
צוותי התפעול והאבטחה יכולים ליצור ולעדכן שיטות מומלצות להקצאת הרשאות לאפליקציות ולמדיניות הקצאת הרשאות בפלטפורמה.
לפשט את תהליך ההצטרפות של אפליקציות על ידי מתן פרויקטים ראשוניים שניתנים לפריסה ופועלים באופן מלא לצוותים, עם שיטות מומלצות של הארגון שמוטמעות בהם.
קיצור הזמן הנדרש לשחזור השירות.
ניהול כל ההגדרות באופן הצהרתי באמצעות GitOps כדי לפשט את הביקורת, את החזרה לגרסה קודמת ואת הבדיקה.
כדי לקצר את הזמן שנדרש לזיהוי הגורמים לבעיה שמשפיעה על השירות, כדאי להשתמש בשיטות פריסה ומעקב סטנדרטיות בכל הארגון.
הגדלת תדירות הפריסה.
מוודאים שמפתחי האפליקציות יכולים לבצע איטרציות באופן עצמאי בארגזי חול משלהם לפיתוח (או באזורי נחיתה) בלי להפריע זה לזה.
כדאי להשתמש ב-GitOps לפריסה, לשיפור ניהול הגרסאות ולמעקב אחרי שינויים.
כדאי להטמיע אמצעי הגנה כדי לאפשר לצוותי השירות לפרוס לעיתים קרובות.
ליצור תהליך הדרגתי של השקה כדי לפרוס באופן עקבי בסביבות טרום-ייצור, וכך לאפשר למפתחים לבצע שינויים בייצור בביטחון.
כדי להבין איך ההטבות והמושגים האלה באים לידי ביטוי ב-GKE וב-CI/CD, כדאי לעיין במסמכים האחרים בסדרה הזו:
הערכת המוכנות לגישה מודרנית
לפני שמטמיעים כלים ותהליכים מודרניים של CI/CD באמצעות GKE, צריך להעריך אם הארגון והצוותים מוכנים לאמץ פלטפורמה חדשה.
מאפיינים ארגוניים
כדי לאמץ פלטפורמה מודרנית, צוותי ההנהלה והצוותים הטכניים של העסק צריכים לספק את התמיכה הבאה:
אחראי בכיר. הטמעה של פלטפורמה להכנת תוכנה להפצה היא בדרך כלל מאמץ גדול שמתבצע על ידי כמה צוותים רב-תחומיים. בדרך כלל התהליך הזה מוביל לשינויים בתפקידים ובאחריות, וגם בשיטות לפיתוח תוכנה. כדי להצליח בהטמעה של הכלים והטכניקות האלה, אתם צריכים תמיכה חזקה מחבר אחד או יותר בצוות הניהול. הספונסרים האפקטיביים ביותר בדרגת מנהיגות הם אלה שרואים בשינויים האלה תהליך שיפור מתמשך, ורוצים להעצים את הצוותים שלהם במקום לנהל אותם.
התאמה בין אסטרטגיה טכנית לאסטרטגיה עסקית. מומלץ שהצוותים העסקיים והצוותים הטכניים יתמקדו בארבעת המדדים העיקריים של הכנת תוכנה להפצה שמוגדרים על ידי DevOps Research and Assessment (DORA): זמן האספקה לשינויים, תדירות הפריסה, הזמן לשחזור השירות ושיעור הכשלים בשינויים. הסכמה על המדדים האלה מאפשרת לצוותים העסקיים ולצוותים הטכניים שלכם להגדיר יעד משותף, לחשב יחד את ההחזר על ההשקעה, לשנות את קצב השינוי ולשנות את רמת ההשקעה.
מקורות מידע. כדי להצליח, צוותים שמפתחים שיטות עבודה מודרניות של CI/CD ובוחרים כלי שרשרת צריכים את המשאבים הנדרשים: זמן, אנשים ותשתית. הצוותים האלה צריכים זמן כדי לנסות ולבחור את התהליכים והכלים הכי טובים. הצוותים האלה מייצגים באופן אידיאלי פונקציות רבות ושונות בתהליך אספקת התוכנה, ויכולים למשוך משאבים אחרים מכל רחבי הארגון. לבסוף, הצוותים צריכים את היכולת להקצות תשתית, כולל משאבי ענן וכלי תוכנה.
פתיחות לאימוץ כלים חדשים. לעתים קרובות, כלים וטכניקות מודרניים של CI/CD מגיעים עם כלים ותהליכים חדשים. הצוותים צריכים להתנסות בתהליכים ובכלים האלה ולהיות פתוחים לאימוץ שלהם. נדרש לולאת משוב כדי שצוותי הפלטפורמה יוכלו לקבל משוב מצוותי האפליקציות, התפעול והאבטחה שמשתמשים בפלטפורמה.
מוכנות תרבותית. כדי להצליח בהטמעה של מערכת CI/CD מודרנית עם GKE, הארגון והצוותים הטכניים שמפתחים את המערכת צריכים להיות מוכנים לשנות את אופן הפעולה והעבודה המשותפת שלהם. לדוגמה, צוותי פיתוח ותפעול צריכים להיות מוכנים לקחת על עצמם אחריות רבה יותר על האבטחה, וצוותי אבטחה ותפעול צריכים להיות מוכנים לייעל את תהליכי אישור השינויים.
יכולות טכניות
כדי לאמץ גישה מודרנית ל-CI/CD, הצוותים שלכם צריכים להיות מוכנים מבחינה טכנית באופן הבא:
ניסיון עם קונטיינרים. צוותים שמאמצים גישות מודרניות של CI/CD צריכים ניסיון מסוים עם קונטיינרים. החוויה הזו כוללת באופן אידיאלי טכניקות פיתוח לבניית תמונות קונטיינר ושילוב קונטיינרים לבניית מערכות גדולות יותר.
אסטרטגיית אינטגרציה רציפה (CI). הצוותים צריכים להיות בעלי ניסיון בשימוש בכלים של CI (כמו Jenkins, TeamCity, Bamboo ו-CircleCI) ובביצוע של שילוב רציף ובדיקות אוטומטיות. מומלץ לארגונים לתכנן איך לשפר עוד יותר את התהליכים האלה.
אוטומציה של פריסה. הצוותים צריכים להיות בעלי ניסיון באוטומציה של פריסה. דוגמאות לכלים אוטומטיים לפריסה כוללות סקריפטים בסיסיים של מעטפת, Terraform, Chef או Puppet. ידע בסיסי בתהליכים ובכלים אוטומטיים לפריסה הוא חיוני כדי לייעל את הפריסות ולהפוך אותן לאוטומטיות.
ארכיטקטורות מוכוונות-שירות. זה לא תנאי מוקדם לאימוץ תהליכי CI/CD מודרניים, אבל אימוץ של ארכיטקטורות מודולריות ומוכוונות-שירות צריך להיות מטרה לטווח ארוך של ארגונים שרוצים לאמץ כלים וטכניקות מודרניים של CI/CD עם GKE. ארכיטקטורות מבוססות-שירותים משפרות את קצב ההתקדמות במשפך השיווק והאמינות.
שליטה מודרנית במקורות. כלים מודרניים לניהול גרסאות כמו Git מאפשרים לצוותים להגדיר תהליכי עבודה כמו פיתוח מבוסס-trunk, הסתעפויות של תכונות ובקשות מיזוג.
עיצוב CI/CD מודרני באמצעות GKE
בקטע הזה מוסבר על פלטפורמה להכנת תוכנה להפצה ועל הרכיבים שלה. כדי לשפר את רמת הביצועים של הכנת תוכנה להפצה, צריך להטמיע CI/CD ושיטות מומלצות טכניות אחרות שיאפשרו לצוותים להפיץ תוכנה במהירות ולפעול ביעילות.
בקטע הזה נדון גם בתשתית שנדרשת לתמיכה במחזור החיים של אספקת התוכנה, ואיך אפשר לנהל את התשתית הזו באופן עקבי באמצעות GKE. בסוף, בקטע הזה מופיעה דוגמה לתהליך עבודה של הכנת תוכנה להפצה, ומוסבר איך מאגרי התחלה מפשטים את תהליך ההצטרפות והיישום של שיטות מומלצות. השיקולים הבאים לעיצוב נבדקים:
פלטפורמה להכנת תוכנה להפצה. ה-framework והיכולות הטכניות שמהווים את הבסיס לתהליך מהיר ואמין של פרסום אפליקציות.
תשתית הפלטפורמה. רכיבי התשתית ושיקולי הניהול שצריך לקחת בחשבון כשבונים את הפלטפורמה ומריצים את האפליקציות.
תהליך עבודה של הכנת תוכנה להפצה. איך צוותים עובדים יחד כדי לבנות, לבדוק ולפרוס קוד בצורה יעילה יותר.
מאגרי קודים. מאגרי מידע שמבצעים כמה פונקציות, כולל אחסון של הלוגיקה העסקית בפועל, הגדרה ספציפית לאפליקציה וקוד לבניית תשתית. יכול להיות שיהיו גם מאגרי קוד התחלתיים שיעזרו לכם לאמץ שיטות מומלצות ולשמור על עקביות בתהליכים אוטומטיים.
אזורי נחיתה של אפליקציות. ישות לוגית שמאפשרת למפתחים לפרוס את האפליקציות שלהם ולבצע בהן איטרציות באופן אוטונומי, תוך שימוש באמצעי הבקרה שהגדרתם.
מודל הפעלה. כלים, תהליכים ושיטות טכניים לניהול התשתית והאפליקציות שמרכיבות את הפלטפורמה.
משילות. תהליכים ושיקולים שצריך לשמור ולנהל בפלטפורמה להכנת תוכנה להפצה.
פלטפורמות להכנת תוכנה להפצה
פלטפורמה להכנת תוכנה להפצה מאחדת את הכלים ומייעלת את התהליכים שנדרשים לבנייה, להפצה, לפריסה ולהפעלה של אפליקציות.
האחריות לתחזוקה של ההגדרה, היציבות, זמן הפעולה וההתאמה של אפליקציה משתנה בין צוותי התפעול, האבטחה והפיתוח, אבל כל הרכיבים והצוותים צריכים לעבוד יחד כדי להאיץ את ההשקות. במאמר הזה מתוארות שיטות לשיפור הניהול של בקרת המקורות והיכולת של האפליקציה לספק נתונים על מצבה (observability), אבל הוא מתמקד בעיקר באינטגרציה רציפה (CI), בפיתוח רציף (CD) ובניהול תצורה.
כדי לבנות פלטפורמה מלאה להכנת תוכנה להפצה, צריך את כל הרכיבים שמופיעים בדיאגרמה הבאה:
כל אחד מהרכיבים האלה מספק פונקציונליות למערכת ולאפליקציות שפועלות בפלטפורמה:
מעקב אחר תשתיות. רמת הבסיס של המעקב שנדרשת כשמבצעים הקצאת משאבים כדי לוודא את הפעולה התקינה של אשכולות Google Kubernetes Engine (GKE), מכונות וירטואליות (VM) ותשתית אחרת שנדרשת כדי שהאפליקציות יפעלו.
תזמור קונטיינרים. הפלטפורמה שמתאמת את הפריסה וההפעלה של אפליקציות מבוססות-קונטיינרים. דוגמאות לפלטפורמות לתזמור קונטיינרים הן Kubernetes, GKE או GKE Enterprise.
Container registry. האחסון ובקרת הגישה לתמונות של קונטיינרים.
CI. התהליך של החלת משימות אוטומטיות על אפליקציה לפני הפריסה. משימות CI כוללות בדרך כלל בנייה, אריזה ובדיקה. סוגי המשימות משתנים בהתאם לאפליקציה ולארגון.
CD. תהליכי פריסה אוטומטיים מאוד שמופעלים בתדירות גבוהה. דוגמאות למתודולוגיות: אישורים ידניים, פריסות קנריות, פריסות כחולות-ירוקות או פריסות מתגלגלות.
מדיניות. מדיניות אבטחה ומדיניות תצורה של התשתית שמוגדרות על ידי צוותי התפעול והאבטחה, ומיושמות ונאכפות באופן רציף על ידי הפלטפורמה.
ניהול קוד מקור. לדוגמה, אחסון עם בקרת גרסאות לקוד, לקובצי תצורה ולהגדרות מדיניות. במערכת CI/CD מודרנית, ניהול קוד המקור מתבצע בדרך כלל באמצעות Git.
ניהול הגדרות. המערכת שמשמשת לאחסון ולהחלה של הגדרות אפליקציה בסביבות שונות.
ניראות האפליקציה. רישום ביומן, מעקב, התראות ומעקב אחר נתונים ברמת האפליקציה, שצוותי המפתחים, המפעילים והאבטחה משתמשים בהם כדי לפתור בעיות ולוודא שהאפליקציות פועלות בצורה תקינה.
תשתית הפלטפורמה
כדי לבנות פלטפורמה ניתנת להרחבה להכנת תוכנה להפצה, צריך אשכולות Kubernetes לפיתוח, לסביבות טרום-ייצור ולמספר אשכולות ייצור. אפשר להשתמש באשכולות למגוון רחב של פונקציות:
פיתוח. באשכולות האלה, מפתחים מבצעים פריסות אד-הוק של האפליקציות שלהם לצורך בדיקה וניסוי.
סביבת האפליקציה.
קדם-הפקה. לכל סביבת טרום-ייצור בתהליך העבודה, צריך להיות אשכול Kubernetes לאירוח האפליקציות. האשכולות האלה צריכים להיות דומים לאשכולות של סביבת הייצור, כדי שתוכלו לצמצם או לבטל את ההבדלים בין הסביבות וכך לשפר את שיעורי ההצלחה של הפריסה.
הפקה. האשכולות האלה מריצים את עומסי העבודה של הייצור. מומלץ להשתמש בכמה אשכולות שמפוזרים גיאוגרפית. הפעולה הזו משפרת את האמינות במקרה של כשלים בתשתית, ומקלה על פעולות ביום השני, כמו שדרוגים והרחבה של אשכולות.
התרשים הבא מציג את הארכיטקטורה ברמה גבוהה:
בארכיטקטורה הזו, אתם מנהלים את האשכולות של כל סביבה באמצעות Config Sync. הגדרת אשכול עקבית היא קריטית כי היא נותנת לצוותי המפתחים, התפעול והאבטחה ביטחון בכך שסביבות טרום-ייצור וייצור פועלות בצורה דומה. אפשר להשתמש ב-Config Sync כדי לאחסן ולהחיל הגדרות נפוצות בכל קבוצת האשכולות. אחרי שהגדרתם את האשכול בצורה סטנדרטית, שניתנת לביקורת וניתנת להרחבה, תוכלו להתמקד בתהליך העבודה של אספקת התוכנה, בהטמעה ובפריסה של אפליקציות.
אתם מנהלים את הפריסות שלכם באשכולות פיתוח, באשכולות של סביבת ביניים ובאשכולות של סביבת ייצור באמצעות צינורות CI/CD של האפליקציה. ניהול בקרת המקור משמש כנקודת התיאום של קוד האפליקציה וההגדרה שלה. צינורות ה-CI/CD וקובצי האימג' בקונטיינרים של אפליקציה מסוימת מבודדים בסביבה של אותה אפליקציה. אתם מאתחלים מאגרי תצורות ואפליקציות באמצעות מאגרי התחלה וכלים אוטומטיים. לדוגמה, אפשר להשתמש ב-Cloud Build כדי להריץ את Terraform כדי להוסיף ולהפעיל אוטומטית אפליקציות חדשות.
אתם פורסים אפליקציות באזורי נחיתה משלהן בכל אשכול, כך שהאפליקציות מבודדות מהרשת ומהזהות. אתם מאתחלים אזורי נחיתה של אפליקציות בסביבות שונות באמצעות סנכרון תצורות, ומשתמשים ב-Cloud Service Mesh או ב-Multi Cluster Ingress כדי לגרום לאשכולות הייצור להיראות כאשכול אחד על ידי יצירת רשת Mesh שמשתרעת על פני אשכולות רבים.
תהליך עבודה של הכנת תוכנה להפצה
רכיב מרכזי בפלטפורמה להכנת תוכנה להפצה הוא מערכת CI/CD. כשמפתחי פלטפורמות מתחילים להגדיר את תהליך ה-CI/CD, הם צריכים לוודא שכל רכיב יוצר או צורך ארטיפקטים שתואמים לממשק סטנדרטי. שימוש בממשק סטנדרטי מפשט את החלפת הרכיבים כשיישום טוב יותר יוצא לשוק.
כשיוצרים פלטפורמה לאפליקציות מבוססות-קונטיינרים, אפשר להשתמש בשלושה ממשקים סטנדרטיים בין רכיבים: מאגרי Git, תמונות Docker ומניפסטים של Kubernetes. הממשקים האלה מאפשרים ליצור צינור עיבוד נתונים של CI/CD שניתן לשימוש חוזר וגמיש, עם תהליך עבודה של פיתוח, בנייה ושחרור, כמו שמוצג בתרשים הבא:
תהליך העבודה הזה פועל באופן הבא:
המפתחים מבצעים קומיט של קוד האפליקציה למאגרי הקוד.
מערכת ה-CI בודקת את הקוד, יוצרת ארטיפקט של קובץ אימג' של Docker ומאחסנת את הארטיפקט במאגר.
אחרי שהארטיפקט מוכן לפריסה, מתווסף אליו הפניה להגדרת האפליקציה.
הגדרת האפליקציה הזו מוצגת בפורמט שניתן לקריאה ב-Kubernetes ומאוחסנת במאגר קוד. עדכונים במאגר הזה מפעילים צינור פריסה שפורס את הארטיפקטים בסביבת פיתוח משולבת.
אחרי שמסיימים את הבדיקה בסביבת הפיתוח המשולבת, המפעילים מעבירים את הפריסה לסביבת טרום-הייצור.
אחרי שמוודאים שהאפליקציה פועלת כמו שצריך בסביבת טרום-ייצור, המפעילים מקבלים את האישורים בצינור הפריסה ומקדמים את הגרסה לסביבת הייצור.
כשאופרטורים מבצעים שינויים בהגדרות הבסיסיות, השינויים האלה חלים על כל הארגון. כשאופרטורים מבצעים שינויים במאגרי המידע שלהם, אפשר להפעיל עדכונים אוטומטיים של הגדרות האפליקציה (ופריסות בעקבותיהם). לחלופין, השינויים של המפעילים יכולים להיקלט בפעם הבאה שהמפתחים יפרסו את השינויים שלהם.
במקביל, מהנדסי אבטחה יכולים להטמיע ולשנות מדיניות שמגדירה מה אפשר לפרוס, ואז להוסיף את המדיניות הזו למאגר המדיניות שלהם.
באמצעות מתודולוגיית GitOps, אתם יכולים לדרוש גישה הצהרתית לכל שינוי באפליקציות ובאשכולות. בגישה הזו, כל השינויים נבדקים ומבוקרים לפני שהם נאכפים. במודל ההצהרתי הזה, שומרים את קובצי ההגדרות במאגר Git, וכך אפשר לשמור יומן שינויים, לבטל פריסות שנכשלו ולראות את ההשפעה הפוטנציאלית של השינויים המוצעים.
בארכיטקטורת ההפניה המשויכת, אתם משתמשים ב-kustomize כדי לשלוט בהגדרות של האפליקציות בארגון. kustomize
הכלי מאפשר למפעילים ליצור בסיסים של הגדרות אפליקציה, שצוותי הפיתוח יכולים לשנות בלי להוסיף או לשנות קוד בבסיס. הגדרת תצורות בסיסיות מאפשרת לצוותי הפלטפורמה ליצור שיטות מומלצות לארגון ולשפר אותן. מפעילים ומפתחים יכולים לבצע איטרציות בפריסות שלהם באופן עצמאי, והמפתחים יכולים ליישם את השיטות המומלצות שהוגדרו על ידי המפעילים. כשמנהלים צריכים להטמיע שיטה מומלצת חדשה בארגון, הם מבצעים את השינוי בבסיס, והשינוי נמשך באופן אוטומטי עם הפריסה הבאה של המפתחים.
מאגרי קודים
מאגרים של קוד מקור הם הליבה של מערכת CI/CD. למפעילים, למפתחים ולמהנדסי אבטחה יש מאגרים משלהם להפצת שינויים בפלטפורמה. שימוש במאגר Git כבסיס לכל השינויים במערכת מספק כמה יתרונות:
יכולת מובנית לביצוע ביקורת. הקובץ מכיל מידע על מתי, מה ומי שינה את המערכת.
תהליך פשוט יותר לחזרה לגרסה הקודמת. האפשרות 'חזרה לגרסה קודמת' ב-Git מאפשרת לחזור למצב קודם של המערכת.
ניהול גרסאות אפשר לתייג קומיטים ב-Git כדי לציין גרסה של מצב המערכת.
עסקאות. כדי לשלב את השינויים במצב, צריך לפתור באופן מפורש את העימותים בין המצבים ולבדוק אותם.
הדיאגרמה הבאה מציגה כיצד צוותים שונים מקיימים אינטראקציה עם מאגר מרכזי עבור כל השינויים:
בקטעים הבאים מוסבר איך מפעילים, מפתחים ומהנדסי אבטחה משתמשים במאגר Git במערכת CI/CD מודרנית.
מאגרי אופרטורים
מאגרי מידע שמנוהלים על ידי אופרטורים מכילים שיטות מומלצות ל-CI/CD ולתצורת אפליקציות, כדי לעזור לצוותים שלכם להטמיע אפליקציות תוך אימוץ שיטות מומלצות ארגוניות מההתחלה. כשהמפעילים מנהלים את המאגרים, המפתחים יכולים להשתמש בכל העדכונים של השיטות המומלצות הארגוניות עם כמה שפחות שיבושים בתהליך העבודה שלהם.
מפעילים יכולים לקודד את השיטות המומלצות של הארגונים שלהם בשני מאגרי מידע. המאגר הראשון הוא המקום שבו האופרטורים מתחזקים שיטות מומלצות משותפות לצינור עיבוד נתונים של CI/CD. במאגר הזה, אופרטורים מספקים למפתחים ספרייה של משימות מוגדרות מראש שבהן הם יכולים להשתמש כדי לבנות את צינורות העיבוד שלהם. מאגרי האפליקציות של המפתחים יקבלו בירושה את המשימות האלה ואת הלוגיקה שבהן באופן אוטומטי, ולא יהיה צורך להעתיק את המשימות באופן ידני. דוגמאות למשימות שאפשר להגדיר כסטנדרט בארגון:
יצירה ואחסון של ארטיפקטים
מתודולוגיות בדיקה לשפות שונות
שלבי הפריסה
בדיקות מדיניות
סריקת אבטחה
מאגר המידע השני שמפעילים מתחזקים כולל שיטות מומלצות להגדרת אפליקציה. בהקשר של GKE, השיטות המומלצות כוללות הקפדה על דרך לניהול מניפסטים הצהרתיים במודל המשאבים של Kubernetes. קובצי המניפסט האלה מתארים את המצב המיועד של האפליקציה. מפעילים יכולים ליצור הגדרות בסיסיות לסוגים שונים של אפליקציות, וכך לספק למפתחים דרך יעילה לפריסת האפליקציות שלהם בהתאם לשיטות המומלצות של הארגון.
מאגרי אפליקציות
מאגרי אפליקציות מאחסנים את הלוגיקה העסקית של האפליקציה וכל הגדרה מיוחדת שנדרשת כדי שהאפליקציה תפעל בצורה תקינה.
מפתחים יכולים להשתמש בשיטות המומלצות שנוצרו על ידי האופרטורים, כי הן מתועדות בצורה ברורה. כדי לעשות זאת, המפתחים מתייחסים למשימות של CI/CD ולבסיסי האפליקציות שהאופרטורים יצרו במאגרים שלהם. אחרי שהמפתחים מבצעים את השינויים שלהם, המפעילים יכולים להתאים אישית עוד יותר את הפריסה של האפליקציה על ידי הוספת הגדרות ספציפיות לסביבה, כמו כתובות URL של מסדי נתונים או תוויות וביאורים של משאבים.
דוגמאות לארטיפקטים שאפשר לאחסן במאגרי אפליקציות:
קוד המקור של האפליקציה
Dockerfileשמתאר איך ליצור ולהריץ את האפליקציהההגדרה של צינור עיבוד הנתונים של CI/CD
תוספים או שינויים בבסיסי הגדרות האפליקציה שנוצרו על ידי אופרטורים
מאגרי תשתית כקוד
מאגרי תשתית כקוד מאחסנים את הקוד לבניית התשתית שנדרשת להרצת האפליקציות. התשתית עשויה לכלול פלטפורמות של רשתות ושל ניהול קונטיינרים, כמו GKE. בדרך כלל, מאגרי המידע האלה נמצאים בבעלות של אדמינים של תשתיות. מפעילים יכולים לעדכן אותם כדי ליישם שיטות מומלצות.
דוגמאות לארטיפקטים שאפשר לאחסן במאגרי אפליקציות:
- קוד שפה הצהרתית (Terraform, Pulumi) שמייצג אובייקטים של תשתית.
סקריפטים של Shell או Python שמשלימים את הגדרות ה-API הדקלרטיביות.
הרחבות או שינויים בתבניות של תשתית הבסיס שנוצרו על ידי צוות התשתית.
מאגרי תצורה ומדיניות
הבטחת פלטפורמה עקבית עם אבטחה משופרת היא בראש סדר העדיפויות של המפעילים ומהנדסי האבטחה.
הגדרות אישיות
הגדרות מרכזיות מאפשרות להפיץ שינויים בהגדרות בכל המערכת. אלה כמה פריטי הגדרות נפוצים שאפשר לנהל באופן מרכזי:
מרחבי שמות של Kubernetes
מכסות
אמצעי בקרה על גישה מבוססת-תפקידים (RBAC)
כללי מדיניות הרשת
חשוב לאכוף את סוגי ההגדרות האלה באופן עקבי בכל האשכולות, כדי שצוותי האפליקציות לא ישתמשו בתשתית לרעה. שימוש במאגר Git לאחסון הגדרות יכול לשפר תהליכים כמו ביקורת ופריסת הגדרות באמצעות שיטות כמו GitOps. כלים כמו סנכרון תצורות יכולים לפשט את התהליך של החלת הגדרות באופן אחיד בתשתית.
מדיניות
מכיוון שמפתחים יכולים להרחיב את הגדרות הבסיס שאופרטורים יוצרים, צריך דרך להגביל את המשאבים שנוצרים באשכולות שמרכיבים את הפלטפורמה. במקרים מסוימים, יכול להיות שתיצרו מדיניות שתאפשר למפתחים ליצור משאבים רק אם הם עומדים בדרישות ספציפיות – לדוגמה, יצירת אובייקטים של Kubernetes Service שלא ניתן להגדיר עבורם איזון עומסים חיצוני.
באמצעות Policy Controller, אפשר לאכוף מדיניות בארכיטקטורת ההפניה המשויכת.
מאגרי נתונים למתחילים
מאגרי קוד למתחילים עוזרים להטמיע שיטות מומלצות ל-CI/CD, לתשתית ולפיתוח בפלטפורמה. מאגרי תבניות יכולים לצמצם באופן משמעותי את העלויות שקשורות לאימוץ שיטות מומלצות. השיטות המומלצות עוזרות לשפר את מהירות הפיתוח, האמינות והפרודוקטיביות של הצוות. בארכיטקטורת העזר המשויכת, יש כמה מאגרי קוד ראשוניים ל-CI/CD, להגדרות של Kubernetes, ל-Go, ל-Java ול-Python, וגם אפליקציות ותשתית ראשוניות.
אינטגרציה רציפה (CI)
בדרך כלל, לארגונים יש קבוצה סטנדרטית של משימות שמוחלות על אפליקציות במהלך CI. לדוגמה, בהטמעה לדוגמה, קבוצת הבסיס של שלבי ה-CI היא הבאה: קומפילציה של קוד ויצירת קובץ אימג' של קונטיינר. השלבים האלה מוגדרים במאגר התבניות, ולכן הם חלים באופן אחיד בכל הפלטפורמה. צוותים של אפליקציות ספציפיות יכולים להוסיף שלבים נוספים.
פיתוח רציף (continuous delivery)
בדומה ל-CI, התהליך של CD כולל בדרך כלל קבוצה סטנדרטית של שלבים לפריסת אפליקציות דרך סביבות הפיתוח, טרום הייצור והייצור. לא משנה באילו מתודולוגיות פריסה משתמשים, מאגר התבניות מאפשר לצוותי פלטפורמה להחיל את המתודולוגיות האלה באופן אחיד על אפליקציות וסביבות שונות. ביישום ההפניה, תהליך הפריסה כולל השקות של פריסות פיתוח, פריסות לפני ייצור, פריסת ייצור בכמה אשכולות ואישורים ידניים לפריסת הייצור באמצעות Cloud Deploy.
הגדרת אפליקציה
כדי שפלטפורמה להפצת תוכנה תהיה יעילה, צריך דרך אחידה ועקבית להחלת הגדרות האפליקציה. באמצעות כלים כמו kustomize ומאגרי התחלה להגדרות Kubernetes, פלטפורמות יכולות לספק בסיס עקבי להגדרת אפליקציות. לדוגמה, ביישום ההפניה, kustomize תצורת הבסיס מאתחלת את מאגרי הסביבה של האפליקציה עם קבוצת תצורות בסיסית מוכרת וטובה. צוותי פיתוח של אפליקציות יכולים להתאים את ההגדרות לצרכים שלהם.
אפליקציות למתחילים
אפליקציות למתחילים יכולות לעזור לכם לצמצם את התקורה שקשורה לאימוץ שיטות מומלצות – לדוגמה, שיטות מומלצות לניראות (observability) ולשימוש בקונטיינרים.
ניראות (observability). כדי להפעיל אפליקציה בצורה יעילה ולשמור על האמינות שלה, צריך להביא בחשבון את הרישום ביומן, המדדים והמעקב. אפליקציות Starter עוזרות לצוותים לבנות מסגרות ואסטרטגיות שמקדמות יכולת צפייה.
שיטות מומלצות לשימוש במאגרי תגים כשיוצרים אפליקציות בקונטיינרים, מומלץ ליצור קובצי אימג' קטנים ונקיים של קונטיינרים. השיטות המומלצות לשימוש בקונטיינרים כוללות אריזה של אפליקציה אחת בקובץ אימג', הסרה של כלים מיותרים מהקובץ וניסיון ליצור קבצים קטנים מתוך קבצים בסיסיים מינימליים.
ארכיטקטורת ההפניה מספקת אפליקציית Go בסיסית, אפליקציית Java בסיסית ואפליקציית Python בסיסית כנקודת התחלה. מומלץ להוסיף אפליקציות למתחילים שמותאמות לשפות, לסטאק התוכנות ולסוגי האפליקציות שהצוותים שלכם מפתחים.
מאגרי תשתית למתחילים
מאגרי התחלה של תשתית כוללים קוד שנכתב מראש ונדרש ליצירת רכיבי תשתית שונים. המאגרים האלה משתמשים בתבניות ובמודולים סטנדרטיים, כפי שהוחלט על ידי צוות התשתית.
לדוגמה, בהטמעה לדוגמה, platform-template מכיל את קוד לתחילת הדרך לבניית Google Cloud פרויקט, ענן וירטואלי פרטי (VPC) ואשכול GKE. בדרך כלל צוותי תשתית משתמשים בתבנית הזו כדי לנהל את התשתית שמשמשת כמה צוותים של אפליקציות כמשאב משותף. באופן דומה, infra-template מכיל קוד בסיסי של תשתית התחלתית שאפליקציה עשויה לדרוש, למשל, Cloud Storage או מסד נתונים של Spanner. צוותי האפליקציות משתמשים בדרך כלל בתבנית הזו כדי לנהל את התשתית של האפליקציות שלהם.
מאגרי תבניות משותפים
מאגרי תבניות משותפים מספקים תבניות סטנדרטיות של משימות שכל אחד בארגון יכול לעשות בהן שימוש חוזר. לדוגמה, מודולים של תשתית כקוד כמו מודולים של Terraform שאפשר להשתמש בהם כדי ליצור משאבי תשתית כמו רשתות וחישובים.
אזורי נחיתה של אפליקציות
כשמשתמשים ב-CI/CD משותף, בהגדרת אפליקציה משותפת ובמדיניות ובהגדרות עקביות בכל האשכולות, אפשר לשלב את היכולות האלה כדי ליצור אזורי נחיתה של אפליקציות.
אזור נחיתה הוא ישות לוגית נעולה שמאפשרת למפתחים לפרוס את האפליקציות שלהם ולבצע בהן איטרציות. אזורי נחיתה של אפליקציות משתמשים באמצעי הבקרה שהגדרתם כדי שהמפתחים יוכלו לפעול באופן אוטונומי. לכל אפליקציה, יוצרים מרחב שמות של Kubernetes בכל אשכול של כל סביבה (לדוגמה, לייצור, לפיתוח או ל-staging). העקביות הזו עוזרת למפעילים לנפות באגים בסביבות ולתחזק אותן לאורך זמן.
התרשים הבא ממחיש את הרעיון של אזורי נחיתה:
מודל הפעלה
כשמפעילים פלטפורמה להפצת תוכנה עם CI/CD מודרני, חשוב לשמור על עקביות ועדכניות של הסביבות, התשתיות והתהליכים. לכן, חשוב לתכנן בקפידה ולבחור את מודל ההפעלה של הפלטפורמה. אפשר לבחור מתוך מגוון מודלים, כמו אשכולות כשירות, תוכניות או תשתית מרובת דיירים.
מכיוון שחשוב לשמור על תשתית עקבית, להגביל את ההתפשטות ולאפשר לצוותים להתמקד באספקת אפליקציות, אנו ממליצים לפרוס תשתית מרובת דיירים. פריסת אפליקציות בתשתית מרובת דיירים מבטלת את הצורך של צוותי האפליקציות לנהל את התשתית, ומאפשרת לצוותי התפעול והאבטחה להתמקד בשמירה על עקביות התשתית.
שיקולים לגבי תשתית של דירות שותפים
כשיוצרים פלטפורמה להכנת תוכנה להפצה עם ריבוי דיירים, יש כמה דברים שכדאי להוסיף לפלטפורמה:
בידוד של עומסי עבודה. הרעיון של אזורי נחיתה לאפליקציות הוא לספק מסגרת לבידוד עומסי עבודה. אזורי נחיתה הם שילוב של מרחבי שמות, מדיניות רשת ו-RBAC. צריך לנהל את כל כללי המדיניות האלה באופן מרכזי ולהחיל אותם באמצעות סנכרון תצורות.
מעקב אחר השימוש בדייר. כדי לקבל פירוט עלויות של מרחבי שמות ותוויות ספציפיים באשכול, אפשר להשתמש במדידת השימוש ב-GKE. מדידת השימוש ב-GKE עוקבת אחרי מידע על בקשות למשאבים ועל השימוש במשאבים של עומסי עבודה באשכול, ואפשר לסנן את המידע הזה לפי מרחבי שמות ותוויות. כשמפעילים את מדידת השימוש ב-GKE באשכול מרובה דיירים, רשומות השימוש במשאבים נכתבות בטבלה ב-BigQuery. אתם יכולים לייצא מדדים ספציפיים לדייר למערכי נתונים ב-BigQuery בפרויקט הדייר המתאים, ואז מבקרים יכולים לנתח את המדדים האלה כדי לקבוע את פירוט העלויות.
מכסות משאבים. כדי להבטיח שלכל הדיירים שמשתפים אשכול תהיה גישה הוגנת למשאבי האשכול, צריך לאכוף מכסות משאבים. יוצרים מכסת משאבים לכל מרחב שמות על סמך מספר ה-Pods שכל דייר פורס, וכמות הזיכרון וה-CPU שכל Pod דורש.
כמה אשכולות לכל סביבה. כדי לשפר את המהימנות של האפליקציה והפלטפורמה, מומלץ להשתמש בכמה אשכולות לכל סביבת טרום-ייצור וייצור. אם יש כמה אשכולות זמינים, אפשר להשיק אפליקציות באשכולות בנפרד כדי לבצע אימות קנרי נוסף. בנוסף, אם יש לכם כמה אשכולות, קל יותר לטפל בבעיות שקשורות למחזור החיים של ניהול האשכולות ולשדרוגים.
רישום ביומן ומעקב ספציפיים לדייר. כדי לבדוק את הפעולות של האפליקציות שלהם, לדיירים צריכה להיות גישה ליומנים ולמדדים. בסביבת Multi-tenancy, רישום ביומן ומעקב צריכים להיות ספציפיים לאפליקציה. לצורך מדדים ומעקב, אפשר להשתמש בשירות המנוהל של Google Cloud ל-Prometheus וב-Grafana לכל מרחב שמות. כדי לייצא רשומות ביומן למערכי נתונים ב-BigQuery, צריך ליצור יעד ואז לסנן את מערכי הנתונים לפי מרחב שמות של דייר. לאחר מכן, הדיירים יכולים לגשת לנתונים המיוצאים ב-BigQuery.
מידע נוסף על תשתית מרובת דיירים זמין במאמר בנושא שיטות מומלצות לשימוש במספר דיירים בארגונים.
גבולות הבידוד
פלטפורמה להכנת תוכנה להפצה נבנית ומשמשת צוותים רבים, ולכן חשוב להגדיר גבולות בידוד מתאימים בין הרכיבים השונים של הפלטפורמה. גבולות הבידוד עוזרים לבנות פלטפורמה חזקה באמצעות המאפיינים הבאים:
הפרדת האחריות. כל צוות מנהל את המשאבים בגבולות הבידוד שלו בלי לדאוג לגבי השאר. לדוגמה, צוות התשתית אחראי רק לתחזוקה של אשכולות GKE. אופרטורים או מפתחים אחראים רק לתחזוקה של צינורות ה-CI/CD וקוד האפליקציה.
בקרת גישה מפורטת. אם המשאבים מופרדים באמצעות גבולות בידוד, צריך להשתמש בבקרת גישה פרטנית כדי להגביל את הגישה.
מצמצם את האזורים המושפעים. אתם יכולים לבצע שינויים ברכיב בלי להשפיע על רכיבים אחרים.
מפחיתים שגיאות ידניות. מכיוון שבקרת הגישה היא פרטנית, אפשר להימנע משגיאות ידניות כמו פריסה בטעות לאשכול ייצור מסביבת פיתוח.
גבולות הבידוד האלה יכולים להתקיים בין אפליקציות שונות, בין תשתית לאפליקציות או אפילו בין סביבות שונות של אפליקציה.
פיקוח
המטרה העיקרית של פלטפורמות להכנת תוכנה להפצה ומערכות CI/CD מודרניות היא לשפר את היעילות של תהליך הכנת התוכנה להפצה הכולל. בנוגע לניהול הפלטפורמה, יש שני שיקולים עיקריים: צירוף אפליקציות, שבדרך כלל נכלל בקטגוריה של ניהול, ופיתוח ותחזוקה שוטפים של הפלטפורמה (כלומר, התייחסות לפלטפורמה כמו למוצר).
הצטרפות לאפליקציה וניהול שלה
המטרה של אימוץ מתודולוגיה וכלים מודרניים של CI/CD היא לייעל את תהליך ההפצה ואת ההטמעה של שירותים חדשים. הטמעת אפליקציות חדשות צריכה להיות תהליך פשוט שאפשר לבצע עם מינימום התערבות מצוותי התפעול והאבטחה. זה לא אומר שצוותי התפעול והאבטחה לא מעורבים, אלא שהקלט הראשוני שלהם מנקודת מבט של פריסה ואבטחה מטופל אוטומטית בתהליך ההקצאה. אחרי ההצטרפות, צוותי התפעול והאבטחה נכללים באופן טבעי בתהליך ההפצה באמצעות בקשות מיזוג, עדכוני מדיניות ואכיפה של שיטות מומלצות.
מומלץ ליצור אוטומציה מסוימת כדי להוסיף אפליקציה חדשה. זה עשוי לכלול יצירה של מאגרי קוד, צינורות CI/CD, אזורי נחיתה וכל תשתית שנדרשת לאפליקציה. אוטומציה מנתקת את התלות המורכבת של צוותי פיתוח בצוותים אחרים בארגון, ומאפשרת למפתחים לנהל את האפליקציה שלהם באופן עצמאי. כך המפתחים יכולים להתחיל לחזור על הקוד של האפליקציה במהירות רבה ולא לבזבז זמן על ביצוע משימות אחרות מלבד כתיבת הקוד. האוטומציה צריכה לאפשר למפתחים להפעיל את האפליקציה בסביבת פיתוח. כדי להעביר את האפליקציה לסביבות גבוהות יותר, צריך לערב צוותים אחרים ולפעול לפי תהליך הבדיקה.
בארכיטקטורת ההפניה המשויכת, האוטומציה הזו נקראת Application Factory (מפעל אפליקציות).
פלטפורמה כמוצר
תהליך העבודה של CI/CD הוא מוצר תוכנה, אלא שהמשתמשים במוצר הם צוותי פיתוח, תפעול ואבטחה. לכן, הפלטפורמה דורשת את אותם תפקידים ותהליכים בפיתוח תוכנה, כמו בעלי מוצר, שיווק (אף על פי שהוא פנימי), לולאות משוב ממשתמשים ומחזורי פיתוח תכונות.
פריסת CI/CD באמצעות GKE
כשמתחילים להטמיע CI/CD מודרני עם GKE בארגון, חשוב מאוד לבחור את אפליקציות הפיילוט הטובות ביותר. צוותי פיתוח, תפעול ואבטחה צריכים גם להתייחס לגורמים אחרים במהלך העבודה, והסעיף הזה מתייחס אליהם.
בחירת בקשת הצטרפות לפיילוט
בחירת האפליקציות הראשונות להעברה לפלטפורמה יכולה להיות שלב ראשון קשה. מועמדים טובים לתוכניות פיילוט הם שירותים שמבצעים עיבוד נתונים או מטפלים בבקשות, אבל לא מאחסנים נתונים – לדוגמה, שכבות שמירה במטמון, קצה קדמי של אתרים או אפליקציות לעיבוד נתונים מבוסס-אירועים. בדרך כלל, האפליקציות האלה עמידות יותר בפני השבתה קצרה ושגיאות פריסה שעלולות להתרחש בכל פעם שמשתמשים בטכניקות חדשות של פריסה וניהול הגדרות. ככל שהצוותים יצברו יותר ניסיון ב-CI/CD ויתחילו ליהנות מיתרונות במונחים של מהימנות ומהירות, תוכלו להתחיל להעביר שירותי ליבה לפלטפורמה של אספקת התוכנה.
שיקולים למפתחים
כשעובדים בתהליך פיתוח מודרני של CI/CD, תכונות, שינויים ופריסות יכולים להתרחש בתדירות גבוהה יותר ובאופן אסינכרוני יותר. צוותי פיתוח צריכים להבין איך שינויים משפיעים על מערכות במורד הזרם או על מערכות תלויות, ואיך השינויים האלה נבדקים. נתיבי התקשורת בין צוותי הפיתוח, התפעול והאבטחה צריכים להיות גמישים. מומלץ להשקיע בשיטות טובות יותר לניהול גרסאות, גם לאפליקציות וגם לחוזים של הנתונים שבאמצעותם השירותים השונים מתקשרים. בנוסף לשיפור שיטות התקשורת והגרסאות, הטמעה של תכונות בחלקים קטנים ושימוש בענפים ובדגלים של תכונות יכולים לשפר את האופן שבו אתם בודקים ומשיקים תכונות.
שיקולים שקשורים למפעילים
בעזרת פלטפורמה להכנת תוכנה להפצה, צוותי התפעול צריכים לתפקד יותר כמו צוותי פיתוח. במקום ליצור תכונות שפונות ללקוחות, הם יוצרים כלים ותהליכים פנימיים שמסייעים בפיתוח, בפריסה ובהפעלה של אפליקציות שפונות ללקוחות. הצוות של הפלטפורמה, צוות הפיתוח וצוות האבטחה משתמשים בכלים של הפלטפורמה. מפעילים צריכים לפתח כלים שיעזרו להם להשיק גרסאות חדשות של אפליקציות, וגם לבטל את ההשקה במקרה של שגיאות באפליקציה או כשלים בהטמעה. בנוסף, מומלץ למפעילים להשקיע יותר מאמצים בבניית מערכות מעקב והתראות כדי לזהות כשלים באופן יזום ולשלוח התראות בהתאם.
שיקולים לצוות האבטחה
צוותי אבטחה צריכים לפעול כדי להפוך את האבטחה לאחריות משותפת שלהם ושל צוותי התפעול והפיתוח. הדפוס הזה נקרא בדרך כלל הזזה שמאלה באבטחה, שבו אבטחת מידע (InfoSec) מעורבת בשלב מוקדם בתהליך הפיתוח, המפתחים עובדים עם כלים שאושרו מראש, ובדיקות האבטחה הן אוטומטיות. בנוסף לטכניקות האלה, אפשר להגדיר ולאכוף מדיניות אבטחה באופן פרוגרמטי באמצעות Policy Controller. השילוב של הטכניקות והכלים האלה מאפשר אכיפת אבטחה בצורה פרואקטיבית יותר.
המאמרים הבאים
כדאי לנסות להטמיע היבטים של ארכיטקטורת ה-CI/CD המודרנית הזו.
כדאי לקרוא את המאמר בנושא Kubernetes והאתגרים של הכנת תוכנה להפצה רציפה.
קריאה על תבניות של מעקב ורישום ביומן בסביבות היברידיות ומרובות עננים.