פריסת שירותים מקוד מקור

בדף הזה מוסבר איך לפרוס שירות חדש או גרסת שירות חדשה ב-Cloud Run ישירות מקוד המקור, באמצעות פקודה אחת של ה-CLI של gcloud,‏ gcloud run deploy עם הדגל --source. במאמר מדריכים למתחילים בנושא פריסה מקוד מקור תוכלו למצוא דוגמה לפריסה של שירות Hello World.

יש שתי דרכים שונות להשתמש בתכונה הזו:

שימו לב שפריסות מקור משתמשות ב-Artifact Registry כדי לאחסן קונטיינרים שנוצרו. אם בפרויקט שלכם עדיין אין מאגר Artifact Registry בשם cloud-run-source-deploy באזור שבו אתם פורסים, התכונה הזו יוצרת באופן אוטומטי מאגר Artifact Registry בשם cloud-run-source-deploy.

אם יש קובץ Docker בספריית קוד המקור, קוד המקור שהועלה נבנה באמצעות קובץ ה-Docker הזה. אם אין קובץ Docker בספריית קוד המקור, חבילות ה-buildpack של Google Cloud מזהות באופן אוטומטי את השפה שבה אתם משתמשים ומאחזרות את יחסי התלות של הקוד כדי ליצור קובץ אימג' של קונטיינר שמוכן לייצור, באמצעות קובץ אימג' בסיסי מאובטח שמנוהל על ידי Google.

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

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

  • מוודאים שהגדרתם פרויקט חדש ל-Cloud Run, כמו שמתואר בדף ההגדרה.

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

  • מפעילים את Cloud Run Admin API, אם הוא עדיין לא מופעל.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

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

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

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

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

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

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

שפות נתמכות

בנוסף למקורות עם קובץ Docker, פריסה מקוד מקור תומכת בשפות הבאות באמצעות buildpacks של Google Cloud:

זמן ריצה פריסת המקור הגדרות אישיות
המשך פריסת שירות Go הגדרת buildpacks של Go
Node.js פריסת שירות Node.js הגדרת buildpacks של Node.js
Python פריסת שירות Python הגדרת buildpacks של Python
‫Java
(כולל Kotlin, ‏ Groovy, ‏ Scala)		 פריסת שירות Java הגדרת buildpacks של Java
‎.NET פריסת שירות ‎ .NET הגדרת buildpacks של ‎ .NET
Ruby פריסת שירות Ruby הגדרת buildpacks של Ruby
PHP פריסת שירות PHP הגדרת buildpacks של PHP
רק במערכת ההפעלה פריסת שירות Go הגדרת סביבת זמן ריצה של מערכת ההפעלה בלבד

מידע נוסף על גרסאות השפה הנתמכות

פריסה מקוד המקור עם build

בקטע הזה נסביר איך משתמשים ב-Buildpacks של Google Cloud וב-Cloud Build כדי ליצור באופן אוטומטי קובצי אימג' של קונטיינרים מקוד המקור, בלי להתקין את Docker במכונה או להגדיר את Buildpacks או את Cloud Build.

