הפניה לסכימת ההגדרות

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

קובץ התצורה של צינור ההפצה יכול לכלול הגדרות של יעדים, או שההגדרות האלה יכולות להיות בקובץ או בקבצים נפרדים. לפי המוסכמה, קובץ שמכיל גם את הגדרות צינור העברת הנתונים וגם את הגדרות היעד נקרא clouddeploy.yaml, והגדרות צינור העברת נתונים ללא יעדים נקראות delivery-pipeline.yaml. אבל אתם יכולים לתת לקבצים האלה כל שם שתרצו. הגדרות אחרות של משאבים, כמו אוטומציות ומדיניות פריסה, יכולות להיות גם באותו קובץ כמו הגדרה של צינור העברה או של יעד.

מה נכנס לאן

‫Cloud Deploy משתמש בשני קובצי תצורה עיקריים:

אפשר להגדיר אותם בקבצים נפרדים, או להגדיר את צינור העברת הנתונים ואת יעדי ההעברה באותו קובץ.

המבנה של קובץ הגדרות של צינור עיבוד נתונים לפריסה

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

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       predeploy:
         tasks: []
       verify:
         tasks: []
       analysis:
       postdeploy:
         tasks: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 dnsEndpoint:
 internalIp:
 proxyUrl:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
tasks:
  render:
  deploy:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
  id:
  [RULE-SPECIFIC_CONFIG]

קובץ ה-YAML הזה כולל שלושה רכיבים עיקריים:

  • צינור האספקה הראשי וההתקדמות

    קובץ התצורה יכול לכלול כל מספר של הגדרות צינור.

  • הגדרות היעד

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

  • הגדרות של סוגי יעד בהתאמה אישית

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

  • הגדרות אוטומציה

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

הגדרות הרכיבים האלה מפורטות בהמשך המסמך.

הגדרה והתקדמות של צינורות עיבוד נתונים

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

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

metadata.name

השדה name מקבל מחרוזת שחייבת להיות ייחודית לכל פרויקט ומיקום.

metadata.annotations וגם metadata.labels

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

מידע נוסף זמין במאמר שימוש בתוויות ובהערות עם Cloud Deploy.

description

מחרוזת שרירותית שמתארת את צינור העברת הנתונים הזה. התיאור הזה מוצג בפרטי צינור ההפצה ב Google Cloud מסוף.

suspended

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

ערך ברירת המחדל הוא false.

serialPipeline

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

stages

רשימה של כל יעדי הפריסה שהוגדרו בצינור העברת התכנים הזה.

הרשימה צריכה להיות מסודרת לפי סדר ההצגה שרוצים. לדוגמה, אם יש לכם יעדים בשם dev, staging ו-production, צריך לרשום אותם באותו הסדר, כך שהפריסה הראשונה תהיה ל-dev והפריסה האחרונה תהיה ל-production.

מאכלסים את השדה stages.targetId בערך של השדה metadata.name בהגדרת היעד המתאימה. ובקטע targetId, כוללים את profiles:

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

targetId

מזהה את היעד הספציפי לשימוש בשלב הזה של צינור העברת הנתונים. הערך הוא המאפיין metadata.name מהגדרת היעד.

אם strategy.standard.verify מוגדר ל-true, אימות הפריסה מופעל ביעד. אם לא מצוינת אסטרטגיית פריסה, נעשה שימוש באסטרטגיית הפריסה של standard, והאימות מוגדר ל-false.

profiles

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

strategy

כולל מאפיינים לציון אסטרטגיית פריסה. אלו האסטרטגיות שנתמכות:

  • standard:

    האפליקציה נפרסת באופן מלא ליעד שצוין.

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

  • canary:

    בפריסה של גרסה ראשונית (canary), פורסים גרסה חדשה של האפליקציה באופן הדרגתי, ומחליפים את הגרסה שכבר פועלת במרווחי זמן שמבוססים על אחוזים (לדוגמה, 25%, אחר כך 50%, אחר כך 75%, ואז באופן מלא).

