במאמר הזה מתואר מסגרת להטמעה של תהליכי אינטגרציה רציפה (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, כדאי לעיין במסמכים האחרים בסדרה הזו:
הערכת המוכנות לגישה מודרנית
לפני שמטמיעים ב-GKE תהליכים וכלים מודרניים של CI/CD, צריך להעריך אם הארגון והצוותים מוכנים לאמץ פלטפורמה חדשה.
מאפיינים של הארגון
כדי לאמץ פלטפורמה מודרנית, אתם צריכים את התמיכה הבאה מצוותי ההנהלה והצוותים הטכניים של העסק שלכם:
אחראי בכיר. הטמעה של פלטפורמה להכנת תוכנה להפצה היא בדרך כלל מאמץ גדול שמתבצע על ידי כמה צוותים רב-תחומיים. התהליך בדרך כלל מוביל לשינויים בתפקידים ובאחריות, וגם בשיטות לפיתוח תוכנה. כדי להצליח בהטמעה של הכלים והטכניקות האלה, אתם צריכים תמיכה חזקה מצד חבר אחד או יותר בצוות הניהול. הספונסרים האפקטיביים ביותר בדרגת מנהיגות הם אלה שרואים בשינויים האלה תהליך שיפור מתמשך, ורוצים להעצים את הצוותים שלהם במקום לנהל אותם.
התאמה בין אסטרטגיה טכנית ועסקית. מומלץ שהצוותים העסקיים והצוותים הטכניים יתאמו ביניהם את ארבעת המדדים העיקריים של הכנת תוכנה להפצה שמוגדרים על ידי 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 והיכולות הטכניות שמהווים את הבסיס לתהליך מהיר ואמין של פרסום אפליקציות.
תשתית הפלטפורמה. רכיבי התשתית ושיקולי הניהול שנדרשים כדי לבנות את הפלטפורמה ולהפעיל את האפליקציות.
תהליך עבודה של הכנת תוכנה להפצה. איך צוותים עובדים יחד כדי לבנות, לבדוק ולפרוס קוד בצורה יעילה יותר.
מאגרי קודים. מאגרי מידע שמבצעים כמה פונקציות, כולל אחסון של הלוגיקה העסקית בפועל, הגדרה ספציפית לאפליקציה וקוד לבניית תשתית. יכול להיות שיהיו גם מאגרי קוד התחלתיים שיעזרו לכם לאמץ שיטות מומלצות ולשמור על עקביות בתהליכים אוטומטיים.
אזורי נחיתה של אפליקציות. ישות לוגית שמאפשרת למפתחים לפרוס את האפליקציות שלהם ולבצע בהן איטרציות באופן אוטונומי, תוך שימוש במגבלות שאתם מגדירים.
מודל הפעלה. כלים, תהליכים ושיטות טכניים לניהול התשתית והאפליקציות שמרכיבות את הפלטפורמה.
משילות. תהליכים ושיקולים שצריך לשמור ולנהל בפלטפורמה להכנת תוכנה להפצה.
פלטפורמות להכנת תוכנה להפצה
פלטפורמה להכנת תוכנה להפצה מאחדת את הכלים ומייעלת את התהליכים שנדרשים כדי ליצור, להפיץ, לפרוס ולהפעיל אפליקציות.
האחריות לשמירה על ההגדרה, היציבות, זמן הפעולה וההתאמה של האפליקציה משתנה בין צוותי התפעול, האבטחה והפיתוח, אבל כל הרכיבים והצוותים צריכים לעבוד יחד כדי להאיץ את ההשקות. במאמר הזה מתוארות שיטות לשיפור הניהול של בקרת המקורות והיכולת לראות את האפליקציה, אבל הוא מתמקד בעיקר באינטגרציה רציפה (CI), בפיתוח רציף (CD) ובניהול תצורה.
כדי לבנות פלטפורמה מלאה להפצת תוכנה, צריך את כל הרכיבים בתרשים הבא:
כל אחד מהרכיבים האלה מספק פונקציונליות למערכת ולאפליקציות שפועלות בפלטפורמה:
מעקב אחר תשתיות. רמת הבסיס של המעקב שנדרשת כשמבצעים הקצאת משאבים כדי לוודא שהאשכולות של Google Kubernetes Engine (GKE), המכונות הווירטואליות (VM) ורכיבי התשתית האחרים שנדרשים כדי שהאפליקציות יפעלו, פועלים בצורה תקינה.
תזמור קונטיינרים. הפלטפורמה שמתאמת את הפריסה וההפעלה של אפליקציות מבוססות-קונטיינרים. דוגמאות לפלטפורמות לתזמור קונטיינרים הן Kubernetes, GKE או GKE Enterprise.
מאגר תמונות של קונטיינרים. האחסון ובקרת הגישה לקובצי אימג' של קונטיינרים.
CI. התהליך של החלת משימות אוטומטיות על אפליקציה לפני הפריסה. משימות CI כוללות בדרך כלל בנייה, אריזה ובדיקה. סוגי המשימות משתנים בהתאם לאפליקציה ולארגון.
CD. תהליכי פריסה אוטומטיים מאוד שמופעלים בתדירות גבוהה. דוגמאות למתודולוגיות: אישורים ידניים, פריסות קנרי, פריסות כחול-ירוק או פריסות מתגלגלות.
מדיניות. מדיניות אבטחה ומדיניות תצורה של התשתית שמוגדרות על ידי צוותי התפעול והאבטחה, ומוחלות ונאכפות באופן רציף על ידי הפלטפורמה.
ניהול קוד מקור. לדוגמה, אחסון עם בקרת גרסאות לקוד, לקובצי תצורה ולהגדרות מדיניות. במערכת CI/CD מודרנית, ניהול קוד המקור מתבצע בדרך כלל באמצעות Git.
ניהול הגדרות. המערכת שמשמשת לאחסון ולהחלה של הגדרות אפליקציה בסביבות שונות.
ניראות של אפליקציות. רישום ביומן, מעקב, התראות וזיהוי מקורות בעיות ברמת האפליקציה, שצוותי מפתחים, מפעילים ואבטחה משתמשים בהם כדי לפתור בעיות ולוודא שהאפליקציות פועלות בצורה תקינה.
תשתית הפלטפורמה
כדי לבנות פלטפורמה ניתנת להרחבה להכנת תוכנה להפצה, צריך אשכולות Kubernetes לפיתוח, לסביבות טרום-ייצור ולמספר אשכולות ייצור. אפשר להשתמש באשכולות למגוון רחב של פונקציות:
פיתוח. במערכות האלה, מפתחים מבצעים פריסות אד-הוק של האפליקציות שלהם לצורך בדיקות וניסויים.
סביבת האפליקציה.
קדם-הפקה. לכל סביבת טרום-ייצור בתהליך העבודה שלכם, צריך להיות אשכול Kubernetes לאירוח האפליקציות. האשכולות האלה צריכים להיות דומים לאשכולות הייצור, כדי שתוכלו לצמצם או לבטל את ההבדלים בין הסביבות וכתוצאה מכך לשפר את שיעורי ההצלחה של הפריסה.
ייצור. האשכולות האלה מריצים את עומסי העבודה של הייצור. מומלץ להשתמש בכמה אשכולות שמפוזרים גיאוגרפית. הפעולה הזו משפרת את האמינות במקרה של כשלים בתשתית, ומקלה על פעולות שוטפות כמו שדרוגים והרחבה של אשכולות.
התרשים הבא מציג את הארכיטקטורה ברמה גבוהה:
בארכיטקטורה הזו, אתם מנהלים את האשכולות של כל סביבה באמצעות סנכרון תצורות. הגדרת אשכול עקבית היא קריטית כי היא מאפשרת לצוותי המפתחים, התפעול והאבטחה להיות בטוחים שסביבות טרום-ייצור וייצור פועלות בצורה דומה. אפשר להשתמש ב-סנכרון תצורות כדי לאחסן ולהחיל הגדרות נפוצות בכל Fleet של אשכולות. אחרי שתקבעו תצורה סטנדרטית, ניתנת לביקורת וניתנת להרחבה של האשכול, תוכלו להתמקד בתהליך העבודה של אספקת התוכנה, בהטמעה ובפריסה של אפליקציות.
אתם מנהלים את הפריסות שלכם באשכולות פיתוח, באשכולות של סביבת ביניים ובאשכולות ייצור דרך צינורות ה-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). כדי להפעיל אפליקציה בצורה יעילה ולשמור על האמינות שלה, צריך להביא בחשבון את הרישום ביומן, המדדים והמעקב. אפליקציות 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 שכל דייר פורס, וכמות הזיכרון והמעבד שכל 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 והאתגרים של פיתוח רציף של תוכנה.
קוראים על תבניות של מעקב ורישום ביומן בענן היברידי ובענן מרובה.