מגבלות

  • הפריסה מהמקור משתמשת ב-Artifact Registry וב-Cloud Build, ולכן התכונה הזו זמינה רק באזורים שנתמכים על ידי Artifact Registry ו-Cloud Build.
  • פריסה מהמקור היא תכונה נוחה, אבל היא לא מאפשרת התאמה אישית מלאה של ה-build. כדי לקבל יותר שליטה, אתם יכולים ליצור את קובץ האימג' של הקונטיינר באמצעות Cloud Build, למשל באמצעות gcloud builds submit, ואז לפרוס את קובץ האימג' של הקונטיינר באמצעות gcloud run deploy --image, למשל.
  • כשפורסים מהמקור באמצעות חבילות ה-buildpack של Google Cloud, התאריך האחרון לשינוי של קובצי המקור מוגדר ל-1 בינואר 1980. זוהי התנהגות ברירת המחדל של buildpacks, והיא נועדה לתמוך בגרסאות build שניתן לשחזר. בהתאם למסגרת השפה, יכול להיות שהפעולה הזו תשפיע על השמירה במטמון של קבצים סטטיים בצד הדפדפן. אם האפליקציה שלכם מושפעת מכך, Google ממליצה להשבית את כותרות ה-HTTP‏ etag ו-Last-Modified באפליקציה.
  • כשפורסים מקוד מקור באמצעות buildpacks של Google Cloud, תמיד משתמשים ב-gcr.io/buildpacks/builder:latest. אם השפה או הגדרות מערכת ההפעלה שאתם מעדיפים לא זמינות ב-latest, אתם יכולים להשתמש ב-builder ספציפי כדי ליצור קובץ אימג' של האפליקציה באמצעות ה-builder שאתם מעדיפים.

  • אפשר לפרוס את השירות מהמקור באמצעות Kotlin ושפות JVM אחרות, כמו Java. השפה שבה אתם משתמשים חייבת לעמוד בכללים הבאים:

    • אפשר ליצור את האפליקציה באמצעות Maven או Gradle.
    • קובץ ה-build מכיל את כל הפלאגינים שנדרשים כדי ליצור מחלקות.

לפני הפריסה באמצעות build

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

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

  • מפעילים את Cloud Build API, אם הוא עדיין לא מופעל.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

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

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

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

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

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

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

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

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

פריסה באמצעות build

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

gcloud

  1. מפעילים את Cloud Shell במסוף Google Cloud .

    הפעלת Cloud Shell

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

  2. עוברים לספריית קובצי המקור. אם יש קובץ Docker בספריית קובצי המקור, הוא משמש את הספרייה, אבל זה לא חובה.

  3. יוצרים ומעלים את השירות:

    gcloud run deploy SERVICE --source .

    מחליפים את SERVICE בשם שרוצים לתת לשירות.

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

  5. מחכים שה-build והפריסה יסתיימו. בסיום, תופיע הודעת הצלחה ב-Cloud Run.

אחרי הפריסה, גרסת השירות הזו מטפלת ב-100% מהתנועה.

פיתוח נייטיב

אתם יכולים לאחסן את מפרט ה-Compose בקובץ YAML, ואז לפרוס אותו מקוד המקור כשירות Cloud Run באמצעות פקודת gcloud אחת.

  1. עוברים לספריית קובצי המקור. אם יש קובץ Docker בספריית קובצי המקור, הוא משמש את הספרייה, אבל זה לא חובה.

  2. בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.

    services:
  web:
    build: .
    ports:
      - "8080:8080"

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

פריסת השירותים

  1. כדי לפרוס את השירותים, מריצים את הפקודה gcloud run compose up:

    gcloud run compose up compose.yaml

  2. מגיבים y לכל בקשה להתקנת רכיבים נדרשים או להפעלת ממשקי API.

  3. אופציונלי: אם רוצים לאפשר גישה לשירות בלי אימות, הופכים את השירות לגלוי לכולם.

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

פריסת מקור מוכן מראש

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

מגבלות

פריסת מקור מוכן מראש נתמכת רק במקרים הבאים:

  • שירותי Cloud Run.
  • סביבות זמן ריצה נתמכות (אין תמיכה בקובצי Docker).
  • ארכיון מקור (‎.tar.gz) <= 250MiB.
  • הקובץ הבינארי (לדוגמה, קובץ בינארי של Go) או הסקריפט (לדוגמה, סקריפט של Python) חייבים להיות תואמים לארכיטקטורת x86.
  • המקור צריך להיות עצמאי, וכל יחסי התלות צריכים להיות ארוזים. תמונת הבסיס של סביבת זמן הריצה מכילה רק את מערכת ההפעלה המינימלית וכמה ספריות שפה.

לפני פריסת קוד מקור מוכן מראש

