שימוש בסביבות הפעלה של Cloud Deploy

סביבת הביצוע של Cloud Deploy היא הסביבה שבה Cloud Deploy מבצע את הפעולות render,‏ predeploy,‏ deploy,‏ verify ו-postdeploy. סביבת ההפעלה מורכבת מהרכיבים הבאים:

  • מאגר העובדים של Cloud Build (ברירת מחדל או פרטי) שבו Cloud Deploy מבצע פעולות של עיבוד, טרום-פריסה, פריסה, אימות ופוסט-פריסה

  • חשבון השירות (ברירת מחדל או חלופי) שמבצע את הפעולות האלה באמצעות קריאה ל-Cloud Deploy

  • מיקום האחסון (ברירת מחדל או חלופי) של מניפסטים שעברו עיבוד ב-Cloud Storage

  • הזמן הקצוב לתפוגה של פעולות ב-Cloud Build (ברירת מחדל או מותאם אישית)

במאמר הזה מוסבר על סביבת הביצוע, חשבונות השירות והאחסון שמוגדרים כברירת מחדל ב-Cloud Deploy, וגם למה כדאי לשנות את ברירות המחדל האלה ואיך עושים את זה.

ברירות מחדל

אלה הגדרות ברירת המחדל שמשמשות את Cloud Deploy להרצה, להפעלת עיבוד ולפריסה, ולאחסון נכסים כמו מניפסטים מעובדים:

  • מאגר עובדים שמוגדר כברירת מחדל

    כברירת מחדל, Cloud Deploy פועל במאגר העובדים שמוגדר כברירת מחדל ב-Cloud Build. עם זאת, אפשר להגדיר את Cloud Deploy כך שישתמש במאגר פרטי של עובדים ב-Cloud Build.

    מידע נוסף על מאגרי עובדים זמין במאמר סקירה כללית של מאגרי ברירת מחדל ומאגרים פרטיים ב-Cloud Build.

  • חשבון השירות שמוגדר כברירת מחדל להרצת הפרויקט

    כברירת מחדל, Cloud Deploy משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

  • מיקום ברירת המחדל לאחסון ב-Cloud Deploy

    הערך הזה הוא הקטגוריה של Cloud Storage שבה Cloud Deploy מאחסן את המניפסטים שעברו עיבוד. כברירת מחדל, Cloud Deploy יוצר קטגוריה של Cloud Storage באותו אזור שבו נמצאים משאבי Cloud Deploy, לפי הפורמט הבא:

    <location>.deploy-artifacts.<project ID>.appspot.com

  • זמן קצוב לתפוגה (timeout) שמוגדר כברירת מחדל ב-Cloud Build

    כברירת מחדל, ל-Cloud Build יש זמן קצוב לתפוגה של שעה אחת לפעולות שהוא מבצע עבור Cloud Deploy. אפשר לשנות את הזמן הקצוב לתפוגה הזה במפרט של סביבת ההפעלה בהגדרות היעד.

  • רמת הפירוט שמוגדרת כברירת מחדל ב-Skaffold, ב-CLI של gcloud וב-kubectl

    כברירת מחדל, רמות היומן של הכלים האלה מוגדרות לערכי ברירת המחדל שלהם, בדרך כלל warn או ערך מקביל. אפשר לשנות את זה ל-debug או לערך שווה ערך.

בקטעים הבאים מתוארים המקרים שבהם כדאי לשנות את אחד מהערכים האלה, ומופיעים קישורים להוראות לביצוע השינוי.

מידע על מאגרי עובדים ב-Cloud Build

סביבת ההפעלה של Cloud Deploy יכולה להשתמש באחת מהאפשרויות הבאות:

  • מאגר ברירת המחדל של Cloud Build

    מאגר ברירת המחדל של העובדים הוא סביבה מאובטחת ומארחת עם גישה לאינטרנט הציבורי. פעולות של עיבוד, פריסה, פריסה מראש, פריסה לאחר מכן ואימות מבוצעות במאגר הזה, בבידוד מעומסי עבודה אחרים.

  • בריכה פרטית

    מאגרי עובדים פרטיים הם מאגרים פרטיים ייעודיים שאפשר להתאים אישית יותר ממאגר העובדים שמוגדר כברירת מחדל. ההתאמה האישית הזו יכולה לכלול את היכולת לגשת למשאבים ברשת פרטית. בדומה למאגר העובדים שמוגדר כברירת מחדל, מאגרי עובדים פרטיים מתארחים ומנוהלים באופן מלא על ידי Cloud Build. המאגרים האלה יכולים להתרחב או להצטמצם עד לאפס, בלי שתצטרכו להגדיר, לשדרג או לשנות את גודל התשתית.

    במאמר סקירה כללית של מאגרי עובדים פרטיים ב-Cloud Build יש תיאור מפורט יותר של מאגרי עובדים שמוגדרים כברירת מחדל ומאגרי עובדים פרטיים, כולל טבלה עם השוואה בין התכונות שלהם.

שינוי סביבת ההפעלה של Cloud Deploy