אסטרטגיית הפריסה מוגדרת לכל יעד. לדוגמה, יכול להיות שיש לכם אסטרטגיית קנרי עבור יעד prod, אבל אסטרטגיה רגילה (ללא strategy) עבור היעדים האחרים.

מידע נוסף זמין במאמר שימוש באסטרטגיית פריסה.

הגדרה של strategy

בקטע הזה מוצגים רכיבי ההגדרה של strategy, לכל זמן ריצה נתמך.

אסטרטגיית פריסה רגילה

שיטת הצעת המחיר הרגילה כוללת רק את הרכיבים הבאים:

strategy:
  standard:
    verify:
      tasks: []
    analysis:

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

המאפיין verify הוא אופציונלי. אם לא מציינים את הפרמטר הזה, לא יהיה ג'וב verify בהשקות שיתקבלו.

הפסקה analysis היא אופציונלית, והיא מיועדת לשימוש עם ניתוח של Cloud Deploy.

אפשר להשמיט את רכיב strategy בשיטת פריסה רגילה.

אסטרטגיית פריסה של גרסה ראשונית (canary)

בקטעים הבאים מוסבר איך להגדיר אסטרטגיית פריסה של גרסה ראשונית (canary) לכל סביבת זמן ריצה שנתמכת ב-Cloud Deploy.

למטרות Cloud Run
strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify:
        tasks: []
      analysis:

במטרות Cloud Run,‏ AutomaticTrafficControl חייב להיות true, אלא אם מגדירים קנרי בהתאמה אישית.

למטרות של GKE ו-GKE Attached Clusters

קובץ ה-YAML הבא מראה איך להגדיר אסטרטגיית פריסה ליעד שפורס ל-GKE או לאשכולות שמצורפים ל-GKE, באמצעות רשת מבוססת-שירות:

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify:
            tasks: []

קובץ ה-YAML הבא מראה איך להגדיר אסטרטגיית פריסה ליעד שפורס ל-GKE או לאשכולות שמצורפים ל-GKE, באמצעות Gateway API:

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify:
            tasks: []

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

קובץ ה-YAML הבא מראה איך להגדיר אסטרטגיית פריסה מותאמת אישית של קנרית (ב-Service Networking, ב-Gateway API או ב-Cloud Run) או אסטרטגיית פריסה מותאמת אישית של קנרית אוטומטית (ב-Service Networking, ב-Gateway API או ב-Cloud Run). ההגדרה הספציפית לזמן הריצה, בקטע runtimeConfig, מושמטת ב-Canary בהתאמה אישית, אבל נכללת בהגדרה אוטומטית של Canary ובהגדרה אוטומטית של Canary בהתאמה אישית.

הגדרת Canary בהתאמה אישית

strategy:
  canary:
    # Runtime configs are configured as shown in the
    # Canary Deployment Strategy section of this document.
    runtimeConfig:

    # Manual configuration for each canary phase
    customCanaryDeployment:
      - name: "PHASE1_NAME"
        percent: PERCENTAGE1
        profiles: [ "PROFILE1_NAME" ]
        verify:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

verify

אפשר לכלול את פסקה verify בקטע strategy.standard, בקטע strategy.canary.canaryDeployment או בכל שלב בקטע strategy.canary.customCanaryDeployment. הוא משמש להפעלת אימות הפריסה עבור יעד. הפסקה הזו היא אופציונלית. אם היא לא מופיעה, לא מתבצע אימות של שלב ההשקה או של שלב הקנרי.

יש שתי דרכים להגדיר את verify:

  • מגדירים את verify: true.

    אם עושים את זה, צריך גם להגדיר קטע verify ב-skaffold.yaml, כמו שמתואר במאמר הגדרת Skaffold לאימות.

  • מגדירים את verify באמצעות משימה אחת או יותר שיפעלו לצורך אימות:

    verify:
  tasks: [VERIFY_TASKS]