כדי להשתמש בתכונה "פריסה ללא גרסה":

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

  • מפעילים את Cloud Run API ואת Cloud Storage API:

    gcloud services enable run.googleapis.com \
  storage.googleapis.com

  • לפני הפריסה, צריך להתקין את יחסי התלות של האפליקציה באופן מקומי, כי הם לא יותקנו (אין build).

פריסה בלי build

בקטע הזה מוסבר איך לפרוס את המקור שנוצר מראש ישירות ב-Cloud Run.

gcloud

כדי לפרוס קוד מקור מוכן מראש מספרייה מקומית, משתמשים בדגל --no-build כדי להורות לפקודה deploy לדלג על השלב של Cloud Build:

gcloud beta run deploy SERVICE_NAME \
  --source APPLICATION_PATH \
  --no-build \
  --base-image=BASE_IMAGE \
  --command=COMMAND \
  --args=ARG

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

  • ‫SERVICE_NAME: השם של שירות Cloud Run.
  • ‫APPLICATION_PATH: המיקום של האפליקציה במערכת הקבצים המקומית.

  • ‫BASE_IMAGE: תמונת הבסיס של סביבת זמן הריצה שבה רוצים להשתמש באפליקציה. לדוגמה: us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24. אפשר גם להשתמש בכינוי הקצר nodejs24.

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

  • ‫COMMAND: הפקודה שהקונטיינר מופעל איתה. זה שינוי אופציונלי. אם לא תציינו פקודה, קובץ האימג' הבסיסי יסיק את פקודת ההתחלה של הקונטיינר בזמן הריצה.

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

YAML

אפשר לאחסן את מפרט השירות בקובץ YAML ואז לפרוס אותו באמצעות ה-CLI של gcloud או עורך Google Cloud המסוף service.yaml.

  1. יוצרים קטגוריית אחסון שתכיל את האפליקציה:

    gcloud storage buckets create gs://BUCKET_NAME --location=BUCKET_LOCATION

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

  2. יוצרים ארכיון עם מקור האפליקציה באמצעות zip או tar, לדוגמה:

    tar -cvzf ARCHIVE_NAME APPLICATION_PATH

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

    • ‫ARCHIVE_NAME: שם הארכיון שרוצים ליצור. לדוגמה, app.tar.gz.
    • ‫APPLICATION_PATH: המיקום של האפליקציה במערכת הקבצים המקומית. לדוגמה, ~/my-application. כדי להעביר לארכיון את ספריית העבודה הנוכחית, מגדירים את הערך הזה בתור *.

  3. מעלים את ארכיון האפליקציה ל-Cloud Storage:

    gcloud storage cp ARCHIVE_NAME gs://BUCKET_NAME

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

    • ‫ARCHIVE_NAME: הנתיב המקומי לארכיון שיצרתם קודם. לדוגמה, app.tar.gz.
    • ‫BUCKET_NAME: שם הקטגוריה שיצרתם קודם. לדוגמה, my-bucket.

  4. יוצרים קובץ service.yaml חדש עם התוכן הבא:

    apiVersion: serving.knative.dev/v2
kind: Service
metadata:
 name: SERVICE_NAME
spec:
 template:
   metadata:
     annotations:
       run.googleapis.com/sources: '{"": "gs://BUCKET_NAME/ARCHIVE_NAME"}'
       run.googleapis.com/base-images: '{"": "BASE_IMAGE"}'
   spec:
     containers:
     - image: scratch
       command:
       - COMMAND
       args:
       - ARG1
       - ARG-N
     runtimeClassName: run.googleapis.com/linux-base-image-update

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

    • ‫SERVICE_NAME: השם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של עד 49 תווים, וייחודיים לכל אזור ופרויקט.
    • ‫BUCKET_NAME: שם הקטגוריה שיצרתם קודם. לדוגמה, my-bucket.
    • ‫ARCHIVE_NAME: הנתיב המקומי לארכיון שיצרתם קודם. לדוגמה, app.tar.gz.

    • ‫BASE_IMAGE: קובץ האימג' הבסיסי של סביבת זמן הריצה שבו רוצים להשתמש באפליקציה. לדוגמה, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.

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

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

    • ‫ARG1: הארגומנט שאתם שולחים לפקודת הקונטיינר. אם משתמשים בכמה ארגומנטים, צריך לציין כל אחד מהם בשורה נפרדת, כמו בדוגמה ARG-N. זה שינוי אופציונלי. אם לא תציינו ארגומנטים, תמונת הבסיס תסיק את הארגומנטים בזמן הריצה.

  5. פורסים את השירות החדש:

    gcloud run services replace service.yaml

