פריסת שירות, משימה או מאגר עובדים ב-Cloud Run

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

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

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

מגבלות

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

יצירת הגדרת היעד

אפשר להגדיר את היעד בקובץ ה-YAML של צינור ההפצה, או בקובץ נפרד. בנוסף, אפשר להגדיר יותר מיעד אחד באותו קובץ.

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

בהגדרת היעד, יוצרים קטע run כדי לציין את המיקום שבו ייצור שירות Cloud Run.

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

run:
 location: projects/[project_name]/locations/[region_name]

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

  • ‫project_name הוא שם הפרויקט שבו ייצור שירות Cloud Run, משימה או מאגר עובדים. Google Cloud

    צריך לעשות את זה לכל יעד. מומלץ להשתמש בפרויקט אחר לכל שירות, משימה או מאגר עובדים של Cloud Run. אם רוצים יותר משירות אחד, מעבודת תצורה או ממאגר עובדים באותו פרויקט, צריך להשתמש בפרופילים של Skaffold בקובץ ההגדרות של skaffold.yaml.

  • ‫region_name הוא האזור שבו ייצור השירות, המשרה או מאגר העובדים. השירות, המשימה או מאגר העובדים יכולים להיות בכל אזור שנתמך על ידי Cloud Run.

בדוגמה הבאה מוצגת הגדרת יעד, שבה מוגדר שייווצרו שירות Cloud Run, משימה או מאגר עובדים:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

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

יצירת הגדרת Skaffold

הקובץ הבא הוא דוגמה לקובץ skaffold.yaml של פריסה ב-Cloud Run:

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

בקובץ skaffold.yaml הזה…

  • ‫manifests.rawYaml מציין את השמות של הגדרות השירות ב-Cloud Run.

    בדוגמה הזו, service.yaml הוא הקובץ שמגדיר שירות Cloud Run ש-Skaffold יפרוס. שם הקובץ יכול להיות כל שם, אבל לפי המוסכמה, הוא service.yaml לשירות, job.yaml לעבודה ו-workerpool.yaml למאגר עובדים.

  • בפסקה deploy מציינים איך רוצים לפרוס את המניפסט, ובאופן ספציפי את הפרויקט והמיקום. השדה deploy הוא שדה חובה.

    מומלץ להשאיר את התג הריק {}. ‫Cloud Deploy מאכלס את הערך הזה במהלך הרינדור, על סמך הפרויקט והמיקום מהגדרת היעד.

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

יצירת הגדרות של שירות Cloud Run

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

אפשרות 1: יצירת שירות חדש ב-Cloud Run service.yaml

בקובץ service.yaml מוגדר שירות Cloud Run. כשיוצרים גרסת הפצה, Skaffold משתמש בהגדרה הזו כדי לפרוס את השירות.

הנה דוגמה פשוטה:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

כאשר:

  • ‫[SERVICE_NAME] הוא שם לשירות Cloud Run הזה.

  • ‫[IMAGE_PATH] מצביע על קובץ אימג' של קונטיינר או על קובצי אימג' של קונטיינר שאתם פורסים באמצעות השירות הזה.

אפשרות 2: העתקת service.yaml משירות קיים באמצעות Google Cloud מסוף

אפשר ליצור שירות באמצעות Google Cloud console או להשתמש בשירות קיים, ולהעתיק משם את service.yaml.

כדי לקבל את service.yaml באמצעות Google Cloud CLI:

gcloud run services describe [service_name] --format=export

כדי לקבל את service.yaml ממסוף Google Cloud :

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

  2. בוחרים את השירות הקיים שרוצים להשתמש בהגדרה שלו.

אפשר גם ליצור תווית חדשה ואז לבחור אותה. כשבוחרים את השירות, מוצג דף פרטי השירות:

דף פרטי השירות במסוףGoogle Cloud , עם הכרטיסייה YAML

  1. לוחצים על הכרטיסייה YAML.

  2. לוחצים על עריכה, ואז מעתיקים את התוכן של קובץ ה-YAML לקובץ חדש בשם service.yaml במערכת הקבצים, כך ש-Skaffold יוכל להשתמש בו כשיוצרים גרסת הפצה.

יצירת הגדרות של משימות Cloud Run

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

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

אפשרות 1: יצירת שירות חדש ב-Cloud Run job.yaml

הקובץ job.yaml מגדיר את משימת Cloud Run. כשיוצרים גרסת הפצה, Skaffold משתמש בהגדרה הזו כדי לפרוס את העבודה.

הנה דוגמה פשוטה:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

כאשר:

  • ‫[JOB_NAME] הוא שם למשימת Cloud Run.

  • ‫[IMAGE_PATH] מצביע על קובץ אימג' של קונטיינר שאתם פורסים עבור המשימה הזו.

אפשרות 2: העתקת job.yaml ממשימה קיימת באמצעות Google Cloud מסוף

אפשר ליצור משימה באמצעות Google Cloud המסוף או להשתמש במשימה קיימת, ולהעתיק משם את job.yaml.

כדי לקבל את job.yaml באמצעות Google Cloud CLI:

gcloud run jobs describe [job_name] --format=export

כדי לקבל את job.yaml ממסוף Google Cloud :

  1. נכנסים לדף Cloud Run Jobs במסוף Google Cloud .

  2. בוחרים את הגדרת העבודה הקיימת שרוצים להשתמש בה.

אפשר גם ליצור תווית חדשה ואז לבחור אותה. כשבוחרים את המשימה, מוצג הדף 'פרטי המשימה':

דף הפרטים של המשימה במסוףGoogle Cloud , שבו מוצגת הכרטיסייה YAML

  1. לוחצים על הכרטיסייה YAML.

  2. לוחצים על עריכה, ואז מעתיקים את התוכן של קובץ ה-YAML לקובץ חדש בשם job.yaml במערכת הקבצים, כך ש-Skaffold יוכל להשתמש בו כשיוצרים גרסת הפצה.

יצירת הגדרות של מאגר עובדים ב-Cloud Run

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

אפשרות 1: יצירת שירות חדש ב-Cloud Run workerpool.yaml

הקובץ workerpool.yaml מגדיר את מאגר העובדים של Cloud Run. כשיוצרים גרסת הפצה, Skaffold משתמש בהגדרה הזו כדי לפרוס את מאגר העובדים.

הנה דוגמה פשוטה:

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
 name: [WORKERPOOL_NAME]
 annotations:
  run.googleapis.com/launch-stage: BETA
spec:
  template:
   spec:
    containers:
    - image: [IMAGE_PATH]

כאשר:

  • ‫[WORKERPOOL_NAME] הוא השם של מאגר העובדים הזה ב-Cloud Run.

  • ‫[IMAGE_PATH] מצביע על קובץ אימג' של קונטיינר שאתם פורסים למאגר העובדים הזה.

אפשרות 2: העתקת workerpool.yaml ממאגר כוח עבודה קיים באמצעות Google Cloud מסוף

אפשר ליצור מאגר עובדים באמצעות Google Cloud המסוף או להשתמש במאגר קיים, ולהעתיק משם את workerpool.yaml.

כדי לקבל את workerpool.yaml באמצעות Google Cloud CLI:

gcloud beta run worker-pools describe [workerpool_name] --format=export

כדי לקבל את workerpool.yaml ממסוף Google Cloud :

  1. במסוף Google Cloud , עוברים לדף Cloud Run Worker pools.

  2. בוחרים את מאגר העובדים הקיים שרוצים להשתמש בהגדרה שלו.

אפשר גם ליצור תווית חדשה ואז לבחור אותה. כשבוחרים את מאגר העובדים, מוצג הדף 'פרטי מאגר העובדים':

דף הפרטים של מאגר העובדים במסוףGoogle Cloud , שבו מוצגת הכרטיסייה YAML

  1. לוחצים על הכרטיסייה YAML.

  2. מעתיקים את התוכן של קובץ ה-YAML לקובץ חדש בשם workerpool.yaml במערכת הקבצים, כדי ש-Skaffold יוכל להשתמש בו כשיוצרים גרסת הפצה.

איך הכל משתלב יחד

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

במדריך למתחילים פריסת אפליקציה ב-Cloud Run באמצעות Cloud Deploy אפשר לראות את כל זה בפעולה.

התנהגות השירותים בגרסאות שונות

כשפורסים מחדש שירות, הגרסה החדשה מבוססת על service.yaml שנפרס לאחרונה. שום דבר מהגרסה הקודמת לא נשמר, אלא אם הוא זהה ב-YAML החדש שפרסתם. לדוגמה, אם יש הגדרות או תוויות בגרסה הקודמת שלא מופיעות ב-YAML החדש, ההגדרות או התוויות האלה לא יופיעו בגרסה החדשה.

הפעלת משימות ב-Cloud Run

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

פריסת שירותים, משימות ומאגרי עובדים ב-Cloud Run בכמה פרויקטים

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

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

פריסת פונקציות Cloud Run

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

  1. בודקים את service.yaml של פונקציית Cloud Run.

    כדי לקבל את הערך הזה, מריצים את הפקודה הבאה:

    gcloud run services describe FUNCTION_NAME \
--format=export \
--region=REGION \
--project=PROJECT

  2. מסירים את ההערות הבאות, אם הן קיימות:

    • run.googleapis.com/build-base-image
    • run.googleapis.com/build-name
    • run.googleapis.com/build-source-location
    • run.googleapis.com/build-enable-automatic-updates

  3. מחליפים את הערך ב-spec.spec.containers.image בערך IMAGE_TAG.

  4. יוצרים צינור עיבוד נתונים ויעדים, עם שירות Cloud Run כיעד.

  5. להפריד את שלב הבנייה משלב הפריסה בתהליך ה-CI. במקום להשתמש ב-Google Cloud CLI כדי לפרוס את הפונקציה, מבצעים את השלבים הבאים:

    1. יוצרים גרסת build של הפונקציה בקונטיינר באמצעות Cloud Build:

      gcloud builds submit --pack image=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME \
--project=PROJECT \
--region=REGION

    2. יצירת גרסה באמצעות Cloud Deploy:

      gcloud deploy releases create RELEASE_NAME \
--project=DEPLOY_PROJECT \
--region=REGION \
--delivery-pipeline=DELIVERY_PIPELINE \
--images=IMAGE_TAG=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME

      בפקודה הזו…

      • ‫RELEASE_NAME הוא השם שרוצים לתת לגרסה הזו. השם חייב להיות ייחודי בין כל הגרסאות של צינור העברת התוכן הזה.

      • ‫DEPLOY_PROJECT הוא מזהה הפרויקט שבו יצרתם את צינור הפריסה.

      • ‫DELIVERY_PIPELINE הוא השם של צינור העברת התוכן שינהל את הפריסה של הגרסה הזו בתהליך ההתקדמות של יעדי הפריסה. השם הזה צריך להיות זהה לשם שמופיע בשדה name בהגדרת צינור הנתונים.

      • ‫REGION הוא שם האזור שבו אתם יוצרים את הגרסה, למשל us-central1. זהו שדה חובה.

      • ‫IMAGE_NAME הוא השם שנתתם לאימג' בשלב הקודם, כשבניתם את הפונקציה.

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