יכול להיות שתצטרכו לשנות את סביבת ההפעלה של Cloud Deploy במקרים הבאים:

  • רוצים לפרוס לאשכול פרטי של Google Kubernetes Engine

  • אתם רוצים לבצע פעולות של עיבוד, פריסה, פריסה מראש, פריסה אחרי העיבוד או אימות, או שילוב של חמש הפעולות האלה, בסביבה מבודדת מארגונים אחרים.

  • אתם רוצים שהפעולות האלה יתבצעו בסביבה שלא מחוברת לאינטרנט הציבורי.

  • אתם רוצים סביבות נפרדות לעיבוד ולפריסה.

  • אתם רוצים להשתמש בחשבון שירות ייעודי עם הרשאות ספציפיות יותר לשימוש שלכם מאשר ההרשאות שזמינות בחשבון השירות שמוגדר כברירת מחדל.

  • אתם רוצים לאחסן מניפסטים שעברו רינדור במיקום שונה מהקטגוריה של Cloud Storage שמוגדרת כברירת מחדל.

ההגדרה של כל שלושת החלקים של סביבת ההפעלה (מאגר העובדים, חשבון השירות והאחסון) מתבצעת לכל יעד, בהגדרת ה-YAML של כל יעד.

מעבר ממאגר ברירת המחדל למאגר פרטי

מאגרי העובדים מוגדרים לכל יעד, כך שהמאגר ישמש לRENDER, לDEPLOY, לPREDEPLOY, לPOSTDEPLOY או לVERIFY (או לשילוב של חמשת אלה) רק עבור אותו יעד.

כדי להשתמש במאגר העובדים שמוגדר כברירת מחדל גם לפעולות רינדור וגם לפעולות פריסה, לא צריך לעשות שום דבר.

זוהי דוגמה להגדרת יעד שמציינת מאגר פרטי של עובדים בשביל DEPLOY, ומאגר ברירת המחדל של עובדים בשביל RENDER, ‏ PREDEPLOY,‏ POSTDEPLOY ו-VERIFY:

executionConfigs:
- usages:
  - DEPLOY
  privatePool:
    workerPool: "projects/p123/locations/us-central1/workerPools/wp123"
- usages:
  - RENDER
  - PREDEPLOY
  - VERIFY
  - POSTDEPLOY

מידע נוסף על הגדרת מאגרי כתובות פרטיים ליעדים זמין במסמכי ההגדרות של צינורות העברת נתונים.

שינוי מחשבון השירות שמוגדר כברירת מחדל לחשבון שירות מותאם אישית

בדומה למאגר העובדים, אפשר לציין חשבון שירות חלופי לשימוש עבור עיבוד או פריסה (או שניהם) לכל יעד. כדי לעשות זאת, מוסיפים את השורה הבאה להגדרת היעד, אחרי הרכיב workerPool:

serviceAccount: "[name]@[project_name].iam.gserviceaccount.com"

חשבון השירות שצוין צריך לכלול את התפקיד clouddeploy.jobRunner, כפי שמתואר במסמך חשבונות שירות של Cloud Deploy.

פרטים נוספים על ההגדרה הזו מופיעים במאמר בנושא הגדרות של יעדים.

שינוי מיקום האחסון

כדי לשנות את קטגוריית האחסון מברירת המחדל של Cloud Deploy, מוסיפים את השורה הבאה להגדרת היעד בקטע workerPool:

artifactStorage: "gs://[bucket_name]/[dir]"

ההגדרה הזו משנה את המיקום שבו נשמרים המניפסטים שעברו רינדור, אבל היא לא משפיעה על המיקום שבו נשמר מקור הרינדור.

שינוי רמת היומן של Skaffold, ה-CLI של gcloud ו-kubectl

כדי לשנות את רמת היומן של Skaffold,‏ ה-CLI של gcloud ו-kubectl, מרמת ברירת המחדל שלהם לרמה debug (או לרמה שוות ערך), מגדירים את verbose ל-true בהגדרות הביצוע. הנה דוגמה:

executionConfigs:
- usages:
  - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose: true

שימוש ב-Cloud Deploy במתחם היקפי של VPC Service Controls

‫Cloud Deploy תומך ב-VPC Service Controls.

אפשר לפעול לפי המדריך לתחילת העבודה עם VPC Service Controls כדי להגדיר גבול גזרה לשירות.

מגבלות

  • צריך להשתמש במאגר עובדים פרטי של Cloud Build עבור סביבת ההפעלה של היעד, ולא במאגר העובדים שמוגדר כברירת מחדל.

  • הפרויקט שמכיל את מאגר העובדים והפרויקט שמכיל את המשאבים של Cloud Deploy חייבים להישאר באותו מתחם אבטחה של VPC Service Controls.

  • כל אשכול GKE שפורס בפרימטר של VPC Service Controls חייב להיות אשכול פרטי.

    כדי להגדיר מאגר פרטי לאשכול פרטי, אפשר לעיין במדריך הזה.

המאמרים הבאים