‫API בארכיטקטורת REST

כדי לפרוס באמצעות ה-API בארכיטקטורת REST:

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X POST \
-d '{"template": {"containers": [{"command": ["COMMAND"], "args": ["ARG1"], "image": "scratch", "baseImageUri": "BASE_IMAGE", "sourceCode": {"cloudStorageSource": {"bucket": "'GCS_BUCKET_NAME", "object":"ARCHIVE_NAME"}}}]}}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE_NAME

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

  • ‫ACCESS_TOKEN: טוקן גישה תקין לחשבון עם הרשאות IAM לפריסת שירותים. לדוגמה, אם אתם מחוברים ל-gcloud, אתם יכולים לאחזר אסימון גישה באמצעות gcloud auth print-access-token. מתוך מכונה של קונטיינר ב-Cloud Run, אתם יכולים לאחזר טוקן גישה באמצעות שרת המטא-נתונים של המכונה של הקונטיינר.
  • ‫COMMAND: הפקודה שבאמצעותה המאגר יופעל. זה שינוי אופציונלי. אם לא תציינו פקודה, קובץ האימג' הבסיסי יסיק את פקודת ההתחלה של הקונטיינר בזמן הריצה.
  • ‫ARG1: הארגומנט שאתם שולחים לפקודת הקונטיינר. אם משתמשים בכמה ארגומנטים, צריך לציין כל אחד מהם בשורה נפרדת, כמו בדוגמה ARG-N. זה שינוי אופציונלי. אם לא תציינו ארגומנטים, תמונת הבסיס תסיק את הארגומנטים בזמן הריצה.

  • ‫BASE_IMAGE: קובץ האימג' הבסיסי של סביבת זמן הריצה שבו רוצים להשתמש באפליקציה. לדוגמה, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.

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

  • ‫BUCKET_NAME: שם הקטגוריה שיצרתם קודם. לדוגמה, my-bucket.

  • ‫ARCHIVE_NAME: הנתיב המקומי לארכיון שיצרתם קודם. לדוגמה, app.tar.gz.

  • ‫PROJECT-ID: מזהה הפרויקט ב- Google Cloud .

  • ‫REGION: האזור של השירות Google Cloud .

  • ‫SERVICE_NAME: השם של שירות Cloud Run. שמות השירותים צריכים להיות באורך של עד 49 תווים, וייחודיים לכל אזור ופרויקט.

Terraform

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

מוסיפים את הקוד הבא למשאב google_cloud_run_v2_service בתצורה של Terraform:
resource "google_storage_bucket_object" "source_tar" {
  provider = google-beta
  name   = "ARCHIVE_NAME"
  bucket = "BUCKET_NAME"
  source = "ARCHIVE_PATH"
}

