Cloud Build הוא שירות להפעלת גרסאות ה-build שפיתחתם, ב- Google Cloud.
בעזרת Cloud Build תוכלו לייבא קוד מקור ממגוון מאגרי מידע או מ-Cloud Storage, להפעיל גרסאות build במפרטים שלכם וליצור ארטיפקטים – כמו קונטיינרים של Docker או ארכיונים של Java. אפשר גם להשתמש ב-Cloud Build כדי להגן על שרשרת האספקה של התוכנות. התכונות של Cloud Build עומדות בדרישות של רמה 3 ב-Supply chain Levels for Software Artifacts (SLSA). הנחיות להגנה על תהליכי בנייה זמינות במאמר הגנה על תהליכי בנייה.תצורת build ושלבי build
אתם יכולים לכתוב קובץ הגדרות build כדי לספק ל-Cloud Build הוראות לגבי המשימות לביצוע. אתם יכולים להגדיר את הגרסאות כך שיאחזרו תלויות, יריצו בדיקות יחידה, ניתוחים סטטיים ובדיקות שילוב, וייצרו ארטיפקטים באמצעות כלי בנייה כמו docker, gradle, maven, bazel ו-gulp.
Cloud Build מריץ את גרסת ה-build כסדרה של שלבים, כשכל שלב מורץ בקונטיינר של Docker. ביצוע שלבי build דומה לביצוע פקודות בסקריפט.
אתם יכולים להשתמש בשלבי ה-build שסופקו על ידי Cloud Build והקהילה של Cloud Build, או לכתוב שלבי build בהתאמה אישית:
- שלבי build שסופקו על ידי Cloud Build: Cloud Build פרסם קבוצה של שלבי build נתמכים בקוד פתוח לשפות ולמשימות נפוצות.
- שלבי בנייה שנוצרו על ידי הקהילה: קהילת המשתמשים של Cloud Build סיפקה שלבי בנייה בקוד פתוח.
- פעולות בנייה בהתאמה אישית: אתם יכולים ליצור פעולות בנייה משלכם לשימוש בבנייה.
כל שלב בנייה מופעל כשהקונטיינר שלו מצורף לרשת Docker מקומית בשם cloudbuild. כך שלבי הבנייה יכולים לתקשר ביניהם ולשתף נתונים. מידע נוסף על רשת cloudbuild זמין במאמר רשת Cloud Build.
אתם יכולים להשתמש בקובצי אימג' רגילים של Docker Hub ב-Cloud Build, כמו Ubuntu ו-Gradle.
התחלת בנייה
אפשר להתחיל באופן ידני בנייה ב-Cloud Build באמצעות Google Cloud CLI או Cloud Build API, או להשתמש בטריגרים של Cloud Build כדי ליצור תהליך עבודה אוטומטי של אינטגרציה רציפה (CI) ופריסה רציפה (CD), שמתחיל בנייה חדשה בתגובה לשינויים בקוד. אפשר לשלב טריגרים של build עם הרבה מאגרי קוד, כולל Cloud Source Repositories, GitHub ו-Bitbucket.צפייה בתוצאות של בנייה
אפשר לראות את תוצאות הבנייה באמצעות ה-CLI של gcloud, Cloud Build API או בדף Build History בקטע Cloud Build במסוףGoogle Cloud , שבו מוצגים פרטים ויומנים של כל בנייה ש-Cloud Build מבצע. הוראות מפורטות מופיעות במאמר הצגת תוצאות של בנייה.
איך בונים
בשלבים הבאים מוסבר באופן כללי על מחזור החיים של גרסת build ב-Cloud Build:
- מכינים את קוד האפליקציה ואת כל הנכסים הנדרשים.
- יוצרים קובץ תצורה של build בפורמט YAML או JSON, שמכיל הוראות ל-Cloud Build.
- שולחים את ה-build ל-Cloud Build.
- Cloud Build מריץ את ה-build על סמך הגדרות ה-build שסיפקתם.
- אם רלוונטי, כל הארטיפקטים שנבנו נדחפים אל Artifact Registry.
Docker
Cloud Build משתמש ב-Docker כדי להריץ גרסאות build. בכל שלב של יצירת גרסת build, Cloud Build מריץ קונטיינר Docker כמופע של docker run. בשלב הזה, Cloud Build מפעיל את Docker engine בגרסה 20.10.24.
ממשקי Cloud Build
אפשר להשתמש ב-Cloud Build באמצעות מסוף Google Cloud , כלי שורת הפקודה gcloud או API בארכיטקטורת REST של Cloud Build.
אפשר להשתמש ב-CLI של gcloud כדי ליצור ולנהל גרסאות build. אפשר להריץ פקודות כדי לבצע משימות כמו שליחת build, הצגת רשימה של builds וביטול build.
אפשר לבקש בנייה באמצעות Cloud Build REST API.
כמו בממשקי API אחרים של Cloud Platform, צריך לאשר גישה באמצעות OAuth2. אחרי שתאשרו את הגישה, תוכלו להשתמש ב-API כדי להתחיל בנייה חדשה, לראות את הסטטוס ואת הפרטים של הבנייה, לראות רשימה של בנייה לפי פרויקט ולבטל בנייה שנמצאת כרגע בתהליך.
מידע נוסף זמין במאמרי העזרה של ה-API.
ברירות מחדל של בריכות ובריכות פרטיות
כברירת מחדל, כשמריצים build ב-Cloud Build, ה-build פועל בסביבה מאובטחת ומארחת עם גישה לאינטרנט הציבורי. כל בנייה מופעלת על worker משלה ומבודדת מעומסי עבודה אחרים. אפשר להתאים אישית את הגדרות המכונה בכמה דרכים, כולל הגדלת הגודל של סוג המכונה או הקצאת יותר נפח אחסון בדיסק. במאגר ברירת המחדל יש מגבלות על מידת ההתאמה האישית של הסביבה, במיוחד בנוגע לגישה לרשת פרטית.
מאגרי עובדים פרטיים הם מאגרי עובדים פרטיים וייעודיים שמציעים התאמה אישית רבה יותר של סביבת build, כולל היכולת לגשת למשאבים ברשת פרטית. בריכות פרטיות, בדומה לבריכות ברירת המחדל, מתארחות ומנוהלות באופן מלא על ידי Cloud Build, וניתן להגדיל או להקטין את הקיבולת שלהן עד לאפס. אין צורך להגדיר, לשדרג או לשנות את גודל התשתית. מאגרים פרטיים הם משאבים ספציפיים ללקוחות, ולכן אפשר להגדיר אותם בדרכים נוספות.מידע נוסף על בריכות פרטיות ועל ההבדלים בין בריכות ברירת מחדל לבריכות פרטיות זמין במאמר סקירה כללית על בריכות פרטיות.
אבטחה
ב-Cloud Build יש כמה תכונות לאבטחת תהליכי הבנייה, כולל:
-
Automated Builds
ב-build אוטומטי או ב-build מבוסס-סקריפט מוגדרים כל שלבי ה-build בסקריפט ה-build או בהגדרת ה-build, כולל השלבים לאחזור קוד המקור והשלבים ליצירת הקוד. הפקודה הידנית היחידה, אם יש כזו, היא הפקודה להרצת ה-build. Cloud Build משתמש בקובץ build config כדי לספק שלבי build ל-Cloud Build.
גרסאות build אוטומטיות מספקות עקביות בשלבי ה-build. עם זאת, חשוב גם להריץ את הבנייה בסביבה עקבית ומהימנה.
אף על פי ש-builds מקומיים יכולים להיות שימושיים למטרות ניפוי באגים, שחרור תוכנה מ-builds מקומיים עלול להוביל להרבה בעיות אבטחה, חוסר עקביות וחוסר יעילות בתהליך ה-build.
- אפשרות לבצע גרסאות build מקומיות מאפשרת לתוקף עם כוונות זדוניות לשנות את תהליך ה-build.
- חוסר עקביות בסביבות המקומיות של המפתחים ובשיטות העבודה שלהם מקשה על שכפול של גרסאות build ועל אבחון בעיות בגרסאות build.
בדרישות של מסגרת SLSA, גרסאות build אוטומטיות הן דרישה לרמה 1 של SLSA, ושימוש בשירות build במקום בסביבות פיתוח לגרסאות build הוא דרישה לרמה 2 של SLSA.
-
אישור המקור של Build
אישור המקור של Build הוא אוסף של נתונים שניתנים לאימות לגבי build.
מטא-נתונים של מקוריות כוללים פרטים כמו תקצירי התמונות שנוצרו, מיקומי מקור הקלט, שרשרת הכלים של הבנייה ומשך הבנייה.
יצירת אישור המקור של Build עוזרת לכם:
- מוודאים שנוצר ארטיפקט בנוי ממיקום מקור מהימן וממערכת build מהימנה.
- זיהוי קוד שהוזרק ממיקום או ממערכת בנייה לא מהימנים.
אתם יכולים להשתמש במנגנוני התראות ומדיניות כדי להשתמש באופן יזום בנתוני מקורות מהימנים של בנייה. לדוגמה, אפשר ליצור כללי מדיניות שמאפשרים רק פריסות של קוד שנבנה ממקורות מאומתים.
Cloud Build יכול ליצור אישור המקור של Build עבור קובצי אימג' של קונטיינרים שמספקים רמת אבטחה של SLSA 3. מידע נוסף זמין במאמר הצגת מקור ה-build.
-
סביבת בנייה זמנית
סביבות זמניות הן סביבות זמניות שמיועדות לפעול רק בזמן הפעלת build יחידה. אחרי הבנייה, הסביבה נמחקת או מוסרת. גרסאות build זמניות מבטיחות ששירות ה-build והשלבים של ה-build יפעלו בסביבה זמנית, כמו קונטיינר או מכונה וירטואלית (VM). במקום לעשות שימוש חוזר בסביבת build קיימת, שירות ה-build מקצה סביבה חדשה לכל build ואז משמיד אותה אחרי שתהליך ה-build מסתיים.
סביבות זמניות מבטיחות בנייה נקייה כי אין קבצים שיוריים או הגדרות סביבה מבנייה קודמת שיכולים להפריע לתהליך הבנייה. סביבה לא זמנית מספקת לתוקפים הזדמנות להחדיר קבצים ותוכן זדוניים. סביבה זמנית גם מפחיתה את עלויות התחזוקה ואת חוסר העקביות בסביבת הבנייה.
Cloud Build מגדיר סביבת מכונה וירטואלית חדשה לכל build, ומשמיד אותה אחרי ה-build.
-
מדיניות הפריסה
אתם יכולים לשלב את Cloud Build עם Binary Authorization כדי לבדוק הצהרות על גרסאות build ולחסום פריסות של תמונות שלא נוצרו על ידי Cloud Build. התהליך הזה יכול להפחית את הסיכון לפריסת תוכנה לא מורשית.
-
מפתחות הצפנה בניהול הלקוח
Cloud Build מספק תאימות למפתחות הצפנה בניהול הלקוח (CMEK) כברירת מחדל. המשתמשים לא צריכים להגדיר שום דבר באופן ספציפי. שירות Cloud Build מספק תאימות ל-CMEK על ידי הצפנה של הדיסק הקשיח (PD) בזמן הבנייה באמצעות מפתח זמני שנוצר לכל בנייה. המפתח נוצר באופן ייחודי לכל גרסת build.
ברגע שהבנייה מסתיימת, המפתח נמחק מהזיכרון ומושמד. הוא לא מאוחסן בשום מקום, מהנדסי Google או צוות התמיכה לא יכולים לגשת אליו, ואי אפשר לשחזר אותו. לא תהיה יותר גישה לנתונים שהוגנו באמצעות מפתח כזה. מידע נוסף זמין במאמר תאימות ל-CMEK ב-Cloud Build.
-
החלונית 'תובנות לגבי אבטחה'
Cloud Build כולל חלונית Security insights במסוף Google Cloud , שבה מוצגת סקירה כללית של כמה מדדי אבטחה. אפשר להשתמש בחלונית הזו כדי לזהות סיכונים בתהליך ה-build ולצמצם אותם.
בחלונית הזו מוצג המידע הבא:
- רמה של Supply-chain Levels for Software Artifacts (SLSA): מזהה את רמת הבשלות של תהליך build של התוכנה בהתאם למפרט SLSA.
- נקודות חולשה: סקירה כללית של נקודות חולשה שנמצאו בארטיפקטים, ושם האימג' שנסרק על ידי Artifact Analysis. אפשר ללחוץ על שם התמונה כדי לראות את פרטי הפגיעות.
- פרטי גרסת ה-Build: פרטים של גרסת ה-Build, כמו הכלי ליצירת גרסת ה-Build והקישור לצפייה ביומנים.
- אישור המקור של Build: אישור המקור של ה-build.
מידע על השימוש ב-Cloud Build עם מוצרים ותכונות אחרים Google Cloud להגנה על שרשרת האספקה של תוכנות מופיע במאמר אבטחה של שרשרת האספקה של תוכנות.