Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

פריסה ממקור עם בנייה (ברירת מחדל): האפשרות הזו משתמשת ב-Buildpacks של Google Cloud וב-Cloud Build כדי ליצור אוטומטית קובצי אימג' של קונטיינרים מקוד המקור שלכם, בלי שתצטרכו להתקין את Docker במחשב או להגדיר buildpacks או Cloud Build. כברירת מחדל, Cloud Run משתמש בסוג המכונה שמוגדר כברירת מחדל ב-Cloud Build. הרצת הפקודה gcloud run deploy --source מבטלת גם את הצורך בהרצת הפקודה gcloud builds submit.
Deploy from source without build (פריסה מקוד המקור בלי לבצע build) (גרסת Preview): האפשרות הזו מאפשרת לפרוס ארטיפקטים ישירות ל-Cloud Run, בלי לעבור את שלב ה-Cloud Build. כך אפשר לקצר את משך הפריסה.

הערה: פריסות של מקורות משתמשות ב-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 כמו שמתואר בדף ההגדרה.
אם אתם כפופים למדיניות ארגונית של הגבלת דומיין שמגבילה הפעלות לא מאומתות של הפרויקט, תצטרכו לגשת לשירות הפרוס שלכם כמו שמתואר בקטע בדיקת שירותים פרטיים.
מפעילים את Cloud Run Admin API.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
להפעלת ה-API

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

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

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

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

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

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

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

שפות נתמכות

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

זמן ריצה	פריסת המקור	הגדרות אישיות
המשך	פריסת שירות 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:

פועלים לפי השלבים בקטע לפני שמתחילים.
מפעילים את Cloud Build API.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
להפעלת ה-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.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts מונע מחשבונות שירות שמוגדרים כברירת מחדל לקבל את התפקיד 'עריכה' באופן אוטומטי. אם יצרתם את הארגון אחרי 3 במאי 2024, האילוץ הזה נאכף כברירת מחדל.

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

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

פריסה עם build

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

gcloud

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

הפעלת Cloud Shell

בחלק התחתון של Google Cloud המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.
עוברים לספריית קובצי המקור. ספריית קובצי המקור משתמשת בקובץ Dockerfile אם הוא קיים, אבל הוא לא נדרש.
יוצרים ופורסים את השירות:
```
gcloud run deploy SERVICE --source .
```
מחליפים את SERVICE בשם שרוצים לתת לשירות.
אם מופיעה בקשה להתקין ממשקי API נדרשים, משיבים y כשמופיעה הבקשה. צריך לעשות את זה רק פעם אחת לכל פרויקט. אם לא הגדרתם ערכי ברירת מחדל לפלטפורמה ולאזור כמו שמתואר בדף ההגדרה, תצטרכו להגיב להנחיות אחרות ולציין את הפלטפורמה והאזור.
מחכים לסיום של ה-build והפריסה. בסיום, תוצג הודעה על הצלחה ב-Cloud Run.

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

Gemini CLI

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

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

מתקינים את הגרסה האחרונה של Gemini CLI.

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

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

מתחברים ל-Google Cloud CLI:
```
gcloud auth login
```
מגדירים Application Default Credentials:
```
gcloud auth application-default login
```
עוברים לספריית קוד המקור.
מפעילים את Gemini CLI:
```
gemini
```
יוצרים ופורסים את השירות:
```
/deploy
```
- אם תתבקשו לציין את Google Cloud הפרויקט, הזינו את שם הפרויקט.
- אם מוצגת בקשה לבחור כלי, בוחרים באפשרות deploy_local_folder.
מחכים לסיום של ה-build והפריסה. בסיום, תוצג הודעה על הצלחה ב-Cloud Run.

פיתוח נייטיב

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

עוברים לספריית קובצי המקור. ספריית המקור משתמשת ב-Dockerfile אם הוא קיים, אבל הוא לא נדרש.
בספריית הפרויקט, יוצרים קובץ compose.yaml עם הגדרות השירות.
```
services:
  web:
    build: .
    ports:
      - "8080:8080"
```
אפשר גם לציין אפשרויות הגדרה נוספות, כמו משתני סביבה, סודות והצמדות של נפחים.

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

כדי לפרוס את השירותים, מריצים את הפקודה gcloud run compose up:
```
gcloud run compose up compose.yaml
```
מגיבים y לכל ההנחיות להתקנת רכיבים נדרשים או להפעלת ממשקי API.
אופציונלי: הפיכת השירות לציבורי אם רוצים לאפשר גישה לשירות ללא אימות.

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

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

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

מגבלות

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

שירותי 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).

פריסה ללא 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. מידע נוסף זמין במאמר בנושא זמן ריצה של מערכת הפעלה בלבד במסמכי התיעוד של Buildpacks.
‫COMMAND: הפקודה שהקונטיינר מופעל איתה.
‫ARG: ארגומנט ששולחים לפקודת מאגר התגים. אם משתמשים בכמה ארגומנטים, צריך לציין כל אחד מהם בשורה נפרדת.