resource "google_cloud_run_v2_service" "default" {
  provider = google-beta
  name     = "SERVICE_NAME"
  location = "REGION"
  deletion_protection = false

  template {
    containers {
      image = "scratch"
      base_image_uri = "BASE_IMAGE"
      command = ["COMMAND"]
      args = ["ARG1"]
      source_code {
        cloud_storage_source {
          bucket = "BUCKET_NAME"
          object = google_storage_bucket_object.source_tar.name
          generation = google_storage_bucket_object.source_tar.generation
        }
      }
    }
  }
}

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

  • ‫ARCHIVE_NAME: שם הקובץ כמו שהוא יופיע בקטגוריה של Cloud Storage. לדוגמה, source-code.tar.gz.
  • ‫BUCKET_NAME: שם הקטגוריה שאליה רוצים להעלות את ארכיון המקור. לדוגמה, my-source-bucket.
  • ‫ARCHIVE_PATH: הנתיב המקומי לארכיון שיצרתם קודם. לדוגמה, ./app.tar.gz. הארכיון הזה חייב להיות בפורמט GZIP‏ (.tar.gz).
  • ‫SERVICE_NAME: השם של שירות Cloud Run
  • ‫REGION: האזור Google Cloud של הקטגוריה ושל השירות. לדוגמה, europe-west1. שני המשאבים צריכים להיות באותו אזור כדי למנוע זמן קצוב לתפוגה של החילוץ.
  • ‫BASE_IMAGE: קובץ האימג' הבסיסי של סביבת זמן הריצה שבו רוצים להשתמש באפליקציה. לדוגמה, us-central1-docker.pkg.dev/serverless-runtimes/google-24/runtimes/nodejs24.
  • ‫COMMAND: הפקודה שבאמצעותה המאגר יופעל. זה שינוי אופציונלי. אם לא תציינו פקודה, קובץ האימג' הבסיסי יסיק את פקודת ההתחלה של הקונטיינר בזמן הריצה.
  • ‫ARG1: הארגומנט שאתם שולחים לפקודת הקונטיינר. זה שינוי אופציונלי. אם לא תציינו ארגומנטים, תמונת הבסיס תסיק את הארגומנטים בזמן הריצה.

MCP

אתם יכולים להשתמש בסוכן AI כדי לפרוס את השירות עם או בלי קטגוריית אחסון באמצעות שרת ה-MCP הרשמי של Cloud Run.

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

  1. כדי להגדיר את שרת ה-MCP המרוחק של Cloud Run, פועלים לפי ההוראות במדריך שימוש בשרת ה-MCP המרוחק של Cloud Run.

    • באמצעות קטגוריית אחסון

      כדי ליצור קטגוריית אחסון ולפרוס שירות, נותנים לסוכן את ההנחיה הבאה: Create storage bucket "my-bucket" for my source code and deploy service "my-app" to Cloud Run from source in this current directory.

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

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

    • בלי קטגוריית אחסון

      אם קטעי הקוד הם בגודל של עד 50MiB ואין להם תלויות חיצוניות, אתם יכולים להנחות את הנציג לפרוס בלי קטגוריית אחסון באמצעות ההנחיה הבאה: Deploy service "my-app" to Cloud Run from source in this current directory.

      הסוכן משתמש בכלי deploy_service_from_file_contents כדי להעביר את קוד המקור ישירות מקובצי המקור המקומיים ל-Cloud Run.

שימוש בהנחיה /deploy

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

כדי לפרוס את ספריית העבודה הנוכחית ב-Cloud Run, מריצים את ההנחיה הבאה ב-/deploy:

/deploy SERVICE_NAME \
    --project PROJECT_ID \
    --region REGION \

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

  • ‫SERVICE_NAME: השם של שירות Cloud Run
  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫REGION: שם האזור

דוגמאות לפריסה של קוד מקור מוכן מראש

בקטע הזה מוצגות דוגמאות לפריסה מקוד המקור בלי להשתמש ב-build.

Node.js

יוצרים שירות Node.js:

  1. יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:

    mkdir helloworld
cd helloworld

  2. יוצרים קובץ package.json עם התוכן הבא:

    {
  "name": "helloworld",
  "description": "Simple hello world sample in Node",
  "version": "1.0.0",
  "private": true,
  "main": "index.js",
  "type": "module",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": ">=16.0.0"
  },
  "author": "Google LLC",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^5.2.1"
  }
}

  3. באותה ספרייה, יוצרים קובץ index.js ומעתיקים אליו את השורות הבאות:

    import express from 'express';
const app = express();