analysis

פריסת ניתוח, שבעזרתו אפשר להריץ בדיקה אחת או יותר מול התראות של Google Cloud Observability, מוגדרת בתוך קטע strategy. פרטים נוספים על ההגדרות זמינים במאמר בנושא הגדרות ניתוח.

deployParameters

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

אפשר גם לכלול את זה ביעדים.

פריסת פרמטרים שהוגדרו בצינור עיבוד נתונים להעברה משתמשת בתוויות כדי להתאים ליעדים:

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

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

משרות של predeploy ושל postdeploy

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

משימות של פריסה מוקדמת מופעלות מיד לפני משימת הפריסה בהשקה. משימות של postdeploy מופעלות אחרי כל שאר המשימות בהשקה, כולל verify ו-analysis, אם רלוונטי.

הגדרת ה-hooks של הפריסה מתבצעת בקטע strategy.standard או strategy.canary באופן הבא:

  • שימוש ב-tasks

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          tasks: [PREDEPLOY_TASKS]
        postdeploy:
          tasks: [POSTDEPLOY_TASKS]

    כאשר:

    • ‫PREDEPLOY_TASKS הם משימה אחת או יותר שרוצים להריץ ב-hook של לפני הפריסה.

    • ‫POSTDEPLOY_TASKS הם משימות שרוצים להפעיל ב-hook של postdeploy.

  • שימוש ב-actions (וב-Skaffold)

    serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

    כאשר ACTION_NAME הוא השם שהוגדר ב-skaffold.yaml עבור customActions.name.

    אפשר להגדיר משימות של predeploy ושל postdeploy בכל אסטרטגיה (לדוגמה, standard, canary).

מידע נוסף על הגדרה ושימוש ב-hooks לפני ואחרי פריסה זמין במאמר הרצת hooks לפני ואחרי פריסה.

הגדרות היעדים

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

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

ראו גם: הגדרות של סוגי יעדים מותאמים אישית

למטרות GKE

קובץ ה-YAML הבא מראה איך להגדיר יעד שפורס לאשכול GKE:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

השם של היעד הזה. השם הזה צריך להיות ייחודי לכל אזור.

metadata.annotations וגם metadata.labels

הגדרת היעד תומכת בהערות ובתוויות של Kubernetes, אבל Cloud Deploy לא דורש אותן.

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

description

בשדה הזה אפשר להזין מחרוזת שמתארת את השימוש ביעד הזה.

deployParameters

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

הפסקה deployParameters מקבלת צמדי מפתח/ערך, כמו שמוצג:

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

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

multiTarget.targetIds: []

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

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

requireApproval

האם נדרש אישור ידני כדי להציג את המבצע הזה לקהל היעד. הערך יכול להיות true או false.

המאפיין הזה הוא אופציונלי. ערך ברירת המחדל הוא false.

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

gke

רק באשכולות GKE, נתיב המשאב שמזהה את האשכול שבו האפליקציה תופעל:

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

  • project_name

    הפרויקט שבו נמצא האשכול. Google Cloud

  • location

    המיקום שבו נמצא האשכול. לדוגמה, us-central1. האשכול יכול להיות גם אזורי (us-central1-c).

  • cluster_name

    שם האשכול, כפי שהוא מופיע ברשימת האשכולות ב-Google Cloud console.

הנה דוגמה:

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

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

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

associatedEntities.[KEY]

בתצורת קנרי, משתמשים בשם הזה כדי להפנות לישויות מ-routeDestinations. מידע נוסף

dnsEndpoint

אם מגדירים את הערך true,‏ Cloud Deploy מתחבר לאשכול GKE באמצעות נקודת הקצה של ה-DNS במקום נקודת הקצה שמוגדרת כברירת מחדל, שיכולה להיות כתובת IP ציבורית, כתובת IP פרטית או נקודת הקצה של ה-DNS, בהתאם להגדרת האשכול.