YAML

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

יוצרים קטגוריית אחסון לאחסון האפליקציה:
```
gcloud storage buckets create gs://BUCKET_NAME --location=BUCKET_LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_NAME: השם שרוצים לתת לקטגוריה, בכפוף לדרישות למתן שמות. לדוגמה, my-bucket.
- ‫BUCKET_LOCATION: המיקום של הקטגוריה. לדוגמה, US.
יוצרים ארכיון עם מקור האפליקציה באמצעות zip או tar, לדוגמה:
```
tar -cvzf ARCHIVE_NAME APPLICATION_PATH
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ARCHIVE_NAME: השם של הארכיון שרוצים ליצור. לדוגמה, app.tar.gz.
- ‫APPLICATION_PATH: המיקום של האפליקציה במערכת הקבצים המקומית. לדוגמה, ~/my-application. כדי לארכב את ספריית העבודה הנוכחית, מגדירים את הערך הזה כ-*.
מעלים את הארכיון של האפליקציה ל-Cloud Storage:
```
gcloud storage cp ARCHIVE_NAME gs://BUCKET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ARCHIVE_NAME: הנתיב המקומי לארכיון שיצרתם קודם. לדוגמה, app.tar.gz.
- ‫BUCKET_NAME: השם של הקטגוריה שיצרתם קודם. לדוגמה, my-bucket.
יוצרים קובץ 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. מידע נוסף זמין במאמר בנושא זמן ריצה של מערכת הפעלה בלבד במסמכי התיעוד של Buildpacks.
- ‫COMMAND: הפקודה שהקונטיינר צריך להפעיל כדי להתחיל.
- ‫ARG1: הארגומנט שאתם שולחים לפקודת הקונטיינר. אם משתמשים בכמה ארגומנטים, צריך לציין כל אחד מהם בשורה נפרדת, כמו בדוגמה ARG-N.

פריסת השירות החדש:

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. מידע נוסף זמין במאמר בנושא זמן ריצה של מערכת הפעלה בלבד במסמכי התיעוד של 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-full/runtimes/nodejs24.
‫COMMAND: הפקודה שהקונטיינר צריך להפעיל.
‫ARG1: הארגומנט שאתם שולחים לפקודת הקונטיינר.

MCP

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

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

כדי להגדיר את שרת ה-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:

יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:
```
mkdir helloworld
cd helloworld
```

יוצרים קובץ 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"
  }
}

באותה תיקייה, יוצרים קובץ 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.

בספרייה helloworld, מריצים את הפקודה הבאה כדי להתקין את יחסי התלות של השירות באופן מקומי:
```
npm install
```
בספרייה 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:

יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:
```
mkdir helloworld
cd helloworld
```
יוצרים קובץ בשם 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.
יוצרים קובץ בשם requirements.txt ומדביקים בו את הקוד הבא:
```
Flask==3.1.3; python_version >= '3.9'
gunicorn==23.0.0
Werkzeug==3.1.8; python_version >= '3.9'
```
הקוד הזה מוסיף חבילות שנדרשות לדוגמה.
יוצרים עותק מקוד של צד שלישי (vendoring) של יחסי התלות:
```
pip3 install -r requirements.txt --target=./vendor
```

פורסים את השירות באמצעות ה-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 באמצעות זמן ריצה של מערכת ההפעלה בלבד:

יוצרים ספרייה חדשה בשם helloworld ועוברים אליה:
```
mkdir helloworld
cd helloworld
```
מאתחלים קובץ go.mod מספריית הפרויקט כדי להצהיר על מודול Go:
```
go mod init github.com/GoogleCloudPlatform/golang-samples/run/helloworld
```

יוצרים קובץ חדש בשם 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)
}

מריצים את הפקודה הבאה כדי ליצור את הקובץ הבינארי שמיועד למערכת הפעלה של Linux, כמו linux/amd64:
```
GOOS="linux" GOARCH=amd64 go build main.go
```
פורסים את השירות באמצעות ה-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 דומה להעלאת הקוד או קובץ ההפעלה לתמונת הבסיס.

לדוגמה:

יוצרים עותק של כל התוכן:
```
cp -R python/hello-world/ workspace
```
מריצים את קובץ האימג' הבסיסי כמשתמש 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 במיקום של קובצי המקור המקומיים.
מריצים את השרת:
```
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:

הגדרת פריסה רציפה

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

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

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

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

שפות נתמכות

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

מגבלות

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

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

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

פריסה עם build

gcloud

Gemini CLI

פיתוח נייטיב

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

מגבלות

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

פריסה ללא build

gcloud

YAML

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

Terraform

MCP

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

Node.js

Python

המשך

פתרון בעיות

פיתוח מקומי

יומן ביצוע

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

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

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

gcloud

YAML

Terraform

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

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