app.get('/', (req, res) => {
  const name = process.env.NAME || 'World';
  res.send(`Hello ${name}!`);
});

const port = parseInt(process.env.PORT) || 8080;
app.listen(port, () => {
  console.log(`helloworld: listening on port ${port}`);
});

    הקוד הזה יוצר שרת אינטרנט בסיסי שמאזין ליציאה שמוגדרת על ידי משתנה הסביבה PORT.

  4. בספרייה helloworld, מריצים את הפקודה הבאה כדי להתקין את יחסי התלות של השירות באופן מקומי:

    npm install

  5. בספרייה helloworld, פורסים את השירות באמצעות הדגל --no-build, שמורה לפקודה deploy לדלג על השלב של Cloud Build:

    gcloud beta run deploy helloworld \
 --source . \
 --region=REGION \
 --no-build \
 --base-image=nodejs24 \

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

    • ‫REGION: האזור שבו השירות פרוס.

Python

יוצרים שירות ב-Python:

  1. יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:

    mkdir helloworld
cd helloworld

  2. יוצרים קובץ בשם main.py ומדביקים בו את הקוד הבא:

    import os

from flask import Flask

app = Flask(__name__)


@app.route("/")
def hello_world():
    """Example Hello World route."""
    name = os.environ.get("NAME", "World")
    return f"Hello {name}!"


if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

    הקוד הזה מגיב לבקשות עם הברכה "Hello World". הטיפול ב-HTTP מתבצע על ידי שרת אינטרנט של Gunicorn בקונטיינר. כשמפעילים את הקוד ישירות לשימוש מקומי, הוא יוצר שרת אינטרנט בסיסי שמאזין ליציאה שמוגדרת על ידי משתנה הסביבה PORT.

  3. יוצרים קובץ בשם requirements.txt ומדביקים בו את הקוד הבא:

    Flask==3.1.3; python_version >= '3.9'
gunicorn==23.0.0
Werkzeug==3.1.9; python_version >= '3.10'

    הקוד הזה מוסיף חבילות שנדרשות לדוגמה.

  4. יוצרים עותק מקוד של צד שלישי (vendoring) של יחסי התלות:

    pip3 install -r requirements.txt --target=./vendor

  5. פורסים את השירות באמצעות ה-CLI של gcloud. הדגל --no-build מורה לפקודה deploy לעקוף את השלב של Cloud Build:

    gcloud beta run deploy helloworld \
  --source . \
  --region=REGION \
  --no-build \
  --base-image=python314 \

מחליפים את REGION באזור שבו השירות פרוס.

המשך

יוצרים ופורסים שירות Go באמצעות סביבת זמן הריצה OS only:

  1. יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:

    mkdir helloworld
cd helloworld

  2. מאתחלים קובץ go.mod מספריית הפרויקט כדי להצהיר על מודול go:

    go mod init github.com/GoogleCloudPlatform/golang-samples/run/helloworld

  3. יוצרים קובץ חדש בשם main.go ומדביקים בו את הקוד הבא:

    
// Sample run-helloworld is a minimal Cloud Run service.
package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)

func main() {
	log.Print("starting server...")
	http.HandleFunc("/", handler)

	// Determine port for HTTP service.
	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
		log.Printf("defaulting to port %s", port)
	}

	// Start HTTP server.
	log.Printf("listening on port %s", port)
	if err := http.ListenAndServe(":"+port, nil); err != nil {
		log.Fatal(err)
	}
}

func handler(w http.ResponseWriter, r *http.Request) {
	name := os.Getenv("NAME")
	if name == "" {
		name = "World"
	}
	fmt.Fprintf(w, "Hello %s!\n", name)
}

  4. כדי ליצור את הקובץ הבינארי שמטרגט מערכת הפעלה של Linux, כמו linux/amd64, מריצים את הפקודה הבאה:

    GOOS="linux" GOARCH=amd64 go build main.go

  5. פורסים את השירות באמצעות ה-CLI של gcloud. הדגל --no-build מורה לפקודה deploy לדלג על השלב של Cloud Build:

    gcloud beta run deploy helloworld \
  --source . \
  --region=REGION \
  --no-build \
  --base-image=osonly24 \
  --command=./main

