בחירת סביבת הפעלה לשירותים

כל המקרים של Cloud Run הם ארגז חול, אבל טכנולוגיית ארגז החול והתכונות הזמינות משתנות בהתאם לסביבת הביצוע שנבחרה.

סביבת ההפעלה מהדור הראשון מבוססת על gVisor ומאופיינת בזמני הפעלה במצב התחלתי (cold start) מהירים ובאמולציה של רוב הקריאות למערכת ההפעלה, אבל לא של כולן.

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

  • ביצועים מהירים יותר של המעבד
  • ביצועים מהירים יותר ברשת, במיוחד במקרים של אובדן מנות
  • תאימות מלאה ל-Linux, כולל תמיכה בכל קריאות המערכת, מרחבי השמות ו-cgroups
  • תמיכה במערכת קבצים ברשת

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

התמחור בשני סביבות ההפעלה זהה. פרטים נוספים מופיעים במחירון של Cloud Run.

בחירת סביבת הפעלה לשירות Cloud Run

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

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

איך בוחרים סביבת הפעלה

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

  • בשירות Cloud Run יש תנועה עם שיאים פתאומיים, והוא צריך להתרחב במהירות למספר רב של מופעים, או שהשירות רגיש לזמני הפעלה במצב התחלתי (cold start).
  • בשירות Cloud Run שלכם יש תעבורה לא סדירה שגורמת להרחבה תכופה מאפס.
  • אתם רוצים להשתמש בפחות מ-512MiB של זיכרון. סביבת ההפעלה מהדור השני דורשת לפחות 512MiB של זיכרון.

כדאי להשתמש בדור השני אם אחד מהתנאים הבאים מתקיים בשירות Cloud Run שלכם:

  • השירות שלכם צריך להשתמש ב-NFS, שנתמך רק בדור השני.
  • התנועה בשירות יציבה למדי, והוא יכול להתמודד עם הפעלות איטיות במצב התחלתי (cold start) שהן קצת יותר איטיות.
  • השירות שלכם כולל עומסי עבודה שדורשים הרבה משאבי CPU.
  • השירות שלכם יכול להרוויח מביצועי רשת מהירים יותר.
  • השירות שלכם משתמש ביציאה ישירה מ-VPC כדי לשלוח תנועה לרשת VPC, ונדרשים ביצועים אופטימליים של הרשת.
  • השירות שלכם צריך להשתמש בתוכנה שיש לה בעיות בהרצה בדור הראשון בגלל קריאות מערכת שלא יושמו.
  • השירות שלכם צריך את הפונקציונליות של Linux cgroup.
  • השירות שלכם משתמש בתשתית של צד שלישי כדי לאבטח קונטיינרים.

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

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

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

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

הגדרה ועדכון של סביבת ההפעלה

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

ברירת המחדל לשירותי Cloud Run היא לא צוין, כלומר Cloud Run בוחר סביבת הפעלה מתאימה. אפשרות אחרת היא לציין סביבת הפעלה. כדי להשתמש בדור השני, צריך לציין לפחות 512MiB של זיכרון.

אפשר להגדיר את סביבת ההפעלה באמצעות מסוף Google Cloud , שורת הפקודה של gcloud או קובץ YAML כשיוצרים שירות חדש או פורסים עדכון חדש:

המסוף

  1. נכנסים ל-Cloud Run במסוף Google Cloud :

    כניסה ל-Cloud Run

  2. בתפריט הניווט של Cloud Run, בוחרים באפשרות Services (שירותים) ולוחצים על Deploy container (פריסת קונטיינר) כדי להגדיר שירות חדש. אם אתם מגדירים שירות קיים, לוחצים על השירות ואז על עריכה ופריסה של עדכון חדש.

  3. אם אתם מגדירים שירות חדש, ממלאים את דף ההגדרות הראשוניות של השירות ואז לוחצים על Container(s), Volumes, Networking, Security (מאגרים, אמצעי אחסון, רשתות, אבטחה) כדי להרחיב את דף הגדרות השירות.

  4. לוחצים על הכרטיסייה מאגר תגים.

    תמונה

    • בוחרים את סביבת ההפעלה הרצויה באמצעות לחצני האפשרויות. משאירים את האפשרות 'ברירת מחדל' כדי לאפשר ל-Cloud Run לבחור סביבת ביצוע מתאימה.

  5. לוחצים על יצירה או על פריסה.

gcloud

כדי לעדכן את סביבת ההפעלה של שירות מסוים, משתמשים בפקודה הבאה:

gcloud run services update SERVICE --execution-environment ENVIRONMENT

מחליפים את SERVICE בשם השירות ואת ENVIRONMENT בסביבת ההפעלה הרצויה. מציינים את הערך gen1 לדור הראשון או gen2 לדור השני.

אפשר גם להגדיר את סביבת ההפעלה במהלך הפריסה באמצעות הפקודה:

gcloud run deploy --image IMAGE_URL --execution-environment ENVIRONMENT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫IMAGE_URL: הפניה לקובץ אימג' בקונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, צריך ליצור מראש את המאגר REPO_NAME. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
  • ‫ENVIRONMENT: סביבת ההפעלה הרצויה. מציינים את הערך gen1 לדור הראשון או gen2 לדור השני.

YAML

  1. אם אתם יוצרים שירות חדש, דלגו על השלב הזה. אם אתם מעדכנים שירות קיים, מורידים את הגדרות ה-YAML שלו:

    gcloud run services describe SERVICE --format export > service.yaml

  2. מגדירים את ההערה run.googleapis.com/execution-environment:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: ENVIRONMENT

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE: השם של שירות Cloud Run.
    • ‫ENVIRONMENT: סביבת ההפעלה שנבחרה. מציינים את הערך gen1 לדור הראשון או gen2 לדור השני.

    מסירים את ההערה run.googleapis.com/execution-environment מההתנהגות שמוגדרת כברירת מחדל.

  3. יוצרים או מעדכנים את השירות באמצעות הפקודה הבאה:

    gcloud run services replace service.yaml

Terraform

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

מוסיפים את השורות הבאות למשאב google_cloud_run_v2_service בקובץ התצורה של Terraform:
resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-execution-environment"
  location = "REGION"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    execution_environment = "ENVIRONMENT"
  }
}

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: Google Cloud האזור. לדוגמה: europe-west1.
  • ‫ENVIRONMENT: EXECUTION_ENVIRONMENT_GEN1 לדור הראשון או EXECUTION_ENVIRONMENT_GEN2 לדור השני.

צפייה בהגדרות של סביבת ההפעלה

כדי לראות את ההגדרות הנוכחיות של סביבת ההפעלה בשירות Cloud Run:

המסוף

  1. במסוף Google Cloud , נכנסים לדף Services של Cloud Run:

    כניסה ל-Cloud Run

  2. לוחצים על השירות שרוצים לראות את הפרטים שלו כדי לפתוח את הדף פרטי השירות.

  3. לוחצים על הכרטיסייה עדכונים.

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

gcloud

  1. משתמשים בפקודה הבאה:

    gcloud run services describe SERVICE

  2. מאתרים את ההגדרה Execution environment (סביבת הפעלה) בתצורה שמוחזרת.

כיבויים מבוקרים

כשמכונת Cloud Run נסגרת, היא מקבלת אות SIGTERM כדי לאפשר כיבוי מבוקר של 10 שניות.

טיפול באות SIGTERM

מומלץ להתקין ב-container SIGTERM handler, במיוחד אם אתם משתמשים בחיוב לפי בקשה.

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

איך בודקים אם מארח התגים מטפל ב-SIGTERM

כדי לבדוק אם יש במאגר התגים שלכם SIGTERM handler:

  1. מפעילים את Cloud Shell. אפשר למצוא את האפשרות הפעלת כפתור Cloud Run Activate Cloud Shell בכותרת של דף התיעוד שבו אתם נמצאים. יכול להיות שתצטרכו לאשר את הפעולה ולחכות עד שהשירות יוקצה. אפשר גם להתחיל סשן עצמאי.

  2. מריצים את הקונטיינר באופן מקומי ב-Cloud Shell:

    docker run IMAGE_URL

    מחליפים את IMAGE_URL בהפניה לקובץ אימג' של קונטיינר, לדוגמה, us-docker.pkg.dev/cloudrun/container/hello:latest. אם אתם משתמשים ב-Artifact Registry, צריך ליצור מראש את המאגר REPO_NAME. כתובת ה-URL היא בפורמט LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

  3. פותחים כרטיסייה נוספת ב-Cloud Shell ומקבלים רשימה של הקונטיינרים שפועלים בסשן הנוכחי של Cloud Shell:

    docker container ls

    צריך לאתר את מזהה מאגר התגים שמוחזר מהפקודה.

  4. באמצעות מזהה מאגר התגים, שולחים למאגר התגים אות SIGTERM

    docker kill -s SIGTERM CONTAINER_ID

  5. חוזרים לכרטיסייה שבה הפעלתם את docker run כדי לבדוק אם הקונטיינר יצא (נעצר). אם אות ה-SIGTERM גרם ליציאה מהקונטיינר, הקונטיינר מטפל ב-SIGTERM.

איך מטפלים ב-SIGTERM

אם הקונטיינר לא מטפל ב-SIGTERM, הדרך הכי פשוטה להוסיף handler של SIGTERM היא לעטוף את השירות ב-tini. כך השירות שלכם יפעל כתהליך משנה של tini, שיקבל את התפקיד של תהליך ההפעלה של הקונטיינר. הוראות מפורטות מופיעות בהוראות של Docker.

לחלופין, אפשר לשנות את האפליקציה כך שתטפל ישירות ב-SIGTERM.

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