הגדרת משתני סביבה של גרסת build (פריסת מקור)

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

בדף הזה מוסבר איך להגדיר משתני סביבת build שזמינים בזמן build. המידע רלוונטי למפתחי פלטפורמות שפורסים שירותים או פונקציות של Cloud Run ממקור. משתנה סביבת הבנייה gcloud CLI flags נתמך בפריסות של קוד מקור (--source), ולא נתמך בפריסות של קובצי אימג' של קונטיינר (--image).

אפשר להשתמש במשתני סביבה להגדרת שירותים או פונקציות, אבל לא מומלץ להשתמש בהם לאחסון סודות כמו פרטי כניסה למסד נתונים או מפתחות API. מאחסנים ערכים רגישים מחוץ לקוד המקור ולמשתני הסביבה. כדי לאחסן סודות, מומלץ להשתמש ב-Secret Manager. כדי להגדיר שירותים שיש להם גישה לסודות ששמורים ב-Secret Manager, אפשר לעיין במאמר הגדרת סודות.

לפני שמתחילים

• Enable the Cloud Run Admin API and Cloud Build APIs.

  Roles required to enable APIs

  To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

  Enable the APIs

  אחרי שמפעילים את Cloud Run Admin API, נוצר באופן אוטומטי חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

התפקידים הנדרשים

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

לוחצים כדי לראות את התפקידים הנדרשים לחשבון הפריסה

כדי לקבל את ההרשאות שנדרשות לבנייה ולפריסה ממקור, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• Cloud Run Source Developer (roles/run.sourceDeveloper) בפרויקט
• Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) בפרויקט
• משתמש בחשבון שירות (roles/iam.serviceAccountUser) בזהות של שירות Cloud Run

לחצו כדי לראות את התפקידים הנדרשים לחשבון השירות של Cloud Build

Cloud Build משתמש אוטומטית בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build כדי לבנות את קוד המקור ואת משאב Cloud Run, אלא אם משנים את ההתנהגות הזו. כדי ש-Cloud Build יוכל לבצע build של המקורות, צריך לבקש מהאדמין להקצות את התפקיד Cloud Run Builder (roles/run.builder) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/run.builder
  

מחליפים את PROJECT_NUMBER במספר הפרויקט ואת PROJECT_ID במזהה הפרויקט. Google CloudGoogle Cloudהוראות מפורטות לאיתור מזהה הפרויקט ומספר הפרויקט מופיעות במאמר יצירה וניהול של פרויקטים.

הענקת תפקיד ה-builder ב-Cloud Run לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לוקחת כמה דקות עד שהיא מופצת.

הערה:

iam.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts מונע מחשבונות שירות שמוגדרים כברירת מחדל לקבל את התפקיד 'עריכה' באופן אוטומטי. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

רשימת ההרשאות והתפקידים ב-IAM שמשויכים ל-Cloud Run מופיעה במאמרים תפקידי IAM ב-Cloud Run והרשאות IAM ב-Cloud Run. אם שירות Cloud Run שלכם מתקשר עםGoogle Cloud ממשקי API, כמו ספריות לקוח ב-Cloud, כדאי לעיין במדריך להגדרת זהות שירות. מידע נוסף על מתן תפקידים זמין במאמרים הרשאות פריסה וניהול גישה.

מספר מקסימלי של משתני סביבה ומגבלות של גרסאות build

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

הגדרת משתני סביבה של build

אתם יכולים להגדיר משתני סביבת build כדי ליצור משתנים חדשים או להחליף משתני build קיימים.

הערה: המפתחות צריכים להתחיל באות ASCII גדולה, ולהכיל אותיות ASCII גדולות, ספרות וקווים תחתונים. מומלץ להימנע מיצירת מפתחות משתנים עם הקידומת GOOGLE_*. כאן מפורטים כל משתני הסביבה הנתמכים של Buildpacks.

gcloud

כדי להגדיר משתני סביבת build כשפורסים שירות מקוד מקור, משתמשים בדגל --set-build-env-vars:

gcloud run deploy SERVICE \
    --source . \
    --set-build-env-vars KEY1=VALUE1,KEY2=VALUE2

מחליפים את:

• ‫SERVICE מחליפים בשם של שירות Cloud Run.
• ‫KEY1=VALUE1,KEY2=VALUE2 עם רשימה מופרדת בפסיקים של שמות משתנים והערכים שלהם, שנפרסים לצד פונקציה שמאפשרת להעביר מידע על הגדרות ל-buildpacks.

אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.

עדכון משתני סביבת build

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

gcloud

כדי לעדכן משתני סביבה של build בשירותים קיימים, משתמשים בדגל --update-build-env-vars:

gcloud run deploy SERVICE \
    --source . \
    --update-build-env-vars KEY1=VALUE1,KEY2=VALUE2

אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.

מחיקת משתני סביבה של גרסת build

אפשר למחוק משתני סביבה של build בשירותים קיימים.

gcloud

כדי להסיר משתני סביבה של build משירותים קיימים, משתמשים בדגל --remove-build-env-vars:

gcloud run deploy SERVICE \
    --source . \
    --remove-build-env-vars KEY1=VALUE1,KEY2=VALUE2

לחלופין, אפשר למחוק משתני סביבה של build באמצעות --clear-build-env-vars בשביל שירותים קיימים:

gcloud run deploy SERVICE \
    --source . \
    --clear-build-env-vars KEY1=VALUE1,KEY2=VALUE2

אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.

שימוש בקובץ של משתני סביבה של build

אפשר להשתמש בקובץ של משתני סביבה של סביבת build עבור פונקציות קיימות.

gcloud

כדי להגדיר משתני סביבה של build מקובץ, משתמשים בדגל --build-env-vars-file:

gcloud run deploy SERVICE \
    --source . \
    --build-env-vars-file FILE_NAME.yaml

מחליפים את FILE_NAME.yaml בתוכן של הקובץ, שצריך להיראות כך:

 KEY1: VALUE1
 KEY2: VALUE2

אם אתם פורסים פונקציה, מוסיפים את הדגל --function עם נקודת הכניסה של הפונקציה מקוד המקור.