מחליפים את REGION באזור שבו השירות פרוס.

פתרון בעיות

בקטע הזה מפורטים כמה טיפים לפתרון בעיות בפריסה מהמקור בלי להשתמש ב-build.

פיתוח מקומי

פריסה מהמקור בלי להשתמש ב-build פועלת באופן דומה לטעינת הקוד או קובץ ההפעלה לתמונת הבסיס.

לדוגמה:

  1. יוצרים עותק של כל התוכן:

    cp -R python/hello-world/ workspace

  2. מריצים את קובץ האימג' הבסיסי כמשתמש Root כשהמקור מותקן. אם אתם צריכים לבצע curl ממכונה מארחת, אתם יכולים לכלול את -p 8080:8080.

    docker run -it -v "LOCAL_PATH" -u 0 us-central1-docker.pkg.dev/serverless-runtimes/google-22-full/runtimes/python314 /bin/bash`

    מחליפים את LOCAL_PATH במיקום של קובצי המקור המקומיים.

  3. מפעילים את השרת:

    python main.py

יומן ביצוע

יומן ההרצה שימושי לניפוי באגים של כשלים בפריסה. במסוףGoogle Cloud , נכנסים לדף Observability > Logs.

ההרשאה נדחתה בגישה ל-Cloud Storage

אם בשירות Cloud Run מופיעות שגיאות מסוג "אין הרשאה" כשמנסים לגשת לאובייקטים ב-Cloud Storage, צריך לתת את התפקיד roles/storage.objectViewer לחשבון השירות של Cloud Run:

gcloud projects add-iam-policy-binding PROJECT \
  --member="SERVICE_ACCOUNT" \
  --role="roles/storage.objectViewer"

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

  • ‫PROJECT: מזהה הפרויקט ב- Google Cloud .
  • ‫SERVICE_ACCOUNT: חשבון השירות שלכם ב-Cloud Run. לדוגמה, service-123@serverless-robot-staging.iam.gserviceaccount.com.

אוטומציה של בנייה מהמקור

כדי להימנע משינויים ללא גרסה במקור המקומי, מומלץ לפרוס באופן אוטומטי כששינויים נדחפים למאגר Git. כדי להקל על התהליך, אתם יכולים לחבר ולהגדיר פריסה רציפה לשירות Cloud Run. כשמקשרים את המאגרים ב-GitHub ל-Cloud Run, אפשר להגדיר גרסאות build ולפרוס את המאגרים בלי לכתוב קובצי Docker או קובצי build.

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

השבתת בדיקת התקינות של הפריסה

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

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

gcloud

כדי להשבית את בדיקת התקינות של הפריסה, משתמשים בדגל --no-deploy-health-check:

gcloud run deploy --image IMAGE_URL --no-deploy-health-check

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

  • ‫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.

אם בדיקת התקינות של הפריסה הושבתה בעבר, אפשר להשתמש ב---deploy-health-check כדי להפעיל אותה מחדש.

YAML

כדי להשבית את בדיקת התקינות של הפריסה, מוסיפים את ההערה run.googleapis.com/health-check-disabled עם הערך 'true' ל-spec.template.metadata.annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/health-check-disabled: 'true'

Terraform

כדי להשבית את בדיקת התקינות של הפריסה, מגדירים את הארגומנט health_check_disabled לערך true בבלוק template.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  ...
  template {
    health_check_disabled = true
    ...
  }
}

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

אחרי שפורסים שירות Cloud Run, אפשר:

מידע ולמידה על הגדרות הפריסה של המקור:

אתם יכולים להפוך את ה-builds והפריסות של שירותי Cloud Run לאוטומטיים באמצעות טריגרים לפיתוח גרסת Build של Cloud Build: