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

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

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

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

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

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

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

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

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

  • Enable the Cloud Run Admin API.

    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 API

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

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

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

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

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

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

שפות נתמכות

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

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

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

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

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

מגבלות

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

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

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

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

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

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

  • Enable the Cloud Build API.

    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 API

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

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

לחצו כדי לראות את התפקידים הנדרשים לחשבון השירות של 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:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

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

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

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

פריסה עם build

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

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. עוברים לספריית קובצי המקור. ספריית קובצי המקור משתמשת ב-Dockerfile אם הוא קיים, אבל הוא לא נדרש.

  3. יוצרים ופורסים את השירות:

    gcloud run deploy SERVICE --source .

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

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

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

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

    Cloud Code

    כדי לבצע פריסה ממקור באמצעות Cloud Code, אפשר לקרוא את המדריכים ל-IntelliJ ול-Visual Studio Code.

    Gemini CLI

    משתמשים בפקודה /deploy בכלי Gemini CLI כדי לפרוס שירות Cloud Run מקוד מקור.

    כדי להשתמש ב-Gemini CLI עם התוסף Cloud Run, צריך לבצע את השלבים הבאים:

    1. מתקינים את הגרסה העדכנית של Gemini CLI באחת מסביבות הפיתוח הבאות:

      • טרמינל
      • Cloud Shell
      • ‫VS Code באמצעות מצב הסוכן של Gemini Code Assist (ראו את הכרטיסייה VS Code)

    2. מתקינים את התוסף Cloud Run:

      gemini extensions install https://github.com/GoogleCloudPlatform/cloud-run-mcp

    3. מתחברים ל-Google Cloud CLI:

      gcloud auth login

    4. מגדירים Application Default Credentials:

      gcloud auth application-default login

    5. עוברים לספריית קוד המקור.

    6. מפעילים את Gemini CLI:

      gemini

    7. יוצרים ופורסים את השירות:

      /deploy
      • אם תתבקשו לציין את Google Cloud הפרויקט, הזינו את שם הפרויקט.
      • אם מוצגת בקשה לבחור כלי, בוחרים באפשרות deploy_local_folder.

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

    MCP

    כדי לפרוס שירות Cloud Run מקוד מקור מלקוח Model Context Protocol‏ (MCP), צריך להתקין את שרת Model Context Protocol‏ (MCP) של Cloud Run.

    הוראות ההתקנה משתנות בהתאם ללקוח ה-MCP. לרוב, צריך להוסיף את השורות הבאות לקובץ JSON של ההגדרות:

    "mcpServers":{
  "cloud-run": {
    "command": "npx",
    "args": ["-y", "@google-cloud/cloud-run-mcp"]
  }
}

    פיתוח נייטיב

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

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

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

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

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

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

      gcloud beta run compose up compose.yaml

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

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

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

פריסה מקוד המקור ללא בנייה

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

מגבלות

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

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

לפני שמבצעים פריסה ללא בנייה

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

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

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

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

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

פריסה ללא build

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

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-full/runtimes/nodejs24.

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

  • ‫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-full/runtimes/nodejs24.

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

    • ‫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-full/runtimes/nodejs24.

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

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

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

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

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

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

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

בקטע הזה מוצגות דוגמאות לפריסה ממקור בלי להשתמש ב-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 \
 --command=node \
 --args=index.js

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

    • ‫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.0.3
gunicorn==23.0.0
Werkzeug==3.1.6

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

  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 \
  --command=python \
  --args=main.py \
  --set-env-vars PYTHONPATH=./vendor

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

Go

יצירה ופריסה של שירות Go באמצעות זמן ריצה של מערכת ההפעלה בלבד:

  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 עם המקור המצורף. אפשר גם לכלול את -p 8080:8080 אם צריך להשתמש ב-curl ממחשב מארח.

    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.

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

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

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

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

כברירת מחדל, 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, אפשר:

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

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