אי אפשר להשתמש באפשרות הזו ביחד עם האפשרות internalIp.

internalIp

אם מגדירים את הערך true,‏ Cloud Deploy מתחבר לאשכול GKE באמצעות כתובת ה-IP הפרטית במקום נקודת הקצה (endpoint) שמוגדרת כברירת מחדל, שיכולה להיות כתובת IP ציבורית, כתובת IP פרטית או נקודת קצה (endpoint) של DNS, בהתאם להגדרת האשכול.

אי אפשר להשתמש באפשרות הזו ביחד עם האפשרות dnsEndpoint. הגדרת הרשת ב-dnsEndpoint פשוטה הרבה יותר, ולכן מומלץ להשתמש בה במקום זאת.

proxyUrl

אם אתם ניגשים לאשכולות דרך HTTP proxy, אתם צריכים לציין כאן את המאפיין proxyUrl. הערך הוא כתובת ה-URL של ה-proxy, שמועברת אל kubectl כשמתחברים לאשכול.

למטרות Cloud Run

קובץ ה-YAML הבא מראה איך להגדיר יעד לפריסה בשירות Cloud Run:

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

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

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

metadata.name

השם של היעד הזה. השם הזה חייב להיות ייחודי לכל אזור.

metadata.annotations וגם metadata.labels

הגדרת היעד תומכת בהערות ותוויות, אבל לא צריך להשתמש בהן ב-Cloud Deploy.

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

description

השדה הזה מקבל מחרוזת שרירותית שמתארת את השימוש ביעד הזה.

multiTarget.targetIds: []

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

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

requireApproval

האם נדרש אישור ידני כדי להציג את המבצע הזה לקהל היעד. הערך יכול להיות true או false.

המאפיין הזה הוא אופציונלי. ערך ברירת המחדל הוא false.

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

run

לשירותי Cloud Run בלבד, המיקום שבו השירות ייווצר:

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

  • project_name

    Google Cloud הפרויקט שבו השירות יפעל.

  • location

    המיקום שבו השירות יפעל. לדוגמה, us-central1.

כשמגדירים [multi-target], לא מציינים את המאפיין run. במקום זאת, המיקום של שירות Cloud Run מוגדר בתוך יעד המשנה המתאים.

במאמר הזה, בקטע executionConfigs, מופיעים תיאורים של מאפייני סביבת ההפעלה.

יעדים של אשכולות GKE מצורפים

הגדרת היעד לפריסה באשכולות מצורפים של GKE דומה להגדרת יעד ליעד GKE, אבל המאפיין הוא anthosCluster.membership במקום gke.cluster, נתיב המשאב שונה ושיטות חיבור ספציפיות (dnsEndpoint או internalIp) לא רלוונטיות.

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

  • project_name

    הפרויקט שבו נמצא האשכול. Google Cloud

  • /location/global/

    המיקום שבו האשכול רשום. global, בכל המקרים.

  • membership_name

    השם של החברות באשכול.

הנה דוגמה:

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

כשמגדירים [multi-target], לא מציינים את המאפיין anthosCluster. האשכול מוגדר במקום זאת בתוך יעד הצאצא המתאים.

מידע נוסף על פריסה לאשכולות מצורפים של GKE זמין במאמר פריסה לאשכולות מצורפים של GKE.

לגבי יעדים בהתאמה אישית

ההגדרה של יעדים מותאמים אישית דומה לכל שאר סוגי היעדים, אבל היא לא כוללת את פסקה gke, את פסקה run או את פסקה anthosCluster.

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

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

כאשר CUSTOM_TARGET_TYPE_NAME הוא השם שבו השתמשתם בהגדרה של סוג טירגוט בהתאמה אישית.

הנה דוגמה:

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

executionConfigs

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

  • usages

    ‫RENDER או DEPLOY או שניהם, בנוסף ל-PREDEPLOY, VERIFY או POSTDEPLOY אם אימות או פריסת ווֹבּוּקים מופעלים ביעד. הם מציינים אילו מהפעולות האלה לבצע עבור היעד הזה באמצעות סביבת ההפעלה הזו. כדי לציין שסביבת ביצוע מותאמת אישית תשמש עבור predeploy hook,‏ render,‏ deploy,‏ postdeploy hook ואימות, צריך להגדיר אותה באופן הבא:

    usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY
- ANALYSIS

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

    עם זאת, אם יש סביבת הפעלה בהתאמה אישית עבור RENDER ו-DEPLOY, חובה לציין סביבת הפעלה עבור VERIFY, PREDEPLOY, POSTDEPLOY או ANALYSIS אם הם מוגדרים בצינור העברת הנתונים.VERIFY, ‫PREDEPLOY, ‏POSTDEPLOY ו-ANALYSIS יכולים להיות באותו usages כמו RENDER או DEPLOY, או בusages נפרדים.

    אי אפשר לציין את usages.VERIFY, usages.PREDEPLOY, usages.POSTDEPLOY או usages.ANALYSIS אלא אם מציינים את RENDER ואת DEPLOY באותן סביבות ביצוע מותאמות אישית או בסביבות ביצוע מותאמות אישית נפרדות.

  • workerPool

    ההגדרה של מאגר העובדים לשימוש. המאפיין הזה מקבל נתיב למשאב שמזהה את מאגר העובדים של Cloud Build שבו רוצים להשתמש בשביל היעד הזה. לדוגמה:

    projects/p123/locations/us-central1/workerPools/wp123.

    כדי להשתמש במאגר ברירת המחדל של Cloud Build, צריך להשמיט את המאפיין הזה.

    ליעד נתון יכולים להיות שני workerPoolים (אחד ל-RENDER ואחד ל-DEPLOY). כשמגדירים את מאגר ברירת המחדל, אפשר לציין חשבון שירות חלופי, מיקום אחסון חלופי או את שניהם.

  • serviceAccount

    שם חשבון השירות שבו רוצים להשתמש לפעולה הזו (RENDER או DEPLOY) עבור היעד הזה.

  • artifactStorage

    קטגוריית Cloud Storage שבה רוצים להשתמש לפעולה הזו (RENDER או DEPLOY) עבור היעד הזה, במקום קטגוריית ברירת המחדל.

  • executionTimeout

    זה שינוי אופציונלי. מגדיר את הזמן הקצוב לתפוגה, בשניות, לפעולות ש-Cloud Build מבצע עבור Cloud Deploy. ברירת המחדל היא 3600 שניות (שעה אחת).
    דוגמה: executionTimeout: "5000s"

  • verbose

    זה שינוי אופציונלי. אם true, רמות המלל מוגדרות ל-debug עבור הכלים הבאים:

    • ‫Skaffold --verbosity מוגדר כ-debug. ערך ברירת המחדל של Skaffold הוא warn.

    • ‫kubectl --v מוגדר ל-4, כלומר לניפוי באגים. ערך ברירת המחדל של kubectl הוא 2.

    • ‫Google Cloud CLI --verbosity מוגדר ל-debug. ערך ברירת המחדל הוא warning.

תחביר חלופי נתמך

ההגדרה executionConfigs שמתוארת במסמך הזה היא חדשה. התחביר הקודם עדיין נתמך:

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

כשמגדירים executionConfigs stanza עבור multi-target, כל יעד צאצא יכול לקבל בירושה את סביבת ההפעלה הזו מה-multi-target.

הגדרות של סוגי יעד בהתאמה אישית

בקטע הזה מתוארים השדות שמשמשים להגדרת סוגים מותאמים אישית של טירגוט

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

קובץ ה-YAML הבא מראה איך להגדיר סוג יעד בהתאמה אישית:

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

כאשר:

  • [CUSTOM_TARGET_TYPE_NAME]

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

  • [RENDER_ACTION_NAME]

    הוא השם של פעולת העיבוד בהתאמה אישית. הערך הזה הוא customAction.name שמוגדר ב-skaffold.yaml.

  • [DEPLOY_ACTION_NAME]

    הוא השם של פעולת הפריסה המותאמת אישית. הערך הזה הוא customAction.name שמוגדר ב-skaffold.yaml.

  • למידע על includeSkaffoldModules, אפשר לעיין במאמר בנושא שימוש בהגדרות תצורה מרוחקות של Skaffold.

הגדרות אוטומציה

בקטע הזה מתוארים השדות שמשמשים להגדרת משאבי האוטומציה של Cloud Deploy.

בדומה ליעדים, אפשר לכלול הגדרות של Automation בהגדרה של צינור העברת הנתונים, או בקובץ או בקבצים נפרדים.

מידע נוסף על אוטומציה ב-Cloud Deploy זמין במאמרי העזרה בנושא אוטומציה.

בקובץ ה-YAML הבא אפשר לראות איך מגדירים אוטומציה. חשוב לזכור שהפרטים הספציפיים של כל כלל אוטומטי שונים. (ההגדרות של סוגי הכללים האוטומטיים הזמינים מפורטות במאמר שימוש בכללים אוטומטיים).

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

rules:
- [RULE_TYPE]:
    id:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

כאשר:

  • [PIPELINE_NAME]

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

  • [PURPOSE]

    הוא שם תיאורי נוסף של הפעולות האוטומטיות האלה. בדרך כלל, זו הפעולה שאוטומטית. לדוגמה, my-app-pipeline/promote.

  • ‫labels ו-annotations הן תוויות או הערות שרוצים לשייך לפעולות האוטומטיות האלה.

  • [DESCRIPTION]

    תיאור אופציונלי של האוטומציה.

  • suspended

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

  • [SERVICE_ACCOUNT_ID]

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

    חובה לציין ערך למאפיין הזה. ‫Cloud Deploy לא משתמש בחשבון השירות שמוגדר כברירת מחדל לאוטומציות.

    לחשבון השירות הזה צריכות להיות ההרשאות הבאות:

    • הרשאה actAs להתחזות לחשבון השירות של ההרצה.

    • הרשאה לבצע את הפעולה שמבוצעת אוטומטית, למשל, clouddeploy.releases.promote כדי לקדם גרסה או clouddeploy.rollouts.advance כדי להעביר שלב בהשקה.

  • [TARGET_ID]

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

    אפשר להגדיר את הערך הזה ל-* כדי לבחור את כל יעדי ההצגה בצינור ההפצה.

  • [LABEL_KEY]:[LABEL_VALUE]

    הוא צמד מפתח/ערך שמשמש להתאמה לצמד מפתח/ערך שמוגדר ביעד. הפעולה הזו תבחר את כל היעדים שמשויכים לצינור העברת הנתונים שיש להם את אותה תווית ואותו ערך.

  • [RULE_TYPE]

    השם של כלל האוטומציה שמשמש לאוטומציה הזו. הערך יכול להיות promoteReleaseRule, timedPromoteReleaseRule, advanceRolloutRule או repairRolloutRule. אפשר לכלול יותר מכלל אחד באוטומציה, כולל יותר מכלל אחד מאותו סוג RULE_TYPE. לדוגמה, אפשר להגדיר יותר מכלל promoteReleaseRule אחד באותה פעולה אוטומטית. מידע נוסף.

  • [RULE_NAME]

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

  • [RULE-SPECIFIC_CONFIG]

    ההגדרה שונה לכל סוג אוטומציה נתמך. ההגדרות האלה מוצגות במאמר שימוש בכללי אוטומציה.

פריסת הגדרות מדיניות

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

כמו במשאבים אחרים של Cloud Deploy, אפשר לכלול הגדרות של DeployPolicy בהגדרת צינור ההפצה או בקובץ נפרד.

קובץ ה-YAML הבא מראה איך להגדיר מדיניות פריסה:

apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
  name: [POLICY_NAME]
  annotations: [ANNOTATIONS]
  labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
    id: [PIPELINE_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
  target:
    id: [TARGET_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
rules:
  - [RULE_TYPE]
      [CONFIGS]

כאשר:

  • [DESCRIPTION]

    טקסט אופציונלי שמתאר את המדיניות הזו.

  • [POLICY_NAME]

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

  • [ANNOTATIONS] וגם [LABELS]

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

  • suspended: [true | false]

    הגדרת suspended לערך true משביתה את המדיניות הזו.

  • [PIPELINE_ID]

    הוא המזהה של צינור ההפצה שרוצים שהמדיניות הזו תשפיע עליו. אפשר להשתמש ב-* כדי לציין את כל צינורות העיבוד. המזהה הזה זהה למאפיין metadata.name בצינור ההעברה.

  • [TARGET_ID]

    הוא המזהה של היעד שרוצים שהמדיניות הזו תשפיע עליו. אפשר להשתמש ב-* כדי לציין את כל היעדים. המזהה הזה זהה למזהה של הנכס metadata.name ביעד.

  • [LABEL_KEY]:[LABEL_VALUE]

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

  • [RULE_TYPE]

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

  • [CONFIGS]

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

פריסת כללי מדיניות

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

rolloutRestriction

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

קובץ ה-YAML הבא מראה איך להגדיר כלל rolloutRestriction:

rules:
- rolloutRestriction:
    id: [RULE_ID]
    actions:
    - [ACTIONS]
    invokers:
    - [INVOKERS]
    timeWindows:
      timeZone: [TIMEZONE]
      oneTimeWindows:
      - start: [START_DATE_TIME]
        end: [END_DATE_TIME]
      weeklyWindows:
      - daysOfWeek:
        - [DAY_OF_WEEK]
        - [DAY_OF_WEEK]
        startTime: [START_TIME]
        endTime: [END_TIME]

כאשר:

  • RULE_ID

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

  • ACTIONS

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

    • ADVANCE

      אי אפשר להקדים את השלבים של השקת התכונה.

    • APPROVE

      אי אפשר לאשר את השקת המבצע.

    • CANCEL

      אי אפשר לבטל השקות.

    • CREATE

      אי אפשר ליצור השקות.

    • IGNORE_JOB

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

    • RETRY_JOB

      אי אפשר לנסות שוב להריץ משימות.

    • ROLLBACK

      אי אפשר לבטל השקות.

    • TERMINATE_JOBRUN

      אי אפשר להפסיק הפעלות של משימות

  • INVOKERS

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

    • USER

      הפעולה מבוססת על פעולת משתמש. לדוגמה, יצירת השקה באופן ידני באמצעות פקודת ה-CLI של gcloud.

    • DEPLOY_AUTOMATION

      פעולה אוטומטית של Cloud Deploy.

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

  • TIMEZONE

    אזור הזמן בפורמט IANA שבו מציינים את חלון הזמן. לדוגמה, America/New_York. זהו שדה חובה.

  • START_DATE_TIME

    ‫oneTimeWindows, התאריך והשעה שמציינים את תחילת חלון ההגבלה, בפורמט "yyyy-mm-dd hh:mm". כדי לציין את תחילת היום, משתמשים ב-00:00. חובה למלא את השדה הזה.

  • END_DATE_TIME

    ‫oneTimeWindows: התאריך והשעה שמציינים את סוף חלון ההגבלה, בפורמט "yyyy-mm-dd hh:mm". כדי להגדיר את השעה לסוף היום, משתמשים ב-24:00. חובה למלא את השדה הזה.

  • DAY_OF_WEEK

    ‫weeklyWindows, היום בשבוע, SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY או SATURDAY. אם משאירים את השדה הזה ריק, המודעה תוצג בכל ימות השבוע

  • START_TIME

    עבור weeklyWindows, שעת ההתחלה ביום בשבוע שצוין. אם מציינים שעת התחלה, צריך לציין גם שעת סיום. כדי לציין את תחילת היום, משתמשים ב-00:00.

  • END_TIME

    עבור weeklyWindows, שעת הסיום ביום הספציפי בשבוע. אם מציינים שעת התחלה, צריך לציין גם שעת סיום. כדי להגדיר את סוף היום, משתמשים ב-24:00.

הגדרות של ניתוח

analysis stanza מאפשרת להגדיר ניתוח של עבודות כדי להריץ בדיקה אחת או יותר של התראות מ-Google Cloud Observability, או נתונים דומים מספקי ניטור אחרים, כדי לבצע פעולות על סמך ההתראות האלה.

הפסקה analysis שונה בהתאם להגדרות שלה: ל-Google Cloud Observability או לספק אחר באמצעות ניתוח בהתאמה אישית.

‫analysis ל-Google Cloud Observability

אפשר להשתמש ישירות בפסקה analysis בתוך קובץ ההגדרות של אסטרטגיית פריסה (strategy.standard.analysis, לשיטה רגילה). אם רוצים להגדיר ניתוח לכל שלב, משתמשים בגרסת גישוש מותאמת אישית (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis).

analysis:
  duration: DURATION
  googleCloud:
    alertPolicyChecks:
    - id: CHECK_ID
      alertPolicies:
      - ALERT_POLICY_NAME
      labels:
        LABEL_KEY: LABEL_VALUE

אלה מאפייני ההגדרה של analysis כשמשתמשים ב-Google Cloud Observability:

  • אתם יכולים להגדיר כמה alertPolicyChecks שתרצו.

  • ‫DURATION הוא משך הזמן, בשניות, בדקות או בשעות, להפעלת הניתוח. אחרי שהזמן הזה מסתיים, ההתראות מ-Google Cloud Observability לא משפיעות יותר על הניתוח. לדוגמה: 200s.

    ‫CHECK_ID הוא מזהה ייחודי לבדיקה של מדיניות ההתראות. התוצאה מוצגת בניתוח, לכל בדיקה.

  • ‫ALERT_POLICY_NAME הוא השם של מדיניות ההתראות שיצרתם ב-Google Cloud Observability.

  • ‫LABEL_KEY הוא שם של תווית שבה הבדיקה תשתמש כדי להתאים למדיניות ההתראות של Google Cloud Observability.

  • ‫LABEL_VALUE הוא הערך שצריך להיות זהה לכל תווית.

בהתאמה אישית analysis

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

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

analysis:
  duration: DURATION
  customChecks:
  - id: CHECK_ID
    frequency: FREQUENCY
    task:
      type: container
      image: IMAGE_NAME
      command: [COMMAND]
      args: [ARGS]
      env:
        [VAR: VALUE]

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

  • ‫CHECK_ID הוא מזהה ייחודי שאתם מספקים לבדיקה של מדיניות ההתראות. התוצאה מוצגת בניתוח של כל בדיקה.

  • FREQUENCY מציין באיזו תדירות, בשניות, בדקות או בשעות, להריץ את הבדיקה. לדוגמה, 300s.

  • ‫IMAGE_NAME הוא הנתיב לקובץ האימג' של הקונטיינר במאגר אימג'ים.

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

  • ‫ARGS היא רשימה של ארגומנטים שצריך לספק לפקודה. אם COMMAND הוא /bin/sh, אחד הארגומנטים יהיה -c, וארגומנט אחר יהיה הפקודה המלאה שרוצים להריץ במעטפת שמופעלת.

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

  • מידע נוסף על אופן הפעולה של Cloud Deploy

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

  • איך מנהלים את קובצי המניפסט

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